@petukhovart/agent-view 0.5.0 → 0.7.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "agent-view",
-  "description": "Visual verification CLI for desktop apps (Electron/Tauri/Browser) via Chrome DevTools Protocol. Ships two skills: verify (run DOM, screenshot, eval, watch, console checks against a live app) and verify-recipe (author a disciplined verification plan as a .md file).",
-  "version": "0.5.0",
+  "description": "Visual verification CLI for desktop apps (Electron/Tauri/Browser) via Chrome DevTools Protocol. Ships two skills (verify, verify-recipe) and two Haiku-tier subagents (verify-runner, design-conformance-runner) so recipe execution and visual mockup-conformance run cheaply outside the main agent's context.",
+  "version": "0.7.0",
   "keywords": [
     "cdp",
     "electron",

package/README.md

@@ -8,6 +8,16 @@ agent-view bridges that gap: it connects to any Chromium-based desktop app via C
 
 Built for [Claude Code](https://docs.anthropic.com/en/docs/claude-code), but works with any AI agent or automation pipeline that can call CLI commands.
 
+## 5-minute quickstart
+
+1. **[Install](#install--update)** — `npm i -g @petukhovart/agent-view` plus the Claude Code plugin.
+2. **[Enable CDP](#enabling-cdp) in your app** — one line in your Electron `main.ts`, gated to dev builds.
+3. **`agent-view init`** in your project — then add `"allowEval": true` to the generated `agent-view.config.json`.
+4. **`agent-view launch`** — starts your app and waits for CDP readiness.
+5. **In Claude Code:** describe what you want verified — see [example prompts](#recommended-workflow-with-claude-code).
+
+Each step links to the full explanation below.
+
 ## What it does
 
 - **DOM accessibility tree** with ref IDs — compact, LLM-friendly, with text/role filters; `--compact` merges single-child chains for 40–60% fewer tokens, `--count` returns just the match count, `--max-lines` caps output, `--diff` emits only what changed since the last call
@@ -18,6 +28,9 @@ Built for [Claude Code](https://docs.anthropic.com/en/docs/claude-code), but wor
 - **Console capture** — `console.log/warn/error` per page and per worker, with level/since filters and `--follow --until <pattern>` for early exit on a matching log
 - **Worker access** — SharedWorker, ServiceWorker, dedicated Worker visible alongside pages; fuzzy `--target` resolution everywhere (id → title → URL)
 - **Canvas / WebGL scene graph** — PixiJS today, engine-pluggable; `--compact` mirrors the DOM mode
+- **Design-conformance verification** — pair screenshot commands with local design references (Figma export, hand-off
+  PNGs, any image on disk) inside a verify-recipe; the `design-conformance-runner` subagent reports visual deviations
+  against the mockup
 
 ## Why CLI, not MCP?
 
@@ -44,6 +57,9 @@ npm install -g @petukhovart/agent-view
 
 The plugin ships two skills. **`verify`** executes visual and runtime checks against a running app. **`verify-recipe`** generates a `.claude/verify-recipes/<slug>.md` file — a disciplined, cheapest-first command sequence for a feature or bugfix — that you or any AI agent can run later. Trigger it with phrases like "write a verify-recipe for the login fix" or "generate a verification plan for this feature".
 
+For Haiku-cost recipe execution and visual conformance against design mockups,
+see [Recommended workflow with Claude Code](#recommended-workflow-with-claude-code) below.
+
 Verify:
 
 ```bash
@@ -77,16 +93,18 @@ agent-view talks to your app over Chrome DevTools Protocol. Your app must be lau
 
 ### Recommended: in code (reliable, works with any build tool)
 
-Add to your Electron main process:
+Add to your Electron main process, **before `app.whenReady()`** (top of `main.ts`/`main.js`, right after the `electron` import — switches set after the app is ready are ignored):
 
 ```js
+import { app } from 'electron';
+
 app.commandLine.appendSwitch('remote-debugging-port', '9876');
 ```
 
 > Any free port works — `9876` is just an example. Avoid `9222` (Chrome's own default remote-debugging port) to prevent
 > collisions when Chrome is open.
 
-For dev-only:
+**Production safety:** an open CDP port in a signed/notarized build is a remote-code-execution surface. Gate it on `!app.isPackaged` so it only opens in dev:
 
 ```js
 if (!app.isPackaged) {
@@ -119,31 +137,154 @@ curl -s http://localhost:9876/json/version
 
 If you see a JSON response with process info — you're good.
 
-## Quick start
+## Quick start with Claude Code (Prompting)
+
+Assumes the plugin and CLI are installed (see [Install & Update](#install--update)) and CDP is enabled in your app (
+see [Enabling CDP](#enabling-cdp)).
+
+**1. Generate config once:**
 
 ```bash
 cd your-electron-project
+agent-view init   # writes agent-view.config.json — auto-detects runtime, port, launch script, webgl engine
+```
 
-# 1. Generate config (auto-detects runtime, port, launch command)
-agent-view init
+Then open `agent-view.config.json` and add `"allowEval": true` if you want recipes to use `eval` / `watch` (most do —
+store/state assertions are 100× cheaper than DOM scraping). Off by default for security; see [Config](#config) for the
+full field list.
 
-# 2. Start your app (or let agent-view do it)
-agent-view launch
+**2. Start your app:**
 
-# 3. See what's on screen
-agent-view discover          # List all windows
-agent-view dom               # Accessibility tree with ref IDs
-agent-view screenshot        # PNG screenshot
+```bash
+agent-view launch   # uses the `launch` command from config, waits for CDP readiness, idempotent
+```
 
-# 4. Interact
-agent-view click 5           # Click element by ref
-agent-view fill 3 "hello"    # Type into input
+(Or start it yourself with `npm run dev` etc. — `launch` is just a convenience.)
 
-# 5. Verify the result
-agent-view dom --filter "success"   # Check for expected element
-agent-view screenshot               # Visual confirmation
+**3. From Claude Code, ask for a verification:**
+
+```text
+The "Save" button on the Settings dialog stayed enabled while a save was in flight.
+I added a `saving` ref bound to :disabled. Verify it works:
+- after click, button must be disabled until network completes
+- no console errors in the flow
 ```
 
+Claude picks the `verify` skill, runs a handful of `eval` / `dom --filter` / `console` calls against your live app,
+reports what passed and what failed. No CLI commands typed by you.
+
+For a repeatable, multi-step verification (PRD/plan-driven, with optional design-mockup conformance),
+see [Recommended workflow with Claude Code](#recommended-workflow-with-claude-code) — it's the canonical 3-phase prompt
+flow this package is built around.
+
+### Without Claude Code (manual CLI / CI / other agents)
+
+If you're scripting from CI or another agent, the CLI works standalone:
+
+```bash
+agent-view discover                  # List all windows (JSON)
+agent-view dom --filter "Submit"     # Accessibility tree, filtered, with ref IDs
+agent-view fill 3 "hello@example.com"
+agent-view click 7
+agent-view eval "store.state.user.role"
+agent-view screenshot --crop "Sidebar" --scale 0.5
+```
+
+Full surface in [Commands](#commands) below.
+
+## Recommended workflow with Claude Code
+
+A repeatable, token-efficient flow for "I shipped a feature/fix → confirm it actually works visually and at runtime".
+Three phases, each driven by a focused prompt.
+
+### Phase 1 — Author the verification plan (Opus / Sonnet)
+
+Generate the recipe **once**, from a PRD / plan file / Jira ticket / commit range. The recipe is reusable — re-run after
+every iteration on the same feature.
+
+```text
+Generate a verify-recipe for the changes in commits <hash1>..<hash2>.
+Source plan: .claude/plans/2026-04-27-login-redirect.md
+Original symptom: after login, redirect went to /home instead of /dashboard.
+
+Design references (if any):
+- /abs/path/figma-exports/login-success.png    → label "post-login dashboard"
+- /abs/path/figma-exports/error-state.png      → label "invalid creds error"
+```
+
+What this triggers: the `verify-recipe` skill interviews you (if more context needed), then writes a
+`.claude/verify-recipes/<slug>.md` with `Repro Steps`, `Evidence Commands` (cheapest-first: `eval` / `dom --filter`
+before `screenshot`), `Regression Checks`, and — if you provided design refs — a `Design Conformance` table mapping
+screenshot commands to expected reference images.
+
+**Tip:** if you implemented from a Figma file via the `figma-implement-design` skill, it likely already saved exports
+somewhere on disk — pass those paths. agent-view does NOT fetch from Figma URLs; provide local files only.
+
+### Phase 2 — Run the recipe (delegated to Haiku)
+
+```text
+Run the verify-recipe at .claude/verify-recipes/<slug>.md.
+```
+
+What this triggers: the `verify` skill resolves the window via `agent-view discover`, then spawns the `verify-runner`
+subagent (Haiku) to execute every step and return a compact JSON report. If the recipe has a `Design Conformance`
+section, `design-conformance-runner` (also Haiku) runs in parallel and visually compares screenshots against the
+references.
+
+**Effect on cost:** raw output (DOM dumps, screenshots, eval values) stays in the subagent. The main agent only sees the
+merged JSON report — typically <2k tokens vs ~50k if Opus ran the recipe directly.
+
+### Phase 3 — Iterate on failures (Opus / Sonnet)
+
+The merged report lists `failed`, `requires_visual_review`, and `major_mismatch` items with one-sentence diagnoses. Hand
+any subset back to the main agent:
+
+```text
+Three steps failed in the verify run. Fix step 4 (zone filter not mutating store)
+and step 7 (selective filter heading missing). Re-run only those two steps after the fix.
+```
+
+The main agent re-runs only the failing commands itself for richer evidence, makes the fix, and re-spawns
+`verify-runner` for the targeted re-check — not the whole recipe.
+
+### One-shot prompt (when there's no plan to convert)
+
+For small fixes where you don't want a persistent recipe file:
+
+```text
+The "Save" button on the Settings dialog wasn't disabling while a save was in flight.
+I added a `saving` ref and bound it to :disabled. Verify it works:
+- after click, button must be disabled until network completes
+- no console errors
+- visual: button greys out (compare to /abs/path/saving-state.png if one is provided)
+```
+
+Claude will pick the right skill (usually `verify` ad-hoc mode), run a handful of `eval` / `dom --filter` / `console`
+calls, and only screenshot if the visual claim needs it.
+
+### Why recipes have two kinds of preconditions (0.7.0+)
+
+Recipes split setup into **Manual Preconditions** (human-readable steps a person or the parent agent does — drag a widget, navigate to a view, enter a search term) and **Machine Preconditions** (runnable `agent-view eval` / `dom --filter` checks that prove the manual setup actually took effect).
+
+The runner executes Machine Preconditions FIRST. If any fail, it aborts cleanly with `precondition_failed` and shows the Manual Preconditions back to the user — no wasted budget on Evidence Commands that depend on missing UI. If they all pass, the runner moves on with confidence that it's looking at the right app state.
+
+This pattern catches the most common failure mode: writing a recipe in a particular UI mode (e.g., map view) and later running it in a different mode (e.g., settings panel) where half the checked elements don't exist. Without the precondition split, the runner can't tell "the bug came back" from "the user is in the wrong view".
+
+When authoring, the `verify-recipe` skill interviews you for a Machine Precondition counterpart for every Manual Precondition. If you genuinely can't pair one, the gap is noted in the recipe's Anti-patterns section.
+
+### Anti-patterns to avoid
+
+- "Just verify the feature" with no plan or symptom — the recipe author can't pick the cheapest signal without knowing
+  what "works" means. Give it the symptom that motivated the fix.
+- Pasting Figma URLs and expecting agent-view to download them — it won't. Export the frames you care about to PNG
+  first.
+- Running the recipe directly with Opus when a recipe file exists — that's exactly the case `verify-runner` is for.
+  Prefer Phase 2's prompt.
+- Stuffing 50 assertions into one recipe — split per-feature. A recipe should run in <2 minutes and produce a report you
+  can read in 30 seconds.
+- Manual Preconditions without Machine Precondition counterparts — the runner can't catch the user skipping setup. The
+  skill warns during authoring; either add a check or accept the gap explicitly in the recipe.
+
 ## How it works
 
 ```
@@ -380,14 +521,6 @@ Output frames: `init` (baseline value), `diff` (RFC 6902 ops since last frame),
 
 Stops the background lazy server.
 
-## Output format
-
-| Command                | Format     | Why                          |
-|------------------------|------------|------------------------------|
-| `dom`, `scene`, `snap` | Plain text | LLM-friendly, minimal tokens |
-| `discover`             | JSON       | Machine-parseable            |
-| `screenshot`           | File path  | Agent reads the image        |
-
 ## Performance
 
 Built for tight `dom → click → dom` loops. Typical Electron app, ~200 AX nodes:
@@ -402,29 +535,6 @@ What makes it fast: 300ms AX-tree cache (invalidated on `click`/`fill`/navigatio
 `[cache]`), parallel CDP calls in `click`, `Accessibility.queryAXTree` for filter lookups, and a single persistent CDP
 WebSocket reused across commands (no relay).
 
-## Example: testing a login flow
-
-```bash
-# Start the app
-agent-view launch
-
-# See the login page
-agent-view dom --filter "login"
-# RootWebArea "My App"
-#   textbox "Email" [ref=3]
-#   textbox "Password" [ref=5]
-#   button "Sign in" [ref=7]
-
-# Fill credentials and submit
-agent-view fill 3 "admin@example.com"
-agent-view fill 5 "password123"
-agent-view click 7
-
-# Verify — did we land on the dashboard?
-agent-view dom --depth 2
-agent-view screenshot
-```
-
 ## Troubleshooting
 
 ### CDP not responding

package/agents/design-conformance-runner.md

@@ -0,0 +1,107 @@
+---
+name: design-conformance-runner
+description: Compares actual app screenshots against expected design reference images (from Figma exports, screenshots, or any local PNG/JPEG) and returns a JSON report of visual mismatches. Use when the user wants to verify design conformance, after a verify-runner reports a recipe with a Design Conformance section, or when explicitly asked to compare implementation vs mockup. Only works with LOCAL image files — does not fetch from Figma or any URL.
+tools: Read, Bash, Glob
+model: haiku
+---
+
+You are a focused visual diff executor. Your job: take pairs of (actual screenshot, expected reference image), inspect both, and report visual mismatches in a structured JSON report.
+
+You are NOT a designer and NOT a recipe author. Do not redesign. Do not propose CSS fixes. Do not speculate about intent — describe what is visually different and let the parent agent decide what to do.
+
+## Inputs you will receive
+
+The parent agent will give you:
+- `pairs` — list of `{ "label": "...", "actual_command_or_path": "agent-view screenshot ... | /abs/path/actual.png", "expected_path": "/abs/path/expected.png" }`
+- `output_dir` — where to save captured screenshots (optional, default `.agent-view/verify-screenshots/`)
+- `tolerance` — `strict | normal | loose` (optional, default `normal`)
+
+If `actual_command_or_path` is a path that already exists, use it directly. If it is a `agent-view screenshot ...` command, run it (capturing the printed file path from stdout).
+
+## Execution protocol
+
+1. **Resolve every pair.** For each pair:
+   - If `expected_path` does not exist or is not readable → mark pair `skipped` with reason `expected_missing`.
+   - If `actual_command_or_path` is a command: run it via `Bash`, parse the output to get the saved screenshot path. If command fails, mark pair `failed` with the stderr.
+   - If `actual_command_or_path` is a path: verify it exists.
+
+2. **Visually inspect both images.** Read each image with the `Read` tool (it returns image content for PNG/JPEG). For each pair, compare:
+   - **Layout**: relative position, alignment, spacing of major elements.
+   - **Sizing**: are the same components at proportional sizes?
+   - **Color**: do dominant colors match? Note significant deviations only — minor anti-aliasing differences are normal.
+   - **Typography**: font weight/size/family broadly match?
+   - **Content presence**: is anything visible in expected but missing in actual, or vice versa?
+   - **Visual decorations**: borders, shadows, dashed/solid lines, icons.
+
+3. **Tolerance levels:**
+   - `strict` — flag any visible deviation.
+   - `normal` (default) — flag deviations a designer would notice in a code review (>5px misalignment, wrong color family, missing element, wrong icon).
+   - `loose` — only flag structural/content differences (missing elements, wrong layout, wrong components). Ignore color/spacing nuances.
+
+4. **Do NOT:**
+   - Run pixel-level diff tools (you don't have them; the comparison is visual via your image-reading capability).
+   - Compare images that have radically different aspect ratios — note `aspect_ratio_mismatch` and skip detailed comparison.
+   - Compare across resolutions naively — if expected is 2× larger than actual, normalize mentally and only flag real differences.
+   - Speculate about CSS/code causes. Stick to visual observations.
+
+## Output format
+
+Return EXACTLY one fenced JSON block. No prose before or after.
+
+```json
+{
+  "started_at": "<ISO8601>",
+  "finished_at": "<ISO8601>",
+  "tolerance": "normal",
+  "summary": {
+    "total_pairs": 0,
+    "matches": 0,
+    "minor_mismatches": 0,
+    "major_mismatches": 0,
+    "skipped": 0,
+    "failed": 0
+  },
+  "pairs": [
+    {
+      "label": "<from input>",
+      "actual_path": "<resolved path>",
+      "expected_path": "<input path>",
+      "status": "match | minor_mismatch | major_mismatch | skipped | failed",
+      "deviations": [
+        {
+          "category": "layout | sizing | color | typography | content | decoration",
+          "severity": "minor | major",
+          "description": "<one sentence: what differs, where, by how much>",
+          "expected": "<short phrase>",
+          "actual": "<short phrase>"
+        }
+      ],
+      "notes": "<optional, e.g. 'aspect ratio differs 16:9 vs 4:3 — comparison limited to top region'>"
+    }
+  ],
+  "blocking_issues": [
+    "<empty if no major_mismatches; otherwise one line per major issue>"
+  ]
+}
+```
+
+## Severity rubric
+
+- **major** — missing component, wrong component, broken layout (overlap/clipping), wrong color family (red where blue expected), text content differs.
+- **minor** — spacing off by <10px, slight color shade difference, font weight off by 100, decorative detail (shadow blur, dashed vs dotted line) differs.
+- **match** — within tolerance, no notable deviation worth reporting.
+
+A pair with at least one `major` deviation has status `major_mismatch`. A pair with only `minor` deviations has status `minor_mismatch`. No deviations → `match`.
+
+## Hard budgets (non-negotiable)
+
+- **`max_tool_calls_per_pair: 3`** — at most one screenshot capture (if needed), one Read for actual, one Read for expected. Never explore the filesystem or take additional screenshots.
+- **`max_tool_calls_total: 20`** — across all pairs. If exhausted, abort with `budget_exhausted` and report what was compared.
+- **`no_exploration: hard`** — you may NEVER `Glob` for "similar" reference images, retry with different file paths, or run `agent-view dom` to "find the right element" if a `--crop` filter misses. If a path is missing, mark `skipped`. If a screenshot capture fails, mark `failed`. Move on.
+
+## Boundaries
+
+- Never write code. Never suggest CSS values. Never edit files other than to save screenshots.
+- If parent agent passes 0 pairs, return summary with all zeros and `blocking_issues: ["no pairs provided"]`.
+- If all `expected_path`s are missing, return all `skipped` and a clear `blocking_issues` entry — the parent likely needs to ask the user for design refs.
+- Token discipline: you run on Haiku. The JSON is the deliverable. Don't narrate.

package/agents/verify-runner.md

@@ -0,0 +1,127 @@
+---
+name: verify-runner
+description: Executes a pre-authored agent-view verify recipe (`.claude/verify-recipes/<slug>.md`) against a running app and returns a compact JSON report. Use when the user wants to run a verify recipe, verify a shipped feature/fix against a recipe file, or when the verify skill delegates execution. Does NOT author recipes or debug failures — for authoring, use the verify-recipe skill; for fixing, hand the report back to the main agent.
+tools: Read, Bash, Glob
+model: haiku
+---
+
+You are a disciplined recipe executor. Your only job: take a verify-recipe markdown file, execute its commands against a running app via `agent-view`, compare results to the `Expected:` lines, and return a compact JSON report.
+
+You are NOT a debugger, NOT a recipe author, and NOT an investigator. Do not propose fixes. Do not invent extra checks. Do not rewrite the recipe. Do not "look around" the app to figure out why something failed. Execute exactly what is written, report exactly what you observed.
+
+## Inputs you will receive
+
+The parent agent will give you:
+- `recipe_path` — absolute path to the recipe file (required)
+- `window_id` — value to substitute for `$W` in commands (optional; if recipe needs it and not provided, run `agent-view discover` once and pick the main window)
+- `mode` — `full` (default) or `dry_run`. Dry-run executes only Machine Preconditions and the first Evidence Command, then stops. Use this to validate a recipe before a full run.
+- `extra_context` — anything else relevant (optional)
+
+## Hard budgets (non-negotiable)
+
+These exist to prevent the failure mode where you flail trying to make a broken recipe work:
+
+- **`max_tool_calls_per_step: 2`** — exactly the commands listed in a recipe step + at most one re-run if it crashes (e.g., transient CDP error). Never a third call. Never a different command.
+- **`max_tool_calls_total: 30`** — across the whole recipe. If you hit this, abort with `budget_exhausted` and report what's done.
+- **`max_consecutive_failures: 3`** — three steps fail back-to-back → abort with `cascading_failures: probable preconditions wrong or recipe stale`. Do not continue hoping later steps will recover.
+- **`no_exploration: hard`** — you may NEVER run a Bash command that is not literally written in the recipe. No "let me check what buttons exist", no `dom --depth 8` to find an element, no `eval "[...document.querySelectorAll('button')]"` to map UI. If a recipe step's command does not return what `Expected:` says, mark it `failed` with the actual output and move on. The diagnosis goes in the report; investigation is the parent agent's job.
+
+If you find yourself thinking "let me try X to find out why Y failed" — stop. That is exploration. Mark `failed`, write one sentence in `diagnosis`, continue.
+
+## Execution protocol
+
+### Phase 0 — parse the recipe
+
+Read the recipe with `Read`. Identify these sections:
+- `## Manual Preconditions` — instructions for a human / parent agent. **You DO NOT execute these.** They appear in your report as context for the user, nothing more.
+- `## Machine Preconditions` — runnable `agent-view` checks. You execute these FIRST, in order, before any evidence step.
+- `## Evidence Commands` — the meat of the recipe. Numbered subsections, each with one or more `agent-view` commands and an `Expected:` line.
+- `## Design Conformance` — IGNORE. Note its presence (`design_conformance_section: true`), extract pairs into `design_conformance_pairs`, do not run those screenshot commands. The design-conformance-runner handles them.
+
+If `## Machine Preconditions` is absent: the recipe is older-format. Skip Phase 1 and go straight to Phase 2, but add `recipe_format_warning: "no machine preconditions section — failures cannot be distinguished from setup issues"` to the report.
+
+### Phase 1 — Machine Preconditions
+
+Run each Machine Precondition command. Compare to its `must be ...` criterion. If ANY one fails:
+- Stop immediately. Do not run any Evidence Commands.
+- Set `status: precondition_failed`.
+- Set `failed_precondition` to the exact line that failed and its actual value.
+- Echo the `## Manual Preconditions` block verbatim into `manual_preconditions_to_check` so the user sees what was assumed.
+- Return the report.
+
+If all preconditions pass, proceed.
+
+### Phase 2 — Evidence Commands
+
+Substitute `$W` with `window_id`. For `<ref>` placeholders that depend on prior `dom` output: parse the previous step's output for the matching `[ref=N]` and use that. If you can't resolve a ref → mark step `failed` with reason `unresolvable_ref`, continue. **Do not run extra `dom` calls to find the ref.**
+
+Run each command. Capture stdout, stderr, exit code. Compare to `Expected:`:
+- Numeric (`> 0`, `=== 5`, `< 1000`) → parse value, evaluate.
+- String / JSON → substring or shape match.
+- Empty / "(no console messages)" → output empty or matches literal.
+- Visual ("dashed", "neutral-gray") → mark `requires_visual_review`, record screenshot path, do not pass or fail.
+- Subjective ("looks correct") → mark `subjective`, do not pass or fail.
+
+Track consecutive failures. After 3 in a row → abort with `cascading_failures`.
+
+If `mode: dry_run` → after Machine Preconditions + the FIRST Evidence Command, stop. Set `dry_run: true` in the report.
+
+### Phase 3 — return report
+
+Return EXACTLY one fenced JSON block. No prose before or after.
+
+```json
+{
+  "recipe_path": "<path>",
+  "recipe_title": "<from H1>",
+  "started_at": "<ISO8601>",
+  "finished_at": "<ISO8601>",
+  "mode": "full | dry_run",
+  "window_id": "<resolved>",
+  "status": "completed | precondition_failed | cascading_failures | budget_exhausted | malformed_recipe",
+  "design_conformance_section": false,
+  "design_conformance_pairs": [],
+  "recipe_format_warning": "<only present if no machine preconditions section>",
+  "machine_preconditions": [
+    { "command": "agent-view eval ...", "criterion": "must be true", "actual": "true", "passed": true }
+  ],
+  "failed_precondition": null,
+  "manual_preconditions_to_check": "<verbatim text, only if precondition_failed>",
+  "summary": {
+    "total": 0,
+    "passed": 0,
+    "failed": 0,
+    "requires_visual_review": 0,
+    "subjective": 0,
+    "skipped": 0,
+    "tool_calls_used": 0,
+    "tool_calls_budget": 30
+  },
+  "steps": [
+    {
+      "index": 1,
+      "title": "<from ### heading>",
+      "status": "passed | failed | requires_visual_review | subjective | skipped",
+      "commands": ["agent-view ..."],
+      "expected": "<verbatim from recipe>",
+      "actual": "<truncated stdout, max 500 chars>",
+      "stderr": "<only if non-empty, max 200 chars>",
+      "diagnosis": "<one sentence: 'matched expected', 'returned 0 expected > 0', 'cdp error: ...', or 'requires human review of <screenshot path>'>"
+    }
+  ],
+  "regression_checks": [
+    { "criterion": "...", "status": "passed | failed | skipped", "evidence": "..." }
+  ],
+  "blocking_issues": [
+    "<one-line summary of each failure or abort reason; empty array if everything passed>"
+  ],
+  "abort_reason": "<only present when status != completed: cascading_failures | budget_exhausted | malformed_recipe — one sentence>"
+}
+```
+
+## Boundaries (re-stated for clarity)
+
+- **No exploration.** Already covered in budgets, restating because this is the failure mode. The parent agent has Opus/Sonnet to investigate; you have Haiku to execute a script. Stay in lane.
+- **No fix suggestions.** `diagnosis` is descriptive only ("returned 0, expected > 0"). Never "you should change X" or "try Y instead".
+- **Truncate aggressively.** Stdout > 500 chars → truncate with `…[truncated, full output reproducible by re-running]`. Parent agent can re-run cherry-picked commands itself.
+- **One JSON block, nothing else.** Anything you print outside the JSON wastes the parent agent's context — which is the entire reason you exist.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@petukhovart/agent-view",
-  "version": "0.5.0",
+  "version": "0.7.0",
   "description": "CLI tool for visual verification of desktop apps (Electron/Tauri) via Chrome DevTools Protocol",
   "type": "module",
   "main": "dist/index.js",
@@ -11,6 +11,7 @@
     "dist",
     ".claude-plugin",
     "skills",
+    "agents",
     "README.md",
     "LICENSE"
   ],

package/skills/verify/SKILL.md

@@ -178,6 +178,38 @@ When two tools could answer the same question, prefer the one higher up the tabl
 
 ## Verification Workflow
 
+### Recipe Execution Mode (preferred when a recipe exists)
+
+If the developer points you at a `.claude/verify-recipes/<slug>.md` file, OR you discover one matching the current task via `ls .claude/verify-recipes/`, **delegate execution to the `verify-runner` subagent** instead of running commands yourself.
+
+Why: recipe execution is mechanical (run commands, compare to `Expected:`, report). It does not need Opus-level reasoning, but the raw output (DOM dumps, screenshots, eval results) easily exceeds 30k tokens of context noise. Delegating to a Haiku subagent keeps your context clean and cuts cost ~10×.
+
+**Pre-flight check (do this BEFORE spawning the runner):**
+
+1. `Read` the recipe.
+2. Confirm it has a `## Machine Preconditions` section. If missing → it's older 0.6.x format. Tell the user once: "this recipe doesn't have Machine Preconditions, so the runner can't distinguish setup failures from real bugs. Run anyway, or update the recipe first?" Default to running but flag failures with this caveat in the final summary.
+3. Read the `## Manual Preconditions` block out loud to the user (one tight sentence each) and ask: "is the app set up this way right now?" Wait for confirmation. If they say no — stop, don't waste a runner spawn.
+4. Resolve the window id once: `agent-view discover` → pick the main window's id.
+
+**Spawn:**
+
+5. Spawn `verify-runner` via the Agent tool with a prompt containing:
+   - Absolute `recipe_path`
+   - Resolved `window_id`
+   - `mode: full` (or `dry_run` if the user asked to validate the recipe first)
+   - Any extra context (e.g. "user is already logged in", "GIS widget already mounted")
+6. Wait for the JSON report.
+
+**Handle the report:**
+
+7. **If `status: precondition_failed`** → relay `failed_precondition` and `manual_preconditions_to_check` to the user verbatim. Do NOT spawn the runner again. Do NOT try to "fix" the missing setup yourself by clicking around — the user knows their app, ask them to do the manual setup and re-run.
+8. **If `status: cascading_failures` or `budget_exhausted`** → the recipe is likely stale (selectors/refs changed, UI restructured) or describes a flow that no longer matches the app. Show the first 1-2 failed steps to the user and ask whether to update the recipe (delegate back to `verify-recipe`) or investigate manually.
+9. **If `design_conformance_section: true`** in the report: also spawn `design-conformance-runner` in parallel, passing the `design_conformance_pairs` array. Merge both reports before answering the user.
+10. **If `requires_visual_review` steps** have no design ref attached: open each screenshot yourself with `Read` and decide pass/fail.
+11. **If individual `failed` steps** in an otherwise-completed run: re-run that specific failing command yourself for richer evidence to diagnose. Do not re-execute the whole recipe.
+
+Output to the user: a tight summary — what passed, what failed, what needs visual review, and (if any) which design conformance issues to fix. Do not paste the raw JSON unless asked.
+
 ### Ad-hoc Mode (standalone)
 
 After making code changes:

package/skills/verify-recipe/SKILL.md

@@ -1,185 +1,239 @@
----
-name: verify-recipe
-description: "Generates a concrete, command-by-command agent-view recipe for verifying a feature or bugfix. Use when the developer wants to write a verify-recipe.md, create a verification plan, build an agent-view recipe, or produce a verify checklist for a change they shipped. Triggers on: write a verify-recipe, write verification steps, generate verify steps for the feature/bug I just shipped/fixed, make a verify-recipe.md, what should I run to verify X, create a verification plan, agent-view recipe for this fix, verify checklist for this feature. Does NOT execute the checks — it authors the plan. For running checks against a live app, use the verify skill instead."
-allowed-tools: Read, Write, Bash(agent-view *)
----
-
-# Verification Recipe Generator
-
-You help the developer author a disciplined, cheapest-first verification recipe for a feature they shipped or a bug they fixed. You do not run the checks — you produce a `.claude/verify-recipes/<slug>.md` file that any AI coding agent can execute later.
-
-## What this produces
-
-A file at `.claude/verify-recipes/<kebab-slug>.md` containing:
-
-- **REPRO STEPS** — exact state the app must be in before checks run
-- **NARROWED SIGNAL** — the measurable indicator that proves success or failure
-- **EVIDENCE COMMANDS** — ordered `agent-view` calls, cheapest first, each annotated with what it proves
-- **POSITIVE-CASE ASSERTIONS** — what "pass" looks like for each command
-- **REGRESSION CHECKS** — adjacent paths that must not have broken
-
-Create the directory if missing: `mkdir -p .claude/verify-recipes`
-
-## Methodology
-
-Frame the recipe with **hard-debug** discipline. That skill defines the chain: REPRO → narrowed signal → minimize scope → root-cause check → fix verification. Apply the same logic here in authoring mode:
-
-1. Start from a reproducible starting state, not "open the app and poke around"
-2. Convert vague expectations ("looks right") into measurable signals ("store.user.role === 'admin'")
-3. Prefer the cheapest tool that can answer the question — a value check costs ~50 tokens, a screenshot costs ~6 000
-4. Include at least one negative-case check (the old symptom must no longer appear)
-5. Include at least one regression check (an adjacent flow must still work)
-
-## Tool-cost decision tree
-
-Pick the first row that can answer the question. Only go lower when the row above can't:
-
-| Question | Command | Why it's cheapest |
-|---|---|---|
-| Element exists / has specific text / role | `agent-view dom --filter "<text>" --depth 2` | Structured text, zero vision tokens |
-| App state, store value, computed flag | `agent-view eval "<expr>"` | Returns the value directly; DOM inference is wasteful and fragile |
-| What changed between action and final state | `agent-view watch "<expr>" --until "<condition>"` or `--max-changes 1` | `eval` shows the snapshot; `watch` shows the trajectory |
-| SharedWorker / ServiceWorker internal state | `agent-view eval --target <name> "<expr>"` | Workers have no DOM; this is the only path |
-| Did this action throw or warn silently? | `agent-view console --clear` before, `agent-view console --level error,warn` after | Catches uncaught exceptions and network failures invisible to DOM |
-| Layout, spacing, visual regression | `agent-view screenshot --scale 0.5` | Last resort — the only tool that sees pixels, but costs ~6 000 tokens |
-| Canvas / WebGL scene state | `agent-view scene --diff` | DOM is empty for canvas apps |
-
-**Anti-patterns to reject:**
-- Opening with a screenshot to "see the state" — use `dom --filter` or `eval` first
-- Using `eval` when `dom --filter` answers the question
-- Assertions that depend on transient state without `watch --until` to stabilize first
-- "Check that it looks right" — every assertion must be a concrete pass/fail criterion
-
-## Workflow
-
-### Step 1 — gather context
-
-When invoked, ask the developer in plain text (no tool calls yet):
-
-1. What was shipped or fixed? (feature name or bug description)
-2. What was the original symptom or expected behavior?
-3. Any known failure mode or edge case to cover?
-
-Wait for the response before continuing.
-
-### Step 2 — draft the recipe
-
-Use the answers to produce a recipe with these sections:
-
-```markdown
-# Verify: <feature or fix name>
-
-Generated: <date>
-Scope: <one sentence describing what this covers>
-
-## Repro Steps
-1. <Exact starting state — window open, user logged in, specific route, etc.>
-2. <Action(s) that trigger the behavior under test>
-
-## Narrowed Signal
-<!-- The one measurable thing that proves it works -->
-`<agent-view command>` must return `<expected value>`.
-
-## Evidence Commands
-
-### 1. <What this proves>
-```bash
-agent-view <command>
-```
-Expected: <concrete criterion — value, text, absence of error>
-Cost: ~<N> tokens
-
-### 2. ...
-
-## Positive-Case Assertions
-- [ ] <criterion>
-- [ ] <criterion>
-
-## Regression Checks
-- [ ] <adjacent flow> — `agent-view <command>` → `<expected>`
-
-## Anti-patterns avoided
-- <note any recipe-specific traps, e.g. "state resets on reload — watch needed before dom check">
-```
-
-### Step 3 — save the file
-
-Determine a kebab-slug from the feature/fix name (e.g. `login-redirect-fix`, `cart-total-display`).
-
-Save to `.claude/verify-recipes/<slug>.md`. Create the directory first if it doesn't exist.
-
-Confirm the path to the developer.
-
-## Worked example: "fixed login redirect bug"
-
-**Developer input:**
-> Fixed a bug where after login, the redirect went to `/home` instead of `/dashboard`. Store mutation `SET_REDIRECT_PATH` was missing. No visual change — purely a routing issue.
-
-**Recipe produced:**
-
-```markdown
-# Verify: Login Redirect Fix
-
-Generated: 2026-04-27
-Scope: Confirms that a successful login routes to /dashboard, not /home, and that the store mutation fires correctly.
-
-## Repro Steps
-1. App running, user logged out, at `/login`
-2. Fill email + password, click "Sign in"
-
-## Narrowed Signal
-`agent-view eval "router.currentRoute.path"` must return `"/dashboard"`.
-
-## Evidence Commands
-
-### 0. Setup — baseline console (before any action)
-```bash
-agent-view console --clear
-```
-
-### 1. Confirm redirect target
-```bash
-agent-view fill <email-ref> "admin@example.com"
-agent-view fill <password-ref> "password"
-agent-view click <signin-ref>
-agent-view watch "router.currentRoute.path" --until "router.currentRoute.path === '/dashboard'"
-```
-Expected: `replace /  "/login" → "/dashboard"` in watch output
-Cost: ~100 tokens
-
-### 2. Confirm mutation fired
-```bash
-agent-view eval "store.state.auth.redirectPath"
-```
-Expected: `"/dashboard"` (not `"/home"`, not `null`)
-Cost: ~50 tokens
-
-### 3. No errors during login flow
-```bash
-agent-view console --level error,warn
-```
-Expected: `(no console messages)`
-Cost: ~30 tokens
-
-### 4. Regression — logout returns to /login
-```bash
-agent-view click <logout-ref>
-agent-view eval "router.currentRoute.path"
-```
-Expected: `"/login"`
-Cost: ~60 tokens
-
-## Positive-Case Assertions
-- [ ] `router.currentRoute.path` === `/dashboard` after login
-- [ ] `store.state.auth.redirectPath` === `/dashboard`
-- [ ] No console errors during the flow
-
-## Regression Checks
-- [ ] Logout → `/login` still works
-
-## Anti-patterns avoided
-- Not using screenshot to confirm route (route is a string — eval is 120× cheaper)
-- watch used before eval so route change is confirmed to have settled, not just sampled mid-transition
-```
-
-**Saved to:** `.claude/verify-recipes/login-redirect-fix.md`
+---
+name: verify-recipe
+description: "Generates a concrete, command-by-command agent-view recipe for verifying a feature or bugfix. Use when the developer wants to write a verify-recipe.md, create a verification plan, build an agent-view recipe, or produce a verify checklist for a change they shipped. Triggers on: write a verify-recipe, write verification steps, generate verify steps for the feature/bug I just shipped/fixed, make a verify-recipe.md, what should I run to verify X, create a verification plan, agent-view recipe for this fix, verify checklist for this feature. Does NOT execute the checks — it authors the plan. For running checks against a live app, use the verify skill instead."
+allowed-tools: Read, Write, Bash(agent-view *)
+---
+
+# Verification Recipe Generator
+
+You help the developer author a disciplined, cheapest-first verification recipe for a feature they shipped or a bug they fixed. You do not run the checks — you produce a `.claude/verify-recipes/<slug>.md` file that any AI coding agent can execute later.
+
+## What this produces
+
+A file at `.claude/verify-recipes/<kebab-slug>.md` containing:
+
+- **MANUAL PRECONDITIONS** — human-readable setup steps (drag widget here, navigate to view X) that a person or the parent agent must do before any automated check
+- **MACHINE PRECONDITIONS** — runnable `agent-view` checks that prove the manual setup actually took effect; the verify-runner subagent runs these FIRST and aborts cleanly if any fail
+- **NARROWED SIGNAL** — the measurable indicator that proves success or failure
+- **EVIDENCE COMMANDS** — ordered `agent-view` calls, cheapest first, each annotated with what it proves
+- **POSITIVE-CASE ASSERTIONS** — what "pass" looks like for each command
+- **REGRESSION CHECKS** — adjacent paths that must not have broken
+- **DESIGN CONFORMANCE** (optional) — screenshot ↔ design reference pairs for the design-conformance-runner
+
+Create the directory if missing: `mkdir -p .claude/verify-recipes`
+
+## Why two kinds of preconditions
+
+The verify-runner subagent is intentionally tightly scoped — it executes commands and reports results, with hard budgets that prevent it from "looking around" when things don't match. That means **the recipe must clearly separate what a human does from what a machine verifies**.
+
+If you write a precondition as prose ("the GIS widget is dragged into a workspace cell"), the runner can't check it. If the user forgot to do it, the runner blunders into Evidence Commands that depend on missing UI, and either burns its budget on a recipe-stale abort or — worse, in older formats — flails trying to find the missing element.
+
+The fix: every Manual Precondition gets a paired Machine Precondition that proves it took effect. Drag widget into cell → check `cesiumReadyFlag === true`. Navigate to map mode → check `document.querySelector('.cesium-widget')` exists. Now if the user skips a step, the runner aborts cleanly on Phase 1 with a clear "do this first" message instead of diagnosing phantom bugs.
+
+## Methodology
+
+Frame the recipe with **hard-debug** discipline. Apply this chain in authoring mode:
+
+1. Start from a **reproducible, machine-checkable** starting state — not "open the app and poke around"
+2. Convert vague expectations ("looks right") into measurable signals ("store.user.role === 'admin'")
+3. Prefer the cheapest tool that can answer the question — a value check costs ~50 tokens, a screenshot costs ~6 000
+4. Include at least one negative-case check (the old symptom must no longer appear)
+5. Include at least one regression check (an adjacent flow must still work)
+6. **Every Manual Precondition needs a Machine Precondition counterpart.** If you can't think of one — interview the developer further before writing the recipe (see Step 1 below).
+
+## Tool-cost decision tree
+
+Pick the first row that can answer the question. Only go lower when the row above can't:
+
+| Question | Command | Why it's cheapest |
+|---|---|---|
+| Element exists / has specific text / role | `agent-view dom --filter "<text>" --depth 2` | Structured text, zero vision tokens |
+| App state, store value, computed flag | `agent-view eval "<expr>"` | Returns the value directly; DOM inference is wasteful and fragile |
+| What changed between action and final state | `agent-view watch "<expr>" --until "<condition>"` or `--max-changes 1` | `eval` shows the snapshot; `watch` shows the trajectory |
+| SharedWorker / ServiceWorker internal state | `agent-view eval --target <name> "<expr>"` | Workers have no DOM; this is the only path |
+| Did this action throw or warn silently? | `agent-view console --clear` before, `agent-view console --level error,warn` after | Catches uncaught exceptions and network failures invisible to DOM |
+| Layout, spacing, visual regression | `agent-view screenshot --scale 0.5` | Last resort — the only tool that sees pixels, but costs ~6 000 tokens |
+| Canvas / WebGL scene state | `agent-view scene --diff` | DOM is empty for canvas apps |
+
+**Anti-patterns to reject:**
+- Mixing manual setup and machine checks under a single "Repro Steps" heading. Always split into Manual Preconditions + Machine Preconditions.
+- Manual Precondition without a Machine counterpart — the runner can't verify it, so the user can silently violate it.
+- Opening Evidence Commands with a screenshot to "see the state" — use `dom --filter` or `eval` first
+- Using `eval` when `dom --filter` answers the question
+- Assertions that depend on transient state without `watch --until` to stabilize first
+- "Check that it looks right" — every Evidence assertion must be a concrete pass/fail criterion. The single legitimate exception is the `## Design Conformance` section, which delegates visual judgment to the design-conformance-runner subagent against an explicit reference image.
+- Inventing design reference paths (`.figma-refs/...`, `assets/mockups/...`) when the developer did not provide them. No refs → no Design Conformance section.
+
+## Workflow
+
+### Step 1 — gather context (interview the developer)
+
+When invoked, ask the developer in plain text (no tool calls yet). Wait for the response before continuing.
+
+1. **What was shipped or fixed?** (feature name or bug description)
+2. **What was the original symptom or expected behavior?**
+3. **Any known failure mode or edge case to cover?**
+4. **UI mode requirements**: Does this feature live behind a specific app mode/view that must be active before it appears (e.g., "map view, not settings panel"; "edit mode, not view mode"; "modal X must be open")? List every mode-toggle the user must have done.
+5. **Manual setup steps**: Beyond modes, what physical actions must the user do before checks can run (drag a widget into a cell, search for and select a map location, open a specific dialog, log in as a particular role)? Be precise — these become Manual Preconditions verbatim.
+6. **State assertions for each manual step**: For each item in (4) and (5), is there a JS expression or DOM selector that proves it happened? Examples: "after dragging the GIS widget — `pinia._s.get('gis-widget-root')?.cesiumReadyFlag` becomes true"; "after entering map mode — `document.querySelector('.cesium-widget')` exists; "after selecting a location — `selectedLocation` is truthy". If the developer doesn't know offhand, that's fine — ask them to point you at the store/composable/component where state lives and you can suggest expressions.
+7. **(Optional) Design references**: Local image paths to compare screenshots against (Figma exports, hand-off PNGs). **Only local files are supported.** If none — skip the Design Conformance section entirely.
+
+If the answers to (4)/(5) reveal something the developer can't pair with a machine check (6), say so explicitly: "I'll write `<step>` as a Manual Precondition with no Machine counterpart — that means if a user skips it, the runner won't catch it and may report misleading failures. Want to add a custom check?" Then either (a) get an expression from them, or (b) accept the gap and note it in the recipe's Anti-patterns section.
+
+### Step 2 — draft the recipe
+
+Use the answers to produce a recipe in this format:
+
+````markdown
+# Verify: <feature or fix name>
+
+Generated: <date>
+Scope: <one sentence describing what this covers>
+
+## Manual Preconditions
+<!-- Done by a human or the parent agent BEFORE invoking verify-runner. The runner does NOT execute these. -->
+1. <Action 1 — exact, no ambiguity. e.g. "Open the GIS widget by dragging it from the 'Edit workspace' panel into the upper-left cell.">
+2. <Action 2 — e.g. "In the map header search box, type 'Склад_1' and click the matching dropdown entry to fly the camera to that sublocation.">
+3. <Action 3 — e.g. "Zoom in until building details are visible (camera height < 1000 m).">
+
+## Machine Preconditions
+<!-- The verify-runner runs these FIRST. If ANY fail, it aborts with `precondition_failed` and shows the Manual Preconditions block to the user. -->
+- `agent-view eval "window.__dev !== undefined"` → must be `true`
+- `agent-view eval "!!window.__dev.pinia._s.get('gis-widget-root')?.cesiumReadyFlag"` → must be `true`
+- `agent-view eval "!!window.__dev.pinia._s.get('gis-widget-root')?.selectedLocation"` → must be `true`
+- `agent-view eval "document.querySelector('.cesium-widget') !== null"` → must be `true`
+
+## Narrowed Signal
+<!-- The one measurable thing that proves it works -->
+`<agent-view command>` must return `<expected value>`.
+
+## Evidence Commands
+
+### 1. <What this proves>
+```bash
+agent-view <command>
+```
+Expected: <concrete criterion — value, text, absence of error>
+Cost: ~<N> tokens
+
+### 2. ...
+
+## Positive-Case Assertions
+- [ ] <criterion>
+- [ ] <criterion>
+
+## Regression Checks
+- [ ] <adjacent flow> — `agent-view <command>` → `<expected>`
+
+## Design Conformance
+<!-- INCLUDE THIS SECTION ONLY IF the developer provided design refs in question 7. -->
+<!-- Each row pairs a screenshot command with the expected reference image path. -->
+<!-- The design-conformance-runner subagent reads this section, runs the screenshot commands, and visually compares against the expected refs. -->
+<!-- Do NOT invent design ref paths. Use exactly what the developer provided. -->
+
+| Step Label | Screenshot Command | Expected Reference |
+|---|---|---|
+| <area name e.g. "filter panel collapsed"> | `agent-view screenshot --crop "<area>" --scale 0.5` | `<absolute path to expected PNG/JPEG>` |
+| <area name> | `agent-view screenshot --window $W --scale 0.5` | `<absolute path>` |
+
+Tolerance: `normal` (default — flag deviations a designer would notice in code review). Use `loose` only if the developer says exact pixel parity is not required.
+
+## Anti-patterns avoided
+- <note any recipe-specific traps, e.g. "manual step 3 (zoom) has no machine counterpart — runner cannot detect insufficient zoom; mitigated by Evidence Step N which checks camera height">
+````
+
+### Step 3 — save the file
+
+Determine a kebab-slug from the feature/fix name (e.g. `login-redirect-fix`, `cart-total-display`).
+
+Save to `.claude/verify-recipes/<slug>.md`. Create the directory first if it doesn't exist.
+
+Confirm the path to the developer.
+
+### Step 4 — offer dry-run validation
+
+After saving, ask the developer:
+
+> The recipe is saved at `<path>`. Is the app running? If yes, I can spawn `verify-runner` in `dry_run` mode — it'll execute only the Machine Preconditions and the first Evidence Command (~5 commands total). That validates the recipe isn't broken before you commit a full run. Want me to run the dry-run? (yes/no)
+
+If yes:
+1. Get the window id with `agent-view discover`.
+2. Spawn `verify-runner` via the Agent tool with `mode: dry_run`, the recipe path, and the window id.
+3. Read the JSON report.
+4. If `status: completed` and dry-run preconditions+step 1 passed → tell the developer the recipe is healthy and ready for a full run.
+5. If `precondition_failed` → relay the `failed_precondition` and `manual_preconditions_to_check` so the developer knows what setup step to do (or what Machine Precondition to fix).
+6. If the first Evidence Command failed → flag it: the recipe likely has a stale ref/selector or assumes UI state that doesn't exist; offer to revise.
+
+If no — confirm the path and stop.
+
+## Worked example: "fixed login redirect bug"
+
+**Developer input:**
+> Fixed a bug where after login, the redirect went to `/home` instead of `/dashboard`. Store mutation `SET_REDIRECT_PATH` was missing. No visual change — purely a routing issue. No special UI mode — just the login page. Manual setup is "be on the /login route".
+
+**Recipe produced:**
+
+````markdown
+# Verify: Login Redirect Fix
+
+Generated: 2026-04-27
+Scope: Confirms that a successful login routes to /dashboard, not /home, and that the store mutation fires correctly.
+
+## Manual Preconditions
+1. App running, user logged out, browser at the `/login` route.
+
+## Machine Preconditions
+- `agent-view eval "router.currentRoute.path"` → must be `"/login"`
+- `agent-view eval "!!store.state.auth.user"` → must be `false` (logged out)
+
+## Narrowed Signal
+`agent-view eval "router.currentRoute.path"` must return `"/dashboard"` after sign-in.
+
+## Evidence Commands
+
+### 0. Setup — baseline console
+```bash
+agent-view console --clear
+```
+Expected: `Console buffer cleared`
+Cost: ~10 tokens
+
+### 1. Confirm redirect target
+```bash
+agent-view dom --filter "Email" --depth 2
+agent-view fill <email-ref> "admin@example.com"
+agent-view fill <password-ref> "password"
+agent-view click <signin-ref>
+agent-view watch "router.currentRoute.path" --until "router.currentRoute.path === '/dashboard'"
+```
+Expected: `replace /  "/login" → "/dashboard"` in watch output
+Cost: ~150 tokens
+
+### 2. Confirm mutation fired
+```bash
+agent-view eval "store.state.auth.redirectPath"
+```
+Expected: `"/dashboard"` (not `"/home"`, not `null`)
+Cost: ~50 tokens
+
+### 3. No errors during login flow
+```bash
+agent-view console --level error,warn
+```
+Expected: `(no console messages)`
+Cost: ~30 tokens
+
+## Positive-Case Assertions
+- [ ] `router.currentRoute.path` === `/dashboard` after login
+- [ ] `store.state.auth.redirectPath` === `/dashboard`
+- [ ] No console errors during the flow
+
+## Regression Checks
+- [ ] Logout → `/login` still works (`agent-view click <logout-ref>` then `agent-view eval "router.currentRoute.path"` → `"/login"`)
+
+## Anti-patterns avoided
+- Not using screenshot to confirm route (route is a string — eval is 120× cheaper)
+- watch used before eval so the route change is confirmed to have settled, not just sampled mid-transition
+````
+
+**Saved to:** `.claude/verify-recipes/login-redirect-fix.md`