документация: README, TODO и журнал решений знают про один плагин

README переписан под два плагина: состав скиллов с префиксами, диаграмма одним контуром, команды установки и обновления, раздел версий про .av-dev.toml. Правка про копии сказала главное — копия была платой за неразрешимый путь, а не за важность правила, и внутри одного дерева остаётся только там, где текст обязан лежать в промпте. DECISIONS: тема 64 с замером цены раскола и четырьмя следствиями. Довод «а вдруг понадобится» снят наблюдением: режим, ради которого раскол держали, покрыт сценарием обслуживания.
2026-08-13 10:33:44 +03:00
parent 95c9499f06
commit a00e132f29
3 changed files with 227 additions and 147 deletions
@@ -3919,3 +3919,64 @@ change по нему не будет никогда, — и такое реше
     когда весь материал для неё у исполнителя. Стоп обязан принести названный
     тип, объяснение и закрытый список решений — иначе выбор делается вслепую или
     не делается вовсе, и работа доезжает до коммита не тем процессом.
+
+
+## 64. Три плагина слились в один: раскол платили, а не пользовались (2026-08-13)
+
+Плагинов было три — `av-dev-docs`, `av-dev-tasks`, `av-dev-code`, — и разрез
+между ними шёл по признаку «ставится порознь» (решение 51). Признак был выбран
+верно, но **посылка под ним не проверялась**: за всё время подмножество не
+понадобилось ни разу, а платился раскол постоянно.
+
+Цена измерена, а не оценена: шестьдесят с лишним кросс-вызовов при цикле
+зависимостей `docs → code → docs`, язык проектных текстов четырьмя помеченными
+копиями по 213 строк, словарь сопровождения двумя, правило границы семью,
+дюжина веток «плагина нет» — и `copies.py`, заведённый ровно затем, чтобы это
+не разъезжалось молча.
+
+**Довод «а вдруг понадобится» снят наблюдением владельца, а не спором.** Ждали
+случая «документы и задачи без OpenSpec» — например, ansible-репозиторий. Он
+уже покрыт: сценарий обслуживания в `resolve` OpenSpec не требует по
+построению, а `docs.py` считает отсутствие `openspec/` неприменимостью, а не
+отказом. То есть режим, ради которого держали раскол, работает и в слитом
+плагине.
+
+**Слияние оказалось дешевле, чем выглядело, потому что граница была сделана
+правильно.** Присутствие соседа узнавалось **следом в проекте**
+(`.docs.json`, `.tasks.json`, `openspec/config.yaml`), а не перечнем
+установленных плагинов. Значит мягкость поведения держалась на состоянии
+проекта и пережила слияние без единой правки логики: сменилась упаковка, а не
+механика. Дом правила переехал из `plugin-boundary.md` в `absence.md` и стал
+говорить о том, чем он и был на деле, — о частях раскладки, которых может не
+быть.
+
+**Версия стала одна и начинается с 1.** Две версии — канон 14 и формат задач 1 —
+двигались порознь, потому что порознь ставились плагины; с одним плагином два
+числа означали бы только вопрос, по какому журналу повышать. Прежние журналы
+закрыты и не переписаны: адрес, верный на день записи, остаётся свидетельством.
+Служебный файл один, `.av-dev.toml` в корне репозитория, и **формат выбран ради
+комментариев** — файл живёт в чужом репозитории, и назначение числа должно
+читаться из него самого, а не из документации плагина. Отсюда правило записи:
+скрипт правит строку, а не переписывает файл.
+
+**Опцион не потерян.** Понадобится инфраструктурный плагин — расколоть обратно
+будет переименованием пространства имён, а не переделкой: граница по-прежнему
+держится на следе в проекте. Платить за этот опцион копиями сегодня незачем.
+
+### Что из этого следует
+
+218. **Разрез, оправданный сценарием, обязан этот сценарий однажды увидеть.**
+     «Ставится порознь» — проверяемое утверждение, и проверяется оно не
+     рассуждением, а тем, поставил ли кто-нибудь половину. Пока не поставил,
+     разрез оплачивается копиями за случай, которого нет.
+219. **Механика, привязанная к состоянию проекта, переживает перестановку
+     плагинов; привязанная к их составу — нет.** Это и есть практическая разница
+     между «узнаём следом» и «узнаём перечнем», и обнаруживается она только на
+     слиянии или расколе.
+220. **Копия дословного текста — плата за неразрешимый путь, а не за важность
+     правила.** Путь разрешился — копия становится вторым домом без причины.
+     Остаётся она там, где текст обязан лежать внутри промпта: устав агента и
+     скелет, уезжающий в проект.
+221. **Формат служебного файла выбирается по тому, кто его читает.** Читает
+     человек в чужом репозитории через полгода — значит комментарии, значит
+     TOML, значит построчная правка вместо перезаписи.
@@ -9,83 +9,98 @@

 ## Плагины

