feat(tri): recover the anchor from git for windowed sections the text does not date - #3029
Merged
Conversation
… does not date
Section 457 counted nine sections here stating a figure over a sliding
population and naming no anchor. Writing a date into each was the wrong
follow-through twice over: it edits nine sections of prose to fix a
defect that is not in the prose, and the dates would be invented by the
editor rather than measured.
They are not missing. `git blame` over the section's own line range
answers the question the text does not, and `tri skill claims
--windowed` now prints it under every windowed section that carries no
anchor of its own:
NO ANCHOR ci-gates 179 A `--limit` on a run list is a time window
last written no later than 2026-08-29 (e817fbe)
Nine dates recovered, none written by hand. Section 179 resolves to the
same commit by an independent `git log -S` -- two mechanisms, one answer.
What it says: the NEWEST commit touching any line of the section, so it
bounds how FRESH the figure can be -- taken no later than this. It is
not when the reading was taken and cannot be, since a typo fixed in
September carries a September date over an August number. It is a bound,
printed as a bound, beside 457's upper bound in the other direction.
The newest, not the oldest: the oldest answers when the section was
started, which any later edit invalidates. The fixture is deliberately
out of order so "the last one seen" and "the newest" cannot both pass.
And it prints a DATE, not an age. "Stale by 12 days" was written first,
and it is exactly the defect this line of work is about -- an age is a
figure over a sliding population, changing every midnight, so quoting it
makes a claim that rots. The rule caught its own tool before it shipped.
Seven clauses mutated, seven killed: newest-versus-oldest,
newest-versus-last, the forty-character commit id, the `author-time`
key, and all three range boundaries. The length check earns its place on
a real shape -- blame content lines are tab-prefixed, so `deadbeef` in a
code block would otherwise be adopted as the answer.
`section_ranges` is kept apart from `section_bodies` rather than
widening its tuple, and a test pins the two walkers to the same set of
sections: a range attached to the wrong section would date the wrong
claim, silently and plausibly.
Refs #2994
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
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
1 participant
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.
Section 457 counted nine sections here that state a figure over a sliding population and name no anchor. The obvious follow-through was to write a date into each. That is the wrong move twice over: it edits nine sections of prose to fix a defect that is not in the prose, and the dates would be invented by the editor rather than measured.
They are not missing.
git blameover the section's own line range answers the question the text does not:Nine dates recovered, none written by hand. Section 179 resolves to
e817fbec5by blame and to the same commit by an independentgit log -S— two mechanisms, one answer.What the date says, and what it does not
It is the newest commit touching any line of the section, so it bounds how FRESH the figure can be: taken no later than this. It is not when the reading was taken, and cannot be — a typo fixed in September carries a September date over an August number. So it is a bound, printed as a bound, sitting beside §457's upper bound in the other direction.
The newest, not the oldest. The oldest answers when the section was started, which any later edit invalidates. The test fixture is deliberately out of order so that the last one seen and the newest cannot both pass.
And it prints a DATE, not an age
stale by 12 dayswas the first thing written here, and it is precisely the defect this whole line of work is about: an age is a figure over a sliding population. It changes every midnight, so quoting it anywhere makes a claim that rots. A date does not move. The rule caught its own tool before the tool shipped.Seven clauses, seven kills
newest-versus-oldest · newest-versus-last · the forty-character commit id · the
author-timekey · and all three range boundaries. Each mutant killed a test; nothing survived unproved.The length check earns its place on a real shape: blame content lines are tab-prefixed, so
deadbeefwritten inside a code block would otherwise be adopted as the answer.section_rangesis kept apart fromsection_bodiesrather than widening its tuple — three call sites and four tests read that shape — and a test pins the two walkers to the same set of sections. A range attached to the wrong section would date the wrong claim, silently and plausibly.cargo test -p tri— 494 passed, 0 failedRefs #2994