check:route-envelope cannot discover packages/rest/src/error-response.ts — a response-emitting module outside the naming convention

[qq9340100]

Filed unassigned by the dev seat working #8850. Observation-class: no gate is red, nothing is broken today. This records a latent reduction in check:route-envelope's coverage that #8850's own PR creates, so it is not lost.

What was measured

#8850 moves the ADR-0112 error/fault-classification prologue out of packages/rest/src/rest-server.ts into a new packages/rest/src/error-response.ts. Two of the response write sites travel with it — sendError and handleRouteError, both res.status(...).json(resolved.body).

Measured with the checker's own scanSource, on the #8850 branch head:

file	responses	ok	err	privateOk	stringError	siblingCode
packages/rest/src/error-response.ts (new)	2	0	0	0	0	0
packages/rest/src/rest-server.ts (after the move)	not pinned (dialectOnly)	—	—	—	44	69

rest-server.ts's ratchet is unmoved — 44 / 69 before and after — because every one of its dialect sites is inside the class body, and the moved prologue contained none. pnpm check:route-envelope is green on the branch. Nothing needed editing and nothing was edited.

The gap

discover() in scripts/check-route-envelope.mjs collects a file only when its basename ends in -routes.ts or appears in OFF_CONVENTION_MODULES. error-response.ts matches neither, so the new module is invisible to the audit entirely.

Before the move, a new non-conforming error dialect written next to sendError landed in rest-server.ts and was counted by the stringError / siblingCode ratchet. After the move, the same literal written in error-response.ts is counted by nothing. The counts are 0 / 0 today, which is exactly the moment the ratchet is worth pinning.

This is the cost the checker's own header names:

The convention is the discovery surface, so anything outside it is invisible until it is named here — which is not a hypothetical cost. rest-server.ts was outside for as long as this gate has existed (#7295), while being the largest response-emitting file in the repo.

Why #8850 did not fix it in place

#8850's dispatch fixed its file surface at packages/rest/src/**, with an explicit instruction to stop on breach and explain rather than widen. scripts/check-route-envelope.mjs is outside it, so the gap is reported here instead of patched under that card.

Suggested remedy

The gate's own documented onboarding path, roughly four lines:

1. add 'error-response.ts' to OFF_CONVENTION_MODULES, with a one-line reason;
2. add 'packages/rest/src/error-response.ts': { responses: 2, ok: 0, err: 0 } to MODULES.

Worth confirming while doing it: the conformant entries in that table are all 0 / 0 / 0, so a responses: 2 entry is the first of its shape and should be read against auditModule before being assumed legal. The alternative shape is a dialectOnly entry, which would be the wrong instrument here — this module's write-site count is stable, which is precisely what dialectOnly exists to accommodate the absence of.

Refs: #8850 (the move that creates this), #7295 (why rest-server.ts is dialectOnly), #7035 (the ratchet's named end state).

[qq9340100]

Claim: PM loop round 14 — cross-lane takeover under the maintainer's 2026-08-13 clause (a blocking item that is mechanical, spec-clear and S-sized is done by the seat it blocks, rather than waited on).
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Seat: domain:cli (this card's file, scripts/check-route-envelope.mjs, is domain:devx — flagging the boundary rather than pretending it is mine)
Landing in: PR #8887 (#8850), the PR that creates the gap
File surface: scripts/check-route-envelope.mjs — two table entries only
Container & model: folded into the in-flight #8850 dispatch, opus

⛔ Labels deliberately untouched. Grading finding cards in this lane is the devx/triage seat's call, not mine; I am taking the work, not the grading.

Why this is being folded in rather than left to queue

The gap is created by #8887, and it is latent rather than red: error-response.ts emits 2 response bodies but is invisible to discover() (neither *-routes.ts nor in OFF_CONVENTION_MODULES), so a non-conforming dialect literal written there would now be counted by nothing — where the same literal beside sendError in rest-server.ts was counted before.

The decisive argument is the timing, and it is the dev's rather than mine: 0/0 is the cheapest possible moment to pin a ratchet, because from there it can only ever tick up into a failure. Once a literal exists in that module the pin stops being a four-line addition and becomes a red gate somebody has to resolve under pressure. This is also the gate's own documented onboarding path — its header says adding a name is cheap and the module then has to appear in MODULES or the audit fails, "which is the point."

I originally leaned the other way (land #8887 clean, leave this to the devx queue). I am overruling myself: leaving another lane to close a hole this lane dug, at the one moment closing it is free, is the wrong trade.

Condition on the fix — not a formality

Every conformant entry in that table is 0/0/0. A responses: 2 entry would be the first of its shape, so auditModule gets read before the entry is written. If a non-zero responses count is not legal there, the dev stops and reports rather than inventing a table shape — in which case this card goes back to the devx seat with that measurement attached, and #8887 lands without it.

⚠️ This is explicitly not a ledger edit of the #8848 kind. check:route-envelope's counts for rest-server.ts did not move (stringError 44 / siblingCode 69, measured with the checker's own scanSource before anything was touched) and no existing ledger line is being changed. This adds a new module to the audit's field of view; it weakens nothing.

The devx seat should feel free to reshape or revert this — it is four lines in your file, taken because the timing was free, not because the lane boundary moved.

---

Generated by Claude Code