добавлены плагины 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-pipeline/skills/task-pipeline/SKILL.md

@@ -0,0 +1,274 @@
+---
+name: task-pipeline
+description: Автономно проводит одну задачу через полный цикл Spec Driven Development — от постановки до коммита (opsx explore→propose→ревью спек профилем design→apply→ревью кода→archive→коммит), с обязательными чекпоинтами ревью и докладом об исходе. Использовать, когда просят взять/сделать задачу или довести идею до реализации.
+---
+
+# Пайплайн задачи
+
+Оркестратор **одной** задачи по Spec Driven Development: проводит её от
+постановки до коммита максимально автономно. Механику не согласовываем — делаем.
+
+Это тонкая обёртка над каноническими скиллами `opsx:explore` / `opsx:propose` /
+`opsx:apply` / `opsx:archive` — вызывай их через Skill, не переизобретай их шаги.
+Ревью — скилл `review-pipeline`, он же держит правило выбора профиля.
+
+Перед стартом прочитай `CLAUDE.md` проекта и то, на что он ссылается
+(архитектура, конвенции), если ещё не в контексте. Проектные факты, нужные ревью
+— инварианты, команда гейта, объёмы, модель угроз, — живут в брифе
+(`docs/review-brief.md`, контракт — в references конвейера ревью).
+
+## Границы: чем пайплайн не владеет
+
+- **Беклогом, спринтом, целями и приоритетами.** Задача приходит извне. Пайплайн
+  её не выбирает, не приоритизирует, не заводит и не переоценивает; если в
+  проекте есть свой процесс управления задачами — он и решает, что брать.
+- **Определением ценности.** «Нужна ли эта функциональность» — не вопрос
+  пайплайна ни на одном шаге.
+
+Пайплайн владеет **своим** определением готовности (ниже) и **сообщает
+наблюдаемый исход**. Что с исходом делать дальше — не его дело.
+
+## Наблюдаемые исходы
+
+Ровно три, и каждый обязан быть назван в докладе прямо:
+
+- **сделана** — определение готовности выполнено целиком;
+- **не доведена** — с причиной и с записанным вопросом; что именно сделано и до
+  какой границы, названо явно;
+- **оказалась крупнее задачи** — распознаётся **до заведения change**, иначе его
+  придётся выбрасывать. Дальше — декомпозиция, и это не работа пайплайна.
+
+## Определение готовности
+
+Задача сделана, когда верно всё:
+
+1. гейт проекта зелёный;
+2. ревью проведено **по профилю**, состав прогона сверен с таблицей профилей
+   поимённо, непущенные проходы названы в границах покрытия;
+3. change заархивирован, дельты влиты в актуальные спеки;
+4. коммит сделан в текущую ветку;
+5. **критерии приёмки, если проект их дал**, проверены поимённо, у каждого назван
+   оракул и исход. Критерии приходят снаружи; пайплайн их не сочиняет и не
+   занижает. Расхождение «критерии закрыты, а суть задачи не достигнута» — дефект
+   критериев, и о нём сообщается, а не молча дорабатывается.
+
+Пункты 1–4 — своё. Пункт 5 — внешнее, и проверяется только если оно дано.
+
+## Принцип автономности
+
+**Умолчание — делать, а не спрашивать.** Задача доводится до коммита без участия
+человека; предполагается, что так пройдёт большинство задач.
+
+Наткнулся на вопрос, который решать не тебе, — **не останавливайся и не
+спрашивай**. Запиши его и продолжай:
+
+1. **Запиши вопрос там, где проект держит вопросы** (секция беклога, файл
+   задачи, трекер — это знает проект). Если проект не сказал, куда, — отдельной
+   секцией `Вопросы` в своём докладе, и это тоже исход. Тело отвечает на три
+   вещи: **что именно решить**, **какие есть варианты и цена каждого**, **что
+   стоит, пока решения нет**. Плюс твоя рекомендация — человек чаще соглашается,
+   чем выбирает заново, и готовое суждение экономит ему весь контекст.
+2. **Переформулируй задачу на остаток** — то, что делается без этого решения.
+   Назови границу: докуда доводим сейчас.
+3. Доведи остаток до конца и закоммить. Задача не «висит на вопросе», она сделана
+   в объявленных границах.
+
+**Что остатком не является** — две оговорки, без которых правило вредит:
+
+- **остаток, который записывает в хранилище или в журнал состояние, зависящее от
+  нерешённого, — не остаток.** Решение поднимается до начала записи. Иначе
+  нерешённое материализуется в данные, а данные переживают решение;
+- **остаток, из которого пропала польза, названная в постановке, — не остаток.**
+  Это исход «не доведена», а не «сделана в границах».
+
+Нет полезного остатка — задача заканчивается исходом «не доведена», вопрос
+записан, ничего не коммитится наполовину.
+
+### Когда всё-таки спрашивать
+
+Узко и по другому основанию — не «сложное решение», а **необратимое действие**:
+
+- деплой, выкладка наружу, смена публичного адреса или токенов;
+- удаление или перезапись рабочих данных, включая подрезку архивов;
+- всё, что уходит за пределы машины.
+
+Здесь ошибка не откатывается коммитом, поэтому спрашиваем даже когда решение
+кажется очевидным. Развилка в дизайне — вопрос в запись; необратимое действие —
+вопрос человеку сейчас.
+
+Стиль правок — заточка под проект и конвенции, right-size, без золочения.
+
+## Шаги
+
+### 1. Прочитать задачу
+
+Задача задана извне (slug, файл, ссылка, описание) — прочитай её и связанные
+спеки и черновики. Не задана — попроси у вызывающего; сам в беклог не лезь и
+приоритеты не интерпретируй.
+
+Если проект даёт задаче **критерии приёмки**, выпиши их сразу: на шаге 3 они
+уезжают в `tasks.md` change. Файл задачи может быть удалён до коммита, а
+критерии обязаны его пережить.
+
+Оцени тривиальность (влияет на шаг 4):
+
+- **тривиальная** — локальная правка без изменения поведения, спек и схемы,
+  решение очевидно. Explore и ревью спек пропускаются;
+- **нетривиальная** — новое или изменённое поведение, дизайн-развилки, задеты
+  инварианты, схема или несколько capability. Полный цикл.
+
+Здесь же — проверка на «крупнее задачи»: если видно, что одним заходом это не
+мерджится, объявляй исход **до** заведения change.
+
+### 2. (Опц.) Груммить идею — `opsx:explore`
+
+Только для идей и мутных постановок. Вызови Skill `opsx:explore`. Развилку
+грумминга не выноси на человека — запиши вопросом и груми остаток. Выход: ясная
+постановка, готовая к propose. **В explore не пишем код.**
+
+### 3. Завести change — `opsx:propose`
+
+Вызови Skill `opsx:propose`. Получаем `proposal.md`, дизайн (для нетривиальных),
+дельта-спеки (`ADDED`/`MODIFIED`/`REMOVED Requirements`), `tasks.md`. Каждое
+`### Requirement` содержит `SHALL`/`MUST`; структурные заголовки английские,
+сценарии `GIVEN/WHEN/THEN`. Прогони `openspec validate --strict <id>`.
+
+Критерии приёмки задачи, если они были, копируются в `tasks.md` отдельным блоком.
+
+### 4. (Нетривиальная) Ревью предложения — профиль `design`, ДО кода
+
+Первый чекпоинт. Вызови Skill **`review-pipeline`** с профилем `design`, ссылкой
+на change `<id>` и путём к брифу. Он запустит `review-specs` (режим «дизайн ДО
+кода»), `review-rubric` (фаза 1: приёмочные критерии для задуманного узла) и
+`review-architecture` по предложению.
+
+Смысл профиля: архитектурная находка на готовом коде стоит переписывания и
+потому игнорируется — та же находка здесь стоит абзаца обсуждения. Рубрику из
+`review-rubric` перенеси в `tasks.md` как приёмочные критерии; там же уже лежат
+критерии от постановки, если они были.
+
+### 5. Отработать замечания ревью предложения
+
+- Мелочь и явные улучшения — правь сам в спеках и дизайне.
+- Развилки (компромисс, scope, инвариант) — вопросом в запись, спеки урезаются на
+  остаток.
+- После правок перепрогони `openspec validate --strict <id>`.
+
+### 6. Написать код — `opsx:apply`
+
+Вызови Skill `opsx:apply` для реализации `tasks.md`. Код — по конвенциям проекта
+(файл назван в разделе `## Карта` брифа). Меняешь схему — обнови её описание в
+документации тем же change, если проект этого требует: гейт обычно это проверяет.
+
+Прогони гейт и добейся зелёного — он же гейт следующего шага.
+
+**Поведенческая верификация.** Если задача меняет реальное поведение (новый
+эндпоинт, разбор входа, схема, форма ответа) — зелёных юнит-тестов мало. Подними
+изменение вживую командой из раздела `## Команды` брифа и прогони сценарий.
+Пропусти только для чисто внутренних правок без наблюдаемого рантайма.
+
+**Сервис не оставляем лежать.** Если запуск упал — почини или откати до конца
+шага.
+
+### 7. Ревью кода — Skill `review-pipeline`
+
+Второй чекпоинт. Вызови Skill **`review-pipeline`**, дав ссылку на change `<id>`,
+базу диффа, путь к брифу, профиль **и режим запуска**. Профиль выбирается по
+факту изменения, а не по ощущению важности; общее правило — в скилле, проектные
+триггеры — в брифе:
+
+- миграция схемы, новый пакет, публичный контракт, правило идентичности или
+  слияния данных → `deep`;
+- иначе меняется поведение, видимое снаружи → `standard`;
+- иначе (багфикс, локальная правка, доки) → `quick`.
+
+**Режим по умолчанию последовательный, и обосновывать его не надо.** Параллельно
+гоняем только тогда, когда об этом попросили явно **и назвали набор** — какие
+именно проходы или какую стадию. Просьба без набора основанием не считается:
+гони последовательно и скажи строкой, что набор не был назван. Причина умолчания
+— замеры: `adversary` и `ops` доказывают находки числами, а два меряющих прохода
+на одной машине портят числа друг другу; находка с испорченным оракулом хуже
+отсутствующей, потому что выглядит доказанной.
+
+Скилл сам гоняет гейт, нужные проходы и обязательный триаж. Возвращает отчёт с
+потолком 7 пунктов, разметкой `Действие: инлайн | развилка` и секцией границ
+покрытия.
+
+**Сверь состав прогона с таблицей профилей в скилле, прежде чем коммитить.**
+Пропуск прохода не отличим от прохода без находок: гейт зелёный, спеки сошлись,
+отчёт выглядит полным. Единственный, кто мог бы заметить пропуск, — триаж, а он
+заполняется тем, что ему подали. Отчёт обязан называть запущенные проходы
+**поимённо и с исходом**; непущенный идёт строкой «не запускался» в границы
+покрытия. Реестр короткий (4–8 проходов) — сверка стоит одного взгляда, а
+молчащий пропуск уже стоил семи находок и отдельной задачи на их дозакрытие.
+
+Отработай так же, как шаг 5: помеченное `инлайн` чини сам и не логируй,
+`развилка` — вопросом в запись (он уже сформулирован триажем, его остаётся
+перенести). После правок — снова гейт.
+
+**Границы покрытия из отчёта не выбрасывай** — они уезжают в финальный доклад
+сжатой строкой. Отчёт, из которого исчезло «что проверить было невозможно»,
+превращается в ложное ощущение проверенности.
+
+Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`): по нему
+потом видно, что было найдено и что из этого осталось незаведённым.
+
+### 8. Архивировать — `opsx:archive`
+
+Вызови Skill `opsx:archive`: change уезжает в архив, дельты вливаются в
+актуальные спеки.
+
+### 9. Синк документации и закрытие задачи
+
+Ревью выполненного — **до** закрытия. Затем:
+
+- суть переехавшего решения — в документацию проекта (архитектура, журнал
+  решений), если её там ещё нет;
+- менялась схема — её описание обновлено тем же change;
+- новое, узнанное о внешнем формате или о данных, — в тот файл проекта, который
+  это накапливает; такой файл обычно ценнее кода;
+- **задача закрывается процедурой проекта** — своей у пайплайна нет. Есть скилл
+  или скрипт беклога — вызови его; нет — скажи в докладе, что задача сделана и
+  закрытие остаётся за вызывающим. Не выдумывай формат чужого индекса.
+
+### 10. Коммит
+
+Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не
+создавай и не переключай, ничего не пушь. При ручном запуске HEAD обычно на
+основной ветке — коммит идёт прямо в неё; под оркестратором `task-batch` HEAD на
+ветке задачи в изолированном worktree, и делать дополнительно ничего не нужно.
+
+Сообщение — по-русски, скиллом `commit`, если он подключён (первая строка «что
+сделано», тело списком 1–3 пункта, без трейлеров). Одна задача — один осмысленный
+коммит.
+
+Готово — доложи кратко:
+
+- **исход** задачи одним из трёх слов и, если не «сделана», чем ограничен
+  результат;
+- что сделано, какие вопросы записаны и куда;
+- ссылка на архивный change;
+- исход по каждому критерию приёмки, если они были;
+- **одна строка границ покрытия**: какой профиль и режим гонялись, какие проходы
+  не запускались и что проверить было невозможно. Доклад без неё сообщает
+  «проверено», не сообщая, что именно.
+
+## Тонкости
+
+- **Не завязывайся на основную ветку и корень репозитория.** Скилл работает в
+  текущем worktree и на текущей ветке: не делай `git checkout`/`switch`, не
+  создавай веток, не пушь.
+- Не пропускай `openspec validate --strict` перед архивацией.
+- Тривиальная задача: шаги 2 и 4 пропускаются; ревью кода (шаг 7) остаётся
+  всегда, но в профиле `quick`.
+- Гейт блокирует: пока он красный, опиниативные проходы не запускаются. Чинить и
+  перезапускать, а не «посмотреть заодно».
+- Если ревью предлагает крупную переработку — это развилка: не правь молча и не
+  спрашивай, запиши вопросом и доведи остаток.
+- Держи вызывающего в цикле короткими репликами на переходах фаз, но не проси
+  подтверждать механику.
+- **Занизить профиль ревью или пропустить проход — самый дешёвый способ
+  «ускориться», и он же самый дорогой по последствиям.** Защита одна: профиль
+  выбирается по факту изменения, состав сверяется поимённо, а непущенное
+  называется в отчёте. Пропуск, названный строкой, стоит строки; пропуск молчащий
+  стоил семи находок.