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-pipeline/skills/review-pipeline/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review-pipeline
-description: "Конвейер ревью изменения, устроенный по темам: документ проекта либо заводит тему ревью, либо питает чужую тему источником, либо процессный и в ревью не читается вовсе. Ядро тем — requirements, autotests, conventions, architecture, security, operations; список тем открытый, свои темы проект заводит документом. Разметка задачи идёт один раз, после propose: агент review-scope выводит размер и сложность, из их максимума — метка, и раздаёт темы проходам обеих стадий. Метка правит и ревью дизайна (small — только specs; medium — плюс rubric; large — плюс architecture), и ревью кода (small — гейт, спеки, код, триаж; medium — плюс приёмник тем; large — плюс доказательство: враждебные постановки, эксплуатационный постмортем, архитектурный проход на широком входе). Триаж обязателен всегда. Порядок прогона — граф зависимостей: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Проектная специфика приходит из документов канона av-dev-pm. Вызывается из task-pipeline (чекпоинты ревью) и из task-batch (финальная сверка)."
+description: "Конвейер ревью изменения, устроенный по темам: документ проекта либо заводит тему ревью, либо питает чужую тему источником, либо процессный и в ревью не читается вовсе. Ядро тем — requirements, autotests, conventions, architecture, security, operations; список тем открытый, свои темы проект заводит документом. Разметка задачи идёт один раз, после propose: агент review-scope выводит размер и сложность, из их максимума — метка, и раздаёт темы проходам обеих стадий. Метка правит и ревью дизайна (small — только specs; medium — плюс rubric; large — плюс architecture), и ревью кода (small — гейт, спеки, код, триаж; medium — плюс приёмник тем; large — плюс доказательство: враждебные постановки, эксплуатационный постмортем, архитектурный проход на широком входе). Триаж обязателен всегда. Порядок прогона — граф зависимостей: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Проектная специфика приходит из документов канона av-dev-docs. Вызывается из task-pipeline (чекпоинты ревью) и из task-batch (финальная сверка)."
 ---
 
 # Конвейер ревью
@@ -52,7 +52,7 @@ description: "Конвейер ревью изменения, устроенны
   требований. **Проект без OpenSpec этим конвейером не проверяется** — подключай
   OpenSpec, а не понижай прогон: ветка деградации здесь не пишется, потому что
   непроверенная ветка деградации хуже честного отказа. Заводить руками не надо:
-  `av-dev-pm:init` делает `openspec init` на новом проекте, `canon adopt` — на
+  `av-dev-docs:init` делает `openspec init` на новом проекте, `canon adopt` — на
   переводимом, и оба кладут `openspec/config.yaml` канонической формы.
 - **Документы канона** — см. следующий раздел.
 - **Проектные копии этих скиллов и агентов удаляются при установке.** Если в
@@ -88,7 +88,7 @@ description: "Конвейер ревью изменения, устроенны
 критерий, по которому судит изменение. `adr.*`, `research.*` и `tasks/` не
 открывает никто.
 
-Дом канона этой раскладки — `av-dev-pm`, `references/canon.md`, раздел «Три
+Дом канона этой раскладки — `av-dev-docs`, `references/canon.md`, раздел «Три
 категории документов». Конвейер её **читатель**: категории и имена тем он берёт
 оттуда и своих не заводит.
 
@@ -120,7 +120,7 @@ description: "Конвейер ревью изменения, устроенны
 читал решения, а эксплуатационный и `specs` — числа. Цена решения записана в
 каноне и повторяется здесь, потому что платит её конвейер: **расхождение
 изменения с записанным решением прогоном не ловится**, это работа сверки
-документации (`av-dev-pm`, агент `doc-consistency`) на сессии между спринтами.
+документации (`av-dev-docs`, агент `doc-consistency`) на сессии между спринтами.
 Строка об этом обязательна в границах покрытия каждого прогона.
 
 **Своя тема проекта бывает двух происхождений, и обе законны:** документ, который
@@ -147,7 +147,7 @@ description: "Конвейер ревью изменения, устроенны
 дом для тех же фактов разошёлся бы и выглядел актуальным.
 
 **Документов канона нет вовсе** — проект не приведён к канону. Скажи это строкой
-и предложи скилл `av-dev-pm:canon`: одна операция на проект против деградации на
+и предложи скилл `av-dev-docs:canon`: одна операция на проект против деградации на
 каждой задаче. Прогон при этом не останавливается.
 
 ## Что получает каждый проход
@@ -1021,7 +1021,7 @@ flowchart TD
   и где это лежит в документах проекта; таблица поразрядной деградации.
 - [references/review-levels.md](references/review-levels.md) — дом правила выбора
   метки: две оси, спорное вниз, чем `small` дешевле, доли как проверка правила.
-- Skill `av-dev-pm:canon` — приведение проекта к канону документов.
+- Skill `av-dev-docs:canon` — приведение проекта к канону документов.
 - [references/finding-contract.md](references/finding-contract.md) — контракт находок.
 - [references/promote.md](references/promote.md) — промоут находка → конвенция → правило → удаление.
 - [references/calibration.md](references/calibration.md) — калибровка инъекцией, вердикты keep/retune/drop.