Token Acquisition Method

The canonical repo auth fixture remains the existing dev impersonation flow:

• POST /auth/dev/impersonate
• or gateway equivalent POST /api/v1/auth/dev/impersonate

This sprint confirmed that this is still the intended token-acquisition method for dev happy-path checks.

In this Docker rehearsal environment, full svc-auth could not be used because it still fails to boot cleanly with the pre-existing native sharp linux runtime mismatch. Because of that, the working parity check used a contract-compatible access token fixture:

• HS256 token
• signed with the shared JWT_SECRET
• carrying the exact claims shape expected by gateway and KES auth ingress

Gateway Auth Behavior

Gateway behavior is unchanged.

requireGatewayAuth(...) in middleware.ts:

1. extracts bearer token
2. verifies JWT signature and required claims
3. calls /auth/me
4. attaches principal to request auth context

Confirmed outcomes:

• missing token -> 401 missing_bearer_token
• invalid token -> 401 invalid_access_token
• valid token -> request reaches proxied KES mutation route

Principal-Resolution Behavior

KES host behavior is unchanged.

buildRequireServiceAuth(...) in auth.ts:

1. extracts bearer token
2. verifies JWT signature and required claims
3. calls /auth/me
4. attaches principal to the KES request auth context

This sprint clarified the earlier failure stage:

• the prior 401 invalid_access_token happened before /auth/me
• it was therefore a token-shape or token-signature problem, not a KES mutation-handler problem

In the isolated rehearsal stack, /auth/me was provided by the already-running contract-compatible auth stub from Sprint 93 because full svc-auth remained unavailable in this container environment.

Route Path Status

Correct direct service mutation path:

• /kes-orchestrator/process-map

Correct gateway mutation path:

• /api/v1/kes/orchestrator/process-map

The earlier temporary API 404 is now classified precisely:

• cause: wrong path
• exact mistake: missing /api/v1
• not a route-mount drift
• not an env seam problem
• not a KES runtime mismatch

Current KES Mutation Auth Status

KES mutation auth path is working for the checked first-cut runtime surface.

Confirmed with authenticated happy-path checks:

• direct old host
• direct new svc-kes host
• gateway fallback path
• gateway cutover-target path

Remaining Blocker

No KES-specific HTTP auth-path blocker remains for the checked routes.

The remaining auth caveat is environmental:

• full svc-auth was still unavailable in this Docker setup because of the existing native sharp runtime mismatch

That caveat does not look like a KES runtime drift issue.