fix(core): a rejecting sys_api_key read is the store outage (503), not "no key", so a cookie beside the key never answers for it

[objectstack-fleet]

Fixes #24299

Clause-②: no (narrowing) (a key whose read fails is no longer taken as "no key", so the request no longer falls on to another credential; owes one CONTRACT_REVIEW_TIER review before the queue)

What changes

resolveApiKeyAdmission (packages/core/src/security/api-key.ts) read the key's sys_api_key row inside a bare catch that answered { outcome: 'none' } ("this request carries no key") and logged nothing. That catch now raises the branded AuthzStoreUnavailableError('sys_api_key', err), the answer the same function already gave when its lifecycle-policy source (api_key_policy) or owner-posture source (auth_gate) rejects. The driver's error is kept as cause.

One read failure stays "no key": a sys_api_key table that was never provisioned, where no key can exist. That is the boundary the 2026-08-30 ruling (option A) draws for resolveAuthzContext's tryFind, asked through the same shared isMissingTableError(err, 'sys_api_key'). No second classifier was added.

The other outcome: 'none' exits are unchanged and pinned: no key header, no engine, an engine with no find, no matching row, a row with no user_id.

No edit to resolve-authz-context.ts (fenced for PR #24373, epic:#15194) was needed. The throw leaves resolveApiKeyAdmission before the session arm runs, and every door already relays the branded outage as 503.

Measured first (M1), before the code changed

The same harness was run on three doors that admit keys, on origin/main d65826fa7c and again after the change. Each case is either the engine's sys_api_key read rejecting with every other table healthy (key read rejects), or every read rejecting (all reject). The key belongs to u_key and the cookie to a different user, u_cookie.

door	fault	caller	before	after
REST GET /api/v1/data/:object (real route, single-kernel wiring)	key read rejects	key only	401 UNAUTHENTICATED	503 SERVICE_UNAVAILABLE
		key + other user's cookie	200, served as u_cookie	503, data service never called
		session only	200 as u_cookie	unchanged
	all reject	key only / key + cookie / session	401 / 503 / 503	503 / 503 / 503
runtime dispatcher (resolveRequestScope + GET /api/v1/automation/_status)	key read rejects	key only	wire 401, scope guest	wire 503, raises sys_api_key
		key + other user's cookie	scope ran as u_cookie (wire 501, admitted)	wire 503, raises sys_api_key
		session only	scope u_cookie	unchanged
settings GET /api/settings (booted SettingsServicePlugin)	key read rejects	key only	401 UNAUTHENTICATED	503 SERVICE_UNAVAILABLE
		key + other user's cookie	200 (the session read answered)	503, session never read
		session only	200	unchanged

The cookie-beside-a-failed-key reading is now measured. A request that led with a key was admitted as the principal of a cookie it did not lead with, on the REST data door and the runtime dispatcher, and served on the settings door. The triage grade (6249028135) named this reading as the point to re-raise; that call is the lane's.

Hypotheses: H1 held (the throw alone gives every door measured 503, through the handling the lifecycle-policy outage already takes). H2 held (the key-plus-cookie case answers 503 and the session is never read).

Pins

• packages/core/src/security/api-key-read-outage.test.ts (new): a rejecting read raises the branded outage (code, status, object, cause). Through resolveAuthzContext, a key plus a cookie rejects and getSession is called zero times. A never-provisioned table (SQLite and Postgres spellings) is still none. A missing-table phrase naming another relation stays loud. The other none exits are unchanged, and a control admits the healthy key.
• packages/rest/src/rest-api-key-read-outage.pin.test.ts (new, door pin): the real REST data route. Key only answers 503 SERVICE_UNAVAILABLE. Key plus cookie answers 503 and the data service is never called. Session only is unchanged. Controls: a healthy key is served as its owner, and an unprovisioned table answers 401.
• packages/services/service-settings/src/settings-routes.api-key-read-outage.pin.test.ts (new, door pin): GET /api/settings on the booted plugin, with the same rows as the REST pin. The session read count is 0 for key plus cookie.
• packages/runtime/src/http-dispatcher.tenancy-posture-outage.test.ts (flipped by the sweep): the one existing pin that asserted the old answer. "A plain engine fault under a key degrades to a guest" now asserts the branded sys_api_key outage, with the superseded assertion quoted. Its intent, that every non-branded identity fault degrades to anonymous, moves to a session read that throws, which still resolves a guest.

Pin sweep: I searched the error code and message across the repo for pins with the same meaning, and ran the suites of every package whose tests send an API key while a read rejects (list below). Only the runtime pin above asserted the old answer. No existing pin asserted 401 on a door for a key whose read fails. authz-store-unavailable.test.ts's TRANSPORT_LEDGER needs no row: it enumerates callers of resolveAuthzContext, and none was added.

Verification record

Final head 3d826adf2 (merge base c76e84922).

• Suites (after the change, before the merge of origin/main c76e8492):

  • @objectstack/core: 104 files, 2551 tests passed.
  • @objectstack/rest: 295 files, 6051 passed and 326 skipped.
  • @objectstack/service-settings: 50 files, 876 passed.
  • @objectstack/service-storage: 60 files, 1041 passed.
  • @objectstack/service-datasource: 45 files, 838 passed.
  • @objectstack/runtime: 1 failed and 420 passed (421 files). The one red was the predicted pin above; after the flip that file reads 11 passed.
  • Targeted files in cloud-connection (41), plugin-sharing (31), organizations (32) and plugin-auth (11): all passed.

• Ablation (declared direction RED). throw new AuthzStoreUnavailableError('sys_api_key', err); was replaced by a none answer carrying the marker ABLATION-24299, through scripts/ablation-replace.mjs (marker 1, anchor 0). @objectstack/core was then rebuilt, and ablation-dist-preflight found the marker in 2 built files. Result: 8 red, every control green.

  • core pin: 3 failed, 3 passed.
  • REST pin: 2 failed, 3 passed.
  • settings pin: 2 failed, 3 passed.
  • runtime pin: 1 failed, 10 passed.

  Restore: blob equals HEAD (13e1cdc2035), git diff HEAD is empty, core was rebuilt, and the --absent preflight exited 0 with the tree clean. A first attempt used a comment marker, which the build strips. Its preflight refused, so that leg's readings were discarded and the leg was re-run with a string marker.

• Typecheck, after the merge of origin/main: core, rest, runtime and service-settings all exit 0. --listFiles shows each new test compiled: tsconfig.test.json for core, rest and runtime, tsconfig.json for settings.

• Gates, on 3d826adf2: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack with no paths derived 69 commands. All 69 exited 0, and each exit code was captured before any pipe. --ran reads 69 derived, 69 run, 0 NOT-MEASURED, 0 UNRUN.

  • The first pass, before the last test commit, turned up three real findings in the new tests, all corrected before that commit: check-rest-log-spy-declared (the REST pin now declares OS_REST_LOG), check:objectql-double-limit (a find double the probe could not drive), and check:where-matcher (two matchers that read a combinator as a field; both now refuse).
  • check:dual-build-cjs-loads first exited 3 because some dist was missing. After a whole-tree build (76 of 76 tasks) it exited 0.
  • Also: eslint --no-inline-config over the 5 changed .ts files exited 0, and check-platform-checklist --changed-from origin/main exited 0.

Acceptance notes

• resolveApiKeyPrincipal, the principal-or-nothing collapse, now raises the outage too instead of answering undefined. Its docblock says so. Its only in-repo users are re-exports. No caller in this repo catches its throw differently from the admission's.
• The storage family's ADR-0069 gate reader calls resolveApiKeyAdmission directly. It had the same fall-through: with none, it went on to read the session's posture. The throw now reaches its door as the branded outage, which its comment already says the door relays as 503. Its suite is green.
• One changeset, on @objectstack/core (minor, breaking, no-migration-prescription). The rest, runtime and settings diffs are tests only, which no package publishes.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/core, touching 2 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/permissions/authorization.mdx (via sys_api_key (literal, a string literal in resolveApiKeyAdmission))
• content/docs/permissions/system-context.mdx (via sys_api_key (literal, a string literal in resolveApiKeyAdmission))
• content/docs/permissions/tenant-audit-census.mdx (via sys_api_key (literal, a string literal in resolveApiKeyAdmission))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-1.mdx (via sys_api_key (literal, a string literal in resolveApiKeyAdmission))
• content/docs/releases/v17/17-5.mdx (via sys_api_key (literal, a string literal in resolveApiKeyAdmission))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 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.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 27 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 584b4225e1fcbaf5e8bed14d9c280d6347a897ff → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 36680df96b5d376c23047ab4ac3cf83e58e2687d — the merge of head 3d826adf2685d9c2c878a4618d4eaa6ec5c43ae6 into base 584b4225e1fcbaf5e8bed14d9c280d6347a897ff, 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 36680df96b5d376c23047ab4ac3cf83e58e2687d && git checkout 36680df96b5d376c23047ab4ac3cf83e58e2687d
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 584b4225e1fcbaf5e8bed14d9c280d6347a897ff 3d826adf2685d9c2c878a4618d4eaa6ec5c43ae6 && git checkout -B drift-repro 584b4225e1fcbaf5e8bed14d9c280d6347a897ff && git merge --no-ff 3d826adf2685d9c2c878a4618d4eaa6ec5c43ae6

node scripts/docs-audit/affected-docs.mjs --json 584b4225e1fcbaf5e8bed14d9c280d6347a897ff

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 584b4225e1fcbaf5e8bed14d9c280d6347a897ff → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 3d826adf2685d9c2c878a4618d4eaa6ec5c43ae6
Local-runs: none
Scope: packages/core/src/security/api-key.ts, packages/core/src/security/api-key-read-outage.test.ts, packages/rest/src/rest-api-key-read-outage.pin.test.ts, packages/runtime/src/http-dispatcher.tenancy-posture-outage.test.ts, packages/services/service-settings/src/settings-routes.api-key-read-outage.pin.test.ts + packages/core/src/security/resolve-authz-context.ts (fenced; read, unchanged), packages/core/src/security/authz-store-unavailable.ts, packages/core/src/security/request-execution-context.ts, packages/core/src/security/authz-store-unavailable.test.ts (TRANSPORT_LEDGER), packages/types/src/driver-error-classification.ts (isMissingTableError, MISSING_TABLE), packages/rest/src/rest-server.ts (computeExecCtx, resolveExecCtx), packages/rest/src/crud-routes.ts, packages/runtime/src/http-dispatcher.ts (resolveRequestScope), packages/runtime/src/security/resolve-execution-context.ts, packages/runtime/src/dispatcher-plugin.ts (errorResponseBase), packages/services/service-settings/src/settings-service-plugin.ts, packages/services/service-settings/src/settings-routes.ts, packages/services/service-storage/src/storage-service-plugin.ts (buildAuthGateSessionReader, buildFileReadAuthorizer, buildAuthSessionResolver), packages/services/service-storage/src/storage-routes.ts, packages/services/service-datasource/src/admin-routes.ts, packages/services/service-print/src/print-routes.ts, packages/plugins/plugin-sharing/src/sharing-plugin.ts, packages/plugins/plugin-hono-server/src/current-user-endpoints.ts, packages/cloud-connection/src/cloud-connection-plugin.ts, packages/cloud-connection/src/marketplace-install-local-plugin.ts, packages/mcp/src/plugin.ts; the prose face .changeset/24299-api-key-read-outage.md is judged under ②. Base read: merge base c76e849220cc58d3b22190f0612b805728191bcf, diff +517/-9 over 6 files, production change in api-key.ts alone.

① Derived judgments

Every served-set and accept-set change, named:

1. The seam (resolveApiKeyAdmission, api-key.ts 702–718). A sys_api_key read that was issued and threw now raises AuthzStoreUnavailableError('sys_api_key', err); the one carve-out is isMissingTableError(err, 'sys_api_key'), which still answers none. RIGHT. The throw leaves the function before any none return, so resolveAuthzContext step 1 (resolve-authz-context.ts 489) rejects before step 2, the session arm (544), can run; neither withRequestGrantsMemo nor the resolver catches it. The same function already gave this answer for its lifecycle-policy source (745, 'api_key_policy') and its owner-posture source (860, 'auth_gate'), so the bare catch was the one seam in the function that did not.

2. Every door that admits keys now answers the outage as 503, key-only and key-plus-cookie alike. Production code reaches the seam two ways: through resolveAuthzContext (the eight transports TRANSPORT_LEDGER pins by set equality, four of them through resolveRequestExecutionContext: REST computeExecCtx 3244, runtime resolveExecutionContext 157, settings verifiedContextFromRequest 341, the storage download authorizer 1498) and through the one direct call in the storage gate reader (storage-service-plugin.ts 1280). Each relays the brand, read in the cited code:

   • REST: computeExecCtx's outer catch returns rethrowAuthzStoreUnavailable(err) (3354); the GET /data/:object handler's catch maps the thrown declared envelope through mapDataError to its own status (crud-routes.ts 166–170). Pinned on the real route: key-only 503 SERVICE_UNAVAILABLE, key-plus-cookie 503 with findData never called.
   • runtime dispatcher: resolveRequestScope's net re-raises by brand (http-dispatcher.ts 762); errorResponseBase reads err.status (dispatcher-plugin.ts 699). The flipped pin asserts brand, 503 and object === 'sys_api_key' at the identity step and executionContext left undefined; the wire render of this class is the file's existing §2 pin.
   • settings: the resolver re-raises by brand (settings-service-plugin.ts 373) and the family door relays (relayAuthzStoreOutage, settings-routes.ts 151). Pinned on the booted GET /api/settings, session read count 0 for key-plus-cookie.
   • storage: the gate reader calls the seam BEFORE its session read (1280 before 1293), and admission.outcome !== 'none' returned undefined only for a verdict, so the old none fell on to the session's posture; the throw now leaves the reader and refuseHeldSession relays it with sendError(res, err.status, err.code, err.message) (storage-routes.ts 660–665). The download authorizer re-raises by brand (1567) and authorizeDownload relays (563). The upload door's buildAuthSessionResolver (1187) reads the session only and never calls the seam: unchanged.
   • datasource (admin-routes.ts 527), sharing (sharing-plugin.ts 995), marketplace install-local (3594) and print (151, a relay) re-raise by brand; cloud-connection's three connection-changing doors re-raise (481) while status withholds details and logs (517), by its own design; MCP stdio: the .catch at plugin.ts 526 rewraps only the lifecycle brand, so the outage escapes and the boot refuses, loud; hono current-user passes headers: undefined (session-only, the key arm never runs): unchanged.

3. No remaining path where a key-led request whose read failed falls on to another credential. extractApiKey (api-key.ts 90) is the only header reader in the repo: x-api-key, then Authorization: ApiKey, then Bearer osk_…; an unprefixed bearer or a JWT-shaped bearer is never a key, so those are session-only callers. The MCP face passes session: 'none' for an unverified JWT but still runs the key arm first. The only caller outside resolveAuthzContext (the storage gate reader) throws before its own getSession. The runtime pin's old "plain engine fault under a key degrades to a guest" assertion was the single pin of the old answer; it is flipped with the superseded assertion quoted, and its degrade-to-anonymous intent is kept on a throwing session read, which the composition's readSession (request-execution-context.ts 263) and the resolver's session arm (catch {} at 567) still swallow. resolve-authz-context.ts needs no change: its blob on this head equals the merge base's, and the fence for PR fix(security): the single-posture platform-admin grant is owned by the Default Organization, and every reader of platform standing reads it #24373 holds.

4. The missing-table carve-out. RIGHT, and precise enough. isMissingTableError keys on SQLSTATE 42P01, ER_NO_SUCH_TABLE, errno 1146 and three dialect phrases, excludes column and sub-object codes and phrases up front, and with readObject given refuses a phrase naming another relation (excludedByReadObject); anything unrecognised is false, so an outage stays loud by default. A connection reset, timeout or permission denial carries none of these. The false-positive direction (a driver composing a missing-table phrase over an outage) is the risk the 2026-08-30 ruling signed off for this predicate on security paths, verbatim beside tryFind (resolve-authz-context.ts 396–433), and the two-direction pins it requires are present: both dialect spellings answer none, a plain fault is loud, a phrase naming main.some_other_base is loud. The other direction (a real missing table on a dialect the predicate does not know) answers 503, which is exactly what tryFind already answers that deployment's session callers, so the two arms stay consistent. Option A (throw on every failure) would answer 503 to every key-bearing request on the supported ABSENT_AUTHZ_TABLES shape while session callers are served. Consequence noted in ③: at this seam a false positive restores the fall-through, not only the quiet refusal.

5. The other none exits are unchanged: no header (688), no engine or an engine without find (689), no row (721), a row with no user_id (724), each pinned beside a healthy-key control. Session-only callers never reach the read (688 returns before it), pinned on REST and settings under the same fault.

6. resolveApiKeyPrincipal (622–632) now rejects where it answered undefined; its docblock drops "a lookup error" and says so. In-repo users are re-exports only (core security/index.ts 125, runtime security/api-key.ts 22 and index.ts 44). RIGHT, and the changeset names it.

7. The label 'sys_api_key'. RIGHT: the constructor's object is documented as the object/table whose read failed, tryFind labels by table (433), and the service sources keep their source labels. No non-test reader branches on .object; it reaches only the message text and the pins.

8. Door pins prove what the card asks, with controls. REST: key-only, key-plus-cookie (service never called), session-only served as the cookie's user, healthy key served as its owner with and without a cookie, unprovisioned table 401 UNAUTHENTICATED. Settings: the same five, session reads counted. Core: the brand, code, status, object and cause; key-plus-cookie through resolveAuthzContext with getSession called zero times; both missing-table spellings; the other-relation phrase; the five none exits; a healthy control. Runtime: the flipped pin plus the moved control. Fixtures refuse combinators and unknown operator shapes rather than matching them. Gap, not a defect: no committed door pin for key-plus-cookie on the runtime dispatcher or on the storage family; the seam-level pin covers the composition both use, and the dev's M1 reading covered the runtime. Ablation as reported on the PR (8 red: 3+2+2+1, controls green) was read, not re-run.

② Semver level

• .changeset/24299-api-key-read-outage.md: '@objectstack/core': minor, fix(core)!:, Clause-②: no (narrowing), one ADR-0087 marker not-required (no-migration-prescription), a BREAKING paragraph and a what-to-do line. RIGHT.
• It is a narrowing and only a narrowing: the served set loses the key-plus-cookie request during an outage (measured 200 as the cookie's user, now 503), the accept set loses "a cookie beside a failed key", and resolveApiKeyPrincipal loses its never-throws shape. Nothing widens: a healthy read, a never-provisioned table and the other none exits answer as before. Narrowing is BREAKING (AGENTS.md Post-Task Checklist 3), and BREAKING ships minor with the bang under the launch-window convention (scripts/check-changeset-no-major.mjs, pre-GA lockstep).
• ADR-0087 disposition: nothing an author writes or stores moves (no spec key, export, option, object definition or row shape), so no-migration-prescription is right; check:adr-0087-registration read [BREAKING+bang+clause-②-narrowing] not-required (no-migration-prescription), and Lint & Repo Gates and Check Changeset are green on this head. The same disposition the [Decision] API key 的生命周期与存放：到期上限与不活动失效取多长，key 继续放自有 sys_api_key 还是迁到 @better-auth/api-key（#23287 裁决 C′ 的留项） #23367 admission narrowing used.
• One changeset is right: only @objectstack/core publishes a source change; the rest, runtime and settings diffs are tests, which no package publishes; runtime's re-export resolves to core's implementation and the group versions in lockstep.
• PR body line 3 carries Clause-②: no (narrowing), agreeing with the changeset and the dispatch's declaration. No published signature moves, so check:api-surface does not.

③ Boundary flags

Dev deviations (report 6254998617), each answered or escalated:

1. Background runs waited on in the same turn: os-dev.md's resource rule names nohup … tail --pid for the check:* battery; the dev extended that shape to the lock-held suites and the tree build and read nothing before exit. Declared, benign. Answered.
2. M1 measured in-process through the registered route handlers, no socket: the dispatch said "over HTTP on a booted stack". The committed pins have the same shape; REST and settings write their status inside the handler, and the adapter layer's render of a thrown declared envelope is pinned elsewhere (hono adapter, hono adapter: render an escaped throw that carries a declared ADR-0112 status + registered code as that envelope, not as bare 500 INTERNAL_ERROR "No response from handler" — #15999's shared half #16545; errorResponseBase). Accepted; a real store outage on a deployed host stays NOT MEASURED, as the card itself states. Answered.
3. The missing-table exception: right under ① item 4. Residual, recorded not blocking: at this seam the signed-off false-positive direction restores the key-plus-cookie fall-through rather than the quiet refusal tryFind's does; the single-classifier design is the ruling's own, and the call-site comment points at the risk text beside tryFind. Answered.
4. Runtime full suite ran before the final merge of c76e8492 (rest import-*, plugin-auth, docs): AGENTS.md §10's scoped re-check applies; the four pins, four typechecks and the 69-gate union were re-run on the final head. CI on this head at 2026-10-18T21:15Z: Test Core 1/6, 5/6, 6/6 success; 2/6, 3/6, 4/6 in progress. The seat reads those before arming. Answered, state recorded.
5. One changeset for test-only packages: right (②). Answered.
6. The shared primary checkout's HEAD detached and the branch pointed at origin/main: no file edit there, and the branch tip equalled the dispatch base d65826f, so nothing was lost by the dev's own reading; still a state write on the shared checkout outside the worktree rule. Escalated to the seat as a note; not a defect of the diff.
7. Trailers and footer: the four commits carry the model-free pair (Claude-Session, Co-authored-by: Claude); the PR footer is the session-URL form; the harness reminder's model-named trailer was correctly not used (AGENTS.md wins; the pre-push hook refuses it). Subjects end (WIP) with no card relation; the PR title and Fixes #24299 carry it. Answered.
8. No second merge of origin/main after pr_create (3 commits behind): per §10. Answered.

open_questions:

• Missing table, B: settled as B (① item 4).
• Label, A: settled as A (① item 7).
• Grade: the seat re-graded p2 to p1, not security (6255097198). Judged right. A key-only caller was refused (401, fail-closed, no admission). The key-plus-cookie caller was served as the cookie's user, a principal whose credential it presented itself, so the cookie alone would have admitted it the same way; no caller gains access beyond the credentials it holds, a narrowly scoped key beside a full session included (the session was in hand). It is identity confusion with wrong audit attribution on public doors under an outage: p1 fits. No elevation path was found in the code read; the only fall-through was the one this PR closes.

out_of_scope_findings:

• The storage family's ADR-0069 gate reader: the same defect class, closed by this PR's throw through the reader's existing relay (refuseHeldSession) and the download authorizer's re-raise; the upload door never admitted keys. Noting it in the acceptance notes rather than filing is right (no residual defect). Not pinned on that door; a follow-up nicety, not owed by the card.

Check-runs on 3d826adf2685d9c2c878a4618d4eaa6ec5c43ae6, read 2026-10-18T21:15Z: 39 runs. Required set: Lint & Repo Gates success, TypeScript Type Check success, Build Core success, Governed Surface Queue Guard success, Test Core 1/6, 5/6, 6/6 success, Test Core 2/6, 3/6, 4/6 in progress. Everything else success or skipped (the full-battery lanes skip on PR runs). Nothing red. Green is the seat's landing condition, not this record's.

Implemented-by: claude/issue-24299-api-key-read-outage
Reviewed-by: session_01JtSQQ3EWsbNPzyYMug1tXy

VERDICT: PASS

[objectstack-fleet]

席位核对 · domain:engine seat 1 · session_01JtSQQ3EWsbNPzyYMug1tXy · 2026-10-18T21:22Z · ACCEPT

Head: 3d826adf26 (the fix, the pins, the gate corrections, then a merge of main). Card #24299 (p1 since re-grade 6255097198), claim 6253890220, dispatch 6253916743. Dev report: 6254998617.

Item	Reading
Shape	Draft PR → main. The body opens Fixes #24299. 6 files, +517 / −9. Not governed (check-governed-merges.mjs --pr 24397).
Scope	One source file, packages/core/src/security/api-key.ts: the catch around the sys_api_key read throws AuthzStoreUnavailableError('sys_api_key', err), except a never-provisioned table (isMissingTableError(err, 'sys_api_key')), which still answers "no key". Pins on core, the REST data door, the runtime dispatcher (an existing pin flipped) and the settings door, declared to domain:cli (6255106909, 6255110824) and domain:services (6255115822). One changeset for @objectstack/core. resolve-authz-context.ts, fenced for the epic:#15194 lane's PR #24373, is unchanged.
Seat's own read	At the head, the catch throws the branded outage and returns none only for the missing-table case, which the comment ties to the 2026-08-30 ruling beside tryFind. git diff over the merge base shows no change to resolve-authz-context.ts.
Measured	Before the fix, with the key read rejecting, on the REST data door, the runtime dispatcher and the settings door: a key-only caller got 401. A key beside another user's session cookie was served as the cookie's user (REST 200; the runtime scope resolved to that user). After the fix, both answer 503 SERVICE_UNAVAILABLE on all three doors. Session-only callers and the other "no key" exits are unchanged.
Review face	The narrowing. CONTRACT_REVIEW_TIER record on this head is PASS. The seat verified its central claims at the head (the row above).
Declaration	Clause-②: no (narrowing), on the claim, the PR body and the changeset alike. The changeset is minor, BREAKING, with the adr-0087 not-required (no-migration-prescription) marker; the record ② finds both right, and names the one other moved shape, resolveApiKeyPrincipal rejecting where it answered undefined.
Pins and ablation	Core: the brand, code, status, object and cause; key plus cookie through resolveAuthzContext with the session read 0 times; both missing-table spellings answer "no key"; a phrase naming another relation stays loud; the other "no key" exits unchanged; a healthy control. Door pins: key-only and key plus cookie 503, session-only and a healthy key served as before, an unprovisioned table 401. The ablation turned 8 cases red (core 3, REST 2, settings 2, runtime 1) with every control green; the restore read back as the HEAD blob.
Gates	Dev at 3d826adf26: 69 derived, 69 run, 0 NOT MEASURED. Typecheck exit 0 for core, rest, runtime and service-settings.
CI	At this read: 40 check-runs on 3d826adf26, 34 success, 6 skipped, 0 failed. The skips are the rostered path and opt-in skips. Test Core 1/6–6/6, every Type Check lane, Lint & Repo Gates, Check Changeset and Governed Surface Queue Guard are green.

Disposition:

• open_questions:
  1. The never-provisioned table: B, it stays "no key", through the shared predicate the 2026-08-30 ruling signed for tryFind. Throwing there would answer 503 to every key-bearing request on the supported ABSENT_AUTHZ_TABLES deployment shape, where no key can exist.
  2. The outage label: A, 'sys_api_key', the table whose read failed, as tryFind labels its reads. No reader branches on it.
  3. The grade: p1, not security, as re-grade 6255097198 set it and record ③ confirms. The caller holds both credentials, so no access is gained beyond them. The harm is identity confusion with wrong audit attribution on public doors during an outage.
• deviations: all accepted, as record ③ judges them. These are: background runs waited on in the same turn; M1 measured through the real route handlers in-process; the missing-table exception; the runtime full suite before the last merge, with the pins and gates re-run on the final head; one changeset for the one published source change; the trailers and footer. The detached shared checkout is noted; no edit was made there.
• out_of_scope_findings: the storage family's gate reader had the same fall-through. This PR's throw reaches it through the reader's existing relay, so nothing is left open (noted in the PR, not filed). Record ③ notes, as a gap rather than a defect, that no committed door pin drives key plus cookie on the runtime dispatcher or the storage family; the seam pin covers the composition both use.

Landing: ordinary queue (pr_ready + automerge_enable through the relay). Every check on this head is green or a rostered skip. Fixes #24299 then closes the card.

---

Generated by Claude Code