smozhesh-sozdat-protokol-tes/design-system/docs/GOAL.md

Цель: KT AI как фабрика прототипов

Северная звезда дизайн-системы KT AI. Этот документ отвечает на вопрос «зачем всё это» и задаёт критерий, по которому проверяется любое решение по системе. DESIGN.md — чем строить, PRINCIPLES.md — почему так, GOAL.md — ради чего.

Standing instruction (/goal)

Строить из дизайн-системы KT AI фабрику прототипов, где бизнес-аналитик за один рабочий день превращает паспорт агента и интервью Төре в правдивый кликабельный прототип процесса владельца, итерирует с владельцем в течение часов, а на выходе отдаёт команде разработки репозиторий с продакшн-готовым фронтендом без дизайн-долга. Главное уравнение системы: прототип === фронтенд продакшна. Каждое улучшение приближает это уравнение к истине; что не приближает — не приоритет.

Делать по одному, проверять, улучшать. Систему держать маленькой и честной (правило двух продуктов).

Конечный образ результата

БА садится с владельцем процесса — на руках паспорт агента и 25-минутное интервью Төре. К концу того же дня владелец кликает прототип своего процесса: его колонки, его статусы, его рабочее действие, AI-ассистент отвечает по его данным. Не макет с выдуманными строками — правдивый первый срез. Владелец оставляет комментарии прямо на экране. БА правит конфиг, не код, — следующая версия готова в тот же день.

После одобрения БА отдаёт разработчикам git-репозиторий, фронтенд которого уже продакшн-готов: те же токены, те же компоненты, тот же код. Разработчики добавляют только то, что умеют только они: авторизацию, роли, реальные интеграции, бэкенд. Фронтенда они почти не пишут. Дизайн-долга на handoff нет, потому что прототип и продукт никогда не были разными вещами.

Определение готовности (Definition of Done системы)

1. Один контракт. Единый типизированный продуктовый контракт (product.config) — общий язык: Төре его выдаёт, превью рендерит, React-стартер из него собирается, валидатор проверяет, handoff-док из него читает. Четырёх копий одной идеи больше нет.
2. Один рантайм. Кликабельный прототип БА и стартовый репозиторий разработчика — один и тот же код. HTML-превью без сборки — быстрое окно в тот же контракт, а не параллельная вселенная.
3. Правда по построению. У каждого поля, которое видит владелец, объявлены тип, допустимые значения, владелец данных и признак редактируемости — это собирается в паспорте/интервью. Никакой выдумки перед владельцем процесса.
4. Канон через проверку, не через память. kt-ai-lint валит сборку на сырых hex, отступах вне шкалы, втором primary, debug-языке в копирайте, запрещённых ROI/FTE на операционном дашборде. 12-пунктовый чек-лист становится машиной, которая говорит да или нет.
5. Архетипы, не одна форма. БА выбирает архетип экрана (Операционная очередь / Документ-сравнение / Разговорный агент / Кабинет-решение); у каждого свой пресет контракта, свой эталонный клонируемый прототип и свои правила.
6. Замкнутая петля обратной связи. Прототип несёт режим комментирования в контексте; обратная связь владельца возвращается структурными заметками, а не скриншотами и памятью о созвоне.
7. Маленькая и честная. Правило двух продуктов держится; система растёт, только когда второй продукт это заслужил; дрейф между ДС, копией в Төре и стартером — структурно ноль.

Метрики (как поймём, что дошли)

Метрика	Цель
Время до первого прототипа (интервью → кликабельный)	< 1 рабочего дня
Цикл итерации (фидбэк → новая версия)	часы, не спринт
Переиспользование фронтенда на handoff	≥ 80% уходит в прод без изменений
Дизайн-долг на handoff	ноль переверстки
Дрейф ДС / Төре / стартер	ноль (один источник, CI)
Пропускная способность одного БА	3–4 прототипа в месяц без дизайнера в цикле

Последовательность строительства (по одному)

P0 — общий хребет (это и есть цель, остальное — полировка):

1. Единая схема продуктового контракта (Zod/JSON Schema): Төре выдаёт, превью и стартер потребляют, валидатор проверяет.
2. Один рантайм: shadcn-стартер рендерит из типизированного контракта; HTML app-shell демотирован до превью того же контракта без сборки.
3. Field-level data contract в паспорте и интервью Төре (тип, значения, владелец, редактируемость).

P1 — быстро и честно на масштабе: 4. kt-ai-lint — исполняемые правила на сгенерированном выводе, в CI. 5. Пресеты архетипов + эталонные клонируемые прототипы. 6. Режим обратной связи в прототипе (комментарии в контексте → markdown).

P2 — гигиена: 7. Убрать дубликат ДС из репозитория Төре (submodule/пакет/CI-проверка). 8. Одностраничный runbook старта + один машинный свод правил; глубокие доки — справочник. 9. visual_check.mjs в CI без ручного запуска.

Решающий критерий

Перед любой работой по системе спросить: приближает ли это уравнение «прототип === фронтенд продакшна»? Если да — делаем. Если нет — это не приоритет, как бы красиво ни выглядело.