добавлены плагины 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 пишет наполовину) — они чинятся следующими
коммитами. Сохранено как база, от которой видно правки.

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

@@ -0,0 +1,195 @@
+# Сессия: четыре шага
+
+Одна сессия между спринтами. Порядок шагов — **зависимость, а не список**:
+переоценивать задачи, не разобрав вопросы, значит переоценивать вслепую; набирать
+спринт, не переоценив, значит набирать из протухшего.
+
+Начинается сессия с `tasks.py check` (и `check --fix`, если дрейф накопился) —
+результат идёт строкой в доклад.
+
+## Шаг 1. Разбор вопросов
+
+`tasks.py list --questions` — всё, что накопилось. Вопрос это решение человека,
+и разбирается он **пачкой**, а не по одному в момент возникновения: по одному —
+это дёрганье, пачкой — это сессия.
+
+Порядок по каждому вопросу:
+
+1. **Проверь, не отвечен ли он уже** — решением, документом, соседним
+   изменением, самим ходом прошедшего спринта. Отвеченный вопрос не выносится
+   человеку: это самая частая находка и она не требует ничьего решения.
+2. **Сформулируй развилку** с вариантами и последствием каждого, рекомендация —
+   первым вариантом.
+3. **Вынеси пачкой** через `AskUserQuestion`, не больше трёх за раз.
+4. **Ответ записывается в тело задачи**, тег снимается `edit <slug> --rm-tag
+   question`, **хук переписывается**: «Решено: …» на вопрос «почему это лежит в
+   беклоге» уже не отвечает.
+
+**Вопросы на задачах-кандидатах разбираются вне очереди порции** — здесь же, на
+этой сессии, даже если сама задача в порцию переоценки не попала. Иначе правило
+«задача с открытым вопросом в набор не берётся» создаёт стимул вопрос не
+записывать, лишь бы не вычеркнуть задачу из ближайшего спринта.
+
+## Шаг 2. Разбор прошедшего спринта — про процесс, а не про задачи
+
+Не «что мы сделали» (это доклад спринта, он уже был), а:
+
+- **что сломалось в процессе и почему не поймали** — промах, доехавший до конца;
+- **сколько на самом деле заняли задачи** против ожидания;
+- **какие правила не сработали или сработали не так** — в том числе правила
+  этого плагина;
+- **какие числа пора пересмотреть** — ориентир по размеру спринта, прирост
+  беклога на одну закрытую задачу, время на задачу. Эта обязанность иначе висит
+  ничья: числа, помеченные как «первый замер», не пересматриваются никогда, если
+  их не пересматривает конкретный шаг.
+
+**Артефакт обязателен.** Вывод, оставшийся в контексте сессии, не существует:
+следующая сессия его не увидит. Куда он пишется — журнал промахов, ADR, раздел
+документации — называет `CLAUDE.md` проекта; нет такого места, значит первый
+разбор его и заводит.
+
+Отдельным ритуалом ретроспектива не выделяется: процесс личный,
+синхронизировать некого.
+
+## Шаг 3. Переоценка задач
+
+Цель — выкинуть то, что перестало быть задачей, и вернуть остальному честное
+состояние. Не «пересмотреть всё», а «пересмотреть порцию до конца».
+
+### Порция и правило остановки
+
+Тридцать задач за один заход — это усталость и штамповка: последние десять
+получат «оставить» не потому, что живы, а потому, что сессия затянулась.
+
+- **5–8 задач за порцию.** Размер обоснован усталостью, а не пропускной
+  способностью, и менять его не надо — **надо брать несколько порций за
+  сессию**.
+- **Сколько порций:** не меньше `⌈урожай прошедшего спринта / 8⌉`. Урожай — это
+  задачи, заведённые за спринт; при урожае в 15 это две-три порции.
+- **Отбор порций по порядку:**
+  1. **урожай спринта** — `list --tag sprint:<слаг>`: свежезаведённое ещё не
+     проходило ни одной проверки на нужность;
+  2. дальше **по залежалости** — `list --stale`;
+  3. по потребности — одна секция целиком, один тег (партия ревью), одна цель
+     (`--goal`), список от пользователя.
+- **Останавливайся на границе порции**, даже если «ещё чуть-чуть осталось».
+  Между порциями — промежуточный доклад.
+
+### Что делать с каждой задачей
+
+Сперва то, что не требует ничьего решения:
+
+1. **Проверь, не сделано ли уже.** Задача, реализованная попутно в соседнем
+   изменении, — самая частая находка. Смотри код, документацию, историю коммитов
+   по ключевым словам. Удаление «как реализованной» деструктивно и без следа
+   (в `REJECTED.md` реализованные не пишутся), поэтому порог улики жёсткий:
+   `close <slug> --implemented` только имея **конкретный коммит или строку
+   документа**, закрывающие задачу, и ссылка идёт в доклад. Есть лишь косвенные
+   признаки — не удаляй сам, вынеси в пачку вопросов. Сделана частично → задача
+   сжимается до остатка: тело правишь редактором, заголовок и хук — через
+   `edit`.
+2. **Проверь, не отменена ли решением.** Документ, ADR или архивное изменение
+   мог закрыть вопрос иначе — тогда `close <slug> --reason "<ссылка на
+   решение>"`. Задача закрывается не только коммитом.
+3. **Проверь пересечения.** Две задачи об одном — содержимое в одну, вторую
+   `close <slug> --reason "слита с <другой-слаг>"`. Смотри **шире порции**:
+   интейк дедуплицирует новое против существующего, но никогда не
+   пересматривает уже лежащее, и две задачи с одной причиной могут лежать рядом
+   месяцами.
+4. **Пере-кластеризуй по общей причине.** Несколько задач, оказавшихся симптомами
+   одного дефекта, сливаются в одну — это находка, которую интейк дать не мог.
+5. **Гигиена полей** — протухший хук, вопрос в прозе, снятый ответ, свойство
+   репозитория в рамках, предписание процесса в теле. Список и правила — в
+   скилле `tasks`.
+
+Затем — то, что решает пользователь:
+
+6. **Жива ли она вообще.** Контекст мог измениться: ушла зависимость, отпал
+   сценарий, обошли иначе. Здесь и звучит вопрос о выкидывании.
+7. **Та ли цель.** Приоритетов нет, и «повысить» нечего — вместо повышения
+   **смена цели** (`edit <slug> --goal <другой>`) или включение в ближайший
+   набор. Задача, которой не находится цель, — кандидат на выход: она не попадёт
+   ни в один спринт.
+8. **Задача ли это по-прежнему.** Не проходит тест «готова к взятию» → `edit
+   <slug> --type idea`, дальше штурм. Разрослась → `edit <slug> --type epic`,
+   дальше декомпозиция.
+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` — вынести распознавание в сервис-спутник
+>    - Понизить до `[idea]` *(рекомендую)* — не проходит тест «готова к взятию»
+>    - Оставить задачей
+
+Каждый вариант несёт причину — ту самую, что уедет в `--reason`. Ответы применяй
+сразу и, если в порции осталось ещё, следующей итерацией показывай следующие ≤3.
+
+## Шаг 4. Выбор цели и набор спринта
+
+1. **Покажи состояние целей**: линия `PLAN.md` с обоснованием порядка, кусты, и
+   по каждой цели-кандидату — сколько под ней задач без открытых вопросов
+   (`list --goal <слаг>`). Цель без готовых задач набором не станет: её сперва
+   надо декомпозировать.
+2. **Цель называет человек.** Это продуктовое решение, а не механика: агент
+   предлагает и объясняет, но не выбирает.
+3. **Набор собирает агент** — `sprint start --goal <слаг>`, затем `sprint take
+   …`. Скрипт не даст взять чужую цель, идею, эпик, задачу с открытым вопросом
+   или без критериев приёмки.
+4. **Набор показывается человеку до старта работ.** Показ — это и есть момент
+   заморозки: после него набор не двигается.
+5. Задача, которой для взятия не хватает только критериев приёмки, дописывается
+   здесь же — но если для критериев нужен ответ человека, это вопрос, и задача в
+   набор не идёт.
+
+**Размер — ориентир, а не закон:** 5–8 задач. Можно взять больше, можно меньше —
+набор под цель важнее круглого числа; одна крупная задача спринтом тоже бывает.
+
+## Доклад сессии
+
+- Что просмотрено: N из M, сколько порций, по какому признаку отобраны.
+- Вопросы: разобрано N, из них отвечено без человека N, снято тегов N.
+- Разбор процесса: что записано и куда.
+- Изменения списком: удалено как реализованное (со ссылками), ушло без
+  реализации (с причинами), понижено до идей, слито, сменило цель.
+- Новый спринт: цель, набор со слагами, дата.
+- **Границы покрытия**: сколько задач не трогали и какие именно секции, теги или
+  цели остались — иначе доклад читается как «беклог разобран».
+- `tasks.py check` после правок — результат строкой.

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

@@ -0,0 +1,91 @@
+# Ведение спринта
+
+Спринт — набор задач под одну цель, замороженный до его конца. Здесь то, что
+происходит **внутри** спринта: как задача заканчивается, что считается сделанным,
+кто принимает и что идёт в доклад. Как спринт набирается — шаг 4 в
+[cadence.md](cadence.md).
+
+## Наблюдаемые исходы задачи
+
+Как они достигаются — дело пайплайна проекта. Сессия знает только исход и его
+след.
+
+- **Сделана** — по определению готовности ниже. `close <slug> --implemented`:
+  файл и строка удаляются, следом остаётся коммит.
+- **Вышла из спринта** — `sprint drop <slug> --reason …`: возвращается в беклог
+  с вопросом в файле и **без живого незакоммиченного предложения** — иначе при
+  следующем взятии оно столкнётся с новым. Наработки, которые жалко терять,
+  переезжают в тело задачи текстом.
+- **Переросла в эпик** — распознаётся **до того, как под неё заведено
+  предложение об изменении**, иначе его придётся выбрасывать. Помечается
+  `[epic]`, выходит из набора, уходит на декомпозицию; спринт продолжается
+  остальными, части в замороженный набор не добавляются.
+- **Отменена решением по ходу** — `close <slug> --reason "<ссылка на решение>"`
+  прямо из спринта. Это редкий, но законный исход, и он называется в докладе.
+
+**Конец спринта** — когда по каждой задаче набора наступил один из исходов. Не
+«все сделаны»: иначе одна застрявшая задача держит спринт бесконечно. Затем
+`sprint close`.
+
+**Провал спринта.** Сработал блокер — спринт распускается (`sprint close
+--dissolve --reason …`), недоделанное возвращается в беклог, новый набор
+делается после ответа человека. Спринт не «ждёт»: ждать может человек, а
+замороженный набор, который нельзя двигать, только мешает.
+
+## Определение готовности
+
+Задача засчитывается сделанной, когда верно **всё**:
+
+1. **Пайплайн задачи пройден до конца** — со своим определением готовности, за
+   которое отвечает проект: проверки, состав ревью, документация, коммит. Здесь
+   оно не пересказывается и не подменяется — **форма фиксирована, содержание
+   даёт `CLAUDE.md` проекта**. Пайплайна нет, задача сделана руками — условие
+   читается как «проверки проекта зелёные и изменение влито».
+2. **Критерии приёмки проверены поимённо** — каждый со своим оракулом, исход по
+   каждому назван. Это единственное, что добавляет управление задачами: пайплайн
+   отвечает «сделано по правилам», критерии — «сделано то, что заказывали».
+3. **Урожай заведён** — вопросы и задачи, найденные по ходу, лежат в беклоге, а
+   не в отчёте.
+
+### Кто и по чему принимает
+
+Три условия, без которых пункт про критерии не исполняется никем:
+
+1. **Критерии переживают файл задачи.** Файл удаляется при закрытии, поэтому
+   критерии копируются туда, где их увидит приёмщик — в предложение об
+   изменении, описание ветки, тело коммита. Куда именно, называет `CLAUDE.md`
+   проекта. Иначе приёмка проверяет критерии из файла, которого больше нет.
+2. **Принимает не исполнитель.** Отдельный контекст — сабагент или человек, —
+   которому дают изменение, отчёт исполнителя и отчёты ревью. Тот же принцип
+   декорреляции, на котором стоит любой конвейер проверки: занизивший и
+   проверяющий не должны быть одним контекстом.
+3. **Расхождение — дефект критериев.** Приёмщик правит критерии и возвращает
+   задачу исполнителю **в этом же спринте**: ответ есть, остаток есть, по тесту
+   про остаток это не выход из спринта.
+
+## Что врывается в замороженный набор
+
+Только два класса — правило и его обоснование в SKILL.md. Здесь механика:
+
+- вторжение **не добавляет** задачу в набор: `SPRINT.md` остаётся набором под
+  цель. Внеплановая работа делается и называется в докладе отдельной строкой
+  «внеплановое: что и почему»;
+- если внеплановое требует больше пары часов, честнее распустить спринт, чем
+  делать вид, что набор соблюдается;
+- всё остальное падает в беклог через обычный интейк и ждёт сессии.
+
+## Доклад в конце спринта
+
+Проверяемые якоря, а не пересказ:
+
+- **Цель спринта** и по каждой задаче набора: **хеш коммита**, дословный исход
+  проверок проекта, **исход по каждому критерию приёмки**.
+- **Какие развилки решались** и чем обоснованы.
+- **Урожай:** сколько задач заведено, какие вопросы накопились, что вышло из
+  спринта и почему, что было внеплановым.
+- **Поимённая сверка урожая** с отчётами ревью: каждая отложенная находка имеет
+  либо слаг, либо строку «не заведена: причина». Нулевой урожай при непустом
+  отчёте — сигнал, а не благополучие.
+- **Созрела ли порция для сессии.** Решение звать — человека, напоминание —
+  обязанность агента: `⌈урожай / 8⌉` порций.
+- **Границы покрытия** сжатой строкой: что в этом спринте не проверялось вовсе.