ревизия покрытия av-dev-pm: три решения из шести оказались «убрать»

Сабагент в роли продакт-менеджера оценил покрытие жизненного цикла личного
проекта скиллами и агентами av-dev-pm. Скоуп сужен по ходу разбора: деплой и
разбор инцидентов делаются вручную, скиллов под них не заводим — три находки
из восьми сняты этим сразу.

Шаг 2 сессии требовал чисел, которых процесс отказался собирать решением.
cadence.md делал обязанностью пересмотр «ориентира по размеру спринта, прироста
беклога на закрытую задачу, времени на задачу» и «сколько заняли задачи против
ожидания». Данных нет: у записи нет дат заведения, взятия и закрытия, close
удаляет файл, sprint close очищает SPRINT.md. Хуже, «против ожидания» и «время
на задачу» требуют оценки и тайм-бокса, а session/SKILL.md в «Почему не Scrum»
их прямо не берёт — пункт противоречил решению через файл от себя. Числа не
пересматривались ни разу, поэтому выкинуты, а не подперты учётом дат. Осталось
качественное; рядом записано, что замеров нет намеренно, иначе следующий
читатель заведёт их обратно как недостающие. Шаг 3 пункт 9 переименован из
«переоценки по измеренному» в «по пройденному».

doc-consistency переехал с каждого синка на сессию, к doc-code-drift. Агент на
opus звался шагом 9 пайплайна, то есть 5-8 opus-проходов за спринт по документам,
меняющимся на несколько абзацев. Довод сильнее денег: расхождение между двумя
документами по определению требует двух, а на большинстве задач синк правит
один. И пачка, отбираемая работой, не видит того, чего работа не касалась, —
а расхождение живёт ровно там. Это снимает открытый вопрос REMAINING про охват
парного статуса ADR. Цена — потеря привязки находки к задаче, принято сознательно.

Отмена цели получила порядок, но не флаг. close запрещал закрыть цель с живыми
задачами и не говорил, что с ними делать. Теперь: сперва задачи поштучно
(close --reason своей причиной либо edit --goal на другую), потом цель в
REJECTED.md, а не в Готово. Флаг --cascade отвергнут: поштучный разбор — не
церемония, а единственный момент, когда видно, что переживёт цель. Место
процедуры — переоценка на сессии, отмена цели и есть разбор её задач.

У брошенного спринта появился второй законный исход. --dissolve везде был
привязан к блокеру, и вернувшийся к месячному набору не имел законного хода:
двигать нельзя, распускать не по чему. Теперь роспуск объясняется блокером или
тем, что набор протух. Порога в неделях нет — тот же класс, что выкинутые
числа: счётчик простоя пришлось бы вести руками. Признак не срок, а что набор
перестал быть твоим. Плюс точка входа «вернулся, а спринт открыт» и триггер в
description скилла.

Журнал канона прогоняется как есть, схлопывать 3 и 4 не стали. Взамен появилась
проверка исхода: шагом 6 adopt и шагом 6 upgrade зовутся оба судьи документов.
Это ответ на открытый вопрос «как проверять, что канон не разошёлся с проектами
после upgrade»: check сверяет число в .pm.json с версией скрипта и про существо
записи не знает ничего, а записи применяются руками.

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

