Re local dev mesh needs a shared identity and reservation graph

Why

Sales hit a concrete operator failure while validating the Onboarding workbench. The market selector could be made to render Dallas and Oahu correctly inside Sales, but that is not enough. The operator expectation is cross-domain: a synthetic Person should be able to start as a Growth intake, become a Platform Person, become a Sales Lead, create a Revenue reservation, become a Delivery Lesson, reference a Coaching Coach, and remain traceable through production-shaped events.

The current local mesh fixture sets do not guarantee that. Each repo has useful local seeds, but several of them mint independent local IDs. That makes localhost look populated while hiding the exact transfer failures the mesh is supposed to expose.

What Sales observed

Platform has a local mesh fixture set with local organization, local Dallas market, local Service Areas, and Person IDs in the per_01970000... range. Platform also has production-shaped canonical Dallas and Oahu geography rows in the canonical geography tables.

Growth seeds local intake rows and intake.captured events, but most seeded intakes are not already tied to the same Person IDs Sales, Revenue, Delivery, or Coaching use. The seed validates Growth capture, not the full Growth to Platform to Sales chain.

Sales has local Leads in the lead_018f5000... range and Person references in the per_018f5000... range. Sales can normalize local Lead geography to Platform canonical Dallas and Oahu, but that does not make the Sales Persons real Platform Persons, and it does not make a Sales reservation the same Revenue reservation or Delivery lesson.

Revenue's mesh uses per_01900000..., crr_01900000..., les_01900000..., credit account, order, ledger, and reservation fixtures. Those are valuable for Revenue cron and lock-state testing, but they are not currently declared as the same People and Reservations that Sales and Platform seed.

Delivery's mesh uses a partly overlapping per_01900000... family for customer handoff and lesson fixtures, but its lesson, lock, service-area, and coach fixture IDs are Delivery-local. It can validate Delivery behavior without proving the Revenue and Sales references are the same operational story.

Coaching's seed uses per_mesh_coach_*, coa_mesh_*, mkt_mesh_*, and svc_mesh_* IDs. That validates Coaching eligibility cases, but it does not prove that a Delivery assignment references a Coach role record backed by a Platform Person and a Platform-owned canonical geography.

Production transfer rule

Production transfer should never be "copy this row into another repo." The transfer graph is the contracts:

1. Growth produces intake.captured on a fsm_ form submission.
2. Platform mints or matches the canonical person_id and produces intake.matched.
3. Sales opens or attaches the lead_ role record to that person_id.
4. Sales close orchestration creates a Revenue crr_ reservation and a Delivery les_ lesson through the scheduling and reservation contracts.
5. Revenue owns reservation funding, lock, ledger, and the first-lock customer.handoff.
6. Delivery owns Participant, Lesson, lesson-site, outcome, and coach assignment facts.
7. Coaching owns Coach role records, eligibility, availability, and booking projections keyed by Platform Person and Platform geography references.

The shared local mesh should model that same transfer graph. It should not seed six unrelated final states that happen to have plausible labels.

Proposed fixture spine

Platform should own the shared synthetic fixture spine for identifiers and identity/geography facts, because Platform owns Person and canonical geography. The spine should be consumable by all repos and include:

1. One synthetic Sguild organization and tenant binding.
2. Canonical Dallas and Oahu market IDs and Service Area IDs, using the same IDs each domain reads in production-shaped geography flows.
3. A Person roster that includes adult learners, guardian plus minor swimmers, reactivation cases, operator users, and coaches. Every domain that stores a Person reference should use these person_id values.
4. A Growth intake roster with fsm_ IDs, source, campaign, visitor, and test-data flags.
5. A Sales Lead roster keyed to the Growth fsm_ and Platform person_id values, including stage history from new through onboarded and terminal cases.
6. Revenue commercial facts keyed to the same person_id values: credit accounts, orders, credit reservations, funding state, lock state, and first-lock handoff rows.
7. Delivery operational facts keyed to the same reservation and Person graph: participants, lesson sites, lesson types, lessons, reservation locks, assignments, and outcomes.
8. Coaching supply facts keyed to Platform coach Persons: coa_ records, service-area coverage, certifications, availability templates, exceptions, and lesson-booking projections.
9. Dispatcher proof events that join the same IDs from source to projection instead of faking successful downstream state.

The manifest does not need to be production data and must not contain real customer information. It should be synthetic and deterministic, but production-shaped enough that a local operator can click from lead intake to payment to lesson to coach without crossing into a different fictional universe.

Asks

Platform: please either publish a shared fixture manifest in the local-dev mesh spec or name the alternative source of truth. It needs to cover Person and canonical geography first, because every other domain depends on those IDs.

Growth: please align local intakes to the shared fsm_ and Person resolution graph, including intake.captured and intake.matched proof paths.

Revenue: please align local reservation, credit account, order, lock, and handoff fixtures to the shared Person and lesson graph, and keep reservation IDs stable for Sales and Delivery references.

Delivery: please align local participant, lesson, reservation-lock, lesson-site, lesson-type, and coach-assignment fixtures to the shared Revenue reservation and Coaching coach graph.

Coaching: please align local coach records to Platform Person IDs and canonical geography IDs, then expose availability and eligibility fixtures against the same Service Areas Delivery schedules into.

Sales: Sales will keep its local Lead fixtures tied to the shared fsm_, person_id, crr_, and les_ identifiers once the shared spine lands. Until then, Sales-local normalization should be treated as an app usability patch, not as proof of cross-domain transfer health.

References

• Root proposal: 2026-05-22-platform-local-dev-mesh-seed-data-proposal
• Sales feedback: 2026-05-22-sales-local-dev-mesh-seed-data-feedback
• Domain topology: domains/README.md
• Identity Contract: contracts/identity/README.md
• Credit Reservation Lock Contract: contracts/credit-reservation-lock/README.md
• Sales Scheduling Surface Contract: contracts/sales-scheduling-surface/README.md