- **av-dev-docs** — документация проекта. Владеет `docs/` и `CLAUDE.md`.
-  - `init` — новый проект: интервью по свободному описанию замысла → первичная
-    документация;
-  - `canon` — привести проект к канону документов: `check` / `adopt` /
-    `upgrade`, плюс скрипт `docs.py`. Там же лежит копия языка проектных
-    текстов — информационный стиль, англицизмы, жаргон; дом у него общий,
-    `shared/language.md`;
-  - `healthcheck` — здоровье документации **судом, а не машиной**: не разошлись
-    ли документы между собой и с кодом. Зовёт двух агентов на весь канон разом —
-    `doc-consistency` (документы между собой и с openspec) и `doc-code-drift`
-    (факты против кода) — и разбирает урожай порциями. Дорого, поэтому не на
-    каждой задаче. Язык документов вычитывает отдельный агент `doc-wording`, и
-    зовут его не отсюда, а те, кто только что писал текст: `docs`, `init` и
-    `canon`;
-  - `docs` — содержимое канона по ходу разработки: ADR из архивного
+Плагина два: **av-dev** — весь процесс, и **av-dev-git** — сообщения коммитов,
+работающие в любом репозитории. До 13 августа 2026 процесс жил тремя плагинами
+(`av-dev-docs`, `av-dev-tasks`, `av-dev-code`); раскол делался под раздельную
+установку, она не понадобилась ни разу, и плагины слились — тема 52
+[DECISIONS.md](DECISIONS.md).
+
+Имя **скилла** несёт префикс прежнего плагина: `doc-`, `task-`, `code-`. Вызов
+выходит вида `/av-dev:<скилл>`.
+
+### av-dev — документы, учёт, работа
+
+**Документы проекта.** Владеют `docs/` и `CLAUDE.md`.
+
+- `doc-init` — новый проект: интервью по свободному описанию замысла →
+  первичная документация;
+- `doc-canon` — привести проект к канону документов: `check` / `adopt` /
+  `upgrade`, плюс скрипт `docs.py`. Он же ведёт журнал версий раскладки —
+  общий, и на документы, и на каталог задач;
+- `doc-healthcheck` — здоровье документации **судом, а не машиной**: не
+  разошлись ли документы между собой и с кодом. Зовёт двух агентов на весь канон
+  разом — `doc-consistency` (документы между собой и с openspec) и
+  `doc-code-drift` (факты против кода) — и разбирает урожай порциями. Дорого,
+  поэтому не на каждой задаче. Язык документов вычитывает отдельный агент
+  `doc-wording`, и зовут его не отсюда, а те, кто только что писал текст:
+  `doc-sync`, `doc-init` и `doc-canon`;
+- `doc-sync` — содержимое канона по ходу разработки: ADR из архивного
  `design.md`, промоут конвенций, запись в разведку и журнал ревью, чистка
  архитектуры.
- **av-dev-tasks** — учёт работ. Владеет каталогом задач.
-  - `tasks` — задачи и цели каталогом markdown-файлов, у каждой записи тип
+
+**Учёт работ.** Владеет каталогом задач.
+
+- `task-track` — задачи и цели каталогом markdown-файлов, у каждой записи тип
  (`goal`, `feature`, `fix`, `chore`, `research`), и тип задаёт её схему;
  вычитывают их два отдельных прохода: `task-form` (форма записи) и
  `task-wording` (язык записей);
