Withdraw M4's null as evidence about the guard (#122) - #123
Merged
Conversation
No run in either arm received injected context. Both arms are defined by receiving records; neither did. The comparison was nothing against nothing, and its null is not a weak result about the guard — it is not a result about the guard. Established by restoring the pinned harness 081d858 and probing it: the saved transcript carries no occurrence of commitlore, Ruled-out, Limit: or active records anywhere in its text. A recording gap would leave the context in the transcript and empty only the field. It was never delivered. The corrected statistical analysis stays. McNemar p=0.1094, ICC 0.581, DEFF 8.56, effective n 13, four saturated tasks — all still true about the data and all irrelevant as evidence about the guard. Both things need saying and the verdict now says both. Provenance is unchanged and still clean: one harness commit, one dist digest, 112 rows, no mid-run rebuild. The failure sits upstream of provenance. The harness recorded faithfully what it did, and what it did was run both arms without records. Ruled-out: retracting the dataset or calling M4 invalid | the data is valid and its provenance is clean; what it measured was not the treatment, and those are different words Limit: the guard question is now unanswered rather than answered null Blast: system Undo: costly Certainty: firm Record-Id: r-m4withdraw
CommitLore — record lintTrailers: clean — 1 commit in Active constraints for the paths this PR touchesLimits (25)
Ruled out (57)
Warnings (30)
Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
MongLong0214
added a commit
that referenced
this pull request
Jul 28, 2026
Co-authored-by was ingested as a record and classified [claim], so on a repository that uses it routinely — which is any repository with AI-assisted commits — a path's whole projection filled with attribution lines and crowded out the decision context the command exists to deliver. The reported repository had 175 trailers over 173 commits and returned three co-author lines for Package.swift and nothing else. CONVENTIONAL_TRAILER_KEYS names the set in one place: Co-authored-by, Signed-off-by, Reviewed-by, Acked-by, Tested-by, Reported-by, Suggested-by, Cc and Change-Id. Matching is on the lowercased key, because all three of Co-authored-by, Co-Authored-By and Co-authored-By occur in the same real history and a case-sensitive list would have fixed a third of the problem. Fixes and Closes are deliberately not in the set. They name the issue a change addresses, which is closer to decision context than to attribution — an agent reading "Fixes #123" learns something a co-author's name never tells it — so they still land in "other" rather than being discarded with pure attribution. The exclusion is counted rather than silent, so a user who wonders where an attribution line went can find out instead of concluding the trailer was never parsed. Verified end to end rather than by unit: a scratch repository whose only trailer is Co-authored-by now reports no active records, and one carrying Co-Authored-By, Signed-off-by and a real Limit reports the Limit alone. Ruled-out: excluding Fixes and Closes with the rest | they carry decision context an agent can use, and discarding them would trade a projection full of attribution for one missing the issue a change answers Limit: the denylist answers a different question from isRecordKey's allowlist, so a conventional trailer this protocol later claims would need removing from one and adding to the other Blast: system Undo: easy Certainty: firm Record-Id: r-convtrail150
MongLong0214
added a commit
that referenced
this pull request
Jul 28, 2026
Co-authored-by was ingested as a record and classified [claim], so on a repository that uses it routinely — which is any repository with AI-assisted commits — a path's whole projection filled with attribution lines and crowded out the decision context the command exists to deliver. The reported repository had 175 trailers over 173 commits and returned three co-author lines for Package.swift and nothing else. CONVENTIONAL_TRAILER_KEYS names the set in one place: Co-authored-by, Signed-off-by, Reviewed-by, Acked-by, Tested-by, Reported-by, Suggested-by, Cc and Change-Id. Matching is on the lowercased key, because all three of Co-authored-by, Co-Authored-By and Co-authored-By occur in the same real history and a case-sensitive list would have fixed a third of the problem. Fixes and Closes are deliberately not in the set. They name the issue a change addresses, which is closer to decision context than to attribution — an agent reading "Fixes #123" learns something a co-author's name never tells it — so they still land in "other" rather than being discarded with pure attribution. The exclusion is counted rather than silent, so a user who wonders where an attribution line went can find out instead of concluding the trailer was never parsed. Verified end to end rather than by unit: a scratch repository whose only trailer is Co-authored-by now reports no active records, and one carrying Co-Authored-By, Signed-off-by and a real Limit reports the Limit alone. Ruled-out: excluding Fixes and Closes with the rest | they carry decision context an agent can use, and discarding them would trade a projection full of attribution for one missing the issue a change answers Limit: the denylist answers a different question from isRecordKey's allowlist, so a conventional trailer this protocol later claims would need removing from one and adding to the other Blast: system Undo: easy Certainty: firm Record-Id: r-convtrail150
MongLong0214
added a commit
that referenced
this pull request
Jul 28, 2026
Co-authored-by was ingested as a record and classified [claim], so on a repository that uses it routinely — which is any repository with AI-assisted commits — a path's whole projection filled with attribution lines and crowded out the decision context the command exists to deliver. The reported repository had 175 trailers over 173 commits and returned three co-author lines for Package.swift and nothing else. CONVENTIONAL_TRAILER_KEYS names the set in one place: Co-authored-by, Signed-off-by, Reviewed-by, Acked-by, Tested-by, Reported-by, Suggested-by, Cc and Change-Id. Matching is on the lowercased key, because all three of Co-authored-by, Co-Authored-By and Co-authored-By occur in the same real history and a case-sensitive list would have fixed a third of the problem. Fixes and Closes are deliberately not in the set. They name the issue a change addresses, which is closer to decision context than to attribution — an agent reading "Fixes #123" learns something a co-author's name never tells it — so they still land in "other" rather than being discarded with pure attribution. The exclusion is counted rather than silent, so a user who wonders where an attribution line went can find out instead of concluding the trailer was never parsed. Verified end to end rather than by unit: a scratch repository whose only trailer is Co-authored-by now reports no active records, and one carrying Co-Authored-By, Signed-off-by and a real Limit reports the Limit alone. Ruled-out: excluding Fixes and Closes with the rest | they carry decision context an agent can use, and discarding them would trade a projection full of attribution for one missing the issue a change answers Limit: the denylist answers a different question from isRecordKey's allowlist, so a conventional trailer this protocol later claims would need removing from one and adding to the other Blast: system Undo: easy Certainty: firm Record-Id: r-convtrail150
MongLong0214
added a commit
that referenced
this pull request
Aug 18, 2026
A blind refutation round on this branch broke three of the four claims I put to it, and verifying one of them found a defect it had not been looking for. `gh pr create` renders "GitHub closes #123 as merged" into the canonical pull request's body. GitHub binds a closing keyword to the number straight after it, and a pull request closed by keyword is recorded closed with `mergedAt` null -- the opposite of the sentence containing it, and the opposite of what T-1502 accepts. Measured on #752 six hours ago: an integration body said "GitHub closes #752, #755, #756 ... as merged", the keyword bound to #752 alone, and that one was recorded closed while the five with no keyword were recorded merged. There is no API to convert it afterwards. This workflow would have reproduced it on every run, and no test read the body. Two ticket statements were also wrong against the file. "The job never checks out or executes a pull request's head" was borrowed from the rule #723 fixed for `preserve`, which only reads a pull request; this one rebuilds it, and rebuilding somebody's change means running it. Unsatisfiable as written, so it would have been dropped rather than met -- what the job split actually holds is that the runner executing that code has no credential. And the negative control the ticket named, skipping `artifact:manifest`, cannot be performed from a pull request: the step is hard-coded in a workflow loaded from the default branch and the source-only filter refuses workflow edits. A negative control nobody can run is the defect it was written to prevent, so it is replaced with one that can be: edit `dist/` on the pushed canonical branch and watch `ci.yml` go red. Limit: the canonical pull request asks for a merge commit and cannot enforce one -- squash and rebase are both enabled and the button remembers the last method used, which is how #760 closed five of six as merged Blast: module Undo: easy Certainty: firm Record-Id: r-t1502body Provenance: authored Verified: restored the keyword and watched the new test fail naming `closes #123`, then restored the fix and saw 21 tests pass across both workflow test files CommitLore-Version: 2.0.0
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No run in either arm received injected context. Both arms are defined by receiving records; neither did.
Established by restoring the pinned harness
081d858cand probing it — the saved transcript contains no occurrence ofcommitlore,Ruled-out,Limit:oractive recordsanywhere in its text. A recording gap would leave the context in the transcript and empty only the field.What changes
The verdict's headline. Its null stops being an answer about the guard and becomes an observation about data that measured no treatment.
What does not
Provenance is clean — one harness commit, one dist digest, 112 rows, no mid-run rebuild. The failure is upstream of provenance: the harness recorded faithfully what it did, and what it did was run both arms without records.
The corrected analysis stays. McNemar p=0.1094, ICC 0.581, DEFF 8.56, effective n≈13, the four saturated tasks — still true about the data, irrelevant as evidence about the guard. The verdict says both.
M4 is not retracted and not called invalid. Its data is valid; what it measured was not the treatment. Recorded in
Ruled-out:.The harness fix is a separate branch (
bug-issue-122) so the correction to the record and the correction to the code are reviewed apart.Tests 1385 / 39 files.
check-readme-numbers.mjsexit 0.