## Verdict
**REJECT**

검토 대상 Planner artifact:
- path: `/home/cube/projects/richard/traning coach/.gjc/_session-019f8455-334a-7000-99ca-318dfd0e06b1/plans/ralplan/019f8455-334a-7000-99ca-318dfd0e06b1/stage-01-planner.md`
- planner sha256: `8b224eceb12cef566b525b45b7b54564f41fc165b8e96c375e3ec89d61b6cafe` (assignment-provided; artifact content was read, but this restricted read-only review did not independently recompute the digest)
- planner stage_n: `1`

## Claim Checks
- **큰 방향은 명세와 대체로 일치합니다.** 단일 외부 유료 고객, 12주 계획/첫 4주 루프, 고객·개인 데이터 분리, AI 초안과 Richard님 최종 승인, 내부 전용 웹, KPI 논리곱, 다중 고객/B2B 보류가 Deep Interview spec에 맞게 남아 있습니다.
- **선택 원칙과 Option B의 방향도 일치합니다.** 사람 승인, 격리 우선, 최소 4주 범위, 감사 가능한 최종문을 내부 웹에 모으는 결정은 안전·운영시간·감사 가능성 driver를 직접 지원합니다.
- **고수준 단계 순서는 이해 가능합니다.** 출시 게이트 → 기록/격리 → grounding/감사 → 웹 승인 → KPI/온보딩 순이며 실고객 활성화를 마지막에 둔 점은 안전 우선 원칙과 맞습니다. 다만 실제 구현을 시작하려면 아래의 교차 계층 계약을 앞 단계에서 확정해야 합니다.
- **구체적으로 명시된 기존 파일은 모두 존재함을 확인했습니다.** `SOUL.md`, `knowledge/README.md`, `customer_coaching.py`, `wizard.py`, `wizard_models.py`, `customer_grounding.py`, `coaching_grounding.py`, `customer_reporting.py`, `customer_schedule.py`, `customer_admin.py`, `gateway/platforms/nutrition_coaching.py`, `gateway/platforms/telegram.py`를 확인했습니다. source spec도 명시 경로에서 읽었습니다.
- **대표 구현 경로 1—적응형 고객 체크인/트레이너 기록—은 현재 파일 범위만으로 실행할 수 없습니다.** 고객 wizard의 단계·저장은 `checkin_cli/wizard.py`뿐 아니라 `gateway/platforms/physique_checkin.py`의 허용 step/edit/callback 계약과 `physique_checkin_prompts.py`의 렌더링에 결합되어 있습니다. 신규 트레이너 기록 타입은 `checkin_cli/models.py`의 `EventType`/payload와 `store.py`의 저장·view 정책도 필요합니다. 이 핵심 callsite들이 Phase 1 파일 범위에 없습니다.
- **대표 구현 경로 2—승인 후 단일 전송/감사—는 아직 설계 계약이 없습니다.** 현재 `NutritionCoachingCoordinator`는 `draft-requests.json`에 요청 토큰만 저장하고, Telegram의 `_render_nutrition_draft`는 생성한 초안을 운영자 메시지로 보여줄 뿐 승인문·수정 이력·전송 claim·최종 전송 기록이나 고객 전송 서비스를 제공하지 않습니다. 따라서 계획이 말하는 “기존 Telegram owner-only 수동 초안/전송 경로”는 현 코드에서 확인되지 않았고, 웹/Telegram 공용 서비스의 모듈·저장소·상태 전이·API도 정해지지 않았습니다.
- **대표 구현 경로 3—평일 KPI/첫 4주 deferral—은 현 동작과 충돌합니다.** `customer_schedule.py`는 활성 고객에게 매일(주말 포함) daily task를 만들고 월 지정일에는 monthly task도 만듭니다. `customer_reporting.py`의 현재 `completion_percent` 분모는 기간의 모든 달력일입니다. Deep Interview는 평일 60~90초 체크인과 첫 4주 일일·주간 기능만 활성화한다고 확정했지만, 계획은 “월간 자동 고객 전달”만 비활성화하여 현재 owner-only monthly 생성은 그대로 남길 수 있습니다. 예정 평일 분모와 월간 task 자체의 비활성 규칙이 필요합니다.
- **웹 구현 위치는 결정되지 않았습니다.** 계획의 “기존 Hermes 웹 프레임워크 위치 조사 후 확정”, “신규 모듈/화면/테스트 1개”는 실행자가 구조를 선택하게 합니다. 실제 저장소에는 `hermes_cli/web_server.py`의 인증된 FastAPI dashboard, React `web/src/App.tsx`, dashboard plugin manifest/API 관례가 있고, 별도로 gateway `api_server.py`도 있습니다. 어느 lifecycle/auth/deployment 경로를 쓸지 정하지 않으면 localhost 바인딩, 세션 인증, CSRF, 기능 플래그, Gateway 프로세스와의 공유 seam을 검증할 수 없습니다.
- **대안 비교는 확정 요구와 맞지 않습니다.** Option A를 viable로 분류했지만 Deep Interview에서 Telegram과 Richard님 전용 내부 웹 관리화면이 둘 다 필수로 확정되었습니다. 따라서 A는 요구 불충족안이거나 historical rejected option이어야 합니다. 실행에 유용한 실제 대안은 기존 dashboard plugin, 기존 dashboard 내 built-in route, 별도 localhost 서비스처럼 동일 요구를 만족하는 구조 대안이어야 합니다.