Тема 31 в DECISIONS.md, следствия 117-123.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
av
2026-08-05 14:02:04 +03:00
co-authored by Claude Opus 5
parent c3e0a6d01f
commit 2d39a77444
13 changed files with 319 additions and 65 deletions
+26 -4
View File
@@ -1,6 +1,6 @@
---
name: session
description: "Ритуал между спринтами и ведение самого спринта: разбор накопившихся вопросов, разбор прошедшего спринта про процесс, переоценка задач порциями, выбор цели и набор нового спринта с заморозкой. Плюс правила по ходу спринта — что врывается в замороженный набор, чем вопрос отличается от блокера, когда задача выходит из спринта, что считается сделанным и что идёт в доклад. Использовать, когда просят закрыть или начать спринт, собрать набор, разобрать вопросы, провести груминг/переоценку/ретроспективу, решить «что делать дальше» или доложить итоги. Формат и содержимое задач — скилл tasks."
description: "Ритуал между спринтами и ведение самого спринта: разбор накопившихся вопросов, разбор прошедшего спринта про процесс, переоценка задач порциями, выбор цели и набор нового спринта с заморозкой. Плюс правила по ходу спринта — что врывается в замороженный набор, чем вопрос отличается от блокера, когда задача выходит из спринта, что считается сделанным и что идёт в доклад. Использовать, когда просят закрыть или начать спринт, собрать набор, разобрать вопросы, провести груминг/переоценку/ретроспективу, решить «что делать дальше» или доложить итоги, а также когда вернулись к проекту после перерыва и надо понять, где остановились. Формат и содержимое задач — скилл tasks."
---
# Сессия между спринтами
@@ -38,7 +38,9 @@ description: "Ритуал между спринтами и ведение са
## Единицы
- **Цель** — то, ради чего набирается спринт. Файл типа `goal` (🎯),
перечисленный в `ROADMAP.md`. Цель постоянна: живёт, пока живёт направление.
перечисленный в `ROADMAP.md`. Цель постоянна: живёт, пока живёт направление, —
и уходит вместе с ним, если замысел оказался неверен (порядок отмены — в
[tasks](../tasks/references/task-goal.md#отменённая-цель--сперва-задачи-потом-цель)).
- **Задача** — то, что мерджится целиком и даёт видимую пользу.
- **Вопрос** — решение человека. Не останавливает начатую работу, но **блокирует
взятие** задачи в спринт. Живёт внутри файла задачи разделом «Вопросы» и тегом
@@ -116,8 +118,9 @@ description: "Ритуал между спринтами и ведение са
Это зависимость, а не список.
1. **Разбор вопросов.**
2. **Разбор прошедшего спринта — про процесс, а не про задачи.** Здесь же
сверка документов канона с кодом — агент `doc-code-drift`, раз в спринт.
2. **Разбор прошедшего спринта — про процесс, а не про задачи.** Здесь же оба
судьи документов канона на весь канон разом, раз в спринт: `doc-consistency`
(документы между собой) и `doc-code-drift` (документы против кода).
3. **Переоценка задач** порциями.
4. **Выбор цели и набор спринта.** Цель называет человек, набор собирает агент и
показывает **до старта работ**.
@@ -144,6 +147,25 @@ flowchart TD
Схема — **сводка**: процедура каждого шага в
[references/cadence.md](references/cadence.md), и при расхождении прав текст.
## Вернулся, а спринт открыт
Сессия — ритуал **между** спринтами, и шаг 1 предполагает только что закрытый.
Вход после перерыва другой, и начинается он не с шага, а с вопроса, свой ли ещё
набор:
1. `tasks.py check` — блок здоровья скажет состояние спринта, число готовых к
взятию и залежавшихся; при расхождении раскладки `--fix`.
2. Прочитать `SPRINT.md`: цель, состав, дата начала.
3. **Развилка, и решает её человек.** Набор всё ещё твой — продолжай спринт, ни
сессии, ни переоценки не нужно, они между спринтами. Перечитываешь, зачем эти
задачи собраны вместе, — набор протух: `sprint close --dissolve --reason …`,
недоделанное возвращается в беклог, дальше обычная сессия с шага 1.
Порога в неделях нет намеренно — почему, в
[references/sprint.md](references/sprint.md), «Протухший набор».
Середины у развилки тоже нет: «доделаю пару штук и решу» — это работа по набору,
которого ты уже не понимаешь.
Процедура каждого шага, размер и отбор порции, храповик на залежавшихся, формат
интерактива и доклад — [references/cadence.md](references/cadence.md).