Coaching acknowledges ADR-0051 and defines creation and repair acceptance checks

Position

Coaching explicitly acknowledges ADR-0051 as proposed, with no objection to the stated ownership and acceptance requirements. This is Coaching's approval of the proposed design, not a claim that Platform has approved, shipped, or supplied the interface. Platform remains owner of Person resolution, ambiguity handling, contact normalization, canonical name, tenant authorization, and durable resolution idempotency. Coaching remains owner of role persistence and its audit. Assignment ownership and the roster contract do not change.

The existing two commitments in Coaching's dependency memo remain the source of truth. They are not duplicated or completed here. Neither event:emerson-platform-person-mapping-ready nor event:coach-person-resolution-interface-ready is cleared by this acknowledgment. The ADR acceptance gate remains separate from interface deployment.

Read-only Emerson handoff

Coaching produced a local, ignored, single-record JSON input compatible with Platform's existing coach bridge. It contains only Emerson's current Coach ID, Organization ID, current Person reference, display name, given and family names derived from the verified display name, phone bridge material, status, and creation timestamp. The export used BEGIN READ ONLY, bound parameters for the exact Coach and Organization, and an exactly-one-row assertion. The current Person reference is still null. No database mutation occurred.

The coordinator receives the absolute export path through the private chat result. Contact values and the private input are not committed or reproduced in this memo. git check-ignore verified that the exported file is ignored. Platform should inspect candidates read-only first, using its own database configuration and resolution rules. Do not run the bridge's commit mode based solely on this handoff. This coordination turn authorizes preparation and inspection, not a production mutation or deployment.

Coaching implementation scope

Use a shared Coach-creation orchestration entry point in a module following the engineering layout standard (dto, schema, repo, service, route, index, and optional actions). Both modules/operator-console and modules/ops must call it. The console currently validates Market and coverage; the older ops path also needs equivalent Organization and home-area/Market validation before any identity call. Preserve the two callers' existing result shapes and actor/audit semantics at their adapters.

The service coordinates local validation, the approved Platform resolution client, and Coach persistence. Cross-cutting HTTP/auth transport belongs in lib; it must use the contract's approved auth and timeout behavior, without importing Platform implementation files or writing Platform tables. Validate the canonical response before writing. The operation key, tenant context, explicit matched/minted/review outcomes, and treatment of an existing Coach with different Market or coverage are contract requirements to settle with Platform, not guessed defaults. Reusing an existing Person-and-Organization Coach must preserve its facts and make the reuse visible to the operator rather than overwriting the role or falsely claiming a new one.

Persist a successful Person reference, new Coach, and creation audit in one Coaching transaction. On an existing-role conflict, load the unique Person-and-Organization Coach and return its ID without adding another creation audit. Catch only the relevant uniqueness conflict; surface unrelated database errors. A resolved Person followed by a failed Coaching transaction remains Platform-owned and is reused on retry, never deleted as compensation.

Creation actions and forms must expose recoverable identity and database errors, preserve inputs and the stable operation identity required by the approved retry contract, and prevent a success redirect or success notice on failure. Manual-review outcomes must show review guidance without selecting a candidate or minting locally. No new Coach may be saved with a null Person reference through either interactive path.

The existing-record repair will validate Platform's canonical mapping through its approved Person read surface, ensure the Person is not attached to a different Coach in Emerson's Organization, then compare and update Emerson's current reference within the repair transaction. If the reference changed after export, stop for review unless it already equals the approved canonical reference. Update only personId and the row's normal update timestamp, plus a durable repair audit; retain the creation audit and all role and scheduling facts. An already-applied mapping is a no-op with no duplicate repair audit. Do not broaden repair to other Coaches.

Acceptance and test plan

1. Both caller paths validate Organization, Market, and coverage before resolution. Invalid local scope makes no Platform request and creates no Coach or audit.
2. A valid matched or minted canonical response creates a linked Coach and exactly one creation audit in the same transaction. The audit includes the non-null reference. A malformed response, archived Person, unresolved alias, or empty Person ID fails closed.
3. A lost Platform response can be retried with the same approved operation identity. The result reuses the canonical Person. Concurrent identical creation requests produce one Person-and-Organization Coach and one creation audit, proven against an isolated test database with the real uniqueness constraint.
4. Platform timeout, auth rejection, invalid phone, incompatible-name or multiple-candidate review, and unavailable identity return recoverable form states. Values remain entered; there is no unlinked Coach, success notice, or success redirect. Contact values do not appear in error logs.
5. A database failure after resolution rolls back the Coach and audit. Retry reuses Person and succeeds once. A pre-existing role is returned without changing its status, Market, coverage, availability, compensation, or audit history; the UI reports reuse.
6. Emerson repair checks the canonical Person and uniqueness before write. A race changing personId is detected. The intended repair preserves Coach ID, Organization, Market, home and covered areas, availability templates/exceptions, bookings, certifications, compensation, creation timestamp, and existing audit entries. A second execution is a no-op.
7. An isolated browser verification exercises portal success, manual review, timeout with retained values, and retry. Run npm test and npm run typecheck after Coaching code changes. Subscriber smoke is required only if subscriber paths change; none are planned.
8. Production verification is a separate release step: establish a Ready Coaching deployment, verify Emerson's roster Person reference and canonical name read, then obtain Sales selector evidence for Emerson and a legitimately portal-created Coach. Do not create a production test Coach merely to claim success without an agreed fixture and scope.

Tests should mock the Platform boundary for service and form cases; isolated integration tests prove actual transaction rollback and uniqueness behavior. Browser, service, isolated database, and production evidence must be labeled separately. This memo prepares tests and scope; it does not claim they have run or passed.

Sales' consumer acknowledgment establishes independent final consumer checks after Coaching delivers each producer commitment. Coaching will supply the exact linked IDs, environment, roster response, and canonical Person name evidence when its producer work lands; completion of Coaching's commitments does not wait on those separately gated Sales final checks. The eventual selector evidence closes the end-to-end report without introducing a circular gate.

Current status

No Coaching runtime source changed, production write occurred, or deployment was attempted. Existing availability edits were preserved. The live ledger was checked: both repair commitments remain conditional on the original mapping, ADR, and interface gates. Platform's contract definition and candidate inspection are the next dependencies.