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/references/canon.md

@@ -1,6 +1,6 @@
 # Канон документов проекта
 
-**Версия 6.**
+**Версия 7.**
 
 Это **единственный дом определения канона**. Скиллы `init`, `canon` и `docs`
 читают его, а не пересказывают: три описания одной раскладки разъедутся, и
@@ -106,6 +106,7 @@ openspec/
 | `database.*` | источник | `operations` — схема и настройки с числами |
 | `CLAUDE.md`, `AGENTS.md` | источник | `autotests` (семантика гейта); инварианты — сквозные |
 | `openspec/specs/` | источник | `requirements` |
+| `openspec/config.yaml` | процессный | — (настройка порождения артефактов, слой **до** тем) |
 | `tasks/` | процессный | — |
 | `review.*` | процессный | — (настройка самого конвейера, слой **над** темами) |
 | `adr.*` | процессный | — |
@@ -411,10 +412,40 @@ kebab-case.** Причина не эстетическая: имя файла с
 ### `openspec/config.yaml`
 
 **Только нужды генерации артефактов** — язык, правила именования capability,
-придирки валидатора RFC 2119 — плюс ссылки на документы канона. Правило ревью,
+придирки валидатора RFC 2119 — плюс **адреса** документов канона. Правило ревью,
 пересказ конвенций и инварианты сюда не пишутся: у них есть свои дома, и второй
 дом разойдётся на первой же правке.
 
+**Каталог `openspec/` — часть канона, а не соседняя технология.** В нём дом темы
+`requirements`, и заводится он командой: `openspec init --tools claude`. Её
+выполняет `init` на новом проекте и `adopt` на переводимом; из канона она названа
+поимённо потому, что её печатает отказ `docs.py`, а отказ без команды заставляет
+искать её в другом месте.
+
+**Файл из коробки настройкой не является.** `openspec init` кладёт `config.yaml`,
+где и `context`, и `rules` лежат закомментированным примером. Такой файл читается
+как настроенный — он есть, он валиден, у него правильное имя, — а работает как
+пустой: предложение пишется без языка, без правил именования capability и без
+знания, где лежит граница домена. Это ровно тот класс, против которого написан
+весь канон, и потому здесь он проверяется машиной, а не чтением.
+
+Проверяется четыре вещи, и каждая — про молчащий пробел, а не про вкус:
+
+1. **`openspec/` есть.** Нет — нет и дома темы `requirements`.
+2. **Имя файла `config.yaml`.** `config.yml` OpenSpec не читает и об этом не
+   сообщает: настройка, написанная в файл с таким именем, пропадает целиком.
+3. **`context` и `rules.specs` не остались примером.** Правила для `specs`
+   обязаны называть `SHALL`: требование без этого литерала валидатор отвергает.
+4. **`context` называет `passport` и `CLAUDE.md`.** Предложение пишется **до**
+   того, как кто-либо откроет `docs/`; без этих двух адресов его пишут, не зная
+   ни границы домена, ни инвариантов.
+
+Пятого — «нет ли здесь пересказа» — машина не проверяет: отличить ссылку от
+пересказа она не умеет. Это работа `doc-consistency`, и раздел «Что проверяет
+машина, а что человек» называет её строкой.
+
+Форма — [skeletons.md](skeletons.md).
+
 ## Правило единственного дома
 
 Факт живёт ровно в одном файле; остальные ссылаются. Карта на случай спора:
@@ -482,6 +513,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 | маркеры долга — числом | **протухший факт, разошедшийся с кодом** | `doc-code-drift` |
 | миграция изменена, а `database.md` нет | зависимость в манифесте, не названная в обзоре | `doc-code-drift` |
 | capability без упоминания в `architecture.md` | второй способ там, где обзор обещал единственный | `doc-code-drift` |
+| `openspec/config.yaml`: имя, `schema`, незаменённый пример, адреса паспорта и `CLAUDE.md` | **пересказ документа канона в `context` вместо ссылки** | `doc-consistency` |
 | | связность и читаемость | `doc-wording` |
 
 **Агентов двое, и разведены они по глубине, а не по охвату.** `doc-consistency`
