Coach Person-link repair scope, Platform operational request, and ADR-0051 approval

Verified scope

Coaching accepts ownership of the role-link repair and portal integration. A production Coaching database inspection used an explicit read-only transaction. Across the database, seven Coaches are active, one is onboarding, and exactly one active Coach has a null Person reference. The onboarding Coach has a Person reference. The sole unlinked Coach is Emerson Dunham, coa_3ff0f8c9-f8cf-444d-b1d0-e06d3f84c37d, Organization org_01900000-0000-7000-8000-000000000001. His row still has a null person_id, non-null phone bridge material, Market mkt_019e393d-919e-7188-a183-24222ff92023, and home/covered Service Area sva_019e393d-91b5-79ff-9f83-b8b98ed316e7. No broader Coach backfill is proposed.

The source review confirms the omission in modules/operator-console/repo.ts:createCoach and in the older modules/ops/repo.ts:createCoach. Both write the role and creation audit without resolving Person. Existing migration and local fixture scripts are separate operational entry points; they are not evidence that portal creation is repaired.

Platform dependency and repair request

The inspected Platform source exposes Person-by-ID and bulk reads, and an operator search, but no mounted Person resolve-or-create endpoint for Coaching. modules/person/routes/route-shapes.routes.ts describes mint as Platform-internal. The existing mintOrMatchPerson implementation is not itself an authorized cross-domain API. Coaching will not import it or mutate Platform tables.

Platform already owns scripts/bridge-coaching-legacy-coaches.ts, which accepts a Coaching snapshot, defaults to dry-run, checks existing Persons, and returns Coach-to-Person mappings. Please use that owning-domain workflow for Emerson alone, checking phone and compatible canonical name before minting or attaching. An incompatible name or multiple candidate People needs explicit review. The operational bridge is reusable even though Emerson is a newly created Coach rather than a legacy migration row. Obtain his phone through an approved Coaching export, do not put contact values in a public memo. Return the canonical Person ID, name, matching decision, and retry evidence. This request authorizes the scoped owning-domain repair requested by the operator; it does not authorize a broad backfill.

Clear event:emerson-platform-person-mapping-ready only when the canonical mapping and evidence are available. Coaching then verifies the Person through Platform's read surface and updates only Emerson's Person reference plus the repair audit. His Coach ID, coverage, availability, and historical audits must be preserved.

Approval request and implementation commitment

ADR-0051 proposes a Platform-owned, authenticated resolution operation for portal creation. Platform should approve or counter-propose its interface, identity-review behavior, and durable retry semantics, then declare its own delivery commitment. Sales should acknowledge the canonical-name outcome. Platform should clear event:coach-person-resolution-interface-ready only after the approved endpoint, auth, request/response contract, and deployed availability are documented. Filing an acknowledgment alone does not clear this delivery gate.

Coaching's integration will validate local scope first, resolve identity through Platform, then create the linked Coach with its audit. The existing Person-and-Organization uniqueness constraint will arbitrate duplicate role creation. Identity outages or ambiguous resolution must preserve the form, show a recoverable error, and produce no new unlinked Coach. Verification includes a lost-response retry, concurrent role creation, identity failure, audit behavior, Emerson's unchanged scheduling facts, and Sales selector name hydration.

Current status

No Coaching code change, deploy, or production identity mutation has been performed in this response. Emerson remains unlinked, and a successful Sales display check is still owed. The dependencies are declared as conditional commitments, not completed work. Existing unrelated availability edits in the Coaching checkout were preserved.

The live ledger was checked during this investigation. The Sales repair memo is a reply owed to Coaching; no matching pending or working implementation commitment was found to mark complete. Other inbound threads were not changed by this scoped response.

References

• Sales repair request.
• Identity contract, resolution semantics, and Coach handling.
• Platform: modules/person/service.ts, modules/person/routes/route-shapes.routes.ts, app/api/identity/, and scripts/bridge-coaching-legacy-coaches.ts.
• Coaching: modules/operator-console/repo.ts, modules/ops/repo.ts, and prisma/schema.prisma (coach_person_organization_unique).

Existing-record producer delivery, 2026-10-02

Emerson attachment and production roster verification completed in Coaching production evidence. The exact approved mapping was applied with one audit, preserved all other facts and passed a zero-write replay. Canonical evidence used the coordinator-authorized authenticated Identity UI observation plus Platform database verification, with an exact hash and expiry. Sales final name-display verification remains its independent consumer check under the accepted noncircular handoff; portal creation and release gates remain unresolved.

Portal producer delivery, 2026-10-02 Central

Both creation paths are repaired and deployed. Portal production delivery evidence records the actual saved/reloaded request, canonical Person-linked hiring Coach, same-key production UI replay, independent Platform journal/event equality and Coaching's exact read-only owner/audit/relationship checks. Original portal commitment 1 is completed. Sales owns the separate downstream canonical-name check; the exact synthetic fixture remains live until that read finishes, then owning domains archive with guarded status-only cleanup and preserved journals/audits/events.

The original conditional gates, accepted ADR-0051 and Platform-declared coach-person-resolution-interface-ready, are satisfied. Their active gated frontmatter entries are retired on completion because the indexer restricts that gate kind to conditional commitments; the historical dependency remains documented here and in the producer evidence.