-  - `groom` — груминг беклога: что сейчас самое важное и что перестало быть
+- `task-groom` — груминг беклога: что сейчас самое важное и что перестало быть
  важным. Ответ записывается **порядком строк** — приоритет это свойство
  очереди, и живёт он в индексе. Интерактивный: разбирает вопросы пачкой,
-    переоценивает порциями по 5–8, расставляет верх очереди с доводом на
-    каждое движение.
- **av-dev-code** — работа по задачам: разведка, решение и проверка сделанного.
-  Владеет `openspec/`. **Требует OpenSpec и сам его заводит** — кроме сценариев
-  разведки и обслуживания, которым он не нужен.
-  - `openspec` — завести, настроить и **проверить** `openspec/` в проекте:
-    `openspec init`, замена примера в `config.yaml` настройкой канонической
-    формы, скрипт `openspec.py` (форма файла + сверка слепка с живой версией
+  переоценивает порциями по 5–8, расставляет верх очереди с доводом на каждое
+  движение.
+
+**Работа по задачам.** Владеет `openspec/`. **Сценарий решения требует OpenSpec
+и заводит его сам** — разведке и обслуживанию он не нужен.
+
+- `code-openspec` — завести, настроить и **проверить** `openspec/` в проекте:
+  `openspec init`, замена примера в `config.yaml` настройкой канонической формы,
+  скрипт `openspec.py` (форма файла + сверка слепка с живой версией
  инструмента). Каталог принадлежит конвейеру, а не канону: без конвейера он
  проекту не нужен, и `docs.py` о нём молчит;
-  - `resolve` — одна задача от постановки до закрытия. **Точка входа одна, а
+- `code-resolve` — одна задача от постановки до закрытия. **Точка входа одна, а
  сценария три, и выбирает сценарий сам скилл, прочитав постановку:**
  классифицировать задачу до вызова человек всё равно не может — «есть ли
  очевидный способ решения» и «меняется ли спека» видно после чтения записи.
  **Решение** идёт циклом SDD с чекпоинтом после ревью дизайна: объяснение
  человеческим языком, повод скорректировать ход.
  **Обслуживание** (тип `chore`: тулчейн и сборка, зависимости, гит-хуки,
-    перенос, чистка) change не заводит и планового стопа не имеет вовсе: дельта-спек
-    у него нет **по построению**, то есть цикл SDD здесь не урезан, а остаётся без
-    входа. Ревью идёт фиксированным планом без метки и без разметчика — `autotests`
-    и `operations`, плюс `conventions` с техническим разбором, если дифф трогает
-    код; главный шаг сценария — синк документации, потому что обслуживание чаще
-    прочих двигает как раз те факты, которые сверяются с кодом. Правка гейта
-    сверяется по составу проверок, а не по цвету. Нашлась дельта-спека — задача
-    **оказалась шире своего типа**: работа останавливается, тип называется
-    (`fix` или `feature`), человек получает объяснение простым языком и два
-    решения — переформулировать запись и решать её процессом того типа следующим
-    прогоном либо прекратить; «доделать как обслуживание» решением не является.
+  перенос, чистка) change не заводит и планового стопа не имеет вовсе:
+  дельта-спек у него нет **по построению**, то есть цикл SDD здесь не урезан, а
+  остаётся без входа. Ревью идёт фиксированным планом без метки и без
+  разметчика — `autotests` и `operations`, плюс `conventions` с техническим
+  разбором, если дифф трогает код; главный шаг сценария — синк документации,
+  потому что обслуживание чаще прочих двигает как раз те факты, которые
+  сверяются с кодом. Правка гейта сверяется по составу проверок, а не по цвету.
+  Нашлась дельта-спека — задача **оказалась шире своего типа**: работа
+  останавливается, тип называется (`fix` или `feature`), человек получает
+  объяснение простым языком и два решения — переформулировать запись и решать её
+  процессом того типа следующим прогоном либо прекратить; «доделать как
+  обслуживание» решением не является.
  **Разведка** (тип `research`, сырая идея, мутная постановка) кода не пишет
  вовсе: её чекпоинт — варианты, 2–4 способа решить с ценой каждого, — стоит до
