fix(runtime): carry the producer's userMessage to the wire at the dispatcher's throw-transparent exit

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[os-steve]

Fixes#13241

errorResponseBase (packages/runtime/src/dispatcher-plugin.ts) resolved every throw through resolveThrownHttpError — whose result already carries userMessage — and then did not read the field. It was the only ADR-0112 error boundary that dropped the author-facing text channel.

Verified on this branch's merge base, all four of triage's readings re-measured rather than taken on trust, with one correction noted below.

⚠️ Parked by design — Clause-②: yes

The PM claim declares clause ② on this card, deliberately and conservatively: two careful seats disagree on whether populating an already-declared field constitutes widening, and a below-tier seat picking the reading that lets it proceed is an escape, not a judgement. This PR is complete-but-parked and an at-tier reviewer clears it.

⛔ This seat has not self-cleared any contract-review gate, has not armed auto-merge, and has not flipped the PR ready. ⛔ It also did not pick the narrower of the two implementation options to look safer under that gate — see the census below, which chose the route on architectural grounds before the gate was ever considered.

⛔ No inference is drawn here from PR #13240 having merged. A merge says that PR cleared; it says nothing about this door's clause-② question, or how it would be answered.

The binding measurement — the buildApiError caller census

Triage's instruction was to census the caller set first, then choose between (1) plumbing at this exit only and (2) making the shared buildApiError carry it so no door can forget again. Six call sites, all in packages/runtime:

#	site	has a thrown error in hand?	producer userMessage available?
1	error-envelope.ts:132 — apiErrorResponse	no — pass-through wrapper	n/a, forwards its caller's input
2	dispatcher-plugin.ts:468 — inline ROUTE_NOT_FOUND 404	no — constructed	none
3	dispatcher-plugin.ts:662 — errorResponseBase	yes	yes, and it was dropped
4	domains/mcp.ts:176 — 405 with Allow	no — constructed	none
5	domains/meta.ts:666 — 405 with Allow	no — constructed	none
6	security/inbound-rate-limit.ts:356 — 429	no — constructed	none

Exactly one of six has a throw. The other five author their own refusal text; there is no producer mark for them to carry.

⇒ Route (2), as stated, is not implementable at buildApiError. That function takes an already-sanitised ApiErrorInput and never sees the throw. Adding userMessage?: string to ApiErrorInput would create a typed slot every caller must still populate explicitly — the "cannot forget" property is not obtained, the forgetting merely moves from the body of errorResponseBase to its argument list — while widening a shared input type consumed by endpoint-executor.ts, api-mapping.ts, endpoint-policy.ts, api-endpoint-step.ts and http-dispatcher.ts for zero behavioural gain at any of them.

⭐ The "one rule, every door inherits" property route (2) was reaching for already exists — one layer up.declaredUserMessage (@objectstack/types) is the single read every boundary applies; its own docblock says so, naming the REST door, the dispatcher door and the sandbox side-channel. resolveThrownHttpError already resolves the field onto ThrownHttpError.userMessage. This exit already called that resolver and simply did not read the answer. So the defect is one door not reading a shared rule, not an absent shared rule — and route (1) is the repair that matches the diagnosis.

The pre-registered conditional escalation does NOT fire. Route (2) could not make a door that today deliberately withholds userMessage start emitting it, because none of the other five call sites has a userMessage in scope to withhold. There is no such door. Measured, not assumed.

What the change is

Both declared siblings now share oneextra object, mirroring errorFromThrown's expression:

constextra={
...(declaredCode!==undefined ? { declaredCode } : {}),
...(thrown.userMessage!==undefined ? {userMessage: thrown.userMessage} : {}),};

⚠️ Two conditional { extra: … } spreads on one object literal do not merge — the later replaces the earlier — so a throw carrying both a demoted declaredCode and a mark would have silently shipped only one. That is pinned (§4) and ablated below.

Wider than the card's framing:userMessage is status-agnostic by ruling (#9934), so the gap was never confined to the declared-5xx band that motivated it. A marked 4xx refusal reaching this exit lost the field too, with no withhold anywhere in the picture. The plumbing is deliberately not gated on the withhold limb, and §2 drives 400/403/409/503 so a later edit cannot quietly re-gate it.

The open question triage asked to be answered on the way past

Does any producer on the throw-transparent routes set author-facing text today? Measured answer: ZERO. The only two in-repo userMessage producers are:

• the sandbox (packages/runtime/src/sandbox/quickjs-runner.ts), reached via /actions — but domains/actions.tscatches and answers through errorFromThrown, which already carries the field;
• metadata-protocol's markedApplicationRefusalError, reached via the REST /meta and /data doors.

Neither reaches this exit. A package-level sweep finds userMessage in only six packages (runtime, rest, metadata-protocol, spec, types, client); no plugin-* or service-* package sets it. ⇒ This confirms the p2 and confirms the change is a no-op on today's tree. It does not close the card's underlying concern, because the contract stays unenforced at one door either way — which is exactly why every test drives the real mounted route rather than asserting a predicate.

