## Summary

Revision 5 correctly repairs the prior HTTP cookie, dashboard ownership, frontend artifact, profile-root, and real-E2E planning defects. It does not define how the running dashboard's launch bearer becomes available to the new live probe, so the mandatory rollout gate cannot execute under the stated service contract. Keep this as **BLOCK / REQUEST CHANGES** until that handoff and the E2E selection policy are exact.

## Claims

- The reviewed artifact is indexed as `stage-05-revision.md`, stage 5, SHA `c1604876d6557b18759cfb6bf3d66d369a6da3fdbfa07ad63b99b6061663bb6c` (`plans/ralplan/.../index.jsonl`).
- Revision 5 changes the HTTP loopback cookie to a bare name with `HttpOnly`, `SameSite=Strict`, `Path=/`, no `Domain`, and a real-browser persistence/rotation/expiry/replay test (`stage-05-revision.md:5-11`). This closes Revision 4's impossible `__Host-`-over-HTTP contract.
- The existing dashboard parser supports `--isolated` (`hermes_cli/subcommands/dashboard.py:48-58`), while `hermes dashboard --stop` scans and terminates all dashboard processes (`hermes_cli/main.py:10848-10867`). Revision 5's unit-only lifecycle and no-global-stop rule (`stage-05-revision.md:13-18`) therefore closes the verified isolation violation.
- Vite writes to `../hermes_cli/web_dist` (`web/vite.config.ts:76-80`), and `cmd_dashboard --skip-build` validates `hermes_cli/web_dist/index.html` (`hermes_cli/main.py:10982-10999`). Revision 5's corrected build/restart precheck (`stage-05-revision.md:20-30`) now matches runtime behavior.
- The current pytest configuration registers only `integration` and globally applies `-m 'not integration'` (`pyproject.toml:348-355`). Revision 5 appropriately requires a new `e2e` marker and non-default selection, but does not settle a command-compatible exclusion policy (`stage-05-revision.md:32-34`).
- `HERMES_HOME` is Hermes' profile isolation root (`hermes-agent/AGENTS.md:1130-1141`); the addendum's canonicalize-and-equality rule (`stage-05-revision.md:36-38`) removes the conflicting config-root ownership.
- Today the dashboard adopts `HERMES_DASHBOARD_SESSION_TOKEN` only if supplied; otherwise it generates `_SESSION_TOKEN` in process memory (`hermes_cli/web_server.py:210-218`). The Revision 4 proposed dashboard unit has no token environment/file handoff (`stage-04-revision.md:39-46`).

## Analysis

### Stage 1 — Spec compliance

The addendum preserves the single-customer, human-approval, gateway-only send, fail-closed capability, and loopback-only console decisions in Revision 4. Its cookie, process ownership, artifact, E2E, and root corrections are direct fixes for the last Revision 4 findings rather than scope expansion.

The safe probe is now required for rollout, but its prerequisite bearer is neither supplied by the proposed unit nor emitted by the current server. A probe cannot bootstrap without that value, and obtaining it from the rendered SPA would violate the addendum's private operational-token boundary. Consequently a healthy deployed service cannot meet the required gate reproducibly.

### Stage 2 — Architecture

The launch bearer is a process-lifetime capability, so its producer, storage owner, consumer, permissions, rotation, and cleanup are part of the dashboard lifecycle boundary—not implementation detail. `web_server.py` currently makes the value process-local when no environment seed exists. Merely adding a probe script creates a second component that needs a trustworthy capability source, yet Revision 5 leaves that source as an unimplemented alternative.

The E2E correction has the same, smaller planning issue. If `not e2e` is added to global `addopts`, the recorded explicit command `pytest ... -m e2e` inherits that exclusion and selects no tests unless it clears/overrides `addopts`. If default suite commands instead receive `-m 'not e2e'`, the explicit E2E command remains valid. The plan must choose one.

### Antithesis and constructive synthesis

A persistent runtime token file adds a secret-bearing file and should not be introduced casually. But a systemd runtime directory owned by the unit user, mode 0700, containing an atomically created 0600 file, with the exact value exported as `HERMES_DASHBOARD_SESSION_TOKEN`, is narrower and auditable. It lets the probe authenticate without logs, browser scraping, query parameters, or receipt persistence, and naturally rotates on unit restart. A server-owned write is also viable, but only with an explicit environment-selected path, secure creation/cleanup, and tests.

## Root Cause

Revision 5 describes the probe's desired credential source but not the component contract that produces it. The existing dashboard intentionally keeps an unseeded session token only in memory, while the planned isolated unit declares no seed or runtime-file mechanism. This missing producer/consumer contract leaves the rollout gate non-executable.

## Findings

1. **HIGH — `stage-05-revision.md:42-49` — Launch-token handoff is undefined.** The new probe needs the dashboard bearer, but neither the Revision 4 unit nor current server exposes one to it. The required bootstrap/health gate therefore cannot run. Define one exact handoff: e.g. a unit RuntimeDirectory plus launcher that atomically creates a 0600 token, exports it as `HERMES_DASHBOARD_SESSION_TOKEN`, and removes it on stop; or a server-owned, explicitly configured runtime file with atomic-write and cleanup semantics. Test absent token, wrong owner/mode, restart rotation, and redacted receipts. [reported P1]
2. **MEDIUM — `stage-05-revision.md:26-34` — E2E exclusion has incompatible alternatives.** The inherited bare full-suite commands and current pytest `addopts` make a global `not e2e` policy conflict with the recorded `-m e2e` command unless overridden. Choose a working policy, update every exact default command or the explicit E2E invocation accordingly, and verify both selections plus credential preflight. [reported P2]

## Recommendations

1. Add the launch-token producer/consumer contract to the dashboard unit and Phase 4 file/test scope; make its lifecycle part of the live-probe acceptance criteria.
2. Choose per-command E2E exclusion (recommended) or global exclusion with an explicit `addopts` override; record exact full-suite and E2E commands.
3. Retain all other Revision 5 corrections unchanged: bare strict loopback cookie, unit-scoped lifecycle, `hermes_cli/web_dist` verification, exact root equality, and dedicated-credential E2E preflight.

## Architectural Status

BLOCK

## Code Review Recommendation

REQUEST CHANGES

## Tradeoffs

| Option | Benefit | Constraint |
|---|---|---|
| Unit-created runtime token + exported environment (recommended) | Probe gets the actual process token; restart rotation and service ownership are explicit | Require 0700 runtime directory, 0600 atomic file, cleanup, and no token logging |
| Server-owned configured runtime token file | Keeps generation within dashboard | Must define secure path creation, ownership, cleanup, and probe contract |
| Extract token from SPA/process memory | No new writer | Leaks/bypasses the intended operational boundary; reject |
| Default commands use `-m 'not e2e'` (recommended) | Explicit `-m e2e` rehearsal works unchanged | Update each full-suite ledger command |
| Global `addopts` excludes E2E | Central default | Explicit E2E command must clear/override inherited addopts |