-    первого написанного требования, а исход уезжает в документы канона и в
-    задачи. Обе пачки — документы и записи — **вычитываются перед коммитом**
-    своими проходами: `doc-wording` по документам, `task-form` и `task-wording`
-    по записям. Выбранный способ реализуется **следующим прогоном**, и запускает его
+  первого написанного требования, а исход уезжает в документы канона и в задачи.
+  Обе пачки — документы и записи — **вычитываются перед коммитом** своими
+  проходами: `doc-wording` по документам, `task-form` и `task-wording` по
+  записям. Выбранный способ реализуется **следующим прогоном**, и запускает его
  человек: смена сценария по ходу — событие с названным исходом, а не тихий
  поворот. Все три сценария лежат справочниками и одинаково —
  `references/solve.md`, `references/maintain.md` и `references/research.md`; в
-    самом скилле только вход, развилка и правила, не зависящие от сценария.
-    OpenSpec нужен решению, разведке и обслуживанию — нет;
-  - `review` — конвейер ревью **по темам**: документ проекта либо
-    заводит тему проверки, либо питает чужую тему источником, либо процессный и в
-    ревью не читается вовсе. Разметка идёт **один раз на задачу**, сразу после
-    `propose`: агент `review-scope` меряет изменение по двум осям — размер и
-    сложность — и берёт метку как максимум по ним. Одна метка правит **обе**
-    стадии ревью: дизайна (`small` — только сверка спек; `medium` — плюс
-    рубрика; `large` — плюс архитектурный проход) и кода (`small` — гейт, спеки,
-    код, триаж; `medium` — плюс приёмник тем; `large` — плюс доказательство:
-    запуск, замер, построенный путь, 5–10% задач). Десять агентов-проходов.
- **av-dev-git** — `commit`: сообщения в личном стиле.
+  самом скилле только вход, развилка и правила, не зависящие от сценария;
+- `code-review` — конвейер ревью **по темам**: документ проекта либо заводит
+  тему проверки, либо питает чужую тему источником, либо процессный и в ревью не
+  читается вовсе. Разметка идёт **один раз на задачу**, сразу после `propose`:
+  агент `review-scope` меряет изменение по двум осям — размер и сложность — и
+  берёт метку как максимум по ним. Одна метка правит **обе** стадии ревью:
+  дизайна (`small` — только сверка спек; `medium` — плюс рубрика; `large` — плюс
+  архитектурный проход) и кода (`small` — гейт, спеки, код, триаж; `medium` —
+  плюс приёмник тем; `large` — плюс доказательство: запуск, замер, построенный
+  путь, 5–10% задач). Десять агентов-проходов.

-Соглашение об именах: имя **плагина** длинное с префиксом `av-dev-`, имена
-**скилов** внутри — короткие. Вызов выходит вида `/av-dev-<плагин>:<скилл>`.
+### av-dev-git
+
+`commit` — сообщения в личном стиле. Отдельным плагином потому, что нужен и в
+репозитории, который к канону не приведён и никогда не будет.

 Кто кого зовёт. Сплошная стрелка — вызов скилла через пространство имён, не
 импорт; пунктир — совет позвать, а не вызов. Агенты-проходы в графе не показаны:
@@ -93,21 +108,23 @@

 ```mermaid
 flowchart TB
-    subgraph pipe["av-dev-code — исполнение; сценарий решения требует OpenSpec"]
+    subgraph avdev["av-dev — один плагин, девять скиллов"]
+        subgraph pipe["работа по задачам; сценарий решения требует OpenSpec"]
            direction LR
-        tp["resolve<br/>3 сценария: разведка,<br/>решение, обслуживание"] --> rp["review<br/>10 агентов-проходов"]
-        osp["openspec<br/>заводит и проверяет openspec/"]
+            tp["code-resolve<br/>3 сценария: разведка,<br/>решение, обслуживание"] --> rp["code-review<br/>10 агентов-проходов"]
+            osp["code-openspec<br/>заводит и проверяет openspec/"]
        end
-    subgraph docsp["av-dev-docs — документация, владеет docs/"]
+        subgraph docsp["документы, владеют docs/"]
            direction LR
-        init["init"]
-        canon["canon"]
-        docs["docs"]
-        hc["healthcheck"]
+            init["doc-init"]
+            canon["doc-canon"]
+            docs["doc-sync"]
+            hc["doc-healthcheck"]
        end
-    subgraph tasksp["av-dev-tasks — учёт работ"]
+        subgraph tasksp["учёт работ"]
            direction LR
-        groom["groom"] --> tasks["tasks"]
+            groom["task-groom"] --> tasks["task-track"]
+        end
    end
    init --> tasks
    init --> osp
@@ -127,18 +144,17 @@ flowchart TB
    tp --> tasks
 ```

