feat/one-api

constantTimeEquals short-circuits on length mismatch — leaks INTERNAL_API_KEY byte length

packages/api/src/middleware/internal-auth.ts:57

Returns false immediately when lengths differ, before calling timingSafeEqual. Leaks only the secret's length — documented as an accepted trade-off for a high-entropy fixed-length key. Low risk given the internal mount is not customer-facing. A constant-time compare over a uniform-length buffer would eliminate the oracle entirely.

Rate limiter is per-Lambda-container in-memory — stated limit is not globally enforced

packages/api/src/middleware/rate-limit.ts:68

The rate-limit store is a module-level Map, scoped to one Lambda container. Vercel may spin up many concurrent instances. A single IP can exceed the stated auth budget (10 scrypt calls/min) by landing requests across different warm containers. This is documented as intentional ('abuse prevention, not exact counting') but the gap is worth tracking. A Redis/Upstash-backed store or Vercel's edge rate limiter would close this.

OPTIONS method bypasses withRateLimit on /v1 mount

apps/platform/src/app/api/v1/[...ts-rest]/route.ts:163

All HTTP methods (GET, POST, PATCH, DELETE, PUT) go through withRateLimit before dispatch. The OPTIONS handler calls baseHandler(request) directly, without withRateLimit. No current OPTIONS routes exist in publicV1Contract, but any future route would be unthrottled. Fix: wrap OPTIONS with withRateLimit.

Multi-org session actors on public-v1 resolve memberships[0] as their org — potentially wrong org for multi-org users

apps/platform/src/api/handlers/public-v1/energy-summary.handler.ts:55

Every public-v1 handler extracts orgId as authReq.auth.memberships[0]?.orgId. For machine tokens this is correct (one org by construction). For session tokens with multiple memberships, memberships[0] depends on Supabase hook injection order — not necessarily the org the user intends. No cross-org leak (RLS + app filter enforce tenancy), but a multi-org user could see the wrong org's data. Tracked as a known convergence hazard; the org-claim GUC migration is in progress.

api-key.decisions.ts imports InsertApiKeyValues from queries.ts — type flow inversion

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

The canonical type flow is: Drizzle schema → domain type → decisions. InsertApiKeyValues is defined in api-key.queries.ts but referenced in CreateApiKeyDecision / CreateServiceKeyDecision return types. This inverts the flow: decisions → queries. The import is type-only (not a D1 infra violation) but creates a conceptual dependency inversion. Fix: move InsertApiKeyValues to api-key.type.ts so the direction is type.ts → decisions.ts → queries.ts.

Three contracts missing from barrel export in contracts/index.ts

apps/platform/src/api/contracts/index.ts:82

siteMonitoringStatusContract, siteSavingsContract, and portfolioContract are imported and registered in the combined router but NOT re-exported via export * in the barrel (lines 7-46 export 43 other contracts but omit these three). Handlers import directly from contract files so there is no functional breakage today. Fix: add three export * lines to the barrel.

No integration test pins 'service actor on non-infra route returns 403' — gate metadata change would silently open access

apps/platform/src/api/utils/__tests__/public-v1-rls.test.ts

The unit test correctly pins that service actors get the unwrapped service-role db. The gate comment says 'route-metadata gate is the control here'. But there is no integration test asserting that a service-token request on an org-scoped endpoint (e.g. /v1/bills) returns 403. If a route's auth metadata is ever widened to include 'service', the service-role connection would have no org boundary. Add an integration test: mint a real service token, call /v1/bills, assert 403.

validateAuth: no test for token with orgId but missing orgPublicId claim

packages/api/src/middleware/__tests__/auth.test.ts

Tests cover machine actor (both claims present) and service actor (neither present). No test for a malformed claim where orgId is set but orgPublicId is absent. AuthContext.memberships[0].orgPublicId would be silent-empty; downstream callers reading it would degrade silently. Medium risk only for operator misconfiguration (tokens are Batu-signed), but worth a test to make the degradation explicit.

Rate-limit N+1 throttle firing not tested end-to-end through withRateLimit wrapper

apps/platform/src/api/utils/__tests__/public-v1-rate-limit-bucket.test.ts

Bucket keying and bypass-fix are unit-tested. But no test fires N+1 requests through withRateLimit and asserts a 429. A regression in the wiring (wrong budget object or wrong key passed to checkRateLimit) would not be caught. The individual pieces are each tested; the integration point is not.

OAuth route rate-limit bypass fix not cross-checked against main mount's fix

apps/platform/src/app/api/v1/auth/oauth/token/__tests__/route.test.ts

The bypass fix for the standalone OAuth route is independently tested; the main mount's fix is tested via public-v1-rate-limit-bucket.test.ts. But no shared test asserts both routes use the same IP-keying logic. If the standalone route regresses independently, the bucket test for the main mount stays green.

Dead branch in withInternalAuth headers extraction — both arms read req.headers

packages/api/src/middleware/internal-auth.ts:138

Line 138: `req instanceof Request ? req.headers : req.headers` — both branches of the ternary return the same expression. Both types have .headers. Simplify to `const headers = req.headers;`.

Inconsistent updateLastUsedAt error handling — service path silently drops errors, machine path logs

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

Service-key path (line 106) swallows errors with .catch(() => {}); machine-key path (line 172) logs a structured console.error. Both are intentionally fire-and-forget, but diverging behavior means future hardenings won't apply uniformly. Extract a shared fireAndForgetLastUsed(database, matched) helper.

loadPrivateKey / loadPublicKey are near-identical — extract a generic lazyKey helper

packages/api/src/auth/public-jwt.ts:161

Both functions follow an identical pattern: check module-level promise, start async IIFE if null, reset on error and re-throw. Only the promise variable, env var, and import call differ. A single lazyKey<T>(holder, loader) closure would eliminate ~25 lines of duplication and ensure any future hardening (retry cap, cache-miss metric) applies to both keys.

JWT config env vars re-read on every signBatuJwt / verifyBatuJwt call — inconsistent with key caching

packages/api/src/auth/public-jwt.ts:216

BATU_PUBLIC_API_ISSUER, BATU_PUBLIC_API_AUDIENCE, BATU_JWT_KID are read from process.env on every call (lines 216-218, 284-285). These are immutable for a container's lifetime — the key promises are already cached at module level. Lazy module-level constants would remove three property lookups per hot-path call and make the caching model consistent.