ADR-0049 isolated joint handoff proof and remaining release boundary
The authorized local rehearsal exercised Revenue's real authenticated assessment, Sales' normal handoff service, the Platform dispatcher's durable failure/recovery path, and Delivery's actual signed inbox and semantic persistence. This memo consolidates the owner evidence under the joint rehearsal plan. It adds no architectural decision or production authorization. paid-invoice-handoff-ready remains uncleared.
One actual no-booking handoff
The preserved isolated database is adr0049_rehearsal_87e1d984f24647b98ec94310d4c98273 at 127.0.0.1:55434. The primary scope is canonical tenant tnt_sguild, organization org_01900000-0000-7000-8000-000000000001, Person per_01a0e0c4-6dfe-72c8-8a13-fb695df305df, and market mkt_01a0e0c4-68d7-7498-b360-13c5fcc2c5dc. Each domain owns its schema and writes. The host interruption was recovered by restarting the existing native PostgreSQL cluster and verified fixture services without resetting data or replaying payment.
| Evidence | Actual source or result |
|---|---|
| Sales Lead | lead_01a0e0d0-f83f-702c-b5e6-044d457506e7 |
| Revenue Order | ord_01a0e0d6-b18b-7167-8653-cc5fe9cd38c2 |
| Revenue payment event | evt_01a0e0f5-259a-7a06-800f-45a5c5e2b6d5 |
| Full-settlement time | 2026-09-27T03:41:37.057Z, preserved from Revenue provenance |
| Sales completed event | evt_01a0ef1b-5507-7ddb-91fa-1c9bcb198dd1 |
| Sales stage event | evt_01a0ef1b-5411-7803-92a0-d48aae1216da |
| Sales history | lsh_01a0ef1b-54a0-737c-9ba5-d021360a9782, decision at 2026-09-29T21:39:00.731Z |
| Delivery Customer | cmun7dnhj0000voudyyz4zsp0, active in canonical market |
| Delivery logical receipt | phr_5aa25f4b93b745465fe02dcb206827aff75ac84d, preparation completed |
| Delivery ownership | cmun7dnj50001voud92cvly22, payment evidence present, first-lock fields null |
Revenue's source is committed internal cash writeback and an actual transactional outbox event, not a real payment-provider charge. The primary has no lesson booking. Sales observed the actual payment event while handoff was disabled, then used the real assessment and normal preview/apply service. It produced exactly one immutable receipt, history row, stage event and completed event; a repeat invocation returned the existing result. Actual queue queries exclude it from all four active stages and include it in terminal. Two pending Sales tasks were cancelled and callback/text follow-up summaries cleared. The prior payment audit remains unchanged. See the Sales joint proof.
Delivery verified one Customer, one completed logical receipt, one payment ownership and two open tasks for initial preparation and scheduling. No lesson or context was fabricated. First lesson, reservation and first-lock time remain null. The actual pure Workbench composer and view predicate expose the customer in active Book with the canonical market key. This is source-backed composition evidence, not a browser or complete remote-coverage test.
Failure, duplicates and reporting
Platform selected only the exact newly emitted event through a non-updatable view and separate transport tables. Three wrong-HMAC attempts returned 401 and created durable DLQ dlq_01a0ef1c-9a8e-79a8-a266-b6003406f6d2. Delivery independently proved zero primary impact before recovery. The actual SDK replay API then delivered the same envelope once, returned 200 and persisted resolution. A second replay was rejected without a second POST. Existing Sales transport state was unchanged. Delivery's semantic rows, rather than the HTTP status alone, establish the successful transfer. See the Platform recovery/reporting proof, including its raw timestamp and timezone evidence correction.
Delivery separately sent the same event and a new consumer-only transport envelope with the identical logical payload. Both returned 200 and preserved Customer, receipt, ownership and task IDs and counts. A third envelope changed paid time by one millisecond and returned 500 with an immutable-evidence conflict; it remained an intentionally failed inbox row and caused no domain mutation. These synthetic transport IDs are retry controls, not additional Sales conversions. The original four Delivery control receipts and eight tasks remained unchanged through the primary proof.
Read-only execution of the actual SALES_HANDOFF_HISTORY_SQL counted one conversion at the Sales decision time before and after transport recovery. IDs and timestamps deep-matched. All eight financial-negative or preview-only Sales controls counted zero and had no specialized handoff event. Reporting did not double-count the specialized event or retries.
Negative evidence and compatibility
Fresh Revenue HTTP proof exercised the actual JWT verifier and source scope: expired, altered-signature and wrong-audience tokens returned 401; valid signed wrong-tenant, wrong-organization and missing-orders-read-scope tokens returned 403; mismatched Person/market returned 404. Anonymous access returned 401 and duplicate/extra query parameters 400. Both missing Order financial scope and zero-price ambiguity returned 503. The issuer's missing-scope fixture retained the other six valid scopes, establishing an authorization denial rather than malformed claims.
Seven separate Sales controls used actual Revenue HTTP assessments and deferred partial payment, unresolved cancellation, pending/full refund, unknown historical settlement time, missing Order scope and zero-price ambiguity. All remained in the actual onboarding queue with no handoff rows/events and their open task. Invoice-less cash was eligible in preview only and caused no transfer. The primary before/after snapshot was unchanged. These control Leads use explicitly documented fixture correlations and are not eight production clients.
Delivery compatibility proof consumed unchanged, actual Revenue credit.reserved, credit.locked and customer.handoff envelopes. Revenue used three explicitly synthetic internal credits per control and genuine reserve/auto-lock writers, with an unreversed three-credit lock debit. No provider charge or primary payment replay occurred. The lock-first control retained genuine first-lock history and added repeat review without initial preparation. The payment-first control accepted later lock enrichment without duplicate tasks or notes. Exact context attached in both arrival orders; another Lead's context remained pending. The paid lock-first envelope was explicitly a synthetic consumer control, distinct from the primary actual Sales producer event. The final primary snapshot remained one Customer, one receipt, one ownership, two tasks and no first-lock or lesson facts.
Revenue additionally verified actual PostgreSQL overlap. Concurrent 400-cent, 600-cent and duplicate 600-cent writers produced 1,000 cents and two source events. A payment transaction paused after outbox insertion while an independent connection observed cleanup or assessment waiting on the real advisory lock; cleanup rejected paid cancellation and assessment saw committed settlement. In the reverse admission order, real closure admission paused at a mocked provider while payment committed; assessment remained pending with a later revision, and the canonical cancellation recheck returned 409 without a receipt or cancelling the paid Order. The corrected two-participant harness uses a separate read-only observer. Its initial pool-timeout attempt is retained and is not a passing result. This is bounded local producer concurrency proof with the documented provider seam, not every provider race or ADR-0048 crash boundary. See the Revenue assessment proof.
Verification, records and release boundary
Platform runtime is local commit 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a; its full 370 Vitest cases, identity/geography integration checks, typecheck, guardrails and warehouse structure validation passed. Sales' complete integration passed 1,679 tests across 138 files, with 15 conditional skips in the ordinary suite; its separate 11 actual PostgreSQL admission/handoff race cases passed using a synthetic Revenue seam. Subsequent narrow Sales tenant/proof changes passed 201 focused cases and typecheck. The Sales integration checkout is locally committed at 91c1a25f7df869afda0ead5ae380b7ff8f6e7457. These are distinct test runs and boundaries, not one combined end-to-end count.
Delivery runtime 6f2ee77 and proof checkpoint 9f2c008 passed 859 runtime tests, eight audit-mapping tests, typecheck, smoke and its static lock-audit guard; actual private-database, signed-inbox and compatibility commands passed separately. Its local consumer proof includes published sanitized evidence. Revenue passed 609 tests across 78 files, followed by 75 focused tests across four files after adding three test-only overlap cases, plus typecheck. Revenue runtime remains an uncommitted working-tree checkpoint on base fecab1cc63c5ef46aad551b3bb4a438ff3606a21, documented by exact source hashes, with intertwined ADR-0048 and unrelated edits preserved. Its source integration commitment remains working. Platform proof imported the existing local fanout source, including pre-existing unrelated changes, without modifying them; .tmp/adr0049-platform-proof-source-hashes.json records the exercised source hashes. The local Platform feature commit alone is not a claim of a clean whole-worktree proof.
No application source was pushed or deployed, no production handoff or fanout flag enabled, and no existing-client reconciliation or customer communication performed. Delivery's current local database guard is intentionally rehearsal-specific and requires release review. Deployed consumer availability, authentication, routing, safe rollout and the Sales readiness decision remain separate obligations. The database and historical evidence are retained. After proof completion Delivery verified and stopped only listener PID 24468 and its owned launcher PID 19008; port 3493 is unoccupied. Revenue verified and stopped listener PID 24028 and launcher PID 1516 on port 3492. Platform verified and stopped issuer PID 23820 on port 3490. Root independently confirmed ports 3490 through 3493 unoccupied, removed the disposable HMAC file, and confirmed shared PostgreSQL PID 6096 still listening on 127.0.0.1:55434. No database was deleted. Cleanup evidence is .tmp/adr0049-final-cleanup-proof.json.