## Missing Evidence
### Definitely missing
1. RTF `2026-07-21` 이후 원자료와 승인 PDF의 정확한 경로/버전 및 기능 매트릭스 산출물 위치가 없습니다. Phase 0의 핵심 입력을 실행자가 찾거나 추측해야 합니다.
2. 내부 웹의 정확한 backend/frontend/bootstrap/config/auth/test 파일이 없습니다. “조사 후 확정”인 채로는 plan approval 대상 구조가 확정되지 않았습니다.
3. 공용 승인·전송·감사 서비스의 canonical 모듈, 저장 위치, 스키마, API와 상태 머신이 없습니다. 특히 `draft → edited → approved → sending → sent|failed|ambiguous` 전이, 승인자/시각, 근거 digest, 최종문, Telegram 결과, 재시도 권한이 정의되지 않았습니다.
4. Telegram이 전송을 수락한 직후 로컬 `sent` 기록 전에 프로세스가 죽는 crash window의 정책이 없습니다. 외부 send API에 종단 idempotency가 없으면 “승인 후 정확히 1회”를 단순 key만으로 보장할 수 없으므로 ambiguous 상태와 수동 reconciliation 또는 명시적 at-most-once 정책이 필요합니다.
5. 트레이너 identity/address/schema와 owner/customer/trainer 공간 중복 규칙, 복수 세션/day 식별 규칙, 통증 신호가 초안 차단으로 전파되는 규칙이 없습니다.
6. Deep Interview acceptance의 동의 철회·삭제 요청·백업·로그 처리·보존기간은 Phase 0 조사와 일반적인 차단 문구 외에 구현·문서·테스트 작업으로 배정되지 않았습니다. 삭제 요청 상태, legal/operational hold, 파생물/백업 처리, 완료 증거가 빠졌습니다.
7. 기존 코드가 매일/월간 task를 생성하는 상황에서 평일 일정, 예정 체크인 분모, 첫 4주 monthly task 비활성화의 구체 규칙과 migration이 없습니다.
8. 60~90초 고객 체크인과 30초 트레이너 기록을 증명할 수용 방법이 없습니다. 분기 unit test만으로 사람의 완료 시간을 검증할 수 없습니다.
9. KPI 단일 기록원의 필드·단위·이벤트 소유자와 운영시간 측정 시작/종료, KST week 경계, 누락/중복/겹친 작업, 최초 15만원 계좌송금과 실제 재결제 증거의 판정 규칙이 없습니다.
10. 직접 영향받는 callsite/계약 파일(`checkin_cli/models.py`, `store.py`, `wizard_storage.py`, `gateway/platforms/physique_checkin.py`, `physique_checkin_prompts.py`, `nutrition_coaching_config.py`)과 운영 문서(`HANDOFF.md`, `choi_coach_system_report.html`)가 범위에 없습니다. HTML은 현재 실시간 콘솔이 아닌 운영 바인더이며 새 승인 흐름과 장애 복구 절차 반영이 필요합니다.
11. 두 소스 루트(`/home/cube/.hermes/...` runtime profile과 `/home/cube/projects/richard/hermes-agent`)의 배포 순서, 호환성, 서비스 재시작, rollback/version-skew 방지가 없습니다.

### Thin but possibly resolvable
- 현재 pre-mortem은 오발송·운영시간·provider 조건은 다루지만, 선택한 Option B의 핵심 신규 위험인 승인/전송 crash consistency, 웹 인증 우회/CSRF, runtime/profile 버전 불일치, 고객 데이터 손실·백업 복구 실패를 다루지 않습니다.
- Verification Plan은 범주가 좋지만 테스트 파일/fixture, 실제 provider·Telegram seam과 mock의 경계, 브라우저 보안 검증, 테스트 계정 timed rehearsal, 명시적 Hermes 회귀 명령/합격 기준이 없어 재현성이 낮습니다.

