## Verdict
**ITERATE**

Reviewed revision (immutable assignment binding): `/home/cube/projects/richard/traning coach/.gjc/_session-019f8523-2088-7000-84b9-de6e6ccef8fd/plans/ralplan/019f8523-2088-7000-84b9-de6e6ccef8fd/stage-09-revision.md`, SHA `f77047e8e91ce63d217be0da719a10aee52cc0922cfbd0eee40d7cf9a916ef4f`.

Source spec: `/home/cube/projects/richard/traning coach/.gjc/_session-019f8455-334a-7000-99ca-318dfd0e06b1/specs/deep-interview-dual-coach-single-customer-pilot.md`.

## Claim Checks
- **Scope reconciliation is mostly correct.** The plan preserves one external paying customer, KRW 150,000 bank transfer, an up-front 12-week plan, first-four-week daily/weekly operation, Telegram plus a private Richard-only web surface, human approval, the four-way KPI conjunction, and the named deferrals. It does not demand the prohibited generic platform work.
- **Referenced implementation files were checked.** All listed existing Python owners exist under the profile-local `checkin_cli` package and Hermes gateway. `checkin_cli/operator_console.py` is correctly new. The docs entry is not path-specific. A material existing contract file, `/home/cube/.hermes/profiles/physique-coach/contracts/checkin-event.schema.json`, exists but is absent from the owner map.
- **Representative task 1 — activation gate fails against current code.** `customer_admin.set_customer_enabled()` currently changes `enabled` directly; it does not require granted consent or verify the data root/safety prerequisites. `CustomerSpec` permits `enabled=True` with default ungranted consent. Therefore the plan's instruction to “keep add/consent/enable gating” is factually wrong, and AC1 is not actionable without an explicit new enable guard and its inputs.
- **Representative task 2 — canonical pilot event implementation is incomplete.** `models.Event` currently has only `check_in`, `safety`, and `payload_ref`; it has no field that can hold the proposed frozen typed pilot payloads. The canonical JSON schema has `additionalProperties: false`, excludes every proposed pilot event type from its enum, and has no typed pilot payload property. Because the handoff says executors may touch only named files, the proposed schema-conformant events cannot be implemented as written while retaining canonical-contract verification.
- **Representative task 3 — schedule/KPI boundary has an undefined state owner.** `customer_schedule.build_due_customer_tasks()` currently derives daily/weekly/monthly tasks from the registry. The revision adds a customer-admin `extend` command and an operator-set extension date, but names neither a registry field nor an event type/payload that stores that date. The explicit new event list has no extension/schedule event. The schedule projection and KPI denominator therefore require invention. Moreover, re-enabling automation after day 28 is outside this assignment's four-week approval boundary; renewal can be recorded without extending automation.
- **Downstream safety holding is described, but trigger creation is not.** Current `wizard.py` creates `safety_signals` only from a narrow urgent-symptom regex (chest pain/fainting/dyspnea). `customer_grounding.py` merely consumes already-populated snapshot signals. The plan lists pain/disorder/eating-risk/drug/extreme-manipulation categories and tests only the downstream “signal present” predicate; it does not define how actual customer or trainer answers become those signals. Injecting a prebuilt signal in a grounding unit test would not prove safe pilot behavior.

## Missing Evidence
- **Definitely missing:** an explicit implementation owner and contract for activation gating; current code has none.
- **Definitely missing:** the canonical JSON schema change or another fully specified typed payload representation compatible with that schema.
- **Definitely missing:** storage semantics for the proposed extension date; the bounded alternative is to remove extension entirely.
- **Definitely missing safety evidence:** input-level tests proving each required safety class in customer and trainer submissions creates a hold, preserves the reason, notifies Richard, and produces zero customer sends.
- **Thin user-visible acceptance:** “normal,” sleep/condition/performance “anomaly,” and “change/problem day” lack deterministic trigger fixtures. AC3/AC4/AC10 cannot be reproduced consistently until the rule table is stated.

## Approval Boundary
No real-customer activation or implementation execution is approved from this revision. A revised plan may proceed once it fixes the bounded event contract, enable gate, four-week schedule state, and input-to-safety behavior. Generic auth/systemd/deployment/browser/concurrency redesign and any post-day-28 automation remain outside approval.

## Summary
- **Clarity:** Strong at product scope and human-approval boundaries; incomplete at event payload/state ownership and branch rules.
- **Verifiability:** Strong stopwatch, HTTP, authorization, KPI-boundary, and downstream draft-gate checks; weak at activation enforcement and actual safety-trigger creation.
- **Completeness:** Missing required canonical contract and enable-gate work; extension state is undefined.
- **Big Picture:** Fits the single-customer pilot except for the unnecessary post-day-28 extension feature.
- **Principle/Option Consistency:** Human approval and isolation are consistent; “schema-conformant typed events” conflicts with the omitted schema and current `Event` shape.
- **Alternatives Depth:** Adequate and bounded; no platform redesign is needed.
- **Risk/Verification Rigor:** Good for routing, loopback access, KPI arithmetic, and downstream holds; insufficient for real input safety classification and activation bypass prevention.

## Required Changes
1. In `customer_admin.py`/`customer_coaching.py`, replace the inaccurate “keep enable gating” wording with an explicit guard: define the profile-root/data-root input, require a valid 12-week plan, granted/versioned consent, valid isolated customer/trainer/owner Telegram boundaries, and required pre-activation checklist evidence before writing `enabled=true`; add bypass/failure tests for every required condition.
2. Specify where each typed pilot payload lives on `Event`, add the canonical contract schema to the owner map, update its event-type enum and discriminated payload rules, and verify every new pilot event against it. Alternatively, explicitly define a typed `payload_ref` sidecar format and owner, but do not leave executors to invent storage. Require a non-null deterministic `dedupe_key` for each new append.
3. Remove the `extend` command/date and “extension re-enables” behavior from this four-week MVP. Make day 28 a hard automation stop while allowing a manual renewal event/KPI judgement. Define the scheduled check-in denominator as the exact eligible weekday dates in the fixed KST window so reporting does not reuse the current all-calendar-day denominator.
4. Add a bounded safety rule table for customer and trainer inputs covering pain, disease, eating risk, drugs, and extreme manipulation. Name where classification occurs and add end-to-end fixtures from real input through stored signal/reason, draft hold, Richard notification, referral guidance, and zero customer send.
5. State deterministic normal/anomaly/change fixtures and their exact related follow-ups/short-vs-detailed outcome so AC3, AC4, and AC10 can be implemented without choosing thresholds ad hoc.