@iamu-dev/iamu 0.7.0-beta.0 → 0.8.0-beta.1

package/dist/templates/skills/iamu-run.md

@@ -12,16 +12,18 @@ This skill resolves what scenario to run following a clear **Target Scenario Res
 2. **Active conversational context:** When `$ARGUMENTS` is empty or generic (e.g. "it", "that", "this", "run it", "walk it", "go"), and a scenario was created, modified, staged, or discussed in the active session — immediately resolve to that active scenario without prompting or re-scanning.
 3. **No argument & No active session scenario:** Check unfinished runs, then present a prioritized pickable list (reruns needing proof first, then drafts and ready-to-run).
 
+**`--target <url>` (or a bare `http(s)://...` URL in `$ARGUMENTS`):** when `$ARGUMENTS` contains `--target <url>` or a URL, take it out before resolving the scenario and persist it immediately with `iamu set testability --target <url>` (and if the resolved scenario had its own `target_url` override that was shadowing the project target, clear it with `iamu set scenario <slug> --no-target` unless the user asked for a scenario-only URL).
+
 **`--no-ux`:** when `$ARGUMENTS` contains `--no-ux`, take it out before resolving the scenario and skip the designer's review (step C3) for this run only: after A, record `iamu designer-record <run-id> --skipped "--no-ux"` so the report says it was skipped. There is no project setting for it: every other run gets a designer's review.
 
+**`--critic`:** when `$ARGUMENTS` contains `--critic`, take it out before resolving the scenario. This run is one critic pass in a builder ↔ critic loop (a gauntlet loop) the user orchestrates: the builder needs the verdict and the findings fast, not fixes or a design review. Skip the advisor (C2) entirely and skip the designer's review (C3): after A, record `iamu designer-record <run-id> --skipped "critic mode"`. Run A, B, C, D (and E in linked mode) as usual. In step 5, present the glance without the Advisor and Designer lines, and do not offer **directions** or **designer**. Per invocation only, like `--no-ux`. When the loop looks converged (every human test passes, or no open major or critical findings), add one line: `Loop looks converged: run once without --critic for the advisor's and designer's review.`
+
 $ARGUMENTS
 
 ## Prerequisites
 
 Before starting, check that `iamu/context.yml` exists and has `domain` filled in. If it is missing or empty, run the `iamu-setup` skill first — context grounds every walkthrough. If `iamu/` does not exist at all, run `iamu init` first.
 
-**Fast Preflight Type/Lint Gate:** Run `iamu preflight` before booting dev servers or walkers. If syntax, typecheck, or lint checks fail, halt immediately with the compiler diagnostic and fix them before launching the browser. Never burn minutes on a browser session against code that will not compile.
-
 ## Steps
 
 ### 0. Verify a driving surface
@@ -150,14 +152,26 @@ After bind + brief, the scenario is ready to execute. Continue to step 3.
 
 ### 3. Target
 
-**Web** — determine the target URL:
-1. If the user passed an explicit target or the scenario has `target_url`, use that.
-2. Otherwise, check `iamu/testability.md` for `target_url`.
-3. If still unconfigured, prompt the user for the target URL (live product, staging, or localhost).
+**Web** — determine and confirm the target URL:
+1. If the user passed `--target <url>` (or a URL in `$ARGUMENTS`), persist it with `iamu set testability --target <url>` (and clear any stale scenario override with `iamu set scenario <slug> --no-target`) and use that.
+2. Otherwise, check the scenario's `target_url`, then check `iamu/testability.md` for `target_url` and `status`.
+3. **Unverified or missing target gate:** If `iamu/testability.md` is missing, has no `target_url`, or has `status: draft` (an unverified guess from `iamu init`), do NOT blindly trust the guess. Ask one focused question to confirm the Target URL and Dev Command before probing or booting:
+   - If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+     - Question: "Target URL & Dev Command: Where does this app run locally?"
+     - Options:
+       1. "[Recommended] Use `<detected_url>` (`<dev_command>`)"
+       2. "Same command (`<dev_command>`), different port or URL — tell me the URL"
+       3. "Use a staging or remote URL — tell me the URL"
+   - Otherwise, state the detected URL and command and ask the user to confirm or provide the right URL.
+   - Persist the confirmed target immediately so `iamu/testability.md` is marked `status: verified`:
+     ```bash
+     iamu set testability --target <url> --dev-command "<dev_command>"
+     ```
+
 **Dev Server Preflight Check:**
 Verify target reachability before launching the walker with `iamu doctor --target <url>` (or a fast HTTP probe).
 If the target is a local URL (e.g. `http://localhost:*`, `http://127.0.0.1:*`) and is unreachable:
