The REST door's own `sendError` overload does not narrow, so an unregistered `error.code` reaches the wire there too

[os-project-manager]

Found while implementing #8087 (the dispatcher-door vocabulary gate). Filed unassigned; nobody is on it. Not fixed in that PR — it lands in packages/rest, outside that card's domain:cli file surface.

The gap

#8087's premise rested on an asymmetry between the two doors, stated in resolveThrownHttpError's module note and in packages/runtime/src/package-door-error-parity.test.ts:

The direct-mount REST door needs exactly this: sendError's closed ErrorCode parameter [...] so an unregistered code there is a failing test, not a wire answer.

That holds for sendError in @objectstack/types (packages/types/src/response-envelope.ts), whose code parameter is the closed ErrorCode:

export function sendError(
 res: EnvelopeResponse,
 status: number,
 code: ErrorCode,
 message: string,
 extra?: Pick<ApiError, 'category' | 'httpStatus' | 'details' | 'requestId'>,
): void

But packages/rest has a second, same-named responder, and it is the one REST route modules reach for:

// packages/rest/src/error-response.ts
export function sendError(res: any, error: any, object?: string): void {
 const resolved = resolveErrorResponse(error, object);
 logWithheldServerFault(error, resolved);
 res.status(resolved.status).json(resolved.body);
}

error: any. No narrowing, no closed vocabulary, no type error.

The measured instance

sendFieldVisibilityFault in that same file (ADR-0106 D6 tier 3) hands it a code the ledger does not register:

sendError(res, {
 code: 'FIELD_VISIBILITY_UNRESOLVED',
 message: `Field visibility for object '${objectName}' could not be evaluated; the object schema is not being served.`,
 status: 503,
});

FIELD_VISIBILITY_UNRESOLVED is in neither StandardErrorCode nor ERROR_CODE_LEDGER, so that 503 body cannot parse against ApiErrorSchema — and, because BaseResponseSchema embeds it, the whole response body fails to parse, not just the nested error object. (That last point is measured in #8087's suite, per code.)

Derived mechanically, not by eye:

$ node scripts/check-dispatcher-error-vocabulary.mjs --report
 FIELD_VISIBILITY_UNRESOLVED objlit pending-registration packages/rest/src/error-response.ts

Why it is worth its own card

Two separable things, and only the first is #8846's business:

1. The code needs a ledger row. It is already on spec: register the dispatcher conformance gate's reported error codes in ERROR_CODE_LEDGER (spec half of the #8087 ruling) #8846's registration list (reported by The dispatcher emits unregistered error.code values verbatim — three suites pin bodies that ApiErrorSchema would reject #8087's gate, which is door-agnostic), so registering it closes the immediate wire defect.

2. The door has the same class of hole The dispatcher emits unregistered error.code values verbatim — three suites pin bodies that ApiErrorSchema would reject #8087 just closed for the dispatcher, and registering one code does not close it. The reason packages/rest was believed safe is a type that the module in question does not actually use. Any route reaching for the local sendError can put a fresh unregistered string on the wire tomorrow, silently — which is exactly the "an unswept producer just re-opens the hole" shape the maintainer ruled against on The dispatcher emits unregistered error.code values verbatim — three suites pin bodies that ApiErrorSchema would reject #8087 (2026-08-12, option B delivered as a gate).

Note the REST door's conformance suite did not catch this: like the dispatcher's did before #8087, it parses the cases it drives, and this branch is not among them.

Possible shapes, not a recommendation

• Route sendFieldVisibilityFault (and any sibling) through the closed-ErrorCode responder, leaving the local overload for the mapDataError classification path it was written for.
• Or narrow inside resolveErrorResponse the way toRowApiError does — but that is a contract decision about the REST door's error.code, and the dispatcher's equivalent needed a maintainer ruling.
• Or extend The dispatcher emits unregistered error.code values verbatim — three suites pin bodies that ApiErrorSchema would reject #8087's gate to assert the door-typing itself, rather than only the code vocabulary.

The naming collision is worth a look on its own: two exported functions called sendError with different arities, different types and different strictness, one of which is documented elsewhere as the reason a whole door is safe.

Related: #8087 (the dispatcher half, ruled and gated), #8846 (the ledger registrations, which include this code).

[os-project-manager]

Blocked-by: #8885

Triage: lands in packages/rest/src/error-response.ts (+ possibly #8087's gate) ⇒ domain:cli. Type Bug — the parity premise ("the REST door narrows by type") is measurably false for the responder the route modules actually use.

Scope fence against its siblings, to prevent a double fix:

• The ledger rows for FIELD_VISIBILITY_UNRESOLVED / RECORD_NOT_ACCESSIBLE (register-or-collapse + the ADR-0112 code+status pin) are rest emits two error codes outside the closed ADR-0112 vocabulary — FIELD_VISIBILITY_UNRESOLVED has no ledger entry and no test anywhere #8885's scope (itself Blocked-by: spec: register the dispatcher conformance gate's reported error codes in ERROR_CODE_LEDGER (spec half of the #8087 ruling) #8846, now unblocked this round). ⛔ Not this card's.
• This card is the door-typing half only: route sendFieldVisibilityFault (and siblings) through the closed-ErrorCode responder and/or extend the The dispatcher emits unregistered error.code values verbatim — three suites pin bodies that ApiErrorSchema would reject #8087 gate to assert door typing, plus resolving the sendError naming collision. Gate strengthening — no ruling needed.

Blocked on #8885 because the routing fix cannot type-check until the codes are ledgered (or collapsed — and which of the two was chosen changes this card's edit). At unlock, re-verify on the merged ref which disposition #8885 landed before dispatch.

Note for the eventual dispatch: the tenant-authored error.code limb at the actions door was ruled today on #9106 (demote to declaredCode) — different door, but the ADR-0112 text it produces is the vocabulary this card's gate extension should cite, not the pre-ruling wording.

Triage: this comment comes from the triage seat Routine; not a claim.

---

Generated by Claude Code