# Owner-Isolated Diagnostic Mode — Stage 27 Critic Review

Reviewed immutable revision `/home/cube/projects/richard/traning coach/.gjc/_session-019f8455-334a-7000-99ca-318dfd0e06b1/plans/ralplan/019f8455-334a-7000-99ca-318dfd0e06b1/stage-27-revision.md`. The RALPLAN index records that path as revision stage 27 with SHA-256 `3e75bcc7e1cfc43c531de09d9c65cdb62a8837687d4c91f77af69b00ae1ee38d`, matching the assignment. I also reviewed the Stage-26 Critic Required Changes at `/home/cube/projects/richard/traning coach/.gjc/_session-019f9ea8-2303-7000-9921-5dfccdd358f8/plans/ralplan/019f9ea8-2303-7000-9921-5dfccdd358f8/stage-26-critic.md`. Review was read-only; no tests, live Telegram actions, or deployment actions were run.

## Verdict
**ITERATE**

## Claim Checks

- **Most Stage-26 corrections are materially incorporated.** Addendum A chooses a separate dormant test-bot process and rejects hot attachment and a bespoke implementation; C assigns roots, lexical cross-root locking, final revalidation and a random per-process boot epoch; D assigns host state and startup/activation/detach/recovery/expiry/shutdown sequencing; F fixes root derivation and makes the v1 migration allowlist empty; G restores exact profile/gateway test and compile commands and row-class terminology; H removes the load-bearing shared-file conflict.
- **The topology choice fits current code.** Current `TelegramAdapter` owns one bot application, while `_get_nutrition_coaching()` builds one ordinary-root `NutritionCoachingCoordinator`. A distinct process/profile/config/token is a coherent way to achieve the required bot/root/process isolation without weakening ordinary identity rules.
- **The spec is substantially closed but its host binding is not fully executable.** Addendum B names the private spec file and its fields, makes capabilities path-free, and requires strict resolution/privacy/symlink/bot checks. However, the diagnostic config is said to contain only a spec path relative to the isolated root plus the authority root; it never explicitly identifies the existing adapter `profile_root` as the isolated root or otherwise supplies that root. “Allowed configured parent roots,” the canonical inputs excluded from `spec_digest`, the source of the separately approved production-bot digest, and its account-ID canonicalization are also not defined.
- **The dormant control-plane path still requires invention against current gateway interfaces.** `AdaptiveOperatorService.__init__` currently requires a coordinator and validates its customer/trainer routes. `TelegramAdapter._reserve_adaptive_review_update()` currently creates that service only after `_get_nutrition_coaching()` loads an ordinary committed registry and constructs a coordinator. The addendum says a dormant `DiagnosticHost` exposes Topic-59 before any child coordinator exists, but does not name the replacement constructor/interface that lets `AdaptiveOperatorService` authenticate and mint a bootstrap from `_verified_spec` plus authority without loading ordinary or diagnostic customer routes.
- **Runtime ownership is improved, but the adapter handoff is not closed.** Addendum D names `DiagnosticHost` fields/methods and good fail-closed ordering. The inspected `telegram.py` has no adapter route lock or dynamic add/remove role-route API; ordinary routing is discovered lazily through `_get_nutrition_coaching()` and coordinator maps. “Under adapter route lock” therefore names a new primitive without specifying its owner, lookup API, atomic install/remove method, or how the pre-existing Topic-59 control route remains one of exactly three active role routes. Executors would still have to design the concurrency boundary that Stage 26 requested.
- **Snapshot/replay is considerably stronger but not yet exact at the source boundary.** Addendum E correctly moves future evidence export into the source process, defines a one-use source capability, provides revision-token classes, names incident source domains, fixes mapping storage, and names `run_diagnostic_replay`. Yet A says the production gateway is “never modified,” while E explicitly adds `diagnostic_audit_export` to the source gateway; a production source is therefore modified with a bounded export route. The approval boundary must say so explicitly. The output directory is merely “already configured by the host,” but neither B’s closed config nor another named schema/API contains it.
- **The claimed exact per-incident source map remains broader than current persistence APIs.** `AdaptiveEventStore` owns a main path plus canonical events, source-day, source-intent, authority-mirror, config-epoch and overlay journals; “AdaptiveEventStore journals” does not select which path attributes and validated reader methods serve provider/audit/reservation incidents. `WizardStorage` stores mutable draft JSON files in a directory, not a wizard JSONL ledger. The directory-manifest token can cover them, but the plan must name the draft-selection API/lock and exact named files. Without that, two executors can choose different evidence sets and still claim conformance.
- **Promotion root derivation is representative and compatible with the repository.** `Path(checkin_cli.__file__).resolve().parent.parent` resolves to the profile package workspace, and walking from `gateway.platforms.nutrition_coaching.__file__` can reach a root containing both `gateway/` and `tests/gateway/`. The plan should still locate and define the “promotion policy” that stores the expected repository identity so this check is not caller-selected.
- **Verification is not fully self-contained.** The profile full/compile and gateway focused/full/compile commands are exact, and all named existing test files were verified. “Docs/hash/link tests and `/tmp` API/algorithm test report are mandatory” gives neither a command nor the report producer/name/assertions. Stage 26 expressly required exact docs/link commands. G also gives expected reason codes by session state but not the expected boolean/value matrix for the exact `checks`, despite Stage 26 requesting reason/check values.
- **Referenced files were checked.** Existing profile modules `customer_admin.py`, `customer_coaching.py`, `models.py`, `store.py`, `wizard.py`, `wizard_storage.py`, `adaptive_nutrition.py`, `customer_schedule.py`, `__init__.py`, the named profile tests and canonical profile `PILOT_RUNBOOK.md` exist. Gateway `nutrition_coaching_config.py`, `nutrition_coaching.py`, `telegram.py` and all four named gateway tests exist. Root `PILOT_RUNBOOK.md`, `HANDOFF.md`, `듀얼코치_사용설명서.md`, and `choi_coach_system_report.html` exist. New `diagnostic_isolation.py`, `diagnostic_evidence.py`, and `test_diagnostic_isolation.py` do not yet exist, as expected for planned additions.

