58 lines
8.4 KiB
Markdown
58 lines
8.4 KiB
Markdown
# Цель: 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 без ручного запуска.
|
||
|
||
## Решающий критерий
|
||
|
||
Перед любой работой по системе спросить: **приближает ли это уравнение «прототип === фронтенд продакшна»?** Если да — делаем. Если нет — это не приоритет, как бы красиво ни выглядело.
|