Files
dev-skills/av-dev/skills/task-track/references/split.md
T
av 3849f084be задачи: цель упразднена, у проекта появилась стадия
Тип goal и индекс ROADMAP.md убраны: цель — зонтик над параллельными
направлениями, а у проекта на одного человека список работ линеен. Роадмап
при этом наполовину дублировал беклог, а «что уже умеет» отвечают спеки и
git log индекса. Секция «Готово» удалена, а не перенесена.

Вместо цели — ось «стадия проекта»: build (беклог это план стройки, порядок
строк значит зависимость, секция одна) и support (очередь правок, порядок
значит важность, секции — полки домена). Стадия объявляется ключом
[tasks] stage, меняется командой stage, без неё check отказывает: порядок
строк нечем прочитать.

Ушли теги goal:/decomposed, поле «Секция», раздел «Завершение», флаги
--goal и edit --section. Версия раскладки 2 → 3, перевод проекта расписан
записью журнала.
2026-08-13 14:26:21 +03:00

9.7 KiB
Raw Blame History

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

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

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

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

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

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

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

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

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

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

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

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

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

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

части полностью замещают его → close <slug> --reason "разложена на a, b". REJECTED.md здесь — не «выкинули», а именно тот след, что переживает запись: через квартал вопрос «куда делась задача X» отвечается строкой со ссылками на наследников, а не археологией git.

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

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

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

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

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

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

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

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

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

Доклад

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