avandClaude Opus 5
d5bee11a6b
Канон 5 объявил «каждый документ docs/ — тема ревью». Правило верно ровно наполовину и потому вредно целиком. Паспорт и схему хранилища ревью читает, но темами они не являются: по ним нельзя сказать «в этом изменении сделано не так», они задают границу, по которой судит чужая тема. Журнал решений и журнал наблюдений ревью изменения не нужны вовсе — ADR объясняет прошлое, а не предъявляет требование. Разметчик, применявший правило буквально, обязан был либо завести фантомные темы passport, adr, database, research и продублировать ими работу architecture и operations, либо потерять четыре документа молча; случались обе ветки, и в собственном образце плана docs/passport.md не попадал ни строкой, а обязательная арифметика покрытия при этом не сходилась. Категорий теперь три, разрез проверяемый. Тема — да, прямо: conventions, security, architecture и любой свой документ проекта. Источник темы — нет, но он задаёт границу для чужой: passport, database, CLAUDE.md, openspec/specs. Процессный — нет, он про то, как мы работаем: tasks, review, adr, research, .pm.json. Открыта одна категория из трёх, две другие перечислены поимённо, так что документ вне раскладки — однозначно своя тема. adr и research прогон больше не открывает ни одним проходом; docs/review остаётся читаемым, но как настройка конвейера, а не критерий. Цена записана и стала обязательной строкой границ покрытия: расхождение с записанным решением ловит теперь только сверка документации, а число под находкой обязано быть снято на этом прогоне, с приложенной командой. Классификация выдаёт задаче метку — small, medium, large. Прежние quick, standard и wide назывались ступенью и описывали ревью: как глубоко смотрим. Классифицируется же задача, и пока величина называлась свойством прогона, её естественно было пересчитывать на каждом прогоне — что конвейер и делал. Слово «ступень» удалено, а не оставлено синонимом: два имени одной вещи расходятся. Выводится метка из двух разведённых осей — размер (малое, среднее, крупное) и сложность (знакомое, незнакомое), — и равна максимуму по ним. Метка не синоним размера: малое незнакомое изменение получает large, трогая один узел, поэтому план печатает три строки с обоснованием каждая и выводить одну из другой запрещено. Оси остались русскими словами — это суждение прозой; метка английская — это идентификатор, который проходы сравнивают. Разметка переехала из ревью кода в шаг 4 пайплайна, сразу после propose. Она шла первым проходом каждого ревью кода, а перед ревью дизайна ту же величину называл сам пайплайн — то есть оркестратор, который только что довёл предложение до propose. Одно и то же измерялось дважды, и один из двух раз без разведённости с автором, ровно в той точке, ради которой разметчик заведён. Теперь запуск один на задачу, диффа он не видит, план обслуживает обе стадии, и метка после кода не пересматривается: расхождение факта с разметкой ловит журнал дефектов постфактум, как и всякую другую ошибку выбора. На диск план не пишется — четвёртый артефакт рядом с proposal, tasks и design пережил бы задачу и разошёлся бы с ней молча. Ревью дизайна тоже растёт меткой: small — specs, medium — плюс rubric, large — плюс architecture и вопрос автору о трёх формах решения. Раньше rubric и architecture включались одним условием, и medium получал ровно один проход, то есть не отличался от quick ничем. Разведены они потому, что зарабатывают на разном: рубрика порождает свойства узла и окупается уже на среднем изменении, её выход уезжает приёмочными критериями в tasks.md; архитектура отвечает на вопрос про второй способ, а он на среднем знакомом изменении отвечается «нет» ещё до запуска. small подешевел тремя способами сразу. Составом: приёмник тем не запускается, три темы ядра переходят к code сверкой по записанным инвариантам CLAUDE.md с потолком в одну находку, и это не «глубина ниже», а другой дом темы. Входом: specs читает только дельта-спеку, code — только индекс конвенций. Потолком: он появился у каждого опиниативного прохода, а не у одного basics, и у половин code он раздельный, потому что конвенционных находок больше по построению и в общем списке они вытеснили бы техническую половину. Сработавший потолок обязан быть объявлен строкой — молчащий срез неотличим от «больше не нашлось». Отрицательный тест small от этого стал жёстче, а не мягче: вопросы про обратимость миграции задавал приёмник тем, и на этой метке их не задаст никто. Пайплайн задачи вырос до двенадцати шагов. Тривиальность перестала решать состав ревью — она влияет только на explore; глубину обеих стадий называет метка. Проверено прогоном ревьюверов по готовому результату: девять расхождений найдено и починено — контракт находок печатал старый перечень проходов вместо плана по темам, три ссылки в task-batch указывали на шаг коммита вместо закрытия, запись changelog не переводила вопросы, адресованные passport и database, ops и adversary утверждали, что на нижних метках их вопросы задаёт basics, шаблон покрытия в review-code зашивал потолки small намертво, триггеры метки рассыпались на два списка против трёх, тема из директивы CLAUDE.md могла остаться без запуска исполнителя. Гейт зелёный: фронтматтеры, копии, одиннадцать диаграмм, ruff, pyrefly; docs.py прогнан на живом фикстуре и печатает категорию в отказе. Канон повышен до версии 6 с записью, выполнимой upgrade. Решения — 40–44. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
114 lines
9.9 KiB
Markdown
114 lines
9.9 KiB
Markdown
# Декомпозиция и мозговой штурм
|
||
|
||
Обе операции превращают одну запись в несколько (или в ноль). Разница во входе:
|
||
декомпозиция дробит **слишком крупную задачу**, штурм прорабатывает **идею**,
|
||
которая ещё не задача.
|
||
|
||
## Тест декомпозиции
|
||
|
||
Задачу можно дробить, только если части удовлетворяют **обоим** условиям:
|
||
|
||
1. **Мерджатся независимо.** Часть Б не требует, чтобы часть А была уже влита.
|
||
Есть порядок «сперва А, потом Б, иначе не собрать» → это не декомпозиция, а
|
||
план реализации: шаги остаются **внутри одного файла**.
|
||
2. **Каждая — самостоятельный шаг.** Часть, осмысленная только в комплекте с
|
||
другой, — не задача. Проверяй тестом «готова к взятию» (task-format): какую
|
||
строку «Завершения» цели двигает **именно эта часть** и какие у неё
|
||
собственные критерии приёмки. У операционных частей (`fix`, `chore`,
|
||
`research`) цели может не быть — тогда достаточно собственных критериев.
|
||
|
||
Не проходит хотя бы одно — **не дроби**. Ложная декомпозиция плодит файлы,
|
||
которые нельзя взять поодиночке, и переоценка потом склеивает их обратно.
|
||
|
||
## Где резать, если резать можно
|
||
|
||
Тест выше говорит, **допустим** ли разрез. Где его провести из нескольких
|
||
допустимых мест — отвечает шов.
|
||
|
||
**Шов — там, где падает метка ревью.** Раздел «Затрагивает» перечисляет
|
||
границы; если одна строка перечня поднимает метку выше остальных, эта часть и
|
||
режется отдельно. Пример: задача перекладывает несколько узлов разом и заодно
|
||
добавляет два поля в существующий ответ. Целиком это `large` — семь проходов по
|
||
всему диффу, включая два, что держат машину и идут цепочкой. Разрезанная по шву,
|
||
она даёт `large` на маленькой переложенной части и `medium` на остатке.
|
||
|
||
**Считай костяк, а не файлы.** У каждой задачи есть несокращаемые четыре прохода
|
||
(гейт, спеки, код, триаж), и они платятся за каждую. Разрез, после которого обе
|
||
половины остаются в одной метке, делает ревью **дороже**: тот же объём
|
||
проверяется тем же составом, но костяк оплачен дважды. Отсюда правило: **резать,
|
||
когда разрез снимает дорогой проход с большей части диффа**, и не резать, когда
|
||
он просто делает файлы мельче.
|
||
|
||
**Это планирование, а не предписание процесса.** Метка ревью выбирается по
|
||
факту изменения — тем, кто его видит, — и в тело задачи не пишется: строка
|
||
«делать с меткой medium» это ровно тот второй дом правила выбора, который
|
||
гигиена полей снимает. Шов пользуется меткой как **признаком**, что в задаче
|
||
две разнородные работы; решение о метке остаётся за конвейером.
|
||
|
||
**Цель наследуется.** Все части несут `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` после правок.
|
||
- Границы покрытия: какие постановки рассмотрены и какие сознательно отброшены —
|
||
чтобы штурм не пришлось повторять с нуля.
|