Files

T

Рефакторинг границ 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>

2026-07-03 21:17:51 +03:00

3.5 KiB

Raw Blame History

notifications Specification

Purpose

Уведомление автора загрузки о значимых событиях: падения (failed/stuck, включая приёмный qbit_add мимо поллинга) с дебаунсом повторов, приглашение в review и готовность, рассинхрон (orphaned/target_missing). Единое место доставки пингов, над которым транспорты (Telegram и др.) — тонкие адаптеры.

Requirements

Requirement: Уведомление о падении загрузки

Любой переход загрузки в failed/stuck система SHALL сопровождать уведомлением автора загрузки через настроенный механизм (notifier), чтобы падение не оставалось незамеченным. Это SHALL включать приёмное падение qbit_add (не удалось добавить раздачу в qBittorrent), которое идёт мимо поллинг-цикла worker.

Scenario: Уведомление при падении приёма

GIVEN приём загрузки, где добавление в qBittorrent не удалось
WHEN загрузка помечается failed с error_code qbit_add
THEN автор загрузки получает уведомление о падении

Requirement: Дебаунс повторных падений

Повторные падения одной задачи в пределах окна дебаунса система SHALL уведомлять лишь один раз, чтобы мерцающий stalled-торрент (stuck ↔ downloading) не спамил автора.

Scenario: Мерцающий stalled не спамит

GIVEN задача, многократно переходящая stuck ↔ downloading в пределах окна дебаунса
WHEN происходят повторные падения
THEN уведомление отправляется один раз за окно

Requirement: Пинг о входе в review и готовности

При переходе загрузки в review система SHALL пинговать автора (сообщение в Telegram / бейдж в вебе) — пользователя зовут, а не он опрашивает. После успешного применения (готовность) система SHALL показывать, что создано.

Scenario: Пинг при входе в review

GIVEN загрузка переходит в review
WHEN происходит переход
THEN автор получает пинг с приглашением подтвердить раскладку

Requirement: Уведомление о рассинхроне

При переходе задачи в orphaned или target_missing система SHALL уведомлять автора загрузки через настроенный механизм уведомлений (notifier), чтобы рассинхрон не оставался незамеченным.

Scenario: Уведомление при потере источника

WHEN задача переходит в orphaned
THEN автор загрузки получает уведомление о рассинхроне

3.5 KiB Raw Blame History Unescape Escape