Repository navigation
the 2026.299.0822 changelog entry claims the FAIL: marker is asserted by a test — nothing asserts on it #193
Description
CHANGELOG/2026.299.0822.md — the entry tag-on-merge wrote from #192's body at merge time — carries a sentence that is false, and it contradicts the sentence right after it. This issue is the record and the claim; the correction lands as a follow-up commit in this repo, beside the entry it corrects, not inside it.
The finding
CHANGELOG/2026.299.0822.md, line 52:
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 first clause is false, and the second sentence says so.
Measured
$ git show origin/main:CHANGELOG/2026.299.0822.md | grep -n "asserted by a test that can fail"
52: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.** …
$ grep -rc 'FAIL:' .github/workflows/*.yml
.github/workflows/deploy.yml:0
.github/workflows/tag-on-merge.yml:0Nothing 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 it does not assert on the message text. No workflow greps for the prefix. The clause "the marker is asserted by a test that can fail" describes a test that does not exist.
Where it is, and where it is not
| surface | carries the false clause |
|---|---|
| the code | no — the harnesses are exactly as the entry describes, and the validator reproduced the diff |
| the commit message | no — it states the truth: "the exit code is the real signal -- nothing in CI greps for the prefix -- but two failure paths in one tool should read alike" |
| the PR body (live on #192) | yes |
the merged changelog entry 2026.299.0822.md |
yes — tag-on-merge wrote it from that body, and the two are the same text |
RCA
- Mechanism. 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 true sentence immediately after it, "Nothing asserts on these messages; they are read by a human", was written from the correct understanding of the same fact, and the two were never reconciled. The false clause is a prose defect: it changes no behaviour and misstates no code.
- Missed control. The pre-push body gate (
pr_body_lint.py) checks the body's structure — its four sections, its rule answers, its head SHA, its footer — and it does not check the body's claims against each other. A body can therefore pass the lint and still contradict itself inside one paragraph, and the contradiction was only visible to a reader — which is how the validator caught it, on the second round, as a non-blocking note. - Blast radius. One sentence in one published changelog entry, and the same sentence in the PR body it was written from. The code is correct, the gate is correct, and the entry's record of what landed is correct.
- Root fix. A body claim about what a test asserts needs to be checked against the tests, not only against the diff's shape. The correction below is the immediate fix; the durable fix is a check that a body's claim about a test's assertions is reproduced from the test source, which is a
pr_body_lint.pycapability. It is carried by pr_body_lint has no arm that checks a body's claim about a diffed file's CONTENT against the diff (measured on plugin-task#52's first-push BLOCK) marketplace#577 — the issue for a body claim that is not checked against the file's content — where this instance's measured evidence was added, so the control is fixed once, in the repo that owns the linter, rather than duplicated here.
The correction, and where it lands
The merged body and the merged entry stay standing. They are the artefacts the verdict was produced against, and the entry is the published history. Rewriting either in place would desynchronize the two surfaces tag-on-merge keeps identical, and would erase the record of what was validated. The precedent for exactly this shape is opencharly/opencharly#582: "Tags are immutable, so this cannot be corrected in place — 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."
So the correction lands as a follow-up commit in this repo, whose own changelog entry — written by tag-on-merge from the follow-up's body — states the false clause, states the true one, and sits beside 2026.299.0822.md.
The true statement, for the record. The FAIL: marker is a human-facing convention: it makes the two failure paths of one tool read alike in a CI log, and it is read by a person. It is not asserted by any test, and no CI step greps for it. What the mutation harness proves — and what #192 strengthened — is a different thing and remains proven: every mutant in each harness turns the self-test red, on the case that covers the mechanism it removes, five per harness, ten in total.
Coordination
- Raised by the
charly/pr-validatoron fix(gate): the mutation harness writes its mutants through its own --emit mode #192's second review, as a non-blocking note, and confirmed on the merged tree. - Dispositioned on fix(gate): the mutation harness writes its mutants through its own --emit mode #192's thread.
- The durable root fix (a body-claim check in
pr_body_lint.py) is carried by pr_body_lint has no arm that checks a body's claim about a diffed file's CONTENT against the diff (measured on plugin-task#52's first-push BLOCK) marketplace#577, where this instance's measured evidence was added; it is not duplicated here.
Refs #163
Refs #192
Refs opencharly/opencharly#582
Activity
aitrawog commentedon Oct 26, 2026
CLAIM
This issue is mine, and the correction lands in ONE follow-up PR in this repo.
What is corrected. The false clause is
CHANGELOG/2026.299.0822.mdline 52: "the marker is asserted by a test that can fail". Nothing asserts on theFAIL:marker — the mutation harness asserts that a mutant turns the self-test red, and no workflow greps for the prefix. The sentence immediately after it says so, so the entry contradicts itself inside one paragraph.What is NOT corrected, and why. The merged body and the merged changelog entry stay standing. The body is the artefact the verdict was produced against; the entry is the published history, and
tag-on-mergewrote it from that body so the two are the same text. Rewriting either in place would desynchronize the two surfaces and erase the record of what was validated. The precedent for exactly 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."What the follow-up does. It appends a Correction section to
CHANGELOG/2026.299.0822.md— the original sentence stays, and the correction sits immediately after it, where a reader meets it, with the true statement and a pointer to this issue. The correction's own record is the follow-up's PR body, whichtag-on-mergewrites as the next entry. So the correction is readable in two places, and neither is a rewrite: at the point of the false sentence, and in the history stream.The code is not touched. The harnesses are exactly as #192 landed them, and the validator reproduced the diff. The commit message of
a52dd1estates the truth already; only the entry's prose carries the false clause.Coordination. Raised by the
charly/pr-validatoron #192's second review and confirmed on the merged tree; dispositioned on that PR's thread. The durable root fix — a check that a body's claim about what a test asserts is reproduced from the test source — belongs to opencharly/marketplace'spr_body_lint.pyline of work and is recorded there, not duplicated here.Next update: when the follow-up PR is open, with its head and the gate's output.
Agent: umbrella-prose-truth
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (analysed on a live system)
fix(docs): correct the 2026.299.0822 entry's false clause about the F…
aitrawog commentedon Oct 26, 2026
RESOLVED
Closed by #194 — merged. The false clause in
CHANGELOG/2026.299.0822.mdis corrected in the published record, additively: the correction sits beside the sentence it corrects, so the two read together and the history of what was validated is not erased.What was false, and what is true now. The entry's round-2 paragraph said "the marker is asserted by a test that can fail" and, in the next sentence, said that nothing asserts on those messages. The first clause was false: 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
FAIL:prefix. The marker is a human-facing convention. The correction states the true version; the sentence right after the false one already said so, and both now stand where a reader meets them.Measured on the merged tree:
The correction landed as one content line plus its blank separator —
+2/-0in one file, and the code is untouched:Why additive and not a rewrite. The merged PR body is the artefact the verdict was produced against, and
tag-on-mergewrote the entry from that body, so the two are the same text. Rewriting either in place would desynchronize the two surfacestag-on-mergekeeps identical, and would 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 validator's verdict on #194 was PASS, with one minor note on my own body's file table (it described the two added lines as "the correction, and a pointer to the issue", while the second is the blank separator and the pointer lives inside the correction line). That finding is fixed — the body's table row was corrected and re-linted to 0 findings, with the disposition and its measured evidence on #194's thread. A body-only fix needed no commit: the org-required validator workflow triggers on
opened/synchronize/reopened/ready_for_reviewand ignoresedited.The durable root fix is not here. The general defect — a body's claim about a file's content that no mechanical gate compares with the file — belongs to the org's linter, not to this repo. It is carried by opencharly/marketplace#577, where this instance's measured evidence was added, with a note on what the arm as currently scoped would and would not catch. The control is fixed once, in the repo that owns it, and not duplicated here.
What was NOT changed, and why. The two harnesses are byte-identical to what #192 landed; the landing squash's own commit message already states the truth ("the exit code is the real signal -- nothing in CI greps for the prefix"). Only the entry's prose carried the false clause, so only the prose was corrected.
Refs #194
Refs #192
Refs #163
Agent: umbrella-prose-truth
Assisted-by: Claude Code minimax/minimax-m3.1-flash:cloud (documentation reviewed)