# Critic Review — Adaptive Nutrition Workflow, Planner Revision 12

Reviewed immutable planner artifact: `/home/cube/projects/richard/traning coach/.gjc/_session-019f8455-334a-7000-99ca-318dfd0e06b1/plans/ralplan/019f8455-334a-7000-99ca-318dfd0e06b1/stage-12-revision.md` (`d2b71c091965dc4edad5fa1f8f9d14b8ba4ce73578d3d78da390d382dee1a2e9`). No Architect output was consumed.

## Verdict
**ITERATE**

The chosen deterministic-policy/operator-approval direction is appropriate, but this is still an architecture synopsis rather than an executable plan. Numeric behavior, safety/config authority, doctrine precedence, lifecycle integration, migration compatibility, operator states, and exact verification remain under-specified. The unresolved items are load-bearing: executors would have to invent policy and persistence behavior.

## Claim Checks

- **Deterministic analytics plus operator approval fits the existing system.** Verified in `checkin_cli/models.py`, `store.py`, `customer_reporting.py`, `operator_console.py`, gateway `nutrition_coaching.py`, and gateway `telegram.py`: the system already has typed events, rebuildable views, owner-gated draft approval, a durable delivery ledger, receipt reconciliation, and customer-scoped transport. Reusing those boundaries is preferable to a parallel stack.
- **The proposed event lifecycle is not additive without explicit contract work.** The canonical contract at `/home/cube/.hermes/profiles/physique-coach/contracts/checkin-event.schema.json` and `checkin_cli/models.py::EventType` enumerate only the current event types and discriminator payloads. Adding `trend_snapshot_created`, `policy_decision_created`, `plan_proposed`, and the other listed events requires exact payload schemas, builders, dedupe keys, schema-version rules, readers, and tests. Old readers reject unknown event types, so appending them to the current stream also affects downgrade rollback.
- **The plan cannot currently satisfy “every revision reconstructable” by merely reusing the draft lifecycle.** `draft_dedupe_key(...)` is keyed by event type/customer/draft ID, the mutable `drafts.json` index stores only the latest text, and the coordinator currently permits editing only `created`/`edited` drafts. Existing tests assert an approved draft is not editable. Revision 12 instead says edits invalidate approval and adds `plan_edited`; it must specify a new revision identity/digest chain and the intended compatibility change rather than assuming current behavior already provides it.
- **Exact topic-59 routing exists as an optional gateway mechanism, not as a currently committed authority.** `telegram.py::_nutrition_operator_address` reads optional `nutrition_coaching.operator_review`; `_nutrition_operator_actor` falls back to the registry owner path when that block is absent. Tests cover `(8693203710,-1004290459350,59)`, but the active profile config read at `config.yaml` has `nutrition_coaching.enabled` and `registry_path` only. The plan’s “Only (...)” claim therefore needs an explicit config migration and a fail-closed rule that prevents fallback for adaptive-plan actions.
- **The stated operator lifecycle does not map to the current UI.** Current Telegram callbacks are `edit|approve|send`; there is no hold callback. The approved card exposes edit/send, while the coordinator rejects approved edits. Revision 12 specifies 수정/승인/보류, separate send, and edit-invalidates-approval but does not define state transitions, callback namespaces, stale-card behavior, or whether Telegram, the loopback console, or both are authoritative.
- **The current customer schema does not contain the proposed policy and meal inputs.** `CustomerProfile` has goal, restrictions, allergies, preferences, digestion, sleep/recovery/training context; `PlanWeek` has calories, protein, optional carbs/fat and free-text meal structure. It has no typed target-rate, calorie/protein/fat bounds, cooldown, carb-cycle spread, training-day assignment, budget, cooking access, meal count, training time, or catalog binding. A storage/config ownership and migration decision is required.
- **There is a definite doctrine conflict to resolve.** `SOUL.md` makes both public doctrines fixed runtime inputs, while `knowledge/nutrition-doctrine.md` explicitly excludes individualized calories, macros, meal frequency, protein amount, and meal plans. A separate `operator_approved_personal_nutrition_policy` can be valid, but the plan does not define precedence, prompt separation, provenance labels, approval/change control, or tests proving public doctrine is not represented as the source of personalized prescription.
- **The active-window rule conflicts with current pilot authority.** Existing transport and KPI logic use `starts_on` through `starts_on + 27 days`; Revision 12 gates only before plan start/after 12 weeks. It is unclear whether days 29–84 permit operator-only candidates, prohibit all adaptive work, or require a separately authorized post-pilot mode. Preserving the current flow requires an explicit answer.
- **The delivery premise is directionally correct but its acceptance wording is too strong.** Current code deliberately leaves an unknown provider result `pending` and forbids blind resend; a receipt can be reconciled without another transport call. “Exactly-once approved delivery” is not provable across an ambiguous external network result. Acceptance should separately require one authorized transport attempt per reservation, no automatic resend after an ambiguous result, explicit receipt reconciliation, and exactly one canonical sent audit.
- **Options are shallow and Option C is not consistently classified.** “Deterministic fixed templates” appears to be a fallback submode of chosen Option B for explanation/model outage, not an independent architecture. The plan does not compare status quo/observe-only, extending the current draft lifecycle versus creating a plan-specific lifecycle, or same-stream versus separate-stream persistence—the choices that determine migration cost and rollback safety.

