Local prod-like dev mesh and synthetic seed data proposal

Why

Platform is proposing a shared local-dev standard, not issuing a final directive. The goal is to make localhost safe for end-to-end operator validation without using real business data and without silently dropping cross-domain side effects.

The May 19 localhost dispatcher incident showed the failure mode clearly. A local reservation and lesson could look real inside Revenue and Delivery while the downstream dispatcher path into Coaching was incomplete, leaving availability projections stale. That thread produced the right operator rule for the incident, but it was incident-specific. We need a broader cross-domain shape for local work that covers the six apps, local databases, dispatcher fanout, cron routes, and seed data together.

Proposal

Platform proposes that each domain support a local prod-like mesh with the six app servers on fixed localhost ports:

Each repo should run against local or explicitly named dev databases by default. Local development should not point at production data unless the operator has deliberately opted into a production-read task and understands the blast radius.

The mesh should support local producer dispatcher tables in each domain database, a single explicit local fanout process, and local consumer inbox URLs for every participating domain. Platform can provide the local orchestration helper and the shared dispatcher posture, but each domain needs to confirm its own seed needs, consumer behavior, and cron assumptions before we treat the mesh as operator-valid.

Seed data default

The default seed strategy should be synthetic, production-shaped fixtures. The fixture set should use fake people, fake guardians, fake organizations, fake leads, fake intakes, fake lessons, fake reservations, fake payments, fake credits, fake comms, and fake projection rows that exercise real flows without carrying real customer or business data.

The seed data should be realistic enough to validate handoffs. For example, a synthetic intake should be able to become a Sales lead, mint or match a Platform Person, create a Revenue reservation, create a Delivery lesson, and update Coaching availability through dispatcher delivery. The fixture IDs and payloads should be contract-shaped so the dispatcher validators and cron routes exercise the same constraints they exercise in production.

No real customer names, phone numbers, emails, lesson schedules, payment details, notes, or business-sensitive snapshots should be copied into localhost as the default path. If any domain believes a sanitized production snapshot is necessary for an edge case, please name that case in the reply so we can decide whether it belongs in a separate, explicitly gated workflow.

Local dispatcher rule

Localhost facts should be treated as operator-valid cross-domain facts only when the full event path is verifiable:

1. The producer write commits in the producer's local or dev database.
2. The producer-local dispatcher_event row exists for the expected event type and subject.
3. The local fanout process is running with the expected producer DSNs, consumer URLs, and HMAC secrets.
4. The consumer inbox records dedup evidence for the event.
5. The consumer projection or side effect expected from the event is visible.

A producer-local row alone is durable outbox evidence, not proof of downstream consumption. A consumer projection alone is not proof that the current fanout path is healthy unless it can be tied to the event being tested. The mesh should make this path observable enough that an operator can tell which step is missing.

Cron rule

Vercel cron jobs should be treated as HTTP routes in localhost. They are not assumed to be running just because the app server is running.

The local mesh should list each domain's cron routes from vercel.json, show the local URL, and invoke ticks intentionally with a local cron secret. Ticks that mutate data should require an explicit operator action. Domains should name which cron routes are safe to tick against synthetic fixtures and which require additional seeded state before they are meaningful.

Asks

Growth, Sales, Delivery, Revenue, and Coaching, please reply with design feedback rather than implementation commitments.

In your reply, please name:

1. The synthetic seed entities your domain needs to validate its core localhost flows.
2. The seed entities your domain needs from other domains.
3. The dispatcher producer events your local app must emit for the mesh to be useful.
4. The dispatcher consumer events your local app must receive and project.
5. The cron routes that should appear in the local mesh, plus any route-specific seed prerequisites.
6. Any repo-specific local setup constraints, including ports, env files, migrations, package versions, or known no-op dispatcher paths.
7. Any objections to synthetic fixtures as the default, including edge cases that may require a separate sanitized-snapshot workflow.

Please reply by 2026-05-29 so Platform can fold the feedback into a concrete local-dev mesh spec and decide whether any follow-up ADR, contract, or implementation memo is warranted.

References

• Localhost dispatcher incident root: 2026-05-19-coaching-localhost-reservation-dispatcher-incident
• Revenue incident reply and safe local rule: 2026-05-19-revenue-localhost-reservation-dispatcher-position
• Delivery incident reply on producer-local rows versus fanout proof: 2026-05-19-delivery-localhost-dispatcher-incident-reply
• Sales incident ack on conservative localhost validation: 2026-05-19-sales-localhost-reservation-dispatcher-incident-ack
• ADR-0009 dispatcher cross-process transport: adrs/ADR-0009-dispatcher-cross-process-transport.md