## Verdict
**ITERATE**

## Claim Checks
- 검토 대상은 `/home/cube/projects/richard/traning coach/.gjc/_session-019f8455-334a-7000-99ca-318dfd0e06b1/plans/ralplan/019f8455-334a-7000-99ca-318dfd0e06b1/stage-04-revision.md`, stage_n `4`입니다. 동일 ralplan의 `index.jsonl`에 기록된 path와 sha256 `433ec13cb3d3acff244abf2ea38da70c11db8acfd7d15310826f0c896b94d9b6`가 assignment contract와 일치합니다.
- 이전 ITERATE의 핵심 안전 계약 네 가지는 대부분 실행 가능한 형태로 닫혔습니다. `commands.jsonl` 한 레코드에 approval과 최초 attempt를 묶고 `commands.lock`/`flock`, duplicate projection 검사, temp-file fsync, atomic rename, directory fsync를 선형화 경계로 지정했습니다. 웹/owner Telegram 동시 승인을 모의하면 한 프로세스만 command를 commit하고 gateway만 O_EXCL claim을 만들므로 실행자가 queue 원자성을 새로 선택할 필요가 없습니다.
- 전송 경계도 닫혔습니다. 최종문을 renderer 이후 4096 UTF-16 code-unit 이하로 domain service가 재검증하고 generic chunk helper를 우회하여 attempt당 Bot API send 1회/message_id 1개로 제한합니다. 이는 현재 `gateway/platforms/telegram.py`의 generic send가 4096 초과를 여러 chunk로 보내는 실제 동작과 충돌하지 않도록 전용 customer sender seam을 요구하며, 4095/4096/4097·escape·surrogate·timeout/crash acceptance가 구체적입니다.
- capability 계약도 닫혔습니다. `data/schema-capabilities.json`, owner module, schema, lock, fsync/rename 순서, incompatible write 전 manifest advance, event별 generation/min-reader, missing/corrupt fail-close, crash/rollback matrix가 있어 mixed deployment를 구현자가 추측할 필요가 없습니다.
- console bootstrap도 닫혔습니다. 실제 loopback launch bearer를 개인 OAuth identity가 아닌 launch capability로 유지하면서 exact bootstrap endpoint, Host/Origin/profile/flag gate, process-memory generation/signing key, profile-bound cookie/CSRF, 30분 idle, restart/replay 상태를 정의했습니다. 기존 `hermes_cli/web_server.py`의 loopback `X-Hermes-Session-Token` seam과 일치합니다.
- adapter/unit/config의 기존 참조는 확인했습니다. `hermes_cli/config.py`, `hermes_cli/web_server.py`, `hermes_cli/main.py`, `hermes_cli/subcommands/dashboard.py`, profile/gateway 코드와 현재 `physique-coach-gateway.service`가 존재합니다. `dashboard --isolated --host/--port/--no-open/--skip-build` 옵션도 실제 parser에 존재하며 제안 unit의 HERMES_HOME/HERMES_PROFILE/venv 경계는 현재 profile gateway unit 관례와 맞습니다. 신규 adapter/routes/tests/dashboard unit은 실행 중 생성 대상으로 명시되어 아직 없는 것이 정상입니다.
- 대표 dashboard 배포 경로에서는 한 가지 확정 오류가 발견됩니다. Revision 4는 frontend artifact를 `/home/cube/projects/richard/hermes-agent/web/dist`라고 선언하지만 실제 `web/vite.config.ts`의 `outDir`은 `../hermes_cli/web_dist`이고 `hermes_cli/main.py::_web_ui_build_needed` 및 `cmd_dashboard --skip-build`도 `/home/cube/projects/richard/hermes-agent/hermes_cli/web_dist/index.html`만 검사합니다. 계획대로 `npm --workspace web run build`를 실행해도 `web/dist`는 만들어지지 않으므로 lifecycle의 exact artifact 계약은 사실과 다릅니다.
- verification ledger는 focused/full npm·pytest 명령을 실경로로 고정해 크게 개선됐지만 완전히 닫히지는 않았습니다. Health/rollout 절의 E2E, fault, backup/restore 명령은 다시 일반 `python`을 사용하고 cwd를 고정하지 않았으며, live `/api/physique-coach/health`는 schema/pass predicate만 있고 인증된 실행 명령 또는 전용 probe script가 없습니다. 따라서 stage-03의 “placeholder 없는 test-account/fault/restore command와 worker/capability/queue health probe” 요구가 일부 남습니다. `systemctl is-active`만으로는 worker heartbeat, manifest/profile match, registry load, stale sending 부재를 검증할 수 없습니다.

