ADR-0049 release source and production preflight checkpoint
The October 2 resume advances final source integration and read-only deployment discovery. The four scoped local implementation commitments remain completed; Sales activation and existing-client reconciliation remain conditional on the uncleared paid-invoice-handoff-ready decision. This checkpoint authorizes no deployment, production migration, feature activation, provider action or reconciliation apply.
Corrected Revenue source
The earlier root source-readiness memo named Revenue d404d2c before a later writer race exposed duplicate generic-release publication. The current runtime candidate is 915ee657d4d5c6c205a26c180a978a26d9864f41; documentation checkpoint 3359395b33e982b3f8b23f6cfdb4ce70a4c92362 adds bounded writer evidence without changing runtime. The corrected writer locks and reads current financial state inside one transaction before deciding whether release is a no-op. Do not select the older integrated commit for release.
The Revenue fix memo records 54 focused and 612 full regression cases, typecheck and dispatcher smoke passing, plus actual valid-policy generic-release orders. The later checkpoint preserves the remaining all-writer, provider, crash, throughput and migration limitations. Its delayed inbox contradiction and non-dedup completion are not described as complete closure acceptance. ADR-0050 remains a separate proposed contract dependency, coordinated through the ADR-0048 owner loop.
Final local integration and build evidence
Sales runtime c24f379488a1a3fb3afa4022523bde8e677a12db preserves the later scheduled-follow-up ordering in the isolated handoff candidate. Documentation checkpoint 70aaa63a37a1b2ed8f7c5cc831e0954d94b35444 is clean and retains an exact 132-path difference inventory against the primary workspace. Earlier deployed user commit 5987b1b is accounted for through the prior integration. Independent primary notes, geography, navigation, menu and cadence edits remain untouched and explicitly classified; this scoped candidate must not replace that dirty workspace wholesale. The later Sales ADR-0048 proof checkpoint adds no application-runtime difference from the integrated source. ADR-0050 has no runtime implementation in this candidate.
Sales passed 76 Workbench tests, application typecheck, retained-fixture read-only cadence drift checks, and a direct Node 24 build with build ID _xg5uCVOP6YhOR_6LfBBZ. Normal source and compiled instrumentation schema/trace checks passed without database writes. Migration and prompt-install hooks were bypassed. These are new bounded integration checks; the previous joint financial proof was not replayed.
Platform's existing committed candidate 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a, extracted in its retained archive, passed a direct Next 16.1.4 build under Node 24.13.0, build ID HH3AMH-3wmXhLm5RHja4E. Database URLs and auth origin used unreachable loopback port 1, the auth secret was an inert build placeholder, and both background workers were disabled. The build used the root's installed dependencies and inferred that parent as its workspace root; it was not an independent clean dependency installation. Prisma migration/generation build hooks were bypassed. Initial failures from the archive's absent own Next package and missing build-only auth configuration remain in separate logs. No application source changed to make this build pass. Evidence: Platform .tmp/adr0049-platform-build-evidence-20261002.json.
Observed Vercel production targets
Authenticated local Vercel CLI GET requests read each project's current production target and then its exact deployment record. The connected Vercel app required reauthentication, but CLI authentication succeeded without changing credentials or configuration. All four target records report READY; this indicates their existing deployment state, not ADR-0049 readiness.
| Project | Production deployment | Metadata source | Deployment Node major |
|---|---|---|---|
| Sales | dpl_5neNsnNv8DQ3mV5GakUouQbwmpB7 |
5987b1b56495c5eca43cc0617579e0da19689f14 |
20 |
| Revenue | dpl_DH9BwUY6AatGaLkrG4taw3NtNGw9 |
f7b8ad71dea126ba34ca615b4e4004c07a348627, dirty CLI upload |
24 |
| Delivery | dpl_Cf9U964S6fADECJgvEuiUzAonxZx |
e806e1b4641a6e24bfa4f06fc94d29b83ccba72e |
24 |
| Platform web | dpl_D6X7rQaPWMkj2L4fFoKTUsLv2Che |
239bf72407972f0bac52294d6f1ecc5f1204f5d3 |
24 |
The Revenue custom-domain alias was independently resolved to that same deployment. Revenue subsequently compared the authenticated uploaded-source manifest: all 758 uploaded files match the f7b8ad7 baseline (749 after explicit LF/CRLF conversion, nine raw). There are ten changed candidate paths and 41 candidate paths absent from that manifest, including the six new API route files and two migrations. This narrows the dirty-upload uncertainty without attesting to compiled artifacts or immutable environment. These Vercel records do not describe the separate Render dispatcher worker. All project defaults currently specify Node 24; Sales' immutable production deployment specifies Node 20 and the candidate retains package engines >=20.11.0 <21. Both majors have local artifact evidence. Verify the actual selected runtime on the next authorized build.
The current production-target environment metadata contains neither Sales handoff flag, Revenue's handoff/provenance flag nor Delivery's handoff flag. This is presence-only metadata for current project settings, not a readback of immutable deployed environment values. Existing dispatcher flag values were not certified. Curated local evidence is in Platform .tmp/adr0049-production-deployments-20261002.json, .tmp/adr0049-revenue-aliases-20261002.json and .tmp/adr0049-vercel-flags-20261002.json; no credentials were included.
Dispatcher inventory boundary
At 2026-10-02T20:43:56.383Z, a repeatable-read, read-only transaction against Platform's configured remote Sales producer connection found zero lead.handoff.completed events, no matching fanout:delivery cursor, zero computed backlog and zero matching unresolved dead letters. The September 29 observation remains separately retained. New evidence: Platform .tmp/adr0049-live-release-inventory-20261002.json.
After the operator signed into Render, the authenticated dashboard identified live background worker srv-d7u4fq9j2pic739goqg0, deployment dep-d9uianvqj5pc73fln7v0, at commit d61bae60eeeb1d694e13a76fcea1b5050dfd8da0. Its repository is Platform main, build command npm ci, start command npm run render:worker. Saved environment values show DISPATCHER_FANOUT_ENABLED=true, tenant tnt_sguild, and Delivery destination https://delivery.sguildswim.com/api/dispatcher/inbox.
The saved Render Sales producer hostname, port, database, schema and Supabase project reference all match the configured connection used for the read-only inventory. Credentials were neither printed nor placed in evidence, and raw credential equality was not asserted. Inspected values were hidden again. This is stronger target configuration evidence than the September 29 record, but not a shell-level attestation of the running process environment or signed Delivery HMAC agreement. Evidence: Platform .tmp/adr0049-render-readonly-20261002.json.
The registry entry has no per-event off switch. Because saved master fanout is enabled, deploying the candidate can immediately route persisted matching rows; an absent cursor starts from zero. Repeat the exact inventory immediately before an authorized rollout and verify consumer readiness first. No Render setting or deployment was changed.
Delivery's concrete preflight gaps
Delivery independently used authenticated Vercel project environment listing, pull and individual /v1/projects/{project_id}/env/{env_id} GETs for the production database variables. Both variables are type sensitive and yielded no usable value. No guessed credential fallback occurred. The first published Delivery preflight therefore could not inspect a database. A subsequent read below used the independently authenticated Render producer binding; masked Vercel application datasource equivalence remains unverified. Source adds closure and payment-handoff migrations, eight closure guards and a 51-model client.
Current project configuration lists DELIVERY_DEFAULT_ORG_ID but lacks the payment consumer's required DELIVERY_ORGANIZATION_ID. The owner confirmed no source fallback between them. The handoff flag is also absent. These settings and the actual generated schema/client must be reviewed before activation. ADR-0049 HMAC ingestion is distinct from the still local-only ADR-0048 closure runtime. Delivery's later ADR-0048 branch has isolated-guard and proof additions to preserve in any future combined source selection; no combined source merge was claimed by this preflight.
Qualified producer catalog findings
After reading Render's saved producer targets for each domain, owners matched hostname, port, database, schema and Supabase project reference against existing authorized credentials. Connections enforced read-only transactions, queried catalog/migration metadata and rolled back. No customer rows, financial writes or migration commands were used. These findings concern the authenticated Render configured producer databases; they do not certify Vercel's masked application URLs or the immutable running-process environment.
Sales observed no journal entries for 202609270001_onboarding_closure or 20260927010000_add_paid_handoff_terminal_outcome, no task_one_open_onboarding_closure index, and zero handed_off vocabulary entries. Revenue observed no entries for 20260927020000_onboarding_closure or 20260927030000_payment_handoff_assessment, no closure/handoff tables or functions, and no reservation closure_revision. These are concrete missing prerequisites on the checked targets. They are not authorization to apply the migrations.
Delivery observed neither 20260927010000_onboarding_closure nor 20260928010000_payment_handoff in its completed migration journal. All three closure tables and payment_handoff_receipt are absent, with zero of eight required closure triggers and zero closure functions. Existing ownership lacks payment_receipt_id, first_paid_at and payment_handed_off_at; credit_reservation_id and first_locked_at remain NOT NULL. This checked producer schema cannot support payment-only ownership yet. The owner retained its read-only catalog and supplemental ownership definitions without querying customer data.
Sales' scoped integration publication is b6337595774410b3e58f7856b014874a9cafc706; Delivery's first preflight is 2c9c35351a052db4b55cd3c7a08e00c7668c2c6c; Revenue's source and qualified catalog record is f595d728161d947a22fe6bfe0ad84fd4630c3e58. Each owner published through its serialized coordination window and ran indexing/freshness. Delivery and Sales' later producer catalog findings are consolidated here. See Sales preflight, Delivery preflight, Revenue preflight, and the curated evidence.
Remaining release boundary
Select clean, reviewed domain source, resolve production migration history and actual generated schema mappings, and verify workload authorization and signed handling on intended deployed endpoints before requesting a concrete release. Revenue's SQL writer guards and shared payment behavior have effects even when new endpoints are disabled. Delivery must retain nullable first-lock compatibility and durable ownership, receipts and preparation recovery. Consumers and routing precede Sales publication; broad scheduled reconciliation remains independently gated.
The ADR-0048 coordinator owns exact ADR-0050 contract drafting and owner approval. This release review neither implements that proposed wire protocol nor clears broader closure acceptance. Existing proof databases, failed evidence and unrelated working-tree changes are retained.
This increment changed no deployed source, database schema, feature setting or customer state. The release requires an application-target-bound migration plan, source/configuration approval and staged deployed verification before Sales can clear activation readiness. Platform's existing dirty fanout and local-mesh work remains outside the candidate.