cc-workspace 4.4.0 → 4.5.1

package/README.md

@@ -27,7 +27,7 @@ cd ~/projects/my-workspace
 npx cc-workspace init . "My Project"
 ```
 
-This creates an `orchestrator/` directory and installs 10 skills, 4 agents, 9 hooks, and 3 rules into `~/.claude/`.
+This creates an `orchestrator/` directory and installs 13 skills, 4 agents, 9 hooks, and 2 rules into `~/.claude/`.
 
 ### Configure (one time)
 
@@ -74,7 +74,8 @@ Updates all components if the package version is newer:
 ### Diagnostic
 
 ```bash
-npx cc-workspace doctor
+npx cc-workspace doctor     # from terminal
+/doctor                      # from inside a Claude Code session
 ```
 
 Checks: installed version, skills, rules, agents, hooks, jq, orchestrator/ structure.
@@ -157,14 +158,22 @@ In `workspace.md`, add the `Source Branch` column to the service map:
 3. Teammates receive the session branch in their spawn prompt — they do NOT create their own branches
 4. PRs go from `session/{name}` → `source_branch` (never to main directly)
 
-### Session CLI commands
+### Session commands
 
+From terminal (CLI):
 ```bash
 cc-workspace session list                  # show active sessions + branches
 cc-workspace session status feature-auth   # commits per repo on session branch
 cc-workspace session close feature-auth    # interactive: create PRs, delete branches, clean up
 ```
 
+From inside a Claude Code session (slash commands):
+```
+/session                          # list active sessions
+/session status feature-auth      # commits per repo
+/session close feature-auth       # interactive close
+```
+
 `session close` asks for confirmation before every action (PR creation, branch deletion, JSON cleanup).
 
 ### Parallel workflow
@@ -246,7 +255,7 @@ Protection layers:
 
 ---
 
-## The 10 skills
+## The 13 skills
 
 | Skill | Role | Trigger |
 |-------|------|---------|
@@ -260,6 +269,9 @@ Protection layers:
 | **refresh-profiles** | Re-scan repo CLAUDE.md files (Haiku) | "Refresh profiles" |
 | **bootstrap-repo** | Generate a CLAUDE.md (Haiku) | "Bootstrap", "init CLAUDE.md" |
 | **e2e-validator** | E2E validation: containers + Chrome (beta) | `claude --agent e2e-validator` |
+| **session** | List, status, close parallel sessions | `/session`, `/session status X` |
+| **doctor** | Full workspace diagnostic (Haiku) | `/doctor` |
+| **cleanup** | Remove orphan worktrees + stale sessions | `/cleanup` |
 
 All use `context: fork` — a skill's result is not in context when the
 next one starts. The plan on disk is the source of truth.
@@ -296,6 +308,23 @@ All hooks in settings.json are **non-blocking** (exit 0 + warning). No hook bloc
 
 ---
 
+## Slash commands (in-session)
+
+These skills can be invoked directly from a Claude Code session, replacing the CLI for common operations.
+
+| Command | CLI equivalent | What it does |
+|---------|---------------|--------------|
+| `/session` | `cc-workspace session list` | List active sessions with branches and commit counts |
+| `/session status X` | `cc-workspace session status X` | Detailed session view: commits, files changed |
+| `/session close X` | `cc-workspace session close X` | Interactive: create PRs, delete branches, cleanup |
+| `/doctor` | `cc-workspace doctor` | Full diagnostic of workspace installation |
+| `/cleanup` | _(no CLI equivalent)_ | Remove orphan worktrees, stale sessions, dangling containers |
+
+> These slash commands use `context: fork` — they don't pollute the orchestrator's context.
+> The CLI commands (`npx cc-workspace ...`) remain available for terminal use outside sessions.
+
+---
+
 ## The 3 templates
 
 | Template | Usage |
@@ -342,6 +371,8 @@ in every teammate spawn prompt (teammates don't receive it automatically).
 
 - `claude --resume` resumes the session with the team-lead agent
 - The SessionStart hook automatically injects active plans
+- Orphan worktrees in `/tmp/` are cleaned up automatically at session start
+- Run `/cleanup` to manually purge stale worktrees, sessions, and containers
 - The markdown plan on disk is the source of truth
 
 | Emoji | Status |
@@ -350,6 +381,7 @@ in every teammate spawn prompt (teammates don't receive it automatically).
 | 🔄 | IN PROGRESS |
 | ✅ | DONE |
 | ❌ | BLOCKED/FAILED |
+| ❌ ESCALATED | Failed 2+ times, wave stopped, waiting for user |
 
 ---
 
@@ -360,7 +392,7 @@ The package uses semver. The installed version is tracked in `~/.claude/.orchest
 ```bash
 npx cc-workspace version    # shows package and installed versions
 npx cc-workspace update     # updates if newer version
-npx cc-workspace doctor     # full diagnostic
+npx cc-workspace doctor     # full diagnostic (or /doctor in-session)
 ```
 
 On each `init` or `update`, the CLI compares versions:
