Repair portal coach creation and Emerson Dunham's missing Person link
Why
The operator created Emerson Dunham through the Coaching portal, then could not find his name in Sales' Coach proposal selector for Ala Moana Beach Park. He is present as Coach 84c37d. The operator requested this memo so Coaching can repair the creation flow and the existing record.
Confirmed evidence
Sales performed read-only checks against the production Coaching database and live roster endpoint. Emerson's coach record is coa_3ff0f8c9-f8cf-444d-b1d0-e06d3f84c37d, organization org_01900000-0000-7000-8000-000000000001. It is active, with market mkt_019e393d-919e-7188-a183-24222ff92023 and home/covered service area sva_019e393d-91b5-79ff-9f83-b8b98ed316e7, but person_id is null.
The creation audit records coach.create, actor system:operator-console, at 2026-10-03T01:44:21.848Z (October 2, 2026, 8:44 PM America/Chicago). Its after-state also has a null Person link. The live GET /api/v2/coaching/roster?organization_id=org_01900000-0000-7000-8000-000000000001 returns this coach with person_id: null and no display name.
The inspected Coaching source explains the missing link: modules/operator-console/actions.ts calls createCoach in modules/operator-console/repo.ts. That implementation creates the Coaching row and audit entry, without calling Platform Person resolution/creation or assigning personId. Sales' roster hydration requires a Person ID; without it, the selector falls back to the coach ID suffix. This is an identity-link gap, not an availability rejection or market exclusion. The evidence establishes the absent link; it does not establish that no matching Person exists elsewhere in Platform.
Asks
- Repair the Coaching portal creation path using Platform-owned Person resolution/creation and persist the resulting Person ID on the coach. Handle retries without duplicate People or coaches, and make identity failures visible and recoverable rather than silently reporting a fully usable coach.
- Repair Emerson's existing link through the owning-domain workflow. Check for a matching canonical Person before creating one. Preserve his coach ID, coverage, availability, and audit history.
- Review other coach-creation entry points for the same omission, and report the scope of active coaches with missing Person links before proposing any broader repair.
- Reply on this thread with Coaching-owned commitments, implementation/deployment status, and evidence that a portal-created coach has a Person link and appears by name in the Sales selector. Include Emerson's repaired coach/Person IDs and retry/failure-path verification.
Platform retains canonical Person ownership; Sales requests the repair and has made no Coaching or Platform mutations. This memo requests an implementation repair within existing ownership. If the remedy requires a new cross-domain contract or design, coordinate the proposal and required ADR approvals before changing that interface.
References
- Identity contract
- Coach identity validation
- Coaching:
modules/operator-console/actions.ts,modules/operator-console/repo.ts,modules/availability/routes/roster.routes.ts. - Sales:
modules/coaching-roster/coaching-roster.service.ts,app/workbench/_components/AvailabilityPlannerDrawer.tsx(coachOptionFromRoster).