## Approval Boundary
- 진행 가능: Phase 0의 **읽기 전용** gap inventory, provider 약관 확인, 토큰 교체 여부 확인, 정확한 RTF/PDF 식별 및 기능 매트릭스 초안 작성.
- 승인되지 않음: 제품 코드/스키마/웹/전송/KPI 구현, 운영 profile 활성화, 테스트 또는 실고객 메시지 전송. 아래 계약과 파일 범위를 포함한 수정 계획이 다시 승인되기 전에는 실행자가 중요한 구조와 안전 의미를 추측해야 합니다.

## Summary
- **Clarity:** 목표와 고수준 phase는 명확하지만 웹 구조, 공용 서비스, 저장 계약이 불명확합니다.
- **Verifiability:** 논리곱·격리·승인 전 0회는 좋으나 시간 목표, crash window, 개인정보 lifecycle, KPI 증거 규칙은 검증 불가하거나 불충분합니다.
- **Completeness:** Deep Interview의 주요 제품 범위는 보존했지만 평일/월간 경계, 삭제·백업·보존, 배포/문서, 실제 callsite가 빠졌습니다.
- **Big Picture:** 안전 우선·단일 고객 MVP는 적합합니다. 다만 profile-local domain과 Hermes gateway/dashboard를 잇는 소유권·배포 경계가 없습니다.
- **Principle/Option Consistency:** Option B는 원칙과 맞지만 Option A를 viable로 둔 것은 확정된 내부 웹 요구와 모순됩니다.
- **Alternatives Depth:** 제품 범위안 A/B/C보다 요구를 모두 만족하는 dashboard/plugin/standalone 구조 대안 비교가 필요합니다.
- **Risk/Verification Rigor:** pre-mortem 형식은 있으나 선택한 웹/전송 설계의 가장 큰 실패창과 복구 증거가 빠졌습니다.

## Required Changes
1. **구조 결정을 완료하십시오.** 기존 Hermes dashboard plugin/built-in route/별도 localhost 서비스 중 실제 viable 대안을 보안·배포·수정량·gateway 공유 관점에서 비교하고 하나를 선택하십시오. 선택안의 정확한 backend route, frontend entry, manifest/bootstrap, config/feature flag, auth middleware, 테스트 파일을 명시하십시오.
2. **Phase 1 전에 canonical domain/storage 계약을 추가하십시오.** customer/trainer 주소와 역할, trainer-session event, adaptive check-in, draft/evidence/edit/approval/delivery/audit/KPI event 스키마와 소유 모듈을 표로 정의하고 append-only/supersedes 및 고객별 root 규칙을 연결하십시오.
3. **전송 상태 머신과 crash semantics를 명시하십시오.** 승인 불변성, idempotency key 범위, concurrent click, send timeout, crash-before/after-accept, `ambiguous` reconciliation, 재시도와 수동 복구가 같은 저장·전송 서비스를 쓰는 방법을 acceptance와 테스트에 포함하십시오. 존재하지 않는 “기존 Telegram 수동 전송 경로” 표현은 실제 신규 작업으로 고치십시오.
4. **파일 범위를 실제 callsite까지 확장하십시오.** 최소한 `models.py`, `store.py`, `wizard_storage.py`, `physique_checkin.py`, `physique_checkin_prompts.py`, `nutrition_coaching_config.py`, 구체적인 기존/신규 테스트 파일, `HANDOFF.md`, `choi_coach_system_report.html`의 변경 또는 불변 사유를 phase별로 적으십시오.
5. **Deep Interview 경계를 그대로 구현 가능하게 만드십시오.** 평일 일정과 예정 분모, 주말 동작, 첫 4주 monthly task 생성 자체의 비활성, 15만원 계좌송금/재결제 증거, 동의 철회·삭제·보존·백업·로그 runbook과 테스트를 명시하십시오.
6. **수용 기준을 측정 가능하게 보강하십시오.** 고객/트레이너 테스트 계정의 timed rehearsal(표본과 시작/종료 정의), 적응형 질문 최대 경로, KST 경계·누락·중복 KPI fixture, 브라우저 auth/Host/Origin/CSRF/replay/PII-log 검사, 장애별 expected state, 구체 회귀 suite와 합격 조건을 적으십시오.
7. **pre-mortem과 배포 계획을 확장하십시오.** 승인 후 전송 crash, 웹 인증 우회, 데이터 손실/복구, 두 소스 루트 version skew를 조기 신호·완화·rollback rehearsal과 함께 추가하고, profile package와 Hermes gateway의 배포 순서 및 활성화 전 호환성 gate를 정의하십시오.