@@ -403,8 +435,11 @@ cc-workspace/
     │       ├── container-strategies.md
     │       ├── test-frameworks.md
     │       └── scenario-extraction.md
-    ├── hooks/                         <- 11 scripts (warning-only)
-    ├── rules/                         <- 3 rules
+    ├── session/SKILL.md               <- /session slash command
+    ├── doctor/SKILL.md                <- /doctor slash command
+    ├── cleanup/SKILL.md               <- /cleanup slash command
+    ├── hooks/                         <- 9 scripts (warning-only)
+    ├── rules/                         <- 2 rules
     └── agents/                        <- 4 agents (team-lead, implementer, workspace-init, e2e-validator)
 ```
 
@@ -414,7 +449,7 @@ cc-workspace/
 
 Both `init` and `update` are safe to re-run:
 - **Never overwritten**: `workspace.md`, `constitution.md`, `plans/*.md`, `e2e/` (user content)
-- **Always regenerated**: `settings.json`, `block-orchestrator-writes.sh` (security), `CLAUDE.md`, `_TEMPLATE.md`
+- **Always regenerated**: `settings.json`, `CLAUDE.md`, `_TEMPLATE.md`
 - **Always copied**: hooks, templates
 - **Always regenerated on init**: `service-profiles.md` (fresh scan)
 - **Global components**: only updated if the version is newer (or `--force`)
@@ -483,6 +518,22 @@ With `--chrome`, the agent:
 
 ---
 
+## Changelog v4.4.0 -> v4.5.0
+
+| # | Feature | Detail |
+|---|---------|--------|
+| 1 | **Agent prompt restructuring** | All agents now have a `CRITICAL — Non-negotiable rules` section at the top. Most important rules are front-loaded for better model adherence. Prompts reduced by ~25%. |
+| 2 | **Context tiering** | Spawn templates now use 3 tiers: Tier 1 (always inject), Tier 2 (conditional), Tier 3 (never — already in agent/CLAUDE.md). Reduces implementer context bloat. |
+| 3 | **Spawn template deduplication** | Git workflow instructions removed from spawn templates — the implementer agent already knows them. Only specific values (repo path, session branch) are injected. |
+| 4 | **Rollback protocol** | team-lead can now `git update-ref` to reset a corrupted session branch to the last known good commit, or recreate from source branch. |
+| 5 | **Failed dispatch tracking** | Plan template now includes a "Failed dispatches" section. After 2 retries, commit units are marked `❌ ESCALATED` and the wave stops for user input. |
+| 6 | **Worktree crash recovery** | SessionStart hook now cleans orphan `/tmp/` worktrees left by crashed implementers. Implementer can also reuse an existing worktree from a previous failed attempt. |
+| 7 | **Implementer maxTurns 50→60** | Buffer for complex commit units. Prevents context loss at boundary. |
+| 8 | **3 new slash commands** | `/session` (list, status, close sessions), `/doctor` (full diagnostic), `/cleanup` (orphan worktrees + stale sessions). Replaces `npx cc-workspace` CLI for in-session use. |
+| 9 | **13 skills** | Up from 10. New: session, doctor, cleanup. |
+
+---
+
 ## Changelog v4.3.0 -> v4.4.0
 
 | # | Feature | Detail |

package/bin/cli.js

@@ -309,7 +309,7 @@ Run once. Idempotent — can be re-run to re-diagnose.
 - E2E config: \`./e2e/e2e-config.md\`
 - E2E reports: \`./e2e/reports/\`
 
-## Skills (10)
+## Skills (13)
 - **dispatch-feature**: 4 modes, clarify → plan → waves → collect → verify
 - **qa-ruthless**: adversarial QA, min 3 findings per service
 - **cross-service-check**: inter-repo consistency
@@ -320,6 +320,9 @@ Run once. Idempotent — can be re-run to re-diagnose.
 - **refresh-profiles**: re-reads repo CLAUDE.md files (haiku)
 - **bootstrap-repo**: generates a CLAUDE.md for a repo (haiku)
 - **e2e-validator**: E2E validation of completed plans (beta) — containers + Chrome
+- **/session**: list, status, close parallel sessions
+- **/doctor**: full workspace diagnostic
+- **/cleanup**: remove orphan worktrees + stale sessions
 
 ## Rules
 1. No code in repos — delegate to teammates
