ADR-0049 source integration and staged release prerequisites

The operator resumed work after the isolated joint proof. This increment prepares reviewable source and separates deployment prerequisites from runtime activation. It does not clear paid-invoice-handoff-ready, authorize production migration or deployment, or apply existing-client reconciliation.

Local source checkpoints

Platform's existing 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a contains the event mirror and reporting implementation. The committed ConsumerLoop, DLQ, signature and registry source match the exercised proof. Existing uncommitted fanout changes add separate local remote-target/redirect guards and remain outside the candidate. The exact-event proof independently fixed its target and disabled redirects. Its result is not evidence that every production guard or deployed source matches the local checkout.

The coordinator extracted the exact Platform commit without changing application files and checked the committed source with inert loopback database URLs and disabled runners. The unit run passed 366 of 367 cases; the only failure was the mirror test's literal CRLF/LF comparison with the copied canonical fixture. After confirming normalized contents were identical and normalizing only that expected fixture, all four tests in the affected file passed. Typecheck, module guardrails and warehouse structure validation passed. Initial missing-sibling and line-ending failures remain in the logs. These 367 committed-source cases differ from the earlier 370-case dirty-worktree run. Database integration was not rerun for this source-only review. Evidence: Platform .tmp/adr0049-clean-source-verification.json and .tmp/adr0049-release-source-review.json.

Delivery local commit 5624d7b66574de346bf2b37cf31be85ff62a89ae removes the unconditional production-environment veto and exact rehearsal database address from runtime. Runtime still requires explicit opt-in, canonical organization, configured PostgreSQL URLs and compatible generated schema mappings. Exact allocation guards remain in proof-only helpers and launchers. No actual environment flag or deployed process changed. Validation passed 882 tests, with 15 skips, eight audit mappings, typecheck, smoke and the static guardrail. See the Delivery source-readiness memo. Rollback disables new ingestion while retaining receipts, ownership, preparation tasks and history.

Sales runtime 57563308f456191070e02bd4175ff46d00e13870, startup helper 8471c2f8a41ceecfa236ca880a690b751d31552a, and release-plan checkpoint 6f910a29a276bfe4b8d4b2c30540d9df7c944f94 preserve the three later user follow-up commits. The full integration passed 1,686 tests with 15 opt-in skips. The subsequent default-false SALES_PAYMENT_HANDOFF_RECONCILIATION_ENABLED cron gate passed 125 focused cases, including six new authorization/flag tests; six affected suites passed 260 cases under Node 20.20.0. With the master handoff flag enabled, an unset or false reconciliation flag prevents scheduled backfill while individual payment/repair and reviewed exact-plan apply retain their normal semantics. Existing legacy reconciliation remains unchanged when handoff is disabled.

The direct Sales Next build passed under Node 20.20.0 with inert database URLs and all handoff/fanout/action flags false. Normal source and compiled instrumentation startup recognized the event and rejected an invalid payload through the installed SDK without a custom registry override. Actual inbox and reconciliation route traces contain both contract files. Migration and prompt-install build hooks were bypassed, so this is compilation, typecheck and artifact evidence only. Failed earlier builds and a broad test-inclusive TypeScript diagnostic remain documented separately. No dependency lockfile or global Node version changed. The dirty Sales primary checkout and unrelated uncommitted changes still require deliberate final integration review; it must not be overlaid or treated as this candidate. See the Sales release-source memo.

Revenue committed the coherent shared ADR-0048/0049 source as d404d2c0ae5f2ac80b6a7276aa14f6bb3e9d5072 on codex/guarded-handoff-integration in C:/Users/jallr/.codex/worktrees/revenue-guarded-handoff-integration/revenue. The clean tracked worktree contains 43 scoped files and preserves unrelated lesson-recognition work in the original checkout. All fourteen published assessment-source hashes and five pinned closure hashes matched before integration. Both actual feature migrations ran after the baseline in a fresh isolated database; seven row guards, fourteen closure serializers, twenty-one assessment serializers and twenty-one revision triggers were verified with a private fifty-model client.

Revenue verification is deliberately reported in separate runs: the integrated full suite passed 606 cases and failed five ten-second setup hooks across 77 files and 611 cases; no behavior assertion failed. After resource contention subsided, all 41 cases in the two affected suites passed with unchanged timeouts and unchanged application source. An intervening interrupted full retry is retained and is not a pass. Typecheck, eight-family dispatcher smoke and diff checks passed. The post-test ledger audit saw zero rows and zero violations, which is not production or populated-ledger reconciliation. The earlier populated local joint proof remains separate evidence. See the Revenue source-integration memo.

