ADR-0049 isolated joint rehearsal boundaries and acceptance evidence

The operator instructed the coordinator to proceed after ADR-0049 acceptance. The architecture is accepted; the earlier coordination-sequence memo's proposed-status description is historical. This plan implements the accepted decision and adds no authority for production activation, deployment or existing-client reconciliation. The Sales paid-invoice-handoff-ready event remains uncleared.

Isolation and sequencing

Use the new Platform foundation, database adr0049_rehearsal_87e1d984f24647b98ec94310d4c98273 on 127.0.0.1:55434. Each owner verifies both database URLs, source and generated schema declarations, and actual database/schema before installing its own schema or creating its own rows. Canonical tenant tnt_sguild remains distinct from organization org_01900000-0000-7000-8000-000000000001. The foundation manifest supplies the fresh Person, market and service area. Owners publish sanitized extensions identifying their rows, checkout, commit or uncommitted source state, private generated client, runtime and controls.

Ports are 3490 for the Platform fixture issuer, 3491 for Sales, 3492 for Revenue and 3493 for Delivery. Services bind to loopback. ADR-0048 ports 3480, 3482 and 3483, its database, source checkout and generated clients stay under that coordinator's control. Sales is integrating the complete ADR-0049 runtime and accepted ADR-0048 admission guards in a separate checkout. Revenue and Delivery switch after their fresh corrected-event proof checkpoint, without waiting for every ADR-0048 release check. Their owners select safe checkouts; no other task edits their application repositories.

Broad dispatcher fanout and external-action runners remain false. Test-process-only payment handoff enablement is permitted after isolation checks. Settlement fixtures must use Revenue-owned committed source writers and disclose whether they represent an offline/internal settlement proof or real sandbox-provider evidence. A synthetic assessment cannot stand in for the Revenue endpoint. No production provider operation, customer message, historical event replay or shared-mesh reset belongs to this rehearsal.

Joint evidence sequence

1. Revenue implements and proves the accepted exact assessment. Its authenticated HTTP response must be no-store, contain every v1 field, and match the source Order, invoice, Person, organization and market. Positive full settlement, installment progression, authoritative full-settlement time, coherent writer-maintained revision, partial/refunded/unresolved-operation negatives and wrong-scope authorization are prerequisites for relying on it.
2. Sales invokes the real assessment and its actual handoff service for the selected current invoice. Preserve before/after evidence for Lead version and selection, terminal/handed_off outcome, invoice_paid history, immutable receipt, same-transaction outbox and cleanup. Verify removal from operational queues and suppression of queued contact work. A no-booking positive case must have explicit organization provenance and null lock references.
3. Dispatch only the newly emitted, exact Sales event through Delivery's signed inbox, with its canonical envelope and unchanged payload. Delivery verifies durable logical receipt, customer, OrgMarket ownership and preparation/scheduling rows. Record their actual IDs and counts. An inbox 2xx or transport dedup row alone is insufficient.
4. Exercise retry with the same event and the same logical handoff in a new envelope. Verify one ownership transition and one set of preparation steps. Reject conflicting logical content. Demonstrate recovery after a failure following customer commit; the durable intent must resume unfinished preparation. Include context before and after handoff, inactive/repeat customer behavior and later first-lock enrichment without duplicate onboarding.
5. Re-run the relevant shared Sales admission/handoff race cases against the full integration source. Extend with real Revenue operations where required to prove cancellation/payment exclusion, including pending or recovering producer operations and zero-payment cancellation guards. Record actual transaction conflicts and source versions. Previously passed synthetic Revenue race cases remain useful Sales evidence but are not relabeled as cross-domain producer proof.
6. Reconcile event and persistence evidence across all three owners. Verify the single history-backed reporting conversion independently from the supplementary specialized event. Each owner records limitations and updates only its own satisfied commitments. Local evidence does not imply deployed endpoint, live subscription or rollout readiness.

The current dispatcher loop has no public exact-event filter. For bounded recovery proof, Platform may create a separate transport schema in this disposable database, with a read-only event view restricted to the exact new Sales event and fresh cursor, dedup and dead-letter tables. The actual SDK consumer and exact-row dead-letter replay then establish retry persistence in those isolated tables. This does not change Sales outbox history or existing delivery cursors, and does not establish deployed fanout readiness. Delivery semantic persistence and preparation recovery remain independent acceptance evidence.

Negative controls and evidence retention

Revenue proves denials using the test issuer's signed wrong-tenant, wrong-organization and missing-scope fixtures at the actual endpoint; wrong audience, expired and altered signatures must also fail. Cross-Person and cross-market requests cannot disclose another scope's facts. A missing or ambiguous invoice, uncertain settlement provenance, partial payment, pending or completed refund, stale assessment, replaced selection or unresolved cancellation cannot transfer Sales ownership. Actual route evidence and synthetic parser/unit evidence are labeled separately.

Preserve failed-run artifacts and create fresh obligations for retries after terminal cancellation. Do not rewrite old invoices, reservations, ledger entries, dedup receipts or proof windows to obtain a pass. Evidence reports contain source hashes, exact commands, sanitized fixture IDs, response statuses and semantic row assertions, without bearer tokens or provider secrets. Retain the dedicated database; stop only verified ADR-0049 fixture processes after the coordinator's explicit cleanup request.