## Verdict
**ITERATE**

검토 대상 Revision artifact:
- path: `/home/cube/projects/richard/traning coach/.gjc/_session-019f8455-334a-7000-99ca-318dfd0e06b1/plans/ralplan/019f8455-334a-7000-99ca-318dfd0e06b1/stage-03-revision.md`
- sha256: `46fa69c4b501d1f042b970e1e3f7116f14d9f32514dd8174cfc3896997e1c986` (ralplan `index.jsonl`의 revision stage_n 3 레코드와 일치함을 확인; 제한된 읽기 전용 검토에서는 digest를 별도 재계산하지 않음)
- stage_n: `3`

## Claim Checks
- **명세/큰 방향:** Deep Interview spec을 읽어 대조했습니다. 단일 외부 유료 고객, 12주 계획과 첫 4주 평일·주간 루프, 고객/트레이너 입력, Richard님 사람 승인, 내부 SSH/loopback 웹, 네 KPI의 논리곱, 자동전송·다중고객·공개 웹 보류가 유지됩니다.
- **Evidence:** 두 `/tmp/gjc-telegram-g4Whjx/...` attachment 경로가 현재 존재함을 확인했습니다. PDF는 읽어 평일 60–90초 체크인, 트레이너 30초 기록, 사람 승인, 보존/철회/provider 조건, 실제 결제·운영시간 근거를 확인했습니다. RTF는 도구가 형식을 지원하지 않아 내용과 두 attachment hash는 독립 검증하지 못했습니다. 다만 Phase 0의 private copy, 0600, hash mismatch launch block은 이전의 “입력 위치 미상” 결함을 실행 가능한 fail-closed gate로 닫습니다.
- **참조 파일:** 기존 profile 파일 `customer_coaching.py`, `customer_admin.py`, `customer_schedule.py`, `customer_reporting.py`, `customer_grounding.py`, `models.py`, `store.py`, `wizard.py`, `wizard_storage.py`와 profile tests, Hermes의 `nutrition_coaching.py`, `nutrition_coaching_config.py`, `telegram.py`, `physique_checkin.py`, `physique_checkin_prompts.py`, `hermes_cli/config.py`, `hermes_cli/web_server.py`, `web/src/App.tsx`, dashboard/gateway tests, `HANDOFF.md`, `choi_coach_system_report.html`의 존재를 확인했습니다. `capabilities.py`, activation/privacy/decision/delivery/worker/pilot 모듈, route/page/API/test, private traceability matrix, dashboard unit은 계획상 신규라 아직 존재하지 않는 것이 정상입니다.
- **Process topology:** Revision 3은 dashboard가 command/attempt만 기록하고 gateway worker만 live Bot client와 token을 보유하도록 분리했습니다. 기존 `telegram.py`가 profile-local `checkin_cli`를 적재하고 실제 send seam을 보유하는 구조와 맞습니다. `ambiguous`/reconciliation/resend authorization도 Telegram exactly-once를 과장하지 않습니다. 그러나 대표 race를 모의하면 dashboard와 owner Telegram이 같은 revision을 동시에 승인할 때 decision append, attempt append, claim create 중 어느 연산이 선형화 지점인지 정해져 있지 않습니다. “at most one nonterminal attempt”와 Sequence Acceptance는 결과만 명시할 뿐, cross-process lock/unique key/부분쓰기 복구 계약이 없습니다. 기존 `EventStore`는 `.events.lock` flock을 쓰지만 신규 queue/decision store가 그 lock을 공유하는지, queue file과 event append가 하나의 원자 경계인지 계획에 없습니다. 실행자가 안전 의미를 선택해야 합니다.
- **Owner auth:** 실제 loopback dashboard는 process-lifetime `_SESSION_TOKEN`을 SPA HTML에 주입하고 `X-Hermes-Session-Token`/legacy Bearer로 `/api`를 보호하며 Host 검사를 수행합니다. Revision 3은 존재하지 않는 OAuth `user_id`를 제거하고 이 capability에서 profile-bound, 30분 idle, HttpOnly/Strict console cookie를 발급하도록 고쳤으므로 방향은 실제 코드와 맞습니다. 다만 bearer는 독립 Richard identity가 아니라 loopback/SSH dashboard에 도달해 SPA를 받은 주체의 capability입니다. bootstrap endpoint/method, signing-key 소유 위치, idle 갱신/rotation, bearer 재사용 여부가 명시되지 않아 인증 구현과 replay 수용 범위를 아직 추측해야 합니다.
- **Config/lifecycle:** canonical flag와 loopback command, 별도 dashboard/gateway process를 명시한 점은 개선됐습니다. 하지만 실제 `cmd_dashboard`는 named profile launch를 machine dashboard(default profile/HERMES root)로 re-exec하고, 코드와 parser는 dashboard에 service manager/PID file이 없다고 명시합니다. 계획의 “configured profile package root”는 config key와 adapter 파일명이 없고, “supported installation path”로 dashboard unit을 만든다는 문구는 실제 installer와 연결되지 않습니다. 현재 문서는 수동 systemd `ExecStart` 예만 제공합니다. 따라서 machine dashboard가 정확히 어느 `physique-coach` data/package root를 열고 어떤 `HERMES_HOME`, interpreter, build artifact로 부팅되는지 확정되지 않았습니다.
- **Privacy:** revoked/delete_pending/deleted와 in-flight network limitation, retention/hold/backup fields, keyed tombstone digest, restore-before-start, completion receipt까지 상태가 닫혔습니다. 이전의 privacy lifecycle 결함은 구현·문서·테스트 범위로 충분히 확장됐습니다.
- **Verification/deploy:** mixed-version matrix, browser auth branches, queue-to-gateway integration, fault/restore rehearsal, rollout/rollback 순서는 좋아졌습니다. 하지만 실행 게이트가 여전히 `<new focused profile tests>`와 `<repo package manager>` placeholder이고 서비스 health는 `systemctl is-active`뿐입니다. 실제 metadata로 npm `test`/`build`, profile pytest root, Hermes tests를 지금 확정할 수 있는데 이를 Phase 0에 다시 맡겼습니다. worker/capability/queue health의 관찰 가능한 성공 조건과 dashboard unit install/uninstall/rollback command도 없습니다.
- **대표 privacy/rollback 경로:** delete_pending tombstone 후 restore가 service 시작 전에 purge manifest를 적용하고 worker가 모든 transition에서 tombstone을 재검증하도록 되어 있어 정책 선택 없이 구현 가능합니다. 다만 실제 서비스 start gate/health command가 위 lifecycle 공백 때문에 끝까지 연결되지 않습니다.

