av-dev-pipeline: бриф удалён, проходы читают документы канона напрямую

- удалены скилл project-brief и контракт брифа; вместо них references/
  project-facts.md — карта «что нужно проходу → где лежит» и таблица
  поразрядной деградации по документам
- девять charter'ов, review-pipeline, task-pipeline и task-batch переписаны
  на пути канона; OpenSpec стал объявленной предпосылкой без ветки деградации
- шаг синка документации переписан в построчный доклад, закрытие задачи —
  вызовом скилла av-dev-pm:tasks вместо строки-слота из CLAUDE.md
- по находкам ревью: docs.py звал tasks.py из чужого каталога и выдавал его
  отказ окружения за дрейф; сверка миграций не видела рабочее дерево;
  плейсхолдер краснел вместо замечания; сверка capability проходила по
  совпадению с именем пакета; tasks.py не читал docs/.pm.json; скилл docs
  пересказывал канон в пяти местах

av-dev-pipeline/skills/task-pipeline/SKILL.md

@@ -15,30 +15,28 @@ description: Автономно проводит одну задачу чере
 
 ## Предпосылки
 
-- **OpenSpec и скиллы `opsx:*`** — внешняя обвязка, на которой стоят шаги 2, 3, 6
-  и 8, а также проход `review-specs` и профиль `design` (они завязаны на
-  `openspec/changes/<id>/specs/*/spec.md` и на `openspec validate --strict`). В
-  проекте без OpenSpec эти шаги упадут на «нет такого скилла»: либо подключаем
-  OpenSpec, либо цикл вырождается в «прочитать задачу → код → ревью кода →
-  коммит», и об отсутствии спекового контура говорится в докладе.
+- **OpenSpec и скиллы `opsx:*` — жёсткая предпосылка, а не опция.** На них стоят
+  шаги 2, 3, 6 и 8, проход `review-specs` и профиль `design` (они завязаны на
+  `openspec/changes/<id>/specs/*/spec.md` и на `openspec validate --strict`).
+  **Проект без OpenSpec этим пайплайном не ведётся** — подключай OpenSpec, а не
+  вырождай цикл: ветка деградации здесь не пишется, потому что непроверенная
+  ветка деградации хуже честного отказа.
 - **Скиллы зовутся с пространством имён** — `av-dev-pipeline:review-pipeline`,
-  `av-dev-pipeline:project-brief`. Короткое имя может разрешиться в устаревшую
-  проектную копию, и это произойдёт молча.
+  `av-dev-pm:docs`, `av-dev-pm:tasks`. Короткое имя может разрешиться в
+  устаревшую проектную копию, и это произойдёт молча.
 - **Проектные копии этих скиллов и агентов удаляются при установке плагина**
   (`.claude/skills/{task-pipeline,review-pipeline,task-batch}`,
   `.claude/agents/<проект>-review-*.md`). Две копии одного скилла расходятся, и
   побеждает та, что короче названа.
 
-Перед стартом прочитай `CLAUDE.md` проекта и то, на что он ссылается
-(архитектура, конвенции), если ещё не в контексте. Проектные факты, нужные ревью
-— инварианты, команда гейта, объёмы, модель угроз, прецеденты, — живут в брифе
-(`docs/review-brief.md`, контракт — в references конвейера ревью).
+Перед стартом прочитай `CLAUDE.md` проекта и то, на что он ссылается, если ещё
+не в контексте. Проектные факты, нужные ревью — инварианты, семантика гейта,
+объёмы, модель угроз, прецеденты, — живут в **документах канона** `av-dev-pm`;
+карта «что где» — `references/project-facts.md` конвейера ревью.
 
-**Брифа нет ни по одному пути — заведи его, а не работай в деградированном
-режиме.** Вызови Skill **`av-dev-pipeline:project-brief`**: он соберёт бриф из
-`CLAUDE.md`, архитектуры, файла задач и конвенций, покажет человеку и вернёт
-путь, который дальше передаётся ревью. Это механика: спрашивать разрешения не
-нужно. Один шаг один раз на проект — против деградации на каждой задаче.
+**Документов канона нет — проект к нему не приведён.** Скажи это строкой и
+предложи скилл `av-dev-pm:canon`: одна операция на проект против поразрядной
+деградации на каждой задаче. Работу при этом не останавливай.
 
 ## Границы: чем пайплайн не владеет
 
@@ -109,7 +107,7 @@ description: Автономно проводит одну задачу чере
    в объявленных границах.
 
 **Что остатком не является — правило живёт не здесь.** Канонический текст с обеими
-оговорками — в плагине `av-dev-tasks`, скилл `av-dev-tasks:session`, раздел
+оговорками — в плагине `av-dev-pm`, скилл `av-dev-pm:session`, раздел
 `## Вопрос, блокер, необратимое`, подраздел «Отличать вопрос от застревания».
 Правило принадлежит управлению задачами, потому что решает **сделана задача или
 вышла**, — это исход планирования, а не исполнения. **Ссылайся, не
@@ -122,7 +120,7 @@ description: Автономно проводит одну задачу чере
 Оба порога — стоп: первый поднимает решение до начала записи, второй даёт исход
 «не доведена».
 
-Плагин `av-dev-tasks` не подключён — правило не отменяется, а становится
+Плагин `av-dev-pm` не подключён — правило не отменяется, а становится
 осторожнее: прежде чем записать зависящее от нерешённого куда бы то ни было —
 в хранилище, в журнал, в витрину или наружу, — спрашивай человека.
 