⚠️ Two findings this work turned up

1. A measured carve-out, recorded rather than closed.HttpDispatcher.dispatch's foot catch is not a pure rethrow: it intercepts isPermissionDeniedError (name === 'PermissionDeniedError', orcode === 'PERMISSION_DENIED', or a message starting [Security] Access denied) and answers it itself from packages/runtime/src/http-dispatcher.ts. Such a throw never reaches errorResponseBase, so its mark is still dropped, by a different door. That file is a trigger file of on-hold decision #7898 and is out of this change's file surface, so this is pinned as an observation, not repaired here. My own test initially assumed a PERMISSION_DENIED 403 was throw-transparent; the instrument caught it, and the corrected row now pins the carve-out so a future reader learns if it moves.

2. A build-graph mechanism, contributed to the existing card #13513 rather than filed anew.pnpm --filter '@objectstack/runtime^...' build — the closure-build recipe AGENTS.md prescribes — cannot be used for runtime: a devDependency cycle (runtime → driver-turso →(devDep) verify → runtime) pulls verifyand runtime itself into runtime's own dependency closure, so there is no topological order and verify's DTS build races runtime's, dying on Cannot find module '@objectstack/runtime'. Pre-existing and unrelated to this diff; worked around here with --filter '!@objectstack/verify', which is a local unblock and ⛔ not a proposed repair. #13513 already tracks the symptom across two earlier observations and states that what it needs is one confirming build owning the cause; that measurement is now a comment there. ⛔ A duplicate was deliberately not opened.

Patch round — check:error-code-casing was RED on the first push, now green

The gate flagged the two code: 'acme_quota_exceeded' literals in §4 as lowercase error codes in a code position (ADR-0112 D1). They are a deliberately unregistered producer spelling, and they have to be: demotedDeclaredCode yields a declaredCode only when the throw spelled something the closed vocabulary rejected, so a registered SCREAMING code there would produce no declaredCode at all and §4 would stop being the both-fields case and assert nothing.

Declared with adr0112-ok: plus a reason, on the line directly above each hit — the only two placements the gate accepts (it matches the marker on the hit line or the one above, and requires a non-empty reason; both pinned in its --self-test).

• ⛔ Not KNOWN_LOWERCASE_CODES: the gate refuses new lines there in terms, and the list is shrink-only and currently empty by design.
• ⛔ Not EXEMPT_FILES: that is for literals which are not error codes (D6/D6b/D6c). These genuinely are in a code position, so exempting the file would be a false declaration and would blind the gate to every future literal in it.
• ⛔ Not the available restructure either — hoisting the spelling into a constant would satisfy the gate, and the gate's own note says so ("a vendor code passing through is a RUNTIME value … it has no literal for any pattern here to capture"). I did not take it: that makes the deliberate non-conformance invisible by construction, whereas the gate deliberately counts an applied suppression into its verdict line. Visibility is the point, so the declared form is the right instrument and the assertion is unchanged — ⛔ nothing was softened to get green.

The gate's own verdict line, after the fix:

✓ check-error-code-casing self-test: 46 recognizer case(s) + 5 registry case(s) pass.
✓ no unlisted lowercase error codes in 5083 scanned file(s) (ADR-0112).
· 15 literal(s) suppressed by an adr0112-ok: reason

Suppression count moved 13 → 15, which is the positive control that my two were applied rather than silently ignored.

⚠️Why the local union missed it.check:error-code-casing is not in the path-derived union — dispatch-gates.mjs classifies it as content-judged and says so itself: "adds or edits a file carrying an ADR-0112 error or notice CODE (judged from CONTENT — no path derivation can name this gate)". So this was not a skipped gate; it was one no path derivation can name, which is exactly the residue CI exists to cover.

Verification

All readings below were re-taken at 5d93e2427 after the patch round described just above — that is this branch's head, so the gate union, the lint run and the test runs are all on the same tree as the final commit. (Authored in session https://claude.ai/code/session_01UngCYXF98BVpYA9hfz6NYk, recorded here in prose because a body edit rewrites the footer below to its bare form.)

Tests. 21 new cases in packages/runtime/src/dispatcher-plugin.declared-user-message.test.ts, driving the real mounted POST /api/v1/analytics/query route.

• targeted trio (new suite + both sibling withhold suites): 76 passed / 76, so runtime: a declared 5xx carrying NO code keeps its prose on /analytics/query where /data withholds it unconditionally #12281's withhold is not re-opened
• full affected package @objectstack/runtime: 202 files, 2992 tests, all passing
• pnpm --filter @objectstack/runtime run typecheck: exit 0

