av-dev-pm расколот на av-dev-docs и av-dev-tasks

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

av-dev-docs: скиллы canon, docs, init; агенты doc-consistency, doc-code-drift,
doc-wording; скрипт docs.py. av-dev-tasks: скиллы tasks, session; агенты
task-form, task-wording; скрипт tasks.py.

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

То, что нужно обоим дословно, стало вторым общим домом. Словарь «Сопровождение и
эксплуатация» назван в трёх местах трёх плагинов — секция роадмапа, раздел
«Эксплуатация» в architecture.md, тема ревью operations — и ни один из трёх им не
владеет; он уехал в shared/operations.md, а canon.md и скилл задач везут копии.
Три перечня «чем держат проект» уже разъезжались на «метриках и логах» против
«мониторинга», так что ссылка тут не годится: плагин, поставленный в одиночку,
получил бы указатель в никуда. Тем же способом язык: у av-dev-tasks появилась
своя копия language.md.

Копий стало 18 при 8 домах.

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

Журналы (DECISIONS, TODO, HISTORY) намеренно не тронуты: они описывают состояние
на момент записи. По той же причине оставлена наблюдённая строка в комментарии
docs.py — она цитирует конфиг живого проекта, а не называет плагин.

Не входит в этот заход и названо отдельно: слияние canon и docs в один скилл,
разделение docs/.pm.json на два конфига и переезд openspec в пайплайн.

Гейт зелёный: копии, фронтматтеры, диаграммы, json. Оба скрипта прогнаны после
переезда — docs.py version и tasks.py check на фикстуре.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

av-dev-tasks/skills/session/references/cadence.md

