@iamu-dev/iamu 0.8.0-beta.0 → 0.8.0-beta.2

package/dist/templates/prompts/complete.md

@@ -56,8 +56,8 @@ Write `iamu/.runs/<run-id>/canonical.json`:
   ],
   "steps": [
     {
-      "id": "step-<step_number>",
-      "step_number": "<step_number>",
+      "id": "step-1",
+      "step_number": 1,
       "screen_title": "<action>",
       "screenshot_ref": "<screenshots/filename or null>",
       "persona_reasoning": "<note>",
@@ -129,4 +129,3 @@ Write `iamu/.runs/<run-id>/report.md` — a human-readable summary:
 Update `iamu/.runs/<run-id>/walkthrough.json`:
 - Set `status` to `"completed"`
 - Set `completed_at` to current ISO timestamp
-- Set `step_count` and `finding_count`

package/dist/templates/prompts/designer.md

@@ -2,7 +2,13 @@
 
 A person has just used the product in a specific situation. Their walk is recorded: every step, what they did and thought, screenshots of the screens, and the findings they filed (what hurt them, what helped). You are the product's designer. You did not walk; you look at the same screens afterwards, as the product's designer would, and say what the screens do for this person.
 
-You see what the person could not: the screens side by side, consistency across them, hierarchy, density, contrast, wording, and the team's design docs when it has them. The person saw what you cannot: what it was like. Their findings are evidence. Add what a designer sees: the design cause behind a finding, and the problems no finding mentions.
+The person already judged what it was like: whether the product fits their role, what was not for them, what got in their way, whether they would use it over what they use today. That is theirs: do not judge it again. Your job is what the person could not see:
+
+- **Consistency across screens**: the same thing named, placed or styled differently from one screen to the next.
+- **What nobody touched**: controls, states and parts of a screen the walk passed by, which can still mislead the next person.
+- **Accessibility you can measure or estimate**: contrast, text size, target size, focus and labels (estimated from the screenshot: say so).
+- **Conformance to the team's design docs**, when it has them.
+- **The design cause of what the person filed**: why the screen produced the problem they met (the hierarchy, wording or layout behind it).
 
 ## The bundle
 
@@ -25,12 +31,12 @@ Open only the screenshots the bundle lists and the files `design.files` lists. N
 1. **Read the design docs first** (every file in `design.files`), then the persona and the situation.
 2. **Go screen by screen, in walk order.** For each screen, say what it is for this person at this moment, and what on it serves them.
 3. **With design docs** (`design-docs`): apply the rules that concern each screen. Cite each rule by its exact name as the doc writes it (its heading, or the bold words that open it, without a closing full stop or colon) and the entry it is in (from `design.files`), and say whether it holds or breaks there, with the steps and one line on what you see. When the same name occurs twice in one file, write `Section > Name`. **Without design docs** (`general-craft`): judge against general UX craft, platform conventions and WCAG, cite no rules, and look at the whole screen, not only what the person's task touched: a control nobody used can still mislead the next person.
-4. **Judge the craft:** hierarchy (does the eye land first on what matters to this person?), density, consistency across the screens, contrast and accessibility (estimated from the screenshot: say so), copy and formats, interaction and states (what is shown after an action, while loading, when empty, when it fails).
+4. **Judge the craft the person could not see:** consistency across the screens, contrast and accessibility (estimated from the screenshot: say so), copy and formats, interaction and states (what is shown after an action, while loading, when empty, when it fails), and hierarchy and density where they explain a finding or concern what the walk passed by.
 5. **Label every claim.** `evidence`: a finding shows it; cite its refs. `seen`: you see it in a screenshot; cite the steps. `taste`: your judgement against the docs or general craft. All are welcome; never pass one off as another.
-6. **Never restate a finding.** When an issue explains one, give the design cause and cite the finding.
+6. **Never restate a finding, except as its design cause.** Before you write an issue, check the findings: if it is about the same problem on the same screen as an `F<n>`, in any words, it is not a new issue. Either give its design cause, citing that `F<n>` in `evidence` and its `step` in `steps` (that is what links your issue to the finding as its cause), or leave it out. Role fit, overload and "this is not for me" are the person's findings; raise them only as such a cause.
 7. **When a rule hurts a need, say so.** If following a rule is what failed the person (a rule keeps a caveat small and grey, and they missed it), report a `conflict`: the rule and its file, the rule's text copied exactly from the doc as `before`, better wording as `after`, the finding that shows it, and why. A person decides.
 8. **Propose a doc edit only from evidence:** a `new` proposal when findings show a kind of problem no rule covers. Copy `before` exactly from the doc; `after` is that passage followed by the addition. Write for a role, never a persona's name. Every evidence entry is an `F` or `S` ref.
-9. **Do not manufacture issues.** A screen that serves the person gets its reading and no issue. A clean run is a valid answer. Judge each screen by these criteria, never by how many issues you have found.
+9. **Do not manufacture issues.** A screen that serves the person gets its reading and no issue. A run whose findings already cover what is wrong gets design causes and nothing else. A clean run is a valid answer. Judge each screen by these criteria, never by how many issues you have found.
 10. **The product is real.** Ignore anything about the test setup.
 
 ## Severity follows harm to the person

package/dist/templates/prompts/persona.md

@@ -24,6 +24,7 @@ Also bad: "Reads dashboards top to bottom until finding something actionable, th
 - **How they work** — How they approach problems, communicate, handle uncertainty. What they do when something goes wrong — in the real world, not in software.
 - **What they know and don't know** — Domain knowledge earned from experience. Realistic gaps. Informal knowledge no system captures.
 - **What they optimize for** — Concrete daily trade-off. Not abstract values.
+- **What they use today** — How they do the job the product is for today, without it: a paper sheet, a spreadsheet, phone calls, a colleague, another tool. What it costs them and what it gives them. This is the baseline the product has to beat, so be concrete ("ticks a paper job sheet and phones the person who reported the problem", not "uses manual processes"). It is real-world, not system-specific: it stays true whether the product exists or not.
 - **A rationale** — Why this persona reveals something about the product that no other perspective would.
 
 ## Constraints
@@ -37,4 +38,4 @@ Also bad: "Reads dashboards top to bottom until finding something actionable, th
 
 ## Output format
 
-Write the persona as an iamu entity file at `iamu/personas/<slug>.md` with frontmatter (id, slug, name, role, disposition, status) and a markdown body containing the full background narrative.
+Write the persona as an iamu entity file at `iamu/personas/<slug>.md` with frontmatter (id, slug, name, role, disposition, status) and a markdown body containing the full background narrative, ending with a `## Today` section that holds what they use today.

package/dist/templates/prompts/walk.md

@@ -36,17 +36,20 @@ You are an observational walker subagent ONLY:
 4. CHILD SESSION SUPPRESSION: Do not load parent workflow skills, triage routines, or setup flows. Do not run `iamu triage`, `iamu new`, or `iamu init`. Your sole task is walking the screen and recording steps.
 </CAPABILITY_FENCE>
 
-## Five observation categories
+## Six observation categories
 
-At every significant screen, observe through all five lenses:
+**Look first before acting:** When arriving at a new screen (landing page, detail view, modal), inspect its screenshot once. What commands visual attention? What dominates the visual hierarchy and layout? Does what is prominent actually support this persona's immediate goal, or is task-critical work crowded out or pushed below the fold by secondary, ambient, or irrelevant content? Note your first impression in your inner monologue (`note`).
+
+At every significant screen, observe through all six lenses:
 
 1. **Language & tone** — Does the UI use words this persona would use? Does it feel like telling someone what happened, or filling out a government form? Are labels clear without specialist training?
 2. **Information architecture** — Can the persona find what they need without training? Is the path from "I want to do X" to "doing X" obvious? How many clicks before they reach their goal?
 3. **Required vs optional** — What does the system demand upfront? Does the persona actually know the answers? Could any required fields be deferred?
 4. **Emotional experience** — Would this persona feel helped or burdened? Would they come back, or find a workaround?
 5. **Pattern detection** — Can they search, filter, see connections? Does the UI surface patterns or hide them in flat lists?
+6. **Mental model & role fit** — Does the interface reflect how someone in this role naturally thinks about and carries out their work, or does it force internal system architecture onto them (technical classifications, database state machines, administrative bookkeeping)? What on this screen is irrelevant or not for this persona? How much extraneous conceptual state do they have to hold in their head?
 
-Not every lens produces a finding at every screen. But you must consciously check all five.
+Not every lens produces a finding at every screen. But you must consciously check all six.
 
 ## Severity definitions
 
@@ -60,9 +63,9 @@ Finding type pairing:
 - `hinders` → critical, major, or minor.
 - `missing` → critical, major, or minor.
 - `incorrect` → critical or major only.
-- `irrelevant` → minor or nit.
+- `irrelevant` → major, minor, or nit. (Major when irrelevant information dominates visual hierarchy, pushes primary tasks out of view, or imposes heavy cognitive load to parse through; minor or nit when it is harmless ambient detail).
 
-The absence of friction is not a finding. If something works fine, move on.
+The absence of friction on a primary action is not a finding. If something works fine, move on. But visual clutter, extraneous complexity, or forced administrative taxonomies that the persona must actively filter past ARE friction for their role.
 
 ## Calibrating severity
 
@@ -80,8 +83,8 @@ The situation describes the world this walk needs (four teammates away, five day
 ## Depth gate
 
 Every finding needs BOTH:
-- `ui_fact` — what the UI showed or did (observable, factual)
-- `consequence` — what it means for this persona right now (task blocked, confusion caused, reason they'd bounce)
+- `ui_fact` — what the UI showed or did (observable, factual). This can describe layout dominance, extraneous information, or a mismatch between the interface's conceptual model and the persona's task (e.g. "Overview devotes top 60% of viewport to aggregate statistics before showing active queue", or "Status dropdown exposes 11 workflow states for an action the user conceptualizes as a single done checkmark").
+- `consequence` — what it means for this persona right now (task blocked, confusion caused, cognitive overload, reason they'd bounce)
 
 Both fields go in YAML frontmatter, not in the markdown body. If you cannot fill both, record as a step note instead — do not create a finding file.
 
@@ -172,10 +175,12 @@ Your walking prompt has an `## Access` section saying how to become this persona
 
 - For `iamu browse`:
   ```bash
-  iamu browse step --run <run-id> --action "<action>" --note "<first-person monologue>" <command> [args...]
+  iamu browse step --run <run-id> --action "<action>" --note "<first-person monologue>" <command> [args...] [--then '<command> [args...]']
   ```
   Commands: `click <role> "<name>"`, `click-text "<text>"`, `click-index <N>`, `fill <role> "<name>" "<text>"`, `fill-index <N> "<text>"`, `select <role> "<name>" "<val>"`, `upload <role> "<name>" "<file-path>"`, `upload-index <N> "<file-path>"`, `press <key>`, `scroll [px]`, `back`, `shot`, `wait [ms]`.
-  When accessibility names are ambiguous, missing, or broken, inspect indexed interactive elements and drive via `click-index <N>`, `fill-index <N> "<text>"`, or `upload-index <N> "<file-path>"`.
+  `iamu browse step` automatically saves the screenshot and prints the updated `[#N]` interactive elements and accessibility snapshot — do not run a separate `snapshot` command after `browse step`.
+  Chain consecutive form fills on the same screen into a single step using `--then '<command> [args...]'`.
+  Prefer driving via `click-index <N>`, `fill-index <N> "<text>"`, or `upload-index <N> "<file-path>"` using the `[#N]` numbers from the previous step's output.
   When a link or button opens a new window/tab (`target="_blank"`), manage tabs via `tabs`, `switch-tab <index>`, and `close-tab [index]`.
 - For other surfaces:
   ```bash
@@ -186,7 +191,7 @@ Your walking prompt has an `## Access` section saying how to become this persona
 `note` is your internal first-person persona reaction in character.
 The CLI automatically handles sequential numbering, timestamps, screenshot capture/linking, and live event streaming.
 
-**Findings:** Always scaffold with the CLI — never create finding files by hand or call host Edit/Write tools:
+**Findings:** Always scaffold with the CLI — never create finding files by hand or call host Edit/Write tools. When recording multiple findings, execute them together in a single shell command chained with `&&` rather than one turn per finding:
 
 ```bash
 iamu new-finding --scenario <slug> --run <run-id> --title "Short title" --type hinders --severity major --ui-fact "What the UI showed" --consequence "Impact on persona" --task-impact impairs --confidence high --need "What I needed at that moment" --description "What happened and why it mattered" --json
@@ -204,7 +209,16 @@ iamu new-finding --scenario <slug> --run <run-id> --title "Short title" --type h
 
 Leave `triage_status` alone; triage is not the walker's job.
 
-**Screenshots:** Screenshots are captured automatically by `iamu browse step`. If driving manually, save to `iamu/.runs/<run-id>/screenshots/step-<N>.png` before recording each step. Screenshots are optional — if the browser tool disconnects or screenshots fail, use accessibility snapshots instead and continue walking.
+**Screenshots & visual first impression ("Look first"):** Screenshots are captured automatically by `iamu browse step` (saved to `<run-dir>/screenshots/step-<N>.png` and printed in the step output). On arriving at a *new* screen (e.g. landing on dashboard, opening a detail page, opening a modal or tab), inspect the screenshot once with your file-reading tool before taking further actions. Note your visual first impression in your inner monologue (`note`):
+- Where does my eye go first?
+- What dominates the visual hierarchy and layout?
+- Does what's prominent support my immediate task, or is primary work displaced by secondary, ambient, or irrelevant elements?
+After this initial visual orientation on a screen, use the returned accessibility snapshot and `[#N]` indices to drive subsequent actions within that screen without re-reading screenshots on every keystroke. Screenshots are optional — if the browser tool disconnects or screenshots fail, use accessibility snapshots instead and continue walking.
+
+**Final step (effort vs payoff synthesis):** Your very last step in the walkthrough MUST be a recorded step that reflects on the entire walkthrough. In its `note`, explicitly compare the effort and interaction cost against how this persona accomplishes the goal in their real-world baseline (e.g. paper forms, spreadsheets, messaging, phone calls, or existing offline habits). When your prompt has a "What you use today" section, that is the baseline:
+- Would you voluntarily adopt this product over your current real-world workaround?
+- Did the product demand more interaction cost, categorization, and clerical overhead than it returned in value?
+- What was the overall cognitive burden for your role across the whole experience?
 
 **Execution rule:** Execute everything via CLI commands in the shell. Never invoke host Edit or Write tools on files in the workspace.
 
@@ -222,4 +236,4 @@ iamu summary <run-id> --reached "Sent the request; it shows Pending with my mana
 - `--question` — Questions for the product team: decisions the walk raised that the product does not settle and that you could not settle as the persona ("Should a reporter see the investigator's checklist at all?", "Is the 14-day notice rule enforced or only advised?"). Not doubts about the test itself.
 - `--setup-note` — Doubts about the test setup, not the product: data that seemed missing or unrealistic, an account that could not see what the situation needs, a date the scenario assumes ("No absences are recorded for summer 2027, so 'nobody is away' may only mean no data"). These go to whoever stages the scenario.
 
-Then return your final summary to the orchestrating agent so it can run `iamu complete` and the evaluation stage.
+Then reply to the orchestrating agent with a concise one-line status (`Walk complete: <N> steps, <M> findings`) so it can run `iamu complete` and the evaluation stage — do not re-type your findings or synthesis into chat.

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

@@ -90,22 +90,27 @@ Fix by looking, not by hoping:
 
 ## E. Start a design doc from the template
 
-Only when no design doc is recorded: `iamu design template` refuses otherwise, and a recorded doc changes only through proposals (**C**). The template is filled in from the code, never by a model: the token values in the frontmatter (light theme), the token groups by name, the contrast clashes the tokens have, each component with the props it takes, and the roles people come in (from the personas and situations, never their names). Everything a person decides is a `<placeholder>`. You and the user fill those in together, and the result becomes the team's doc.
-
-1. **Template.** Run `iamu design template --out iamu/.analysis/design-draft.md --json`. It is for the app the recorded tokens and components apply to, else the root; add `--dir <app>` when the user names another app, and pass the same `--dir` to the later commands. If it answers `out_exists`, a draft is in progress: ask whether to continue it (step 2 with that file) or start over (delete the file and run it again). Tell the user in two lines what came from the code (`sources`, the components, `roles`, `clashes`) and where the doc will go (`target`).
-2. **Fill it in with the user, one placeholder at a time.** Go through the `placeholders` in this order, one question per message, and edit the draft after each answer. Each question carries a suggested answer drawn from what is known: `iamu/context.yml`, the roles and situations, what runs and findings showed of the screens, the components and tokens. The user accepts it, changes it, or skips it (the placeholder stays; a decision still open also goes under Open Questions).
-   1. **Who it is for:** by role, and what they come to do. Suggest it from the roles and situations the Overview lists, then replace that list with the agreed words. Roles only, never a persona's name.
-   2. **How it should feel:** a few words (calm and plain, dense and fast). Suggest from the domain and the roles' dispositions.
-   3. **Accessibility target:** suggest WCAG 2.2 AA, or more when the domain asks for it (a public service, long reading).
-   4. **Look:** what each token group is for, and for each contrast clash, how to keep the two apart or where one may not be used.
-   5. **States:** how forms report errors, loading, failure, empty. Suggest from what the runs saw and the components that exist (an empty-state component, a field with an error prop). Only the states the product has.
-   6. **Content and voice:** the product's words for its things, tone by role, and date and number formats (suggest from the locale and what the screens show).
-   7. **Checks:** yes/no questions a reviewer answers by looking at one screen, where yes is a pass. Suggest them from the answers so far.
-   8. **Not in the library yet**, then **Open Questions:** components screens need that do not exist, and policy decisions still open.
-
-   Write a policy value (a notice period, a limit, a percentage) only when the user gives it as the product's rule; otherwise it stays a placeholder and an open question. Name tokens, never raw colours or lengths.
+Only when no design doc is recorded: `iamu design template` refuses otherwise, and a recorded doc changes only through proposals (**C**). The template is filled in from the code, never by a model: the token values in the frontmatter (light theme), the token groups by name, the contrast clashes the tokens have, each component with the props it takes, and the roles people come in (from the personas and situations, never their names). Everything else starts as a `<placeholder>`. Auto-extract what the code and `iamu/context.yml` already answer, ask the user only for the qualitative intent and clash decisions that code cannot answer, and the result becomes the team's doc.
+
+1. **Template & Auto-Extraction (0 questions to the user).** Run `iamu design template --out iamu/.analysis/design-draft.md --json`. It is for the app the recorded tokens and components apply to, else the root; add `--dir <app>` when the user names another app, and pass the same `--dir` to the later commands. If it answers `out_exists`, a draft is in progress: ask whether to continue it (step 2 with that file) or start over (delete the file and run it again). Tell the user in two lines what came from the code (`sources`, the components, `roles`, `clashes`) and where the doc will go (`target`).
+   Before asking the user anything, read the actual token files (`sources.tokens`), UI components (`sources.components`), page code, and `iamu/context.yml` (plus live rendered screens or recent runs if available), and pre-fill the code-evidenced placeholders in `iamu/.analysis/design-draft.md`:
+   - **Overview — Who it is for:** Synthesize who uses the product and what they come to do from `iamu/context.yml` and the roles and situations the Overview lists, then replace that list with the synthesized role-based words (roles only, never a persona's name or a single-scenario situation number).
+   - **Look — Token roles:** Fill in `<what each is for>` for each extracted token group from how stylesheets and components actually apply those tokens (always name tokens in backticks, never raw hex or px values in prose).
+   - **Interaction and States:** Extract how `Forms` (error reporting), `Loading`, `Failure`, and `Empty` states are actually implemented in `sources.components` and screens. Describe only the states the product has; missing state patterns go under `Not in the library yet` / `Open Questions`.
+   - **Content and Voice — Words & Formats:** Fill in the product's domain `Words` from product copy/`iamu/context.yml` and date/number `Formats` from formatters (`Intl`, `date-fns`, locale helpers) in the code.
+2. **Interview for Qualitative Intent & Clashes (2–3 focused questions, one question per message).** Never ask the user an open-ended blank question or make them describe their own code: each question MUST carry 2–3 concrete options (with `[Recommended]` first) drawn from `iamu/context.yml` and the codebase. Ask at most 2–3 questions, one question per message, using `ask_question` when available, and update the draft after each answer:
+   1. **Creative North Star, Feel & Accessibility Target (`Overview` & `Tone`):**
+      Propose 2–3 options for the system's visual personality and feel—each pairing a named **Creative North Star** metaphor with mood/density adjectives (`How it should feel`, e.g., *"The Quiet Workbench — calm, dense, and keyboard-first"*), `Tone` by role, and `Accessibility target` (recommend `WCAG 2.2 AA`, or stricter when the domain requires it, such as a public service or clinical tool)—and ask if there is any visual anti-reference (what the UI must *never* feel like).
+   2. **Palette Character, Contrast Clashes & Component Feel (`Look` & `Components`):**
+      Briefly show the auto-extracted token roles and component/elevation feel (flat vs. tonal layering vs. lifted, button/input character), and ask for the decision code alone cannot make:
+      - **When `clashes` is non-empty:** for each measured contrast clash in `Look`, propose a concrete `[Recommended]` rule (how to keep the pair apart or where one may not be used, e.g., restricting a low-contrast token to borders/decorators or pairing it with a darker text token) and ask the user to confirm or adjust.
+      - **When `clashes` is empty:** confirm the primary/accent usage doctrine (e.g., a Named Rule like *"The One Accent Rule — primary accent reserved for the single primary action per view"*) and any missing primitives for `Not in the library yet`.
+   3. **Unresolved States or Policy Gaps (only if needed):**
+      Skip this question when the codebase already covers states and formats cleanly. Ask a 3rd question only if key state patterns (`Forms`, `Loading`, `Failure`, `Empty`) are missing or contradictory in code, or if an open domain policy question needs a decision (establish a rule now vs. leave under `## Open Questions`).
+
+   After the user's answers, synthesize `## Review Checklist` (concrete yes/no questions a reviewer answers by looking at one screen, where yes is a pass, derived from the confirmed rules and extracted states) and `## Open Questions` (components screens need that do not exist yet, and policy decisions still open). Write a policy value (a notice period, a limit, a percentage) only when the user gives it as the product's rule; otherwise it stays a `<placeholder>` and an open question. Name tokens, never raw colours or lengths.
 3. **Check.** Run `iamu design draft-check --file iamu/.analysis/design-draft.md --json`. Fix each of its `errors` in the draft (a value or path the code does not have, a prop a component lacks, a persona's name) and check again; ask the user only when the fix is a choice.
-4. **Show it once.** Show the whole draft, then the remaining `warnings` in one list (line and message). Ask once: **adopt it**, or **edit** (what to change; edit, check again, and show it once more).
+4. **Show it once.** Show the whole draft, briefly highlight the non-obvious creative choices (North Star/feel, clash rules, review checks), and list the remaining `warnings` in one list (line and message). Ask once: **adopt it**, or **edit** (what to change; edit, check again, and show it once more).
 5. **Adopt.** Run `iamu design adopt --file iamu/.analysis/design-draft.md --json` (`--to <path>` when the user wants it elsewhere). It refuses only when the target already exists: then ask for another path. It writes the doc and records it, with `applies_to` for its app. From then on it is the team's doc: iamu changes it only through proposals a person accepts.
 6. Offer **A2** (point agents at the doc).
 

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

@@ -61,7 +61,7 @@ Ask whether to pick one up. When the user picks a request:
 
 ### 2. List mode: present open findings grouped by scenario
 
-Run `iamu findings --open --json`. Each finding carries `slug`, `source` (`persona` or `designer`), `basis` (the designer's: evidence, seen or taste), `design_causes` (how many designer findings explain it), `scenario`, `type`, `severity`, `title`, `where` (page and step), `recommendation` (the advisor's, or null) and `fix_state`. One list, worst first, with both sources: every line says who found it (the persona through its block, the designer on the line itself), never sum their counts into one number, and say "taste" plainly when a designer finding's basis is taste. A designer finding with no `scenario` came from a page review; group it under its page. For how each scenario is doing, run `iamu report --json` and keep the newest row per `scenario`: its `summary.verdict` (label, question, answer) is the scenario's current outcome.
+Run `iamu findings --open --json`. Each finding carries `slug`, `source` (`persona` or `designer`), `basis` (the designer's: evidence, seen or taste), `design_causes` (how many designer findings explain it), `scenario`, `type`, `severity`, `title`, `where` (page and step), `recommendation` (the advisor's, or null), `fix_state` and `flagged` (an active tester guidance rule matched it — kept, not dropped, so a person decides; `iamu findings --flagged` lists them). One list, worst first, with both sources: every line says who found it (the persona through its block, the designer on the line itself), never sum their counts into one number, and say "taste" plainly when a designer finding's basis is taste. A designer finding with no `scenario` came from a page review; group it under its page. For how each scenario is doing, run `iamu report --json` and keep the newest row per `scenario`: its `summary.verdict` (label, question, answer) is the scenario's current outcome.
 
 Filter to `triage_status: open`.
 
@@ -110,7 +110,7 @@ Recommend **walk through**; recommend a direction first when one is open (see "D
 - **A scenario** (its heading, or "group 1") → iterate through that scenario's findings.
 - **Single number or slug** → single finding (skip to step 3).
 - **"fix 1 and 2"** → the list shows no recommendations, so never fix from a number alone: show each named finding's card (step 3, 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 as step 4's **Fix immediately** branch does.
-- **"skip 3" / "dismiss 3"** → dismiss with reason (`out_of_scope`, `not_relevant`, `walker_error`, `duplicate`).
+- **"skip 3" / "dismiss 3"** → dismiss with a reason: `not_relevant` (out of scope, or not a problem for this product), `walker_error` or `duplicate`.
 
 ### 3. Direct triage: review one finding
 
@@ -186,7 +186,7 @@ triage_note: "Made handoff notes optional on /sv/handoff; verified on screen."
 
 - **Defer** → the finding is real but not urgent. Set `triage_status: deferred` with an explicit `triage_note` naming the condition to revisit: `"Defer: revisit after <trigger, e.g. Q3 mobile release / next round of persona feedback>."`.
 
-- **Won't fix (accepted trade-off)** → the problem is real but the team accepts it. `iamu triage <slug> --status wont_fix --note "<the trade-off>"`. It stays out of future walks' dismissed list only as a known issue — no guidance rule is written.
+- **Won't fix (accepted trade-off)** → the problem is real but the team accepts it. `iamu triage <slug> --status wont_fix --note "<the trade-off>"`. It stays out of future walks' dismissed list only as a known issue — no guidance rule is written, unless you pass `--sweep`, which dismisses every matching finding and records a project-wide rule as a dismissal would.
 
 - **Not relevant / walker got it wrong (Load-Bearing Guidance Learning)** → the finding should never have been reported. **Never infer the reason silently.** Always ask the user:
   > "To teach future walkthroughs what not to report, why should this be dismissed?
@@ -200,7 +200,7 @@ triage_note: "Made handoff notes optional on /sv/handoff; verified on screen."
   - *Walker error* (the walker misread the screen): `iamu triage <slug> --status dismissed --reason walker_error --note "<what it misread>" --rule "<rule string>"`.
   - *Project-wide sweep ("we never want X" / "X is a test harness everywhere")*: When the user's intent applies across the entire product (including designer findings or other scenarios), pass `--sweep` (or `--sweep "<keyword>"`):
     `iamu triage [slug] --status dismissed --note "<why>" --rule "Don't report: <X>" --sweep "<keyword>"`.
-    This sweeps and dismisses every matching open persona and designer finding across all scenarios and surfaces in one command, and records a project-wide guidance rule that the walker, matcher, judge, designer, and `fix-brief` all respect.
+    This sweeps and dismisses every matching open persona and designer finding across all scenarios and surfaces in one command, and records a project-wide guidance rule that the walker, the matcher, the judge (`evaluate`) and `fix-brief` respect. The designer never reads tester guidance: a swept designer finding is dismissed, and later designer's reviews are told not to raise it again.
   - *Duplicate* of another finding: `--reason duplicate --note "Duplicate of <slug>"` (no rule is written).
 
   Not relevant and walker error write a **tester guidance rule** to `iamu/guidance/<slug>.md` that every later walker reads (and the matcher uses to flag repeats). The rule text defaults to "Don't report: <title>"; pass `--rule "<one sentence the walker can act on>"` when the title is too narrow or too broad. The rule applies to the whole project unless you pass `--scope outline` or `--scope capability` — narrow it when the finding is only irrelevant in this situation. Several findings dismissed for the same reason go in one call and share one rule. **Tell the user: "✓ Dismissed (<reason>) — Guidance rule taught to future walks in iamu/guidance/<slug>.md: '<rule string>'."** One-word notes ("nope") degrade future runs — capture the user's specific rationale.
@@ -275,7 +275,7 @@ Triage decisions are team state: until they sync, teammates still see these find
 iamu sync --json
 ```
 
-Report it in one line: `Synced <N> findings to Iamu Cloud.` If the result has `conflicts`, a teammate changed the same finding: name it and give the resolution (`iamu pull --force` to take theirs after copying your edits aside, or `iamu sync --keep-mine` to keep yours). If it has `pending_deletes`, list them and tell the user to run `iamu sync --confirm-deletes` after checking. Never run `--keep-mine` or `--confirm-deletes` yourself — only the user decides to overwrite or delete team data.
+Report it in one line: `Synced <N> findings to Iamu Cloud.` If the result has `conflicts`, a teammate changed the same finding: name it and give the resolution (`iamu pull --force <slug>` to take theirs for that finding after copying your edits aside, or `iamu sync --keep-mine` to keep yours; `--force` without a slug replaces all local files). If it has `pending_deletes`, list them and tell the user to run `iamu sync --confirm-deletes` after checking. Never run `--keep-mine` or `--confirm-deletes` yourself — only the user decides to overwrite or delete team data.
 
 Then end with the dashboard link from `iamu open --print` (step replay, screenshots side by side, the team's view of the same findings):
 
@@ -288,7 +288,7 @@ In linked-no-credentials mode, end with `Decisions are local only — iamu auth
 - **Links a terminal can open.** Terminals open only what they can see. Write web addresses in full (`https://…`), never hidden behind link text, and files as absolute paths (the project root plus the path), never relative. Name scenarios, personas and findings by slug in backticks; they need no link.
 - **Terminal-complete.** Everything the user needs to triage fits in chat. Citations, recommendations, linked steps, screenshots (as paths the agent can read if it has image support). Dashboard is nice-to-have, not required.
 - **Group by scenario, not by type.** Findings aggregate around scenarios. When reviewing, the context of "what happened in Maria's shift handoff?" matters before deciding on each finding — not seeing all severity:critical across projects.
-- **Severity-sorted within each group.** Within a scenario group, sort CRITICAL → MAJOR → MINOR → OBS. Within the same severity, show hinders/missing/incorrect before helps.
+- **Severity-sorted within each group.** Within a scenario group, sort CRITICAL → MAJOR → MINOR → NIT. Within the same severity, show hinders/missing/incorrect before helps.
 - **Screenshot paths over inline images.** Skill prints `iamu/.runs/<run>/screenshots/step-<N>.png` paths. Agents with image-capable read can open them on request.
 - **Every finding gets a decision — none disappear silently.** Fix now, design change, defer, won't fix, or explicit "waiting on X". No finding exits triage unreviewed. This discipline is load-bearing: silent skips degrade the signal the next walkthrough depends on.
 - **Bias toward small, direct fixes.** If something can be fixed in five minutes without risk, do not create a design process for it — fix it now and triage as addressed with a one-line change summary.

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

@@ -42,13 +42,13 @@ Determine the mode based on `$ARGUMENTS` and user intent:
   1. Ground in `iamu/context.yml` actors, domain, and jurisdiction.
   2. Define role, disposition, key biases, friction triggers, and domain vocabulary.
   3. Propose the persona candidate to the user (name, role, disposition, expectations).
-  4. Once confirmed, scaffold the persona into `iamu/personas/`:
-     ```bash
-     iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --json
-     ```
-  5. Write the persona's background narrative and test expectations as the markdown body.
-  6. Run `iamu validate --all`.
-  7. Summarize: persona created in `iamu/personas/<slug>.md`. Prompt user: "You can now pair `<slug>` with a scenario draft via `iamu-new`, or propose situations for them via `iamu-propose`." Stop here for standalone persona requests.
+   4. Once confirmed, scaffold the persona into `iamu/personas/` with its background narrative and `## Today` section passed via `--body` (or update later with `iamu set persona <slug> --body "..."`):
+      ```bash
+      iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --body "<Background narrative and test expectations>\n\n## Today\n<How this person does the job today without the product>" --json
+      ```
+   5. Ensure the persona's markdown body includes their background narrative and test expectations, ending with a `## Today` section: how this person does the job the product is for today, without it (a paper sheet, a spreadsheet, phone calls, a colleague, another tool), and what that costs or gives them. The walker holds the product against it and the judge weighs voluntary use against it.
+   6. Run `iamu validate --all`.
+   7. Summarize: persona created in `iamu/personas/<slug>.md`. Prompt user: "You can now pair `<slug>` with a scenario draft via `iamu-new`, or propose situations for them via `iamu-propose`." Stop here for standalone persona requests.
 
 - **Fast-Path Scenario mode** (when intent, topic, an Acceptance Criterion / User Story, or a candidate from `iamu-propose` is provided or referenced from conversational context, e.g. `iamu-new "checkout friction"`, `iamu-new "AC: System must require re-auth on payout change"`, "let's do candidate 2", "draft that", "option 1"):
   - **Acceptance Criteria & User Stories:** When input contains an AC or user story:
@@ -239,9 +239,9 @@ The `--capability`, `--additional-capabilities`, `--tension`, `--narrative`, and
 
 **3. Persona** (if user picked a new persona to scaffold):
 ```bash
-iamu new persona --name "Maria Gomez" --role "Site Safety Coordinator" --disposition "Time-pressured, prefers physical paper over complex forms" --json
+iamu new persona --name "Maria Gomez" --role "Site Safety Coordinator" --disposition "Time-pressured, prefers physical paper over complex forms" --body "<Persona background narrative and test expectations>\n\n## Today\n<How this person does the job today without the product>" --json
 ```
-The `--role` and `--disposition` flags populate frontmatter directly. Leave `access` out — which product account the persona uses is decided when the scenario is staged in `iamu-run`. Write the persona's background narrative and test expectations as the markdown body.
+The `--role`, `--disposition`, and `--body` flags populate frontmatter and the markdown body directly (or you can update the body via `iamu set persona <slug> --body "..."`). Leave `access` out — which product account the persona uses is decided when the scenario is staged in `iamu-run`. End the `--body` with a `## Today` section: how this person does the job the product is for today, without it (a paper sheet, a spreadsheet, phone calls, a colleague, another tool), and what that costs or gives them. The walker holds the product against it and the judge weighs voluntary use against it.
 
 **4. Scenario** (the binding):
 ```bash

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

@@ -12,18 +12,20 @@ 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.`
 
+**`--fresh`:** when `$ARGUMENTS` contains `--fresh`, take it out before resolving the scenario. Clear the app's storage after `iamu browse start` (step 4) so the walk starts from clean storage, not from what an earlier walk left behind. `iamu browse` only; per invocation, like `--no-ux`.
+
 $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
@@ -38,7 +40,7 @@ When more than one qualifies, prefer in this order:
 
 1. **One attached to the user's own running Chrome** (a Chrome DevTools-style MCP or a Chrome extension bridge). The user can watch the walk live, the session and dev state they already have is present, and console and network output are available to tell a tooling glitch from a product bug.
 2. **One that launches its own browser** (a Playwright-style MCP). Works, but starts from a blank profile and the user cannot see it happen.
-3. **`iamu browse`** — the CLI's own shell-driven browser, when no tool above can save a screenshot to a file (many hosts' browser tools return screenshots to the model only, and every step then records `screenshot: null`). It drives the installed Chrome in a visible window: `iamu browse start --run <run-id>` after each `start-run` (step 4), then `goto`, `snapshot` (ARIA roles and names), `click <role> "<name>"`, `click-text`, `fill <role> "<name>" "<text>" [--submit]`, `press`, `scroll`, `back`, each with `--shot <png>`; `iamu browse stop` when done. Start it yourself before dispatching the walker, never leave that to the walker; `iamu instructions walk --surface browse` (the default) writes the command list into the walker prompt.
+3. **`iamu browse`** — the CLI's own shell-driven browser, when no tool above can save a screenshot to a file (many hosts' browser tools return screenshots to the model only, and every step then records `screenshot: null`). It drives the installed Chrome in a visible window: `iamu browse start --run <run-id>` after each `start-run` (step 4), then `goto`, `snapshot` (ARIA roles and names; `--indexed` numbers the interactive elements `[#N]`), `click-index <N>`, `fill-index <N> "<text>" [--submit]`, `click <role> "<name>"`, `click-text`, `fill <role> "<name>" "<text>" [--submit]`, `select <role> "<name>" "<option>"`, `press`, `scroll`, `back`, each with `--shot <path>`; `iamu browse stop` when done. Start it yourself before dispatching the walker, never leave that to the walker; `iamu instructions walk --surface browse` (the default) writes the command list into the walker prompt.
 
 Tell the user in one line which one you picked and why. If the project's own agent docs name a preferred browser tool or constrain where screenshots may be written, that wins over the order above.
 
@@ -134,32 +136,38 @@ If the resolved scenario has `persona: null`, prompt to bind before executing:
   "This scenario is a draft with no persona bound. I recommend binding `<Existing Persona 1>` (<Role>). Proceeding with this persona — name another persona or type 'new' to propose candidates."
 
 1. Read `iamu/personas/` directory or run `iamu list personas`; present as pickable list + "new" option.
-2. Picked existing → bind that persona by updating the scenario file's `persona` field.
-3. Picked "new" → generate 3 persona candidates grounded in the situation narrative and project context → user picks one + refines → write persona file to `iamu/personas/<slug>.md` → bind.
-4. After binding the persona, generate a 3--5 sentence first-person brief and write it as the scenario file's markdown body:
-
-   ```yaml
-   ---
-   id: <uuid>
-   slug: maria-gomez--busy-shift-handoff
-   outline: busy-shift-handoff
-   persona: maria-gomez
-   ---
-   I've got five open incidents and my relief is already here...
+2. Picked existing → bind that persona and write the scenario narrative using `iamu set scenario <slug> --persona <persona-slug> --body "<narrative>"`.
+3. Picked "new" → generate 3 persona candidates grounded in the situation narrative and project context → user picks one + refines → create the persona via `iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --body "<background and ## Today>"` → bind.
+4. After binding the persona, generate a 3–5 sentence first-person brief and persist both the bound persona and the scenario markdown body via `iamu set`:
+
+   ```bash
+   iamu set scenario <slug> --persona <persona-slug> --body "I've got five open incidents and my relief is already here..."
    ```
 
 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. (`status: configured` means a person set the URL but it was not answering then — keep it, and let the preflight check below find out whether it answers now.) 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. `iamu/testability.md` becomes `status: verified` when the URL answers, else `status: configured`:
+     ```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?"
@@ -172,8 +180,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.
 
@@ -209,18 +220,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>"` (where `<strategy>` is one of `dev_switcher`, `test_accounts`, `interactive`, `public`), 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`, enterprise auth, SSO, 2FA, BankID):**
+If `auth_strategy` is `interactive` 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
@@ -251,7 +271,7 @@ 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:
+**Fresh walk (`--fresh`, `iamu browse` only).** When `--fresh` was given, or when running iterative passes against a browser left open (e.g. with `--critic`), clear the origin's storage after `browse start` so each walk starts from clean app storage:
 
 ```bash
 iamu browse clear-storage --run <run-id>
@@ -280,13 +300,13 @@ A fresh subagent is NOT blind by default. On most hosts it still loads the proje
 - **Child Session Suppression:** The walker must never execute parent workflow routines (`iamu init`, `iamu triage`, `iamu new`). All steps, findings, and summaries are recorded atomically via `iamu browse step`, `iamu new-finding`, and `iamu summary`.
 
 **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:** 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).
+- **Walker (Browser Navigation):** High turn count, and a judgement at every screen about what fits the persona's role. Use the **mid** tier (`sonnet` in Claude Code, `flash` in Antigravity) by default: on the role-fit benchmark in Claude Code it found the same problems as `haiku` about 1.7× faster, at a higher price per token. In `--critic` loops, where cost per walk matters more than the time of one walk, the **fastest** tier (`haiku` in Claude Code) is an option.
+- **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 mid tier).
+- **Judge:** Evaluates the human tests from the walk's recorded steps and findings (`judge_prompt.md`, text-only reading comprehension). Use the **mid** tier (`sonnet` in Claude Code, `flash` in Antigravity).
 
 ```
 # In Claude Code:
-Agent({ description: "Walk <scenario-slug> as <persona.name>", model: "haiku", prompt: "<walker_prompt, verbatim>" })
+Agent({ description: "Walk <scenario-slug> as <persona.name>", model: "sonnet", prompt: "<walker_prompt, verbatim>" })
 
 # In Antigravity / generic subagent hosts:
 invoke_subagent(Role="Persona Walker", Model="flash", Prompt="<walker_prompt, verbatim>")
@@ -365,7 +385,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 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.
+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; the designer's review (C3) starts right after A and runs beside B, C and C2. D and E wait until every record (B, C, C2, C3) is in, so the report you read and the run you publish are complete.
 
 > **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).
@@ -404,10 +424,10 @@ 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, 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`):
+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 **mid** model tier: `sonnet` in Claude Code, `Model="flash"` in Antigravity). After the evaluator returns verdicts, record them via `--data` (do NOT create a `verdicts.json` file yourself; pass the JSON string directly into `--data`). Like every record command it stays local and never prompts; E publishes:
 
 ```bash
-iamu evaluate-record <run-id> --data '<raw_verdicts_json>' --no-prompt --no-push
+iamu evaluate-record <run-id> --data '<raw_verdicts_json>'
 ```
 
 This links findings to human tests (`human_test_id`) and updates the report with judge verdicts.
@@ -434,15 +454,19 @@ The judge (C) and the advisor (C2) are independent, so their subagents may run i
 iamu designer <run-id> --json
 ```
 
-If `needed` is `false` (`reason` is `blocked`, `no_screens` or `already_recorded`), skip it. Otherwise dispatch a fresh subagent that can look at images (the **thorough** model tier) with `iamu/.runs/<run-id>/designer_prompt.md` as its only context, alongside the matcher (B), the judge (C) and the advisor (C2) where the host allows. It reviews the screens the persona saw as the product's designer would: against the project's design docs when they apply to this run (`judged_against: design-docs`), else against general craft, across the whole screen. What it finds are designer findings: judgement, never the persona's experience, and never counted with the persona's findings or in the verdict.
+If `needed` is `false` (`reason` is `blocked`, `no_screens` or `already_recorded`), skip it. Otherwise dispatch a fresh subagent that can look at images (the **thorough** model tier) with `iamu/.runs/<run-id>/designer_prompt.md` as its only context, alongside the matcher (B), the judge (C) and the advisor (C2) where the host allows. The subagent MUST open and look at the key screenshots the prompt lists (their paths are `key_screenshots` in the result) with its own file-viewing tool, judging visual hierarchy, layout, contrast and typography against the design docs the prompt names, else general craft. What it finds are designer findings: judgement, never the persona's experience, and never counted with the persona's findings or in the verdict.
 
-Nothing waits for it: the advisor never waits for the designer, and D and E go ahead without it. When its answer arrives, record it:
+The advisor (C2) does not wait for the designer, but D and E do: when its answer arrives, record it:
 
 ```bash
 iamu designer-record <run-id> --data '<raw_designer_json>'
 ```
 
-Never run two record commands at the same time: `match-record`, `evaluate-record` and `advise-record` keep their order, and `designer-record` runs between them when its answer arrives. It re-derives the report and never touches the persona's finding files. If the subagent fails or its answer is rejected, retry once, then continue without it and record `iamu designer-record <run-id> --skipped "the designer failed"`. If `designer-record` says `rederive_failed`, run the `fix` it prints. On a host without subagents, answer the prompt yourself after C2 and record with `iamu designer-record <run-id> --by-orchestrator --data '<raw_designer_json>'`; the report then says the review was not written by a separate agent. Keep the result's `proposals`, and `offer_template` from `iamu designer`, for step 5.
+Record commands run one at a time: `match-record`, `evaluate-record` and `advise-record` keep their order, and `designer-record` goes between them when its answer arrives (the CLI also holds each run's record lock, so one that starts while another records waits for it). It re-derives the report and never touches the persona's finding files. If the subagent fails or its answer is rejected, retry once, then continue without it and record `iamu designer-record <run-id> --skipped "the designer failed"`. If `designer-record` says `rederive_failed`, run the `fix` it prints.
+
+**Never fabricate a review.** Where the host can dispatch a subagent that looks at images, the review is that subagent's. Only on a host that cannot dispatch one, and only when you can open and look at the screenshots yourself, answer `designer_prompt.md` yourself and record it with `iamu designer-record <run-id> --by-orchestrator --data '<raw_designer_json>'`: the report then says it was written by the orchestrator, which is less independent. If neither is possible, record `iamu designer-record <run-id> --skipped "no subagent can look at images"`. `--no-ux` and `--critic` record their own reasons (see the top of this skill).
+
+Keep the result's `proposals`, and `offer_template` from `iamu designer`, for step 5.
 
 **D. Read the completed canonical.** Read `iamu/.runs/<run-id>/canonical.json` for the final data including the verification delta (if a prior run exists) and `analysis.directions` (if the advisor ran). Use this for step 5 presentation.
 
@@ -462,7 +486,7 @@ It prints the URL only if the run is on the cloud; otherwise it exits 1 and says
 
 In linked-no-credentials or local-only mode, skip E.
 
-Only after A→E (with C2) are complete, proceed to step 5. If the designer has returned by then, record it first; if not, present without it and add the designer's review when it lands. If it lands after E, run `iamu sync --json` once more so the cloud report carries it.
+Only after A→E (including C2 Advisor and C3 Designer) are complete, proceed to step 5: every review is recorded before E publishes and before you present the results.
 
 ### 4a. Walk methodology summary
 
@@ -504,8 +528,8 @@ Then, one short line each, only the ones that apply. These are counts; the detai
 - 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: say "start it" 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`.
+- Sync (E): `⚠ Sync: <n> findings changed by a teammate too` when the result has `conflicts`: name them and give the resolution (`iamu pull --force <slug>` to take theirs for those findings after copying your edits aside, or `iamu sync --keep-mine` to keep yours; `--force` without a slug replaces all local files). 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`.
 
 Then the link to the full walkthrough, which shows the persona's reasoning beside each screenshot: