# 듀얼 코치 연결 흐름 구현 계획

## RALPLAN-DR
### Principles
1. 고객별 데이터 격리와 append-only 이력을 훼손하지 않는다.
2. AI는 초안과 위험 판정만 만들며 고객 자동 전송은 금지한다.
3. 트레이너 일정 관리가 아니라 코칭에 필요한 최소 일정 참조만 구현한다.
4. 기존 canonical typed API를 확장하고 raw storage 편집은 금지한다.

### Decision Drivers
1. 기존 profile/gateway의 exact-triple 라우팅 및 승인 경계 재사용
2. 일정 미확정 상태에서도 체크인과 안전한 기본 영양 안내 가능
3. 위험·안전 신호·미응답을 누락 없이 운영자 검토로 연결

### Options
- A. 기존 customer wizard/EventStore와 AdaptiveOperatorService에 additive event/projection 추가 — 기존 격리·승인·감사 경계를 재사용하나 projection 변경이 필요하다.
- B. 별도 듀얼코치 서비스/저장소 구축 — 격리는 쉬우나 canonical source가 분열되고 운영 경계가 중복된다.

**Decision:** A. 기존 canonical 모듈을 additive하게 확장한다. B는 이중 장부와 승인 경계 중복 때문에 제외한다.

## Implementation Sequence
1. Canonical domain contract
   - `/home/cube/.hermes/profiles/physique-coach/workspace/checkin_cli/`의 customer wizard EventStore 및 typed customer modules에서 현재 일정 참조, 영양 전략 상태, 체크인 위험 판정 이벤트를 찾고 additive schema를 정의한다.
   - 이벤트: 최초 일정 기록, 기본 영양 전략 생성, 일정 확인, 확정 전략 전환, 체크인 제출, 검토 항목 생성, 일정 메모 갱신.
   - 일정 필드는 날짜·시작 시각·고객 확인·트레이너 확인·마지막 변경 메모로 제한한다.
2. Trainer session-record surface
   - 기존 trainer exact-triple route와 세션 기록 경로에 최초 일정 입력을 추가한다.
   - 트레이너 캘린더, 가용 시간 탐색, 상세 변경 감사는 구현하지 않는다.
3. Nutrition strategy projection
   - 일정 미확정이면 식사 원칙·수분·단백질·규칙성만 포함한 기본안을 생성한다.
   - 일정 확인 후 기본안을 이력으로 보존하고 운동일·휴식일·식사 원칙·예외 대응이 있는 확정 전략으로 원자적 전환한다.
   - 마지막 일정 변경 메모를 다음 전략 생성 입력에 포함한다.
4. Morning check-in and risk policy
   - 체중·수면·피로·통증·운동 가능 여부·식사 계획 이탈 여부를 typed 입력으로 받는다.
   - 공통 임계치 기반 위험도를 계산하되 통증·운동 불가는 강제 검토한다.
   - 자동 알림 1회 후 미응답이면 운영자 검토 항목을 생성한다. 판정 규칙과 임계치 버전을 기록한다.
5. Operator review integration
   - Host-owned `AdaptiveOperatorService`/Topic-59 review 경계에 일정 메모, 위험·안전·미응답 검토 사유를 표시한다.
   - 최신 revision 승인 전 고객 전송을 금지하고 mutation 직전 owner/config/registry/consent/activation/source/artifact/epoch pins를 재검증한다.
6. Projection/import compatibility
   - `history_imported` 및 `import_manifest.observation_kst_day` 계약을 먼저 확인하고 projection schema mismatch를 수정한 뒤 역사 데이터나 synthetic fixture를 사용한다.
   - 기존 revision/epoch와 데이터는 보존한다.

## Acceptance Criteria
- 최초 일정 완료에는 날짜·시작 시각·고객 확인·트레이너 확인이 필요하다.
- 일정 미확정 상태에서도 체크인과 제한된 기본 영양 전략이 활성화된다.
- 운영자 일정 확인 후 확정 전략으로 전환되고 기본안은 append-only 이력에 남는다.
- 위험 임계치 초과, 통증, 운동 불가, 알림 후 미응답이 각각 운영자 검토 항목을 만든다.
- 어떤 경로도 AI 초안을 고객에게 자동 전송하지 않는다.
- 고객 A/B, Richard 개인 공간, 트레이너 공간 사이 데이터가 교차하지 않는다.
- 일정 변경 기능은 현재 일정·마지막 메모를 넘는 캘린더 관리로 확장되지 않는다.

## Verification
- Unit: 전략 상태 전이, 강제 안전 신호, 임계치 경계값, 미응답 알림 idempotency.
- Integration: trainer record→customer EventStore→nutrition projection→Topic-59 review.
- Isolation: 잘못된 chat/topic/user triple 및 customer id 교차 접근 fail-closed.
- Regression: append-only supersedes, 최신 revision 승인, uncertain delivery reconciliation.
- Migration: 기존 데이터/revision/epoch 보존 및 importer/projection schema 계약.

## Risks
- 일정 기록이 캘린더 기능으로 팽창: schema와 UI 필드를 명시 목록으로 제한한다.
- 임계치 오판: 안전 신호 강제 검토와 정책 버전 기록으로 완화한다.
- projection mismatch: importer 계약 수정 전 fixture/history 생성 금지.
- 중복 검토/알림: event idempotency key와 receipt reconciliation을 사용한다.

## Intent Reconciliation
- 상세 `artifact:schedule-audit-log`는 승인된 `artifact:schedule-reference-note`로 대체한다.
- 트레이너 일정 관리와 고객 자동 전송은 비목표다.

## ADR
- **Decision:** Extend existing canonical customer modules and operator review flow additively.
- **Drivers:** isolation, approval safety, minimal schedule scope.
- **Alternatives considered:** separate service/storage; rejected due to split canonical state and duplicated controls.
- **Consequences:** projection and event schemas grow additively; migration compatibility must be verified first.
- **Follow-ups:** execute only after explicit approval; preserve live-data and provider-action prohibitions during verification.