limit 29: the pin is stale on main, and the suite is shaped so it cannot see it

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.

[githubscum]

The work order

Run the check that limit 29 recommends to every reader, and see whether anything
in this repository actually runs it. Nothing does, and the artifact it guards is
wrong.

What it found

The committed pin is stale on main. It names 2173d231 (stamped
2026-08-23). The last commit touching the source tree is dc1910b (#36). The
reader-side check reports divergence and exits 1 on a clean main checkout, and
has since #36 landed. A reader following the instruction printed in the pin block
is correctly told they are reading a description of somewhere else.

The suite is green at 891 while that is true, and the two tests named for the
real log are why. Both write the state they then assert:

• one runs --stamp on the shipped log and then asserts the check reports
  current. Proves the stamp path works. Cannot fail on a stale committed pin,
  because it overwrites the pin before reading it.
• the other writes a foreign hash in and asserts exit 1. Proves the check path
  works. Cannot fail on a stale committed pin either, for the mirror reason.

The committed value is never read by anything. That is limit 29's own thesis one
level up: the mechanism built to make staleness detectable is never pointed at
the artifact, and its tests are shaped so they structurally cannot fail on it.
The 2026-08-23 fix said "the check exists, the automation does not." This is what
that cost.

Second defect, same read. Those two tests reach green by writing to the
tracked log and restoring in a finally. A finally survives an assertion
failure, not a killed process. An interrupted npm test can leave the shipped
confession log carrying a fabricated commit hash, in the file this repository's
own tooling stages and commits. The entry already says a false pin is caught only
by review; the suite that tests the pin can manufacture one unattended.

What is NOT in this PR, deliberately

No re-stamp. The obvious repair is a read-only test asserting the committed
pin equals the last source commit. It fails on main today, so landing it needs
a re-stamp in the same change, and the tool's own header says stamping is a claim
that the entries were verified against that tree. This lane has not read 61
entries against dc1910b. Re-stamping to go green would be precisely the
dishonesty the pin exists to prevent. The stamp is owed by whoever verifies,
and that is the reviewer's call, not this lane's.

No test-isolation fix. It is separable and needs no stamp: an env override on
the log path, git resolution left anchored to the repo, so the mutation tests use
a scratch copy. That edit lands in a self-mod gated directory and was blocked
unsigned while this ran. Named in the entry rather than smuggled into a file the
gate happens to allow.

Tested

• Full suite: 891/891 green, 151 suites.
• The stale pin was confirmed by comparing the committed pin against
  git log -1 -- src, not inferred.
• The false green was confirmed by running the pinning test file directly and
  watching all 7 pass against a log whose committed pin is wrong.
• Docs-only. Zero source changes, zero deletions, 60 added lines. The pin block
  itself is untouched, verified in the diff.

What a reviewer should doubt

1. That "stale" is the right word. The pin targets the last source commit by
   design, so a commit touching only docs or tests does not stale it. I checked
   the source pathspec specifically. If you think the pin should track something
   else, the entry's framing changes.
2. Whether refusing to stamp is discipline or an excuse. A reasonable
   reviewer could say the stamp is mechanical and the lane should have run it.
   The counter-argument is in the entry; the decision is yours.
3. Whether the interrupted-run hazard is real enough to record. It needs a
   process kill inside a ~150ms window. I judged it worth recording because the
   file is one this repo's tooling commits, and because a limit found and not
   written down is worse than one never found. You may rate it lower.
4. The claim that no other test reads the log's content. I grepped the test
   directory; only this file reads or writes it. A miss there would change the
   concurrency argument.

[githubscum]

Provenance, stated rather than left to lapse. This was written on-meter, not
dispatched to a local executor. Three prior runs of this lane measured the 870
timing out on artifacts of this size (280s on a ~1500-token draft, two 100s+
empty returns before that), so the lane's own note says to stop budgeting a
draft of this shape on it. Nothing was dispatched this run, and no local model
was left resident.

One block worth recording. The intended first half of this work order was the
test-isolation fix, which needs an edit inside a self-mod gated directory. That
edit was blocked unsigned and was not reshaped to get around the matcher. The
gate did the right thing; the change is named in the entry instead.

[githubscum]

Run 6 advanced this branch: the numbering hole this PR's own limit was built to prevent

This PR reported that the pin is stale and that no test reads the shipped log.
Looking for what a read-only test on the real log would catch, I found something
already broken on main, and it is worse than a stale pin.

Entry 25 does not exist

main today carries 60 numbered entries running 1 to 61. 25 is missing. No
duplicates, no other gap.

dc1910b (PR #36, the outside contributor's destructive-matcher fix) appended an
amendment to entry 24 and, in the same hunk, deleted the ## 25. heading line.
Nothing else about entry 25 was touched. Its body, three paragraphs on gh as
the authenticated vendor CLI the rules could not see, has been sitting inside
entry 24 ever since.

Two consequences, both live on main right now:

1. A citation of "KNOWN-LIMITS 25" resolves to nothing.
2. A reader of entry 24 ("the destructive allowlist exempts real directories
   named tmp/temp/scratchpad") gets a section that changes subject mid-way to an
   unrelated limit about GitHub's CLI.

This is the 2026-08-22 incident again, the one limit 29 and the pin exist
because of, except that the number now means nothing rather than something else.
It survived code review and 891 green tests.

What this commit adds

• The heading, restored. A faithful revert of the deleted line. The body was
  never moved and is not moved now; only the heading comes back. Verified after:
  61 entries, contiguous 1 to 61, no duplicates.
• A read-only structural test on the shipped log. Contiguity from 1,
  uniqueness, and a sanity floor so a broken parse cannot pass by finding zero
  headings. It opens the committed file, writes nothing, and needs no pin.
• An amendment to entry 29 recording the whole thing, because a limit found
  and not written down is worse than one never found.

Still not fixed, and the reason has not changed

The stale pin. This run verified the log's structure; it did not read 61
entries for truth against dc1910b. Stamping on the strength of a numbering
check would be a smaller lie than stamping on nothing and would still be one.
The stamp stays owed to whoever verifies. That is doubt #2 from the original PR
body, unchanged.

What a reviewer should doubt

1. Whether restoring the heading is the right repair at all. The alternative
   reading is that fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36 meant to fold gh into 24 and only forgot to renumber. I
   do not believe it (the commit message says "amend limit 24" and nothing about
   25; the deletion sits inside an unrelated hunk), but the person who merged fix(C6): scope rm trigger to its segment; check every git-clean pathspec; amend limit 24 #36
   can settle it in one sentence and I cannot. If folding was intended, the fix
   is a tombstone at 25, not a restoration, and the test still belongs.
2. Whether contiguity is the right invariant. It forbids ever retiring a
   number. That is deliberate here, since the whole point is that external
   citations must keep resolving, but it is a policy choice and it should be made
   on purpose rather than inherited from my test.
3. The sanity floor is a magic number. It is set well below the current count
   so it does not need touching on every entry added, which also means it is weak.

Provenance

Off-meter dispatch was attempted and failed: the local 870 was warmed
successfully (18.4s load, resident in /api/ps) and then returned nothing on a
~900-token test draft inside a 240s timeout. That is the fourth measured failure
at this artifact size, so the test file and the prose were both written
on-meter. Stated rather than left to inference.

Fail-first and the full suite were run before the push; results are in the
commit message.

[githubscum]

Run 7 advanced this branch again: the same defect class, checked from the other side

Run 6 left a note saying a second structural check was worth considering and had
not been written. This is that check, though not the one the note described.

What it does

The numbering test from run 6 asks whether the log is intact: does every
number from 1 to the highest have an entry under it. This asks whether the
pointers into it are intact: does every citation in the tree name an entry
that exists.

Those are different failures. An entry can vanish, which is what happened in
dc1910b. Or a citation can name a number that never existed, which happens
when a number is typed wrong in a comment, or written ahead of the entry it
means to cite. The log can be perfectly contiguous while a comment in the source
sends a reader to nothing.

It scans every .js / .mjs / .md / .json file in the tree for the explicit
KNOWN-LIMITS <n> form and asserts each cited number resolves. Read-only, no
pin, no git, no fixture.

The result is a null, and it is written down as a null

No dangling citation exists. Every citation in the tree resolves, and every
one resolved on main too. I checked before writing the test, per the method
that worked last run, and the check came back clean.

So this is a guard against a class of defect that has already occurred twice in
this file, not the discovery of a live one. The header of the test says exactly
that. A null recorded carefully is worth more than a null quietly reshaped into
a find, and this lane has enough tests already that a reviewer needs to be able
to tell which is which.

Fail-first, both halves

A green repo-wide assertion over a clean repo proves nothing on its own, so:

1. The resolver is exercised against a synthetic citation that cannot resolve,
   inside the suite, every run.
2. End-to-end proven by hand before the commit: a temporary file citing a
   nonexistent entry turned the suite RED and reported it as
   <file>:1 cites 4242. The probe was removed and the tree verified clean.

Full suite 898/898 (895 before, +3).

What a reviewer should doubt

1. The scope is narrow and that is a judgment call. Only the explicit
   KNOWN-LIMITS <n> form is scanned. The bare limit <n> shorthand is roughly
   twice as common in the tree and is skipped, because it collides with ordinary
   prose like "rate limit 5". That means the majority of references are
   unguarded. I think the collision makes the loose form unscannable without
   false positives, but someone who disagrees would get a much stronger test.
2. Whether a guard with no live defect behind it earns its place in the suite.
   It costs about a second per run walking the tree. The argument for it is that
   this exact file has broken twice; the argument against is that this direction
   has never broken once.
3. The floor is a magic number again, same weakness the numbering test has,
   and for the same reason.
4. The test scans itself, which is a real footgun: a nonexistent number typed
   into its own comments fails the suite on the comment. It is named in the
   header so it is not rediscovered, and the synthetic fixture is built by
   concatenation to dodge it. That is subtle enough to be worth a second opinion.

Provenance and what did not happen

Written on-meter, stated rather than left to inference. Four prior runs of
this lane measured the local 870 returning nothing or timing out on drafts of
this size, and the lane's own note now says to stop dispatching test files to
it. Nothing was dispatched this run and no local model was left resident.

No new PR was opened, on purpose. Five are open and none has a review
comment yet. The lane can produce faster than review absorbs, and a sixth PR
would be a cost rather than an output. This is the second consecutive run that
advanced a branch instead.

PR #33 was again not reviewed. The desk row pay-auth-pr33 still reads
needs_signed, so the gate held for the sixth run. That PR is now nine days
open from an outside contributor, waiting on one signed row.