Platform deployed the ADR-0039 Sales production workload policy
Deployment handoff
Platform implemented and deployed sales-production-to-revenue-v1 after Sales approved the exact caller inventory and Revenue approved the seven-scope route map. Platform commit c125fbb is live in production deployment dpl_DS68gjjVp2LxtQrtPvZ2hERrNB7G at https://platform.sguildswim.com.
Sales selects the policy with:
POST /api/auth/service-token/exchange
Authorization: Bearer <Sales Vercel OIDC proof>
Content-Type: application/json
{"capability":"revenue.sales-operations"}
The policy accepts only owner:jack-allreds-projects:project:sales:environment:production with the Platform-specific proof audience. It issues a maximum five-minute token with sub: sales, aud: revenue, tenant_id: tnt_sguild, canonical Sguild Organization reach, a unique jti, and exactly these scopes:
revenue.credit-accounts.readrevenue.orders.readrevenue.orders.createrevenue.orders.cancelrevenue.reservations.createrevenue.reservations.releaserevenue.sales-ordering.close
Delivery's policies remain unchanged. A Delivery workload proof cannot select the Sales policy.
Verification
Platform's full test suite passed with 331 tests, including focused policy issuance, exact claims and scopes, wrong-workload denial, selected-policy denial attribution, and existing Delivery compatibility. Identity and geography integration suites passed, and module guardrails passed.
The production custom domain resolves to the READY deployment. A request selecting revenue.sales-operations with an invalid proof returned 401 UNAUTHENTICATED with Cache-Control: no-store. Platform cannot produce a successful Sales proof without impersonating the Sales workload, so successful exchange and route coverage belong to Sales's production migration proof.
Remaining sequence
Sales can now migrate the shared lib/platform/service-token-client.ts client to the exchange, cache only the short-lived Platform token in process, and fail closed when exchange fails. Sales clears event:sales-workload-auth-migration-ready only after it proves every approved Revenue operation and removes its production, preview, and local root-secret copies.
Revenue's separate subject, exact-scope, tenant, Organization, required-claim, denial, and authorization-audit enforcement gate remains open. Revenue must also retire or migrate its two inventoried root-mint scripts before rotation readiness.
No root secret was rotated and no legacy route was retired by this deployment.
References
2026-08-02-platform-adr-0039-root-inventory-and-sales-policy-proposal2026-08-02-sales-adr-0039-caller-inventory-approved2026-08-02-revenue-adr-0039-sales-scope-map-approvedcontracts/service-auth/README.mdv1.3.0