@@ -183,7 +181,7 @@ description: Автономно проводит одну задачу чере
 ### 4. (Нетривиальная) Ревью предложения — профиль `design`, ДО кода
 
 Первый чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`** с профилем
-`design`, ссылкой на change `<id>` и путём к брифу. Он запустит `review-specs`
+`design` и ссылкой на change `<id>`. Он запустит `review-specs`
 (режим «дизайн ДО кода»), `review-rubric` (фаза 1: приёмочные критерии для
 задуманного узла) и `review-architecture` по предложению.
 
@@ -202,14 +200,14 @@ description: Автономно проводит одну задачу чере
 ### 6. Написать код — `opsx:apply`
 
 Вызови Skill `opsx:apply` для реализации `tasks.md`. Код — по конвенциям проекта
-(файл назван в разделе `## Карта` брифа). Меняешь схему — обнови её описание в
+(каталог `docs/conventions/`). Меняешь схему — обнови её описание в
 документации тем же change, если проект этого требует: гейт обычно это проверяет.
 
 Прогони гейт и добейся зелёного — он же гейт следующего шага.
 
 **Поведенческая верификация.** Если задача меняет реальное поведение (новый
 эндпоинт, разбор входа, схема, форма ответа) — зелёных юнит-тестов мало. Подними
-изменение вживую командой из раздела `## Команды` брифа и прогони сценарий.
+изменение вживую командой из раздела команд `CLAUDE.md` и прогони сценарий.
 Пропусти только для чисто внутренних правок без наблюдаемого рантайма.
 
 **Сервис не оставляем лежать.** Если запуск упал — почини или откати до конца
@@ -218,10 +216,10 @@ description: Автономно проводит одну задачу чере
 ### 7. Ревью кода — Skill `av-dev-pipeline:review-pipeline`
 
 Второй чекпоинт. Вызови Skill **`av-dev-pipeline:review-pipeline`**, дав ссылку
-на change `<id>`, базу диффа, путь к брифу, профиль **и режим запуска**.
+на change `<id>`, базу диффа, профиль **и режим запуска**.
 
 **Правило выбора профиля живёт в скилле конвейера** (раздел «Профили»), проектные
-триггеры — в разделе `## Триггеры` брифа. Здесь оно не пересказывается: три
+триггеры — в `docs/review.md`, если записаны. Здесь оно не пересказывается: три
 копии одного правила расходятся, и работать будет та, которую прочитали
 последней. Помни ровно одно — **профиль выбирается по факту изменения, а не по
 ощущению важности**, и посмотри таблицу перед вызовом.
@@ -271,22 +269,38 @@ description: Автономно проводит одну задачу чере
 
 ### 9. Синк документации
 
-Ревью выполненного — до этого шага. Затем:
+Ревью выполненного — до этого шага. Затем **вызови Skill `av-dev-pm:docs`**: он
+владеет содержимым документов канона и ведёт чек-лист синка. Плагина нет —
+пройди чек-лист сам по списку ниже.
 
-- суть переехавшего решения — в документацию проекта (архитектура, журнал
-  решений), если её там ещё нет;
-- менялась схема — её описание обновлено тем же change;
-- новое, узнанное о внешнем формате или о данных, — в тот файл проекта, который
-  это накапливает; такой файл обычно ценнее кода;
-- воспроизведённый дефект (свой или чужой) — в раздел `## Прецеденты` брифа:
-  класс, симптом, чем воспроизведён, чем закончилось. Это единственный артефакт,
-  который делает следующее ревью умнее.
+**Правило одно и оно жёсткое: принуждённое отрицание.** Доклад обязан назвать
+**каждый** документ канона — либо чем он обновлён, либо «не требуется, потому
+что…». Нетронутые группируются одной строкой с общей причиной. Список триггеров
+прозой уже проверен на живом проекте и дал 6 записей ADR на 43 изменения;
+работает только обязательное отрицание.
 
-**Задачу пайплайн не закрывает.** Записи учёта — индекс, статус, спринт — он не
-трогает вовсе: закрытие происходит **после приёмки** и делается владельцем
-спринта, а пайплайн на этом шаге стоит до коммита и до всякой приёмки. Скриптов
-и скиллов учёта не зови — их у тебя и нет: пути между плагинами не разрешаются, и
-моста здесь намеренно не проложено. Твоё дело — назвать исход в докладе.
+Документы и их триггеры: `openspec/specs/` (поведение — вливает `opsx:archive`),
+`database.md` (тронуты миграции), `architecture.md` (новый компонент, граница,
+внешняя зависимость), `adr/` (дорогой откат, намеренный отказ, пересмотр
+прежнего), `research/` (узнали новое о внешних данных), `security.md` (новый
+недоверенный вход, токен, путь наружу), `conventions/` (промоут, включая
+**удаление** формулировки, ставшей правилом линтера), `review.md`
+(воспроизведённый дефект — с пометкой «проскочил» или «пойман ревью»),
+`passport.md`, `CLAUDE.md`.
+
+### 9а. Закрыть задачу
+
+**Вызови Skill `av-dev-pm:tasks`** и попроси закрыть задачу как реализованную —
+он владеет форматом и двигает строку между индексами сам. Путь к его скрипту не
+выясняй и индексы руками не правь: мост между плагинами — вызов скилла, а не
+путь.
+
+Плагина в проекте нет — вызов не разрешится. Тогда **ничего не выдумывай**:
+скажи в докладе, что учёт задач остаётся за владельцем, и назови исход.
+
+**Приёмщик и исполнитель здесь совпадают**, и закрытие не окончательно: человек
+на сессии может вернуть задачу (`reopen` с причиной). Поэтому доклад по критериям
+приёмки — не формальность, а единственное, по чему приёмка вообще возможна.
 
 ### 10. Коммит