orchestrator/docs/work-items/ORCH-113/12-review.md

verdict, work_item, stage, author_agent, status, created_at, model_used, type, work_item_id, version

verdict	work_item	stage	author_agent	status	created_at	model_used	type	work_item_id	version
APPROVED	ORCH-113	review	reviewer	approved	2026-06-15	claude-opus-4-8	review	ORCH-113	1

Review ORCH-113 — BUG: job-reaper не должен повторно запускать финализацию deploy-staging, пока жив исходный finalizer

Summary

Фикс инцидента ORCH-111 реализован чисто и полно. Введён процесс-локальный реестр владения финализацией (src/finalizer_liveness.py, never-raise leaf по паттерну serial_gate/coverage_gate): монитор mark()-ит владение сразу после штампа exit_code и clear()-ит его в finally хвоста финализации; reaper в Tier-2 при stage=="deploy-staging" И активном владении делает defer вместо повторного advance_stage, проваливаясь к Tier-3 backstop (который маркер игнорирует → застрявший finalizer всё равно добивается).

Проверено по всем 4 осям; блокирующих findings нет.

• ТЗ: FR-1…FR-5 реализованы; AC-1…AC-6 покрыты тестами tests/test_orch113_reaper_finalizer_liveness.py (TC-01…TC-08). Схема БД — нулевое изменение (выбран in-memory реестр), что строже допущенной ТЗ §5 «аддитивная колонка». API §4 (read-only ключи в GET /queue) и QG §6 (не трогать) — соблюдены.
• ADR: реализация байт-в-байт соответствует ADR-001 / сквозному adr-0043 (D1–D5). Трассировка сохранена: авторитет Tier-3 (adr-0011/ORCH-065) и сквозной бюджет reaper_max_running_s (5400) > Σ(gate-work)+grace (ORCH-109/110) не нарушены — зафиксировано регресс-тестом TC-07. Ни один маркированный инвариант не сломан.
• Качество кода: хвост _monitor_agent вынесен в _run_monitor_finalization дословно — подтверждено git diff -w (+49/−0, нулевое изменение логики); все переменные, на которые ссылается извлечённое тело, — параметры/локальные/модульные (нет риска NameError, проверено вручную). never-raise во всех публичных функциях и врезках. Обязательный регресс-тест багфикс-трека (ORCH-019 BR-4 / coverage ORCH-027) присутствует: TC-05 по построению КРАСНЫЙ до фикса (assert calls == [], который pre-fix reaper нарушил бы вызовом _try_advance_stage) и ЗЕЛЁНЫЙ после.
• Документация: обновлены в том же PR — docs/architecture/README.md (описание Job-reaper + раздел Tier-2 + список kill-switch + ссылки на ADR), docs/architecture/internals.md (детализация Tier-2), CHANGELOG.md, ADR-001 (work-item) и сквозной adr-0043; все номерные доки задачи (00–04, 06-adr, 07, 08, 10) на месте.

Проверка прогона: pytest tests/ -q → 2001 passed, 0 failures (AC-6); целевой файл — 13 passed.

Findings

P0 — Blocker

• нет

P1 — Must fix

• нет

P2 — Should fix

• нет

P3 — Nice-to-have (не блокирует приёмку)

• Frontmatter обоих ADR (ADR-001 и adr-0043) держит status: proposed. По мере мержа фикса статус естественно становится принятым решением — стоит при следующем касании обновить на accepted (косметика трассировки, не влияет на гейт).
• В врезке mark() (launcher._monitor_agent, стр. ~884) делается отдельный get_task_by_repo_branch(repo, branch) ради stage-контекста, хотя тот же lookup повторяется ниже в хвосте финализации (стр. ~984). Дублирование на пути, и так делающем БД-работу, обёрнуто never-raise; stage здесь — best-effort контекст для snapshot() (reaper резолвит стадию независимо через _task_meta), так что корректность не зависит от него. Можно при желании переиспользовать один lookup.

Документация

Статус: полностью обновлена в том же PR (golden source соблюдён).

Артефакт	Изменение	Оценка
docs/architecture/README.md	Job-reaper компонент + раздел Tier-2 + список kill-switch (ORCH_REAPER_FINALIZER_LIVENESS_ENABLED) + ссылки на adr-0043	✅
docs/architecture/internals.md	Детализация Tier-2 deploy-staging defer	✅
CHANGELOG.md	Развёрнутая запись [Unreleased] с подпунктами (leaf / эмиссия / консультация / наблюдаемость)	✅
docs/work-items/ORCH-113/06-adr/ADR-001-…	Детальный ADR (D1–D5, альтернативы, последствия)	✅
docs/architecture/adr/adr-0043-…	Сквозной ADR (уточняет adr-0011/0040/0042/0041)	✅
docs/work-items/ORCH-113/{00..04,07,08,10}	Полный пакет номерных доков	✅

Обзорные доки / витрина: правка внутренняя для job-reaper; высокоуровневые описания в docs/overview/tech-architecture.md («job-reaper возвращает в очередь job'ы, чей исполнитель умер») и README.md остаются корректными — обновления не требуют (ORCH-079/ORCH-011 не задеты). Раздел README «Известные ограничения» не содержит пункта, закрываемого этим PR (баг был инцидентом, не значился ограничением) — обновление не требуется. Известное ограничение --workers>1 (TR-3) — системное пред-допущение, документировано в 10-tech-risks.md и обоих ADR; вынос в README не обязателен.