Bounded repair of two paid invoice handoffs
Sales reported two current invoices settled after the original release inventory that remain in onboarded/awaiting_payment. The operator instructed Sales to repair them and explicitly approved coordination with the existing ADR-0049 domain owners. The completed October 2 activation record remains historical evidence; this is a new bounded repair, not a reversal of that milestone.
Platform coordinates the repair in chat 01a0e0a8-093e-7d80-b8ef-5997067ae039, host local. Sales chat 01a10df6-1702-7822-95f6-a4df79f4940a owns Sales source, release and the exact two-candidate recovery. The private allowlist and reported financial facts are retained at C:/Users/jallr/Documents/Sguild/repos/platform/.tmp/adr0049-paid-handoff-repair-20261005/cases.private.json. Reported facts require Revenue confirmation; the public memo carries no customer contact data.
Owning-domain requests
Revenue assignment ADR-0049/revenue/paid-invoice-repair-20261005 must diagnose the actual assessment for both selected current invoices against the serving source. Confirm full-settlement event provenance and exact Person, Client, organization and market scope. One reported replacement order and its settlement have no reservation linkage. Its original booking reservation is a candidate relationship to investigate, not authority to reassign financial ownership. The other assessment failure is initially unconfirmed. Propose a correction only from established source evidence and the accepted contract, with affected positive, negative and concurrency checks and a concrete recovery plan before a production change. A read must not repair evidence or infer missing scope from an unrelated account.
Delivery assignment ADR-0049/delivery/paid-invoice-verification-20261005 must first inspect existing customer, ownership, booking and preparation facts read-only. After Sales publishes each real handoff through its normal guarded service, verify the exact event, durable receipt, correct existing customer, payment ownership, curated context and recoverable preparation. Preserve first-lock facts and prove that retries cannot duplicate preparation. An HTTP acknowledgment alone is insufficient.
Sales is preparing an isolated release from its observed serving source with sanitized assessment errors and recovery restricted to the exact two-candidate plan. Preview is read-only by default; apply must retain fresh Revenue assessment, current invoice selection, Lead version, scope, cancellation fences and transactional history/outbox checks. The separate broad scheduled reconciliation flag remains disabled. No terminal Lead is reopened, no synthetic payment or settlement time is introduced, and no customer communication is included.
Assignment and release boundaries
The legacy Revenue and Delivery participants received an explicit bounded return to ADR-0049. Their held ADR-0050 assignments, databases, listeners and evidence must be preserved, with an explicit handback after this repair. The ADR-0050 coordinator was notified. Any currently exclusive rehearsal conflicts must be reported before repair work begins. Different ADRs retain their own milestones and release ownership.
The request alone did not establish a production repair or release. The verified outcome below establishes the bounded repair. Any required new cross-domain design follows the ADR approval process rather than weakening the accepted assessment contract.
Verified repair outcome
Both current invoices were recovered through the ordinary guarded Sales handoff on October 5. Revenue source 18e94812cecd3840ee9adca9295b8465f82995a9, based on serving 14090538972f5dea9ae6dfdc05d9f94328afd3a5, is canonical and READY in deployment dpl_6UvjrDq562tTpAwpdhZrgPM4TGDX. It recognizes only an inbound payment audit that exactly matches an already committed settlement and proves reservationless credit-drawer scope through the exact creation event, complete unreversed purchase ledger, and one correctly scoped account. Unrelated actions, refunds, cancellation operations and fences remain blocking. No reservation, payment timestamp, ledger or historical audit status was rewritten.
Revenue passed 646 tests across 77 files, including 60 focused assessment checks and ledger/reversal commit and rollback races, plus typecheck. Candidate reads of both real records used server-enforced read-only connections with identical before and after snapshots. All 809 uploaded source files matched the clean export, including downloaded byte comparison; no private paths entered the upload. The build and promotion were migration-free. Assessment remains enabled; closure and provider execution remain disabled. Revenue response and reviewed source PR retain its owned evidence and rollback plan.
Sales used current deployment dpl_4Uv4aLESupHeyTx6frcjhxF7YAnC, source 2cb35d3baed358cd6b2493db8d9fa4565ec2f833, after fresh authenticated assessments reported both exact candidates eligible. Concurrent cadence and Scheduling UI releases were preserved. The final change from the reviewed combined baseline affected only Scheduling UI and its test; recovery runtime was unchanged. The uploaded archive matched its content-addressed SHA1 and all 895 source files matched the publisher source. The existing temporary recovery credential retained its exact two-candidate scope and expiry. No additional promotion was needed for recovery.
Sales persisted exactly two invoice-paid receipts, two stage-history entries and two real lead.handoff.completed events. Both Leads are terminal/handed_off, their threads are closed, and their pending Sales tasks, actions, enrollments, callbacks and queued touches are zero. Original full-settlement timestamps remain October 3 at 08:07:21Z and 17:14:18Z. Actual handoff timestamps are October 5 at 22:09:51.133Z and 22:09:51.960Z. Earlier five-hour discrepancies were diagnostic parsing artifacts, not financial-record changes. Repeating the same exact plan returned already_applied with the same event IDs, and complete after/retry snapshots were identical.
Delivery's final read-only semantic proof is semantic-verification.json, SHA256 a3f5774afcf166d5dce3e54b477edddbb5e0c245b5e8df8c66a2d7b54071c716, under its private repair evidence directory. Platform read this exact artifact. Each event has one durable payment receipt and correct ownership record, attaches the curated Sales context to the existing customer, and has completed preparation with two tasks and one context note. Original customer, lesson and first-lock handoff facts are preserved. Subsequent Delivery snapshots after the Sales repeat are identical, with no duplicate preparation and no manufactured replay. The consumer source remains 5c36fd2021069d766b17f97032b4266c8d0b4f5a, unchanged in the relevant consumer files from the previously proved release. Transport acknowledgment was not used as semantic proof.
The exact two-customer repair is complete. Broad scheduled reconciliation remains disabled; no general historical replay or future retry-policy activation is claimed. No customer communication or ADR-0050 fixture operation was performed. Domain-owned commitment publication and the explicit legacy-owner handback accompany this evidence consolidation.