feat/one-api

Service key revoke handler implicitly guarded by null-orgId comparison rather than explicit kind check

apps/platform/src/api/handlers/api-keys.handler.ts

revokeApiKeyHandler fetches by publicId (no kind filter) and guards cross-org with existing.orgId !== org.id. For service keys (orgId=null), null !== 'any-org' → 404 — safe. But the guard's intent is implicit. An explicit if (existing.kind === 'service') return notFound() would make the protection clear and survive future handler refactors that might change the cross-org check.

createServiceKeyShell lacks the advisory lock that createApiKeyShell uses before its pre-check

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

Customer createApiKeyShell acquires acquireOrgCreateLock before the duplicate-name pre-check to make count→insert race-free. createServiceKeyShell does not acquire a lock; the pre-check is raceable. The DB partial unique index correctly catches the race and the isUniqueViolation handler converts it to serviceNameTaken. This is the backstopped case documented in the comment — not a live vulnerability, but the most privileged credential type has weaker defense-in-depth than customer keys.

No meta-gate test for service actor with insufficient scope — scope-gate fix branch is untested

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

The fix changed the scope-enforcement condition from actorType === 'machine' to actorType !== 'user' so service actors are also scope-checked. But every test route that accepts service actors has scopes:[] — so the scope-check branch for service actors is never exercised. A regression to the old condition leaves all tests green. Add a test contract with auth:['service'] + scopes:['catalog:write'] and assert that serviceAuth(['bills:read']) returns 403 insufficient_scope.

Outbox event rows not cleaned up in service key integration tests

domains/core/src/api-key/__tests__/api-key.integration.test.ts:156

createServiceKeyShell now writes outbox events. The integration test cleans up apiKeys rows but not domainEvents. If FK is not ON DELETE CASCADE, events accumulate across test runs. The outbox-event assertion (expect(events).toHaveLength(1)) would fail on the second run since the query filters by aggregateId only. Verify CASCADE exists or add explicit cleanup: database.delete(domainEvents).where(eq(domainEvents.aggregateId, apiKey.id)).

Rotation test passes orgRotId for a service key — context mismatch in test command

domains/core/src/api-key/__tests__/api-key.integration.test.ts:243

rotateApiKeyShell is called with orgId: orgRotId for a service key (orgId: null). The guard checks kind === 'service' before using orgId, so the test passes — but it doesn't match the real call site semantics (a caller trying to rotate a service key wouldn't know which orgId to pass). The test would still pass if the guard were removed and the org-id were accidentally used. Minor — the domain guard is the real protection.

isUniqueViolation defined three times across core domain under different names

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

The function is now defined locally in api-key.shells.ts (isUniqueViolation), in column-configuration.shells.ts (isPostgresUniqueViolation), and secret-configuration.shells.ts (isPostgresUniqueViolation). Additional inline variants exist in utility/cross-domain. Extract to domains/core/src/shared/ (which already exports outboxQueries and createShellLogger) under a stable name. The api-key variant has the correct cause-fallback; the utility/cross-domain variants that only probe top.code are missing it.

ApiKeyServiceRotationUnsupported maps to API_KEY_INVALID_NAME (wrong HTTP 422 vs declared 400, wrong semantics)

apps/platform/src/api/mappers/api-key.mapper.ts:78

The new ApiKeyServiceRotationUnsupportedError has statusCode:400 on the domain type, but the mapper routes it through fail('API_KEY_INVALID_NAME', ...) which codes.ts maps to HTTP 422. This is a direct convention violation: the domain-declared status (400) is silently overridden, and the public code conflates 'name string malformed' with 'operation unsupported on this credential class'. Callers cannot distinguish the two. Fix: register API_KEY_SERVICE_ROTATION_UNSUPPORTED: 400 in codes.ts and use it here.

findByOrg returns rows.map(toApiKey) as OrgScopedApiKey[] with no runtime guard

domains/core/src/api-key/api-key.queries.ts:42

The cast is logically justified (eq(orgId, x) cannot match null-org rows), but it's a type assertion with no narrowing. If the query ever gains an OR branch, the cast silently lies. The downstream mapApiKeyToResponse now reads key.orgId directly with no coercion. A filter(k => k.orgId !== null) before the cast, or a type guard, would make the narrowing structurally enforced.

CI integration test step hardcoded to one file; 35+ other integration suites still pass vacuously

.github/workflows/pr-checks.yml:263

The new step runs src/api-key/__tests__/api-key.integration.test.ts by exact path. There are 36 *.integration.test.ts files across core/utility/cross-domain/metrics domains — all still early-return without a DB in the validate job. Also, the step is gated on db-changes.outputs.changed == 'true': a logic-only change to api-key.shells.ts would skip it entirely. Fix: use a glob pattern (src/**/*.integration.test.ts per domain filter), and reconsider the condition to also include domain source files.