Привёл набор 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>
4.1 KiB
4.1 KiB
1. Дельта-спеки change (готово при propose)
- 1.1
recognition— REMOVED 4 требования метабазы + ADDED разбор LLM - 1.2
metadata-match(new) — поиск/подтверждение матча + перенесённые требования - 1.3
review(new) — процесс ревью + перенос 3 требований из web-ui - 1.4
file-layout(new) — миграция jellyfin-layout.md - 1.5
download-tracking(new) — миграция прямого пути FSM из workflow.md - 1.6
notifications(new) — падения/дебаунс/пинги + перенос из state-reconciliation - 1.7
ingest— ADDED ядро приёма + перенос 3 требований из identity - 1.8
identity/web-ui/state-reconciliation— REMOVED-дельты переносов - 1.9
openspec validate --strict— проходит
2. Ревью дизайна (чекпоинт до влития)
- 2.1 Проверить полноту переносов по таблицам design.md D2–D5: каждое исходное требование учтено (STAY либо REMOVED+ADDED), ни одно не потеряно
- 2.2 Сверить счётчик требований до/после (сумма по капабилити не изменилась, кроме намеренно добавленного «Приём источника и заведение загрузки»)
- 2.3 Подтвердить, что формулировки перенесены эквивалентно (нормативная сила SHALL/MUST и сценарии сохранены), поведение системы не меняется
3. Purpose живых спек (при/после archive)
- 3.1 Дописать
## Purposeновым capability (metadata-match,review,file-layout,download-tracking,notifications) — иначе archive проставит «TBD», как уlive-status - 3.2 Подчистить стухший
## Purposeу доноров:identity(убрать инфохэши/дедуп/атомарный возврат),recognition(убрать сверку/локаль TMDB/сбор кандидатов — оставить разбор LLM),state-reconciliation(убрать «уведомления о рассинхроне»),web-ui(убрать ревью-специфику)
5. Синхронизация docs/specs (источник истины переезжает в OpenSpec)
- 5.1
docs/specs/recognition.md— шапка «источник истины: openspec/specs/ recognition + metadata-match»; не дублировать содержимое - 5.2
docs/specs/review-ux.md— шапка «источник истины: openspec/specs/review» - 5.3
docs/specs/jellyfin-layout.md— шапка «источник истины: openspec/specs/ file-layout» - 5.4
docs/specs/workflow.md— шапка «прямой путь FSM: openspec/specs/ download-tracking; сверка: state-reconciliation; уведомления: notifications» - 5.5
docs/specs/architecture.md— сверить перечень capabilities и ссылки
6. Обновление беклога и памятки
- 6.1
docs/backlog.md— снять пункт «Пересмотр набора capabilities и рефакторинг спек» - 6.2
CLAUDE.md— при необходимости обновить перечисление capabilities (ingest, recognition, metadata-match, review, file-layout, download-tracking, notifications, state-reconciliation, live-status, web-ui, identity)
7. Влитие и архив
- 7.1 Ревью change до архива (процесс CLAUDE.md)
- 7.2
openspec archive refactor-capability-boundaries— влить дельты вopenspec/specs/ - 7.3 Повторный
openspec validate --strictпо влитым спекам