Sales held recovery evidence and unresolved no-order provenance

Prepared owner checkpoint for root publication only. This file is not published and does not close the full ADR-0050 runtime or activation milestone. Assignment: ADR-0050/sales/001. Coordinator: 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local. No new business commands were executed for this documentation pass.

Source and execution boundary

Sales joint source is 79a3951d94b22111301913a16e7a5f27f111749f. Revenue joint source is 5f10755c031897b6598a051f915c6864ee0901e1. Delivery initial attempt used 28bc89393602d6e77f102d4949f302dbdf9db656; same-ID recovery and the remaining cases used 75589fa499b3c62ef94ef5702d5470c4781a1059. Delivery v2 manifest SHA-256 is 07fc105801ac852cf10db93997e10c7ecb026b2f71e5ef28b9f6b9ea3bb99593. The local Platform signer was port 3580, with refreshed public JWKS hash fbd1bfff81988b5507ad0bb5099dfad893a9effd28ff2484ffe8efbf8ef13bb0. Delivery and Revenue listeners were ports 3487 and 3587.

Revenue final code 120339c6 was not used in the joint rehearsal. Its final-source acceptance is separate. The Sales soft-capture candidate d31ddf1a4bd233c3d4e2714350452de8b7cbc878 was not the held-flow runtime; soft-create/bind execution remains gated on accepted ADR-0052 design.

All domain handlers, journals and outboxes in this evidence ran against isolated local fixture databases. Invoice provider behavior used Revenue's strictly local in-process double. There is no external-provider, production identity, shared-mesh, deployment or production activation claim.

Persisted effects after the three valid flows

Read-only verification at 2026-10-03T00:05:02.184Z found the following results. These counts describe each subsequent authorized cancellation flow, not the wrong-person denied preview.

Each Revenue reservation is RELEASED at closure revision 1. Each Delivery lesson is Canceled at outcome version 1; its lock is released at version 2. Each Sales lead is terminal/lost. Each fixture has one aborted Delivery predecessor and one completed child. Replaying Sales completion left one stage-history row per lead. Revenue has six persisted closure-operation rows and six dispatcher events across the three fixtures, three invoice operations/events and three release operations/events. Delivery has six operation rows and three cancellation outbox events. Revenue credit_ledger_entries, refunds, revenue_recognitions, external_actions and payment_handoff_settlements each have zero rows in the inspected fixture database.

The Delivery whole-schema comparison against http-baseline.json covers 57 tables: 48 hashes are unchanged. Changes are confined to lesson, reservation_lock, dispatcher_event and six closure journal/lineage tables. This is a complete Delivery baseline comparison. There is no complete pre-recovery Revenue table-count baseline; current persisted counts must not be described as that comparison. Counts and recorded calls do not prove the absence of unrecorded network attempts.

Wrong-person denial, separate from valid cancellation

The harness sent GET /api/v1/delivery/v1/onboarding-closure-reevaluations/a541a588-8a77-454b-8d91-ca8f8d63b2fc/preview with the fixture's exact organization, closure and lesson but wrong person per_01a0fe9f-d403-712f-8468-eccf62a8354d. Delivery returned HTTP 404 with protocol_version 1.1 and error code not_found. The harness then made a separate correctly bound preview and executed the valid cancellation.

No producer database snapshot was taken immediately before and after the denied GET. The record proves denial and that no mutation command was sent by that harness for the wrong-person identity. It does not independently prove zero database effects from the denied request. The final one-per-fixture cancellation counts belong to the later valid flow and cannot be attributed to the denial. No rerun was performed solely to strengthen this documentation claim.

Response loss and same-key recovery

For held_response_loss the transport wrapper awaited the actual Delivery child POST response, recorded its HTTP 200 completed envelope, then threw before returning that envelope to the Sales worker. The boundary is Delivery HTTP response to Sales application consumption. It is a deliberate local discarded response, not a provider-network failure or a process-kill experiment.

Sales remained pending with its prepared child command saved. Retry performed a GET of the same child, received completed, rechecked linked obligations and completed Lost. Deep equality of the afterLoss and after task snapshots confirms the saved child's operation ID, fingerprint, path and full body are identical. No replacement child or release key was allocated for retry. The recorded transport trace contains one successful child POST and subsequent reads; this statement is limited to the recorded trace.

For held_invoice_positive the earlier actual HTTP 500 followed a missing Delivery launcher tenant configuration: Revenue had already committed its release while Delivery's local finalization rolled back and Sales remained pending. The corrected launcher recovered using the same saved child and release IDs. Sales' same-id-recovery-verification.json proves canonical receipt equality with the pre-recovery saved Revenue receipt and the original financial event. Revenue independently confirmed that positive fixture's original receipt/event equality, RELEASED revision 1, one release event plus one order event, zero ledger rows and zero external actions. This owner confirmation is recorded as reported by the coordinator, not a new final-source rehearsal.

Exact operation and event identities

held_invoice_positive

Lead: lead_01a0fe9f-d2f9-735e-bed5-e502c3fce797. Closure: ocl_c5a01a98-0e2b-45fb-b42e-b493721c5a69.

• invoice: 563389d0-3015-419f-9e72-1502b761ff84

• deliveryPredecessor: 5bd98a36-7545-4b04-90eb-dab717b1dd70

• deliveryChild: 2d3723e7-a606-40ed-a15f-72188b934780

• revenueRelease: 7db89e5d-1123-4250-9b65-a2e76229321c

• invoice event: evt_01a0fea3-616d-7aca-bf47-e5c74ee3ba23

• release event: evt_01a0feac-4273-7a4e-92fe-12af6854593f

• delivery event: evt_01a0ff0f-d361-7652-9ee3-d8969f2340f5

