## 1. Дельта-спека

- [x] 1.1 Переформулировать требование о re-read `source_type` в дельта-спеке
      `download-tracking`: «под блокировкой переходов после тик-снимка, перед
      подготовкой запроса на добавление», с сохранённой рациональю «не
      полагаться на снимок, снятый вне блокировки»
- [x] 1.2 Назвать остаточное окно (апгрейд в момент вывода имени) явно:
      известное ограничение, запрос под блокировкой не пересобирается, и почему
      (`sourceAddParts` читает байты `.torrent`, медленное под замком не держим)
- [x] 1.3 Записать достоверный маршрут восстановления: `metaDL` →
      `magnet_timeout` → `failed`; сверка не оживляет, `Retry` при живом
      торренте перецепляется; нужен ручной шаг — убрать зависшую раздачу из
      qBittorrent, после чего `Retry` добавит байтами
- [x] 1.4 Уточнить пункт «Re-read состояния перед `add`»: он проверяет только
      состояние и запрос не пересобирает
- [x] 1.5 Добавить сценарий «Апгрейд magnet → .torrent до подготовки запроса —
      добавляется файлом» (закрытое окно, оракул — существующий тест)
- [x] 1.6 Добавить сценарий «Апгрейд magnet → .torrent в окне вывода имени —
      добавляется magnet» с исходом `magnet_timeout` → `failed` → ручной шаг +
      `Retry`

## 2. Отработка ревью предложения (профиль `design`, проход `specs`)

- [x] 2.1 (major) Дельта на `ingest`: обусловить обещание «воркер добавит
      раздачу файлом» моментом апгрейда и добавить сценарий на окно — иначе
      ложная гарантия переезжает в соседнюю capability (design D5)
- [x] 2.2 (minor) Снять `SHALL NOT`/`SHALL` там, где решение отложено:
      «пересобирать запрос под блокировкой» и «восстановление требует ручного
      шага» — в описательный залог (design D6)
- [x] 2.3 (minor) Поправить «снимок снят вне блокировки» → список снят под
      блокировкой, но к моменту обработки устарел (`worker.go:392-394`)
- [x] 2.4 (minor) Назвать исход ветки «байты `.torrent` недоступны»:
      предложение в требовании плюс сценарий (design D7)
- [x] 2.5 (границы спеки) Назвать, что на публичном трекере/DHT ущерба нет, и
      что повторный приём `.torrent` без удаления зависшей раздачи усыновит её
      же
- [x] 2.6 Поправить `design.md`: `Delete` из `failed` недоступен
      (`state-reconciliation` «Полное удаление загрузки пользователем»)

## 3. Проверка

- [x] 3.1 `openspec validate --strict catched-source-type-reread-wording` —
      зелёный
- [x] 3.2 `git diff --stat` не содержит ни одного файла под `internal/`
- [x] 3.3 `task gate` — зелёный; `TestProcessCatchedReReadsSourceTypeUnderLock`
      проходит без правок теста

## 4. Критерии приёмки (из постановки задачи)

- [x] 4.1 Требование спеки описывает фактическое поведение: re-read
      `source_type` под блокировкой после тик-снимка, апгрейд в окне namer'а
      назван допустимым и самоисцеляемым (оракул: `openspec validate --strict`)
- [x] 4.2 В спеке есть сценарий, покрывающий апгрейд в окне namer'а с исходом
      «magnet из снимка, дальше `magnet_timeout` → `failed` → `Retry`» (оракул:
      тот же прогон плюс существующий
      `TestProcessCatchedReReadsSourceTypeUnderLock` проходит без правок)
- [x] 4.3 Ни один файл под `internal/` в диффе не изменён (оракул:
      `git diff --stat` в отчёте ревью)

**Отклонение от буквы критерия 4.1/4.2, обнаруженное при сверке с кодом:**
маршрут «`Retry` перечитает актуальный `source_type` и добьёт» верен НЕ всегда —
`Retry` при живом торренте в `metaDL` перецепляется к нему без повторного `add`
(`internal/worker/worker.go:1043-1059`, `classify` на `:1130-1142`). В спеку
пишется достоверная версия с ручным шагом; см. `design.md` D2. Слово
«самоисцеляемое» заменено на «известное ограничение с названной ценой».
