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-tasks/skills/tasks/references/task-chore.md

@@ -0,0 +1,60 @@
+# 🧹 `chore` — обслуживание, наблюдаемое поведение не меняется
+
+Зависимости, сборка, перенос, чистка, оснастка. Отвечает на **«что нужно
+сделать»**, глаголом в неопределённой форме.
+
+Общая форма записи (мета, слаг, строка индекса) — [task-format.md](task-format.md).
+Здесь только то, что у этого типа своё.
+
+## Схема
+
+| | |
+| --- | --- |
+| Заголовок отвечает на | что нужно сделать |
+| Обязательные разделы | `Затрагивает`, `Критерии приёмки` |
+| Допустимые сверх того | `Рамки`, `Вопросы` |
+| Поле места | **Категория** — полка домена беклога |
+| Цель (`goal:<слаг>`) | нет: цель — это возможность, а здесь её не появляется |
+| Индекс | `BACKLOG.md` → `SPRINT.md` |
+| Берётся в спринт | да |
+
+## Адресат — разработчик, и это законно
+
+Тест готовности спрашивает «что станет наблюдаемо иначе». У `chore` ответ
+адресован **разработчику**, а не пользователю: «перестанет собираться два раза»,
+«уедет последний вызов устаревшего API», «проверки гоняются одной командой».
+Это ответ, а не отговорка.
+
+**У `chore` тест готовности слабее честно, а не молча.** Пока типа не было,
+такие задачи либо не заводились вовсе, либо формулировались как выдуманная
+пользовательская польза — и то и другое хуже, чем сказать прямо, для кого работа.
+
+Отсюда же граница: если после задачи меняется то, что видит пользователь, — это
+не `chore`. Тип, оставшийся от первой формулировки, врёт ровно там, где по нему
+отбирают.
+
+## Алгоритм
+
+1. **Проверить, что поведение не меняется.** Меняется — это `feature` или `fix`,
+   и у неё другие требования (цель, воспроизведение).
+2. **Назвать, что перестанет мешать** — одной фразой, адресуясь разработчику.
+   «Прибраться в модуле X» — не ответ: непонятно, что изменится.
+3. **Назвать границы** в `Затрагивает`. У обслуживания они часто не в коде:
+   конфиг и его образцы, версия зависимости, команда сборки, файл CI. Границей
+   считается то, у чего есть внешняя сторона и цена изменения.
+4. **Написать критерии приёмки** — 2–5 утверждений с оракулами. У `chore`
+   оракул обычно самый дешёвый из всех типов: команда, которая раньше падала
+   или требовала трёх шагов, теперь отрабатывает одним.
+5. **Проверить, что это не «заодно».** Обслуживание любит склеиваться в пачку
+   («обновить зависимости и переписать сборку и убрать мёртвый код»). Не
+   мерджится порознь — это несколько задач ([split.md](split.md)).
+6. **Цель не проставлять.** `chore` служит работоспособности, а не направлению,
+   и в набор спринта входит помимо его цели. Работа по сопровождению проекта
+   при этом видна в роадмапе — секцией `Сопровождение`, но целью не становится.
+
+## Что видит машина, а что человек
+
+`check` и `sprint take` смотрят на **наличие непустого** `Затрагивает` и на
+**число** критериев — ровно то же, что у `feature`. Разница между типами здесь не
+в строгости проверки, а в том, **кому адресован ответ** на «что станет
+наблюдаемо иначе», — и это судит человек.