From 7317be448a1668e6d7f4d12e1a2565f7f37815f8 Mon Sep 17 00:00:00 2001 From: Andreas Trawoeger Date: Mon, 26 Oct 2026 09:27:14 +0100 Subject: [PATCH] fix(docs): correct the 2026.299.0822 entry's false clause about the FAIL: marker The `charly/pr-validator` raised it on opencharly/docs#192's second review as a non-blocking note, and it is right: the entry's round-2 paragraph says "the marker is asserted by a test that can fail" and then, in the next sentence, says that nothing asserts on these messages. The first clause is false. Nothing asserts on the `FAIL:` marker. The mutation harness asserts that a mutant turns the SELF-TEST red, on the case that covers the mechanism it removes; it does not assert on the message text, and no CI step greps for the prefix. Measured on the merged tree: $ grep -rc 'FAIL:' .github/workflows/*.yml .github/workflows/deploy.yml:0 .github/workflows/tag-on-merge.yml:0 The clause was written to say "this change is covered by a test that can fail" -- which is true, and is the change's central property -- but it was phrased as "the MARKER is asserted by a test", which is a different and false claim. The sentence right after it was written from the correct understanding of the same fact, and the two were never reconciled. WHAT THIS CHANGES, AND WHAT IT DOES NOT. The correction is APPENDED to the entry, immediately after the paragraph that carries the false clause, so the two read beside each other. The false sentence is NOT written over, and the merged PR body is NOT edited: the body is the artefact the verdict was produced against, and the entry is the published history that `tag-on-merge` wrote from that body. Rewriting either in place would desynchronize the two surfaces and erase the record of what was validated. The precedent for this shape is opencharly/opencharly#582: "it needs a follow-up commit that adds a correction, not a rewrite ... the correction belongs in history where the divergence can be read beside it." The CODE is not touched. The harnesses are exactly as opencharly/docs#192 landed them, and the validator reproduced that diff. The commit message of the landing squash a52dd1e states the truth already: "the exit code is the real signal -- nothing in CI greps for the prefix -- but two failure paths in one tool should read alike". Only the entry's prose carried the false clause. Refs opencharly/docs#163 Refs opencharly/docs#193 Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (documentation reviewed) --- CHANGELOG/2026.299.0822.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG/2026.299.0822.md b/CHANGELOG/2026.299.0822.md index 37c30893..b206a450 100644 --- a/CHANGELOG/2026.299.0822.md +++ b/CHANGELOG/2026.299.0822.md @@ -51,6 +51,8 @@ $ grep -n 'FAIL:' .github/scripts/test_check_dependency_advisories.py .github/sc Both harnesses now carry the marker on **both** failure paths, and the marker is asserted by a test that can fail — the harness itself, whose every mutant must turn the self-test red. **Nothing asserts on these messages; they are read by a human.** The gate's *outcome* is unchanged: five mutants per harness, every one still turning the self-test red on the case that covers the mechanism it removes. +**Correction (opencharly/docs#193).** The clause *"the marker is asserted by a test that can fail"* above is **false**, and the sentence right after it says so. Nothing asserts on the `FAIL:` marker: the mutation harness asserts that a mutant turns the **self-test** red — on the case that covers the mechanism it removes — and no CI step greps for the prefix, so the marker is a **human-facing** convention that makes the two failure paths of one tool read alike in a log. The **code** is unaffected by this note, and the change's central property is unchanged and still proven: every mutant in each harness turns the self-test red, five per harness, ten in total. This correction is appended rather than written over the sentence above, so the two can be read beside each other; the merged PR body carries the same text and is left standing for the same reason. + **Rebutted — the missing `timeout=`.** The validator notes that the harness's `subprocess.run` calls carry no `timeout=`, and calls it harmless. It is, and adding one would be a **regression in the failure mode**: - the step already carries a deadline, and this repo's own gate asserts that every step does (5 min for the step-deadline harness, 10 min for the advisory one), so the set of child processes is bounded;