Files
dev-skills/av-dev-pm/skills/tasks/references/split.md
T
avandClaude Opus 5 cc173b6b94 ступень ревью поднимает проход, а не риск
Полный набор гонялся чаще, чем оправдано, и размер задач тут вторая причина,
не первая. Первая — триггеры: миграция схемы, публичный контракт и инвариант
поднимали ступень, не добавляя ни одного прохода. Миграцию гоняет gate шагом
миграций и разбирает ops, контракт сверяет specs направлением code→spec,
инвариант даёт основание для critical любому проходу — все трое уже в
standard. На проекте с базой и эндпоинтами верхняя ступень оказывалась не
исключением, а умолчанием: правило объявляло исключением то, что происходит
всегда.

Теперь ступень поднимает то, что даёт работу новому проходу. wide означает
ровно одно — изменение вводит новое понятие или структурную единицу; добавить
поле в существующий ответ это не концепт. standard стал рабочим умолчанием.
Проект, где изменение контракта и правда архитектурное, поднимает его сам в
docs/review.md — уточнением, а не возвратом прежнего умолчания.

Чекпоинт design получил то же условие: specs идёт всегда, rubric и
architecture — только при новом понятии. Он стоит на каждой задаче, поэтому
при мелкой нарезке три прохода умножаются на число задач.

Со стороны задач — шов нарезки: тест декомпозиции отвечает, допустим ли
разрез, шов отвечает, где его провести. Резать по границе, за которой падает
ступень; не резать, когда обе половины остаются в одной — костяк из четырёх
проходов платится за каждую задачу, и такой разрез делает ревью дороже.
Порога в числе границ нет по тому же принципу, что в теме 16: размер не
триггер. Дешёвое место заметить разнородную задачу — показ набора спринта,
там «Затрагивает» уже написан, а предложение ещё не заведено.

Правило выведено из состава проходов, а не из статистики прогонов — замер
остаётся за обкаткой. DECISIONS 18, RRR–WWW и следствия 72–75; JJJ темы 17
помечен как пересмотренный. Шаг про «Триггеры профиля» дописан в ещё не
выкаченную версию 3 канона, а не отдельной версией.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 17:06:12 +03:00

9.1 KiB
Raw Blame History

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

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

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

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

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

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

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

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

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

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

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

Цель наследуется. Все части несут 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 после правок.
  • Границы покрытия: какие постановки рассмотрены и какие сознательно отброшены — чтобы штурм не пришлось повторять с нуля.