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/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