-Зависимости **взаимные, но каждая мягкая**. `av-dev-code` зовёт обоих соседей;
-обратные вызовы тоже есть — `av-dev:doc-init` и `av-dev:doc-canon` заводят
-OpenSpec скиллом `av-dev:code-openspec`, `av-dev:doc-sync` берёт у
-`av-dev:code-review` форму записи журнала дефектов и процедуру промоута,
-`av-dev:doc-canon` и `av-dev:doc-healthcheck` зовут `av-dev:task-track`.
-**Мягкая** значит, что у любого вызова есть ветка «не разрешился»: соседа в
-проекте нет — вызывающий называет строкой, чего теперь не делает никто, и работу
-не останавливает. Как именно зовут соседа и что делают, когда вызов не
-разрешился, — `shared/plugin-boundary.md`: правило нужно большинству скиллов, и
-ни один плагин им не владеет. То, что нужно нескольким дословно — граница
-плагинов, язык проектных текстов, словарь сопровождения, — живёт домом в
-`shared/` и уезжает в каждый плагин помеченной копией.
+**Скиллы зовут друг друга полным именем, а не по пути.** Внутри одного плагина
+путь бы разрешился, но короткое имя разрешается в устаревшую проектную копию из
+`.claude/skills/` — молча и без признаков подмены.
+
+**Отсутствовать может не плагин, а часть раскладки проекта**: `docs/`, каталог
+задач, `openspec/`. Тогда вызывающий называет строкой, чего теперь не делает
+никто, и работу не останавливает. Правило целиком —
+[shared/absence.md](av-dev/shared/absence.md): оно нужно почти каждому скиллу, и
+ни один им не владеет. Там же, в `shared/`, живут язык проектных текстов и
+словарь сопровождения; скиллы читают их по ссылке, а дословной копией они
+уезжают только в уставы вычитки — туда, где текст обязан лежать внутри промпта.

 ## Канон документов проекта

@@ -165,18 +181,21 @@ OpenSpec скиллом `av-dev:code-openspec`, `av-dev:doc-sync` берёт у
 «тема → её дом → что оттуда берётся» —
 [project-facts.md](av-dev/skills/code-review/references/project-facts.md).

-Прийти в старый проект и перевести его на канон — `/av-dev:doc-canon`. Канон
-версионируется, и проекты повышаются по [журналу
-версий](av-dev/skills/doc-canon/references/changelog.md); версия проекта живёт в
-`docs/.docs.json`.
+Прийти в старый проект и перевести его на канон — `/av-dev:doc-canon`.
+Раскладка версионируется, и проекты повышаются по [журналу
+версий](av-dev/skills/doc-canon/references/changelog.md).

-**Версий две, и они независимы.** У каталога задач своя — ключ `tasks` в
-`<каталог задач>/.tasks.json`, свой [журнал
-версий](av-dev/skills/task-track/references/changelog.md) и своё повышение
-скиллом `/av-dev:task-track`. Плагины ставятся порознь: у проекта, взявшего учёт
-работ без канона документов, `docs/` нет вовсе, и общее число оказалось бы домом,
-которого у половины проектов не существует. Имя служебного файла при этом
-называет владельца — `.docs.json`, `.tasks.json`, `openspec/config.yaml`.
+**Версия одна, и живёт она в `.av-dev.toml` в корне репозитория** — вместе с
+настройками: `[docs] migrations` и секция `[tasks]`, где лежит каталог задач и
+как названы его части. Версий было две, пока плагинов было три и проект мог
+взять учёт работ без канона документов; теперь плагин один, и второе число
+означало бы только вопрос, по какому журналу повышать. Прежние
+`docs/.docs.json` и `<каталог задач>/.tasks.json` не читаются: увидев их,
+`docs.py check` называет прежнюю раскладку и зовёт `upgrade` — запись 1
+журнала. Формат TOML взят ради комментариев: файл лежит в репозитории проекта,
+и назначение числа читают из него самого, а скрипты правят строку, а не
+переписывают файл. Имя служебного файла по-прежнему называет владельца —
+`.av-dev.toml`, `openspec/config.yaml`.

 ## Подключение

