A script named verify_all_152.py has never parsed, and nothing looks for conflict markers - #2874
Merged
Conversation
`scripts/verify_all_152.py` -- a verification script by its name, whose docstring promises 152 formulas at 50-digit precision -- carries eight unresolved `Updated upstream` / `Stashed changes` conflicts, two of them nested. `ast.parse` on it is a SyntaxError. It has been that way since f1fb145, the commit that introduced it: checked, there is no earlier clean revision to restore. Nothing imports it and nothing runs it. Nothing looked for the shape. A second marker sat in `.claude/skills/ci-gates/SKILL.md` from 2c0ce54 (#2574) until #2865 removed it by hand during an unrelated merge. `tri skill check` read that file and reported OK, because it checks section numbering. tools/check_conflict_markers.py 7592 files read, 1 carrying, 60 not read It abstains on a bare seven-equals line: that is an ordinary Markdown rule and this repository has hundreds, while git always writes the divider BETWEEN two LABELLED markers, so the labelled pair alone is sufficient. The gate builds its own patterns from `"<" * 7` rather than literals -- the first draft contained them and refused its own source, which the self-check caught. The workflow carries no `paths:` filter, and the reason is specific rather than inherited: a marker can land in any file, so a filter would be a filter on where the defect may hide. `verify_all_152.py` is recorded in the baseline WITH ITS REASON rather than repaired. Resolving it means choosing which of 152 numeric formulas is right, and that is the owner's call. The gate reports a baseline line that has outlived its debt, so the record cannot quietly become an excuse. Self-check covers six branches including both controls: a clean tree must stay silent, a bare divider must abstain, a planted marker must be seen at the right lines, a baselined file must be counted but not new, a baseline outliving its debt must be reported, and the gate's own source must be clean. Refs #2873, #2756, #2574 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
gHashTag
enabled auto-merge (squash)
August 29, 2026 19:40
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
2 participants
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.
scripts/verify_all_152.pycarries eight unresolved merge conflicts, someof them nested:
It does not parse:
It has been that way since
f1fb1456b, the commit that introduced it —checked: there is no earlier, clean revision to restore. Nothing imports
it and nothing runs it (
git grep verify_all_152outside the file itselfreturns nothing), so it has never executed once.
The name is the sharp part. A file called
verify_all_152.py, whose docstringsays "Verify all 152 Trinity formulas with 50-digit mpmath precision", is an
instrument. Anyone reading the tree sees a verification script and reasonably
assumes the 152 formulas are verified by something. What is actually there is
a syntax error.
Nothing looks for the shape
A second marker sat in
.claude/skills/ci-gates/SKILL.md(committed in2c0ce54e8, #2574) and was found by hand while resolving an unrelated merge —removed in #2865. No check in this repository looks for conflict markers, and
tri skill checkreports OK on a skill file containing one, because it checkssection numbering and nothing else.
What this adds
tools/check_conflict_markers.py— scans every tracked file, refuses the onescarrying an opening or closing marker. Measured on master: 7592 files read,
1 carrying markers, 60 not read (binary; the abstention is printed rather
than folded into the pass).
It abstains on a bare
=======. Seven equals signs with nothing after themis an ordinary Markdown rule and this repository has hundreds; git always
writes that line between two labelled markers, so refusing on the labelled pair
alone loses nothing and invents no false positives.
The file is recorded in
tools/conflict_markers_baseline.txtwith the reasonrather than being repaired, because repairing it means choosing which of 152
numeric formulas is right, and that is not a gate's judgement to make.
What the owner decides
formulas are verified somewhere else, this file is a misleading duplicate;
if they are not, this is the gap.
baseline entry that has outlived its debt, so it will say when that happens.
Refs #2756, #2574.
Controls
The planted-marker expectation was wrong on the first run — I predicted lines
2 and 5, the answer is 2 and 6. The self-check said so before the gate ran on
anything real.
Refs #2873