Revenue source integration is committed locally
Revenue committed d404d2c0ae5f2ac80b6a7276aa14f6bb3e9d5072 on local branch codex/guarded-handoff-integration, based on fecab1cc63c5ef46aad551b3bb4a438ff3606a21. The clean checkout is C:/Users/jallr/.codex/worktrees/revenue-guarded-handoff-integration/revenue. It contains 43 scoped files, with 3,757 insertions and 40 deletions. The source commit is local and has not been pushed, merged into main or deployed.
This integrates ADR-0048 and ADR-0049 together because assessment reads closure journals and fences and shares their writer serialization, authorization and actual dispatcher receipt dependencies. The boundary includes both complete modules/routes/migrations, SDK event ID and canonical tenant support, guarded invoice recreation, serialized payment writeback, full-settlement provenance and test isolation checks. The stale-date ordering test uses a new future interval. All fourteen published assessment checkpoint hashes and five pinned closure hashes matched before integration. Runtime source was copied unchanged; integration-specific changes are documentation and the ignored local evidence directory.
The original Revenue dirty tree remains intact. Unrelated lesson consumption, recognition reconciliation, recognition deferral and repair changes were excluded. Historical rehearsal artifacts, hardcoded fixture harnesses and credentials were not committed. Exact source and validation evidence lists every file hash, excluded dirty path, allocation and log hash.
Actual integrated verification
The integration used an independent dependency installation and generated fifty-model client. A fresh loopback database, revenue_integration_bcd1221d1c26463e8f6a0fdc2e307b71, hosts only its revenue_test schema. The base commit's schema established the baseline, then the actual closure migration and assessment migration were applied in order with only schema qualifiers changed. Both URLs, compiled schema and actual database were verified. All seven closure row guards, fourteen closure statement serializers, twenty-one assessment serializers and twenty-one revision triggers were enabled.
The full integrated suite ran 611 tests across 77 files: 606 passed, and five existing setup hooks exceeded their unchanged ten-second limit. The failures occurred during table-truncation setup in modules/credit-reservation/service.contract-compliance.test.ts and modules/sales-ordering-surface/service.pg.test.ts; no behavior assertion failed. After dependency installation completed, those two complete suites passed all 41 tests with the same timeout settings and no source changes. A full retry started before the coordinator requested the narrower rerun was stopped and is not counted as a pass. The original, interrupted and successful retry logs remain distinct. This is not a claim of a single clean 611-test full run.
Typecheck, eight-family dispatcher smoke and diff checks passed on the integrated source. The post-suite ledger audit reported zero entries and zero append-only violations. That empty scan is explicitly bounded; it is not populated-ledger integrity proof. Earlier isolated ledger and writer evidence remains in the assessment and joint-proof memos. Verification used Node v24.13.0; no claim about a deployed runtime was inferred.
Configuration and release boundary
Closure HTTP, closure provider execution and assessment/provenance flags require literal true; their defaults remain off. No source configuration enables them, dispatcher fanout or external-action runners. The closure provider adapter still permits only the Square sandbox host.
The flags do not neutralize shared dependencies: canonical tenant selection, payment serialization/idempotency and installed database triggers affect their existing paths regardless of endpoint flags. Consumer and queued-event tenancy, migration history/data compatibility and global-lock throughput therefore remain release checks. This local test applies the two feature migrations against the current baseline, not against production migration history or data.
The live ledger was checked September 29. With this source integration and the previously accepted joint local proof, Revenue's ADR-0049 assessment implementation commitment is completed. The broader ADR-0048 commitment remains working, and the paid-invoice-handoff production readiness event remains uncleared. Source push/merge, deployment, production migrations and activation require their separate release steps. No production flag, financial cleanup, historical replay, external provider action or customer communication occurred. The separate coordinator-owned ADR-0048 response-loss proof uses a pinned copied runtime and is outside this source integration.