Repository navigation
Re-review and recovery of a Document Review #47
Description
Parent
What to build
A Document Review's second round and its recovery work as a Code Review's do. After a design (or requirements) round whose result is fix then one re-review, the result's Next Call argv echoes the caller's own --parent and every --document, adds the one axis, the resume handle, and the Response path; running it rebuilds the Document Review preparation, appends the caller's Response to the re-review turn under its heading, and the second result's next is escalate with nextCall null. A resume without a Response is refused before a round is spent, as today. --recover-session on a Document Review whose driver died returns the same result the delivery would have, with the documents receipt as written — recovery's fill of the Code Review legacy fields (specFile, specFailure, responseFile) becomes conditional on the receipt being a Code Review one, and a Code Review receipt recovers exactly as it does today. This condition is the one edit to the delivery half.
Acceptance criteria
- A
designround's Next Callargvcarries--parent(when given) and every--documentin the caller's order, plus--axis design,--resume-session, and--response; the same forrequirements - Running that
argvwith a Response delivers the design brief unchanged with the Response appended under its heading, and returnsnext: escalate,nextCall: null - A resume without a Response is refused before any round is granted
-
--recover-sessionafter a killed driver returns each Document Review axis's stored report and apreparationequal to the delivered receipt, with nospecFile/specFailurekeys added - A recovered Code Review receipt still carries
specFile,specFailure, andresponseFile, and every existing recovery test passes unchanged - Both Lanes are covered where the existing rounds and recovery suites cover both
Blocked by
- An unfetched Parent is carried; an unfetched document stops the review #46 — serial chain: the failure rules land before the rounds and recovery are exercised.
Routing
Workflow: tdd
Executor: codex
Model: gpt-5.6-sol
Effort: xhigh
Review: claude claude-opus-5 medium
Reasons: Resume and recovery paths are behaviour a test can pin → tdd; nothing downstream couples to them → non-core; it crosses preparation and the delivery half's recovery → complex; executor and review set by the user at confirmation.
Activity
Simon-AI-coding commentedon Aug 31, 2026
Carried from #45's Spec review (crew run crewtask/3, coordinator ruling)
#45's Spec reviewer (Codex, session
7d6ee174-96dc-4035-af8b-bba6d3434c6b) raised one finding that is this ticket's scope by the wave table, so #45 deferred it here rather than absorbing it. It describesbridge/review_bridge.pyon branchworktree-45-45at review time; the line number will shift once #45 lands, but the site is named.worktree-45-45) unconditionally addsspecFileandspecFailuretopreparation, so a recovered documents review's receipt carries Code Review fields. A Document Review runs end to end on the Bridge #45's acceptance requires "The result'spreparationis the documents receipt with every field Document Review: hold a spec or ticket set to its Parent and to the checkout, on the same Bridge #43 names" — and only those. Expected here: recovery rebuilds the receipt per review kind (the Bridge chooses axes, rounds, and preparation from one review-kind table #44 table row), and a test at the command seam pins the recovered documents receipt to exactly Document Review: hold a spec or ticket set to its Parent and to the checkout, on the same Bridge #43's field set.Note: #45's new tests do not cover the recovery path; that test belongs in this ticket.