### Representative implementation simulation

1. **Dormant startup and prepare:** `DiagnosticHost` can verify a spec and bot in principle, but current Telegram control ingress cannot construct `AdaptiveOperatorService` without first obtaining an ordinary coordinator. The plan does not say whether the service gains a `DiagnosticAuthority`/host constructor, a separate diagnostic control service is introduced, or the host itself implements session issuance. That is a load-bearing unresolved API choice.
2. **Activate, detach, expire and restart:** profile activation/recovery transactions and host ordering are actionable. Atomic route installation/removal is not: current adapter has no described route registry/lock, and the plan does not define whether the dormant operator route is retained while only customer/trainer routes are installed or all three entries are swapped. Crash/race tests cannot be written against a named method until this interface is fixed.
3. **Export and replay:** a source capability can bind one customer and the revision-token strategy can detect concurrent changes. Implementation still has to invent the configured artifact root, the output transaction, which `AdaptiveEventStore` paths/readers apply to each delivery incident, and the exact draft files/read lock for incomplete/KST incidents. It also must decide whether modifying a production source gateway is approved despite A’s prohibition.

## Missing Evidence

Definitely missing:

1. The exact binding from the distinct process’s existing adapter/profile configuration to `isolated_profile_root`, the allowed-parent policy, spec/bot digest canonicalization, and the authoritative source for `production_bot_account_digest`.
2. A named dormant control-plane constructor/API that works before any child coordinator or diagnostic registry is loaded.
3. A concrete `TelegramAdapter` route registry/lock/install/remove/lookup contract and exact accounting of the persistent Topic-59 route versus the three active role routes.
4. Reconciliation of “production gateway is never modified” with the required source-side audit-export action, plus the closed source artifact-root config and atomic output/one-use consumption path.
5. Exact per-incident path attributes, validated reader methods and locks for mutable wizard drafts and the multiple adaptive/delivery journals.
6. Exact docs/hash/link and `/tmp` report commands, and the expected diagnostic preflight `checks` values by prepared/active/prior-boot/expired/terminal/corrupt state.

Possibly unclear rather than definitely wrong: whether the spec field itself is intended to be the separately approved production-bot digest, and whether “diagnostic config” implicitly includes the ordinary adapter’s existing `profile_root`. Both should be made explicit rather than left to executor interpretation.

## Approval Boundary

The separate dormant test-bot process, marked isolated registry, two-root lock order, random boot fencing, host lifecycle ordering, source-process export principle, revision fencing, synthetic replay, fixed promotion roots, empty migration allowlist, exact main test commands, and sequenced ownership are suitable foundations for the next revision. Product implementation is not approved until the dormant ingress/adapter route API, source-export production boundary, exact evidence paths and remaining verification contracts above are closed. No live Telegram, credential handling, manual P2→P6, real-customer action, or deployment is approved.

## Summary

- **Clarity:** Stronger topology and ownership; dormant ingress, route mutation and source export still ambiguous.
- **Verifiability:** Main test commands and row classes are exact; docs/report commands, route APIs and preflight check values are not.
- **Completeness:** Stage-26 items 2, 3, 7 and most of 1, 4, 5, 6 are closed; load-bearing executable edges remain.
- **Big Picture:** Separate-process isolation is sound, but source export necessarily adds a narrowly bounded production/source feature and must be acknowledged.
- **Principle/Option Consistency:** No-config-only activation and synthetic-only replay remain consistent; “production never modified” conflicts with source-side export.
- **Alternatives Depth:** Separate process, hot attach and bespoke implementation are now compared adequately.
- **Risk/Verification Rigor:** Crash and authority checks are strong; route concurrency and evidence-source selection remain under-specified.

## Required Changes

1. **Finish bootstrap host binding.** State that the diagnostic process’s canonical configured `profile_root` is the isolated root (or add an exact closed field), enumerate allowed parents, define `spec_digest`/`authority_digest`/bot digest canonical inputs, and name the canonical production-bot digest source. Add the exact dormant control-plane constructor and mint/consume method flow that does not require an ordinary coordinator or enabled registry.
2. **Define adapter route mutation.** Name the new adapter-owned async lock and exact install/remove/lookup methods; specify whether Topic-59 is retained and only customer/trainer routes are added, how exactly-three route counting works, and how every ingress consults the host/session under that lock. Include install/remove versus expiry/stop race tests.
3. **Close source export.** Replace the absolute “production gateway never modified” claim with the precise boundary: no diagnostic customer/provider routes or isolated-root attachment, but one bounded authenticated audit-export action is added to a source gateway. Add the closed artifact-root config, containment/mode/symlink checks, atomic no-output-on-failure transaction and one-use capability ledger.
4. **Make evidence selection exact.** For every incident class, enumerate concrete path attributes/files, validated read methods and locks, including selected wizard draft filenames and the exact `AdaptiveEventStore` journal(s). Bind each to the stated before/after token and retry behavior.
5. **Complete verification exactness.** Give executable cwd/interpreter/test commands for docs/hash/link assertions and the `/tmp` API/algorithm report, including its producer, fixed filename and required assertions. Add the expected `checks` truth/value matrix for each session state and include any new gateway sibling module in compile commands.
6. **Locate promotion identity policy.** Name its repository-relative code/policy location and exact identity comparison so the expected Hermes root cannot be caller-supplied or silently learned from the candidate root.