## Summary
Revision 6 closes the runtime bearer, universal API-bearer middleware, explicit pytest selection, and mandatory Python Playwright availability contracts with concrete, fail-closed mechanisms. It does not yet supply an executable safe path for a Telegram send or a trustworthy source for Telegram collision checks; two HIGH findings block approval. The idle-expiry browser assertion also lacks the concrete test-only control needed to make its requirement deterministic.

## Claims
- Reviewed only `stage-06-revision.md` at the assignment-provided SHA `e86862488aabfafec71e8ee46303296e242f3af0409ab7ffbd697294939983cd`.
- The runtime bearer contract is specific: a named user unit owns a `0700` runtime directory; prepare/launch/probe/cleanup all validate type, owner, and mode; the launcher injects the exact rotated token; the probe sends it on bootstrap and health (Locked Runtime Bearer Contract; File-Level Changes).
- The plan keeps the launch-token middleware on every `/api` route, including bootstrap and health, and rejects a console-session bypass (Locked Runtime Bearer Contract item 7; Acceptance Criterion 4).
- Normal pytest commands explicitly exclude `integration` and `e2e`; external gates use explicit `-m e2e`; global marker selection is removed (File-Level Changes; Acceptance Criterion 7; Verification).
- The browser gate mandates Python Playwright, locked dependency graph, Chromium availability/startup, an owned isolated child, and non-skip failure semantics (Python Playwright Browser Gate).
- Telegram credentials use three dedicated names and fail closed for absent/malformed values, allowlist mismatch, target/token collision, active real registry, or non-test-only target (Telegram E2E Contract).

## Analysis
### Stage 1 — Spec compliance
The revision materially resolves the launch-token ambiguity: the service and probe share one per-start file-backed token, the API bearer gate remains universal, and secret-bearing outputs are redacted. The rollout state cleanly separates readiness from real activation for the live probe, and explicit marker selection closes the inherited `addopts` deselection problem.

However, the plan requires Telegram E2E to be able to contact a dedicated test target, while Step 4 runs that E2E before Step 5 and the locked state leaves both the global outbound flag false and the test registry inactive until Step 5. No test-only dispatch capability, override, or post-preflight send transition is defined. This is a direct sequencing/flag contradiction rather than a safe default.

The credential preflight is fail-closed only relative to whatever `HERMES_HOME` the invocation supplies. The plan never binds its Telegram command or activation sequence to the authoritative production/customer registry root. Because the browser contract itself uses a temporary `HERMES_HOME`, a test/empty root is a plausible input that makes production-target and token collision checks vacuous before the external call.

### Stage 2 — Architecture
The unit-scoped runtime token boundary is appropriately narrow: named-unit lifecycle avoids global termination, and exact metadata validation prevents unsafe runtime file substitution. Requiring bearer on both bootstrap and health avoids a privileged health exception. The browser child lifecycle likewise avoids impacting unrelated services.

The external-delivery boundary has no equivalently authoritative state transition. A receipt can record a state only after an implementer has chosen how to bypass or alter the global gate; it cannot make that choice safe. Collision checks also must read a specified canonical registry, not an arbitrary caller-selected profile root.

### Stage 3 — Constructive synthesis
Use one explicit test-send state machine: preflight against a named, immutable canonical registry source; enable an independently named, allowlist-constrained test-target capability only after preflight; send exactly to the allowlisted pair; capture the test receipt; revoke that capability and deactivate the test target. Keep `gateway.physique_coach_outbound_enabled=false` for all non-test targets throughout. Alternatively make the current E2E entirely pre-send and move the real test send into Step 5, with the same scoped capability and receipt requirements. The former gives stronger end-to-end coverage; the latter minimizes deployment-state changes but leaves E2E without an external-send assertion.

For browser expiry, define a named setting accepted only by `--isolated` mode (or inject a deterministic clock), set it to a concrete short duration in the child environment, and make normal service startup reject the setting. This permits fast deterministic expiry testing without changing production session policy.

### Stage 4 — Quality, security, and performance
No additional material concerns were found in this plan-only review. The explicit redaction, no-symlink validation, exact permissions, named service lifecycle, and hard browser availability failure are appropriate security and operational constraints.

## Root Cause
The plan locks security predicates but leaves two safety-critical authorities unspecified: which registry source is authoritative for Telegram collision detection, and which precisely scoped capability can authorize a test-target send while the global outbound gate remains false. The browser expiry test similarly declares a required state without defining how its isolated server reaches it.

## Findings
- **HIGH — stage-06-revision.md:68-80:** Telegram E2E precedes activation while outbound is false and the test target remains inactive. Define the test-only send transition, scope, revocation, and receipt evidence, or make Step 4 pre-send-only and move the controlled send after activation.
- **HIGH — stage-06-revision.md:99-105:** `HERMES_HOME` for collision preflight is unbound, so a temporary/test root can bypass comparison with customer targets and tokens. Require a specific authoritative, read-only registry source; reject temporary/test roots; record its nonsecret identity.
- **MEDIUM — stage-06-revision.md:86-94:** The mandatory idle-expiry assertion has no named setting, value, fixture injection, or deterministic clock. Specify an isolated-only control and concrete duration, and reject it for normal service startup.

## Recommendations
1. Resolve the test-send state machine before implementation; it is a release-blocking specification issue.
2. Bind Telegram preflight to the canonical production/customer registry source and show that identity in the test receipt without exposing credentials.
3. Lock the browser fixture's session-expiry mechanism and duration.
4. Retain the already strong unit/token, universal middleware, test selection, and hard browser-preflight contracts unchanged.

## Architectural Status
BLOCK

## Code Review Recommendation
REQUEST CHANGES

## Tradeoffs
| Option | Benefit | Cost | Recommendation |
|---|---|---|---|
| Scoped test-target capability after preflight | Preserves an actual external E2E send while keeping global/customer delivery disabled | Requires an explicit temporary capability and revocation | Preferred |
| Pre-send-only E2E, controlled send in Step 5 | Fewer active delivery transitions | The E2E gate itself does not prove external send behavior | Acceptable only if Step 5 gets an equally strict executable send contract |
| Caller-selected `HERMES_HOME` | Simple invocation | Collision checks can be vacuous | Reject |
| Named immutable canonical registry source | Meaningful production collision guard | Requires a controlled configuration input | Required |