Platform acknowledges ADR-0049 and prepares disabled routing and history-backed reporting
Platform acknowledges ADR-0049's separate operational handoff and financial first-lock meanings, explicit invoice/organization/Person/market correlation, immutable receipt and disabled rollout. This is Platform's position only. Sales owns ADR acceptance, and Revenue and Delivery must supply their own acknowledgments and implementations. No ADR status or ownership clause is changed here.
Exact read authorization
Platform agrees that GET /api/v1/orders/{order_id}/payment-handoff-assessment?organization_id=...&person_id=...&platform_market_id=... fits the existing revenue.sales-operations workload capability, exact sub: sales, aud: revenue and revenue.orders.read. No new selector, audience, scope or service-auth implementation change is required. This is a bounded order read, not authorization for the existing Delivery-only sales-ordering status read or general financial access.
Revenue must verify the existing required JWT claims, canonical tenant and Organization reach, then reauthorize the requested Order against explicit organization, Person and Platform Market source rows. Tenant is not organization. A valid scope or caller-supplied identifier is insufficient. Wrong linkage yields a nondisclosing rejection; no Client/account creation or payment effect occurs. Return Cache-Control: no-store and coherent financial/operation revision, full-settlement time and unresolved-operation assessment under the proposed read contract. Revenue owns those implementation and negative authorization proofs. Platform's review does not assert that the endpoint is deployed or approved by Revenue.
Routing and schema
Local Platform commit 3b0ef9d in C:/Users/jallr/Documents/Sguild/repos/platform mirrors only the canonical lead.handoff.completed@1 registry entry and payload schema for this work. Producer is Sales, consumers are Delivery and platform-warehouse. Existing registry-driven fanout:delivery reads the Sales producer DSN and uses the configured Delivery inbox URL/secret. The warehouse consumer is synthetic, not another webhook worker. The single-runner topology remains intact.
SALES_PAYMENT_HANDOFF_ENABLED=false remains the producer gate. No live subscription, cursor, endpoint, secret, flag or historical event fanout was changed. Delivery's exact inbox binding and semantic receipt/customer/ownership/preparation proof remain contingent on Delivery's safe checkpoint after ADR-0048. Tests used a mocked loopback HTTP destination and checked the actual HMAC-signed envelope; they did not call Delivery. No SDK/npm package was published and no runtime code was pushed or deployed.
Analytics questions and implementation
How many Leads transferred in a period? How long from intake to handoff, and which intake cohort converted? Did later lock enrichment or specialized event retries add another conversion? The existing Sales handoff count, duration, source-class, entity and cohort queries now share the earliest non-null handoff-evidence history per tenant/Lead. No new warehouse face was introduced.
Sales confirmed that both successful and unsuccessful lead.stage.changed@1 transitions can carry to_stage=terminal; the payload has no substage or handoff evidence. Success therefore stays classified by immutable sales.lead_stage_history, not current Lead state or terminal/inbound-event inference. New history has to_substage=handed_off, handoff_evidence=invoice_paid. Historical non-null evidence remains eligible, including credit_locked, customer_handoff, late_paid_attended and sales_ordering_close.
Decision attribution uses Sales' confirmed physical changed_at, not row-insertion created_at; existing query field names retain a compatibility alias. Dedup runs before period filtering, and joins require both tenant and Lead. The specialized lead.handoff.completed event is evidence only and cannot create a second conversion. Historical rows without dispatcher events remain counted. No heuristic event/time join or new paid-wait metric is introduced. Existing first-lock metric aliases remain, and actual Revenue lock metrics are unchanged.
Changed Platform paths are lib/dispatcher/contracts/event-types-registry.json, its new lead-lifecycle/schema/payloads/lead.handoff.completed-v1.json, lib/dispatcher/payment-handoff.test.ts, lib/mart/sections/sales-handoff.ts, lib/mart/sections/sales.ts, lib/mart/registry.ts, generated contracts/mart/metrics.json, scripts/check-adr0049-handoff-reporting.ts and docs/dispatcher/adr0049-payment-handoff.md. Regenerating the metric manifest also reflects already-present Finance registry entries; no Finance computation changed. Unrelated local fanout/docs/scripts/skill changes remain outside this commit.
Verification and limitations
The full Vitest suite passed 370 tests across 50 files. New tests cover canonical mirror equality, nullable lesson references, missing scope identifiers and PII rejection, registry-driven HMAC transport and disabled fanout. Typecheck, module guardrails, warehouse dbt validation and diff checks passed. Warehouse validation is local structure validation, not deployed model availability.
Created a separate empty loopback database platform_adr0049_20260927 on 127.0.0.1:55434; applied the 30 Platform migrations only. Verified both database URLs, actual database/schema and the generated Platform client's database before fixture writes. All 32 identity and 3 geography scenarios passed. Those integration components and Vitest together cover the npm test suite without running against the shared environment. Fanout and external runners were false in the proof processes.
The reporting script executed the exact shared SQL against synthetic source tables in that dedicated database. Six eligible tenant/Lead rows survived from nine history rows; the later lock did not duplicate invoice-paid conversion; Lost/exhausted were excluded; historical ordering-close evidence remained; another tenant and a distinct repeat Lead stayed separate. September 26 contained three decisions despite October insertion timestamps. Adding broad/specialized/retried dispatcher events changed no conversion count. Transaction rollback removed the fixture schema/tables. This is real Postgres mapping proof, not Sales/Revenue/Delivery end-to-end behavior.
The local Platform deliverable is complete. Delivery endpoint/semantic acknowledgment, Revenue exact assessment, joint payment/cancellation races, consumer deployment and isolated end-to-end receipt/preparation evidence remain activation prerequisites. The Sales readiness event remains uncleared. No production, provider, financial or customer-message action occurred.