# Часть 12. MVP

MVP-фаза отличается от обычной фазы фичи. Здесь вы просите агента реализовать не один маленький кусок, а оставшуюся часть минимально жизнеспособного продукта. Это рискованно. Делать так стоит только если проектные правила, спецификации, тесты и проверка уже достаточно зрелые.

MVP полезен как стресс-тест ваших же спецификаций: если агент, прочитав конституцию и спецификации фич, строит не то, что вы ожидаете, проблема не только в агенте. Скорее всего, спецификации давали слишком много свободы или дорожная карта была непонятной.

## Когда можно пробовать MVP

Подходящий момент:

- как минимум две фичи уже прошли полный цикл;
- `mission.md`, `tech-stack.md`, `roadmap.md` актуальны;
- есть политика тестирования;
- есть журнал изменений;
- вы готовы проверять большой объём изменений;
- дорожная карта содержит чёткие границы MVP.

Неподходящий момент:

- первая же фаза проекта;
- нет тестов;
- дорожная карта расплывчата;
- агент уже часто нарушает границы;
- вы не можете выделить время на проверку.

## MVP-запрос для Qwen Code

```text
/clear
Прочитай @QWEN.md, @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md
и все существующие спецификации фич в @specs/.

Мы рассматриваем MVP-ветку.
Пока ничего не реализуй.

Сначала:
1. найди минимальный набор оставшихся пунктов дорожной карты, нужных для MVP;
2. перечисли риски их совместной реализации;
3. задай мне три группы вопросов о границах MVP, решениях и проверке.
```

После ответов:

```text
Создай specs/YYYY-MM-DD-mvp/requirements.md, plan.md и validation.md.
План должен быть разбит на группы, чтобы я мог просить реализовать его по частям.
Код реализации пока не пиши.
```

## Пример границ MVP

```markdown
# Требования — MVP

## Границы

MVP должен сделать AgentClinic цельной небольшой демонстрацией:
- главная страница;
- агенты и недуги;
- терапии;
- форма запроса на приём;
- сводка панели управления;
- адаптивные стили;
- тесты критичных маршрутов.

## За границами

- Аутентификация.
- Оплата.
- Отправка писем.
- Интерфейс администрирования для редактирования.
- Внешнее развёртывание.

## Решения

- Использовать таблицы SQLite и начальные данные.
- Отправленные формы сохранять локально.
- Всё рендерить на сервере.
- Использовать существующий макет и CSS-соглашения.
```

## Проверка MVP

Для MVP проверка должна быть жёстче, чем для маленькой фичи:

```markdown
## Автоматические проверки

- npm run typecheck проходит успешно.
- npm test проходит успешно.
- Тесты маршрутов покрывают /, /agents, /ailments, /therapies и /appointments.
- Тесты базы данных покрывают миграции и начальные данные.

## Ручные проверки

- В свежем клоне можно запустить npm install, npm run seed и npm run dev.
- Основная навигация ведёт на все страницы MVP.
- Форма записи обрабатывает корректный и некорректный ввод.
- На мобильной ширине 375px макет не ломается.
- Журнал изменений описывает MVP-ветку.

## Проверка отклонений

- Аутентификация не добавлена.
- Клиентский фреймворк не добавлен.
- Внешние сервисы не требуются.
```

## Реализация MVP по группам

Даже если спецификация MVP одна, реализацию не обязательно делать одной командой.

```text
Реализуй только группу 1 из @specs/2026-05-05-mvp/plan.md.
Запусти нужные проверки.
Остановись и перечисли изменённые файлы.
```

Потом:

```text
Реализуй группу 2.
Не редактируй файлы из группы 1, если этого не требует проверка.
```

Так вы сохраняете контрольные точки, которые удобно проверять.

## Когда остановиться: таймбоксинг и откат к последней зелёной точке

MVP-ветка склонна разрастаться. Агент реализует группу 1, потом группу 2, потом начинает «по ходу» поправлять группу 1 под группу 3 — и через час непонятно, в каком состоянии репозиторий.

Заранее зафиксируйте две вещи: бюджет времени и точку отката.

**Бюджет времени.** Договоритесь с собой (или с командой) о таймбоксе на сессию. Для учебного MVP это 2–4 часа. Когда таймбокс истёк, не «ещё одна группа» — остановка, оценка, решение.

**Точка отката.** Перед каждой группой задач делайте коммит, даже если он промежуточный. После коммита запускайте `npm run typecheck` и фиксируйте, что эта точка зелёная:

```bash
git commit -m "MVP group 1: agents page"
npm run typecheck
git tag mvp-green-1
```

Если следующая группа всё ломает и за разумное время вы не понимаете, как починить — откатывайтесь к последнему зелёному состоянию:

```bash
git reset --hard mvp-green-1
```

Это не поражение. Это сигнал, что спецификация MVP была недостаточно детальной для конкретной группы — её надо доуточнить отдельной малой фичей вместо того, чтобы добивать в MVP-ветке.

Признаки, что пора остановиться раньше таймбокса:

- агент два раза подряд возвращается к одной и той же группе и не закрывает её;
- `git diff --stat` показывает изменения в файлах, которых нет ни в одной группе плана;
- после очередной реализации перестают проходить тесты, которые проходили до неё;
- агент начинает спрашивать «можно я заодно…» — это значит, граница MVP стала ему мешать, и спецификации надо поправить, а не границу подвинуть.

## После MVP спросите о пробелах в спецификации

Один из лучших вопросов:

```text
По реализации MVP скажи, что тебе пришлось вывести самому, потому что это не было явно задано.
Перечисли пробелы в спецификациях и предложи обновления для mission, tech-stack, roadmap или спецификации MVP.
Файлы не изменяй.
```

Если агент честно отвечает «я сам решил X», это подарок. Запишите X в спецификации, если решение важно.

## Практика

- [ ] Не начинайте MVP, пока две малые фазы не пройдены.
- [ ] Попросите Qwen Code оценить готовность.
- [ ] Создайте спецификацию MVP.
- [ ] Зафиксируйте таймбокс сессии и точку отката.
- [ ] Реализуйте группы задач MVP по частям, тегируя зелёные точки.
- [ ] Проведите проверку отклонений.
- [ ] Обновите проектные правила и журнал изменений.

## Контрольные вопросы

1. Почему MVP — стресс-тест спецификаций?
2. Какие условия должны быть выполнены до крупной агентской реализации?
3. Почему после MVP нужно спрашивать агента о неявных выводах?