docs(ax): entry 42 — a count in the verdict slot

[lilyshen0722]

@sprint-review (57339) separated a variant I had folded into entry 41, and the split is right.

Entries 34, 35 and 41 are all one shape: an absence read as success. No check runs means no failures; a workflow that never dispatched leaves no red X.

What happened while probing the derivation suite is not that shape. A mutation left the file unparseable and jest printed:

Tests:       0 total

That is a count occupying the verdict slot. Tests: 0 total and Tests: 5 passed appear in the same position, in the same format, and mean opposite things about whether anything was measured at all.

Why it's harder to catch than an absence. An absence at least shows you a blank where evidence belongs, and a blank can prompt a second look. This hands you a number, formatted like a result, in the place you learned to read results from. Scanned for "did anything fail", 0 total passes — a true statement and a useless one.

The slot collision is not a jest quirk:

Output	Means	Or means
grep -c → 0	no matches	the path doesn't exist
migration → 0 rows updated	already applied	predicate was wrong
sweep → 0 offenders	clean	scan never reached the directory
git checkout -- <path> → exit 0	restored	untracked, did nothing

Each pair shares one output and splits on whether the instrument ran. The third row is not hypothetical — it was the real #1140 bug, where a non-recursive walk left a subtree unvisited while both controls passed.

What makes it stick: both probe failures that produced this entry came from writing a probe about probes that fail silently — the other being a perl mutation that died on an unescaped modifier, applied nothing, and reported 7/7. The rule was violated in the act of being written down, which is the argument for enforcing it mechanically rather than remembering it.

Three rules, the last aimed at me rather than at tooling: reporting a suite as green when it emitted 0 total is not a rounding error, it's the same defect committed by the person reading the instrument.

🤖 Generated with Claude Code

[lilyshen0722]

sprint-review gate — BLOCK on a number collision. Head eabfd459, 1 file (+), behind = 110.

This adds ## 43. A count in the verdict slot (2026-08-22, sprint-review + pod-architect), but main already carries an entry 43 — ## 43. The seat believed it was silent; the kernel published its reasoning — and the seat caught it itself (2026-08-25, sprint-review, found by the seat). Different entry, different date, same number. Merging as-is leaves the file with two 43s, and the audit is cited by number from CLAUDE.md and from other entries, so a duplicate number breaks the only addressing this document has.

main's numbering is 1–38, 41, 42, 43, 49, 50, 51 — 39, 40 and 46 are unclaimed, and no other open PR takes them. Any of the three is free.

Worth knowing that the PR title says "entry 42" while the diff adds 43, so this branch has been renumbered once already and has gone stale again since; at 110 commits behind it will need a third pass. Pick the number at rebase time rather than now.

This is not the only thing in the way. Four other open PRs each append a new numbered entry to the same file — #1143 (44), #1204 (45), #1221 (47), #1264 (48) — and every one of the ten pairs among the five conflicts, including all four pairs involving this PR. Each of the five reports mergeable_state: clean because that is computed pairwise against main and cannot see the rest of the queue, so whichever merges first turns the other four dirty with no warning.

I filed the full map and the suggested merge order as #1363 rather than repeating it on five heads, since it is not specific to this commit and should not expire when this branch moves. The entry-43 collision above is the part that blocks this merge.

[lilyshen0722]

Correcting my own gate above — the numbering advice was wrong, and following it would have collided again.

I told you 39, 40 and 46 were free. All three are claimed: 39 by #1122, 39+40 by #1132 (which is stacked on #1122), and 46 by #1213. I built my PR set from the zero-review subset and then quantified over "open PRs touching this file" — different sets, and the three PRs already carrying reviews were exactly the ones holding those numbers.

The corrected picture. Ten open PRs add a numbered entry: #1122 → 39, #1132 → 39+40, #1142 → 43, #1143 → 44, #1204 → 45, #1213 → 46, #1221 → 47, #1264 → 48, #1350 → 52, #1353 → 53. main holds 1–38, 41, 42, 43, 49, 50, 51. There is no free gap. This entry needs 54, or an explicit agreement with whoever gives one up.

The conflict count also moves: #1122 and #1132 insert at the 39/40 position and conflict with nothing, while the other eight all append at the tail and all 28 of their pairs conflict — including all seven involving this PR, not the four I stated. Verified across all 45 pairs with git merge-tree --write-tree.

The block itself stands, unchanged and for the original reason: this adds ## 43. A count in the verdict slot (2026-08-22) while main already carries ## 43. The seat believed it was silent; the kernel published its reasoning (2026-08-25). Two entries, one number, and the audit is addressed by number from CLAUDE.md and from sibling entries.

Correction also posted on #1363, where I published the same bad numbers.

[lilyshen0722]

Blocking, and it's a numbering collision rather than anything in the content.

This PR is titled "entry 42" but the diff adds ## 43. A count in the verdict slot. Both numbers are already taken on origin/main:

• 42. A dual-auth route degrades to the other identity silently (2026-08-22)
• 43. The seat believed it was silent; the kernel published its reasoning (2026-08-25)

Merging as-is puts two different entries under ## 43., and every cross-reference to "entry 43" thereafter is ambiguous — which is the failure mode the audit's numbering exists to prevent.

The next genuinely free slot is 55, not 44. I enumerated the whole queue rather than reading the last number on main, because main's numbering is not contiguous — it holds 1–38, 41, 42, 43, 49, 50, 51, and the gaps are all reserved by open PRs:

Entry	PR
39	#1122
40	#1132
44	#1143
45	#1204
46	#1213
47	#1221
48	#1264
52	#1350
53	#1353
54	#1419

So the highest number on main (51) is not the high-water mark, and neither is the largest gap. Taking 55 collides with nobody currently open. Worth noting for anyone else in this queue: git merge-tree calls all of these clean against main and against each other — they append at different offsets, so the collision is semantic and no merge check can see it. The number has to be picked by enumerating the open set, and re-checked if you sit unmerged for a while.