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.

av-dev-pipeline/skills/review-pipeline/references/project-facts.md

@@ -5,10 +5,10 @@
 выдаёт правдоподобные общие места: их дорого опровергать и нечем подтверждать.
 
 Отдельного файла-брифа **нет**. Проектная конкретика живёт в документах канона
-`av-dev-pm`, и проход читает их напрямую: пути жёсткие, посредник не нужен, а
+`av-dev-docs`, и проход читает их напрямую: пути жёсткие, посредник не нужен, а
 второй дом для тех же фактов разошёлся бы и выглядел актуальным.
 
-Определение канона — в плагине `av-dev-pm`,
+Определение канона — в плагине `av-dev-docs`,
 `skills/canon/references/canon.md`. Здесь только карта «тема → её дом → что
 оттуда берётся».
 
@@ -119,7 +119,7 @@
 строка неотличима от «мы просто не стали» и перестаёт читаться на третьей задаче.
 
 **Документов канона нет вовсе** — проект не приведён к канону. Это не повод
-работать вслепую: скажи об этом строкой и предложи `av-dev-pm:canon`. Одна
+работать вслепую: скажи об этом строкой и предложи `av-dev-docs:canon`. Одна
 операция на проект против деградации на каждой задаче.
 
 ## Правило чтения

av-dev-pipeline/skills/review-pipeline/references/review-journal.md

@@ -1,7 +1,7 @@
 # Журнал дефектов
 
 Артефакт проекта, а не плагина: файл живёт в репозитории — **`docs/review.md`**,
-слот канона `av-dev-pm`. Здесь описано, зачем он и какой формы, потому что без
+слот канона `av-dev-docs`. Здесь описано, зачем он и какой формы, потому что без
 него конвейер не учится: находки закрываются, а почему их не поймали — забывается,
 и один и тот же класс проскакивает второй раз.
 
@@ -41,7 +41,7 @@
 ## Форма записи
 
 **Это дом формы, и у него есть копия.** Скелет `docs/review.md`, который кладёт
-в проект `av-dev-pm` (`skills/canon/references/skeletons.md`), повторяет её
+в проект `av-dev-docs` (`skills/canon/references/skeletons.md`), повторяет её
 дословно — он уезжает в репозиторий и обязан там что-то говорить. Правка формы
 здесь **обязана** тянуть правку скелета и запись в журнал версий канона; иначе
 проекты продолжат писать по старой форме, а конвейер — ждать поля, которого нет.

av-dev-pipeline/skills/review-pipeline/references/review-levels.md

@@ -94,7 +94,7 @@
 костяк — гейт, спеки, код, триаж**. Разрезать задачу, обе половины которой
 остаются в одной метке, значит заплатить костяк дважды за ту же проверку.
 Резать стоит там, где разрез **снимает доказательство с большей части диффа**.
-Шов и правило нарезки живут у того, кто ведёт задачи, — скилл `av-dev-pm:tasks`,
+Шов и правило нарезки живут у того, кто ведёт задачи, — скилл `av-dev-tasks:tasks`,
 его `references/split.md`. Пути туда конвейер не выносит: за пределы своего
 плагина он ходит вызовом скилла, а не файлом.
 

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

@@ -28,7 +28,7 @@ description: Проводит несколько задач разом — пл
   проход `review-specs` финальной сверки. Проекта без OpenSpec это касается так
   же, как одиночного пайплайна (см. его раздел «Предпосылки»).
 - **Скиллы зовутся с пространством имён**: `av-dev-pipeline:task-pipeline`,
-  `av-dev-pipeline:review-pipeline`, `av-dev-pm:tasks`. Короткое имя
+  `av-dev-pipeline:review-pipeline`, `av-dev-tasks:tasks`. Короткое имя
   может разрешиться в устаревшую проектную копию, и это произойдёт молча — в
   charter'е сабагента пиши полное имя, он твоего контекста не видит.
 - **Проектные копии этих скиллов и агентов при установке плагина удаляются.**
@@ -39,7 +39,7 @@ description: Проводит несколько задач разом — пл
 `docs/database.md` и `docs/.pm.json` (ключ `migrations`).
 
 **Документов канона нет — проект к нему не приведён.** Скажи это строкой и
-предложи `av-dev-pm:canon` **до первой задачи**: иначе каждая задача батча
+предложи `av-dev-docs:canon` **до первой задачи**: иначе каждая задача батча
 заплатит поразрядной деградацией ревью, а имя основной ветки придётся
 угадывать.
 
@@ -52,7 +52,7 @@ description: Проводит несколько задач разом — пл
   же трёх словах, что и `task-pipeline`: сделана / не доведена / оказалась крупнее
   задачи.
 - **Задачи закрывает пайплайн внутри каждого сабагента**, шагом 12 — после
