Repository navigation
skill lost: a body that is not its own — and the prototype that was right because one alternative was dead - #3214
Merged
Merged
Conversation
SKILL 556 found two headings in docs/NOW.md with nothing under them, at
lines 6359 and 6361. Repairing them turned up a third entry the
empty-body check could not see, because it HAD a body -- just not its
own.
SW-conformance — gf96 0 lines -> its own 23
Wave Loop 434 — boot-evidence 0 lines -> its own 45
SW-conformance — gf48 39 lines, all W434's -> its own 17
Fifty lines below its heading, gf48 carried "### What landed (Variant B
-- board reachable, P12/relay still blocked)" and
XADC_LIVE_W434_OPERATING_POINT: FPGA boot evidence under a software
conformance promotion. All 39 of its lines came from W434's 45, and six
of W434's were gone outright.
SKILL 556 reported "31 of Wave Loop 434's 34 substantial lines are still
elsewhere in the file, so most of that content survives". Both halves are
true and the conclusion is wrong: they survive under the WRONG heading,
which is misattribution and worse than loss. Nineteen of the thirty-four
appear exactly once and are W434-specific, and every one of those sat
under gf48; the other fifteen appear up to twenty-five times each and are
boilerplate. "Still in the file" is the same unit error as "50 red
workflows" -- the container is not the claim.
Restoring gf48 from its last NON-EMPTY body would have restored the
damage: at 5057850 that body was W434's. The selector has to be
content, not emptiness -- the last version whose first lines actually
mention `gf48 (GoldenFloat48`. Same shape as SKILL 559: absence is not
the discriminator, identity is.
Verified: 310 headings before and after, 0 titles lost, 0 empty bodies,
exactly 3 bodies changed.
SKILL 565.
Refs #3195
SKILL 565 found one entry carrying another's body, by accident, while repairing something else. The question left was whether that was a case or a class. This asks it: an entry whose body names NONE of its own identifiers and does name one another entry owns. Measured: 1 on the damaged base, 0 on the repaired tree, 0 in SKILL.md across 524 sections. The naive question is useless here. 58 of the 63 docs/NOW.md entries with a wave number in the heading mention some OTHER wave, because an entry routinely points at the next one. Naming none of its own discriminates. THE PROTOTYPE GAVE THE RIGHT NUMBER FOR THE WRONG REASON. The python sketch reported 1 on the damaged file; ported to Rust it reported 49. The difference is one alternative: `\b#` requires a word character immediately before the `#`, and there is never one, so that branch matched nothing ever. The sketch silently compared waves and formats only -- which happens to be the correct population -- and reported the correct number while carrying a rule it never applied. Had it shipped, the code would have said "issue numbers count" and the behaviour would have said otherwise until someone fixed the regex, at which point the tool would have changed its mind for no visible reason. Issue numbers are now excluded deliberately, with that measurement written beside the pattern. Both test fixtures were wrong and both tests were right to fail: XADC_LIVE_W434_OPERATING_POINT does not match, because the `_` before W434 is a word character and the pattern is anchored on a word boundary -- what made the live case detectable was the plain `wave-loop-434` on its branch line. And a fixture with entry 889's body naming 888 and 890 but not 889 asserted no flag, which is exactly the shape that should flag. SKILL 568. Refs #3195
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Sep 5, 2026
Merged
…ns on sets 644 identifier occurrences visible to the shipped matcher, 988 to a wider one: 35% invisible, 79 of them the underscore form W<nnn> inside a longer identifier. Real, and the wrong number. The check operates on SETS. Those 344 extra occurrences buy FOUR extra distinct identifiers (339, 470, 825, 883); only 10 of 310 entries have a different body id-set; and the verdict is 0 on the repaired file and 1 on the damaged one under both matchers. Constructed the blind spot by hand as well -- strip the single plain line from the damaged entry, leaving underscore forms only. Both matchers still find it: the body names W431 and W432 in prose. The predicted blind spot has no instance in this repository. Declined. Widening costs a false-positive surface and buys nothing measurable. The audit's value was not the answer but learning that the worry was counted in occurrences while the thing it threatened was set membership -- SKILL 535 turned on the instrument instead of the report. SKILL 571. Refs #3195
The message of b299090 lost a literal. It was written in a heredoc that the shell expanded, and the phrase in backticks -- the branch line wave-loop-434, spelled with backticks around it -- was run as a command rather than quoted. The sentence now reads "strip the single plain / line from the damaged entry". The intended sentence: strip the single plain wave-loop-434 line (the one on the entry's Branch: row) from the damaged entry, leaving only the underscore forms. Both matchers still find it. Fourth time in this session that backticks inside a double-quoted or heredoc string have been expanded. It is recorded in my notes and I wrote it anyway; the note now says to use a quoted heredoc delimiter for any message containing backticks, which is what this one uses. The commit cannot be amended -- force-push is forbidden here -- so this is the correction of record. Refs #3195
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 00:44:24 UTC
Summary
Seal Status
|
This was referenced Sep 5, 2026
Merged
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 01:14:15 UTC
Summary
Seal Status
|
…ong one
SKILL 571 asked in which unit a check DECIDES against the unit a reader
AUDITS it in, and declined to widen a matcher because the two agreed. A
fan-out over the whole CLI asked that everywhere. The strongest survivor
is in the code that pass wrote.
`bodies()` keys by section title -- correct for the history walk, since a
title is the identity that survives renumbering. Every OTHER question was
asked over that map too. A repeated heading text is one key, and the
later insert OVERWRITES, so only the last copy's body is ever examined.
Measured on docs/NOW.md: 312 heading lines, 310 distinct texts.
`Honesty limits (BINDING)` at 1479 and 1708; a `Wave Loop 777` subject at
4504 and 4601. The command printed "present on origin/master 310" for a
312-heading file and asked "does every heading have a body?" over 310
seats -- while four comments in that same source file said 312.
I measured 312-vs-310 in SKILL 556, wrote it into the prose, and then
built the tool on the map that collapses them.
The verdict was right by luck: all four colliding occurrences have bodies
(30/18 and 34/34 non-blank), so hollow is 0 either way. It flips the
first time a repeated subject's EARLIER copy is bare.
Fixed by separating the two questions instead of picking one:
titles ever written 792
headings on origin/master 312 (## lines)
distinct titles 310 (what the history walk compares)
Hollow and misattribution now run over occurrences(), which collapses
nothing; the history walk keeps the title map, because that is what makes
renumbering invisible to it.
Both structural tests failed again and both were right to -- second time
in two passes that restructuring a guard broke the test pinning it. They
now assert the ARGUMENT rather than the call, so two of the three mutants
no longer compile.
SKILL 577.
Refs #3195
Collaborator
Author
Update: the units fan-out found this PR's own codeA workflow swept the whole CLI asking "in which unit does this count DECIDE, and in which unit would
Measured on
I measured 312-vs-310 in SKILL 556, wrote it into the prose, and then built the tool on the map that The verdict was right, by luckAll four colliding occurrences have bodies (30/18 and 34/34 non-blank lines), so hollow is 0 either Fixed by separating the questions, not picking oneHollow and misattribution run over Both structural tests failed again, and are now pinned to the populationThey asserted 745 crate tests. SKILL 577. |
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 01:18:23 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-05 01:38:48 UTC
Summary
Seal Status
|
This was referenced Sep 5, 2026
fix(rust): lower Zig's undefined to Default::default() (+2) — NOT auto-merged, needs your call
#3223
Closed
Merged
Contributor
PR DashboardGenerated at: 2026-09-05 02:01:51 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 5, 2026
Contributor
PR DashboardGenerated at: 2026-09-05 02:23:22 UTC
Summary
Seal Status
|
gHashTag
enabled auto-merge (squash)
September 5, 2026 02:24
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-05 02:30:50 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
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.
#3212 repaired one entry carrying another's body, found by accident while fixing something else. The
question it left: was that a case or a class?
tri skill lostnow asks it — an entry whose body names none of its own identifiers and does nameone another entry owns.
Measured: 1 on the damaged base, 0 on the repaired tree, 0 in
SKILL.mdacross 524 sections.The naive question is useless here
58 of the 63
docs/NOW.mdentries with a wave number in the heading mention some other wave,because an entry routinely points at the next one. Naming none of its own is what discriminates —
SW-conformance — gf48carried 39 lines of Wave Loop 434 and never saidgf48.The prototype gave the right number because one alternative was dead
The python sketch reported 1 on the damaged file. Ported to Rust it reported 49. One
alternative accounts for it:
\b#requires a word character immediately before the#. There is never one — that branchmatched nothing, ever. The sketch silently compared wave and format identifiers only, which
happens to be the correct population, and reported the correct number while carrying a rule it
never applied.
Had it shipped, the code would have said "issue numbers count" and the behaviour would have said
otherwise, until someone fixed the regex and the tool changed its mind for no visible reason.
Issue numbers are now excluded deliberately, with that measurement written beside the pattern —
with
#NNNNlive, 49 of 312 entries flag and the one real case is buried.Both fixtures were wrong, and both tests were right to fail
XADC_LIVE_W434_OPERATING_POINTdoes not match: the_beforeW434is a word character, so\bWfails. What made the live case detectable was the plain`wave-loop-434`on its branch line.exactly the shape that should flag.
Two fixtures, two failures, both because the fixture was unrepresentative and the code was right.
Same lesson as #3210, one pass later.
744 crate tests. Five mutants run, all killed — two only after the fixtures were corrected, and two
more (call site never asks; foreign ids not required to be owned by a heading) after the first
round left them alive.
SKILL 568. Refs #3195