Delivery verifies paid ownership, durable preparation, exact replay and genuine lock compatibility locally
Delivery completes its named disabled local implementation and semantic-proof commitment. Runtime commit 6f2ee77 and proof checkpoint 9f2c008 are on local branch codex/adr-0049-payment-handoff; they are not pushed or deployed. The runtime requires the specifically allocated rehearsal database and private generated client, and remains disabled in production. This completion does not authorize activation.
Actual primary handoff
Sales' persisted lead.handoff.completed@1 event evt_01a0ef1b-5507-7ddb-91fa-1c9bcb198dd1 binds Lead lead_01a0e0d0-f83f-702c-b5e6-044d457506e7, Order ord_01a0e0d6-b18b-7167-8653-cc5fe9cd38c2 and the reserved primary Person. Platform's actual SDK made three wrong-HMAC attempts, retained an unresolved dead letter, and later replayed that exact event successfully. Delivery independently proved zero primary domain or inbox impact after the failed phase. A second SDK replay refused the resolved dead letter without another POST.
After correct delivery, direct private-Prisma reads found exactly one active Customer (cmun7dnhj0000voudyyz4zsp0), one completed logical receipt (phr_5aa25f4b93b745465fe02dcb206827aff75ac84d), one payment ownership row and two open tasks: initial preparation and scheduling. The original payment time remains 2026-09-27T03:41:37.057Z; handoff time is 2026-09-29T21:39:00.682Z. Canonical tenant tnt_sguild remains separate from the Customer's historical organization-scoped tenant column. No lesson, reservation or first-lock fact was invented for this primary handoff.
The actual pure Workbench composer and view predicate, supplied with read-only Customer/task/zero-lesson source facts, return Book and Schedule first lesson with the canonical market. An absent market-name snapshot uses Market details pending. This establishes source-backed classification, not browser rendering or full remote credit-coverage enrichment. Platform separately confirmed its actual reporting query retained one conversion and the same decision timestamp across transport recovery.
Recovery, duplicates and compatibility
Signed retries through the actual Delivery inbox returned 200 for the original event and a new transport ID with identical logical content. A separately labeled consumer-only conflicting payload returned 500 and remains a failed inbox record for reconciliation. Deep snapshots after each request preserved Customer, receipt, payment ownership and both tasks, plus all four earlier control receipts and eight tasks. Transport now contains two processed primary-related records and one failed conflict control, not additional Sales conversions.
Earlier actual private-Prisma controls proved concurrent logical duplicates, immutable-evidence conflict rejection, a committed pending preparation intent resumed by redelivery, completed-task preservation, repeat review without initial onboarding, and inactive history with visible reactivation review. Those synthetic consumer fixtures are distinct from the actual primary Sales producer proof.
Revenue then supplied real persisted credit.reserved@1, credit.locked@1 and customer.handoff@1 envelopes for two fresh control reservations funded by synthetic internal test credits. Delivery validated the exact owner account, reservation, organization, market, lesson and unreversed lock-debit evidence. Version 1 payloads omit some scope fields; the harness checked those through the owner manifest and existing Delivery projection without adding fields to or rewriting any envelope. No Revenue record or financial ledger was written by Delivery.
Both arrival orders passed. Payment-first ownership gained the genuine lock timestamp and reservation without another onboarding; lock-first history survived a later consumer-only synthetic paid-handoff fixture and received repeat review. Exact context attached before and after payment. Context for another Lead remained pending, and duplicate legacy handoff/context handling added no tasks or notes. Fresh future lesson intervals were recorded only after read-only checks confirmed the allocated IDs had never been created; the original interval artifact remains intact. The primary customer's first-lock facts remain null throughout these controls.
Evidence and remaining gates
The sanitized source evidence includes exact primary receipt, ownership, task and transport records, replay outcomes, actual Revenue envelopes and compatibility source rows. The dedicated database is adr0049_rehearsal_87e1d984f24647b98ec94310d4c98273, with Delivery schema delivery_adr0049_test. Both connection URLs, all 51 private-client model mappings, actual connected database and eight existing closure guards were verified. The preserved database was restored without reseeding after interruption.
Full runtime checks passed 859 tests plus eight audit-mapping tests, typecheck, smoke and the static lock-audit guardrail. Later proof-tool changes ran the actual read-only, signed-HTTP and compatibility commands recorded in the Delivery repo. Static audit success is not full financial reconciliation. Production workload issuance, full financial reconciliation capability, browser/full Workbench enrichment, broader dispatcher fanout and rollout acceptance remain separate gates. No production flag, deployment, provider charge or customer message changed. The isolated listener remains available only for the coordinator's remaining checks and shutdown sequence.