-  коммита работы и **отдельным коммитом учёта**, вызовом Skill `av-dev-pm:tasks`.
+  коммита работы и **отдельным коммитом учёта**, вызовом Skill `av-dev-tasks:tasks`.
   Батч сам записей учёта не трогает: он не знает, чем кончилась приёмка, и
   дублировать закрытие ему незачем. Но грязное дерево после сабагента — **его**
   проблема: на нём откажут и `rebase`, и `worktree remove` (см. шаг 6). Урожай ревью батч
@@ -88,7 +88,7 @@ description: Проводит несколько задач разом — пл
 ### 1. Прочитать набор
 
 Набор задан списком (слаги, файлы, описания) — прочитай файл каждой задачи и
-связанные спеки и черновики. Сырьё (в терминах `av-dev-pm` — запись типа
+связанные спеки и черновики. Сырьё (в терминах `av-dev-tasks` — запись типа
 `research` с пустым разделом «Вопрос») включается, но помни: сабагент проведёт
 его сперва через `opsx:explore`, это тяжелее и чаще упирается в вопрос.
 

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

@@ -23,7 +23,7 @@ description: "Автономно проводит одну задачу чере
   вырождай цикл: ветка деградации здесь не пишется, потому что непроверенная
   ветка деградации хуже честного отказа.
 - **Скиллы зовутся с пространством имён** — `av-dev-pipeline:review-pipeline`,
-  `av-dev-pm:docs`, `av-dev-pm:tasks`. Короткое имя может разрешиться в
+  `av-dev-docs:docs`, `av-dev-tasks:tasks`. Короткое имя может разрешиться в
   устаревшую проектную копию, и это произойдёт молча.
 - **Проектные копии этих скиллов и агентов удаляются при установке плагина**
   (`.claude/skills/` — и голые имена `task-pipeline`, `review-pipeline`,
@@ -34,11 +34,11 @@ description: "Автономно проводит одну задачу чере
 
 Перед стартом прочитай `CLAUDE.md` проекта и то, на что он ссылается, если ещё
 не в контексте. Проектные факты, нужные ревью — инварианты, семантика гейта,
-объёмы, модель угроз, прецеденты, — живут в **документах канона** `av-dev-pm`;
+объёмы, модель угроз, прецеденты, — живут в **документах канона** `av-dev-docs`;
 карта «что где» — `references/project-facts.md` конвейера ревью.
 
 **Документов канона нет — проект к нему не приведён.** Скажи это строкой и
-предложи скилл `av-dev-pm:canon`: одна операция на проект против поразрядной
+предложи скилл `av-dev-docs:canon`: одна операция на проект против поразрядной
 деградации на каждой задаче. Работу при этом не останавливай.
 
 ## Границы: чем пайплайн не владеет
@@ -47,12 +47,12 @@ description: "Автономно проводит одну задачу чере
   её не выбирает, не приоритизирует, не заводит и не переоценивает; если в
   проекте есть свой процесс управления задачами — он и решает, что брать.
 - **Форматом задач.** Пайплайн **не правит индексы руками и не выдумывает путь
-  к скрипту учёта**: он зовёт Skill `av-dev-pm:tasks`, который этим владеет
+  к скрипту учёта**: он зовёт Skill `av-dev-tasks:tasks`, который этим владеет
   (шаг 12). Закрытие как таковое — его работа, и это осознанное решение с
   названной ценой: **приёмщик и исполнитель совпали**. Закрытие поэтому **не
   окончательно** — человек на сессии возвращает задачу `reopen` с причиной, а
   доклад по критериям приёмки становится единственным, по чему приёмка вообще
-  возможна. Плагина `av-dev-pm` в проекте нет — вызов не разрешится, и тогда
+  возможна. Плагина `av-dev-tasks` в проекте нет — вызов не разрешится, и тогда
   учёт остаётся владельцу, о чём говорится в докладе.
 - **Заведением задач из урожая ревью.** Отложенные находки отдаются **списком**
   (см. шаг 8); превращать их в задачи — работа того, кто ведёт задачи проекта.
@@ -113,7 +113,7 @@ description: "Автономно проводит одну задачу чере
    в объявленных границах.
 
 **Что остатком не является — правило живёт не здесь.** Канонический текст с обеими
-оговорками — в плагине `av-dev-pm`, скилл `av-dev-pm:session`, раздел
+оговорками — в плагине `av-dev-tasks`, скилл `av-dev-tasks:session`, раздел
 `## Вопрос, блокер, необратимое`, подраздел «Отличать вопрос от застревания».
 Правило принадлежит управлению задачами, потому что решает **сделана задача или
 вышла**, — это исход планирования, а не исполнения. **Ссылайся, не
@@ -126,7 +126,7 @@ description: "Автономно проводит одну задачу чере
 Оба порога — стоп: первый поднимает решение до начала записи, второй даёт исход
 «не доведена».
 
-Плагин `av-dev-pm` не подключён — правило не отменяется, а становится
+Плагин `av-dev-tasks` не подключён — правило не отменяется, а становится
 осторожнее: прежде чем записать зависящее от нерешённого куда бы то ни было —
 в хранилище, в журнал, в витрину или наружу, — спрашивай человека.
 
@@ -164,9 +164,9 @@ flowchart TD
     s7["7. opsx:apply — код, гейт, поведенческая верификация"]
     s8["8. ревью кода, состав по той же метки"]
     s9["9. opsx:archive"]
-    s10["10. синк документации — av-dev-pm:docs"]
+    s10["10. синк документации — av-dev-docs:docs"]
     s11["11. коммит работы — av-dev-git:commit"]
-    s12["12. закрыть задачу — av-dev-pm:tasks,<br/>вторым коммитом учёта"]
+    s12["12. закрыть задачу — av-dev-tasks:tasks,<br/>вторым коммитом учёта"]
 
     s1 --> triv
     s1 -.-> big
@@ -383,7 +383,7 @@ change `<id>`, **план разметки с шага 4** и указание,
 
 ### 10. Синк документации
 
-Ревью выполненного — до этого шага. Затем **вызови Skill `av-dev-pm:docs`**: он
+Ревью выполненного — до этого шага. Затем **вызови Skill `av-dev-docs:docs`**: он
 владеет содержимым документов канона и ведёт чек-лист синка. Плагина нет — шаг
 всё равно делается, см. ниже.
 
@@ -394,17 +394,17 @@ change `<id>`, **план разметки с шага 4** и указание,
 работает только обязательное отрицание.
 
 **Список документов и их триггеров здесь не дублируется** — он в чек-листе
-скилла `av-dev-pm:docs`, и копия уже однажды разошлась с оригиналом, потеряв два
+скилла `av-dev-docs:docs`, и копия уже однажды разошлась с оригиналом, потеряв два
 триггера.
 
-**Плагина `av-dev-pm` в проекте нет** — путь в его дерево не разрешится ниоткуда,
+**Плагина `av-dev-docs` в проекте нет** — путь в его дерево не разрешится ниоткуда,
 поэтому за списком иди в **свой** reference:
 [references/project-facts.md](../review-pipeline/references/project-facts.md)
 конвейера ревью перечисляет все документы канона с их предметом. Пройди по этому
 перечню — каждый документ получает строку, отрицание остаётся обязательным.
 Триггеры при этом ты знаешь хуже, и это называется в докладе строкой: «синк
-сделан по перечню документов, без списка триггеров — плагина `av-dev-pm` нет».
-Канона в проекте тоже нет — назови это исходом и предложи `av-dev-pm:canon`.
+сделан по перечню документов, без списка триггеров — плагина `av-dev-docs` нет».
+Канона в проекте тоже нет — назови это исходом и предложи `av-dev-docs:canon`.
 
 ### 11. Коммит
 
@@ -419,7 +419,7 @@ change `<id>`, **план разметки с шага 4** и указание,
 
 ### 12. Закрыть задачу — **после коммита, не раньше**
 
-**Вызови Skill `av-dev-pm:tasks`** и попроси закрыть задачу как реализованную —
+**Вызови Skill `av-dev-tasks:tasks`** и попроси закрыть задачу как реализованную —
 он владеет форматом и двигает строку из набора спринта сам. Путь к его скрипту не
 выясняй и индексы руками не правь: мост между плагинами — вызов скилла, а не
 путь.
@@ -428,7 +428,7 @@ change `<id>`, **план разметки с шага 4** и указание,
 оставило бы задачу закрытой без единого следа работы, если шаг 11 упадёт.
 
 **Закрытие тоже коммитится — вторым коммитом, тут же.** Удаление файла задачи и
-правка индексов (их имена знает `av-dev-pm`, не ты) — это правки в рабочем
+правка индексов (их имена знает `av-dev-tasks`, не ты) — это правки в рабочем
 дереве, и оставить их незакоммиченными нельзя по трём причинам: `task-batch` следом делает `rebase`
 и `worktree remove`, а те откажут на грязном дереве; закрытие, не доехавшее до
 основной ветки, оставит задачу открытой молча; и опора «набор спринта под git