-1. Inspect `iamu/testability.md` for `Command:` under `## Target & Run Instructions` (or check `package.json` for a `dev` or `start` script).
+1. Inspect `iamu/testability.md` for `dev_command` (or `Command:` under `## Target & Run Instructions`, or `package.json` for a `dev` or `start` script).
 2. Prompt the user:
    - If interactive tool available:
      - Question: "Target URL <url> is unreachable. Boot dev server now?"
@@ -170,8 +184,11 @@ If the target is a local URL (e.g. `http://localhost:*`, `http://127.0.0.1:*`) a
      Proceeding with dev server boot — say "wait" to start manually or provide a different target URL.
 3. If Option 1 is chosen:
    - Launch `<dev_command>` in the background as a managed daemon process.
-   - Poll `<url>` with HTTP requests until it responds (timeout: 30s).
+   - Inspect the dev server stdout for the actual listening URL/port (e.g. if Vite or Next.js switches from `:5173` to `:5174`). If the actual URL differs from `<url>`, persist it immediately with `iamu set testability --target <actual_url>` and note the port change in one line.
+   - Poll the target URL with HTTP requests until it responds (timeout: 30s).
    - Once reachable, proceed immediately to the walkthrough.
+4. If Option 3 ("Specify a different target URL") is chosen:
+   - Ask for the URL and **persist it to disk** with `iamu set testability --target <new_url>` (and if the scenario had a stale `target_url` override, clear it with `iamu set scenario <slug> --no-target`) so future runs use the corrected URL automatically.
 
 Where the walk *starts* is part of the situation, not of the environment: a persona arriving from a video, an email or a search result lands on a specific page, not the home page. If the scenario has `entry_path`, `iamu start-run` resolves it against the target — pass the product's base URL as `--target`. If it has none but the situation clearly begins on a particular page, set it first with `iamu set scenario <slug> --entry <path>` (a path like `/en/episodes/1`, never a full URL), so this run and every later one start there. A walk started on the wrong page reports the detour as a finding.
 
@@ -207,18 +224,27 @@ Staging adds to a scenario and never changes what it is about: do not edit the n
 - `access.project` — from `iamu/testability.md` `access` (older projects: `iamu/context.yml`): HOW switching user is done in this product (a dev persona switcher, a storage key, seeded test accounts, a login form). Written once per project.
 - `access.persona` — from the persona file's `access`: WHICH user this persona is (an account name, a role, a switcher key).
 
-**Interactive Auth Handshake (for enterprise auth, SSO, 2FA, BankID):**
-If the product is behind enterprise login where automated dev persona switching is not configured:
+**Confirm Login & Auth When Unconfigured:**
+Never silently guess login credentials or auth strategy without confirming with the user. If `iamu/testability.md` has no `auth_strategy` / `access` configured (or is still `status: draft`) and the scenario requires a signed-in persona:
+1. Check the codebase and agent docs (`CLAUDE.md`, `AGENTS.md`, seed files, auth routes) to see if a dev login mechanism exists so you can pre-fill a recommendation.
+2. Ask one focused question:
+   - If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+     - Question: "Login & Auth for `<persona.name>` (`<persona.role>`): How should Iamu sign in as this persona?"
+     - Options:
+       1. "[Recommended] <Detected mechanism from codebase/docs, or 'Interactive login in Chrome' if none detected>"
+       2. "Use a dev switcher, header, storage key, or seeded test account — tell me how"
+       3. "Interactive login in Chrome (SSO / 2FA / manual sign-in)"
+       4. "No login needed (public / unauthenticated)"
+   - Otherwise, state the recommended login mechanism and ask the user to confirm or specify how to log in.
+3. Persist what the user confirmed: the project mechanism into `iamu/testability.md` via `iamu set testability --auth-strategy <strategy> --access "<mechanism>"`, and the persona's own account/role key with `iamu set persona <slug> --access "<key>"`. Passwords and tokens never go in either — name where they live (an env var, a vault entry) instead.
+
+**Interactive Auth Handshake (for `interactive_browser`, enterprise auth, SSO, 2FA, BankID):**
+If `auth_strategy` is `interactive_browser` or the product is behind enterprise login where automated dev persona switching is not configured:
 1. Open the browser to the target URL (`iamu browse start --run <run-id>` or browser tool).
 2. Prompt the human user:
    > 👉 **Please log in as `<persona.role>` (`<persona.name>`) in the opened browser window.** Tell me once you reach the dashboard (e.g. "I'm logged in") to hand control to the walker...
 3. Wait for the user to confirm, then let the walker drive the authenticated session.
 
