dev-skills/av-dev/skills/task-track/references/split.md

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

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

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

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

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

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

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

## Где резать, если резать можно

Тест выше говорит, **допустим** ли разрез. Где его провести из нескольких
допустимых мест — отвечает шов.

**Шов — там, где падает метка ревью.** Раздел «Затрагивает» перечисляет
границы; если одна строка перечня поднимает метку выше остальных, эта часть и
режется отдельно. Пример: задача перекладывает несколько узлов разом и заодно
добавляет два поля в существующий ответ. Целиком это `large` — полный состав проходов по
всему диффу, включая те, что держат машину и идут цепочкой. Разрезанная по шву,
она даёт `large` на маленькой переложенной части и `medium` на остатке.

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

**Это планирование, а не предписание процесса.** Метка ревью выбирается по
факту изменения — тем, кто его видит, — и в тело задачи не пишется: строка
«делать с меткой medium» это ровно тот второй дом правила выбора, который
гигиена полей снимает. Шов пользуется меткой как **признаком**, что в задаче
две разнородные работы; решение о метке остаётся за конвейером.

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

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

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

**Зонтика над частями нет никакого.** Тип `epic` упразднён, цель, игравшая его
роль после него, — тоже. Если частям нужен общий заголовок, у них общее место в
списке: они встают подряд, и соседство и есть тот ответ, ради которого заводили
зонтик.

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

Задача, которая **оказалась крупнее задачи**, распознаётся до того, как под неё
заведено предложение об изменении: иначе его придётся выбрасывать. Она выходит
из работы на декомпозицию, а её строка возвращается в беклог с причиной
(`move … --reason "крупнее задачи"`). **Место в списке частям назначает
человек**: машина поставит их в конец секции, а на стройке место наследуется от
родителя (`move --after`), да и на доработке крупная задача редко распадается на
что-то менее срочное, чем была сама.

## Мозговой штурм сырья

Сырьё — запись типа `research`, у которой раздел «Вопрос» пуст: она не проходит
тест «готова к взятию», потому что неясно, что именно делаем. Штурм проясняет —
и это **generative-операция, а не applicative**.

Исход штурма и есть заполненный «Вопрос» (тогда разведку можно брать в работу)
или набор задач с типами, которые из ответа следуют. Третий законный исход —
`close --reason`.

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

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

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

## Доклад

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