канон 13: файл версии зовётся по владельцу, у задач появилась своя версия формата

Имя `.pm.json` пережило плагин `av-dev-pm` на два месяца и указывало в пустоту.
Правило, которое из этого вынуто: имя служебного файла — имя плагина, который
его завёл, и по нему же владельца узнают.

- `docs/.pm.json` → `docs/.docs.json`, запись 13 журнала. Прежнее имя docs.py
  не читает намеренно: по этому числу upgrade решает, какие записи применять,
  и два дома разъехались бы молча ровно там, где это дороже всего. Вместо
  совместимости — узнавание: check видит старый файл и печатает готовую git mv
- у каталога задач появилась своя версия формата — ключ `tasks` в
  `.tasks.json`, свой журнал версий и своё повышение. До сих пор её не было
  вовсе, хотя docs.py в комментарии уверенно на неё ссылался: описание
  опережало механику ровно так, как сказано в решении 195
- число своё, а не копия канонического: плагин ставится в одиночку, и у
  проекта без docs/ версии канона нет — сверять было бы не с чем
- конфиг задач стал обязательным (init и adopt apply пишут его всегда), check
  сверяет число, `check --fix` его не приписывает: приписанное объявляло бы
  каталог приведённым к формату, шагов которого никто не делал
- переезды 11 и 12 в новый журнал задним числом не переписаны — версия 1
  велит догнать формат по журналу канона, называя признаки отставания
  поимённо (каталог в docs/tasks/, живой SPRINT.md)
- запись 60 в DECISIONS со следствиями 200–203; отдельно разведено с решением
  F, где `.docs.json` отвергался как указатель путей: отвергнут был указатель,
  а не имя

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

@@ -116,8 +116,10 @@ capability: незаполненный канон это переходное с
 
 **Присутствие узнаётся вызовом или следом в проекте, но не объявлением.** Перечня
 установленных плагинов проект не ведёт — он разошёлся бы с действительностью
-молча. Что сосед здесь работал, видно по заведённому им файлу: `docs/.pm.json` —
+молча. Что сосед здесь работал, видно по заведённому им файлу: `docs/.docs.json` —
 канон, `<каталог задач>/.tasks.json` — задачи, `openspec/config.yaml` — конвейер.
+Имя файла — имя плагина, который его завёл, и держит он в том числе версию своего
+формата: у канона документов и у каталога задач они свои и двигаются порознь.
 
 <!-- /копия: граница-плагинов -->
 
@@ -176,7 +178,7 @@ capability), `openspec/config.yaml`.
 
 Порядок важен — он минимизирует окно, в котором ссылки битые:
 
-1. `docs/.pm.json` с `{"canon": <текущая версия>}` и путём миграций, если БД есть;
+1. `docs/.docs.json` с `{"canon": <текущая версия>}` и путём миграций, если БД есть;
 2. каталоги канона и скелет **по [references/skeletons.md](references/skeletons.md)**:
    незаполненное — одной честной информативной строкой, а не «TBD»;
 3. **OpenSpec, если его нет или `config.yaml` остался примером** — **вызови
@@ -265,7 +267,7 @@ capability), `openspec/config.yaml`.
 3. Иначе иди по [changelog.md](references/changelog.md) снизу вверх от версии
    проекта до текущей и делай названное в каждой записи. Записи независимы и
    применяются по порядку.
-4. Подними `canon` в `docs/.pm.json` до текущей.
+4. Подними `canon` в `docs/.docs.json` до текущей.
 5. `docs.py check`.
 6. **Позови судей** — Skill `av-dev-docs:healthcheck`.
 7. **Позови вычитку** — агент `doc-wording`, но **только по тем документам,
@@ -276,7 +278,15 @@ capability), `openspec/config.yaml`.
 Записи журнала описывают **что сделать проекту**. Если запись этого не говорит —
 это дефект журнала, и о нём надо сказать, а не догадываться.
 
-**Шаг 6 обязателен, и вот почему.** `check` сверяет **число** в `.pm.json` с
+**Каталог задач повышается своим журналом, а не этим.** У него своя версия
+формата — ключ `tasks` в `<каталог задач>/.tasks.json`, — и двигает её плагин
+`av-dev-tasks`. Запись канона вправе сказать «позови соседа», но не вправе
+двигать чужое число: две версии, которые ходят по одному журналу, разъезжаются
+на первом же проекте, поставившем один плагин без другого. Отстал каталог
+задач — это скажет `tasks.py check` своей строкой гейта, а повысит скилл
+`av-dev-tasks:tasks`.
+
+**Шаг 6 обязателен, и вот почему.** `check` сверяет **число** в `.docs.json` с
 версией скрипта — и только его. Применена ли запись журнала **по существу**, он
 не знает: проект несёт `"canon": 6` и может не иметь того, чего требовала любая
 из пройденных версий. Записи применяются руками (переименовать секцию, проставить