@@ -191,9 +210,7 @@ cd /path/to/project
 claude plugin marketplace add https://git.vakhrushev.me/av/dev-skills.git --scope project

 # плагины: scope обязателен, умолчание у команды — user, а нам нужен project
-claude plugin install av-dev-docs@av-dev-skills --scope project
-claude plugin install av-dev-tasks@av-dev-skills --scope project
-claude plugin install av-dev-code@av-dev-skills --scope project
+claude plugin install av-dev@av-dev-skills --scope project
 claude plugin install av-dev-git@av-dev-skills --scope project
 ```

@@ -209,9 +226,7 @@ claude plugin install av-dev-git@av-dev-skills --scope project
    }
  },
  "enabledPlugins": {
-    "av-dev-docs@av-dev-skills": true,
-    "av-dev-tasks@av-dev-skills": true,
-    "av-dev-code@av-dev-skills": true,
+    "av-dev@av-dev-skills": true,
    "av-dev-git@av-dev-skills": true
  }
 }
@@ -240,9 +255,7 @@ claude plugin marketplace update av-dev-skills

 # 2. снимки плагинов — из каталога проекта, где они установлены
 cd /path/to/project
-claude plugin update av-dev-docs@av-dev-skills --scope project
-claude plugin update av-dev-tasks@av-dev-skills --scope project
-claude plugin update av-dev-code@av-dev-skills --scope project
+claude plugin update av-dev@av-dev-skills --scope project
 claude plugin update av-dev-git@av-dev-skills --scope project
 ```

@@ -316,7 +329,7 @@ claude plugin uninstall <плагин>@av-dev-skills --scope project
 <plugin>/skills/<skill>/references/  что читается по ссылке из скилла
 <plugin>/skills/<skill>/scripts/     tasks.py, docs.py, openspec.py
 <plugin>/agents/                     charter'ы сабагентов
-shared/                              дома правил, общих для нескольких плагинов
+av-dev/shared/                       дома правил и общий читатель .av-dev.toml
 scripts/                             проверки репозитория и пересборка копий
 pyproject.toml                       линтеры скриптов, только для этого репозитория
 lefthook.yml                         гейт коммита: проверки документов
@@ -398,19 +411,23 @@ python3 scripts/copies.py     # 0 сошлось, 1 расхождение, 2 р
 сверку не входят. Маркер, уехавший в проект вместе со скелетом, там полезен: он
 говорит, что у текста есть дом и правится он там.

-**Дом правила, общего для нескольких плагинов, лежит в `shared/` и ни одному из
-них не принадлежит.** Так живёт язык проектных текстов: он одинаково нужен
-документам канона и задачам, и хранить его внутри одного плагина значило бы
-отдать общее правило во владение половине. Так же живёт граница плагинов —
-правило обращения к соседу. Плагин везёт копию и потому остаётся
-самодостаточным — `shared/` нужен этому репозиторию, а не установленному
-плагину.
+**Дом правила, общего нескольким скиллам, лежит в `av-dev/shared/` и ни одному
+из них не принадлежит.** Так живут язык проектных текстов, словарь
+сопровождения и правило об отсутствующих частях раскладки: каждое нужно
+многим, и хранить его внутри одного скилла значило бы отдать общее правило во
+владение части.
+
+**Копия при этом делается не всегда.** Пока плагинов было три, копия была
+единственным способом: путь в дерево соседа не разрешался. Внутри одного дерева
+скилл читает дом **по ссылке**, и дословная копия остаётся там, где текст обязан
+лежать внутри самого промпта, — в уставах вычитки, где он и есть критерий
+суждения, — и в скелетах, уезжающих в репозиторий проекта.

 **Дом ставится в `shared/` только тогда, когда владельца нет.** У адресов
