Files
dev-skills/av-dev-pm/skills/tasks/references/split.md
T
avandClaude Opus 5 21b840a8e4 профили ревью: тяжёлые проходы в верхнюю ступень, на умолчании — один базовый
Тема 33 сняла самую большую разовую статью расхода, но не тронула главную —
частоту. Меряющая пара стояла в standard, то есть на большинстве задач, и именно
она делала прогон долгим: два прохода держат машину, идут цепочкой и доказывают
находки запуском. Цель разбора названа прямо: лучше поправить в следующей задаче,
чем держать одну два часа.

adversary и ops переехали в wide. Стадия осталась самой урожайной за всю историю
замеров — пять из семи выживших находок дозапуска и единственная находка про
молчаливый старт отката, — но её ценность оплачивается на каждой задаче, а
получается на немногих. Решение по цене, не по ценности.

Заведён review-basics: мелкая осадка двух тяжёлых проходов, без единого запуска.
Стоит только в standard. Восемь вопросов, на которые отвечают чтением: таймаут и
отказ соседа, идемпотентность и одновременная запись, остановка на середине,
частичный откат при двух версиях, наблюдаемость и тишина, очевидный рост объёма,
второй способ мимо единой точки (грепом, не картой), что отсюда удалить. Потолок
4 находки, машину не держит, ничего не меряет.

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

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

Лестница вышла 4/5/7. Главный выигрыш не в числе проходов, а в том, что из
standard ушла цепочка: теперь там гейт, три прохода одним сообщением и триаж —
граф плоский, ждать некому.

Правило выбора ступени переписано на два вопроса, и объём изменения вошёл в него
впервые. Крупное или незнакомое — трогает несколько узлов, переносит
ответственность, форму решения нащупывают по ходу — это wide, и он рассчитан на
5-10% задач. Мелкое — один узел, форма очевидна заранее, откат сводится к
обратной правке — quick. Всё остальное standard, рабочее умолчание. Раньше
ступень выбиралась только по классу изменения и на размер смотреть запрещала;
теперь признаков два: класс отвечает за обратимость, объём — за цену
разбирательства.

Отрицательный тест сохранил прежнюю мудрость в новой рамке: что после мерджа не
откатывается обратной правкой — не quick, каким бы маленьким ни был дифф. Три
строки миграции идут в standard.

Спорный случай решается вниз, и асимметрия объяснена ценой: ошибка в сторону
standard стоит находки на следующей задаче, ошибка в обратную — трёх тяжёлых
проходов на каждой задаче, выбранной неверно.

Сделка записана вместе с обратной связью, иначе это тихая потеря качества. На
quick и standard не проверяется ничего, что требует запуска: построенный путь,
эксперимент против драйвера, любое число. Это самая крупная граница покрытия
конвейера, и она идёт строкой в каждом таком прогоне поимённо. Сигналов о том,
что ступень занижена, два: журнал дефектов в docs/review.md и сам basics —
он единственный, кто смотрит на дифф целиком на нижних ступенях, и обязан
сказать строкой, если задача выглядит крупнее профиля.

Побочно: условие профиля design то же самое, так что rubric и architecture на
предложении тоже упали до 5-10% задач.

Тема 34 в DECISIONS.md, следствия 130-133. Версия канона не поднята; инструкция
проекту дописана в пункт 8 записи «Версия 4».

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

9.9 KiB
Raw Blame History

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • части полностью замещают его → close <slug> --reason "разложена на a, b". REJECTED.md здесь — не «выкинули», а именно тот след, что переживает запись: через квартал вопрос «куда делась задача X» отвечается строкой со ссылками на наследников, а не археологией git;
  • родитель осмыслен как возможность, а не как шаг → это цель. Тип на месте не меняется (цель живёт в другом индексе): заводится --type goal в ROADMAP.md, части получают --goal <новый слаг>, родитель закрывается с причиной-ссылкой.

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

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

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

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

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

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

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

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

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

Доклад

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