Resolving locale, route permissions, and workspace projection.
Current scope: Guest
Category: 10_normative | Version: v1.0.0
Owner: DOCUMENT_CUSTODIAN | Review cycle: 90 days
Approval authority: GOVERNANCE_ADMIN
Documentation portal is read-only. Editing and mutation endpoints are disabled.
Kvary platform is originally created in Georgian. Where a Georgian version exists, Georgian is authoritative for platform UI, documentation, and legal interpretation.
Translations into other languages are provided for convenience. Some records may originate in other languages and carry their own source or legal locale for a specific flow, but where a Georgian version is available, the Georgian version prevails for platform-level wording and interpretation.
Metadata incomplete: Document ID, Version, Status, Owner Role, Last Review Date, Next Review Date, Change Log
This sprint closed the remaining authenticated-mutation gap from Sprint 93.
The parity claim here is limited to the first-cut KES HTTP/runtime surface:
It is not a claim that Kafka relay, projection, idempotency, or DLQ/replay backbone is already KES-local.
Direct old host vs new host:
PUT /kes-orchestrator/process-mapPOST /kes-orchestrator/casesGateway path verification:
PUT /api/v1/kes/orchestrator/process-mapPOST /api/v1/kes/orchestrator/casesRead framing retained:
GET /kes-orchestrator/process-mapGET /api/v1/kes/orchestrator/process-mapCanonical repo dev procedure remains:
svc-auth with DEV_AUTH_TOOLS=truePOST /auth/dev/impersonate or POST /api/v1/auth/dev/impersonatetokens.accessTokenThat 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:
JWT_SECRET: dev-secret-change-mesubemailsidtype: "access"iatexp/auth/meThis was enough to verify the exact failing stage and the KES mutation path itself without changing auth behavior.
The earlier 401 invalid_access_token was not a KES mutation-handler failure.
It failed earlier in the auth pipeline:
verifyAccessToken(...)401 invalid_access_token/auth/me principal resolution did not run for that failure pathThis is grounded in:
The earlier temporary API 404 was also not KES runtime drift.
It was a wrong path:
/kes-orchestrator/process-map/api/v1/kes/orchestrator/process-mapTwo probe issues were isolated and removed:
/api/v1Once those were corrected, authenticated mutation requests moved past auth ingress and into normal KES validation and mutation handling.
Using a valid repo-compatible access token:
PUT /kes-orchestrator/process-map with { "actorId": "...", "steps": [] }
200POST /kes-orchestrator/cases with valid required fields
201Using the same auth procedure and equivalent payloads:
PUT /kes-orchestrator/process-map
200POST /kes-orchestrator/cases
201Correct mounted gateway path:
PUT /api/v1/kes/orchestrator/process-map
200POST /api/v1/kes/orchestrator/cases
201This was verified both:
svc-kes hostAuthenticated mutation happy-path parity is now confirmed for the checked first-cut KES runtime surface.
Confirmed items:
caseId and timestamps