-владелец есть: раскладку `docs/` держит канон, каталог задач — плагин задач, и
-переносить их наружу значило бы отобрать у владельца его же предмет. Общее без
-владельца едет копией из `shared/`; чужое с владельцем остаётся дома, а
-потребитель на него ссылается.
+владелец есть: раскладку `docs/` держит `doc-canon`, каталог задач —
+`task-track`, и переносить их наружу значило бы отобрать у владельца его же
+предмет. Общее без владельца живёт в `shared/`; чужое с владельцем остаётся
+дома, а потребитель на него ссылается.

 Скрипт ловит четыре вещи: копия разошлась с домом (с диффом), копия указывает не
 на тот файл, дом остался без копий, разметка сломана. Чего он **не** ловит —
@@ -15,13 +15,16 @@

 ## Где мы сейчас

-Плагинов четыре, и каждый ставится отдельно: `av-dev-docs` (канон документов и
-их содержимое), `av-dev-tasks` (задачи и цели), `av-dev-code` (код по задачам:
-цикл SDD, конвейер ревью, OpenSpec), `av-dev-git`. Общее, что нужно нескольким
-дословно, живёт домом в `shared/` и уезжает копиями.
+Плагина два: `av-dev` — весь процесс девятью скиллами (`doc-*` — документы,
+`task-*` — учёт работ, `code-*` — работа по задачам), и `av-dev-git` —
+сообщения коммитов. Прежние три (`av-dev-docs`, `av-dev-tasks`, `av-dev-code`)
+слились 13 августа 2026, тема 64 DECISIONS. Общее, что нужно нескольким скиллам,
+живёт домом в `av-dev/shared/`.

-Канон документов — **версия 14**; формат задач — **версия 1**, своя и со своим журналом. Живые проекты стоят на 2–3 и на плагине
-`av-dev-pm`, которого больше нет.
+Раскладка — **версия 1**, одна на документы и на каталог задач, в
+`.av-dev.toml` в корне проекта. Живые проекты стоят на каноне 2–3 и на плагине
+`av-dev-pm`, которого больше нет: им идти сперва по закрытому журналу канона до
+14, потом по записи 1 действующего.

 Бумажная часть закрыта аудитом четырёх плагинов и четырьмя пропусками правок
 (DECISIONS, запись 59). Всё, что ниже, проверяется **только на живом коде**.
@@ -35,19 +38,18 @@
 ### healthlog — первым

 - [ ] переустановить плагины: снять `av-dev-pm` и `av-dev-pipeline`, поставить
-      `av-dev-docs`, `av-dev-tasks`, `av-dev-code`, `av-dev-git`. Оба прежних
-      имени мертвы, и `plugin update` их не переименует — только снять и
-      поставить. `marketplace update`, затем `plugin update` — одного шага мало
+      `av-dev` и `av-dev-git`. Прежние имена мертвы, и `plugin update` их не
+      переименует — только снять и поставить. `marketplace update`, затем `plugin update` — одного шага мало
      (README, «Обновление»)
 - [ ] удалить проектные копии: `.claude/skills/healthlog-{task,review}-pipeline`
      и девять `.claude/agents/healthlog-review-*.md`. Они прошлого поколения и
      после переезда указывают на документы, которых уже не будет
- [ ] `av-dev:doc-canon` в режиме `adopt` — он приведёт проект к канону 14
+- [ ] `av-dev:doc-canon` в режиме `adopt` — он приведёт проект к раскладке 1
      сразу, картой и с подтверждением. Файл-в-файл здесь не расписан: раскладку
      знает скилл, и второй перечень разошёлся бы с ним
 - [ ] каталог задач — в `tasks/` корня (канон 11), не в `docs/tasks/`, без
-      `SPRINT.md` (канон 12) и с версией формата в `tasks/.tasks.json` (журнал
-      задач, версия 1). Скилл задач зовётся из `adopt` сам
+      `SPRINT.md` (канон 12); версия и настройки — в `.av-dev.toml` корня, там
+      же секция `[tasks]`. Скилл задач зовётся из `adopt` сам
 - [ ] гейт проекта: три шага вместо одного — `docs.py check`, `tasks.py check
      --dir tasks`, `openspec.py check`. **Второй и третий раньше не были
      нужны:** согласованность задач тянул за собой `docs.py`, форму `config.yaml`