Sales persists closure wire mappings and proves isolated admission ordering
Sales refreshed Revenue's published implementation memo and Revenue v1.0.0, Delivery v1.0.0 and service-auth v1.5.0 contracts. ADR acceptance and protocol agreement are satisfied, and independent adapter work is underway. The original Sales integration/rehearsal commitment moves from conditional to working with its satisfied ADR gate removed. It is not completed. No producer readiness or production activation follows from this status change.
Changes and publication
Sales commit 6bd7e3e is pushed on codex/onboarding-closure, following e5cb093. Checkout: sales/.cache/onboarding-closure. Changed files are modules/onboarding-closure/{dto.ts,schema.ts,revenue-protocol.ts,revenue-protocol.test.ts,delivery-protocol.ts,delivery-protocol.test.ts,producer-journal.repo.ts,producer-journal.repo.test.ts,admission-postgres.test.ts} and docs/onboarding-closure.md. No invoice-paid handoff paths or another Sales checkout were edited.
The invoice slice exact-inspects selected order and reservation IDs before mutation/recovery, persists UUID operation/request/fingerprint mappings through a tenant/lead/closure-scoped leased journal, and retains the same operation on uncertain transport or recovery. Inspection must return the exact requested set. Unknown ownership, paid amount, ambiguous external linkage, nonterminal decisions, unfamiliar reason codes or contradictory current assessment keep closure pending. More than 100 total obligations fail closed. The coordinator reports that Revenue now unions proven bindings with a total cap of 100; Sales does not rely on batching to exceed that cap.
The Delivery mapping slice persists both UUIDs for reserved holds, normalized invoice operation IDs and versioned immutable requests. Soft holds allocate no Revenue operation. Receipt validation requires matching bindings and current clear assessment; reserved holds additionally require a fresh Revenue verification callback. Version drift cannot mutate an existing request. New policy-re-evaluation generations remain blocked until supported predecessor semantics are published and integrated. These protocol modules have injected dependencies and are not yet wired to the live runner; its producer remains null.
Verification and limits
All 105 closure unit tests pass, including 18 Revenue protocol, 11 Delivery protocol and 5 journal tests. Type checking and diff checks pass. The ordinary unit invocation skips the explicit opt-in database tests.
Three real PostgreSQL admission tests passed separately in newly created database sales_closure_proof_82e491cf5f50494f9e8f4b32d77a198d, retained for evidence. Both source URLs were checked as loopback, and the new database identity and sales table schema were checked before fixture writes. There were no shared mesh or Revenue fixture writes. The tests invoke Sales' actual admission helper and literal lead row lock through a minimal pg repository adapter: closure wins first, earlier external work remains durably visible, and concurrent admission permits only one external call while uncertainty remains open. This proves SQL lock ordering and helper behavior, not generated Prisma query parity or the entire closure transaction. The retained database contains synthetic proof rows only.
No cross-domain rehearsal was attempted. The coordinator's Revenue isolation incident hold was respected; these tests used a separate Sales-created database and no contaminated records.
Remaining integration and rehearsal
Revenue's exact receipt JSON names/examples are awaiting its publication clarification; current decoding follows observed local producer fields and stays gated. Delivery's initial authoritative lesson-version inspection route is awaiting the agreed additive publication, so Sales does not infer versions from mirrors. Published Platform selectors will be integrated without changing default workload scopes; no deployed mint capability is assumed. Live producer HTTP orchestration, direct Revenue release-receipt verification, and generated-Prisma admission proof remain work, not completed evidence.
Once producers are ready, agree a disposable cross-domain target with verified actual database/schema destinations, generated clients and installed migrations/SQL guards before any fixture write. Keep fanout and external customer actions disabled. Use newly created future unpaid obligations and explicit correlations. Prove invoice-first cancellation, Delivery preparation/release/finalization, both race winners, interruption at each commit boundary and current receipt assessment before completing Lost. Provider sandbox races and production policy proof remain separate gates. No reset, production deployment, activation, or live obligation cancellation is authorized by this memo.