Positive controls, not merely green. Absence is asserted twice everywhere it is asserted at all — on Object.keys(error) / hasOwnPropertyand on the serialized bytes — because JSON.stringify silently drops a key whose value is undefined, so a byte assertion alone cannot distinguish "omitted" from "emitted as undefined". §3 additionally drives the guard itself against a present-but-undefined envelope, demonstrating the byte limb blind on that shape while the key limb still catches it.

Ablations — direction predicted before running, both matched exactly.

ablation	prediction	observed
A — delete the userMessage limb from the merged extra	partial red with a specific shape: the presence-asserting rows go red, the absence-asserting rows (§3 omissions, §1's unmarked row, the §2 carve-out) stay green, siblings untouched	9 failed / 67 passed; the 9 are exactly the predicted presence rows; both sibling suites green
B — restore the two-spread extra (the pre-merge bug shape)	exactly one red — §4's both-fields row — everything else green	1 failed / 75 passed; the failure is §4's both-fields row

Both legs were mutated with an anchored replacement asserting a hit count of exactly 1 (a zero-hit edit exits 0 and would have read as a successful ablation), confirmed on disk by blob-hash inequality against the HEAD blob, and restored via git checkout HEAD -- ABSOLUTE_PATH with the restore proven by hash equality plus an empty git diff HEAD — not by an exit code. No rebuild was needed or claimed: the suite imports ./dispatcher-plugin.js, which vitest resolves to same-package source, and every @objectstack/* it touches is source-aliased in packages/runtime/vitest.config.ts.

Gates. Union derived at 5d93e2427 with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (no paths passed; stderr read and confirms the change set and the repo assertion). Harvested with --commands to avoid the 15-of-30 single-spelling trap. Exit codes captured before any pipe.

• 31 of 34 pass. Including the most targeted: check:route-envelope, check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:type-check-coverage, check:comment-mask-adoption, check:undeclared-dep-imports, and the changeset family.
• pnpm lint (whole repo, eslint . --no-inline-config): exit 0, run in full — no narrowing claimed and none needed.
• node scripts/check-nul-bytes.mjs: OK, 7541 files, no raw control bytes.

3 refusals, reported separately and ⛔ NOT folded into the passes — each is NOT MEASURED, in the gate's own words:

• node scripts/check-test-completeness.mjs — exit 3: "the local reading for this gate is NOT MEASURED. ⛔ It is not a red, and there is nothing here to fix." It needs a saved turbo run test log that only CI produces.
• pnpm check:dual-build-cjs-loads — exit 3: "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/. … ⛔ This is NOT a pass: nothing was measured."
• pnpm check:type-check-debt — exit 1. Its structural half printed OK — 66/78 workspace packages type-checked, but the --re-measure ratchet refused: "cannot run: 23 workspace dependenc(ies) of the ledgered packages have no built type entry point on disk", because a number measured without the closure "would silently measure a DIFFERENT WORLD".

One NOT MEASURED I am flagging on my own diff, not on a gate.@objectstack/runtime's tsconfig excludes **/*.test.ts, so its green typecheck says nothing about the new test file. Measured rather than assumed with tsc --noEmit --listFiles: src/dispatcher-plugin.ts → 1 hit (the implementation is covered), the new test file → 0 hits. check:type-check-coverage passes, so the existing TEST_DEBT entry already accounts for that layer.

Triage's four readings, re-measured

Three hold exactly. One has drifted and is corrected here:

claim	reading at 5d93e2427
userMessage absent from dispatcher-plugin.ts	⚠️1 hit, not 0 — but it is a comment line added by #13240 ("The author-facing text channel is userMessage"), not code. The substantive claim holds: zero code references. Triage measured 0 at a81aa9dd, before that comment landed.
positive control — buildApiError in the same file	5 hits ⇒ the absence was real, not a broken read
the caught-path sibling carries it	http-dispatcher.ts:850 — confirmed verbatim
the envelope slot is declared	contract.zod.ts:87 — confirmed

Card body sanitizer self-check

Clean. The body is structurally complete — ## The gap → ## Why it matters more after #12281 → ## Not established here → ## Region → ## Refs, closing on its three-ref list, with no tag-shaped fragment anywhere in it and nothing cut mid-sentence.

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 707d35adf48162df29799f09f0c6c6fa4d0044ca — the merge of head 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 into base eaba72e48cc294038e74ece5bf7677568d55b038, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 707d35adf48162df29799f09f0c6c6fa4d0044ca && git checkout 707d35adf48162df29799f09f0c6c6fa4d0044ca
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin eaba72e48cc294038e74ece5bf7677568d55b038 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4 && git checkout -B drift-repro eaba72e48cc294038e74ece5bf7677568d55b038 && git merge --no-ff 5d93e24278a6127ef7dbb17f4ed3ba12ebfb5df4
node scripts/docs-audit/affected-docs.mjs --json eaba72e48cc294038e74ece5bf7677568d55b038

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.