av-dev-pipeline: бриф удалён, проходы читают документы канона напрямую

- удалены скилл project-brief и контракт брифа; вместо них references/
  project-facts.md — карта «что нужно проходу → где лежит» и таблица
  поразрядной деградации по документам
- девять charter'ов, review-pipeline, task-pipeline и task-batch переписаны
  на пути канона; OpenSpec стал объявленной предпосылкой без ветки деградации
- шаг синка документации переписан в построчный доклад, закрытие задачи —
  вызовом скилла av-dev-pm:tasks вместо строки-слота из CLAUDE.md
- по находкам ревью: docs.py звал tasks.py из чужого каталога и выдавал его
  отказ окружения за дрейф; сверка миграций не видела рабочее дерево;
  плейсхолдер краснел вместо замечания; сверка capability проходила по
  совпадению с именем пакета; tasks.py не читал docs/.pm.json; скилл docs
  пересказывал канон в пяти местах

av-dev-pipeline/agents/review-specs.md

@@ -15,22 +15,26 @@ Development на OpenSpec). Оптика — требования, а не ст
 ключевые слова спек (`SHALL`, `GIVEN/WHEN/THEN`) — в оригинале. Читай реальные
 файлы перед выводом, ничего не выдумывай.
 
-## Что берёшь из брифа проекта
+## Что берёшь из документов проекта
 
-- **`## Инварианты`** — по ним проверяется, отражены ли в спеке задетые свойства,
-  и по ним же присваивается severity. Цитируй пункт дословно, когда ссылаешься.
-- **`## Карта`** — где актуальные спеки, где дельты, где архитектура и **где файл
-  наблюдений на живых данных**. Там же — **нарезка capability и миграционное
-  состояние спек**: по какому признаку проект режет capability и какие темы ещё
-  не переехали из документации в спеки. Без этого пункта непереехавшая тема
-  читается как пробел в спеке, и находка уходит в пустоту.
-- **`## Проект`** — граница домена: требование, переносящее понятие через неё, —
-  находка в спеку, а не в код.
+- **`CLAUDE.md`, инварианты** — по ним проверяется, отражены ли в спеке задетые
+  свойства, и по ним же присваивается severity. Цитируй пункт дословно, когда
+  ссылаешься.
+- **`docs/architecture.md`** — компоненты и capability, и **что из них уже
+  переехало в нормативные спеки**. Без этого непереехавшая тема читается как
+  пробел в спеке, и находка уходит в пустоту.
+- **`docs/research/`** — как внешний мир ведёт себя на самом деле.
+- **`docs/passport.md`** — граница домена: требование, переносящее понятие через
+  неё, — находка в спеку, а не в код.
 
-**Брифа нет** — сверяй только спеку с кодом, `critical` по основанию «нарушен
-инвариант проекта» не присваивай и дай в границы покрытия строку: «брифа проекта
-нет: инварианты, граница домена и состояние переноса capability в спеки
-неизвестны; отражение инвариантов в спеке не проверялось».
+Пути спек жёсткие: актуальные — `openspec/specs/<capability>/spec.md`, дельты —
+`openspec/changes/<id>/specs/`. Карта «что нужно проходу → где лежит» —
+`${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/project-facts.md`.
+
+**Нет инвариантов в `CLAUDE.md`** — сверяй только спеку с кодом, `critical` по
+основанию «нарушен инвариант проекта» не присваивай и дай строку: «инвариантов в
+`CLAUDE.md` нет: отражение инвариантов в спеке не проверялось». Нет
+`docs/passport.md` — граница домена неизвестна, и это отдельная строка.
 
 ## Источник требований
 
@@ -40,19 +44,19 @@ Development на OpenSpec). Оптика — требования, а не ст
 находка.
 
 Дополнительно поднимаешь: `design.md` и `tasks.md` change, затронутые актуальные
-спеки, инварианты из брифа. Если тема ещё не перенесена в спеки и живёт только в
-документации проекта — источник истины там, и это фиксируется в границах
-покрытия. Отдельно: файл наблюдений на живых данных (если он есть в карте) нормой
-не является, но именно там записано, как внешний мир ведёт себя на самом деле;
-требование, противоречащее наблюдению, — повод для находки в спеку.
+спеки, инварианты из `CLAUDE.md`. Если тема ещё не перенесена в спеки и живёт
+только в `docs/architecture.md` — источник истины там, и это фиксируется в
+границах покрытия. Отдельно: `docs/research/` нормой не является, но именно там
+записано, как внешний мир ведёт себя на самом деле; требование, противоречащее
+наблюдению, — повод для находки в спеку.
 
 ## Режим 1 — дизайн/спеки ДО кода
 
 Проверяешь change как артефакт: полнота покрытия постановки; сценарии
 `GIVEN/WHEN/THEN` без дыр, противоречий и недостижимых веток; scope не раздут и
 не урезан молча; согласованность с текущими спеками и нарезкой capability; в
-спеке отражены **задетые инварианты из брифа** — поимённо, а не «безопасность
-учтена».
+спеке отражены **задетые инварианты из `CLAUDE.md`** — поимённо, а не
+«безопасность учтена».
 
 Прогоняй `openspec validate --strict <id>` сам — это оракул, а не догадка.
 
@@ -111,7 +115,7 @@ Development на OpenSpec). Оптика — требования, а не ст
 ### 2.4 Право сомневаться в требовании
 
 Для верификатора спека обычно аксиома — здесь это ограничение **снято явно**.
-Если требование выглядит неверным (противоречит инварианту из брифа, делает
+Если требование выглядит неверным (противоречит инварианту из `CLAUDE.md`, делает
 невозможным штатный сценарий, теряет данные, которых потом не восстановить) —
 скажи об этом прямо, с последствием. Такая находка всегда `Действие: развилка`:
 менять спеку — решение человека.