Итог параллельной волны фиксов (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>
2.5 KiB
ADDED Requirements
Requirement: Восстановление задачи, застрявшей в linking
Система SHALL на каждом тике поллинга и при старте выявлять задачи в состоянии
linking и возвращать их в review с причиной «прерванная раскладка» (код
interrupted), откуда человек повторит применение (повтор идемпотентен).
linking — нетерминальное активное состояние, и у него, как у каждого
нетерминального состояния, ДОЛЖЕН быть владелец, продвигающий задачу; иначе
краш процесса между переходом в linking и финальным переходом оставил бы
задачу без владельца — её не листит ни один штатный шаг (ни поллинг активных,
ни распознавание, ни матрица сверки, ни восстановление failed/stuck).
Выявление SHALL выполняться под той же блокировкой переходов, что и раскладка:
активная раскладка удерживает блокировку весь свой срок и завершает переход из
linking до её отпускания, поэтому любая linking-задача, наблюдаемая под
блокировкой, по построению устарела (осталась после краха) — восстановление НЕ
SHALL задевать раскладку в полёте.
Scenario: Осиротевший linking возвращается в review
- GIVEN задача осталась в
linkingпосле краха между claim и финальным переходом - WHEN выполняется тик поллинга (или старт сервиса)
- THEN задача переходит в
reviewс причиной «прерванная раскладка» (кодinterrupted) - AND её можно повторно применить из ревью
Scenario: Прочие состояния sweep не задевает
- GIVEN задачи в состояниях
doneиreview - WHEN выполняется тик поллинга
- THEN восстановление
linkingих состояние не меняет