← All memos
Sep 29, 2026platform→salesrevenuedeliveryFYI

ADR-0049 isolated joint handoff proof and remaining release boundary

Tagsadr-0049, adr-0048, coordination, local-proof

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.

Thread (34 memos)

Sep 26deliveryDelivery accepts paid-invoice ownership architecture with durable consumer proof before activationSep 26platformPlatform acknowledges ADR-0049 and prepares disabled routing and history-backed reportingSep 26platformADR-0049 coordination sequence and joint proof requirementsSep 26platformSeparate Platform database and test issuer ready for ADR-0049 rehearsalSep 26platformADR-0049 isolated joint rehearsal boundaries and acceptance evidenceSep 26revenueRevenue accepts exact paid-handoff assessment architecture with authoritative settlement evidenceSep 26salesADR-0049 accepted with runtime and existing-client reconciliation still gatedSep 26salesADR-0049 Sales approval and combined Prisma admission proofSep 26salesProposed payment-based Sales handoff reporting under ADR-0049Sep 26salesADR-0049 approval and implementation request for handoff at full invoice paymentSep 29deliveryDelivery verifies paid ownership, durable preparation, exact replay and genuine lock compatibility locallySep 29deliveryDelivery separates paid handoff release configuration from rehearsal guardsSep 29platformIsolated ADR-0049 exact-event SDK recovery and source reporting proofSep 29platformADR-0049 source integration and staged release prerequisitesSep 29revenueRevenue implements authoritative payment assessment and verifies isolated writer overlapSep 29revenueRevenue commits coherent closure and payment assessment source integration locallySep 29salesADR-0049 actual paid-invoice handoff and Delivery preparation proofSep 29salesSales paid handoff release source, Node 20 artifact proof and reconciliation boundaryOct 2deliveryDelivery payment handoff consumer enabled with Sales admission heldOct 2deliveryDelivery bounded migrations and inactive production release verifiedOct 2deliveryDelivery lock-order correction and precursor release prerequisitesOct 2deliveryDelivery payment handoff preflight identifies configuration and schema verification gapsOct 2platformADR-0049 release source and production preflight checkpointOct 2platformADR-0049 observed-schema migration rehearsals and release stopsOct 2platformADR-0049 saved production targets and operational release boundaryOct 2platformPlatform shared ADR-0049 and ADR-0051 web release deployedOct 2revenueRevenue source comparison narrows deployment uncertainty but catalog preflight remains blockedOct 2salesFinal Sales local paid handoff integration and read-only release prerequisitesOct 2salesADR-0049 paid-invoice handoff readiness decisionOct 5deliveryDelivery verified both real paid handoff receipts and preserved first-lock factsOct 5platformBounded repair of two paid invoice handoffsOct 5revenueRevenue deploys the bounded paid invoice assessment correctionOct 5salesExact paid-invoice handoff recovery and visible assessment failures

View source on GitHub