-If automated switching exists:
-1. Check the project's own agent docs (`CLAUDE.md`, `AGENTS.md`) for a documented way to switch user or role.
-2. Map the persona to the closest account or role the product actually has. If nothing fits, say so.
-3. Persist what you learned: the mechanism into `iamu/testability.md` via `iamu set testability --access "<key>"`, and the persona's own key with `iamu set persona <slug> --access <key>`. Passwords and tokens never go in either — name where they live (an env var, a vault entry) instead.
-
 Carry the result into the walking prompt as the `## Access` section: the exact steps to become the persona, with the instruction to do them BEFORE the first recorded step.
 
 ### 4. Execute the walkthrough
@@ -249,6 +275,12 @@ iamu browse start --run <run-id>
 
 It sizes the page as the device the persona's tags name (`mobile`/`phone`, `tablet`/`ipad`, `desktop`/`laptop`; `start-run` prints it as `device`) and resizes a browser left at another persona's size.
 
+**Fresh walk in a loop (`--fresh`, `iamu browse` only).** When running iterative passes against a running browser (e.g. with `--critic` or `--fresh`), clear the origin's storage after `browse start` so each walk starts from clean app storage:
+
+```bash
+iamu browse clear-storage --run <run-id>
+```
+
 **Get the walker prompt.** The CLI composes the whole thing — persona, situation, brief, access, driving surface, methodology, dismissed findings and the run-directory contract (steps, screenshots, findings, `summary.json`). It also automatically writes `walker_prompt.txt` to the run directory (`iamu/.runs/<run-id>/walker_prompt.txt`):
 
 ```bash
@@ -273,7 +305,8 @@ A fresh subagent is NOT blind by default. On most hosts it still loads the proje
 
 **Model tiering & subagent dispatch:**
 - **Walker (Browser Navigation):** High turn count, mechanical tool-use. Use the **fast** model tier (`flash` or `haiku`) by default to cut walk time by ~60% and conserve session quota.
-- **Matcher & Judge:** Broad synthesis and semantic comparison. Use the **thorough** frontier tier (`pro`, `sonnet`, or active model) to prevent severity inflation.
+- **Matcher:** Short-text classification (same problem or not) into strict JSON that `match-record` validates. Use the **fastest** tier (`haiku` in Claude Code, `flash_lite` in Antigravity, else the fast tier).
+- **Judge:** Evaluates the human tests from the walk's recorded steps and findings (`judge_prompt.md`, text-only reading comprehension). Use the **fast** tier (`sonnet` in Claude Code, `flash` in Antigravity).
 
 ```
 # In Claude Code:
@@ -356,7 +389,7 @@ iamu summary <run-id> --worked "What worked 1" --worked "What worked 2" --questi
 
 **Post-walk pipeline (MANDATORY — do NOT skip any step):**
 
