## Summary
Stage-27 revision SHA-256 `3e75bcc7e1cfc43c531de09d9c65cdb62a8837687d4c91f77af69b00ae1ee38d` is recorded for the reviewed immutable path in `index.jsonl`. The separate dormant test-bot process, isolated root/registry, marked-loader rejection, current-boot fencing, source-side bounded export, synthetic-only replay, and fixed promotion roots close the prior Stage-26 critic architecture requirements. However, the binding addendum makes only `diagnostic_prepare` reachable while retaining distinct activation/revalidation/close transitions without defining their authenticated callback paths; this leaves the state machine non-executable without an invented control path.

## Claims
- `index.jsonl` records the target stage-27 revision with the assigned SHA-256.
- Stage-27 lines 167-173 select a separate dormant diagnostic `TelegramAdapter` with test bot, isolated profile/config/token environment/route table, replacing hot attachment.
- Stage-27 lines 177-206 provides a private spec, current-process boot epoch, cross-root lock ordering, revalidation before append/reservation/provider work, and ordered attach/detach/recovery behavior.
- Stage-27 lines 209-239 moves future source evidence export to the source process, gives exact revision-fence tokens, uses existing validated readers, and permits only digest-verified synthetic import; it also fixes promotion roots and makes migrations deny-by-default.
- Stage-27 lines 241-264 names profile/gateway validation commands, affected gateway tests, row classes, and state reason expectations.

## Analysis
### Stage-26 critic requirement coverage
The binding addendum selects the previously missing process topology and prevents diagnostic attachment to the ordinary gateway. It preserves ordinary full-triple semantics while using a marked isolated registry accepted only through a session-bound diagnostic loader. It defines the dormant route/active three-role route boundary, boot epoch, recovery behavior, read-only revision fencing, explicit incident-source map, synthetic provenance, promotion allowlist, and concrete verification/row-delta matrix. These address the earlier blockers about enabled-only runtime visibility, private-DM containment, preflight versioning, restart recovery, non-mutating snapshots, replay sufficiency, and promotion scope.

### Remaining architecture defects
The control route says it exposes only `diagnostic_prepare`, yet the retained contract requires typed `diagnostic_activate`, `diagnostic_revalidate`, and `diagnostic_close`, and `DiagnosticHost` supplies activate/revalidate APIs. No state-scoped callback transitions, capability consume point, or control-route action table bridges them. The plan therefore cannot prove an active session can be reached, restart revalidation can be performed, or active diagnostics can be closed without an executor inventing privileged ingress behavior.

The closed config is limited to a relative spec path and authority-root path but requires validation against unspecified “allowed configured parent roots.” The trust anchor is neither a closed config field nor declared compiled/host-owned, so alternate-root rejection is not executable from the plan.

## Root Cause
The topology and persistence contracts are now specified, but the authenticated control-plane state machine and its root bootstrap trust anchor remain implicit. Both are admission boundaries and must be explicit rather than implementation choices.

## Findings
1. HIGH — `stage-27-revision.md:190` (reported P1): define persisted, typed Topic-59 callbacks for prepare, activate, revalidate, and close, including state preconditions and one-use capability mint/consume. The current single visible action conflicts with the retained lifecycle transitions.
2. MEDIUM — `stage-27-revision.md:177-188` (reported P2): make the allowed authority/isolated parent roots compiled/host-owned or independently owner-approved and digest-pinned; test alternate-root/spec substitution rejection before control-route registration.

## Recommendations
1. Amend the addendum with one explicit authenticated control-route action table: `diagnostic_prepare` creates prepared state; a state-bound `diagnostic_activate` callback consumes its capability; only restart-unvalidated sessions receive `diagnostic_revalidate`; active sessions receive `diagnostic_close`; all other callbacks reject with zero product/provider rows.
2. Define the host bootstrap trust anchor and isolated-root derivation outside the editable diagnostic config, require canonical distinct roots under it, and add startup negative tests.
3. Retain the selected separate-process topology and all existing source-side evidence, replay, and promotion constraints.

## Architectural Status
BLOCK

## Code Review Recommendation
REQUEST CHANGES

## Tradeoffs
- A single initial `diagnostic_prepare` menu plus explicitly state-bound persisted callbacks preserves the no-natural-language/no-ambient-ingress requirement while allowing the lifecycle to execute.
- An implicit prepare-to-activate transition is smaller, but would collapse distinct audit states and contradict the retained explicit action/capability contract.
- Compiled/owner-pinned parent roots add bootstrap configuration but prevent config-directed root substitution; a generic configured parent list does not define an authority boundary.