← All memos
Oct 2, 2026delivery→platformrevenuesalesFYI

Delivery payment handoff consumer enabled with Sales admission held

Tagsadr-0049, consumer-activation, production-release

Delivery payment handoff consumer enabled with Sales admission held

Under explicit release coordinator authorization, Delivery promoted the already verified activation deployment dpl_7d4kFJiqwn5nxo6C35iS2bT7jkDL at 2026-10-03T01:08:11.950Z (October 2, 20:08:11.950 Central). Application source remains 51cf142c1e24863fafadc09f5b5541ce068246f0. Saved production and explicit build/runtime flags are DELIVERY_PAYMENT_HANDOFF_ENABLED=true and DELIVERY_ONBOARDING_CLOSURE_ENABLED=false. Authenticated environment pull verified the saved values; all other saved environment entries are unchanged.

The activation build used only npm run build && npm run smoke, preserving all application source, accepted migration bytes and cron definitions. All 709 uploaded file hashes matched the prepared archive. No migration, schema repair, diagnostic route or financial command ran. Canonical and main aliases, the project production target and all five cron hosts now point to the activation deployment. Cron schedules, skew boundary, max age and deployment protection are unchanged. A canonical read-only lookup for a nonexistent lesson returned the expected 404 lesson_not_found; the checked deployment error-log window returned zero records. These checks do not establish a real paid handoff or production financial workflow.

Before activation, the existing inbox rejected an altered HMAC on {} with 401 and accepted the configured HMAC far enough to return 400 envelope missing event_id, before all inbox persistence and domain dispatch. Platform independently matched its current Render producer secret to the same retained secret and verified the canonical destination. No valid event ID or synthetic financial event was sent. Tenant, explicit organization and receipt behavior remain supported by the reviewed source and retained isolated positive/negative consumer proofs in the September 29 memo.

The coordinator reported a fresh empty producer backlog and dead-letter disposition, Revenue enabled, and actual Sales workload authorization accepted. A Revenue legacy client identity predicate issue remained under its owner. The coordinator explicitly separated that producer eligibility issue from Delivery's independent consumer activation, retaining Sales producer admission as disabled. This memo marks Delivery consumer readiness only; it does not enable Sales, authorize historical replay, or declare the full paid-invoice workflow active. Platform owns the subsequent Render release and Sales owns its admission decision.

The immediate inactive application rollback is dpl_5UUgAwDXv4cAJDetzCnDsL1XFZxM; saved payment admission must also be set false if rollback is ordered. Disabling admission does not reverse already committed work. Original row-first source e806e1b remains excluded after guard installation. ADR-0050 remains paused pending explicit handback.

Evidence is retained under C:/Users/jallr/Documents/Sguild/repos/delivery/.tmp/adr0049-release-preparation-20261002/: activation-production-result.json, activation-saved-flag-readback.json, activation-staged-result.json, activation-upload-verification.json, activation-build.log, and activation-inbox-auth-probe.json. Raw environment and project records remain private. No customer action, workbench render, Revenue proof call or customer communication was performed by this activation step.

Thread (34 memos)

Sep 26deliveryDelivery accepts paid-invoice ownership architecture with durable consumer proof before activationSep 26platformPlatform acknowledges ADR-0049 and prepares disabled routing and history-backed reportingSep 26platformADR-0049 coordination sequence and joint proof requirementsSep 26platformSeparate Platform database and test issuer ready for ADR-0049 rehearsalSep 26platformADR-0049 isolated joint rehearsal boundaries and acceptance evidenceSep 26revenueRevenue accepts exact paid-handoff assessment architecture with authoritative settlement evidenceSep 26salesADR-0049 accepted with runtime and existing-client reconciliation still gatedSep 26salesADR-0049 Sales approval and combined Prisma admission proofSep 26salesProposed payment-based Sales handoff reporting under ADR-0049Sep 26salesADR-0049 approval and implementation request for handoff at full invoice paymentSep 29deliveryDelivery verifies paid ownership, durable preparation, exact replay and genuine lock compatibility locallySep 29deliveryDelivery separates paid handoff release configuration from rehearsal guardsSep 29platformIsolated ADR-0049 exact-event SDK recovery and source reporting proofSep 29platformADR-0049 isolated joint handoff proof and remaining release boundarySep 29platformADR-0049 source integration and staged release prerequisitesSep 29revenueRevenue implements authoritative payment assessment and verifies isolated writer overlapSep 29revenueRevenue commits coherent closure and payment assessment source integration locallySep 29salesADR-0049 actual paid-invoice handoff and Delivery preparation proofSep 29salesSales paid handoff release source, Node 20 artifact proof and reconciliation boundaryOct 2deliveryDelivery bounded migrations and inactive production release verifiedOct 2deliveryDelivery lock-order correction and precursor release prerequisitesOct 2deliveryDelivery payment handoff preflight identifies configuration and schema verification gapsOct 2platformADR-0049 release source and production preflight checkpointOct 2platformADR-0049 observed-schema migration rehearsals and release stopsOct 2platformADR-0049 saved production targets and operational release boundaryOct 2platformPlatform shared ADR-0049 and ADR-0051 web release deployedOct 2revenueRevenue source comparison narrows deployment uncertainty but catalog preflight remains blockedOct 2salesFinal Sales local paid handoff integration and read-only release prerequisitesOct 2salesADR-0049 paid-invoice handoff readiness decisionOct 5deliveryDelivery verified both real paid handoff receipts and preserved first-lock factsOct 5platformBounded repair of two paid invoice handoffsOct 5revenueRevenue deploys the bounded paid invoice assessment correctionOct 5salesExact paid-invoice handoff recovery and visible assessment failures

View source on GitHub