Рефакторинг границ capabilities: цепочка загрузка→матч→ревью→раскладка (openspec)

Привёл набор capabilities в OpenSpec к цепочке обработки, чтобы имя capability
отвечало одному поведению. Чисто по спекам, код и поведение системы не меняются.

Change refactor-capability-boundaries (архивирован):
- recognition разделён на recognition (разбор LLM) + metadata-match (сверка с базами)
- review выделен из web-ui + мигрирован из docs/specs/review-ux.md
- новые capability из docs/specs: file-layout, download-tracking, notifications
- identity очищен до инфра-id; приём (инфохэши, дедуп, ядро приёма) — в ingest
- уведомление о рассинхроне перенесено из state-reconciliation в notifications
- дубль владения путём и безопасного undo оставлен в state-reconciliation

Итог: 11 capabilities, openspec validate --strict проходит (+37/−11 требований).
Источник истины по мигрированным темам переехал в openspec/specs (шапки в docs).
Снят пункт беклога «Пересмотр набора capabilities».

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

docs/backlog.md

@@ -165,33 +165,6 @@ qBittorrent, пул LLM-вызовов и запись в SQLite спроект
 [docs/conventions](conventions/README.md),
 [«Словарь единого языка»](#словарь-единого-языка-ubiquitous-language).
 
-### Пересмотр набора capabilities и рефакторинг спек
-
-Деление capabilities в OpenSpec сложилось по ходу миграции и смешивает
-разные действия в одной спеке. Пример: `recognition` держит и разбор через
-LLM, и **сверку с внешними базами** — а «поиск в базе» и «подтверждение
-матча официальным id» суть разные действия, значит и разные capability.
-Нужно пересмотреть набор и границы, чтобы имя capability отвечало одному
-поведению:
-
-- `recognition` — только разбор сигналов через LLM (план, тип, название,
-  файлы → серии);
-- отдельные capability под работу с метабазами: поиск записей во внешних
-  базах и сверку/подтверждение матча (разнести пока смешанное в
-  `recognition`);
-- `web-ui` — только общее оформление, дизайн-система и общие компоненты
-  страниц;
-- `review` — весь процесс ревью после распознавания и матча (мигрировать из
-  [review-ux.md](specs/review-ux.md); сейчас поведение ревью не в OpenSpec).
-
-Работа чисто по спекам (границы, RENAMED/MOVED requirements), код не
-трогаем. Ценно тем, что снимает путаницу «какой capability трогать» на
-каждой задаче.
-
-Связано: `CLAUDE.md` (SDD, миграция capabilities), openspec/specs
-(`recognition`, `web-ui`), [review-ux.md](specs/review-ux.md),
-[«Словарь единого языка»](#словарь-единого-языка-ubiquitous-language).
-
 ### Сила совпадения кандидата и пересмотр распознавания/матчинга _(идея)_
 
 Сейчас у кандидата метабазы нет метрики силы совпадения (`metadata_candidate`

docs/specs/jellyfin-layout.md

@@ -1,5 +1,10 @@
 # Конвенции раскладки Jellyfin
 
+> **Источник истины переехал в OpenSpec** — `openspec/specs/file-layout/` (имена,
+> хардлинки, коллизия, copy-fallback). Владение путём (`superseded`) и безопасный
+> undo (`nlink<=1`) — в `openspec/specs/state-reconciliation/`. Этот файл —
+> справочный нарратив; при расхождении верна спека OpenSpec.
+
 Целевые имена и структура, в которые jellybit раскладывает файлы
 хардлинками. Источники:
 [Movies](https://jellyfin.org/docs/general/server/media/movies),

docs/specs/recognition.md

@@ -1,5 +1,10 @@
 # Распознавание контента
 
+> **Источник истины переехал в OpenSpec.** Актуальные требования —
+> `openspec/specs/recognition/` (разбор сигналов LLM) и
+> `openspec/specs/metadata-match/` (сверка с внешними базами). Этот файл остаётся
+> справочным нарративом; при расхождении верна спека OpenSpec.
+
 ## Задача
 
 По доступным сигналам определить: фильм или сериал; каноническое название

docs/specs/review-ux.md

@@ -1,5 +1,9 @@
 # Ревью раскладки человеком
 
+> **Источник истины переехал в OpenSpec** — `openspec/specs/review/`. Этот файл
+> остаётся справочным нарративом (UI-макеты, разбор сценариев); при расхождении
+> верна спека OpenSpec.
+
 Что происходит, когда система не уверена в распознавании и не
 раскладывает файлы автоматически. Когда именно наступает ревью — см.
 [recognition.md](recognition.md); место состояния `review` в общем потоке —

docs/specs/workflow.md

@@ -1,5 +1,12 @@
 # Жизненный цикл загрузки и машина состояний
 
+> **Источник истины переехал в OpenSpec.** Прямой путь FSM (downloading →
+> completed → stuck/failed, поллинг, усыновление) — `openspec/specs/
+> download-tracking/`; сверка с реальностью — `openspec/specs/
+> state-reconciliation/`; уведомления — `openspec/specs/notifications/`. Этот
+> файл — справочный нарратив по графу состояний; при расхождении верна спека
+> OpenSpec.
+
 Как загрузка проходит путь от приёма источника до разложенных файлов:
 состояния, переходы и то, что их вызывает. Кто владеет переходами и общее
 устройство — в [architecture.md](architecture.md); детали распознавания —