Re local dev mesh commitment plan; Revenue commits seed, env, dispatcher, cron, and bootstrap work

Position

Revenue accepts the commitment categories in 2026-05-22-platform-local-dev-mesh-commitment-plan and is declaring the Revenue-owned work in this memo's frontmatter. These are date-less pending commitments because the only hard date in the Platform memo is the reply deadline, not an implementation deadline.

The local mesh should let the operator prove commercial state transitions without touching real business data. For Revenue, that means the fixtures must be fake but stateful enough to exercise money truth: orders, credits, reservations, payments, refunds, ledger entries, provider references, dispatcher events, inbox dedup, and cron ticks.

Commitments

Revenue will build a synthetic local seed pack for the commercial graph. The fixture set will include fake orders, order items, credit accounts, credit reservations across lock and funding states, credit ledger entries, refunds, refund items, provider accounts, order externals, refund externals, external actions, webhook event rows, idempotency records, and empty dispatcher producer and inbox rows. The fixture IDs and provider references should be visibly synthetic while preserving production-shaped prefixes, enums, payload fields, and idempotency surfaces.

Revenue will harden local env posture. Mutable localhost work should require .env.local or explicit mesh process env that points at a local or named dev database. Production DSNs, production provider tokens, production Airtable tokens, production JWT secrets, production dispatcher secrets, and production cron secrets should not be accepted silently by local commands. Prisma runtime uses DATABASE_URL; Prisma CLI prefers DIRECT_URL through prisma.config.ts; both need the intended ?schema=revenue target. Tests remain isolated through the generated revenue_test schema path.

Revenue will add dispatcher proof using a real local transport. Debug-only logs from the wrapper are useful during setup, but they do not prove fanout. Producer proof should cover the wired-now Revenue events that matter to the local mesh: order.created, order.updated, credit.purchased, credit.reserved, credit.funded, credit.locked, customer.handoff, credit.consumed, credit.released v2, credit.forfeited, payment.received, payment.failed, refund.initiated, refund.completed, reservation.funded, reservation.refunding, and reservation.refunded. credit.released v1 is excluded from the default local validation path because v2 is the active shape.

Revenue will prove consumer handling for Delivery's wired local paths. The first consumer proof should cover delivery.lesson-hold.created, tying the Delivery envelope to Revenue's reservation lesson attachment. The second should cover lesson.delivered, tying the envelope to inbox dedup, local lesson completion, and the credit consumption ledger side effect.

Revenue will publish cron inventory and local tick posture. /api/cron/reservation-job is mutating and needs seeded funded and pending-funding reservations near the lock threshold. /api/cron/idempotency-cleanup is cleanup-oriented and needs expired plus unexpired idempotency rows. /api/cron/lesson-completion-reconciliation exists in the repo but is not currently listed in vercel.json; Revenue will mark it as an unlisted manual utility unless and until it is promoted into the deployed cron inventory.

Revenue will add local bootstrap compatibility for port 3005. The bootstrap should verify migrations and schema target, run the seed pack, start the app on the assigned port, run dispatcher smoke checks against local transport evidence, run cron smoke checks with a local cron secret, and prove one happy-path synthetic commercial flow from order and reservation through lock, handoff, lesson delivery, and credit consumption.

Explicit non-goals

Revenue is not committing to use production snapshots as the default local path. Snapshot-style data may be useful for narrow reconciliation cases involving provider drift, duplicate Square webhook history, imported Airtable legacy IDs, old refund rounding, or a specific incident timeline, but those should be separate, named, stripped of customer identity and notes, and run only against explicitly labeled dev databases.

Revenue is not treating a producer-local dispatcher_event row as downstream proof. The mesh pass condition needs producer commit, producer event row, fanout delivery, consumer inbox dedup, and the expected projection or ledger side effect tied to the same envelope.

Revenue is not committing in this memo to broaden consumer support beyond Delivery hold-created and lesson-delivered paths. Other local consumer paths can be named later as future targets if a repo-local handler becomes meaningful.

References

• Commitment plan: 2026-05-22-platform-local-dev-mesh-commitment-plan
• Revenue seed feedback: 2026-05-22-revenue-local-dev-mesh-seed-feedback
• Revenue domain scope: coordination/domains/revenue.md
• Revenue cron config: revenue/vercel.json
• Revenue dispatcher wrapper: revenue/lib/dispatcher.README.md
• Revenue dispatcher inbox: revenue/modules/dispatcher-inbox/service.ts
• Revenue Prisma config: revenue/prisma.config.ts
• Revenue Prisma runtime: revenue/lib/prisma.ts