@@ -507,7 +539,7 @@ kebab-case.** Причина не эстетическая: имя файла с
 
 ```json
 {
-  "canon": 6,
+  "canon": 7,
   "migrations": "internal/store/migrations",
   "tasks": {
     "backlog": "INDEX.md"

av-dev-pm/skills/canon/references/changelog.md

@@ -13,6 +13,62 @@ upgrade` идёт по записям снизу вверх от версии п
 
 ---
 
+## Версия 7 — 2026-08-07
+
+`openspec/` был предпосылкой, о которой канон говорил, но за которой не следил.
+Каталог назван в раскладке, `openspec/specs/` объявлен домом темы `requirements`,
+`config.yaml` описан абзацем — а заводил всё это человек руками, и проверялось
+из перечисленного ничего. Заведение нового проекта проходило мимо: `init`
+собирал документы канона и оставлял проект без каталога, без которого не работают
+ни `opsx:propose`, ни ревью дизайна, ни сверка требований.
+
+Хуже отсутствия оказался файл из коробки. `openspec init` кладёт `config.yaml`,
+где `context` и `rules` — закомментированный пример на английском. Такой файл
+читается как настроенный: он есть, он валиден, имя правильное. Работает он как
+пустой, и узнаётся это по предложению, написанному на другом языке, с
+capability по имени пакета и без единого `SHALL`.
+
+**Что изменилось:**
+
+1. **`init` заводит OpenSpec сам** — `openspec init --tools claude`, до первого
+   документа канона. Команда названа в каноне поимённо, потому что её печатает
+   отказ `docs.py`.
+2. **У `openspec/config.yaml` появилась каноническая форма** и скелет в
+   `skeletons.md`. Содержание — только то, что нужно **в момент порождения
+   артефакта**: язык, правила именования capability, придирки валидатора и
+   **адреса** документов канона. Пересказ паспорта, инвариантов, конвенций и
+   правил ревью в него не переносится.
+3. **`docs.py check` проверяет четыре вещи:** каталог `openspec/` есть; файл
+   называется `config.yaml` (`config.yml` OpenSpec читать не станет и об этом не
+   сообщит); `context` и `rules.specs` не остались примером, а правила для
+   `specs` называют `SHALL`; `context` называет `passport` и `CLAUDE.md`.
+4. **Пятое проверяет агент.** Отличить ссылку на документ от пересказа документа
+   машина не умеет — это работа `doc-consistency`, и в таблице «Что проверяет
+   машина, а что человек» она стоит строкой.
+
+**Что переехало:** ничего в раскладке `docs/`. Ни один файл не переименовывается
+и не перемещается.
+
+**Что сделать проекту:**
+
+1. Нет `openspec/` — завести: `openspec init --tools claude`. Команда кладёт ещё
+   и `.claude/skills/openspec-*` с `.claude/commands/opsx/*`; это её нормальная
+   работа, удалять их не надо.
+2. Открыть `openspec/config.yaml` и привести к скелету из
+   [skeletons.md](skeletons.md): блок `context` с языком, правилами именования
+   capability, требованием `SHALL` и **адресами** `docs/passport.md` и
+   `CLAUDE.md`; блок `rules` с четырьмя правилами для `specs`.
+3. **Вычистить из `context` пересказ.** Инварианты, перечень конвенций, состав
+   шагов гейта, правило выбора метки и состав проходов ревью — заменить ссылкой
+   на дом. Признак пересказа простой: строку можно опровергнуть, открыв другой
+   файл проекта.
+4. Проверить имя файла: `config.yml` переименовать в `config.yaml`. Если жили оба
+   — содержимое `.yml` до сих пор не читалось никем, и переносить из него нужно
+   именно то, чего нет в `.yaml`.
+5. `docs/.pm.json`: `"canon": 7`.
+
+---
+
 ## Версия 6 — 2026-08-07
 
 Версия 5 объявила: **каждый документ `docs/` — тема ревью**. Правило оказалось

av-dev-pm/skills/canon/references/skeletons.md

@@ -417,11 +417,84 @@ severity стоит здесь, а не выводится каждым прох
 тронуть рабочие данные, без третьего вся шкала ранжирования триажа держится на
 догадке.
 