• sales event: evt_01a0ff0f-dd69-7d64-b67c-0936d342af30

held_response_loss

Lead: lead_01a0fe9f-d3df-74a4-a3b9-250e9d7f9365. Closure: ocl_adb4173e-7814-4044-8267-bae1951a6404.

• invoice: b94b011a-b235-45b5-b187-77de6b628e96

• deliveryPredecessor: 108467ba-1d84-4459-bcde-e71a4c887491

• deliveryChild: 06faca9f-821e-4bee-a15a-e6a8a78c696b

• revenueRelease: 3e5e149b-f09d-414d-9b55-76cb8eb6d5c8

• invoice event: evt_01a0fea3-62cf-7ba6-8d38-5c72694e9a4e

• release event: evt_01a0ff11-3f4e-711a-9c18-9bf3cd39011b

• delivery event: evt_01a0ff11-400b-73f4-b4ab-7dbed13c3a0a

• sales event: evt_01a0ff11-4546-7161-b8e1-a319778d567c

held_wrong_binding

Lead: lead_01a0fe9f-d403-712f-8468-cd31dde34b73. Closure: ocl_93182b95-389b-4451-bdb7-3114a6374b77.

• invoice: ef44e222-8463-4578-a184-7dad1b063ab4

• deliveryPredecessor: a541a588-8a77-454b-8d91-ca8f8d63b2fc

• deliveryChild: eb8065b4-50f2-4f44-bc15-4c8757791425

• revenueRelease: f143871c-97c4-4252-af2f-91e220ee2405

• invoice event: evt_01a0fea3-63ab-7ad0-993c-2ded96002efe

• release event: evt_01a0ff11-0504-7300-9e5e-a5e9a4a38139

• delivery event: evt_01a0ff11-0638-7560-8f47-4b76c4290379

• sales event: evt_01a0ff11-0a88-7964-81fd-47ad4763b15e

Response to Revenue's no-order provenance request

Sales reviewed the published request at coordination commit 6f676452. The existing Sales-owned linkage is LeadLessonBooking in prisma/schema.prisma, with tenantId, leadId, organizationId, personId, lessonId, creditReservationId and reservationLockId. recordLeadLessonBooking in modules/lead-lesson-bookings/repo.ts upserts by tenantId/lessonId and can update leadId, personId, organizationId and reservation linkage. It is therefore a mutable Sales query/recovery projection, not immutable producer admission provenance.

loadClosureSnapshot in modules/onboarding-closure/repo.ts:46 reads bookings by tenant and selected lead. At lines 73-88 it deduplicates reservation IDs and blocks missing, conflicting, cross-lead or person-mismatched linkage. Invoice candidates use explicit LeadOrderCorrelation and onboarding-payment task history, with shared/unknown ownership blocked. An internal lead booking projection can identify a Sales candidate but does not establish Revenue-authoritative ownership of a no-order reservation.

The reviewed Sales source supplies tenant-scoped internal booking reads and operator closure routes; no existing immutable, service-authenticated reservation-to-lead provenance interface was identified in this path. No new endpoint, capability, admission field or Order is proposed or implemented by this checkpoint. The existing scalar IDs above are known identifiers, not a claim that their historical association is immutable. Person, account or lesson matches alone are insufficient.

Consequently the no-order path remains denied/unresolved. Sales retains Closure pending, pauses outreach and blocks new obligations until authoritative obligations clear. A future accepted cross-domain design must establish who owns and admits the immutable association, its exact identifiers, service authorization scope, and absent/contradictory-link behavior. This checkpoint does not settle that design. Revenue continues to own financial eligibility and reservation truth, Delivery owns lesson/hold truth, and Sales owns its lead and closure intent. No synthetic Order was added to the original no-order fixture; it remains an unexecuted provenance-gap fixture, not a positive cancellation test.

Evidence location and publication limits

Local Sales checkout: C:/Users/jallr/Documents/Sguild/repos/sales/.cache/onboarding-reevaluation. Evidence directory: .tmp/adr0050_rehearsal_cdd447836e3a48b3b607bc176da4e3c0. These are local evidence references, not durable published artifacts. The publisher should preserve or package them before claiming a remotely reproducible bundle.

• verified-all-three.json, SHA-256 9246f114b77da3ed73242e5f2726cf65126d20950cc33fc444e389745107b76d.
• producer-effects-readonly.json, SHA-256 8b052e548068c634dab76fe2815dce2f737a019a15f0a4c7fc35751d4f95ed02.
• joint-composed-evidence.json, SHA-256 30992b78b2778888296d1e62eb5f973b22e0941df07608ed529c2fc48363f0ad.
• same-id-recovery-verification.json, SHA-256 a83267873abb1e5fcda7d9a9b5a807e974501de59a9a36dc48e08b9707d3b813.

verified-all-three.json includes the exact persisted invoice, Delivery child and Revenue release request bodies and all operation/event identities. joint-composed-evidence.json additionally includes actual wire requests, idempotency keys and responses. Revenue's internal invoice request includes operation_kind, while its v1 wire body excludes that internal field; the harness checked the published fingerprint before use. Original and derived forms are both retained. Other substantive request fields were preserved.

The saved fixture setup aligned the placeholder Sales closure actor/reason with the actual immutable invoice-root actor/reason before any Sales command. That separately authorized setup and before/after values are retained. The distinct original Delivery root request was not rewritten. Historical HTTP 500 evidence is retained even though the final valid flows completed.

This documentation pass compared existing evidence and inspected source only. No new mutation rehearsal, fixture reset, producer code change, coordination publication or production action occurred. Root remains sole publisher. Full ADR-0050 acceptance, final-source composed verification, no-order provenance and ADR-0052-gated soft-create/bind work remain separate outstanding matters.