## Missing Evidence
### Definitely missing
1. 승인/attempt/claim의 **단일 선형화 계약**: lock 파일과 lock 범위, revision unique key, append 순서, file+directory fsync, dashboard/Telegram 동시 승인, crash between decision and attempt, orphan claim/attempt 복구 규칙이 없습니다.
2. dashboard의 **실제 profile/config adapter와 service lifecycle**: adapter 모듈명, machine-root에서 `physique-coach` root를 찾는 canonical config/path, package import collision 방지, exact unit generator/installer 또는 승인된 수동 unit 계약, `ExecStart`/`HERMES_HOME`/WorkingDirectory/UMask/build lifecycle, stop/update/rollback 규칙이 없습니다. 기존 Hermes에는 dashboard service installer가 없습니다.
3. **완전히 고정된 verification/deploy ledger**: placeholder 없는 focused/full 명령과 테스트 파일, dashboard unit install/enable/disable/remove 명령, capability/worker/queue health probe와 expected output, E2E/fault/backup-restore rehearsal 실행 방법이 없습니다.
4. console capability session의 **bootstrap/replay contract**: endpoint/method, bearer 검증 후 cookie 발급/갱신, signing key와 launch generation 저장 위치, restart/replay/idle-expiry expected states가 없습니다.

### Thin but possibly resolvable
- Revision 3의 ADR alternatives는 올바른 요구 충족/불충족 경계를 제시하지만 queue backend와 dashboard service 설치 대안의 운영 trade-off는 얕습니다.
- RTF 내용과 attachment digest는 이번 도구 범위에서 검증되지 않았습니다. Phase 0의 mandatory hash/copy gate가 이를 launch blocker로 다루므로 계획 결함은 아니지만, 실행 전 증거가 필요합니다.
- 기존 `EventStore._write_private`는 file replacement와 directory fsync를 보장하지 않습니다. privacy purge receipt와 queue commit이 어떤 신규 durability helper를 표준으로 삼는지 명시하면 병렬 구현이 갈라지는 것을 막을 수 있습니다.

