The parity claim here is limited to the first-cut KES HTTP/runtime surface:

• authenticated mutation auth ingress
• authenticated mutation route behavior
• direct old-host vs new-host parity
• gateway path parity under the existing seam

It is not a claim that Kafka relay, projection, idempotency, or DLQ/replay backbone is already KES-local.

Exact Mutation Routes Tested

Direct old host vs new host:

• PUT /kes-orchestrator/process-map
• POST /kes-orchestrator/cases

Gateway path verification:

• PUT /api/v1/kes/orchestrator/process-map
• POST /api/v1/kes/orchestrator/cases

Read framing retained:

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

Auth Procedure Used

Canonical repo dev procedure remains:

1. run svc-auth with DEV_AUTH_TOOLS=true
2. call POST /auth/dev/impersonate or POST /api/v1/auth/dev/impersonate
3. use tokens.accessToken

That remains the correct repo-auth path.

In this Docker rehearsal environment, full svc-auth still could not be used because its runtime failed on the pre-existing native sharp linux runtime mismatch. Because of that, this sprint used a contract-compatible fallback fixture:

• same shared JWT_SECRET: dev-secret-change-me
• same required access-token claims checked by gateway and KES:
  • sub
  • email
  • sid
  • type: "access"
  • iat
  • exp
• same upstream principal-resolution contract shape through /auth/me

This was enough to verify the exact failing stage and the KES mutation path itself without changing auth behavior.

Where Auth Previously Failed

The earlier 401 invalid_access_token was not a KES mutation-handler failure.

It failed earlier in the auth pipeline:

• bearer token reached gateway or KES host
• JWT verification ran first
• token failed verifyAccessToken(...)
• request returned 401 invalid_access_token
• /auth/me principal resolution did not run for that failure path

This is grounded in:

• middleware.ts
• auth.ts

The earlier temporary API 404 was also not KES runtime drift.

It was a wrong path:

• wrong: /kes-orchestrator/process-map
• correct gateway path: /api/v1/kes/orchestrator/process-map

What Was Clarified

Two probe issues were isolated and removed:

1. the incorrect temp API path missing /api/v1
2. malformed / invalid bearer-token usage in the earlier mutation probe

Once those were corrected, authenticated mutation requests moved past auth ingress and into normal KES validation and mutation handling.

Old Host Result

Using a valid repo-compatible access token:

• PUT /kes-orchestrator/process-map with { "actorId": "...", "steps": [] }
  • status: 200
• POST /kes-orchestrator/cases with valid required fields
  • status: 201

New Host Result

Using the same auth procedure and equivalent payloads:

• PUT /kes-orchestrator/process-map
  • status: 200
• POST /kes-orchestrator/cases
  • status: 201

Gateway Result

Correct mounted gateway path:

• PUT /api/v1/kes/orchestrator/process-map
  • status: 200
• POST /api/v1/kes/orchestrator/cases
  • status: 201

This was verified both:

• through the fallback temp API pointed at the old host
• through a temp API pointed at the extracted svc-kes host

Parity Verdict

Authenticated mutation happy-path parity is now confirmed for the checked first-cut KES runtime surface.

Confirmed items:

• authenticated process-map mutation parity
• authenticated case-creation parity
• correct gateway route prefix and path usage
• correct transition from auth ingress into KES validation/mutation flow

Notes

• direct old/new mutation bodies used distinct IDs to avoid uniqueness collisions
• response-body differences that remained were expected generated values only, such as caseId and timestamps
• shared event-backbone ownership remains outside this parity claim on purpose