Exact paid-invoice handoff recovery and visible assessment failures
The operator authorized repair of two real paid current invoices on October 5 and explicitly authorized coordination with the existing ADR-0049 domain owners. This is an exact customer recovery, not historical payment replay or broad automatic reconciliation activation. Sales edits remain in Sales and sales-coordination; Revenue owns financial scope correction, and Delivery owns semantic receipt and preparation evidence.
Confirmed boundaries
The original live Sales deployment is dpl_f3vFNLaYaHX4zrWvX1WBa25jeg3w, source ff4d48037722d4327a6926cee354fd1624721268. Admission is enabled and broad reconciliation is disabled. Both current invoices have real full-payment settlement rows and Sales payment observations. Neither Lead has an invoice-paid handoff receipt. Both Sales bookings are funded and locked, but the existing profile filter hides locked bookings without completion evidence.
The first exact tuple is Lead lead_019e1e7f-bd95-7645-8fe8-3bc5fc83ee46, selected Order ord_01a0ff20-9646-71a3-877b-bf3573ea445c. Its original payment and settlement carry the existing reservation. Actual authenticated Sales production-workload preview returned cancellation_pending from Revenue's assessment. Sales local context checks pass. The specific source of Revenue's pending flag remains its owner's diagnosis.
The second exact tuple is Lead lead_01a0d4e4-54a1-734f-8dc5-ca2c6ee68332, selected Order ord_01a0ff32-47e9-78b4-9ceb-043aec92460c. Its paid Order and settlement have no reservation reference, while the original booked Order is different. Actual authenticated preview returned HTTP 503 with order_scope_unproven. No reservation reference was copied and no settlement timestamp was changed. Revenue must prove the paid Order's relationship through its canonical records before any correction or reassessment.
Sales repair
Source e31d48e preserves sanitized Revenue error codes, displays handoff_locked bookings, and adds a bounded authenticated exact-plan POST to the existing reconciliation endpoint. It defaults to read-only preview. Explicit apply uses the ordinary authoritative assessment, current selection, cancellation guards, Serializable Lead transaction and durable receipt. The existing GET broad-reconciliation hold is retained. A deployment-only recovery credential expires and is bound to the hash of the two exact reviewed candidate tuples; the shared cron credential is unchanged.
Validation: 242 affected tests, typecheck, and read-only readiness passed. The production build uses Prisma generation and Next build only, with no migration, seed, prompt installation or provider command. Staged upload verification caught private diagnostics included by the deployment packager despite Git ignore rules. The first staged deployment was removed, its generated alias restored, and its temporary credential rotated. Source 2401a5e adds explicit deployment exclusions before restaging. No canonical promotion or customer apply occurred in that first stage. Private evidence is retained in the managed Sales worktree .tmp/; no credentials are included in this memo.
Owning-domain requests
Revenue: identify the exact pending source for the first assessment and prove the relationship for the second Order. Propose only a bounded correction supported by current source records and the operator's repair authorization. Do not create another payment, infer scope from an unrelated account, or transplant an old reservation to make an assessment pass.
Delivery: verify actual customer, receipt, OrgMarket ownership and preparation records for each real Sales handoff event after application. Existing first-lock/customer evidence is separate from payment-transfer receipt evidence. Transport acknowledgment alone does not close the recovery commitment.
Platform coordinates the existing owners under the user's explicit messaging authorization. A future durable retry policy needs a concrete bounded proposal and positive and negative evidence; broad historical reconciliation stays disabled during this exact repair.
Verified recovery
Revenue confirmed the blockers: a committed payment's inbound audit row retained Pending status, and a paid credit-drawer Order without a reservation could not prove canonical scope through the existing assessment path. Reviewed Revenue source 18e94812cecd3840ee9adca9295b8465f82995a9 recognizes only an exact committed settlement audit and proves reservationless purchase scope through the committed purchase ledger and account. Unknown actions, refunds, cancellation fences, and unproven scope continue to defer. The owner reported 646 tests, including 60 focused checks, typecheck, and read-only live proof. Deployment dpl_6UvjrDq562tTpAwpdhZrgPM4TGDX is canonical READY. No historical audit status, settlement time, or reservation link was rewritten.
Sales recovery source was integrated with the concurrent onboarding follow-up reset in 813da77f16bf29bb6106fa53178271ca436b43e6, preserving 590 passing tests and typecheck. A later Scheduling UI release, 2cb35d3baed358cd6b2493db8d9fa4565ec2f833, retained the recovery credential. Its only source differences from the reviewed integrated release are the Scheduling handshake component and its test. The downloaded source archive SHA1 83bfe72d3bff788bfde9669b20cd595dff759fe9 matches the uploaded artifact; all 895 archived files match Git source (allowing text line endings), with only .gitignore omitted. Server, handoff, cancellation, authentication, dispatcher and build configuration are unchanged. At recovery, Sales deployment dpl_4Uv4aLESupHeyTx6frcjhxF7YAnC was canonical READY. An intervening recovery guard stopped before POST when that release advanced; no older deployment was applied or re-promoted.
Fresh authenticated preview through that current Sales workload returned both exact candidates eligible. Normal guarded apply completed both at approximately 2026-10-05T22:09:51Z. Each Lead is terminal/handed_off, its thread is closed, follow-up pointers are cleared, and all pending tasks, cadence actions, enrollments, callbacks and unsent cron touches are zero. Each has exactly one invoice-paid stage transition, one durable handoff receipt and one real outbox event:
- First tuple:
evt_01a10e1d-b98a-75a8-8057-fd503c35ec62, originalpaid_at2026-10-03T08:07:21.000Z, actualhanded_off_at2026-10-05T22:09:51.133Z. - Second tuple:
evt_01a10e1d-bbd0-7965-8e7b-bc970e6de8cf, originalpaid_at2026-10-03T17:14:18.000Z, actualhanded_off_at2026-10-05T22:09:51.960Z.
The identical exact plan was repeated through the same current deployment. Both results were already_applied with the original event IDs. Read-only Sales snapshots after apply and after repeat are deeply equal, proving no additional Lead, receipt, history, event or pending-queue mutations.
Delivery's owning semantic verification reports success, read-only evidence SHA256 a3f5774afcf166d5dce3e54b477edddbb5e0c245b5e8df8c66a2d7b54071c716, source 5c36fd2021069d766b17f97032b4266c8d0b4f5a. Sales independently read that artifact. Both exact producer events match Delivery's event mirror and durable inbox receipt. Each payment receipt and organization/market ownership row belongs to the correct existing customer. Sales context is attached with one communication-preference note. Repeat preparation is completed with exactly two deterministic tasks per customer. Original customer, lesson and first-lock records are preserved. Delivery's subsequent snapshot after the Sales repeat is identical, with no duplicate preparation or receipt. No synthetic downstream replay or customer communication was sent.
Private Sales evidence is in the managed repair worktree .tmp/, including sales-before.json, sales-after.json, sales-retry.json, exact-apply.json, exact-repeat.json and source verification artifacts. Delivery evidence is delivery/.tmp/adr0049-paid-handoff-repair-20261005/semantic-verification.json. The exact two-customer commitment is complete. Admission remains enabled, broad historical reconciliation remains disabled, and the deployment-only exact-plan credential expires at 2026-10-05T22:56:17.087Z. Future retry policy is a separate bounded design decision, not part of this completed recovery.