A Document Review runs end to end on the Bridge #45

Parent

#43

What to build

A caller runs a Document Review on the Bridge end to end: --document <ref> (repeatable) with an optional --parent <ref>, each reference in the syntax --spec accepts today, and --axis both, requirements, or design. The Bridge fetches the Parent and every document the way it fetches a spec — an issue written out beside the report files, a path read where it lies — fills the two Document Review Axis Briefs exactly as #43 fixes them (environment line, Parent slot, document list, the design axis's load sentence and Standards sources: line, each axis's template baseline, the gate sentence, matt's report sentence; no mention of rounds), delivers them to whichever Lane was named, and returns the usual JSON result whose preparation is the documents receipt (parentSource, parentFile, parentFailure, documents, standardsFiles, standardsCondition, codeGraphUsed false, responseFile).

The review kind is documents when --document is present and code otherwise; the kind table (#44) gains its second row: axes requirements then design, each earning two rounds, prepared by DocumentReviewPreparation — the second adapter at the preparation seam, with the same Interface a Lane already calls (a brief per axis, briefs for a set of axes, a receipt). It reuses the spec reader and the standards-source reader; no Review Scope is resolved and no code graph is run. Argument validation refuses, before any Lane opens, --document with --base or --spec, a code axis name with --document, and a documents axis name without it.

Code Review is unchanged: its briefs, receipt, rounds, and every existing test.

Acceptance criteria

• review-bridge --reviewer <lane> --document <ref> --axis both delivers a requirements brief and a design brief to the Lane, in that order, whose text matches Document Review: hold a spec or ticket set to its Parent and to the checkout, on the same Bridge #43's two briefs with the slots filled; with --parent the Parent slot names the fetched file and its summary, without it the slot reads not provided; hold the documents to each other.
• The design brief's second line asks the reviewer to load the codebase-design skill and to say in its report's first line if it cannot; no argument, path, or fallback for the skill exists
• The result's preparation is 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 a Code Review's receipt is unchanged
• The three mixed-argument shapes are refused before any Lane opens, and the refusal names what was mixed
• requirements and design each earn two rounds; standards and spec keep theirs
• The Parent and each document reach the Lane as files the Bridge wrote or found, never as text pasted into the brief; an issue reference is fetched with gh and written beside the report files
• Tests run at the command seam through the existing harness and fake Lanes, asserting on delivered brief text and the JSON result only; every existing Bridge test passes unchanged
• --help lists the new options and the new axis names

Blocked by

• Bridge chooses axes, rounds, and preparation from one review-kind table #44 — the review-kind table this ticket adds its row to.

Routing

Workflow: tdd
Executor: codex
Model: gpt-5.6-sol
Effort: xhigh
Review: codex gpt-5.6-sol xhigh
Reasons: New runtime behaviour pinned by delivered brief text and receipts → tdd; #3, #4, and #5 couple to its arguments and receipt → core; it crosses the argument layer, preparation, and the brief → complex; executor and review set by the user at confirmation.