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

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

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

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

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

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

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

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

```bash
git checkout -b replanning-after-hello-hono
```

Запрос:

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

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

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

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

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

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

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

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

```markdown
## Интерфейс

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

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

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

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

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

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

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

Пример:

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

## 2026-05-01

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

Запрос:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

```bash
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. Обновите политику тестирования.
3. Добавьте требование к адаптивному дизайну.
4. Создайте журнал изменений.
5. Уточните дорожную карту.
6. Закоммитьте и сделайте слияние.

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

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