ADR-0049 coordination sequence and joint proof requirements
The operator invoked Platform's Sguild ADR Coordinator for ADR-0049. Platform is exchanging requests and evidence directly with the existing domain tasks. Each domain retains its implementation, acknowledgment, and commitment ownership. This memo records sequencing and proof requirements; it does not acknowledge the ADR for another domain or clear the Sales readiness event.
Work sequencing
Sales task 49 (01a0e08d-8f05-73d1-a0db-0c2bf309b32f) owns the disabled producer and combined Sales payment/cancellation proof. Its existing local implementation and 509-test report remain distinct from end-to-end readiness. Sales is coordinating shared paths with its ADR-0048 task in the separate codex/onboarding-closure checkout.
Platform task 48 (01a0e03a-33b7-7ed2-b7ec-6bcfd238220e) has completed its ADR-0048 scope and is handling ADR-0049 authorization review, disabled routing configuration, and history-backed reporting. Platform's ADR-0049 coordinator is 01a0e0a8-093e-7d80-b8ef-5997067ae039, host local. Canonical coordination publication and indexer operations are serialized with this participant.
Revenue task 48 (01a0e01e-15c6-77e3-9164-4d8270b788fd) and Delivery task 48 (01a0e01d-c101-7073-bb3b-2467e04bad8e) are finishing ADR-0048 checkpoints. Both reported that overlapping ADR-0049 runtime edits would be unsafe. ADR-0049 review remains read-only until those checkpoints; neither response is an architectural acknowledgment. The ADR-0048 coordinator (01a0e095-f279-7fd0-a8ef-92ce8f9547fc) retains that work and receives material shared-race findings.
Review findings
Paid-before-booking handoff requires explicit organization provenance. Sales found that its existing no-booking correlation and onboarding metadata do not carry organization, and its first implementation used a singleton fallback. The requested correction is additive Sales-owned provenance from authenticated or verified scoped invoice selection/creation. Missing or conflicting historical provenance defers handoff rather than assigning a default. This follows the proposed ADR's explicit organization rule and does not introduce a new Revenue API.
The shared Lead row lock alone does not establish cancellation/payment serialization. A SERIALIZABLE transaction can retain a snapshot from before a competing admission inserts its Task. Sales is checking a Lead-row version write under the admission lock and testing both real entry points. An admitted but unresolved producer operation must remain visible and block handoff; terminal handed-off Leads must reject new Sales admission.
Sales confirmed that lead.stage.changed@1 emits the plain stage string terminal for both new paid handoffs and historical locked closures. The event carries neither substage nor handoff evidence, and terminal alone cannot classify a successful conversion. The authoritative discriminator remains immutable sales.lead_stage_history: new to_substage=handed_off with handoff_evidence=invoice_paid, alongside historical successful evidence. Platform will keep reporting history-backed and count each tenant/Lead conversion once. lead.handoff.completed@1 is supplementary evidence, not another conversion.
Platform's initial auth review found the exact assessment compatible with existing revenue.sales-operations, subject sales, audience revenue, scope revenue.orders.read. Revenue must still verify tenant, organization, Person, and Platform Market against canonical Order rows for each no-store read. This finding does not establish a deployed assessment endpoint.
Required evidence
| Owner | Evidence needed before the joint readiness decision |
|---|---|
| Sales | Explicit current invoice and organization provenance; real handoff and closure admission transactions in the same dedicated database; admission-first and handoff-first orderings; unresolved/unknown producer results; retry and serialization failure; immutable event, history, receipt, cleanup and no terminal resurrection. |
| Revenue | Owner acknowledgment of the exact assessment; coherent full-settlement timestamp and financial/operation revision; partial, offline, refunded and wrong-scope cases; unresolved cancellation/release/refund blocking and atomic unpaid cancellation safeguards. |
| Delivery | Owner acknowledgment and exact consumer binding; tenant/Lead/Order dedup; actual customer and OrgMarket ownership IDs; nullable first-lock facts; context in either order; recoverable preparation once; inactive/repeat and no-booking work; later-lock enrichment without duplicate onboarding. |
| Platform | Schema/registry mirror, least-privilege read review, disabled routing configuration, history-backed reporting and relevant validations. Live subscription and deployment readiness remain separate. |
| Joint | Isolated transport plus actual Delivery customer/ownership/preparation persistence, failed-delivery recovery, Sales queue removal, and the shared ADR-0048/0049 race proof. HTTP acknowledgment or synthetic assessment alone cannot satisfy this row. |
Each proof must name the checkout and commit or uncommitted state, exact test command, database/schema isolation, fixture and persistence identifiers, memo publication, and remaining limitations. Test-process-only flags may exercise the disabled code after isolation checks; saved environment flags and production remain unchanged.
Release state
ADR-0049 remains proposed. SALES_PAYMENT_HANDOFF_ENABLED stays false outside explicitly isolated proof processes. No production deployment, financial mutation, customer message, historical fanout, or existing-client transfer is authorized by this coordination pass. The Sales paid-invoice-handoff-ready event remains uncleared until owner decisions and the required evidence are accepted. Architecture acceptance and eventual rollout approval are separate from local implementation progress.