feat/one-api

decision.value.event is computed but never used — shell re-derives outbox inline

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

All four sibling operations (createApiKeyShell, rotateApiKeyShell, revokeApiKeyShell, deleteApiKeyShell) pass decision.value.event.eventData to the outbox insert. createServiceKeyShell ignores decision.value.event entirely and re-derives the outbox payload inline from the inserted row (publicId, orgId, name, prefix, scopes). The CreateServiceKeyDecision.event field is dead: any future change to the event shape in decideCreateService will silently not affect what is persisted. This breaks the FCIS guarantee that the decision is the sole source of what-to-write. Fix: use decision.value.event.eventData in the outbox call (post-filling aggregateId from inserted.id as the decision documents), or drop the event field from CreateServiceKeyDecision to make the omission intentional and visible.

Shell double-trims: uses trimmed name for DB query but passes untrimmed command.name to decision

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

Line 452 computes `const name = command.name.trim()` and uses it for findActiveServiceByName (line 467). Line 472 passes `{ name: command.name }` (untrimmed) to decideCreateService, which re-trims internally. Both paths resolve to the same value today, but ownership of trimming is split between shell and decision — a fragile asymmetry not present in any sibling operation. The canonical FCIS pattern: either the shell normalises once and passes the normalised value everywhere, or the decision owns normalisation and the shell passes raw input. Pick one: pass `name` (already trimmed) to decideCreateService and remove the re-trim there, or keep the re-trim in the decision and have the shell query with the decision-resolved name.

rlsProxy is mechanically correct — is_local=true correctly scopes both GUCs to the transaction

packages/database/src/rls.ts:44

set_config('request.jwt.claims', ..., true) and SET LOCAL ROLE are both transaction-scoped. The refactoring from two 26-line copies to a shared helper changes no behavior. The Reflect.get fallback is standard Proxy practice. RLS drift between the two wrappers is now structurally prevented.

SERVICE_NAME_PATTERN regex is correct — 1-64 char range verified by tests

domains/core/src/api-key/api-key.decisions.ts:436

/^[a-z][a-z0-9-]{0,63}$/ encodes exactly 1-64 chars. The unit tests confirm 'a' (1), 'a'.repeat(64) (64) pass and 'a'.repeat(65) (65) fails.

rlsProxy claims parameter is an open Record<string,string> — type does not constrain future callers

packages/database/src/rls.ts:36

Both current callers pass verified JWT values so there is no injection path. However, rlsProxy accepts any Record<string,string>, making it easy for a future caller to pass an untrusted string. A closed type (discriminated union of the two valid claim shapes, or separate typed overloads) would let the type system prevent misuse before runtime.

Service key scopes=['*'] is hardcoded — acknowledged as architectural debt

domains/core/src/api-key/api-key.decisions.ts:495

No active vulnerability: service keys authenticate on the internal mount only, and no HTTP route exposes createServiceKeyShell to external callers. The code comment acknowledges this will be revisited when a real permissions model lands.

rlsProxy non-transaction passthrough is documented — no new exposure

packages/database/src/rls.ts:36

The proxy only intercepts .transaction(); bare selects pass to the admin connection. This is documented in the module header and rls-checklist.md. No change in behavior from this diff.

CreateServiceKeyPrepared.hashedSecret naming pulls infra term into decisions layer

domains/core/src/api-key/api-key.decisions.ts

The type is structurally clean (no infra imports), but naming a field 'hashedSecret' in decisions.ts leaks an implementation detail from the scrypt pre-computation step. Consider 'secretHash' or moving the PreparedInput type to api-key.shells.ts where it is produced. Not a functional issue.

Hardcoded contract RPUs ('900000000001-3') will hit unique constraint on re-runs if cleanup is partial

apps/platform/src/__tests__/integration/contract-access.test.ts:66

The partial unique index uq_utility_contracts_one_active_per_rpu blocks multiple active rows with the same contract_number. mkContract inserts status='active' contracts with hardcoded contractNumbers. If beforeAll partially succeeds (e.g. sited contract inserted, then site insert throws), afterAll returns early via `if (!available) return` without cleaning up, leaving active contracts with those RPUs. The next run fails with a unique-constraint violation. Fix: suffix the contractNumbers with a timestamp (same approach used for publicIds) so each run gets unique RPUs — e.g. `` `900000000${Date.now().toString().slice(-3)}` `` — or make the partial-setup cleanup unconditional.

Grammar tests miss trailing-hyphen and consecutive-hyphen edge cases

domains/core/src/api-key/__tests__/api-key.decisions.test.ts:432

SERVICE_NAME_PATTERN allows 'cfe-' (trailing hyphen) and 'cfe--pipeline' (consecutive hyphens). Neither is tested. If the spec intends stricter kebab-case (no trailing or consecutive hyphens), these should be reject cases; if the permissive behavior is intentional, they should be documented accept cases.

Whitespace-only service name (trim → empty) not tested

domains/core/src/api-key/__tests__/api-key.decisions.test.ts:447

The trim test only covers ' cfe-pipeline ' (valid after trim). A whitespace-only input (' ') trims to '' and fails SERVICE_NAME_PATTERN correctly, but there is no test for this path. The sibling decideCreate test suite includes it.

contract-access.test.ts passes service-role db — RLS enforcement layer not exercised

apps/platform/src/__tests__/integration/contract-access.test.ts:140

The test passes the bare admin database (service-role) as rlsDb. RLS claims are not injected, so the transaction reads all rows. The business-logic gate is validated correctly, but a RLS policy regression that leaked cross-org rows would pass these tests. A companion assertion with createRLSDb(database, fixture.userA.authId) would complete the coverage.

Silent-pass pattern: `if (!available) return` gives false-green when DB is absent

apps/platform/src/__tests__/integration/contract-access.test.ts:139

Vitest counts early-return tests as passing (0 assertions) rather than skipped, producing a misleading green signal. Use `test.skipIf(!available)(...)` or `ctx.skip()` in beforeAll so the reporter surfaces the skip.

not_found sentinel is a 27-char ID vs the standard 30-char prefix_ULID format

apps/platform/src/__tests__/integration/contract-access.test.ts:163

'uct_01DOESNOTEXIST000000001' is 27 chars; standard public IDs are 30. findByPublicId does a simple WHERE clause so this works, but a realistic 30-char fabricated ULID would better model the production path.

Dead blank line left after inline grammar check removal

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

After `const name = command.name.trim();` there is a leftover blank line where the removed inline validation block used to be. Remove it.