Files

T

добавлены плагины av-dev-tasks и av-dev-pipeline

Пара плагинов с намеренно проведённой границей: av-dev-tasks отвечает
за то, что делаем и в каком порядке, av-dev-pipeline — за то, как ведём
одну задачу. Зависимости между ними нет: управление задачами работает и
с ручным исполнением, пайплайн — на проекте с любым учётом задач.

- av-dev-tasks — преемник av-dev-backlog: цели вместо приоритетов,
  спринт под одну цель с заморозкой набора, различение вопроса и
  блокера, каденция «вопросы — разбор — переоценка — набор».
  Раскладка docs/tasks с items/, PLAN.md, BACKLOG.md, SPRINT.md,
  REJECTED.md; проверенное из av-dev-backlog перенесено, не переписано.
- av-dev-pipeline — вынос того, что лежало копиями в healthlog и
  jellybit (3628 строк) и уже разошлось: цикл SDD, конвейер ревью с
  обязательным триажем, прогон нескольких задач разом. Проектная
  специфика вынесена в файл-бриф, charter'ы несут метод.

Коммит фиксирует состояние на момент ревью: три прохода нашли
блокирующие дефекты (нет шага, заводящего бриф; git rebase на занятой
worktree ветке; sprint drop пишет наполовину) — они чинятся следующими
коммитами. Сохранено как база, от которой видно правки.

2026-08-03 11:01:29 +03:00

7.8 KiB

Raw Blame History

Ведение спринта

Спринт — набор задач под одну цель, замороженный до его конца. Здесь то, что происходит внутри спринта: как задача заканчивается, что считается сделанным, кто принимает и что идёт в доклад. Как спринт набирается — шаг 4 в cadence.md.

Наблюдаемые исходы задачи

Как они достигаются — дело пайплайна проекта. Сессия знает только исход и его след.

Сделана — по определению готовности ниже. close <slug> --implemented: файл и строка удаляются, следом остаётся коммит.
Вышла из спринта — sprint drop <slug> --reason …: возвращается в беклог с вопросом в файле и без живого незакоммиченного предложения — иначе при следующем взятии оно столкнётся с новым. Наработки, которые жалко терять, переезжают в тело задачи текстом.
Переросла в эпик — распознаётся до того, как под неё заведено предложение об изменении, иначе его придётся выбрасывать. Помечается [epic], выходит из набора, уходит на декомпозицию; спринт продолжается остальными, части в замороженный набор не добавляются.
Отменена решением по ходу — close <slug> --reason "<ссылка на решение>" прямо из спринта. Это редкий, но законный исход, и он называется в докладе.

Конец спринта — когда по каждой задаче набора наступил один из исходов. Не «все сделаны»: иначе одна застрявшая задача держит спринт бесконечно. Затем sprint close.

Провал спринта. Сработал блокер — спринт распускается (sprint close --dissolve --reason …), недоделанное возвращается в беклог, новый набор делается после ответа человека. Спринт не «ждёт»: ждать может человек, а замороженный набор, который нельзя двигать, только мешает.

Определение готовности

Задача засчитывается сделанной, когда верно всё:

Пайплайн задачи пройден до конца — со своим определением готовности, за которое отвечает проект: проверки, состав ревью, документация, коммит. Здесь оно не пересказывается и не подменяется — форма фиксирована, содержание даёт CLAUDE.md проекта. Пайплайна нет, задача сделана руками — условие читается как «проверки проекта зелёные и изменение влито».
Критерии приёмки проверены поимённо — каждый со своим оракулом, исход по каждому назван. Это единственное, что добавляет управление задачами: пайплайн отвечает «сделано по правилам», критерии — «сделано то, что заказывали».
Урожай заведён — вопросы и задачи, найденные по ходу, лежат в беклоге, а не в отчёте.

Кто и по чему принимает

Три условия, без которых пункт про критерии не исполняется никем:

Критерии переживают файл задачи. Файл удаляется при закрытии, поэтому критерии копируются туда, где их увидит приёмщик — в предложение об изменении, описание ветки, тело коммита. Куда именно, называет CLAUDE.md проекта. Иначе приёмка проверяет критерии из файла, которого больше нет.
Принимает не исполнитель. Отдельный контекст — сабагент или человек, — которому дают изменение, отчёт исполнителя и отчёты ревью. Тот же принцип декорреляции, на котором стоит любой конвейер проверки: занизивший и проверяющий не должны быть одним контекстом.
Расхождение — дефект критериев. Приёмщик правит критерии и возвращает задачу исполнителю в этом же спринте: ответ есть, остаток есть, по тесту про остаток это не выход из спринта.

Что врывается в замороженный набор

Только два класса — правило и его обоснование в SKILL.md. Здесь механика:

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

Доклад в конце спринта

Проверяемые якоря, а не пересказ:

Цель спринта и по каждой задаче набора: хеш коммита, дословный исход проверок проекта, исход по каждому критерию приёмки.
Какие развилки решались и чем обоснованы.
Урожай: сколько задач заведено, какие вопросы накопились, что вышло из спринта и почему, что было внеплановым.
Поимённая сверка урожая с отчётами ревью: каждая отложенная находка имеет либо слаг, либо строку «не заведена: причина». Нулевой урожай при непустом отчёте — сигнал, а не благополучие.
Созрела ли порция для сессии. Решение звать — человека, напоминание — обязанность агента: ⌈урожай / 8⌉ порций.
Границы покрытия сжатой строкой: что в этом спринте не проверялось вовсе.

7.8 KiB Raw Blame History