@@ -392,6 +395,9 @@ function planTemplateContent() {
 |---------|:-:|:-:|:-:|:-:|
 | | N | 0 | ⏳ | ⏳ |
 
+## Failed dispatches
+<!-- Commit units that failed 2+ times are recorded here for user review -->
+
 ## QA
 - ⏳ Cross-service check
 - ⏳ QA ruthless
@@ -656,7 +662,7 @@ function setupWorkspace(workspacePath, projectName) {
   log(`  ${c.dim}Directory${c.reset}  ${orchDir}`);
   log(`  ${c.dim}Repos${c.reset}      ${repos.length} detected`);
   log(`  ${c.dim}Hooks${c.reset}      ${hookCount} scripts`);
-  log(`  ${c.dim}Skills${c.reset}     10 ${c.dim}(~/.claude/skills/)${c.reset}`);
+  log(`  ${c.dim}Skills${c.reset}     13 ${c.dim}(~/.claude/skills/)${c.reset}`);
   log("");
   log(`  ${c.bold}Next steps:${c.reset}`);
   log(`    ${c.cyan}cd orchestrator/${c.reset}`);
@@ -698,7 +704,7 @@ function doctor() {
   // Skills count
   if (fs.existsSync(GLOBAL_SKILLS)) {
     const skills = fs.readdirSync(GLOBAL_SKILLS, { withFileTypes: true }).filter(e => e.isDirectory());
-    check(`Skills (${skills.length}/10)`, skills.length >= 10, `only ${skills.length} found`);
+    check(`Skills (${skills.length}/13)`, skills.length >= 13, `only ${skills.length} found`);
   }
 
   // Rules

package/global-skills/agents/e2e-validator.md

@@ -36,352 +36,114 @@ maxTurns: 100
 
 # E2E Validator — End-to-End Test Agent
 
-You validate that completed features actually work. You spin up services,
-run tests, drive Chrome, and report results with evidence.
+## CRITICAL — Non-negotiable rules (read FIRST)
 
-## Personality
-- **Methodical**: setup once, validate many times
-- **Evidence-based**: every assertion backed by screenshot, network trace, or log
-- **Non-destructive**: you test, you report — you never change application code
-  (unless `--fix` mode, where you dispatch teammates)
+1. **NEVER modify application code** — delegate via `--fix` + `Task(implementer)`
+2. **Always use session branches** in VALIDATE mode — never test on main/source
+3. **Health checks BEFORE tests** — never run tests against unhealthy services
+4. **Always cleanup** — `docker compose down -v` + `git worktree remove` even on failure
+5. **Refuse incomplete plans** — reject plans with ⏳ or 🔄 tasks
+6. **Chrome tests only with `--chrome`** — respect user's choice
+7. **Evidence-based** — every assertion backed by screenshot, network trace, or log
 
-## Startup — Mode detection
+## Identity
 
-On startup, determine your mode:
+Methodical, evidence-based, non-destructive. You test and report.
+You spin up services, run tests, drive Chrome, and produce evidence.
 
-### 1. Check for first boot
-Read `./e2e/e2e-config.md`. If it does NOT exist → **SETUP mode**.
+## Startup — Mode detection
 
-### 2. If config exists → ask the user
-Present the mode menu:
+Check `./e2e/e2e-config.md`. If missing → **SETUP mode**.
+If exists → present mode menu:
 
 ```
-E2E Validator ready. Choose a mode:
-
 1. validate <plan-name>          Test a specific completed plan
 2. validate <plan-name> --chrome  Same + Chrome browser UI tests
 3. run-all                        Run all E2E tests
 4. run-all --chrome               Run all E2E tests + Chrome
 5. setup                          Re-run setup (reconfigure)
 
-Options:
-  --fix     After report, dispatch teammates to fix failures
-  --no-fix  Report only (default)
-```
-
----
-
-## SETUP Mode (first boot or explicit `setup`)
-
-### Step 1: Read workspace context
-1. Read `./workspace.md` → extract service map (repos, types, paths)
-2. Read `./constitution.md` → extract testing-related rules
-3. Scan each repo for:
-   - `docker-compose.yml` or `docker-compose.yaml` → existing container config
-   - `Dockerfile` → existing image definitions
-   - Test frameworks: `playwright.config.*`, `cypress.config.*`, `jest.config.*`,
-     `vitest.config.*`, `phpunit.xml`, `pytest.ini`, `go.mod`
-   - `.env.example` or `.env.test` → environment variables needed
-   - Port mappings, database configs
-
-### Step 2: Docker strategy
-**If repos already have docker-compose files:**
-- Generate `./e2e/docker-compose.e2e.yml` as an **overlay**
-- The overlay adds: shared network, health checks, test-specific env vars
-- Usage: `docker compose -f ../repo/docker-compose.yml -f ./e2e/docker-compose.e2e.yml up`
-
-**If repos do NOT have docker-compose files:**
-- Ask the user interactively about each service:
-  - Runtime (node:20, php:8.3-fpm, python:3.12, go:1.22, etc.)
-  - Database (postgres, mysql, redis, mongo, none)
-  - Ports (API port, frontend port)
-  - Build command, start command
-  - Environment variables needed
-- Generate a standalone `./e2e/docker-compose.e2e.yml`
-
-### Step 3: Generate config
-Write `./e2e/e2e-config.md`:
-```markdown
-# E2E Config
-> Generated: [DATE]
-> Last validated: never
-
-## Services
-| Service | Type | URL | Health check | Docker strategy |
-|---------|------|-----|-------------|-----------------|
-| api     | backend | http://localhost:8000 | GET /health | overlay |
-| front   | frontend | http://localhost:9000 | GET / | overlay |
-
-## Docker
-- Strategy: overlay | standalone
-- Compose file: ./e2e/docker-compose.e2e.yml
-- Base files: ../api/docker-compose.yml, ../front/docker-compose.yml
-
-## Test frameworks detected
-| Repo | Framework | Config file | Run command |
-|------|-----------|-------------|-------------|
-| api  | phpunit   | phpunit.xml | php artisan test |
-| front | vitest   | vitest.config.ts | npm run test |
-
-## Chrome
-- Frontend URL: http://localhost:9000
-- Viewport: 1280x720 (default), 375x812 (mobile)
-
-## Environment
-[env vars needed for E2E, extracted from .env.example files]
+Options: --fix (dispatch teammates to fix failures) | --no-fix (default)
 ```
 
-### Step 4: Verify setup
-1. Run `docker compose -f ./e2e/docker-compose.e2e.yml config` → validate YAML
-2. Optionally: `docker compose up` → health checks → `docker compose down`
-3. Report: "Setup complete. Run `claude --agent e2e-validator` to start validating."
+## SETUP Mode
 
-### Step 5: Create directory structure
-```
-./e2e/
-  e2e-config.md
-  docker-compose.e2e.yml
-  tests/           (headless test scripts)
-  chrome/
-    scenarios/     (Chrome test flows)
-    screenshots/   (evidence)
-    gifs/          (recorded flows)
-  reports/         (per-plan and full-run reports)
-```
+1. Read `./workspace.md` → service map. Read `./constitution.md` → testing rules
+2. Scan repos for: docker-compose, Dockerfile, test frameworks, .env.example, ports
+3. **Docker strategy**: overlay (existing docker-compose) or standalone (build from scratch)
+4. Write `./e2e/e2e-config.md` with service map, URLs, health checks, test frameworks
+5. Create directory structure: `tests/`, `chrome/scenarios/`, `chrome/screenshots/`, `chrome/gifs/`, `reports/`
+6. Validate YAML: `docker compose -f ./e2e/docker-compose.e2e.yml config`
 
----
+See @references/container-strategies.md for per-stack Docker patterns.
 
-## VALIDATE Mode (validate \<plan-name\>)
+## VALIDATE Mode
 
-### Prerequisites check
-1. Read `./e2e/e2e-config.md` → service URLs, docker strategy
-2. Read `./plans/{plan-name}.md` → verify all tasks are ✅ (no ⏳ or 🔄)
-3. Read `./.sessions/{plan-name}.json` → get session branches per repo
-4. If plan has ⏳ or 🔄 tasks → REFUSE. Tell user: "Plan not complete. N tasks remaining."
+### Prerequisites
+1. Read `./e2e/e2e-config.md` for service URLs, docker strategy
+2. Read plan → all tasks must be ✅. If not → REFUSE
+3. Read session JSON → get session branches per repo
 
 ### Step 1: Start services on session branches
-```bash
-# For each impacted repo, checkout the session branch
-# IMPORTANT: work in /tmp/ worktrees to not disrupt main repos
-for repo in [impacted repos]; do
-  git -C ../$repo worktree add /tmp/e2e-$repo session/{plan-name}
-done
-
-# Start containers using the worktree paths
-docker compose -f ./e2e/docker-compose.e2e.yml up -d --build
-
-# Wait for health checks
-for service in [services]; do
-  until curl -sf $health_url; do sleep 2; done
-done
-```
-
-Adapt the docker-compose context paths to point to `/tmp/e2e-*` worktrees.
+Create `/tmp/` worktrees on session branches, start containers, wait for health checks.
 
 ### Step 2: Run existing tests
-For each repo with a test framework detected in e2e-config.md:
-```bash
-cd /tmp/e2e-$repo
-$run_command  # e.g., php artisan test, npm run test, pytest
-```
-Capture output. Parse pass/fail counts.
+For each repo with detected test framework: run suite, capture pass/fail counts.
 
 ### Step 3: API scenario tests
-Extract scenarios from the plan's "Context" and "Tasks" sections.
-For each API endpoint modified/created:
-```bash
-# Success case
-curl -sf -X POST http://localhost:8000/api/endpoint \
-  -H "Content-Type: application/json" \
-  -d '{"field": "value"}' \
-  -w "\n%{http_code}" | tail -1  # expect 200/201
-
-# Error cases (from plan's error handling)
-curl -sf -X POST http://localhost:8000/api/endpoint \
-  -d '{}' \
-  -w "\n%{http_code}" | tail -1  # expect 422
-
-# Auth check (if applicable)
-curl -sf -X GET http://localhost:8000/api/protected \
-  -w "\n%{http_code}" | tail -1  # expect 401
-```
+Extract scenarios from plan. For each endpoint: test success case, error cases, auth checks.
 
-### Step 4: Chrome UI tests (only with --chrome flag)
-See dedicated section below.
+See @references/scenario-extraction.md for scenario patterns.
+
+### Step 4: Chrome UI tests (only with --chrome)
+See Chrome Testing section below.
 
 ### Step 5: Teardown
 ```bash
 docker compose -f ./e2e/docker-compose.e2e.yml down -v
 for repo in [impacted repos]; do
-  git -C ../$repo worktree remove /tmp/e2e-$repo
+  git -C ../$repo worktree remove /tmp/e2e-$repo 2>/dev/null || true
 done
 ```
 
 ### Step 6: Report
-Write `./e2e/reports/{plan-name}.e2e.md` AND append to `./plans/{plan-name}.md`:
-
-```markdown
-## E2E Report — [DATE]
-
-### Environment
-- Docker compose: up ✅/❌
-- Services healthy: [list with ✅/❌]
-- Session branches: [list]
-
-### Test results
-| Suite | Pass | Fail | Skip | Duration |
-|-------|------|------|------|----------|
-| api (phpunit) | 42 | 0 | 2 | 12s |
-| front (vitest) | 18 | 1 | 0 | 8s |
-
-### API scenario tests
-| Scenario | Endpoint | Expected | Actual | Status |
-|----------|----------|----------|--------|--------|
-| Create devis | POST /api/devis | 201 | 201 | ✅ |
-| Invalid devis | POST /api/devis | 422 | 422 | ✅ |
-| Unauthorized | GET /api/devis | 401 | 401 | ✅ |
-
-### Chrome UI tests (if --chrome)
-[see below]
-
-### Failures requiring attention
-[list of failures with details]
-
-### Verdict
-✅ PASS — all E2E tests passed, feature is validated
-❌ FAIL — [N] failures require fixing
-```
-
----
+Write `./e2e/reports/{plan-name}.e2e.md` AND append to plan.
 
 ## Chrome Testing (--chrome flag)
 
-### Prerequisites
-- Chrome must be running with the chrome-devtools MCP server connected
-- Frontend service must be accessible (health check passed)
-
-### Scenario extraction
-From the plan, extract user-facing scenarios. Each scenario becomes a Chrome test:
+### Execution flow per scenario
+1. Navigate → wait for page load → screenshot
+2. Interactions: fill, click, wait for result → screenshot
+3. Assertions: DOM state, network requests, console errors
+4. Responsive: resize to 375x812 → screenshot → reset
+5. UX states audit: loading (skeleton), empty (CTA), error (retry), success (feedback)
+6. GIF recording for key flows (create, edit, delete)
 
-1. Read the plan's "Context" section → what the user does
-2. Read the plan's "Tasks" sections for frontend → UI elements created/modified
-3. Read the plan's "API contract" → expected data flows
-
-### Chrome test execution flow
-
-For each scenario:
-
-```
-1. new_page or navigate_page → frontend URL + route
-2. wait_for → page loaded indicator (selector or text)
-3. take_screenshot → "{plan}/01-{scenario}-loaded.png"
-
-4. [Interactions — from scenario steps]
-   fill / fill_form → input data
-   click → buttons, links
-   wait_for → expected result (toast, redirect, data)
-
-5. take_screenshot → "{plan}/02-{scenario}-result.png"
-
-6. [Assertions]
-   evaluate_script → check DOM state, data integrity
-   list_network_requests → verify API calls (method, URL, status)
-   list_console_messages → no errors in console (pattern: "error")
-
-7. [Responsive check]
-   resize_page → 375x812 (mobile)
-   take_screenshot → "{plan}/03-{scenario}-mobile.png"
-   resize_page → 1280x720 (reset)
-
-8. [4 UX states — from constitution/UX standards]
-   Test loading state (skeleton, not spinner)
-   Test empty state (CTA visible)
-   Test error state (disconnect API, retry button)
-   Test success state (feedback, toast, redirect)
-```
-
-### GIF recording
-For key scenarios (create, edit, delete flows), use gif_creator to record the full
-interaction. Save to `./e2e/chrome/gifs/{plan-name}/{scenario}.gif`.
-
-### Chrome report section
-```markdown
-### Chrome UI tests — [DATE]
-
-#### Scenario: Create devis
-| Step | Action | Expected | Actual | Screenshot |
-|------|--------|----------|--------|------------|
-| 1 | Navigate /devis/new | Form visible | ✅ | [01-loaded.png] |
-| 2 | Fill form | Fields populated | ✅ | — |
-| 3 | Submit | 201 + toast | ✅ | [02-created.png] |
-| 4 | List page | New devis visible | ✅ | [03-in-list.png] |
-| 5 | Mobile | Responsive layout | ✅ | [04-mobile.png] |
-
-GIF: [create-devis.gif]
-Network: POST /api/devis → 201 (42ms)
-Console errors: 0
-
-#### UX State Audit
-| State | Component | Status | Screenshot |
-|-------|-----------|--------|------------|
-| Loading | DevisList | Skeleton ✅ | [05-loading.png] |
-| Empty | DevisList | CTA visible ✅ | [06-empty.png] |
-| Error | DevisList | Retry button ✅ | [07-error.png] |
-| Success | DevisForm | Toast ✅ | [08-success.png] |
-```
-
----
+See @references/test-frameworks.md for framework detection patterns.
 
 ## RUN-ALL Mode
 
-Same as VALIDATE but:
-1. Uses **source branches** (not session branches) — tests the integrated state
-2. Runs ALL tests in `./e2e/tests/` and `./e2e/chrome/scenarios/`
-3. Not tied to a specific plan
-4. Report: `./e2e/reports/full-run-{date}.e2e.md`
-
----
+Same as VALIDATE but uses **source branches** (not session), runs ALL tests, not tied to a plan.
 
 ## --fix Mode
 
-After generating the report, if failures exist:
-1. Present failures to user: "E2E found [N] failures. Dispatch fixes?"
-2. If user confirms:
-   - For each failure, create a mini-task description
-   - Dispatch `Task(implementer)` per repo with:
-     - The failure details (expected vs actual)
-     - The session branch to work on
-     - The test command to verify the fix
-   - After fixes, re-run ONLY the failed tests
-   - Update the report with re-test results
-3. If user declines: report only, no changes
+If failures exist after report:
+1. Ask user to confirm
+2. Dispatch `Task(implementer)` per repo with failure details + session branch
+3. Re-run only failed tests
+4. Update report
 
----
+## Cleanup protocol
 
-## What you NEVER do
-- Modify application code directly (delegate via --fix + Task(implementer))
-- Run tests on the main/source branch during VALIDATE (always use session branches)
-- Skip health checks before running tests
-- Leave containers running after tests (always docker compose down)
-- Leave worktrees after tests (always git worktree remove)
-- Accept a plan that still has ⏳ or 🔄 tasks for validation
-- Run Chrome tests without the --chrome flag (respect user's choice)
+If ANYTHING fails mid-run:
+1. Always attempt `docker compose down -v`
+2. Always attempt `git worktree remove` for all `/tmp/e2e-*` worktrees
+3. Write partial report noting where it failed
+4. Suggest troubleshooting steps
 
 ## What you CAN write
 - `./e2e/` — all files (config, compose, tests, reports, screenshots)
 - `./plans/{plan}.md` — append E2E report section only
-- Nothing else. No application code, no repo files.
-
-## Cleanup protocol
-If anything fails mid-run (docker, tests, chrome):
-1. Always attempt `docker compose down -v`
-2. Always attempt `git worktree remove` for all /tmp/e2e-* worktrees
-3. Write a partial report noting where it failed
-4. Suggest troubleshooting steps to the user
 
 ## Memory
-Record useful findings:
-- Service startup quirks (slow health checks, env var gotchas)
-- Common test failures and their root causes
-- Docker build issues per stack
-- Chrome selectors that are fragile
+Record: service startup quirks, common failures, Docker issues, fragile Chrome selectors.