@iamu-dev/iamu 0.8.0-beta.1 → 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.
 
@@ -206,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`. Do not read step screenshot PNGs with your file-reading tool after routine steps — use the returned accessibility snapshot unless checking a visual layout discrepancy. 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.
 

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

@@ -18,6 +18,8 @@ This skill resolves what scenario to run following a clear **Target Scenario Res
 
 **`--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
@@ -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,18 +136,12 @@ 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.
@@ -155,7 +151,7 @@ After bind + brief, the scenario is ready to execute. Continue to step 3.
 **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:
+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:
@@ -163,7 +159,7 @@ After bind + brief, the scenario is ready to execute. Continue to step 3.
        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`:
+   - 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>"
      ```
@@ -236,10 +232,10 @@ Never silently guess login credentials or auth strategy without confirming with
        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.
+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_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:
+**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...
@@ -275,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>
@@ -304,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>")
@@ -389,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).
@@ -428,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.
@@ -458,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.
 
@@ -486,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
 
@@ -528,7 +528,7 @@ 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.
+- 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:

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

@@ -271,7 +271,7 @@ iamu set context \
 ```
 
 *If user chooses Option 2 (Save context only):* run `iamu set context ...` as above, and exit cleanly:
-"✓ Project context initialized. When you're ready to create your first test journey, run `/iamu:new`."
+"✓ Project context initialized. When you're ready to create your first test journey, run the `iamu-new` skill."
 
 ---
 
@@ -390,7 +390,7 @@ Step 3b: Walk Surface & Persona Login
    ```
 3. **Scaffold Persona**:
    ```bash
-   iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --body "<2-4 sentence narrative detailing technical habits, patience level, and specific friction triggers>" [--access "<confirmed-account-or-role>"] --json
+   iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --body "<2-4 sentence narrative detailing technical habits, patience level, and specific friction triggers>\n\n## Today\n<how they do this job today without the product, and what that costs or gives them>" [--access "<confirmed-account-or-role>"] --json
    ```
 4. **Scaffold Bound Scenario**:
    ```bash

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

@@ -77,7 +77,7 @@ Present an honest, concise audit of what the scenario needs vs. what the system
 
 - **Target URL:** `http://localhost:3000` (`pnpm dev`, from `iamu/testability.md`)
 - **Entry Route:** `/incidents` (verified in `src/app/(dashboard)/incidents/page.tsx`)
-- **Persona Login:** Maria Gomez (Shift Coordinator) → `coordinator@site-a.test` (`dev_bypass` / `seed_accounts` / `interactive_browser`)
+- **Persona Login:** Maria Gomez (Shift Coordinator) → `coordinator@site-a.test` (`dev_switcher` / `test_accounts` / `interactive` / `public`)
 - **World State:** 5 open incidents, 1 serious and unassigned (Current DB / Seed: 0 incidents)
 ```
 

package/dist/templates.d.ts

@@ -9,7 +9,7 @@ export declare function getTemplatesRoot(): string;
 export declare function getTemplateDir(subdir: "skills" | "prompts"): string;
 export declare function getTemplateFile(subdir: "skills" | "prompts", filename: string): string;
 /** Prompt templates `iamu init` installs and `iamu update` refreshes in `iamu/.prompts/`. */
-export declare const PROMPT_FILES: readonly ["walk.md", "persona.md", "outline.md", "combine.md", "complete.md", "evaluate.md", "advise.md", "design-draft.md", "design-review.md", "design-review-match.md", "designer.md"];
+export declare const PROMPT_FILES: readonly ["walk.md", "persona.md", "outline.md", "combine.md", "complete.md", "advise.md", "design-draft.md", "design-review.md", "design-review-match.md", "designer.md"];
 /**
  * A prompt as the project has it: its `iamu/.prompts/<name>` copy (which
  * a team may tune), else the bundled template.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iamu-dev/iamu",
-  "version": "0.8.0-beta.1",
+  "version": "0.8.0-beta.2",
   "type": "module",
   "description": "Test your product as realistic personas — scenario-driven development CLI",
   "license": "MIT",

package/dist/templates/prompts/evaluate.md

@@ -1,64 +0,0 @@
-# Evaluation methodology
-
-You are the EVALUATOR of a walkthrough. A different agent (the walker) drove this walkthrough as a specific persona. That walker was DELIBERATELY NOT shown the human-test questions below — your job is to read the recorded evidence and answer the questions yourself, without confirmation bias.
-
-Your output is the verdict on whether the product earns the scenario's "Human Test" — would this persona come back and use it voluntarily?
-
-## Rules
-
-- **Ground every verdict in evidence.** Cite specific step IDs and finding IDs. Quote specific phrases from `ui_fact`, `consequence`, or `persona_reasoning` when they're load-bearing. A verdict without grounding is rejected.
-- **Justifications must be falsifiable.** A reader with the same evidence must be able to verify what you cited.
-- **Disagree with the walker if the evidence supports it.** The walker's summaries are inputs, not verdicts. If a finding contradicts a walker claim, your verdict reflects the finding.
-
-## Verdict calibration
-
-- **`no`** — evidence uniformly negative on the critical-path task. Don't manufacture nuance.
-- **`yes`** — evidence shows the persona completed the task without measurable friction.
-- **`partial`** — genuinely different outcomes on different surfaces. NOT "mixed but ultimately negative" — that's `no`.
-- **`not_applicable`** — cannot determine from available evidence. Use instead of guessing.
-
-## Input
-
-Read `iamu/.runs/<run-id>/canonical.json` for:
-- `steps[]` — what the walker observed (persona_reasoning, actions, screenshots)
-- `findings[]` — what helped, hindered, was missing, or was incorrect
-- `human_tests[]` — the questions to answer (verdict is currently null)
-
-Read the outline file for the full human_test questions if needed.
-
-## Output
-
-Write the evaluation results to a temporary file, then use it to update canonical.json.
-
-Write `/tmp/iamu-eval-<run-id>.json`:
-
-```json
-{
-  "verdicts": [
-    {
-      "human_test_id": "<id>",
-      "verdict": "yes|partial|no|not_applicable",
-      "reasoning": "Steps 3-5 show... Finding X demonstrates...",
-      "grounding_step_ids": ["step-3", "step-4", "step-5"],
-      "grounding_finding_ids": ["<finding-uuid>"]
-    }
-  ],
-  "overall": {
-    "question": "Would <persona> come back?",
-    "answer": "<one paragraph grounded in specific observations>",
-    "reasoning": "<supporting argument>"
-  },
-  "provenance": {
-    "judge_mode": "subagent",
-    "model": "<model that ran this evaluation>",
-    "prompt_id": "judge",
-    "prompt_version": "1.0.0"
-  }
-}
-```
-
-Then update `canonical.json`:
-- Set each `human_tests[].verdict`, `.reasoning`, `.grounding_step_ids`, `.grounding_finding_ids`
-- Set `human_test_overall.answer` and `.reasoning`
-- Set `provenance.judge_prompt` and `provenance.judge_mode`
-- Regenerate `report.md` with verdicts filled in