-After the walker returns, you MUST complete ALL of the following before presenting findings to the user. Do NOT present findings early. Do NOT ask the user anything. Execute steps A→B→C→D→E in order; the designer's review (C3) starts right after A and runs beside them.
+After the walker returns, you MUST complete ALL of the following before presenting findings to the user. Do NOT present findings early. Do NOT ask the user anything. Execute A, then B and C in parallel, then C2, D and E in order; the designer's review (C3) starts right after A and runs beside them.
 
 > **CRITICAL EXECUTION RULE (Zero Host File Tools):**
 > Never invoke host edit or write tools (`write_to_file`, `create_file`, `replace_file_content`, etc.) on any files in `iamu/` (including run artifacts, steps, findings, outlines, personas, scenarios, or guidance). All files in `iamu/` must be generated and modified exclusively via `iamu` CLI commands (`iamu new`, `iamu set`, `iamu step`, `iamu new-finding`, `iamu evaluate-record`, `iamu match-record`, etc.). If an entity needs a field updated (e.g. adding a capability to an outline), run `iamu set <type> <slug> ...` instead of editing files by hand. Record subagent JSON outputs directly through the CLI using `--data '<json>'` (or pipe via stdin).
@@ -371,13 +404,17 @@ This reads all steps, findings, and entity files, assembles `canonical.json`, ge
 
 **If the result has `blocked`**, the walker could not start the walk as it was set up (`iamu summary --blocked`): it could not become the persona, or the world the situation needs was not there. That is a setup problem, not a product finding. Skip B and C — a blocked run is never compared with earlier runs and never counts as a re-run. Tell the user in one line what was missing (`blocked.reason`), then run the `iamu-stage` skill with that reason as the starting point: fix the scenario's `state`, the persona's access, or the seed, and offer to run the scenario again. Findings the walker recorded before it stopped stay as they are. E still runs in linked mode; the report says the run was blocked.
 
