feat/one-api

createServiceKeyShell .catch() swallows programmer errors — rotateApiKeyShell rethrows them

domains/core/src/api-key/api-key.shells.ts:522

The shell comment claims 'same pattern rotateApiKeyShell uses', but `rotateApiKeyShell`'s `.catch()` (line 261–268) has an explicit `throw e` for any exception that is NOT the `RotateInsertFailed` sentinel — it only converts known-safe errors to Results. The new `createServiceKeyShell .catch()` converts EVERY non-unique-violation error to `err(ApiKeyErrors.databaseError('insert'))`, including outbox-write bugs, null-pointer errors, and infrastructure panics. These become silent `databaseError` Results instead of propagating to the crash reporter. Fix: add `throw e` as the final else branch, parallel to `rotateApiKeyShell`.

API_KEY_FORMAT alias name is misleading — service-key OR-composition is implicit

apps/platform/src/api/handlers/public-v1/auth-token.handler.ts:69

The variable is named `API_KEY_FORMAT` but is assigned `CUSTOMER_KEY_SECRET_FORMAT`. The actual pre-auth check is `API_KEY_FORMAT.test(key) || SERVICE_KEY_SECRET_FORMAT.test(key)`, which is currently correct. But a future simplification to just `!API_KEY_FORMAT.test(key)` would silently reject all `sk_` service-key tokens with a 401. Rename to `CUSTOMER_KEY_FORMAT` or `CUSTOMER_KEY_REGEX` to make the OR-composition self-documenting and close the future-dev trap.

Timing equalization gap: candidates-found-but-none-match path skips dummy hash verify

apps/platform/src/api/handlers/public-v1/auth-token.handler.ts:119

The DUMMY_HASH equalization fires only on the zero-candidates branch. When candidates are found but every `verifySecret` call fails (e.g. prefix collision with a different org's key), the handler falls through to `return UNAUTHORIZED_RESPONSE` without burning an equalizing scrypt hash. An attacker who learns a valid prefix can distinguish 'prefix exists but wrong secret' from 'prefix unknown' via a ~50ms timing delta. Low severity because: (a) the prefix is already visible to org admins, (b) cross-org prefix collision is cryptographically unlikely. Consider moving the equalization to cover both zero-candidates AND no-match paths.

Service key updateLastUsedAt errors silently swallowed — no logging unlike the customer-key path

apps/platform/src/api/handlers/public-v1/auth-token.handler.ts:136

The service-key path calls `apiKeyQueries.updateLastUsedAt(…).catch(() => {})` — discarding the error with no log. The customer-key path logs a `console.error`. A persistent write failure on the service key's `lastUsedAt` is silently invisible, making it impossible to detect if audit telemetry is broken for the most-privileged credential class. Mirror the customer-key pattern: `.catch((e) => console.error('Failed to update lastUsedAt for service key', e))`.

All service keys minted with wildcard scopes ['*'] — no least-privilege issuance

domains/core/src/api-key/api-key.shells.ts:486

createServiceKeyShell always mints `scopes: ['*']`. The scope gate works correctly (this diff's regression tests prove it), but every service key has platform-wide authority. A compromised `sk_` token grants full access to all scope-checked infra routes. Consider accepting a `scopes` parameter in `CreateServiceKeyCommand` for least-privilege issuance (e.g. `cfe-pipeline` gets `['cfe:collect']`). Not urgent while service keys are Batu-internal, but worth tracking.

rotate contract declares no 400 — ApiKeyServiceRotationUnsupported collapses to 500 on wire

apps/platform/src/api/contracts/api-keys.contract.ts:145

The rotate contract (lines 145–161) declares 201/401/403/404/409/422/500 but NOT 400. `api-key.mapper.ts` maps `ApiKeyServiceRotationUnsupported` → `fail('API_KEY_SERVICE_ROTATION_UNSUPPORTED', …)` which resolves to HTTP 400 via `codes.ts`. Per ts-rest's anti-pattern, any status not declared in `responses` collapses to a generic 500 — so a customer trying to rotate a service key gets an opaque 500 instead of a descriptive 400. The decision test and error-code registration are both present; only the contract declaration is missing. Fix: add `400: JSendFailSchema(['API_KEY_SERVICE_ROTATION_UNSUPPORTED'] as const)` to the rotate contract responses, and add a handler-level test asserting the HTTP 400 path end-to-end.

shells.test.ts buildKey missing `kind` field — service-key guard in decideRotate never fires in shell tests

domains/core/src/api-key/__tests__/api-key.shells.test.ts:81

The `buildKey()` fixture in shells.test.ts does not set `kind`, so the `rotateApiKeyShell` tests exercise rotation of a key whose `kind` is `undefined` (or whatever TS default applies). The `ApiKeyServiceRotationUnsupported` guard in `decideRotate` checks `existing.kind === 'service'` — this branch is never reached from shell-level tests. Add `kind: 'machine'` to the default fixture and add one shell test that passes a `kind: 'service'` key and asserts the shell returns an `ApiKeyServiceRotationUnsupported` error.

No test for a sk_ credential whose DB row carries kind='machine' (cross-kind mismatch path)

apps/platform/src/api/handlers/public-v1/__tests__/auth-token.service.test.ts:75

The handler routes by prefix (`sk_` → service path) then reads the row's `kind`. There is no test where `findActiveByPrefix` returns a row with `kind: 'machine'` for an `sk_` token. A data inconsistency (row migrated incorrectly) would silently produce a wrong token class. The `kind` discriminator is the core invariant of this branch — it deserves a mismatch test.

Passing scope tests don't assert okHandler was called

apps/platform/src/api/utils/__tests__/public-v1-meta-gate.test.ts:255

The two new passing tests ('holding the required scope' + 'wildcard grant') only assert `result.status === 200`. Other tests in the same file assert `expect(okHandler).toHaveBeenCalledOnce()`. Adding the handler-call assertion makes these tests as rigorous as their siblings and would catch a gate implementation that short-circuits to 200 without calling the handler.