Часть 10. Перепланирование проекта

После первой фичи хочется сразу строить следующую. В SDD лучше сделать паузу. Перепланирование — это момент, когда вы обновляете проектные документы, пока отклонение ещё мало. Чем быстрее агент пишет код, тем важнее регулярно возвращаться к проектным правилам.

Перепланирование отвечает на вопросы:

• что мы узнали после предыдущей фазы;
• нужно ли обновить технологический стек;
• не устарела ли дорожная карта;
• какие проверки должны стать обязательными;
• есть ли повторяемый процесс, который стоит автоматизировать.

Пример перепланирования после Hello Hono

После первой фичи можно понять:

• нужен Vitest для проверки;
• нужен адаптивный дизайн как проектное правило;
• нужен CHANGELOG.md;
• дорожная карта слишком раздроблена или, наоборот, слишком крупная;
• запрос к Qwen Code для спецификации фичи повторяется и просится в навык.

Создайте ветку:

git checkout -b replanning-after-hello-hono

Запрос:

/clear
Прочитай @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md
и завершённую спецификацию фичи Hello Hono.

Мы проводим фазу перепланирования.
Не реализуй новые продуктовые фичи.
Предложи изменения для:

1. политики тестирования с Vitest;
2. адаптивного дизайна как общего требования к продукту;
3. ведения журнала изменений;
4. размера фаз в дорожной карте.

Перед правкой перечисли предлагаемые изменения файлов.

Обновление tech-stack.md

Добавьте политику тестирования:

## Тестирование

- Vitest проверяет маршруты, компоненты и базу данных.
- `npm test` должен запускать `vitest run`.
- В файлах проверки фичи должны быть названы обязательные автоматические проверки.

Добавьте ограничение для интерфейса:

## Интерфейс

- HTML рендерится на сервере через Hono JSX.
- Обычный CSS, если новая зависимость не одобрена явно.
- Страницы должны работать на мобильной ширине 375px и настольной ширине 1280px.

Обновление старых спецификаций

Когда проектные правила меняются, старые спецификации фич могут стать неполными. Попросите Qwen Code:

Обнови существующие спецификации фич под новую политику тестирования
и адаптивного дизайна.
Пока не меняй реализацию, если этого не требует обновлённая проверка.
Перед правкой покажи краткое резюме.

Это важно: история спецификаций должна объяснять, какие правила действовали на момент реализации.

Журнал изменений как коммуникация

CHANGELOG.md полезен не только людям. Агент тоже может читать его как краткую историю проекта.

Пример:

# Журнал изменений

## 2026-05-01

- Добавлена конституция проекта для SDD.
- Реализована базовая фича Hello Hono.
- Добавлены макет, статический CSS и строгая проверка TypeScript.

Запрос:

Создай или обнови @CHANGELOG.md.
Используй заголовки с датами.
Опирайся на историю Git и изменения текущей ветки.
Пиши кратко и понятно для заинтересованных людей.

Изменение размера фаз в дорожной карте

Плохая дорожная карта:

## Фаза 2: построить все фичи приложения

Слишком широко. Агент внесёт много изменений, человеку будет тяжело проверять.

Плохая дорожная карта:

## Фаза 2: добавить один CSS-отступ

Слишком мелко. Больше накладных расходов, чем ценности.

Хорошая дорожная карта:

## Фаза 2: Агенты и недуги

Цель: добавить базовую доменную модель и страницы только для чтения.

- [ ] Добавить SQLite-схему для агентов и недугов.
- [ ] Добавить начальные вымышленные данные.
- [ ] Добавить страницы /agents и /ailments.
- [ ] Добавить тесты маршрутов и компонентов.

Шаг кодификации: что превратить в правило

Перепланирование — момент, когда вы превращаете разовые наблюдения в постоянные правила. Если этого не делать, каждая следующая фича повторит ту же ошибку, а агент будет угадывать каждый раз заново.

Кодификация — это запись наблюдения как одного из четырёх артефактов:

• **Правило в QWEN.md.** Подходит, когда наблюдение касается поведения агента: «никогда не меняй tsconfig.json без подтверждения», «всегда показывай список изменённых файлов перед записью».
• **Решение в tech-stack.md.** Подходит, когда наблюдение касается долговременного технического выбора: «используем Vitest для всех тестов», «без ORM в первых фазах», «все таблицы получают created_at».
• **Шаблон в validation.md.** Подходит, когда наблюдение касается формы проверки: «для маршрута проверять и 200, и 404», «для миграции проверять идемпотентность повторным запуском».
• Хук, навык или запрос. Подходит, когда наблюдение повторяется механически и его проще автоматизировать (см. части 14 и 17).

Простой запрос для шага кодификации в конце ветки перепланирования:

По итогам фичи Hello Hono и проведённого перепланирования предложи

список изменений в QWEN.md, tech-stack.md, шаблоне validation.md
и наборе хуков/навыков. Для каждого пункта укажи:
1. наблюдение, которое к этому привело;
2. предлагаемое правило или артефакт;
3. в какой файл его внести;
4. почему его не стоит держать только в чате.
Файлы пока не изменяй.

Если список длиннее 5–7 пунктов, не пытайтесь внедрить всё разом — выберите два-три самых частых наблюдения, запишите их и оставьте остальное на следующее перепланирование.

Маховик обратной связи: сигнал → что обновить

Чтобы кодификация не превращалась в большой ритуал, держите под рукой короткое соответствие «сигнал → что обновить». Удобно представлять это как маховик: каждое наблюдение из последней фичи запускает обновление, которое снижает шанс той же проблемы в следующей.

| Тест прошёл, но реальное поведение оказалось неверным | новый факт в validation.md, возможно — другого уровня (см. часть 9) | | Решение появилось в коде, но не в requirements.md | внести задним числом в requirements.md через ветку перепланирования | | Однотипный запрос к агенту повторяется уже в третий раз | вынести запрос в .qwen/skills/<name>/SKILL.md | | Опасная команда чуть не была выполнена | добавить защитный хук (часть 17) | | Секрет чуть не попал в спецификацию | правило в QWEN.md + сценарий проверки (часть 18) |

Список не претендует на полноту. Его задача — показать, что для каждого замеченного сбоя есть постоянное место для записи реакции. Если место найти не удаётся, это сигнал, что в проектной структуре не хватает раздела, и его стоит завести.

Коммит перепланирования

npm test
npm run typecheck
git add specs CHANGELOG.md package.json package-lock.json vitest.config.ts tests
git commit -m "Replan workflow after first feature"
git checkout main
git merge replanning-after-hello-hono
git branch -d replanning-after-hello-hono

Практика

1. Создайте ветку для перепланирования.
2. Обновите политику тестирования.

1. Добавьте требование к адаптивному дизайну.
2. Создайте журнал изменений.
3. Уточните дорожную карту.
4. Закоммитьте и сделайте слияние.

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

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