docs(spec-tooling): fix stale envelope-attribution claim in check-driver-conformance

[os-help]

Fixes #7159

What

scripts/check-driver-conformance.mjs, FILTER_TEXT requirement 3's comment block claimed driver-mongodb's default: arm was "the last place a bare new Error escaped the ADR-0112 envelope" — a repo-wide claim. It was already false when written (objectql's having face had two bare new Error returns escaping the same envelope, per #6993's census), and after #7047 (edb4af099, merged via PR #7161, confirmed on origin/main in this branch's ancestry) the claim became true but misattributed — having, not driver-mongodb, was the actual last site.

Fix

Scoped the clause to the DRIVER family — checkable against this gate's own case-set (the five driver refusals FILTER_TEXT requirement 3 covers) rather than a repo-wide sweep that can go stale the next time a new face is added. Kept the trailing note (per the issue's own argument) that having sat outside this gate's scope (packages/drivers/*), since that gap is the reason two consecutive defects on that face (#5905, #7047) were found by hand-run censuses instead of CI.

Diff:

-//      `code` half the case-set requires and the last place a bare `new Error`
-//      escaped the ADR-0112 envelope.
+//      `code` half the case-set requires and the last bare `new Error` in the
+//      DRIVER family (this gate's own scope, `packages/drivers/*`). The sixth
+//      refusal face — objectql's `having` (`having-filter.ts`) — was outside
+//      that scope and kept its bare `new Error` until #7047.

Prose-only, one file, no case-set/gate-logic/exit-code change.

Durability of the fix

The card's own test for this class of bug: will the corrected sentence still be accurate, or visibly wrong, after the next face is added? The new claim is scoped to "last bare new Error in the DRIVER family (this gate's own scope)" — that's checkable directly against the FILTER_TEXT requirement-3 case-set this comment sits inside, so a future driver face regressing would be a claim about the same five-driver scope the gate already enumerates, not an unscoped repo sweep. It can still go stale if a sixth driver is added and its refusal predates the DRIVER-family claim without anyone re-auditing — same failure shape as this issue, one level narrower — so this is "checkable / narrower blast radius" rather than "provably permanent."

Verification

$ pnpm check:driver-conformance
OK  self-test: detects driven / unused / re-declared fixtures, discovers both axes, ...
...
check-driver-conformance: OK — 36 covered cell(s), 4 in the DEBT ledger, 0 exempt.

Both the --self-test half and the real check pass unchanged — no case-set or DEBT-ledger count moved.

$ node scripts/check-nul-bytes.mjs
check-nul-bytes: OK (scanned 6620 text file(s) ...; no raw ASCII control bytes).

Out of scope

Left all other prose in this file untouched, including any other comment blocks noticed in passing, per this card's scope fence.

---

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 10, 2026 3:17am