@@ -0,0 +1,277 @@
+# Сессия: четыре шага
+
+Одна сессия между спринтами. Порядок шагов — **зависимость, а не список**:
+переоценивать задачи, не разобрав вопросы, значит переоценивать вслепую; набирать
+спринт, не переоценив, значит набирать из протухшего.
+
+Начинается сессия с `tasks.py check` (и `check --fix`, если дрейф накопился) —
+результат идёт строкой в доклад.
+
+## Шаг 1. Разбор вопросов
+
+`tasks.py list --questions` — всё, что накопилось. Вопрос это решение человека,
+и разбирается он **пачкой**, а не по одному, как только возник: по одному —
+это дёрганье, пачкой — это сессия.
+
+Порядок по каждому вопросу:
+
+1. **Проверь, не отвечен ли он уже** — решением, документом, соседним
+   изменением, самим ходом прошедшего спринта. Отвеченный вопрос не выносится
+   человеку: это самая частая находка и она не требует ничьего решения.
+2. **Сформулируй развилку** с вариантами и последствием каждого, рекомендация —
+   первым вариантом.
+3. **Вынеси пачкой** через `AskUserQuestion`, не больше трёх за раз.
+4. **Запиши ответ в тело задачи, опустоши раздел «Вопросы»**, сними тег
+   (`edit <slug> --rm-tag question`), **перепиши «зачем»**: «Решено:
+   …» на вопрос «почему это лежит в беклоге» уже не отвечает. Опустошение
+   раздела — не уборка, а условие взятия: правило и причина в скилле `tasks`,
+   [references/task-format.md](../../tasks/references/task-format.md).
+
+**Вопросы на задачах-кандидатах разбираются вне очереди порции** — здесь же, на
+этой сессии, даже если сама задача в порцию переоценки не попала. Иначе правило
+«задача с открытым вопросом в набор не берётся» создаёт стимул вопрос не
+записывать, лишь бы не вычеркнуть задачу из ближайшего спринта.
+
+## Шаг 2. Разбор прошедшего спринта — про процесс, а не про задачи
+
+Не «что мы сделали» (это доклад спринта, он уже был), а:
+
+- **что сломалось в процессе и почему не поймали** — промах, доехавший до конца;
+- **что оказалось дороже, чем выглядело при заведении** — не число, а сам факт и
+  причина: чего не было видно в постановке;
+- **какие правила не сработали или сработали не так** — в том числе правила
+  этого плагина.
+
+Замеров процесс не ведёт намеренно: оценки в очках и velocity не взяты
+(«[Почему не Scrum](../SKILL.md#почему-не-scrum)»), а спринт ограничен объёмом, а
+не временем — сравнивать «сколько заняло» не с чем. Разбор здесь качественный, и
+это не упущение.
+
+**Артефакт обязателен.** Вывод, оставшийся в контексте сессии, не существует:
+следующая сессия его не увидит. Дом у него один и известен из канона —
+**`docs/review.md`**: вывод про конвейер и про то, что перестали проверять, идёт
+в раздел настройки, вывод про воспроизведённый дефект — в журнал. Решение с
+долгим следом — в `docs/adr/`.
+
+Отдельным ритуалом ретроспектива не выделяется: процесс личный,
+синхронизировать некого.
+
+**Здесь же зовутся оба судьи документов** — на весь канон разом, а не на пачку,
+отобранную работой:
+
+- **`doc-consistency`** — согласованность документов между собой и с openspec:
+  факт в двух домах, прямое противоречие, поведение в `architecture.md` вместо
+  спек, ADR без парного статуса при замене, число без провенанса;
+- **`doc-code-drift`** — сверка с кодом по закрытому перечню фактов: имя основной
+  ветки, команды, пути, внешние зависимости поимённо, настройки с числовым
+  значением, единые точки проекта, capability.
+
+Раз в спринт, а не чаще. Дорог из них по-настоящему первый — `doc-consistency`
+на `opus`: он сличает утверждения двух документов, и это суждение. Второй с
+недавних пор на `sonnet` — у него закрытый перечень фактов и команда на каждый, —
+но он читает репозиторий целиком, и дешёвым от смены модели не стал. Но и не
+реже — **спринт это ровно то, что двигает код и документы**:
+переименованная цель сборки, ушедшая зависимость, второй способ делать то, что
+обзор объявил единственным; факт, дописанный в `architecture.md`, уже живущий в
+`CLAUDE.md`. Протухшее и раздвоившееся неотличимо от свежего, и по нему принимают
+решения, пока кто-нибудь не наткнётся.
+
+**Пачка — весь канон, и это не расточительство, а охват.** Когда пачку отбирала
+работа, без присмотра оставалось ровно то, чего работа не касалась: правка,
+отменившая решение, живёт в одном документе, а парный статус нужен в другом.
+Канон мал, раз в спринт он читается целиком.
+
+Находки обоих — обычный материал переоценки: строка на замену идёт в документ
+сразу, работа больше чем на абзац становится задачей типа `chore`. **Позвал —
+скажи в докладе, кого именно позвал, и приложи границы покрытия**; не позвал —
+скажи и это, иначе доклад читается как «сверено».
+
+## Шаг 3. Переоценка задач
+
+Цель — выкинуть то, что перестало быть задачей, и вернуть остальному честное
+состояние. Не «пересмотреть всё», а «пересмотреть порцию до конца».
+
+### Порция и правило остановки
+
+Тридцать задач за один заход — это усталость и штамповка: последние десять
+получат «оставить» не потому, что живы, а потому, что сессия затянулась.
+
+- **5–8 задач за порцию.** Размер обоснован усталостью, а не пропускной
+  способностью, и менять его не надо — **надо брать несколько порций за
+  сессию**.
+- **Сколько порций:** не меньше `⌈урожай прошедшего спринта / 8⌉`. Урожай — это
+  задачи, заведённые за спринт; при урожае в 15 это две-три порции.
+- **Отбор порций по порядку:**
+  1. **урожай спринта** — `list --tag sprint:<слаг>`: свежезаведённое ещё не
+     проходило ни одной проверки на нужность. Тег на задачах проставлен
+     автоматически при заведении — руками не метят и не вспоминают. **Слаг
+     берётся из отчёта `sprint close`, а не из `SPRINT.md`:** сессия идёт после
+     закрытия, а закрытие этот файл очищает;
+  2. дальше **по залежалости** — `list --stale`;
+  3. по потребности — одна секция целиком, один тег (партия ревью), одна цель
+     (`--goal`), список от пользователя.
+- **Останавливайся на границе порции**, даже если «ещё чуть-чуть осталось».
+  Между порциями — промежуточный доклад.
+
+### Что делать с каждой задачей
+
+Сперва то, что не требует ничьего решения:
+
+1. **Проверь, не сделано ли уже.** Задача, реализованная попутно в соседнем
+   изменении, — самая частая находка. Смотри код, документацию, историю коммитов
+   по ключевым словам. Удаление «как реализованной» деструктивно и без следа
+   (в `REJECTED.md` реализованные не пишутся), поэтому порог улики жёсткий:
+   `close <slug> --implemented` только имея **конкретный коммит или строку
+   документа**, закрывающие задачу, и ссылка идёт в доклад. Есть лишь косвенные
+   признаки — не удаляй сам, вынеси в пачку вопросов. Сделана частично → задача
+   сжимается до остатка: тело правишь редактором, заголовок и «зачем» — через
+   `edit`.
+2. **Проверь, не отменена ли решением.** Документ, ADR или архивное изменение
+   мог закрыть вопрос иначе — тогда `close <slug> --reason "<ссылка на
+   решение>"`. Задача закрывается не только коммитом.
+3. **Проверь пересечения.** Две задачи об одном — содержимое в одну, вторую
+   `close <slug> --reason "слита с <другой-слаг>"`. Смотри **шире порции**:
+   интейк дедуплицирует новое против существующего, но никогда не
+   пересматривает уже лежащее, и две задачи с одной причиной могут лежать рядом
+   месяцами.
+4. **Пере-кластеризуй по общей причине.** Несколько задач, оказавшихся симптомами
+   одного дефекта, сливаются в одну — это находка, которую интейк дать не мог.
+5. **Гигиена полей** — протухшее «зачем», вопрос в прозе, снятый ответ, свойство
+   репозитория в рамках, предписание процесса в теле, тип, разошедшийся с
+   задачей, границы вместо реализации в разделе «Затрагивает». Список и правила —
+   в скилле `tasks`. **Переоценка — то самое место, где беклог добирает тип и
+   разделы его схемы:** требовать их на входе значило бы выгонять в заметки то,
+   что должно лежать задачей, а к взятию в спринт они уже обязательны. Блок
+   здоровья `check` печатает, сколько записей готово к взятию, — по этому числу
+   и видно, добрала переоценка или нет.
+
+Затем — то, что решает пользователь:
+
+6. **Жива ли она вообще.** Контекст мог измениться: ушла зависимость, отпал
+   сценарий, обошли иначе. Здесь и звучит вопрос, выкидывать ли.
+7. **Та ли цель — и нужна ли она вообще.** Приоритетов нет, и «повысить» нечего
+   — вместо повышения задача **меняет цель** (`edit <slug> --goal <другой>`) или
+   входит в ближайший набор. `feature`, которой не находится цель, — кандидат
+   на выход: новая возможность вне цели это возможность, которой никто не
+   заказывал. Операционной задаче (`fix`, `chore`, `research`) цель не нужна, и
+   выдумывать её здесь не надо.
+
+   **Отменяется и сама цель** — когда замысел оказался неверен, а не когда
+   задача выбрала не ту. Тогда порция расширяется до всех задач этой цели: каждую
+   либо закрыть своей причиной, либо перевесить на другую цель, и только потом
+   закрыть цель. Порядок и почему он такой —
+   [task-goal.md](../../tasks/references/task-goal.md#отменённая-цель--сперва-задачи-потом-цель).
+   Здесь этому и место: отмена цели это разбор её задач, а разбор задач — этот
+   шаг.
+8. **Задача ли это по-прежнему.** Не проходит тест «готова к взятию» → `edit
+   <slug> --type research` и опустошённый раздел «Вопрос», то есть сырьё; дальше
+   штурм. Разрослась → это несколько задач под той же целью, дальше
+   декомпозиция.
+9. **Переоценка по пройденному.** Прошедший спринт показывает, чего на самом
+   деле стоит такая работа. Это меняет цену **других** задач, и именно здесь
+   применяется: задача, оказавшаяся заметно дороже, чем думалось, при прежней
+   пользе — кандидат на выход. Судит человек по тому, что помнит о прошедшем
+   спринте; замеров процесс не ведёт и оценок не хранит.
+
+### Храповик на залежавшихся
+
+Сильно залежавшаяся задача — сигнал сама по себе: её либо ни разу не собирались
+делать, либо нечем взять. Измеряй наблюдаемым — датой последней правки из git
+(`list --stale` ставит такие первыми); счётчик «сколько сессий пережила» нигде
+не хранится.
+
+Задача из верхних строк `--stale`, которую и этот заход оставляет без изменений,
+**либо двигается (меняет цель, идёт в набор, уходит с причиной), либо остаётся с
+явно записанной причиной**, почему её держим (`move <slug> --section <та же>
+--reason …`). Молчаливое «оставить как есть» на давно неподвижной задаче — это
+решение не принимать решение; запись причины превращает его в осознанное и не
+даёт тому же вопросу всплыть на следующей сессии.
+
+### Интерактив
+
+- Вопросы — через `AskUserQuestion`, **не больше трёх за раз**. Порция в 5–8
+  задач обычно даёт больше трёх суждений — тогда веди несколько итераций по ≤3,
+  а не по одному на задачу и не одним перегруженным запросом.
+- К каждому варианту — **предварительное суждение, рекомендация первым
+  вариантом**: «предлагаю выкинуть, потому что …». Пользователю дешевле
+  возразить, чем судить с нуля.
+- Всё, что решается фактом (сделано / отменено / дублируется), решай сам и
+  показывай списком в докладе, а не выноси в вопросы.
+
+Пример одной итерации — три залежавшихся задачи, механику по ним уже разобрали:
+
+> **Переоценка: 3 залежавшихся (порция по `--stale`)**
+>
+> 1. `versii-kachestvo-repaki` — версии и качество одного тайтла
+>    - Выкинуть *(рекомендую)* — помечена «не боль», за полгода ни разу не возникла
+>    - Оставить под целью `nadyozhnost-razdach`
+>    - Перевести под цель `kachestvo-mediateki` — там она первая в очереди
+> 2. `backup-sqlite` — бэкап базы
+>    - Оставить под текущей целью *(рекомендую)* — не сработала, но риск реальный
+>    - Взять в ближайший набор — без бэкапа ретеншн опасен
+>    - Выкинуть
+> 3. `guessit-sputnik` — вынести распознавание в сервис-спутник
+>    - Понизить до сырья (`--type research`) *(рекомендую)* — не проходит тест «готова к взятию»
+>    - Оставить задачей
+
+Каждый вариант несёт причину — ту самую, что уедет в `--reason`. Ответы применяй
+сразу и, если в порции осталось ещё, следующей итерацией показывай следующие ≤3.
+
+## Шаг 4. Выбор цели и набор спринта
+
+1. **Покажи состояние проекта**: секцию `Готово` (что приложение уже умеет —
+   это половина ответа на «где мы»), затем `Запланировано` с обоснованием
+   очереди, `Направления`, и
+   по каждой цели-кандидату — сколько под ней задач без открытых вопросов
+   (`list --goal <слаг>`). Цель без готовых задач набором не станет: её сперва
+   надо декомпозировать.
+2. **Цель называет человек** — либо называет, что цели не будет. Это
+   продуктовое решение, а не механика: агент предлагает и объясняет, но не
+   выбирает. **Оба ответа законны**, и «без цели» — такой же ответ, как слаг:
+   спринт бывает под багфикс, под техдолг, под здоровье проекта. Спрашивается он
+   так же, как цель, и в отдельный вопрос не выносится: это один и тот же вопрос
+   «подо что набираем».
+3. **Набор собирает агент** — `sprint start --goal <слаг>` (или `sprint start
+   --no-goal`), затем `sprint take …`. Скрипт не даст взять цель, задачу с чужой
+   целью, с открытым вопросом, без типа и **без разделов, которых требует её
+   тип** (у `fix` это в том числе `Воспроизведение`, у `research` — `Вопрос` и
+   `Куда ляжет ответ`, и сырьё поэтому не берётся вовсе). Задача без цели (`fix`,
+   `chore`, `research`) берётся свободно — операционная работа входит в набор
+   помимо его цели. **В спринте без цели чужой цели нет вовсе**: сверять не с
+   чем, берётся что угодно готовое, и единственной защитой остаётся показ набора
+   человеку.
+4. **Набор показывается человеку до старта работ.** Показ — это и есть момент
+   заморозки: после него набор не двигается. **В показе называется состав по
+   типам** — три `fix` и ни одной `feature` под целью развития это разговор про
+   цель, а не про набор, и увидеть его надо до заморозки, а не в докладе по
+   итогам. **У набора без цели показ — единственная проверка состава**: скрипту
+   там отказывать не по чему, и «что угодно готовое» превращается в осмысленный
+   набор только глазами человека.
+
+   Здесь же последний дешёвый момент заметить **разнородную задачу**: раздел
+   «Затрагивает» показывает границы до того, как заведено предложение об
+   изменении. Строка, которая одна тянет задачу на метку выше остального
+   перечня, — кандидат на разрез (шов — в `tasks`, `references/split.md`).
+   Замеченная здесь, она стоит одного `edit`; замеченная на ревью — выброшенного
+   предложения.
+5. Задача, которой для взятия не хватает только разделов её типа, дописывается
+   здесь же — критерии с оракулами, перечень границ, шаги воспроизведения. Но
+   если для этого нужен ответ человека, это вопрос, и задача в набор не идёт.
+
+**Размер — ориентир, а не закон:** 5–8 задач. Можно взять больше, можно меньше —
+набор под цель важнее круглого числа; одна крупная задача спринтом тоже бывает.
+
+## Доклад сессии
+
+- Что просмотрено: N из M, сколько порций, по какому признаку отобраны.
+- Вопросы: разобрано N, из них отвечено без человека N, снято тегов N.
+- Разбор процесса: что записано и куда.
+- Сверка документов с кодом: звался ли `doc-code-drift`, что проверено из
+  названного, что разошлось.
+- Изменения списком: удалено как реализованное (со ссылками), ушло без
+  реализации (с причинами), понижено до сырья, слито, сменило тип или цель.
+- Новый спринт: цель — **или строка «без цели» с объяснением, почему** (багфикс,
+  техдолг, здоровье), — набор со слагами, дата, состав по типам.
+- **Границы покрытия**: сколько задач не трогали и какие именно секции, теги или
+  цели остались — иначе доклад читается как «беклог разобран».
+- `tasks.py check` после правок — результат строкой.

av-dev-tasks/skills/session/references/sprint.md

@@ -0,0 +1,199 @@
+# Ведение спринта
+
+Спринт — набор задач, замороженный до его конца: под одну цель или **без цели**
+(багфикс, техдолг, здоровье — это законно, `sprint start --no-goal`). Здесь то,
+что происходит **внутри** спринта: как задача заканчивается, что считается сделанным,
+кто принимает и что идёт в доклад. Как спринт набирается — шаг 4 в
+[cadence.md](cadence.md).
+
+## Наблюдаемые исходы задачи
+
+Как они достигаются — дело пайплайна проекта. Сессия знает только исход и его
+след.
+
+- **Сделана** — по определению готовности ниже. `close <slug> --implemented`:
+  файл и строка удаляются, следом остаётся коммит. **Закрывает агент-оркестратор
+  последним шагом пайплайна, после коммита; приёмка человеком идёт позже и
+  отменяется `reopen`** — см. «Кто и когда закрывает».
+- **Вышла из спринта** — `sprint drop <slug> --reason …`: возвращается в беклог
+  с вопросом в файле и **без живого незакоммиченного предложения** — иначе при
+  следующем взятии оно столкнётся с новым. Наработки, которые жалко терять,
+  переезжают в тело задачи текстом.
+- **Оказалась крупнее задачи** — распознаётся **до того, как под неё заведено
+  предложение об изменении**, иначе его придётся выбрасывать. Выходит из набора,
+  уходит на декомпозицию; спринт продолжается остальными, части заводятся под той
+  же целью (у спринта без цели — без неё) и в замороженный набор не добавляются.
+- **Отменена решением по ходу** — `close <slug> --reason "<ссылка на решение>"`
+  прямо из спринта. Это редкий, но законный исход, и он называется в докладе.
+
+**Конец спринта** — когда по каждой задаче набора наступил один из исходов. Не
+«все сделаны»: иначе одна застрявшая задача держит спринт бесконечно. Затем
+`sprint close`.
+
+```mermaid
+flowchart TD
+    take["sprint take — задача в наборе"]
+    done["сделана<br/>close --implemented"]
+    out["вышла<br/>sprint drop --reason"]
+    epic["крупнее задачи<br/>распознаётся до заведения change"]
+    cancel["отменена решением по ходу<br/>close --reason"]
+    all{"по каждой задаче набора<br/>наступил исход?"}
+    harvest["урожай заводится интейком tasks"]
+    close["sprint close"]
+    dissolve["sprint close --dissolve --reason<br/>недоделанное — в беклог"]
+
+    take --> done
+    take --> out
+    take --> epic
+    take --> cancel
+    done --> all
+    out --> all
+    epic --> all
+    cancel --> all
+    all -->|да| harvest
+    harvest -->|"тег sprint: ставится, пока SPRINT.md не очищен"| close
+    take -->|"продолжать нечем ни одной задачей — блокер"| dissolve
+    done -->|"приёмка не сошлась: reopen --reason"| take
+```
+
+Два ребра на схеме — те, где порядок обязателен и нарушается молча: **урожай до
+`sprint close`** (после команды автотег уже не поставится) и **блокер в обход
+исходов** (спринт распускается, а не ждёт).
+
+Схема — **сводка**: определение готовности и правила приёмки ниже, и при
+расхождении прав текст.
+
+**Урожай заводится при закрытии спринта, а не при закрытии задачи.** Это
+обязанность закрывающего: пройти по спискам находок от исполнителей и завести
+недостающее интейком скилла `tasks` — с дедупликацией и картой человеку. Заводимое
+метится тегом спринта само (`sprint:<слаг>`), поэтому первая порция следующей
+сессии поднимается одной командой `list --tag sprint:<слаг>`. Спринт, закрытый
+без этого шага, оставляет находки жить в отчётах — то есть нигде.
+
+**Порядок здесь обязателен: урожай заводится ДО команды `sprint close`.**
+Автотег ставится по слагу из `SPRINT.md`, а `sprint close` этот файл очищает;
+заведённое после команды остаётся без тега и в первую порцию следующей сессии
+не попадёт — молча, потому что пустой `list --tag` выглядит как «урожая не
+было». Если так уже вышло, тег ставится руками: `add … --tag sprint:<слаг>`,
+слаг берётся из отчёта `sprint close`.
+
+**Провал спринта.** Сработал блокер — спринт распускается (`sprint close
+--dissolve --reason …`), недоделанное возвращается в беклог, новый набор
+делается после ответа человека. Спринт не «ждёт»: ждать может человек, а
+замороженный набор, который нельзя двигать, только мешает.
+
+**Протухший набор — второй законный повод роспуска.** Работа стояла, и человек
+вернулся к спринту, состав которого уже не держит в голове. Тем же роспуском:
+`sprint close --dissolve --reason "работа стояла с <когда>"`, недоделанное в
+беклог, новый набор — после переоценки, а не поверх старого.
+
+Порога в неделях нет и не будет: счётчик простоя пришлось бы вести руками, а
+решает всё равно человек. Признак — не срок, а **что набор перестал быть твоим**:
+взялся перечитывать, зачем эти задачи вместе, — он протух. Заморозка тут не
+мешает, она запрещает *двигать* набор, а не распустить его целиком.
+
+## Определение готовности
+
+Задача засчитывается сделанной, когда верно **всё**:
+
+1. **Пайплайн задачи пройден до конца** — со своим определением готовности, за
+   которое отвечает проект: проверки, состав ревью, документация, коммит. Здесь
+   оно не пересказывается и не подменяется — **форма фиксирована, содержание
+   даёт `CLAUDE.md` проекта**. Пайплайна нет, задача сделана руками — условие
+   читается как «проверки проекта зелёные и изменение влито».
+2. **Критерии приёмки проверены поимённо** — каждый со своим оракулом, исход по
+   каждому назван. Это единственное, что добавляет управление задачами: пайплайн
+   отвечает «сделано по правилам», критерии — «сделано то, что заказывали».
+3. **Находки по ходу отданы списком** — исполнитель обязан их **назвать**
+   (каждую, с пометкой «заведена / не заведена: причина»), но **не обязан
+   заводить**: заведение интерактивно — оно требует дедупликации против беклога
+   и кладбища, а ещё решений человека. Обязанность **завести урожай** — на
+   закрытии спринта, ниже. Иначе автономный исполнитель оказался бы разом и
+   обязан завести задачи, и не вправе сделать это в одиночку.
+
+### Кто и когда закрывает
+
+**Задачу закрывает агент-оркестратор — тот же, кто её и сделал**, последним шагом
+пайплайна, после коммита. Порядок:
+
+1. пайплайн доводит задачу до коммита;
+2. **после коммита** зовёт `Skill av-dev-tasks:tasks` и закрывает задачу
+   (`close <slug> --implemented`); строка уходит из `SPRINT.md`;
+3. **докладывает исход и по каждому критерию — оракул и наблюдаемый исход.**
+   Это доклад приёмщику, а не отметка «принято».
+
+**Приёмщик и исполнитель здесь совпадают, и это принято сознательно** — цена
+названа в `SKILL.md`, раздел «Стимулы». Поэтому закрытие **не окончательно**, а
+доклад по критериям — не формальность: он единственное, по чему приёмка вообще
+возможна.
+
+**Порядок «коммит, потом закрытие» обязателен.** Закрытие удаляет файл задачи;
+упавший коммит после закрытия оставил бы задачу закрытой без единого следа
+работы.
+
+**Само закрытие тоже коммитится, отдельным коммитом.** Удаление файла задачи и
+правка индекса — правки в рабочем дереве; пока они не в истории, `SPRINT.md`
+ничего не показывает, а `reopen` восстанавливает текст из `HEAD` в узком окне:
+его закроет первый посторонний коммит. Сообщение про учёт, а не про
+работу: `закрыта задача <slug>`.
+
+**Дорога назад существует и обязана быть названа.** Человек на сессии сверил
+критерии, и приёмка не сошлась — `tasks.py reopen <slug> --reason "приёмка не
+сошлась: …"`:
+файл восстанавливается из истории git, строка возвращается в набор идущего
+спринта (или в беклог, если спринта нет), строка кладбища снимается. Тело
+восстанавливается **на момент удаления** — всё, что было дописано позже, живёт
+только в коммите задачи, и это называется в докладе.
+
+### Кто и по чему принимает
+
+Три условия, без которых пункт про критерии не исполняется никем:
+
+1. **Критерии переживают файл задачи.** Файл удаляется при закрытии, поэтому
+   критерии копируются туда, где их увидит приёмщик. Куда именно — **отвечает
+   пайплайн проекта, а не слот в `CLAUDE.md`**: он переносит их в `tasks.md`
+   изменения, когда заводит change. Проект без пайплайна называет своё место
+   сам.
+2. **Принимает человек на сессии, а не отдельный агент.** Исполнитель и приёмщик
+   в момент закрытия **не разведены** (решение о снятии и его
+   цена — в `SKILL.md`, «Стимулы»). Опоры остались три: **сохранённый независимый
+   отчёт ревью** (при конвейере `av-dev-pipeline` — отчёт триажа в
+   `openspec/changes/archive/<id>/review/`, до архивации — `changes/<id>/review/`),
+   `SPRINT.md` под git и `reopen`. Переоценка на сессии и есть момент, когда
+   критерии видит не исполнитель. **Конвейера ревью в проекте нет — первой опоры
+   нет тоже**, и это называется строкой доклада, а не обходится молча
+   (`SKILL.md`, «Стимулы»).
+3. **Расхождение — дефект критериев.** Приёмщик правит критерии и возвращает
+   задачу исполнителю **в этом же спринте**: ответ есть, остаток есть, по тесту
+   про остаток это не выход из спринта.
+
+## Что врывается в замороженный набор
+
+Только два класса — правило и его обоснование в SKILL.md. Здесь механика:
+
+- вторжение **не добавляет** задачу в набор: `SPRINT.md` остаётся тем набором,
+  который заморозили и показали. Внеплановая работа делается и называется в
+  докладе отдельной строкой «внеплановое: что и почему»;
+- если внеплановое требует больше пары часов, честнее распустить спринт, чем
+  делать вид, что набор соблюдается;
+- всё остальное падает в беклог через обычный интейк и ждёт сессии.
+
+## Доклад в конце спринта
+
+Проверяемые якоря, а не пересказ:
+
+- **Цель спринта** — или строка «спринт без цели» с тем, чем он был (багфикс,
+  техдолг, здоровье): у бесцельного набора это единственное место, где состав
+  вообще объясняется. И по каждой задаче набора: **хеш коммита**, дословный
+  исход проверок проекта, **исход по каждому критерию приёмки**.
+- **Какие развилки решались** и чем обоснованы.
+- **Урожай:** сколько задач заведено, какие вопросы накопились, что вышло из
+  спринта и почему, что было внеплановым.
+- **Поимённая сверка урожая** с независимыми отчётами ревью: каждая отложенная
+  находка имеет либо слаг, либо строку «не заведена: причина». Нулевой урожай при
+  непустом отчёте — сигнал, а не благополучие. **Отчётов нет** (проект без
+  конвейера ревью) — сверять не с чем, и строка доклада говорит именно это, а не
+  «сверено».
+- **Созрела ли порция для сессии.** Решение звать — человека, напоминание —
+  обязанность агента: `⌈урожай / 8⌉` порций.
+- **Границы покрытия** сжатой строкой: что в этом спринте не проверялось вовсе.