Correct #3205: the census it shipped already existed, with a stronger method - #3207
Merged
Merged
Conversation
… method `tri unparsed report --list` names the same eight specs #3205 announced -- the five `specs/` imports and the three `algorithm` blocks -- ranked by construct, each row backed by a live probe, and confirmed by causality through REMOVAL rather than by showing a conversion moves the error. Its module header already stated the lesson #3205 presented as new, naming the same four examples. The framing was also inverted. That report prints these rows under `work queue -- every row proved unsupported by its own probe` and keeps a separate one-row list headed `refused ON PURPOSE -- a position, not a gap`. So the project's position is that `import` and `algorithm` are compiler gaps to implement; #3205 asserted no compiler change could retire them. `t27c known` was run before shipping and answered "Nothing speaks to this." That is true of its population -- gates under `tools/`, baselines, a paper -- and not of the repository, which holds the answer in `cli/tri/src/`. Skill section 554 is rewritten from the claim that was wrong to the lesson that was real: an all-clear is scoped to what was searched, and this one prints its own scope on its first line. The corpus figures, the ledger-at-cap reading, the three controls and the W643 audit from #3205 are unaffected and restated. Refs #3204 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
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 4, 2026
The previous commit rebuilt this file on master by TITLE, keeping every section present here and absent there. One of them was 554 'Debt a fix cannot retire is a different kind of debt' -- and master did not LACK it, master had rewritten it, in 6a49402 'Correct #3205', because the claim was wrong. A by-title rebuild cannot tell a section I authored from one the base deliberately removed. Both read as 'present here, absent there'. Eight passes of resolving this file that way, and the hole only showed the first time master withdrew something. Two discriminators failed before one worked: - the MERGE BASE is useless once you have already merged: it becomes master's head, and both sections look equally new. - ANCESTRY is useless because master squashes: the commit that introduced the withdrawn section is not an ancestor of master, and neither are mine. What works is master's own HISTORY of the text: git log origin/master -S'<title>' -- SKILL.md 'Debt a fix cannot retire' -> 2 commits: 6d333d3 added it (#3205), 6a49402 removed it (#3207). My two sections -> 0 commits each. A title master's history has ever held, but its head does not, was taken out on purpose. 520 sections, nothing of master's lost, nothing withdrawn resurrected. Refs #3195
gHashTag
added a commit
that referenced
this pull request
Sep 4, 2026
…e headings in docs/NOW.md (#3206) * feat(tri): skill lost -- the audit that found nothing, and why that is the result SKILL 552 repaired one section whose body the tooling destroyed. The obvious next question is whether it was the only one. `tri skill lost` walks every commit that touched the file, records each section's body the first time it appeared, and reports any whose body on the base is a strict PREFIX of that first version. An edit in place is not a prefix; a truncation is. Measured over 281 commits and 518 titles ever written: titles ever written 518 present on master 516 bodies that are a strict prefix of an earlier 40 of those, trailing blank lines only 38 real cut tails 2 Both real cut tails are reorganisations, checked rather than assumed: an unnumbered `## Writing a gate here` block that moved (a body runs to the next NUMBERED heading, so a moved unnumbered block reads exactly like a truncation), and one paragraph. Both still on master. Both absent titles are deliberate: one rewritten under a longer heading with 43 of 43 substantial lines alive, and one withdrawn on purpose by 7071b07, whose subject is "withdraw a claim of mine" and whose body gives the two master runs that refuted it. Zero unexplained losses. SKILL 550 was the only one, it was caused by the tool in this session, and it is repaired. A clean audit is what makes that a closed incident rather than a sample of an unknown population. The command prints the caveats in its own output, because the next reader hits the same two false leads: a missing title is not a loss, and a cut tail is not a loss when an unnumbered block moved. Eighth pass running whose surviving mutant was the wiring -- `if truncated(then, n)` replaced with `if false` makes the command walk 281 commits, find nothing by construction, and report health forever, with all three tests on `truncated` green. FIRST one found by mutating the call site before writing any test for the helper, which is the rule the previous seven produced. SKILL 553. Refs #3195 * skill: renumber onto origin/master (guarded) Refs #3195 * feat(tri): skill lost --file, and two bare headings in docs/NOW.md The plan was "run the same audit over docs/NOW.md". Checked before built: that file has ZERO numbered headings. 312 of them, every one shaped `## fix(...)` or `## Wave Loop 434 — ...`. A --file flag on a command that insists on `## N. ` would have walked 810 commits, found an empty population, and printed a clean bill of health. The check that stopped it cost one grep -c, and it is the same question as "does this gate have a subject". So the key generalised instead: strip a leading `N. ` when there is one, otherwise the heading IS the key. Renumbering stays invisible -- half of what happens to SKILL.md is renumbering -- and NOW.md becomes a population for the first time. Found present tense, with no history at all: 2 heading(s) with an EMPTY body on origin/master: SW-conformance — gf96 promoted to strict SW-bitexact (Closes #1366) Wave Loop 434 — FPGA boot-evidence live XADC validation ... docs/NOW.md lines 6359 and 6361 -- two CONSECUTIVE bare headings, nothing under either. SKILL.md: 0 of 523. Their history says how much: 25 and 59 lines. For Wave Loop 434, 31 of 34 substantial lines survive elsewhere in the file. For SW-conformance, 2 of 21 survive and the rest is in no tracked file. This question is strictly cheaper than the history walk and answers most of it -- one read against 810 `git show` -- so it is asked first. NOT published as a finding: the same run says 792 titles ever, 310 present. Those 482 are not 482 losses. NOW.md mixes rotating status sections meant to be replaced with per-change entries that are not, and separating them is a different measurement. The command prints the figure and does not characterise it. Three mutants, all killed after two survived first: the hollow filter was inline so an inverted test built its own copy, and section_key's fixtures had no non-numeric dotted prefix to discriminate `v1. Something`. SKILL 556. Refs #3195 * skill: restore the master section my --ours resolution dropped `tri skill renumber` REFUSED this merge, naming the section it would drop -- the guard shipped two passes ago, working exactly as designed. I then resolved the conflict with `git checkout --ours`, which takes my side wholesale and discarded master's new section anyway. master 518 -> 520 lost 1 Debt a fix cannot retire is a different kind of debt The guard lives in the tool. My hand procedure walks around it. That is SKILL 536 -- the fix lived in the tool and the probe went around it -- repeating, with the probe now being a git command rather than a shell pipeline. Rebuilt on master by TITLE: 520 sections, nothing of master's lost, all three of this branch's sections present, ascending, no duplicates. Refs #3195 * skill: drop the withdrawn section my by-title rebuild resurrected The previous commit rebuilt this file on master by TITLE, keeping every section present here and absent there. One of them was 554 'Debt a fix cannot retire is a different kind of debt' -- and master did not LACK it, master had rewritten it, in 6a49402 'Correct #3205', because the claim was wrong. A by-title rebuild cannot tell a section I authored from one the base deliberately removed. Both read as 'present here, absent there'. Eight passes of resolving this file that way, and the hole only showed the first time master withdrew something. Two discriminators failed before one worked: - the MERGE BASE is useless once you have already merged: it becomes master's head, and both sections look equally new. - ANCESTRY is useless because master squashes: the commit that introduced the withdrawn section is not an ancestor of master, and neither are mine. What works is master's own HISTORY of the text: git log origin/master -S'<title>' -- SKILL.md 'Debt a fix cannot retire' -> 2 commits: 6d333d3 added it (#3205), 6a49402 removed it (#3207). My two sections -> 0 commits each. A title master's history has ever held, but its head does not, was taken out on purpose. 520 sections, nothing of master's lost, nothing withdrawn resurrected. Refs #3195 * docs: SKILL 559 -- absence from the head is not evidence of authorship Refs #3195
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.
An hour after #3205 merged,
tri unparsed report --listprinted the same eight specs itannounced. This corrects the record. #3204 is closed as superseded.
Already in the tree
cli/tri/src/unparsed.rsranks the constructs that stop the parser, each row backedby a live probe:
The five
specs/imports plus the threealgorithmblocks are exactly the eight#3205 named — same files. Its method is stronger: causality by removal ("a
confirmed item is one whose removal MOVES the reported error"), with 14 candidates
refuted that way. #3205 showed only that a conversion moves the error, the weaker
half of the same test. Its module header already stated the lesson #3205 presented
as new, naming the same four examples.
The framing was inverted
That report prints these rows under
work queue -- every row proved unsupported by its own probe, and keeps a separate one-row list headedrefused ON PURPOSE -- a position, not a gapholding onlyx as T. The project's recorded position is thatimportandalgorithmare compiler gaps to implement. #3205 asserted nocompiler change could retire them — the opposite.
Why the anti-rediscovery tool did not stop it
t27c known --dir . --about "..."was run before shipping and answered "Nothingspeaks to this. Measure -- and record the negative, it is a result." That is true of
its population — gates under
tools/, baselines, a paper — and not of the repository,which holds the answer in
cli/tri/src/. The command prints its own scope on itsfirst line,
gates read from .../tools, and I did not treat that as the caveat it is.Control:
max_entriesoccurs 0 times undertools/and 24 times in therepository, so the zero was the scope, not the tree.
Changes
an all-clear is scoped to what was searched
docs/nowentry recording the correctionUnaffected and restated: the corpus figures, the ledger-at-cap reading, the three
controls, and the W643 audit.
Refs #3204