OpenSpec: архивация трёх параллельных changes + синк спек
Итог параллельной волны фиксов (worktree-изоляция, cherry-pick в master): - ingest-dedup-integrity (F1, F6) → спека ingest - retry-stall-basis (MAJOR-1, MAJOR-2) → спека state-reconciliation - linking-transition-robustness (MAJOR-4, MINOR-7) → спеки file-layout и state-reconciliation Дельты влиты в openspec/specs, changes перенесены в openspec/changes/archive/2026-07-08-*. Беклог не трогаю (по решению). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.8
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-07-08
|
||||
@@ -0,0 +1,79 @@
|
||||
## Context
|
||||
|
||||
Приём дедуплицирует входящий источник по активной задаче двумя путями:
|
||||
|
||||
1. **Быстрый чек** — `Ingest` вызывает `FindActiveByInfohash`, при попадании
|
||||
уходит в `attached()` (дозапись недостающих хешей через `AddInfohashes`).
|
||||
Это основной путь.
|
||||
2. **Гонка** — быстрый чек пуст, но пока выводили имя/готовили запись,
|
||||
активная задача появилась; `CreateDownloadIfNoActive` внутри своей
|
||||
транзакции находит её и возвращает как дедуп (дозапись хешей внутри той же
|
||||
tx).
|
||||
|
||||
F1 живёт в пути 2 (неохраняемая дозапись). F6 задевает ОБА пути: в реальном
|
||||
сценарии первым отрабатывает быстрый чек (путь 1), поэтому апгрейд обязан
|
||||
работать и там.
|
||||
|
||||
## F1 — пер-хеш гард дозаписи в дедуп-ветке
|
||||
|
||||
**Решение.** В дедуп-ветке `CreateDownloadIfNoActive` заменяем безусловный
|
||||
цикл `INSERT OR IGNORE` на тот же гард, что в `AddInfohashes`: для каждого
|
||||
хеша `h` проверяем `findActiveByInfohash(ctx, tx, {h}, existing.ID)`; если
|
||||
другая активная задача владеет `h` — пропускаем (не дописываем), иначе
|
||||
`INSERT OR IGNORE`. Транзакция уже открыта, `excludeID = existing.ID`
|
||||
исключает саму дедуп-цель (её собственные хеши не конфликтуют с ней самой).
|
||||
|
||||
**Почему пропуск, а не ошибка.** Дедуп по контракту не падает — возвращает
|
||||
существующую задачу. Конфликтный хеш принадлежит другой активной задаче;
|
||||
молча его не трогаем — это и есть сохранение инварианта. В отличие от
|
||||
`AddInfohashes`, который сигналит `ErrInfohashTaken` вызывающему (там это
|
||||
осмысленно), у дедуп-ветки наблюдаемого канала ошибки нет и он не нужен:
|
||||
поведение — «присоединиться к найденной задаче, чужое не красть».
|
||||
|
||||
## F6 — апгрейд catched-magnet до torrent
|
||||
|
||||
**Решение.** Новый guarded-метод хранилища:
|
||||
|
||||
```
|
||||
UpgradeCatchedMagnetToTorrent(ctx, downloadID string, torrentBlob []byte) (bool, error)
|
||||
```
|
||||
|
||||
в одной write-транзакции:
|
||||
|
||||
1. Пустой `torrentBlob` → `(false, nil)` (защитный no-op).
|
||||
2. Гардированный UPDATE:
|
||||
`UPDATE download SET source_type='torrent', updated_at=?
|
||||
WHERE id=? AND source_type='magnet' AND state='catched'`.
|
||||
`RowsAffected==0` → задача не подходит (уже `downloading`/отменена/не
|
||||
magnet) → коммит без эффекта, `(false, nil)`.
|
||||
3. `RowsAffected==1` → `INSERT OR REPLACE INTO download_torrent(download_id,
|
||||
data)` (у magnet блоба нет; `OR REPLACE` — страховка идемпотентности),
|
||||
коммит, `(true, nil)`.
|
||||
|
||||
**Почему гард `state='catched'`.** Апгрейд имеет смысл только пока worker ещё
|
||||
не отдал источник в qBittorrent. В `catched` worker на шаге добавления
|
||||
выбирает способ по `source_type` (`internal/worker/worker.go:sourceAddParts`):
|
||||
после смены на `torrent` он добавит файлом — метаданные приедут сразу. Если
|
||||
задача уже `downloading`, magnet давно в qBittorrent (застрял в metaDL), и
|
||||
смена `source_type` его не переотдаст; это отдельная забота retry/desync, не
|
||||
приёма. Тот же паттерн ре-валидации, что у `PromoteCatched`: если задачу
|
||||
успели отменить, UPDATE не заденет строк и апгрейд просто не применится.
|
||||
|
||||
**Где вызываем.** Оба дедуп-пути `Ingest` сводим к `attached()` (в ветке
|
||||
гонки `existing` от `CreateDownloadIfNoActive` уже с подгруженными хешами, так
|
||||
что переиспользование безопасно). В `attached()` после дозаписи хешей: если
|
||||
входящий источник — `torrent` и есть байты, зовём
|
||||
`UpgradeCatchedMagnetToTorrent`. Вызов best-effort: ошибка/неуспех логируются
|
||||
`Warn`/`Info`, приём не валится (как и дозапись хешей). Результат приёма
|
||||
по-прежнему несёт `State` существующей задачи (остаётся `catched`) — меняется
|
||||
лишь способ будущего добавления.
|
||||
|
||||
**Идемпотентность и повтор.** Повторный `.torrent` того же хеша: первый
|
||||
апгрейд перевёл задачу в `torrent`, гард `source_type='magnet'` на втором даст
|
||||
`RowsAffected==0` → no-op. Байты уже сохранены при создании torrent-ветки —
|
||||
`OR REPLACE` перезапишет теми же данными без вреда.
|
||||
|
||||
## Границы
|
||||
|
||||
Схему не трогаем: `download_torrent` и колонка `source_type` уже есть. ER-схема
|
||||
`docs/specs/database.md` без изменений. Апгрейд — операция над данными.
|
||||
@@ -0,0 +1,56 @@
|
||||
## Why
|
||||
|
||||
Ревью приёма (Fable, 2026-07-08) вскрыло два дефекта в дедуп-ветках приёма,
|
||||
оба про инвариант «≤1 активная загрузка на infohash» и про сохранность
|
||||
источника:
|
||||
|
||||
- **F1 — неохраняемая дозапись хешей.** Дедуп-ветка
|
||||
`CreateDownloadIfNoActive` (`internal/store/download.go`) безусловно
|
||||
дописывает ВСЕ хеши входящего источника в найденную активную задачу
|
||||
(`INSERT OR IGNORE`) без пер-хеш гарда владения — в отличие от
|
||||
`AddInfohashes`, где гард есть. Это единственная неохраняемая запись хешей,
|
||||
и она в авторитетном методе инварианта. Сценарий: активная A владеет `v1`,
|
||||
активная B владеет `v2` того же гибридного торрента; приём гибрида
|
||||
`{v1,v2}`, дедупнувшись на B, допишет `v1` в B → две активные владеют `v1`.
|
||||
Инвариант нарушен.
|
||||
|
||||
- **F6 — потерянный upgrade-путь `.torrent` поверх magnet.** Пользователь
|
||||
сначала ловит magnet с закрытого трекера (задача `catched`,
|
||||
`source_type=magnet`), понимает, что без DHT метаданные не докачаются, и
|
||||
грузит правильный `.torrent`. Приём дедупит по infohash на magnet-задачу; по
|
||||
текущей спеке байты при дедупе НЕ сохраняются, `source_type` остаётся
|
||||
`magnet`. Worker добавляет раздачу по magnet-URL → вечный metaDL → failed.
|
||||
Ровно тот артефакт, который бы починил загрузку, выбрасывается с «уже в
|
||||
работе».
|
||||
|
||||
## What Changes
|
||||
|
||||
- **F1:** дедуп-ветка `CreateDownloadIfNoActive` применяет тот же пер-хеш
|
||||
гард, что и `AddInfohashes`: хеш, которым владеет ДРУГАЯ активная задача,
|
||||
не дописывается. Транзакция уже открыта — правка внутри неё.
|
||||
|
||||
- **F6:** при дедупе, где входящее — байты `.torrent`, а активная задача
|
||||
поймана как `magnet` и ещё не добавлена в qBittorrent (состояние
|
||||
`catched`), система сохраняет байты и меняет `source_type` на `torrent` в
|
||||
одной транзакции. Тогда worker добавит раздачу файлом и метаданные не
|
||||
придётся докачивать по DHT. Это ПРОТИВОРЕЧИТ действующему правилу спеки
|
||||
ingest «при дедупликации байты сохраняться SHALL NOT» — правило смягчается
|
||||
этим целевым исключением (MODIFIED-дельта).
|
||||
|
||||
Схема БД не меняется: таблица `download_torrent` уже есть, `source_type` —
|
||||
существующая колонка; апгрейд — изменение данных, не структуры.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### Modified Capabilities
|
||||
- `ingest`: уточняется поведение дедупа (пер-хеш гард дозаписи; сохранение
|
||||
`.torrent`-байт и смена источника при апгрейде `catched`-magnet).
|
||||
|
||||
## Impact
|
||||
|
||||
- Код: `internal/store/download.go` (гард F1 + новый guarded-метод апгрейда),
|
||||
`internal/ingest/ingest.go` (вызов апгрейда на обоих дедуп-путях).
|
||||
- Тесты: `internal/store`, `internal/ingest`.
|
||||
- Совместимость: изменение только ужесточает инвариант (F1) и добавляет
|
||||
целевой апгрейд (F6); существующие потоки без `.torrent`-поверх-magnet
|
||||
ведут себя как прежде.
|
||||
@@ -0,0 +1,154 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Атомарность возврата загрузки в активное состояние
|
||||
|
||||
Система SHALL атомарно (в одной write-транзакции) проверять на каждом пути,
|
||||
возвращающем загрузку из терминального состояния в активное (ручной retry,
|
||||
воскрешение фоновой сверкой, повторная раскладка/relink) или создающем её
|
||||
(приём, adopt чужой раздачи), что никакая другая активная загрузка не
|
||||
владеет любым из хешей этой, и при владении SHALL отказывать в переходе,
|
||||
сохраняя инвариант «не более одной активной загрузки на infohash».
|
||||
Отказ SHALL происходить до побочных эффектов во внешних системах
|
||||
(повторного добавления торрента в qBittorrent).
|
||||
|
||||
Та же проверка SHALL применяться к дозаписи хешей загрузке (раскрытие
|
||||
гибридного торрента) на ВСЕХ путях дозаписи, включая дедуп-дозапись при
|
||||
приёме: хеш, которым владеет другая активная загрузка, дописан быть SHALL
|
||||
NOT — ни отдельным методом дозаписи, ни дедуп-веткой атомарного заведения,
|
||||
которая доносит недостающие хеши найденной активной задаче. Прямой перевод
|
||||
терминальной загрузки в активное состояние в обход этой проверки SHALL
|
||||
отклоняться хранилищем (механический бэкстоп вместо удалённого
|
||||
unique-индекса).
|
||||
|
||||
#### Scenario: Retry при занятом хеше
|
||||
|
||||
- **GIVEN** загрузка #1 в `failed` с хешем `h`, и другая активная загрузка
|
||||
#2 с тем же `h`
|
||||
- **WHEN** пользователь вызывает retry для #1
|
||||
- **THEN** переход отклоняется с пояснением, #1 остаётся в `failed`
|
||||
- **AND** активной по `h` остаётся #2
|
||||
|
||||
#### Scenario: Дедуп-дозапись не крадёт чужой хеш
|
||||
|
||||
- **GIVEN** активная загрузка A владеет хешем `v1`, активная загрузка B
|
||||
владеет хешем `v2` того же гибридного торрента
|
||||
- **WHEN** принимается источник с обоими хешами `{v1, v2}` и дедупится на B
|
||||
- **THEN** B получает только незанятые хеши, а `v1` (в собственности A) B не
|
||||
дописывается
|
||||
- **AND** инвариант «не более одной активной загрузки на infohash»
|
||||
сохраняется (по `v1` активна только A)
|
||||
|
||||
### Requirement: Приём источника из .torrent-файла
|
||||
|
||||
Приём SHALL принимать источник в виде **байтов `.torrent`-файла** (наряду с
|
||||
magnet-ссылкой) — тем же быстрым use-case, общим для транспортов. Получив
|
||||
непустые байты торрента, система SHALL разобрать их локально (без сети),
|
||||
извлечь инфохэш(и) и завести загрузку с `source_type = torrent`, после чего
|
||||
сразу вернуть ответ транспорту (синхронный путь к qBittorrent не обращается —
|
||||
добавление делает воркер, см. `download-tracking`).
|
||||
|
||||
Инфохэши система SHALL извлекать такими, какими их сообщает qBittorrent, чтобы
|
||||
сопоставление раздач и дедупликация работали: v1-хеш (для v1/гибридного файла)
|
||||
SHALL вычисляться как SHA1 **исходных** байтов info-словаря (без переэнкода);
|
||||
v2-хеш (для v2/гибридного файла, BEP52) SHALL извлекаться как 64-hex `infohash_v2`.
|
||||
Для чистого v2-only файла система SHALL записывать v2-хеш (v1 у него нет).
|
||||
Извлечение всех известных хешей и дозапись недостающих подчиняются требованию
|
||||
«Множество инфохэшей загрузки».
|
||||
|
||||
Дедупликацию по активной задаче, атомарное заведение (`download` в состоянии
|
||||
`catched` + записи `download_infohash`) и инвариант «не более одной активной
|
||||
загрузки на infohash» torrent-приём SHALL проходить тем же атомарным путём, что
|
||||
и magnet (см. «Приём источника и заведение загрузки», «Дедупликация приёма по
|
||||
любому из хешей», «Атомарность возврата загрузки в активное состояние»).
|
||||
|
||||
Байты `.torrent` система SHALL сохранять персистентно, привязанными к загрузке,
|
||||
чтобы воркер мог добавить источник в qBittorrent именно файлом (не по magnet):
|
||||
раздачи закрытых трекеров и торренты без DHT по magnet-хешу метаданные не
|
||||
получат. Сохранение байтов SHALL выполняться в той же write-транзакции, что и
|
||||
заведение загрузки; при дедупликации (новая загрузка не создана) байты в общем
|
||||
случае сохраняться SHALL NOT.
|
||||
|
||||
**Исключение — апгрейд пойманной magnet-задачи до torrent.** Если входящий
|
||||
источник — байты `.torrent`, а дедуп попал на активную загрузку с
|
||||
`source_type = magnet`, ещё НЕ отданную в qBittorrent (состояние `catched`),
|
||||
система SHALL в одной write-транзакции сохранить байты `.torrent`,
|
||||
привязав их к этой загрузке, и сменить её `source_type` на `torrent`. Тем
|
||||
самым воркер добавит раздачу файлом, а не magnet-хешем (иначе на закрытом
|
||||
трекере без DHT метаданные не докачаются, а magnet застрянет в metaDL →
|
||||
failed). Апгрейд SHALL применяться ТОЛЬКО пока загрузка в `catched` (воркер
|
||||
источник ещё не добавил); для уже добавленной (`downloading` и далее)
|
||||
загрузки смена `source_type` при дедупе выполняться SHALL NOT — её судьба
|
||||
решается путями retry/сверки, а не приёмом. Апгрейд SHALL быть best-effort:
|
||||
его неуспех приём не прерывает.
|
||||
|
||||
Из полей `.torrent` система SHALL синтезировать контекст распознавания (имя
|
||||
раздачи, суммарный размер, сигнал по дереву файлов, домен трекера, комментарий)
|
||||
и **дополнять** им контекст транспорта — тем же правилом слияния, что и синтез
|
||||
из полей magnet (пользовательский текст первым; при пустом тексте — только
|
||||
синтез). Обогащённый контекст система SHALL сохранять в `download.Context`.
|
||||
Синтез SHALL выполняться без сетевых запросов.
|
||||
|
||||
`source_ref` у torrent-загрузки SHALL быть человекочитаемым референсом (имя
|
||||
раздачи или файла), а НЕ адресом добавления: добавление в qBittorrent идёт
|
||||
байтами, и трактовать `source_ref` как magnet/URL для добавления система SHALL
|
||||
NOT.
|
||||
|
||||
#### Scenario: Быстрый приём .torrent-файла
|
||||
|
||||
- **GIVEN** валидные байты `.torrent`-файла и (опц.) текст контекста
|
||||
- **WHEN** вызывается приём
|
||||
- **THEN** из файла извлекаются инфохэши и создаётся `download` в состоянии
|
||||
`catched` (`source_type = torrent`) с записями `download_infohash`
|
||||
- **AND** байты файла сохраняются привязанными к загрузке
|
||||
- **AND** ответ транспорту отдан без обращения к qBittorrent
|
||||
|
||||
#### Scenario: Инфохэш из исходных байтов info
|
||||
|
||||
- **WHEN** система разбирает v1/гибридный `.torrent`-файл
|
||||
- **THEN** инфохэш v1 вычисляется как SHA1 исходных байтов info-словаря
|
||||
- **AND** совпадает с хешем, по которому qBittorrent позже сопоставит раздачу
|
||||
|
||||
#### Scenario: v2-only файл записывается под v2-хешем
|
||||
|
||||
- **WHEN** система разбирает `.torrent` только с метаданными v2 (без v1)
|
||||
- **THEN** у загрузки записывается v2-хеш (64-hex), совпадающий с `infohash_v2`
|
||||
qBittorrent
|
||||
- **AND** сопоставление раздачи работает по нему
|
||||
|
||||
#### Scenario: Дубль .torrent по активной torrent-задаче
|
||||
|
||||
- **GIVEN** уже есть активная (в т.ч. `catched`) загрузка с тем же infohash и
|
||||
`source_type = torrent`
|
||||
- **WHEN** принимается `.torrent` с тем же инфохэшем
|
||||
- **THEN** новая загрузка не создаётся, возвращается существующая
|
||||
- **AND** байты торрента повторно не сохраняются (дубль)
|
||||
|
||||
#### Scenario: Апгрейд catched-magnet до torrent
|
||||
|
||||
- **GIVEN** активная загрузка в `catched` с `source_type = magnet` и хешем `h`
|
||||
(magnet-задача ещё не отдана в qBittorrent)
|
||||
- **WHEN** принимается `.torrent` с тем же инфохэшем `h`
|
||||
- **THEN** новая загрузка не создаётся, возвращается существующая
|
||||
- **AND** байты `.torrent` сохраняются привязанными к ней, а её `source_type`
|
||||
становится `torrent` — в одной транзакции
|
||||
- **AND** воркер добавит раздачу файлом (не по magnet)
|
||||
|
||||
#### Scenario: Magnet-задача уже добавлена — апгрейда нет
|
||||
|
||||
- **GIVEN** активная загрузка с `source_type = magnet` уже в `downloading`
|
||||
(отдана в qBittorrent)
|
||||
- **WHEN** принимается `.torrent` с тем же инфохэшем
|
||||
- **THEN** возвращается существующая загрузка, её `source_type` остаётся
|
||||
`magnet`, байты `.torrent` не сохраняются
|
||||
|
||||
#### Scenario: Контекст из полей файла
|
||||
|
||||
- **WHEN** принят `.torrent` с именем раздачи, деревом файлов и трекерами
|
||||
- **THEN** в `download.Context` добавляется синтез (имя, размер, сигнал по
|
||||
файлам, домен трекера), дополняющий текст транспорта
|
||||
- **AND** синтез выполнен без сетевых запросов
|
||||
|
||||
#### Scenario: Слишком большой .torrent отклоняется
|
||||
|
||||
- **WHEN** принимаемый `.torrent`-файл превышает ограничение размера
|
||||
- **THEN** приём отклоняется с ошибкой, загрузка не создаётся
|
||||
@@ -0,0 +1,29 @@
|
||||
## 1. F1 — пер-хеш гард дедуп-дозаписи
|
||||
|
||||
- [x] 1.1 В `CreateDownloadIfNoActive` (`internal/store/download.go`) заменить
|
||||
безусловный цикл `INSERT OR IGNORE` дедуп-ветки на пер-хеш гард как в
|
||||
`AddInfohashes`: пропускать хеш, которым владеет другая активная задача
|
||||
(`findActiveByInfohash(..., existing.ID)`), внутри уже открытой tx.
|
||||
- [x] 1.2 Тест в `internal/store`: гибридный дедуп на B не крадёт хеш,
|
||||
принадлежащий активной A (инвариант сохранён).
|
||||
|
||||
## 2. F6 — апгрейд catched-magnet до torrent
|
||||
|
||||
- [x] 2.1 Добавить guarded-метод хранилища
|
||||
`UpgradeCatchedMagnetToTorrent(ctx, downloadID, torrentBlob) (bool, error)`:
|
||||
в одной tx гардированным UPDATE `source_type='torrent'` при
|
||||
`source_type='magnet' AND state='catched'`, затем сохранить байты в
|
||||
`download_torrent`; вернуть, был ли апгрейд.
|
||||
- [x] 2.2 В `internal/ingest/ingest.go` свести оба дедуп-пути к `attached()` и
|
||||
вызвать апгрейд, когда входящий источник — torrent с байтами
|
||||
(best-effort: неуспех логируется, приём не валится).
|
||||
- [x] 2.3 Обновить интерфейс `ingest.Store` и `fakeStore` в тестах.
|
||||
- [x] 2.4 Тесты в `internal/store`: апгрейд из `catched`+magnet сохраняет байты
|
||||
и меняет `source_type`; из `downloading`/не-magnet — no-op. Тест в
|
||||
`internal/ingest`: дедуп `.torrent` на catched-magnet вызывает апгрейд.
|
||||
|
||||
## 3. Проверки
|
||||
|
||||
- [x] 3.1 `openspec validate --strict ingest-dedup-integrity`
|
||||
- [x] 3.2 `task test`
|
||||
- [x] 3.3 `task lint`
|
||||
Reference in New Issue
Block a user