Representative task simulations failed at the following points:

1. **Trend projector:** an executor cannot decide whether sample counts are events or distinct KST days, which same-day measurement wins, how partial corrections inherit fields, what to do with orphan/fork/cycle correction graphs, whether outliers are excluded or only flagged, how confidence is calculated, or which rounding mode makes serialization byte-stable.
2. **Numeric engine:** an executor has no exact function from observed rate/adherence to energy change, no unit/meaning for max change and cooldown, no policy for clamping or infeasible protein/fat/carbohydrate constraints, and no deterministic tie-breaker for reconciling rounded daily high/medium/low values to weekly totals.
3. **Operator lifecycle:** an executor cannot map `plan_proposed/edited/held/approved/effective` onto existing draft events and ledgers, cannot implement “edit invalidates approval” using current transitions, and cannot know when send becomes visible, what hold does, or how stale/replayed/concurrent topic-59 callbacks resolve.

## Missing Evidence

### Definitely missing

1. An implementation map naming the profile/gateway contract, domain, projector, coordinator, Telegram/operator-console, config, documentation, and test files to change, including whether new modules are justified.
2. Exact typed payloads, IDs, version/digest fields, dedupe rules, canonical serialization, authority rules, and persistence locations for snapshots, policy configs, proposals/revisions, effective plans, catalog rows, adherence and evaluations.
3. Exact definitions for window anchors, sample units, complete nutrition day, active-plan adherence/tolerance, confidence, anomaly/outlier handling, repeated digestion concern, eating risk, very-low recovery, implausible rate, and low-adherence cooldown behavior.
4. The numeric algorithm and a decision table covering maintain/observe/calorie candidate/macro candidate/human review, including priority when multiple gates fail and the rule for suppressing all numbers.
5. Concrete operator-approved configuration values or a firm execution boundary that excludes numeric candidate implementation until those values are approved. “Open intent items” cannot simultaneously be executor choices.
6. The meal catalog source/owner/path, versioning and approval process, serving-unit conversion, macro-source confidence, restriction/allergen matching, availability/budget/cooking semantics, substitution equivalence, rounding, and infeasible/no-match behavior.
7. Numeric-prose validation grammar: normalized token/unit handling, allowed non-nutrition numbers (date, D+, counts, percentages), ranges/decimals/Korean unit forms, derived values, Unicode/comma variants, and fail-closed behavior on parse uncertainty or prompt injection.
8. Doctrine precedence/change control and explicit approval to introduce a prescriptive private policy despite the current fixed doctrine’s exclusions.
9. Migration preflight/backfill/rebuild/checksum/idempotence/permissions, dual-read or cutover behavior, old-event compatibility, rollback executable compatibility, stale cards/outbox behavior, backup/restore, and corruption handling.
10. Exact operator states and recovery text for disabled config, missing inputs, hold, stale policy/catalog, edit/reapproval, approval, effective-plan activation, pending/unknown delivery, delivered-but-unaudited, revocation, and rollback.
11. Named test files/commands and golden fixtures that turn the broad test list into pass/fail release evidence; manual topic-59/test-account verification and documentation/runbook updates are also absent.
12. Data-governance handling for append-only personalized plans/adherence alongside consent withdrawal, retention, deletion, backup deletion, least-privilege file permissions, and PII-free metrics.

### Possibly unclear; must be resolved explicitly

- Whether the 12-week plan remains the sole effective source and adaptive plans are proposals layered over it, or whether `plan_effective` replaces a week of `CustomerSpec.plan`.
- Whether days 29–84 are operator-only shadow analysis or entirely out of scope under the four-week pilot.
- Whether Option C means a deterministic rationale template only or an alternate numeric plan generator.
- Whether topic 59 replaces the loopback console for this lifecycle or both surfaces must implement identical state and authorization semantics.

## Approval Boundary

The following direction is acceptable for the next revision: correction-aware deterministic projection; fail-closed typed policy; catalog-bound meal compilation; LLM explanation only after numeric validation; exact operator authorization; explicit approval and separate send; receipt-based no-resend recovery; disabled-by-default rollout.

No source execution is approved from this artifact. The planner must either (a) scope the executable phase to schema/projector/shadow infrastructure that can never emit numeric candidates, with numeric and delivery phases explicitly blocked on approved configuration, or (b) obtain and encode all open policy decisions now. Customer delivery, effective-plan activation, doctrine changes, and migration/cutover remain outside approval until the requirements below are added.

## Summary

