Files
dev-skills/av-dev-pm/skills/tasks/references/split.md
T
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>
2026-08-07 10:57:15 +03:00

9.9 KiB
Raw Blame History

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

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

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

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

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