Deployment has effects before producer enablement

The single Render runner imports Platform source directly. A new dispatcher npm release is not intrinsically required for that runner. Sales uses its normal startup registry override and traced local contract files; installed package version alone cannot establish payload availability. Its actual build and normal initialization must verify those files, independently of rehearsal-only overrides.

The Platform registry addition is active and has no per-event off switch. If the existing master fanout switch is already enabled, deploying the new runner source can immediately route matching rows. An absent cursor starts at zero. SALES_PAYMENT_HANDOFF_ENABLED=false stops new publication but cannot suppress previously persisted events. Never reset a cursor, delete history or fabricate a starting point to make rollout appear safe.

Read-only inventory at 2026-09-29T22:23:46.637Z used Platform's configured remote Sales producer database and fully qualified Sales tables. It found zero lead.handoff.completed rows, no matching Delivery cursor, zero computed backlog and zero matching unresolved dead letters. This connection's equivalence to the live Render runner is unverified. Current Render deployed source, producer DSN and master fanout setting were unavailable through the existing authenticated tools. The result is a scoped database observation, not a live runner certification. Evidence: Platform .tmp/adr0049-live-release-inventory.json.

Revenue's flags do not make every shared change inert. Installing the migrations activates source serialization and revision triggers, and shared payment/idempotency and tenant behavior can affect existing writers even with endpoints disabled. Review migration order, actual deployed schema history, existing writer compatibility and serialization throughput before any production change. Feature migrations must install their SQL guards; a schema-only push is insufficient. No historical settlement provenance is inferred by migration or assessment reads.

Concrete staged release boundary

1. Review and select exact source checkpoints, including shared ADR-0048 dependencies and preserved later Sales changes. Confirm production schema history, generated clients, configuration and migrations against each owner's checklist. Current local test databases do not establish production migration compatibility.
2. Obtain release authorization for concrete deployments and migration effects. Verify live Render source, master switch, intended Sales producer connection, routing destination and consumer readiness, then repeat the exact backlog/cursor/dead-letter inventory immediately before runner deployment.
3. Deploy and validate Revenue assessment and Delivery ingestion before enabling Sales publication. Confirm actual scoped authorization and disabled behavior on the intended environments. Revenue provenance collection and the new consumer's readiness require their own explicit configuration decisions.
4. Deploy the registry/reporting source only after its immediate routing implications are understood and Delivery can consume existing and new matching events. Verify durable delivery and actual domain records, not just HTTP acknowledgment.
5. Sales may clear its readiness decision only after the remaining deployed prerequisites are satisfied. Enable new handoffs separately from automatic reconciliation. Preserve independent controls for exact reviewed apply and broad scheduled scans.
6. Preview existing clients without mutation, retaining exact scope and invoice selection. Apply only reviewed, still-eligible candidates through the same service with fresh assessment and local transactional revalidation. Partial/refunded/unresolved or ambiguous historical evidence remains deferred. Old paidAt alone is insufficient, and no promise is made that all already-paid clients qualify.

Disabling new production handoffs is a forward stop. It does not retract ownership, reopen terminal Sales Leads, delete tasks or receipts, or rewrite financial and dispatcher history. Monitor transport failures alongside Delivery ownership and preparation outcomes. Existing domain responsibilities and financial first-lock semantics remain unchanged.

Publication and remaining work

The September 29 live ledger confirms the scoped Sales, Revenue, Delivery and Platform local implementation commitments completed. Sales activation/reconciliation remains conditional on its uncleared readiness decision. Revenue source integration published as 01531843ef9db165c1f3217793329bf449a829be, Sales source readiness as f3caac8be2d18bb668ed6e6f52d29f22775d7f91, and Delivery source readiness as 023eb54cfac7f72280c7fc781bb0d60696647337. These coordination publications are distinct from the local application commits. No application source was pushed or deployed during this increment. Prior ADR-0049 proof listeners remain stopped and its databases retained. The separate ADR-0048 recovery coordinator owns fresh fixtures and runtime copies; this source work does not modify their pinned source or proof history.