## Missing Evidence
### Definitely missing
1. 정확한 frontend build artifact 경로가 틀렸습니다. 실행 계약은 `hermes_cli/web_dist`로 수정하고 build 후 `index.html`/manifest 확인 및 `--skip-build` start gate와 연결해야 합니다.
2. live health의 재현 가능한 호출 방법이 없습니다. launch bearer를 노출하지 않으면서 실제 dashboard process의 `/api/physique-coach/health`를 호출하고 profile/capability/registry/heartbeat/queue predicate를 판정하는 전용 probe command 또는 test script가 필요합니다.
3. E2E/fault/backup-restore rehearsal 명령이 exact ledger의 절대 interpreter/cwd 규칙을 따르지 않습니다. 알려진 venv interpreter와 각 repo cwd로 고정해야 receipt를 재현할 수 있습니다.

### Thin but resolvable
- `dashboard.physique_coach_profile_root`를 config owner로 선언하면서 adapter는 profile root를 오직 `HERMES_HOME`에서 resolve한다고 했습니다. 해당 config field를 제거하거나, expected-root allowlist로 사용해 `HERMES_HOME`과 일치 검증한다는 역할을 한 문장으로 명시하면 됩니다.

## Approval Boundary
- 진행 가능: plan-only 수정, source/evidence hash 보존, 신규 파일 생성 전 read-only inventory.
- 아직 승인되지 않음: product/schema/dashboard/worker 구현, systemd unit 생성·서비스 재시작, token rotation, Telegram E2E, 고객 활성화. 잘못된 artifact 경로와 미완 live probe/command를 고친 동일 plan artifact가 필요합니다.

## Summary
- **Clarity:** 핵심 transaction/session/manifest/send 계약은 명확합니다. build artifact 한 곳과 profile-root config 역할이 어긋납니다.
- **Verifiability:** boundary/fault tests는 강하지만 live health와 세 rehearsal 명령이 완전히 재현 가능하지 않습니다.
- **Completeness:** 이전 안전 공백 대부분은 닫혔고 deployment verification 접합부만 남았습니다.
- **Big Picture:** gateway-only sender, derived queue, one-message delivery, isolated profile dashboard는 단일 고객·사람 승인·실패 가시성 driver와 맞습니다.
- **Principle/Option Consistency:** append-only/fail-closed/no-auto-retry 원칙은 일관됩니다. profile-root source만 중복 소유처럼 보입니다.
- **Alternatives Depth:** 기존 ADR은 요구를 만족하는 선택과 기각 이유를 충분히 설명합니다.
- **Risk/Verification Rigor:** crash/version/replay/restore risk는 구체적이나 실제 rollout health invocation이 빠졌습니다.

## Required Changes
1. frontend artifact를 실제 `/home/cube/projects/richard/hermes-agent/hermes_cli/web_dist`로 고치고 build-success 및 `--skip-build` precondition을 그 경로에 묶으십시오.
2. `/api/physique-coach/health`를 live service에서 안전하게 호출하는 exact probe command/script, cwd, interpreter, expected exit/status를 추가하십시오. `systemctl is-active`와 함께 두 probe 모두 rollout gate가 되어야 합니다.
3. E2E/fault/backup-restore 세 명령을 `/home/cube/projects/richard/hermes-agent/venv/bin/python`과 명시 cwd로 고정하고 receipt에 남기는 정확한 순서를 적으십시오.
4. `dashboard.physique_coach_profile_root`가 `HERMES_HOME`의 expected-value 검증인지 제거 대상인지 하나로 정하십시오.