init заводит openspec сам; конфиг стал слотом канона

Каталог openspec/ был предпосылкой, о которой канон говорил, но за которой не
следил. openspec/specs/ объявлен домом темы requirements, config.yaml описан
абзацем — а заводилось всё руками, и не проверялось ничего. Новый проект выходил
из init с полным каноном документов и без каталога, без которого не работают ни
opsx:propose, ни ревью дизайна, ни сверка требований.

Теперь init делает openspec init --tools claude шагом 3, до первого документа, а
adopt заводит его тем же способом, если на переводимом проекте его нет. Команда
названа поимённо в трёх местах — скилле, каноне и отказе docs.py: отказ без
команды заставляет искать её в другом месте.

Файл из коробки оказался хуже отсутствующего, и потому проверяется машиной.
openspec init кладёт config.yaml, где context и rules — закомментированный пример
на английском. Такой файл читается как настроенный: он есть, он валиден, имя
правильное. Работает он как пустой, и узнаётся это по уже написанному
предложению — на другом языке, с capability по имени пакета, без единого SHALL.
docs.py проверяет четыре вещи, каждая про молчащий пробел: каталог есть; имя
именно config.yaml (config.yml OpenSpec не читает и об этом не сообщает); context
и rules.specs не остались примером, а правила называют SHALL; context называет
passport и CLAUDE.md. Последние два обязательны по порядку работы: предложение
пишется до того, как кто-либо откроет docs/, и без этих строк его пишут, не зная
ни границы домена, ни инвариантов.

Форма конфига записана скелетом и сформулирована разрезом: утверждение, которое
можно опровергнуть, открыв другой файл проекта, — пересказ; строка, которая
говорит, какой файл открыть, — ссылка. Машина этот разрез не проверяет, отличить
одно от другого она не умеет; он отдан doc-consistency отдельным абзацем правила
«один факт — один дом», и config.yaml добавлен ему во вход. Место второго дома
там самое частое: context читается при порождении каждого артефакта, туда удобно
дописать «чтобы агент знал», и так заводятся копии инвариантов, конвенций,
состава гейта и правил ревью.

Образец лёг в канон, а не в конвейер, как планировало решение C: форма документа
принадлежит владельцу канона документов, конвейер её читатель. Иначе
av-dev-pipeline завёл бы описание файла, который заводит и проверяет av-dev-pm.

Канон повышен до версии 7 с записью, выполнимой upgrade: завести openspec,
привести config.yaml к скелету, вычистить из context пересказ, проверить имя
файла, поднять номер в .pm.json. Проверка прогнана на четырёх фикстурах — свежий
openspec init, два живых проекта и пустой каталог; отличает все четыре случая.
Решение — 47.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

av-dev-pm/skills/canon/SKILL.md

@@ -136,20 +136,25 @@ capability), `openspec/config.yaml`.
 1. `docs/.pm.json` с `{"canon": <текущая версия>}` и путём миграций, если БД есть;
 2. каталоги канона и скелет **по [references/skeletons.md](references/skeletons.md)**:
    незаполненное — одной честной информативной строкой, а не «TBD»;
-3. переносы содержимого;
-4. каталог задач — **вызови скилл `av-dev-pm:tasks`**, сценарий адаптации: он
+3. **OpenSpec, если его нет** — `openspec init --tools claude`, и `config.yaml`
+   по тому же скелету. Каталог есть, а `config.yaml` из коробки — тот же случай,
+   что отсутствие: закомментированный пример выглядит настройкой и не является
+   ею. Пересказ инвариантов, конвенций и правил ревью из `context` вычисти
+   ссылкой на дом — на переводимом проекте он там почти наверняка есть;
+4. переносы содержимого;
+5. каталог задач — **вызови скилл `av-dev-pm:tasks`**, сценарий адаптации: он
    владеет форматом задач. Он же переименует транслитные слаги в английские и
    тем же проходом починит перекрёстные ссылки;
-5. починка ссылок на перенесённое во всём репозитории — `docs/`, `openspec/`,
+6. починка ссылок на перенесённое во всём репозитории — `docs/`, `openspec/`,
    `CLAUDE.md`, `README.md`;
-6. удаление оригиналов — **только тех, чьё содержимое найдено в новом доме**;
-7. **шаг `docs.py check` в гейт проекта.** Путь к скрипту — переменной с
+7. удаление оригиналов — **только тех, чьё содержимое найдено в новом доме**;
+8. **шаг `docs.py check` в гейт проекта.** Путь к скрипту — переменной с
    умолчанием на канонический путь маркетплейса, чтобы переустановка плагина не
    меняла `Taskfile`; шаг обязан **краснеть внятно**, если скрипт не найден, а не
    пропускаться. Передай ему базу диффа (`--base`) той же переменной, что и
    остальным шагам гейта: без неё сверка миграций со схемой не гоняется вовсе.
    Пример строки покажи человеку — гейт принадлежит проекту, и правит его он;
-8. `docs.py check` — до **отсутствия дрейфа раскладки**. Замечания
+9. `docs.py check` — до **отсутствия дрейфа раскладки**. Замечания
    (незаполненные плейсхолдеры, слабое упоминание capability) остаются:
    незаполненный канон это объявленное переходное состояние из шага 5, а не
    отказ. **Пункт «задачи без цели» из вложенной проверки `tasks.py` тоже