+**B and C run in parallel.** The matcher (B) and the judge (C) answer different questions from different inputs, and the judge never reads the matcher's output. Run `iamu match` and `iamu evaluate` one after the other (both are instant), then dispatch both subagents at the same time. Record their answers one after the other as they arrive (`match-record` and `evaluate-record` both rewrite the report; never run them at the same time). Keep them separate: the judge must not see earlier runs' findings, so its verdict cannot drift toward "it was fixed, so it passes".
+
+**How to dispatch the matcher and the judge.** Do not paste the prompt into the dispatch; give the absolute path. Their whole prompt is: `Read <absolute path to match_prompt.md / judge_prompt.md> and answer exactly as it says. Everything you need is in that file. Do not open any other file, run any command or search any code. Reply with the JSON only.` Both are pure reading tasks; a subagent that goes looking for context (the repo, the CLI's source, other runs) costs minutes and can see things it must not.
+
 **B. Match findings to earlier runs.** Get the matcher bundle:
 
 ```bash
 iamu match <run-id> --json
 ```
 
-If `needed` is `false` (no earlier findings for this scenario, or none this run), skip to C. Otherwise, read the prompt from `iamu/.runs/<run-id>/match_prompt.md` directly and dispatch a matcher subagent with it as its only context (use the **thorough** model tier, e.g. `Model="pro"` in Antigravity, to accurately evaluate semantic equivalence). Record its JSON answer via `--data` (do NOT create a `matches.json` file yourself; pass the JSON string directly into `--data`):
+If `needed` is `false` (no earlier findings for this scenario, or none this run), there is no matcher subagent. Otherwise, read the prompt from `iamu/.runs/<run-id>/match_prompt.md` directly and dispatch a matcher subagent with it as its only context (use the **fastest** model tier: `haiku` in Claude Code, `Model="flash_lite"` in Antigravity). Record its JSON answer via `--data` (do NOT create a `matches.json` file yourself; pass the JSON string directly into `--data`):
 
 ```bash
 iamu match-record <run-id> --data '<raw_matches_json>'
@@ -391,7 +428,7 @@ This links recurrences to their earlier canonical finding, marks earlier finding
 iamu evaluate <run-id> --json
 ```
 
-Read the evaluation prompt from `iamu/.runs/<run-id>/judge_prompt.md` directly. Dispatch the evaluator as a subagent with that prompt (use the **thorough** model tier, e.g. `Model="pro"` in Antigravity, to prevent severity inflation). After the evaluator returns verdicts, record them locally with `--no-push` via `--data` (do NOT create a `verdicts.json` file yourself; pass the JSON string directly into `--data`):
+Read the evaluation prompt from `iamu/.runs/<run-id>/judge_prompt.md` directly. Dispatch the evaluator as a subagent with that prompt, at the same time as the matcher (use the **fast** model tier: `sonnet` in Claude Code, `Model="flash"` in Antigravity). After the evaluator returns verdicts, record them locally with `--no-push` via `--data` (do NOT create a `verdicts.json` file yourself; pass the JSON string directly into `--data`):
 
 ```bash
 iamu evaluate-record <run-id> --data '<raw_verdicts_json>' --no-prompt --no-push
@@ -399,7 +436,7 @@ iamu evaluate-record <run-id> --data '<raw_verdicts_json>' --no-prompt --no-push
 
 This links findings to human tests (`human_test_id`) and updates the report with judge verdicts.
 
-**C2. Advise: fixes and directions.** Get the advisor prompt:
+**C2. Advise: fixes and directions.** Skip in `--critic` mode. Otherwise get the advisor prompt:
 
 ```bash
 iamu advise <run-id> --json
@@ -415,7 +452,7 @@ Each entry is checked on its own. Entries that come back rejected (an invented f
 
 The judge (C) and the advisor (C2) are independent, so their subagents may run in parallel, but run `evaluate-record` and `advise-record` one after the other: both rewrite finding files. On a host without subagents, run the advise prompt yourself inline and record it the same way.
 
-**C3. Designer's review.** For every run (unless `--no-ux` was given), start it as soon as A is done:
+**C3. Designer's review.** For every run (unless `--no-ux` or `--critic` was given), start it as soon as A is done:
 
 ```bash
 iamu designer <run-id> --json
@@ -459,73 +496,61 @@ The `walker_prompt` from `iamu instructions walk` is the source of truth and con
 - **Dedup**: Skip findings in the dismissed list or already logged in the current run.
 - **Graceful degradation**: On judge evaluation failure, set verdicts to pending/null and proceed with report presentation.
 
-### 5. Present assessment — stay in the conversation
-
-You MUST output the complete Executive Scorecard to the chat stream FIRST. Build it from `iamu report <scenario-slug> --json`: the first row is this run, and its `summary` holds everything below already assembled (verdict, per-test labels, the since-last-run outcome of each earlier finding, findings with titles, where and recommendations, directions, observations). Do not re-read `canonical.json` or `verdicts.json` yourself. Output rich Markdown, not inside a code fence, so tables render. Write addresses and file paths out in full so a terminal can open them:
-
-### <summary.persona> · <summary.situation>
-<summary.steps> steps · Cloud: <cloud_url, the full https address> *(not on the cloud: the row's `report_path`, the absolute path to report.md)*
-
-If `summary.checks` is set, say first what this run was checking, in one line: `Re-checked <fixes> fixes waiting for a re-check: <fixed> confirmed fixed, <cameBack> came back, the rest not confirmed`, plus the directions that landed. Name the ones that came back.
-
-> **<summary.verdict.question>** **<summary.verdict.label>**
-> <summary.verdict.answer>
-
-If `summary.tests` has more than one test, add one line per test: `**<label>** · <question>`.
-
-If `summary.since` is set, show what happened to every earlier finding this run re-checked (`summary.since.items`), then one line for the new ones:
+### 5. Present the result — a glance, then the user decides
 
-**Since the last run** (<date of summary.since.baselineAt>)
+Build it from `iamu report <scenario-slug> --json`: the first row is this run, and its `summary` holds everything already assembled (verdict, per-test labels, the since-last-run outcome of each earlier finding, findings with titles and where, directions, observations). Do not re-read `canonical.json` or `verdicts.json` yourself.
 
-| Earlier finding | Now | Notes |
-|---|---|---|
-| <title> | **Resolved** / **Persists** / Not seen / Unclear | <item.note, or — > |
+The result is read in a terminal first. Show a **glance** the user can take in without scrolling: about 15 lines, no tables, one line per item, the verdict on top. The depth (the persona's reasoning step by step, the screenshots, every recommendation) lives in the walkthrough report; link it and do not retell it. Output Markdown, not inside a code fence. Write addresses and paths out in full so a terminal can open them.
 
-For a persisting finding, put its qualifiers in brackets: the `shift` ("less severe, major → minor") and "the fix did not hold" when `fixedBefore` is true (it was marked fixed before this run).
+**The glance**, in this order. Leave out every line whose data is empty:
 
-`+ <summary.since.added> new problems this run.` "Not seen" means the walk did not pass that way: never call it fixed.
+### <summary.persona> · <summary.situation> — **<summary.verdict.label>**
+> <summary.verdict.question> <summary.verdict.answer, its first sentence>
 
-**Findings** (<N> problems, <K> strengths), worst first:
+- `summary.tests` with more than one test: one line, `Tests: **<label>** <question, shortened to a few words> · **<label>** …`.
+- `summary.checks`: `↻ Re-checked <fixes> fixes: <fixed> confirmed fixed, <cameBack> came back (<their titles>)`.
+- `summary.since`: `Since <date of summary.since.baselineAt>: <n> resolved · <n> persist · <n> not seen · +<summary.since.added> new`. Name a persisting finding whose fix did not hold (`fixedBefore`): `(fix did not hold: <title>)`.
 
-| # | Finding | Severity | Where | What to do |
-|---|---|---|---|---|
-| 1 | <title> | **Major** | <where> | <first sentence or two of recommendation, or — > |
+Then the problems, worst first:
 
-Mark a finding that persists from the last run with `(persists)` after its title. When the designer gave a finding's design cause (a `summary.designer.issues` entry whose `design_cause_of` is that finding's `id`), add it under the row as `↳ Design cause (designer, <basis>): <what>`. Strengths go on one line under the table: `✓ Strengths: <title>; <title>`.
+**<N> problems** · <counts by severity, only the ones above zero, e.g. "1 major · 2 minor">
+1. **<Severity>** · <title> · <where>
+2. **<Severity>** · <title> · <where>
 
-If `summary.directions` is non-empty:
+One line per finding, numbered as in step 6, so "fix 2" means one finding. Add ` (persists)` after a title that persists from the last run, ` (unstable)` when the finding's `stability` is `unstable`, and ` ↳ design cause` when the designer gave one (a `summary.designer.issues` entry whose `design_cause_of` is that finding's `id`). No recommendation here: it is in the card. Show at most 7; past that, end with `+<n> more (<counts by severity>)`. With no problems, write `No problems found.` instead: the verdict still stands on its own, a run without findings can still answer NO.
 
-**Directions** (structural changes the advisor proposes)
+An **unstable** finding has come and gone across this scenario's runs without a fix recorded against it: it may be critic noise rather than a product problem. Whoever acts on the findings (the user, or a builder agent in a loop) confirms an unstable finding (re-run, or a person checks the screen) before changing code for it. When any are shown, add one line under the list: `(unstable) = came and went across runs without a fix; confirm before acting.`
 
-| Direction | Size | Absorbs | Re-run to check |
-|---|---|---|---|
-| <title> | <size> | <absorbs> findings | <verify> scenarios |
+`✓ <K> strengths: <title>; <title>` on one line.
 
-Reach is a prediction until those scenarios run again.
+Then, one short line each, only the ones that apply. These are counts; the detail is behind the words in the last line:
+- Designer (`summary.designer`): `Designer: <n> major or critical · <n> minor · <n> rules broken`, its count apart from the persona's, never one total. Add `judged against general craft` when `judged_against` is `general-craft`, and `written by the orchestrator` when `dispatch` is `inline`.
+- Advisor: `Advisor: <n> directions (absorb <n> findings)`, plus `· <n> notes` for `summary.observations` and `· <n> entries rejected` when the advise record (C2) rejected entries.
+- Design docs: `Design docs: <N> proposed edits — decided after the findings` (`design_proposals` from C2, `proposals` from C3). They wait for a person; never apply them yourself.
+- ⚠ Test setup (`summary.setupNotes`): `⚠ Test setup: <n> doubts about the test, not the product. A finding resting on one may not be real.` Never fold this one away.
+- Sync (E): `⚠ Sync: <n> findings changed by a teammate too` when the result has `conflicts`: name them and give the resolution (`iamu pull --force` to take theirs after copying your edits aside, or `iamu sync --keep-mine` to keep yours). When it has `pending_deletes`: `<n> deletions wait for you: check them, then run iamu sync --confirm-deletes`. Never run either yourself.
+- Design doc offer: only when the designer's result (C3) had `offer_template: true`: `No design doc yet (designer judged by general craft only — Iamu gets much sharper when it checks your own tokens, components, and rules): say "start it" (or run iamu-design) and I'll draft one from your code with you, or "no" and I won't offer again.` On "start it", after triage, follow the `iamu-design` skill, mode E. On "no", run `iamu design template --decline`.
 
-If `summary.designer` is set, add the **Designer's review**: the designer's judgement of these screens, never the persona's experience. Give its count apart from the persona's ("2 designer findings"), never one total.
-- One line on what it was judged against: the design docs in `summary.designer.design_files`, or, when `judged_against` is `general-craft`, `Judged against general craft: recording the project's design docs makes this review sharper`, followed by the `hint` command `iamu designer` printed. Say so when `dispatch` is `inline` ("written by the orchestrator, less independent").
-- When the designer's result (C3) had `offer_template: true` (no design doc recorded or found, and the offer not declined), add one line: `No design doc yet: I can start one from your code (tokens, components, the roles you test with) and fill in the rest with you. Say "start it", or "no" and I won't offer it again.` On "start it", after triage, follow the `iamu-design` skill, mode E. On "no", run `iamu design template --decline`. Never offer it when the result does not say so.
-- The rule breaks (`summary.designer.rules_broken`), one line each: `"<rule>" (<file>) on <screen>, step <n>`, then `<rules_held> rules held`.
-- The major and critical designer findings that are not a design cause (`summary.designer.issues` with no `design_cause_of`), one line each: `<id> · designer · <severity> · <basis> · <screen> · <title>`, with `breaks "<rule>"` when it breaks one; then the count of minor and nit ones in one line.
+Then the link to the full walkthrough, which shows the persona's reasoning beside each screenshot:
 
-If `summary.observations` is non-empty, end with **Also worth knowing** (the advisor's notes): one bullet each, `Not walked: <title>` (coverage_gap) or `Feature risk: <title>` (feature_risk).
+`Walkthrough: <the cloud URL from E>`. Not on the cloud: run `iamu open <run-id> --local --print` and give the path it prints (the local HTML report).
 
-If the advise step or the designer proposed design doc edits (`design_proposals` in the advise result, `proposals` in the designer result), add one line: `Design docs: <N> proposed edits — decided after the findings`. They wait for a person; never apply them yourself.
+End with the choices on one line, the recommended one first, and **stop**: the user reads the result before deciding. Do not open Finding #1, and do not use a question tool here, since it covers the glance.
 
-If `summary.setupNotes` is non-empty, add **Test setup** with one bullet each. These are doubts about the test, not the product (missing data, an account that cannot see enough, a date the scenario assumes). Offer the `iamu-stage` skill to fix the setup before the next run; a finding that rests on a setup doubt may not be real.
+`Next: **triage** (one by one from #1) · **fix 2** · **directions** · **designer** · **since** · **setup**`
 
-Do NOT output `### What Worked` paragraphs or lengthy bullet essays. Keep the scorecard scannable: the tables are the summary.
+Name only the words that apply. Recommend **directions** when the advisor proposed any, **setup** when there are setup doubts, else **triage**. With no problems and no major or critical designer findings, offer only the open words (`designer`, `since`), or nothing.
 
-**Zero-Friction Triage Transition (Eliminate Meta-Prompt Gate):**
-Do NOT prompt the user with a generic "How would you like to proceed?" multiple-choice modal. That intermediate prompt adds cognitive friction, duplicates the triage options, and obscures the assessment scorecard.
+**Behind the words.** When the user says one, show it, then offer the same Next line again (without the word just used):
 
-- **If `summary.findings` is empty (no problems):**
-  Output: "No problems found in this run." The verdict above still stands on its own: a run without findings can still answer NO.
-  Do not enter finding triage for the persona; when the designer's review has major or critical designer findings, triage those (step 6 lists them the same way), then the proposed design doc edits.
+- **triage** / a number: step 6. **fix 2** / "fix 1 and 3": step 6B, which shows the cards and waits for a yes before any edit.
+- **directions**: step 6, "Directions come first".
+- **since**: each item of `summary.since.items` on one line, `<Resolved / Persists / Not seen / Unclear> · <title> · <item.note>`, with a persisting one's `shift` ("less severe, major → minor") and "the fix did not hold" when `fixedBefore`. "Not seen" means the walk did not pass that way: never call it fixed.
+- **designer**: the designer's judgement of these screens, never the persona's experience. One line on what it was judged against (the files in `summary.designer.design_files`, or for `general-craft`: `Judged against general craft: recording the project's design docs makes this review sharper`, and the `hint` command `iamu designer` printed). Then the rule breaks, one line each: `"<rule>" (<file>) on <screen>, step <n>`, then `<rules_held> rules held`. Then the major and critical designer findings that are not a design cause, one line each: `<id> · <severity> · <basis> · <screen> · <title>`, with `breaks "<rule>"` when set; then the count of minor and nit ones.
+- **notes**: the advisor's `summary.observations`, one bullet each, `Not walked: <title>` (coverage_gap) or `Feature risk: <title>` (feature_risk).
+- **setup**: `summary.setupNotes`, one bullet each (missing data, an account that cannot see enough, a date the scenario assumes); offer the `iamu-stage` skill to fix the setup before the next run.
 
-- **If `summary.findings` is not empty:**
-  Output the Executive Scorecard above to chat FIRST, and advance IMMEDIATELY to triage on **Finding #1 of <total>** (Step 6 below) in the same turn. The user can choose to queue to fix, queue all remaining fixes (batch accept), dismiss, or discuss directly from Finding #1.
+Do NOT output `### What Worked` paragraphs, open-question lists or the recommendations in the glance: the walkthrough report holds them.
 
 ### 6. Conversational Triage & Guided Review
 
@@ -677,12 +702,12 @@ When the user asks to review findings one by one:
      6. In linked mode, run `iamu sync --json` once so teammates see the verified decisions.
 
 #### B. Direct Batch Actions ("fix 1 and 2", "fix all critical")
-Read the finding details from the canonical JSON (already in context), inspect the code, make the edits, and update frontmatter to `triage_status: addressed` with `triage_note`.
+The glance shows no recommendations, so never fix from a number alone. First show each named finding's card (step 6A format, without the decision prompt), then one line: `Fix <these N> as shown? Say "yes", or name the ones to leave out.` Only on a yes, fix each with the fix loop (`iamu fix-brief <slug> --json` and its `loop`; findings on one page go together as one change; a designer finding from `iamu fix-brief <run-id>#D<n> --json`) and record each with `iamu triage <slug> --status addressed --note "<summary of fix>"`. Then continue as in item 3's "Executing the queued fixes" from `iamu validate --all`.
 
 #### C. Ad-hoc Questions & Challenges ("why did Karl do that?", "is #2 really a bug?")
 Answer directly using persona brief context and step evidence. If the walker got confused or misinterpreted intended behavior, recommend dismissing as `walker_error` or `not_relevant` rather than adding unnecessary code.
 
-**Linked mode: publish triage decisions.** When the user is done fixing and dismissing, run `iamu sync --json` once so teammates see the decisions (and any team request for these findings closes). Report it in one line (`Synced 3 findings to Iamu Cloud.`), with conflicts handled as in item 6. Do not sync after every single edit.
+**Linked mode: publish triage decisions.** When the user is done fixing and dismissing, run `iamu sync --json` once so teammates see the decisions (and any team request for these findings closes). Report it in one line (`Synced 3 findings to Iamu Cloud.`), with conflicts and pending deletions handled as in step 5's Sync line. Do not sync after every single edit.
 
 **Do NOT** dump the user at file paths. The report and finding files exist for later reference, but the conversation is the triage surface. Mention artifacts only if the user asks for them or wants to share the report externally. The cloud link is the exception: in linked mode it IS the shareable report, so it always goes in the presentation.