Sales production authentication exchanges and cleanup verified
Draft for coordinator publication only. ADR-0050/sales/015 passed its production authentication-only gate. This does not activate onboarding cancellation or establish recipient business authorization, invoice cancellation, reservation release or Lost completion.
One canonical invocation in window 58eb2ac6-cdcb-4d01-ac09-c91c6120fe0e ran diagnostic source 1dde6dad34e2300f2a752b7dffd15fa4bae82119 on deployment dpl_75CaRDVwwZ9mc3HmK72Mk1MfqbyE. Both explicit Platform exchanges returned 200/no-store. Sales verified real Vercel workload proofs and the returned RS256 tokens against the exact issuer, signing key, subject, scalar audience, scopes, tenant, singleton organization, timestamps and 300-second lifetime. Seven exact Sales audit records persisted.
| Capability | Request ID | Issued token JTI |
|---|---|---|
| revenue.onboarding-closure.sales | c0977e8a-0939-4edf-ad18-e98db589f1af | 144f128a-d52b-4b58-bd5d-97ae6c7a7fa2 |
| delivery.onboarding-closure.sales | dc2a5dc5-84a4-46bb-b85d-65e064a9f814 | addf1af4-571a-4c3d-9b9f-6c17969ce9a5 |
The coordinator independently read production Platform issuance audits and matched exactly one row per request/JTI, including policy, outcome, subject, audience, tenant, organization, scopes and issued/expiry times. Policies are sales-production-to-revenue-onboarding-closure-v1 and sales-production-to-delivery-onboarding-closure-v1. Platform remained pinned to source 78290b38f1ab49a7e54b41de9ad8263faf337cbf, deployment dpl_BpNjgi9ohaskNdkh8uh4NAtGJJ82 and kid hB6gJqJq02iUNjoN. The immutable Sales rows still describe Platform audit verification as required at invocation time; the later independent evidence satisfies that requirement without rewriting history.
Both exact artifacts were staged READY before promotion. Uploaded path sets and file hashes matched the reviewed packages. All seven temporary project settings were removed and the original 30-setting business snapshot matched before diagnostic promotion. Immediately after the single invocation, cleanup d8a292a66a3a65010109e8311b4bacd9b7005417 on dpl_8wpCYjJjH28ZkdypRf4KSnXQStJA became canonical and READY. The diagnostic route returned 404 with and without the former approval. The retained diagnostic URL returned protection 302, not a demonstrated route 404. Cleanup deployment has no diagnostic settings. The audit role is NOLOGIN, has no Sales schema/audit access, and has zero sessions after its own session was drained. Ephemeral owner custody ended. Previous 014 audit rows match their retained evidence exactly; old 013 window remains empty. Business configuration is unchanged, with no Revenue/Delivery business calls or activation.
The initial read-only preflight stopped because Platform uses GitHub source metadata rather than CLI source metadata. The owner-side invocation reader was adjusted to require agreement across all available source hashes with the same approved pin. No artifact or production state changed during that stop. Architecture evidence is configured ARM64 and exact uploaded configuration, not observed process.arch.
Evidence
- Sales .cache/proof-auth015/.tmp/proof015-live/summary.json, SHA-256 419a0bc5918b2f78b8f51d700cd0e27ee0f9d024f8eed137db87658400353b2d.
- The same directory contains result.json, staged-readback.json, cleanup-db-readback.json, cleanup-deployment-readback.json, the safe owner-side runner and a hashed evidence package.
- Platform .tmp/adr-coordination/ADR-0050/sales015-production/issuer-audit-result.json, SHA-256 dc1cbfda464dfa73d6f435addfde0472086250c47ff59851d4431885c444327c; an exact copy is included with Sales evidence.
- Diagnostic archive SHA-256 001eb5d20dc6743dd1cdcacab3a809a1047916b9db7fc844f9362d53d744317e; diagnostic manifest SHA-256 604d3400b0c9d6014fb87ac33921422fab733b9db6410b6e31dda45da5301359.
- Reused cleanup archive SHA-256 69b2bb9eaa186c21a3f82545fb6381cbe227586a4e9f5199ef3791c3b03634d3. Previous review artifacts remain preserved.