avandClaude Opus 4.8
512567c8ba
Привёл набор 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>
57 lines
3.5 KiB
Markdown
57 lines
3.5 KiB
Markdown
# 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** автор загрузки получает уведомление о рассинхроне
|
||
|