## Approval Boundary
- 진행 가능: 두 attachment의 private copy/hash 검증과 traceability 초안, 실제 interpreter/npm/profile pytest 경로 기록, dashboard unit/adapter/queue linearization의 읽기 전용 설계 보강.
- 아직 승인되지 않음: product schema/queue/worker/dashboard/privacy/KPI 구현, systemd unit 생성·재시작, 토큰 회전, 테스트/실고객 메시지, 고객 활성화. 위 네 계약을 plan artifact에 확정하기 전에는 executor가 인증·내구성·서비스 소유권을 선택해야 합니다.

## Summary
- **Clarity:** 제품 경계와 각 phase는 명확하나 queue atomicity, console bootstrap, dashboard profile root가 불명확합니다.
- **Verifiability:** privacy/delivery fault expected states는 강해졌지만 command placeholder와 health probe 부재가 남았습니다.
- **Completeness:** 이전 evidence/privacy/callsite/schedule/KPI 결함은 대부분 닫혔고, process/service 접합부만 미완입니다.
- **Big Picture:** gateway sole sender와 machine dashboard command producer는 bot token 비노출·at-most-once driver에 맞습니다.
- **Principle/Option Consistency:** 사람 승인, fail-closed capability, append-only, no auto-retry가 일관됩니다. bearer는 identity가 아니라 reachability capability라는 표현을 끝까지 유지해야 합니다.
- **Alternatives Depth:** built-in route/plugin/sidecar와 direct-send/IPC 배제는 적절하나 lifecycle/queue 대안은 얕습니다.
- **Risk/Verification Rigor:** privacy/crash/rollback 위험은 구체적이지만 동시 승인 commit crash와 dashboard update/service restart 위험의 검증 절차가 아직 부족합니다.

## Required Changes
1. `customer_decisions.py`/`customer_delivery.py`/`customer_outbound_worker.py`가 공유하는 exact queue layout과 cross-process transaction을 적으십시오. 동일 revision 승인 race의 선형화 지점, lock/unique key, append/claim/fsync 순서, 각 crash point의 재시작 projection, orphan 처리와 Sequence Acceptance 테스트를 명시해야 합니다.
2. dashboard adapter와 lifecycle을 확정하십시오. adapter 파일명과 canonical profile-root/package-root resolution, machine dashboard의 `HERMES_HOME` 관계, config fields/defaults를 적고, installer가 없다면 승인된 unit 생성/검증/삭제 경로와 exact unit properties/ExecStart를 계획 범위에 넣으십시오. update가 stale dashboard를 종료하는 기존 동작과 systemd restart 정책도 연결하십시오.
3. console session bootstrap을 API contract로 적으십시오. route/method, launch bearer의 실제 의미, cookie/signing key/generation/CSRF 형식과 저장 위치, 30분 idle 갱신, restart/expired/replay expected states와 tests를 고정하십시오.
4. metadata 조사 결과를 계획에 반영해 placeholder 없는 verification/deploy 명령, focused test filenames, worker/capability/queue health probe, dashboard/gateway unit 설치·rollback, test-account E2E 및 backup-restore fault command/receipt 필드를 명시하십시오.