# Декомпозиция и мозговой штурм

Обе операции превращают одну запись в несколько (или в ноль). Разница во входе:
декомпозиция дробит **готовую задачу или эпик**, штурм прорабатывает **идею**,
которая ещё не задача.

## Тест декомпозиции

Задачу можно дробить, только если части удовлетворяют **обоим** условиям:

1. **Мерджатся независимо.** Часть Б не требует, чтобы часть А была уже влита.
   Есть порядок «сперва А, потом Б, иначе не собрать» → это не декомпозиция, а
   план реализации: шаги остаются **внутри одного файла**.
2. **Каждая даёт видимую пользу.** Часть, полезная только в комплекте с другой,
   — не самостоятельная задача. Пользу проверяй тестом «готова к взятию»
   (task-format): что станет наблюдаемо иначе именно от этой части и какие у неё
   собственные критерии приёмки.

Не проходит хотя бы одно — **не дроби**. Ложная декомпозиция плодит файлы,
которые нельзя взять поодиночке, и переоценка потом склеивает их обратно.

**Цель наследуется.** Все части несут `goal:` родителя: декомпозиция не меняет
того, чему работа служит. Если у части цель другая — это признак, что дробили не
по той границе, либо что часть вообще из другой работы.

## Что делать с родителем

После разделения родитель **не остаётся** третьей висящей строкой:

- части полностью замещают его → `close <slug> --reason "разложена на a, b"`.
  `REJECTED.md` здесь — не «выкинули», а именно тот след, что переживает запись:
  через квартал вопрос «куда делась задача X» отвечается строкой со ссылками на
  наследников, а не археологией git;
- родитель осмыслен как зонтик → `edit <slug> --type epic`, тело — ссылки на
  задачи-части, своих шагов у него нет. **Эпик не берётся в спринт** и живёт
  ровно до тех пор, пока не закрыта последняя часть.

Зонтик, который перестал быть временным и описывает направление, а не работу, —
это уже **цель**, а не эпик. Тип на месте не меняется (цель живёт в другом
индексе): заводится `[goal]` в `ROADMAP.md`, задачи получают `--goal <новый слаг>`,
эпик закрывается с причиной-ссылкой.

## Когда декомпозиция случается посреди спринта

Задача, которая **переросла в эпик**, распознаётся до того, как под неё заведено
предложение об изменении: иначе его придётся выбрасывать. Она помечается
`[epic]`, выходит из набора (`sprint drop … --reason "переросла в эпик"`), уходит
на декомпозицию, а спринт продолжается остальными. Части заводятся сразу, но в
текущий набор **не добавляются** — набор заморожен.

## Мозговой штурм идеи

Идея (`[idea]`) не проходит тест «готова к взятию»: неясно, что именно делаем.
Штурм проясняет — и это **generative-операция, а не applicative**.

Applicative-штурм («перечисли задачи, следующие из идеи») выдаёт очевидное:
перечисляется то, что уже видно в формулировке. Ценное — на уровень выше.

1. **Сперва — формы, а не задачи.** Предложи **три разные постановки** идеи и
   назови **компромисс каждой**: что она даёт, чем платит, что оставляет за
   бортом. Если получилась одна постановка — штурм не состоялся, это
   applicative.
2. **Вынеси формы пользователю** через `AskUserQuestion` с компромиссами. Рамку
   выбирает он: это продуктовое решение, не механика.
3. **Назови цель.** Выбранная форма служит какой-то цели — существующей или
   новой. Идея, для которой цель не находится, скорее всего уезжает в
   `REJECTED.md`, а не заводится задачей.
4. **Только выбранную форму** дроби по тесту декомпозиции выше и проставь
   критерии приёмки: без них наследники останутся идеями под другим именем.

**«Выкинуть» — полноправный исход штурма, а не его неудача.** Проработка, честно
показавшая, что пользы нет или она несоразмерна цене, — это результат: идея
уезжает с этой самой причиной, и та причина гасит её повторное появление.

## Доклад

- Идея/задача на входе, выбранная рамка (для штурма), задачи-наследники со
  слагами, целями и секциями.
- Судьба родителя: удалён / стал эпиком / стал целью / выкинут с причиной.
- `tasks.py check` после правок.
- Границы покрытия: какие постановки рассмотрены и какие сознательно отброшены —
  чтобы штурм не пришлось повторять с нуля.