ADR-0039 root rotation is not yet safe because Sales still consumes the root-mint route

Revenue does not yet clear event:revenue-service-auth-enforcement-ready. Delivery's production migration is complete, but the current two-event definition of service-auth-root-rotation-ready omits an active root-mint consumer and would authorize an unsafe rotation.

Current Revenue verification result

Revenue's production verifier is not yet at the service-auth v1.1.0 bar. lib/auth/platform-jwt.ts verifies the Platform signature, issuer, audience, expiration, sub, and tenant_id, then returns only subject and tenant. It does not yet require or authorize organization_ids, exact operation scope, iat, nbf, or jti, and it does not emit the contract's resource-server authorization decision record. Revenue therefore cannot truthfully declare its enforcement event from the current deployment.

The shared routes also carry a sequencing constraint. Sales currently calls Revenue reservation, coverage, order, and release APIs using lib/platform/service-token-client.ts, which presents PLATFORM_SERVICE_JWT_MINT_SECRET or SERVICE_JWT_MINT_SECRET to Platform's consumer-facing root-mint route and asks for sub: sales. Several of those are the same Revenue routes Delivery now calls with the ADR-0039 scoped token.

Contract consequence

Service-auth contract section 9 says Platform rotates the root secret after every known consumer migration is complete, and that Revenue removes all no-scope compatibility before rotation. The current service-auth-root-rotation-ready all-of event names only Delivery migration and Revenue enforcement. Clearing Revenue's event under that graph would make the root-rotation commitment appear ready while Sales still depends on the old secret.

Requests

Platform, please correct the rotation gate so its definition of readiness includes migration of every active root-mint consumer, explicitly including Sales, before the root secret rotates or the consumer-facing route retires.

Sales, please confirm the active production callers and propose the smallest policy-bound workload exchange and exact Revenue scope set needed to replace the current root-mint client. Revenue will review the route-to-scope map and will not broaden Delivery's policy to cover Sales operations.

Revenue will continue the verifier, route-policy, and authorization-audit implementation against the accepted contract. Revenue will declare event:revenue-service-auth-enforcement-ready only after the intended token succeeds in production, wrong subject, missing scope, wrong tenant, and wrong Organization reach fail with the contract's stable 401 or 403 behavior, and a token-correlated authorization decision is observable without secret material.

References

• adrs/ADR-0039-platform-issued-workload-identity.md
• contracts/service-auth/README.md
• 2026-07-30-platform-adr-0039-workload-identity-ack
• 2026-07-30-revenue-adr-0039-workload-identity-ack
• 2026-08-02-delivery-adr-0039-workload-auth-migration-ready