- **Clarity:** Direction is clear; data semantics, state transitions, and ownership are not.
- **Verifiability:** Broad test categories exist, but exact fixtures, expected outputs, commands, and release gates are absent.
- **Completeness:** Missing load-bearing policy, schema, file-map, migration, operator-recovery, and governance details.
- **Big Picture:** Correctly preserves deterministic/operator-controlled intent, but conflicts with the current 28-day pilot boundary and fixed doctrine unless explicitly reconciled.
- **Principle/Option Consistency:** B is coherent; C is ambiguously a fallback inside B, and the edit/approval and exactly-once claims conflict with current semantics.
- **Alternatives Depth:** Insufficient for consensus; persistence and lifecycle alternatives are not compared.
- **Risk/Verification Rigor:** Premortem identifies three major risks but omits doctrine conflict, unsafe config, correction ambiguity, migration/downgrade incompatibility, stale callbacks, policy/catalog corruption, and privacy lifecycle.

## Required Changes

1. **Resolve scope and authority first.** State the effective-plan source, four-week versus twelve-week behavior, candidate/effective/delivery permissions by day, and whether execution stops at disabled shadow infrastructure until all open policy values are approved.
2. **Rewrite Options as actual alternatives.** Add status quo/observe-only; compare extending the existing draft/event/outbox lifecycle versus a plan-specific lifecycle; compare same event stream versus a versioned separate stream. Reclassify deterministic explanation templates as a B fallback unless they independently generate plans. Record why the chosen path wins on safety, rollback, and complexity.
3. **Add a file-and-symbol implementation map with staged exit criteria.** At minimum cover the canonical JSON schema, `models.py`, `store.py`, projector/reporting boundary, customer/config models, `nutrition_coaching.py`, `operator_console.py`, `telegram.py`, active config/template, profile doctrine/grounding only if authorized, runbooks/user docs, and both profile/gateway tests. Sequence contract/read compatibility before writers; projection before policy; policy before UI; migration preflight before any writer is enabled; shadow comparison before operator candidates; delivery last.
4. **Specify canonical data contracts.** Give field-level schemas, enums, units, bounds, optionality, version/effective dates, content digests, IDs/dedupe keys, revision links, provenance and storage authority. Define whether new events share `events.jsonl`; if so, make old/new reader and downgrade behavior explicit. Scope “byte-stable” to named derived payloads and define canonical serialization rather than event envelopes with timestamps.
5. **Provide an exact projection contract and gate table.** Define KST interval endpoints, event/day counting, same-day selection, cumulative/partial correction semantics, invalid graph behavior, missing-versus-zero, completeness, adherence tolerance, anomaly/outlier handling, confidence formula, rounding mode, gate precedence, typed reasons, and whether any failed safety/schema/correction gate suppresses every numeric field. Include boundary examples at 3/4 weight samples, 9/10 over 14 days, 4/5 complete nutrition days, cooldown edges, consent revocation, and day 28/29/84/85.
6. **Provide the full deterministic numeric specification.** Define rate and adherence calculations; candidate delta formula; clamp order; calorie/protein/fat/carbohydrate units and bounds; infeasible-input outcome; cooldown start/reset; one-change-at-a-time rule; daily/weekly rounding; high/medium/low assignment and deterministic remainder/tie-break distribution. Add a table of golden input → exact typed output cases, including all bounds and contradictory configurations.
7. **Define meal/catalog and explanation behavior.** Specify approved catalog lifecycle and exact compiler invariants, missing/no-match results, restriction/allergen fail-closed matching, serving conversion and reconciliation. Specify the LLM prompt contract and numeric-token validator grammar, and prove unknown/altered numbers, invented foods, overlength text, malformed output, and model outage all produce the deterministic fallback without changing proposal data.
8. **Resolve doctrine formally.** Define authority ordering among `SOUL.md`, public doctrine, the existing nutrition doctrine, operator policy and plan data; label all personalized numbers as operator-approved deterministic policy rather than public-doctrine claims; identify who approves policy versions; and add tests that excluded medical/extreme behaviors remain impossible. Do not silently override the existing explicit exclusions.
9. **Specify the complete operator state machine.** Map every new lifecycle event to current or new records; define revision IDs and how edits after approval append a revision and invalidate approval; define hold/release; effective-plan activation; callback namespaces; send-button visibility; stale/replayed/concurrent callback behavior; topic-59 fail-closed authorization with no owner-DM fallback; console parity; Telegram length/rendering constraints; and recovery instructions for every outbox state. Replace “exactly once delivery” with verifiable transport/reservation/audit guarantees.
10. **Expand migration, rollback, observability, and release verification.** Add preflight, backup, dry-run rebuild, source/target counts and digests, idempotent rerun, permissions, corruption refusal, feature/config cutover, stale card cancellation, and a rollback compatibility matrix. Name focused unit/integration/E2E/security tests and commands, synthetic 14-day golden fixtures, old-data regression fixtures, crash points around every ledger/event write, process/thread concurrency, wrong-topic/customer/actor negatives, no-PII assertions, shadow mismatch thresholds, manual test-account proof, and required updates to `PILOT_RUNBOOK.md`, the operator guide, handoff, and config template.