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>
107 lines
9.1 KiB
Markdown
107 lines
9.1 KiB
Markdown
# Декомпозиция и мозговой штурм
|
||
|
||
Обе операции превращают одну запись в несколько (или в ноль). Разница во входе:
|
||
декомпозиция дробит **готовую задачу или эпик**, штурм прорабатывает **идею**,
|
||
которая ещё не задача.
|
||
|
||
## Тест декомпозиции
|
||
|
||
Задачу можно дробить, только если части удовлетворяют **обоим** условиям:
|
||
|
||
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` после правок.
|
||
- Границы покрытия: какие постановки рассмотрены и какие сознательно отброшены —
|
||
чтобы штурм не пришлось повторять с нуля.
|