feat(tri): skill refs -- every cross-reference, and whether it resolves - #3056
Merged
Conversation
`tri skill refs` resolves every cross-reference in the skills against the sections that actually exist. On this file at this commit: 438 sections, 224 references (212 by symbol, 12 written out), 17 pointing at nothing across 7 distinct numbers, and 8 references carrying no number at all. The numbers are a fingerprint. 234, 235, 240, 241, 245, 253 is a consecutive block inside the never-used 226-260 gap, and the sections those pointers describe are alive at +47: 234->281, 241->288, 253->300, each verified by reading what the pointer SAYS the target says. A renumbering moved the sections and left the pointers. A dangling pointer is not a broken link. "Related: 241, a guard whose precondition had stopped holding" is a claim about what this file contains, and the claim is false -- worse than a missing one, because a reader who does not check believes it. Two details a count would hide, both printed. Six -- now eight -- references carry no number at all, `(§--the same rule the widths ledger states...)`, which a resolver of numbers cannot see. And the written-out form is counted apart from the symbol form, because the words can be about a document that is not this one. It reports and does not fail: fixing a pointer means deciding what it MEANT, and that is a reading, not a rename. Section 474 records three pairs that contradict, all three read by hand. 19 against 23: the same coverage gate, the same breakdown, under 136 and 121, with nothing marking the change. 369 against 370: 369 says fixing the family "moves the accept count by nothing" and 370 says "+68 ... the largest single lever in the project" -- 370 is right AND corrects the wrong section, opening "Section 366 says..." when the sentence it quotes is 369's, so one correction left 369 uncorrected and blamed 366 for a sentence it never wrote. 281 against 290: "gets both conventions right at once" against "finds no definition at all in 231 of 650 specs". The file already has an in-place RETRACTED marker convention, ruled by section 34, and none of the three uses it. The figures in 473 were corrected before committing: written against the tree before these sections existed the command said 436/189/6/12, and the sections quote the dead numbers as examples -- writing about dangling pointers created five more occurrences of them. The distinct count did not move; a citation of a dead number is not a new dead number. Seven clauses mutated, seven killed. Two survived until fixtures were written for the only inputs that discriminate them: `section12` glued to its digits, and the literal section sign as opposed to the HTML entity. Skill sections 473 and 474. Refs #2994
This was referenced Sep 3, 2026
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-03 20:24:56 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 3, 2026
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-03 20:52:50 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-03 21:04:29 UTC
Summary
Seal Status
|
Conflict in the skill file: master took 473, so the two sections added here are renumbered 474 and 475. Master's copy of the file was taken whole and the two sections re-appended, which is the only resolution that cannot lose a neighbour's work. The figures in the first of them were re-read from the merged tree as the last action before this commit, per section 470: 439 sections, 224 references, 8 with no number at all, 17 pointing at nothing across the same 7 distinct numbers. The dangling count did not move across the merge -- the sections master added carry no dead pointers.
Contributor
PR DashboardGenerated at: 2026-09-03 21:15:32 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
gHashTag
added a commit
that referenced
this pull request
Sep 3, 2026
Refs #3051 Tenth collision. Also a correction to the previous commit's reasoning: I said a multi-ref `git fetch origin master w48b-tri-fmt` had left origin/master stale. It had not -- the parent of that merge is 6c54ab3, which was the tip at the time, and #3056 landed afterwards. Master moved between the merge and the check. The w48b-tri-fmt ref failure earlier in the session WAS real; conflating the two was my error.
gHashTag
added a commit
that referenced
this pull request
Sep 3, 2026
…3066) * tri topic: has someone already done this, or are they doing it now? Closes #3065 Twice in one session I started work another session had shipped or had open. #3049 shipped `tri gates quiet` and `tri gates empty`, which cover two of the four lenses a 29-agent fan-out of mine was scanning at the same moment. #3056 shipped `tri skill refs` -- every cross-reference and whether it resolves -- which is the tool for a dangling pointer I had just written a paragraph about. The first was an OPEN PULL REQUEST the whole time I was scanning. The second was a merged commit. Neither was hard to find afterwards; both were free to find before, and the reason I did not is that it takes four commands and none of them is habit. So: one command over open PRs, open issues, the last N commits on the base branch, and every SKILL.md section title. A row matches on any keyword and rows are ordered by how many DISTINCT keywords they carry -- ranking by occurrences would put a title repeating one word above one carrying two. Verified retroactively on both collisions: each comes out at the top of its own query. It prints the DISTRIBUTION rather than applying a threshold. 468 of 694 on a three-word query is not a result, and a cutoff would need a number nobody has measured -- which is the mistake that produced a three-state column with no correct members earlier the same day. It refuses when `gh` cannot answer, and says so in the words this repository uses. "Nobody else is working on this" and "I could not ask" are the same empty list, which is the defect the last five issues here have all been about. Four mutants, four kills, each by exactly one test, with passed+failed asserted against the expected six every time -- because `cargo test topic` also matches `issues::tests::the_matcher_reads_the_claim_and_not_the_topic`, and a filter that catches somebody else's test is how a mutant reads as surviving. Stated in the module rather than left to be found: it reads titles, not bodies or diffs, so a pull request whose title does not name its subject is invisible here, and the ordering is a word count, not an understanding. * skill: a verification that only prints is a suggestion Refs #3065 The section this session earned twice over. My own check printed OK=False -- 442 sections where 440 were expected -- and I pushed. The file had three of master's sections duplicated. The tool was handed the wrong input, which is ordinary; the lesson is that the guard which caught it reached nobody because its answer was a line of text rather than an exit code the push was downstream of. Two smaller versions the same hour, both caught because the guard sat in the right place: a stale binary answered with its usage text (the merge was resolved but never concluded, so the binary predated the code), and a completed merge still did not have origin/master as an ancestor because master moved underneath it. The section is placed by the command it sits next to, so its number came from tri skill renumber rather than by hand -- and this commit's own check gates the push on exit code, which is the thing it is about. * topic: refuse a keyword carrying spaces Refs #3065 Found on this command's SECOND use, by me. `for q in "a b c"; do tri topic $q; done` in zsh does not word-split, so the whole phrase arrived as one keyword, matched nothing, and the command answered `rows matching 0` -- which reads as "nobody else is working on this". That is the exact sentence this command exists to keep from being said wrongly, produced by its own input handling, four queries in a row, and I believed all four until I re-ran one I knew had matched. Refused rather than answered, with the split spelled out. A single word padded with spaces is not a quoting mistake and is not flagged -- mutating the guard to `k.contains` instead of `k.trim().contains` kills that assertion. Prior art, checked rather than assumed: pytest reserves exit code 5 for "No tests were collected" as a public-API outcome distinct from 1 (tests failed), 2 (interrupted), 3 (internal error) and 4 (usage error). This repository's convention -- 2 for everything that is not a reading -- is coarser than the field's by one distinction: "the instrument is missing" and "the population is empty" are the same code here and different codes there.
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.
A pointer at a section that does not exist is a false claim
The numbers are a fingerprint.
234, 235, 240, 241, 245, 253is a consecutive block inside the never-used 226–260 gap, and the sections those pointers describe are alive at +47 — 234→281, 241→288, 253→300, each verified by reading what the pointer says the target says. A renumbering moved the sections and left the pointers.A dangling pointer is not a broken link.
Related: §241, a guard whose precondition had stopped holdingis a claim about what this file contains, and the claim is false — worse than a missing one, because a reader who does not check believes it.Two details a count would hide, both printed:
(§—the same rule the widths ledger states…). A resolver of numbers cannot see these; there is no number to fail.section 245) is counted apart from the symbol form, because the words can be about a document that is not this one.It reports and does not fail: fixing a pointer means deciding what it MEANT, and that is a reading, not a rename.
Three pairs of sections contradict each other
All three read by hand:
coveragegate, the same breakdown (99 orphaned, 81 with a twin), under 136 and 121. Nothing marks the change§370 is right and it corrects the wrong section — it opens "Section 366 says…" while §366 is about
tri prose reportagainsttri unparsed report; the sentence it quotes is §369's. So one correction produced two defects: §369 is left uncorrected, and §366 is blamed for a sentence it never wrote.The file already has an in-place
**RETRACTED, see §N.**convention, ruled by §34, and none of the three uses it. A convention that exists and is skipped is not a convention.Reported, not repaired — and had §19 and §23 each named a sha, this would be a history rather than a contradiction.
The section about dangling pointers created five more
The figures in §473 were corrected before committing. Written against the tree before these sections existed, the command said
436 / 189 / 6 / 12. The sections quote the dead numbers as examples, so writing about dangling pointers added five occurrences of them. The distinct count did not move — a citation of a dead number is not a new dead number.And the total on the references line moves with every sentence written about it: correcting it from 223 to 224 was itself a citation. §470's rule earned its place immediately.
section12glued to its digits, and the literal§as opposed to§cargo test -p tri— 549 passed, 0 failedRefs #2994