docs(tooling): keep the read-seam rule's repaired #8845 exhibit as history and record the blind-spot measurement

[os-project-manager]

Fixes#9004

Comment-only change to scripts/check-durability-degradation-log-level.mjs. The gate's behaviour, vocabulary, scan roots and baselines are untouched — the diff is 53 added / 6 removed lines, every one of them a comment line.

The problem

The header block "Measured and DELIBERATELY NOT added — the FALL-THROUGH / empty-accumulator criterion (#8845)" named cascadeDeleteRelations in the present tense, twice, as a live fail-open instance. That seam was repaired by #8895 (a751f7d4f), so the block taught a repaired defect as a current one.

Both failure modes were live:

• deleting the exhibit would destroy the evidence for a decision still in force — the block exists so the next author reads the numbers before re-proposing the criterion, and The read-seam invention rule has no declared failure-propagation vocabulary, so "the catch reported the failure" is uncheckable — the blocker measured under #8845 #8901 cites it as the authority for exactly that;
• leaving it would send the next reader to a seam they will find already repaired, from which the whole measurement reads stale.

So the exhibit is kept as history, with its tense made true.

Does the measurement's conclusion survive? Yes — and #8895 strengthens it

Checked leg by leg. The conclusion ("this shape does not need a looser invention criterion; it needs a declared failure-propagation vocabulary") rests on six supporting arguments. Five are untouched by #8895. The sixth — the jump-only narrowing that "buys its number by exempting three REAL instances" — needs at least one genuine instance to stand, and still has two.

Two ways #8895 is evidence for the conclusion, both now recorded in the block:

1. The gate's output is byte-identical before and after the repair — 67 read seam(s) … (7 … discriminated) (1 pass … through) (1 baselined) on both trees. Measured by ablating the repair back to its pre-ObjectQL.cascadeDeleteRelations fails OPEN: a failed dependents probe skips the restrict guard entirely, so a delete that should be refused succeeds silently #8895catch { continue } and re-running, with the ablation's diff scope proven to be the single intended hunk.
2. The shape of the repair is the direction the block argues for — it discriminates through a declared predicate (isMissingTableError) rather than a hand-rolled code test. That is the "declared, checkable fact" the block asks for, applied by hand at one seam because no gate could ask for it.

I went one step past the filed measurement: planting a return [] in that same catch turns the gate red, naming engine.ts:10084 (in cascadeDeleteRelations()). So the seam sits in the census throughout — reported clean while it was broken, and reported clean now that it is repaired. What decides visibility is the shape of the exit, never whether the seam is correct. Surveyed, cleared, harmful: the #6116 shape a fourth time.

The number question — anchored, not decremented

No census number is changed. The block already anchors every count to origin/main @ 8664a2c, and I verified that anchor is real rather than decorative: the gate answers 66 read seams at 8664a2c and 67 on today's main. The extra seam was gained after that commit, and is not from #8895 — the ablation moves nothing.

Decrementing by hand would have been arithmetic standing in for a census. Re-deriving the whole census against today's tree would have swapped a reproducible number for an undated one, and re-done #8845's work inside a documentation-accuracy card. Instead the anchoring is made explicit and load-bearing, so the numbers stay checkable by anyone who runs the gate at that commit.

Each exhibit verified independently

Not assumed to have moved together with #8895:

exhibit	state
cascadeDeleteRelations (objectql)	repaired by #8895 — discriminates, then rethrows
searchAll (metadata-protocol)	unchanged, live — silent per-object continue
findReferencesToMeta (metadata-protocol)	unchanged, live — silent valueless return
checkGovernance (objectql lifecycle)	unchanged, live — #8906 remains open

Verification

Union re-run after the final commit, at 80fdecc9d, clean tree:

• pnpm check:durability-log-level — pass, including its 35-case read-seam self-test. Its output is identical to the pre-edit baseline, which is the direct proof the change is inert.
• pnpm check:cross-package-test-inputs — pass. Not named in my dispatch prompt; picked up by re-deriving node scripts/pm/dispatch-gates.mjs against the actual changed path.
• node scripts/check-nul-bytes.mjs — pass, plus a control-character self-scan over the edited file, since the change discusses code shapes.

skip-changeset: scripts/-only and comment-only, so nothing user-visible is released.

Out of scope

• check-durability-degradation-log-level: collectLoggedLevels only recognises a logger named logger/log/console, so a catch that reports through an injected logger reads as silent to BOTH rules #8897 (pm:on-hold) names this file as its restart trigger. Its three-way is answered on that card: declined here and re-held on the same trigger, with the hold's premise re-verified (the one live injected-logger seam still invents no answer, so the misclassification remains unreachable). It is not addressed in this PR.
• The read-seam invention rule has no declared failure-propagation vocabulary, so "the catch reported the failure" is uncheckable — the blocker measured under #8845 #8901 remains open and lifecycle checkGovernance: a failed row-count probe silently drops the object from quota/growth alerting and from nextCounts, losing the next sweep's growth baseline too (split from #8896) #8906 remains open. Neither is touched here.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 16, 2026 7:15am