ADR-0049 actual paid-invoice handoff and Delivery preparation proof

The isolated primary flow now reaches actual Delivery customer, payment ownership and preparation records before lesson lock. Revenue supplied real persisted internal-invoice settlement and a fresh authenticated assessment, Sales closed through the normal handoff service, and Platform delivered the exact Sales event after a durable failure/replay test. This memo does not clear paid-invoice-handoff-ready, deploy any application, or apply existing-client reconciliation. Curated-context arrival ordering and genuine later-lock compatibility remain separate owner evidence.

Source and environment

Sales has the complete runtime, recovery and Workbench integration in C:/Users/jallr/Documents/Sguild/repos/sales/.cache/payment-handoff-integration, branch codex/payment-handoff-integration, local commit 91c1a25f7df869afda0ead5ae380b7ff8f6e7457. It includes ADR-0048 owner baseline 4c5cf5d0681d02e277532c67144780d31c84880f; all closure guards are retained. This supersedes the earlier bounded-checkout limitation without rewriting that historical proof. The original dirty Sales workspace remains preserved. Sales source has not been pushed or deployed.

The joint database is adr0049_rehearsal_87e1d984f24647b98ec94310d4c98273, native PostgreSQL on 127.0.0.1:55434. Both database URLs, actual database identity, private dependencies and all 48 Sales Prisma model schemas are checked before each mutable phase. Ninety Sales migrations are installed without broad seeding or reset. After the machine pause, Platform restored the existing cluster and all owners revalidated their loopback services. The real Revenue HTTP assessment uses a scoped short-lived token from the isolated issuer. No credentials are published here. Only the isolated Sales apply child enables publication; broad fanout, external actions and production remain disabled.

Exact primary proof

Revenue's original settlement was not replayed. Sales first consumed the actual payment event with handoff publication disabled, preserving payment audit aud_01a0ef17-7632-7418-a192-b7d7dc31e612 while the client stayed active. A fresh eligible preview and normal apply then produced one terminal/handed_off closure with invoice_paid, cancelled both pending Sales tasks, and cleared callback/text follow-up summaries. Existing payment evidence did not prevent repair. An immediate duplicate returned the same receipt/event. Actual getLeadInboxByStage queries exclude the client from all four active queues and include it in terminal. The original payment audit and timestamp remain unchanged.

The authoritative assessment has revision 84 and assessed_at 2026-09-29T21:39:00.612Z. Sales requires exact configured/context/assessment tenancy and exact selected invoice scope. It reads Revenue once before the transaction, then rechecks local selection/context/version and assessment freshness under the Lead lock. It does not claim a second Revenue read under that lock. This is confirmed internal cash invoice settlement, not an external provider payment rehearsal.

Platform's actual dispatcher ConsumerLoop made three wrong-signature attempts, all HTTP 401, and persisted dlq_01a0ef1c-9a8e-79a8-a266-b6003406f6d2. Delivery remained unchanged. A separate exact replay produced one HTTP 200 and durable DLQ resolution; a second resolved replay was rejected without another POST. The replay API does not write ConsumerLoop dedup, which is explicitly asserted. A new isolated transport schema exposes only the chosen Sales event. Existing Sales transport state is unchanged. This proves bounded SDK durability, not deployed fanout subscriptions.

Delivery independently verified these persisted rows after replay:

Delivery retains the original payment time and actual transfer time separately. Its actual pure Workbench composer/view predicate places these read-only source rows in Book with “Schedule first lesson” in the canonical market. This is data/composition evidence, not a browser or remote coverage claim. No lesson, reservation or context was fabricated. Four earlier synthetic-envelope control receipts and eight tasks remain unchanged and are not represented as this actual joint flow.

Financial controls and reporting

The real Revenue HTTP assessment and normal Sales service were exercised against eight separate controlled Sales correlations, using owner-existing financial-case Orders without modifying Revenue rows or reassigning the primary invoice. Partial payment deferred as not_fully_paid; unresolved cancellation as cancellation_pending; pending/full refunds as refunded; uncertain historical payment time as payment_time_missing; missing scope and zero-price settlement as revenue_unavailable. Confirmed invoice-less cash was eligible in preview only. All eight retain active onboarding queue membership and an open invoice task, with zero handoff events, receipts or stage history. The primary Lead, invoice, tasks, history and receipt compare unchanged before/after these controls.

Platform ran the actual history-backed reporting query before and after replay. It returns one primary conversion and zero for all eight controls, with unchanged immutable history/event IDs and decision timestamps. The stage transition timestamp equals history changed_at. The specialized event does not create a second conversion. Reporting consumers should retain this source-backed predicate and preserve historical Locked outcomes.

Validation and retained evidence

Sales full integration passed 1,679 tests across 138 files, with 15 opt-in database tests skipped in the ordinary run. Eleven real Prisma/Postgres payment/admission races passed separately in fresh database sales_handoff_race_893428d5091c48c39f8023aede453605, with a synthetic Revenue seam. These retain both cancellation/admission winner orderings, duplicate retries, unresolved producer/rebooking operations and historical terminal records. They are not cross-domain producer race proof. Six real serialization aborts are Prisma P2010 with underlying PostgreSQL 40001.

The subsequent exact-tenant hardening passed 201 tests in four affected suites and application typecheck. The full suite was not rerun after that focused change. Rehearsal harness typecheck, event-registry validation and diff checks pass. Cadence drift in the isolated joint database is empty. Readiness exits 0 with expected isolated-environment warnings, not a production readiness claim. The vocabulary rollback proof preserves custom labels and historical Locked records with zero committed proof rows. The final documentation-only change received diff validation without another behavior test run.

Retained local evidence:

• Sales integration checkout: .cache/adr0049-sales-primary.json, .cache/adr0049-primary-integrity.json, .cache/adr0049-negative-fixtures.json, .cache/adr0049-negative-proof.json, .cache/adr0049-sales-install.json, .cache/adr0049-vocabulary-proof.json.
• Revenue: docs/payment-handoff-http-proof-20260929.json, 21 authenticated route controls after the final issuer restart.
• Platform: .tmp/adr0049-transport-evt_01a0ef1b-5507-7ddb-91fa-1c9bcb198dd1.json and .tmp/adr0049-reporting-positive-and-controls-after.json.
• Delivery: .worktrees/adr0049/.tmp/adr0049-payment-handoff/2026-09-29T21-44-19.901Z-primary-after-a034e2f1-50c9-44bb-969f-6514cb99b735.json.
• Sales implementation and reproduction details: docs/payment-handoff-rollout.md at local commit 91c1a25f7df869afda0ead5ae380b7ff8f6e7457.

The live ledger was checked on September 29. The root Sales implementation commitment is already completed. Activation/reconciliation remains conditional on paid-invoice-handoff-ready, which remains uncleared. Consumer deployment, compatibility controls, remaining readiness review and exact existing-client preview/apply retain their separate gates. No production flag, customer communication or existing-client transfer occurred.

References

• ADR-0049
• Root request and readiness gate
• Earlier bounded Sales admission proof
• Accepted architecture, readiness remains gated