+## `openspec/config.yaml`
+
+Каталог `openspec/` заводится командой — `openspec init --tools claude`, — и она
+кладёт `config.yaml` с закомментированным примером внутри. Пример **заменяется
+целиком**: нетронутый файл выглядит настроенным, а работает как пустой.
+
+**Это маршрутизатор, а не второй дом фактов.** Сюда пишут ровно то, что нужно
+**в момент порождения артефакта** и чего в этот момент ещё никто не открыл:
+язык, правила именования capability, придирки валидатора и **адреса** документов
+канона. Пересказ паспорта, инвариантов, конвенций и правил ревью сюда не
+переносится: расходится он молча, а замечают это в уже написанном предложении.
+
+```yaml
+schema: spec-driven
+
+context: |
+  Language: Russian
+  Пиши на русском, но:
+  - Структурные заголовки оставляй на английском:
+    ## ADDED/MODIFIED/REMOVED Requirements, ### Requirement:, #### Scenario:
+  - Ключевые слова GIVEN/WHEN/THEN и RFC 2119 (SHALL/MUST/SHOULD) — на английском
+  - Технические термины, пути и код — на английском
+
+  Имена capabilities:
+  - Capability — это ПОВЕДЕНИЕ или домен системы, а не пакет кода (совпадение с
+    именем пакета допустимо, но не критерий).
+  - Существительное, понятное без знания кода: ingest, parsing, storage,
+    read-api. НЕ store/httpapi — это реализация.
+  - Гранулярность по принципу «требования меняются вместе». Дробить, когда в
+    одной спеке смешиваются разные заботы. Переименовать дёшево (RENAMED
+    Requirements) — не дроби преждевременно в маленьком проекте.
+
+  RFC 2119 — требование валидатора, не стиль:
+  - Каждое ### Requirement ОБЯЗАНО содержать литерал SHALL или MUST, иначе
+    `openspec validate` падает. Поэтому эти слова и WHEN/THEN не русифицируем.
+
+  Что это за проект — читай перед предложением, а не отсюда:
+  - docs/passport.md — цель, её граница (чем проект НЕ является), потребители,
+    типовые сценарии, референсы;
+  - CLAUDE.md — инварианты с severity и семантика гейта;
+  - docs/architecture.md — устройство; docs/security.md — периметр;
+    docs/adr/ — почему решено так; docs/research/ — что уже измерено.
+  Пересказа этих документов здесь нет намеренно: второй дом факта расходится с
+  первым молча, и заметно это становится в предложении, которое уже написано.
+
+  Ревью: правило выбора метки и состав проходов здесь не пересказываем — их дом
+  скилл av-dev-pipeline:review-pipeline, проектная настройка — docs/review.md.
+
+  Конвенции кода: механизированное проверяет гейт, прозой остаётся
+  docs/conventions/. Ни состав шагов гейта, ни перечень конвенций здесь не
+  пересказываем: и то и другое растёт по ходу задач.
+
+  Развилка или блокер — сперва prior art. Готовые решения смотрим в референсах
+  паспорта, отвергаем — с названной причиной, и причина идёт в design.md этого
+  же изменения.
+
+rules:
+  proposal:
+    - Capabilities называй по поведению или домену системы, не по пакету кода
+  specs:
+    # Кавычки обязательны: без них YAML обрежет строку на первом '#'.
+    - "Каждое ### Requirement обязано содержать SHALL или MUST (иначе валидация падает)"
+    - "Сценарий — ровно #### (четыре решётки); три или список молча теряются"
+    - "SHALL/MUST должно стоять в ПЕРВОМ абзаце требования: валидатор смотрит только его"
+    - "Заголовки и WHEN/THEN/GIVEN — на английском, остальной текст на русском"
+```
+
+**Четыре правила для `specs` сняты отказами валидатора, а не выведены из
+документации** — потому и записаны дословно: без них каждое второе предложение
+узнаёт их падением `openspec validate --strict`. Блок `context` проект
+дополняет своим (стек, разведка, особенности домена), но **адреса паспорта и
+`CLAUDE.md` обязательны** — их отсутствие `docs.py check` называет отказом.
+
 ## `docs/.pm.json`
 
 ```json
 {
-  "canon": 6
+  "canon": 7
 }
 ```