Sales paid handoff release source and reconciliation boundary
Sales has a clean, locally committed integration candidate at 6f910a29a276bfe4b8d4b2c30540d9df7c944f94, branch codex/payment-handoff-integration, checkout C:/Users/jallr/Documents/Sguild/repos/sales/.cache/payment-handoff-integration. The rollout and exact preview/apply plan is in docs/payment-handoff-rollout.md. No Sales source was pushed or deployed. This memo does not clear paid-invoice-handoff-ready or authorize production preview, apply, routing or customer communication.
Source preservation and ADR-0048 compatibility
The candidate retains the complete paid-handoff implementation and ADR-0048 baseline 4c5cf5d, plus the subsequent exact-tenant hardening. It now incorporates existing user changes 2e5138b, 2922d5a and 5987b1b: follow-up due sorts above cadence due, and same-day date-only calls/texts are due immediately. The invoice prompt installer, script repository and three-step outreach SQL match the primary workspace at review. Existing SMS copy-button behavior remains present. No message copy or recorded communication was rewritten.
The primary Sales workspace remains dirty on 82d9f80 and was not edited, staged, reset or overlaid. Its unrelated scheduling-note, geography, navigation and other changes require deliberate final source integration; this candidate must not silently replace them. ADR-0048 candidate 4b477fe differs from the integrated baseline only in proof documentation. The ADR-0048 owner reported its active response-loss work is proof tooling only, without a runtime guard change at this checkpoint. Compare its final candidate before release and incorporate any required runtime correction through that owner.
The consolidated joint proof, published as 6f2ae6a9d8d02cd17351a633c62dc68f56bbf898, replaces the earlier pending local context/lock/overlap notes. It establishes both context arrival orders, genuine later-lock enrichment, duplicate delivery and bounded Revenue PostgreSQL overlap with the documented provider seam. These controls retain their distinct synthetic-envelope and real-writer boundaries. Broader ADR-0048 response-loss acceptance remains separately owned.
Automatic reconciliation is separately disabled
Runtime commit 57563308f456191070e02bd4175ff46d00e13870 adds Sales-only SALES_PAYMENT_HANDOFF_RECONCILIATION_ENABLED, default false, to the authenticated scheduled payment-reconciliation route. When the master handoff flag is true and this flag is not exactly true, the route returns skipped=payment_handoff_reconciliation_disabled without scanning, cursor writes or legacy repair. No shared event/API contract changes.
| Master handoff flag | Automatic reconciliation flag | Result |
|---|---|---|
| false | false or true | Payment handoff/manual apply disabled; legacy reconciliation keeps its existing behavior |
| true | false or absent | Individual payment events, explicit repairs and exact saved-plan apply work; automatic backfill skips |
| true | true | Automatic paged missed-event reconciliation also runs |
The manual service and exact-plan semantics are unchanged. This separates enabling new transfers from automatically scanning existing clients. Disabling automatic reconciliation is the first rollback step; disable the master flag too when new payment-based transfers must stop. Preserve successful receipts, ownership, tasks, outbox and message suppression. Sales flags cannot recall committed events or pause Platform's existing fanout. Later refunds/cancellations remain Delivery and Revenue responsibilities.
Normal startup and final build evidence
Installed @sguild/dispatcher 2.0.1 lacks the event in its bundled registry. Normal instrumentation.ts register() calls the standard instrumentation.node.ts bootstrap, which loads the local Sales registry before SDK access. No proof-only registry override is required. The checked release artifact must contain this registry and lib/dispatcher/contracts/lead-lifecycle/schema/payloads/lead.handoff.completed-v1.json; an arbitrary override or old package fallback is insufficient.
The final direct Next build passed under declared-major runtime Node 20.20.0, build ID gbWsmuE_Grk-V_rlTh8hg, on helper/source checkpoint 8471c2f8a41ceecfa236ca880a690b751d31552a. Both the dispatcher inbox and payment-reconciliation route .nft.json traces include the exact local registry and payload schema. A fresh Node 20 process then invoked compiled .next/server/instrumentation.js register() without a registry override, recognized the event, and rejected an empty payload with the actual SDK PayloadValidationError before database access. Source instrumentation passed the same check. There was no custom registry loader, valid publish or synthetic transaction writer in this verification.
The Node 20 binary was obtained through version-pinned npm runtime installation under the checkout's ignored .cache/node20-runtime. No global runtime, package manifest or lockfile changed. Builds used unreachable loopback database URLs, absent .env files, and false Sales/fanout/external-action flags. Direct Next invocation bypassed the project's mutation-capable migration and onboarding-prompt hooks. This proves local compilation, lint, types and packaging, not deployed database/auth or migration acceptance. A prior Node 24 build also passed, but it is not used as Node 20 evidence.
The first two failed build logs remain: inherited parent ESLint configuration and two proof-script NODE_ENV typing issues. Fixes set project-local lint/tracing roots and correct types without disabling rules, typechecking or runtime guards. The final helper is scripts/local-dev/verify-payment-handoff-startup.ts, with --built for compiled startup and artifact trace assertions.
Validation is deliberately separated:
- Full preserved-follow-up integration: 1,686 tests passed in 138 files, 15 opt-in skips; application typecheck passed.
- Subsequent reconciliation gate: 125 focused tests passed, including six new flag/auth tests.
- Node 20 affected suites: 260 tests passed in six files, zero skips.
- Node 20 direct Next build, source/compiled startup, artifact traces, local read-only readiness smoke and cadence drift passed. Readiness retains expected stopped-service/default warnings and skips write/auth/identity probes.
- A broad raw
tsc -p tsconfig.jsondiagnostic still reports existing test-fixture typing errors. It is not a passing check; no non-test errors remained in that diagnostic after the proof typing fixes. The official application check and final Next build pass. Unrelated test fixtures were not rewritten.
Evidence in the integration checkout: .cache/adr0049-release-build-node20.log, .cache/adr0049-normal-startup.json, .cache/adr0049-built-startup.json, .cache/adr0049-node20-tests.json, .cache/release-integration-tests.json, .cache/adr0049-release-readiness-node20.log, and the retained failed build/type logs. Final documentation-only changes received diff validation.
Concrete release and existing-client boundary
The plan requires pinned clean domain candidates, reviewed complete migration inventories, final ADR-0048 compatibility, actual deployed Revenue auth/assessment and Delivery consumer readiness before routing. Delivery's disabled release-source candidate is acknowledged as a later source checkpoint, not a deployment. Revenue integration remains owned by Revenue.
Platform must inventory exact outbox/cursor/dedup/DLQ and master fanout before its runner deployment. The event registry entry is active with no per-event switch, so updated routing may drain backlog immediately while Sales publication is false. Require ready Delivery consumption and an accepted backlog disposition first. Do not reset or delete transport state.
Later authorized production preview must page to completion, retain exact tenant/Lead/Order plans and hashes, and include a read-only sidecar of current invoice, Person, organization, market, cancellation/terminal state and Revenue provenance. Count eligible, deferred and failed categories explicitly. CLI candidate IDs alone are not the full financial evidence. No production preview or population count has been performed here.
Revenue settlement-provenance recording is gated by REVENUE_PAYMENT_HANDOFF_ENABLED. Historical paid status or paidAt alone cannot prove full settlement; assessment reads must not repair history. Unknown provenance remains deferred for Revenue-owned evidence review. Do not backfill timestamps from Sales audits, replay a financial writer, or promise every already-paid client is eligible.
After separately accepted readiness and exact plans, enable the master Sales flag while automatic reconciliation remains false. Apply reviewed batches through scripts/payment-handoffs.ts --apply --plan ..., which rechecks current authoritative evidence, then verify exact Delivery customer/ownership/preparation records. The status command supplies transport evidence only. Enable automatic reconciliation separately after population review. Source, preview, deployment and readiness gates remain distinct.
The live ledger was inspected: the Sales local implementation commitment is already completed; activation/reconciliation remains conditional with paid-invoice-handoff-ready uncleared. No gate or commitment status changes are made by this memo.