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

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

@@ -78,70 +78,108 @@ No local codebase detected. To seed context, provide one of:
 
 ### 3. Step 1/3: Establish the Safety Fence (`iamu/testability.md`)
 
-Present the detected environment and safety fence. Explain clearly *why* this boundary is required before any autonomous agent runs.
+Never dump the target URL, dev command, login mechanism, and untestable boundaries into a single "take-it-or-leave-it" blob. Walk through them **one focused question at a time**, using what you found in the codebase to pre-fill the recommended choice and persisting each answer immediately with `iamu set testability`.
 
-**Dual-Surface Prompting (Sequencing Rule):**
-You MUST output the safety fence card to the chat stream FIRST. In the SAME turn, invoke `ask_question` with the full context embedded in the `question` argument:
+#### Step 1a: Target URL & Dev Command (1 question)
+
+Before asking, check whether a server is already responding on the detected port (`curl -I` or `iamu doctor --target <url> --json`). If this is a monorepo with multiple runnable apps (`apps/*`, `packages/*`), list each detected app and its URL as selectable options.
+
+Output the detected target briefly to chat first, then invoke `ask_question` in the same turn:
 
 ```text
-Step 1/3: Safety Fence & Environment Boundary
-Why this matters: Iamu drives a real headless browser with full agency. This boundary guarantees the agent stays confined to your local environment and never touches external services or triggers real-world side effects.
-
-Detected Environment:
-  Target URL:       <target_url, e.g. http://localhost:5173>
-  Dev Command:      <dev_command, e.g. ./dev or pnpm dev>
-  Safe Fixtures:    <detected seed scripts or mock handlers, e.g. organization_realistic_seed.sql, MSW>
-  DO NOT WALK:      <detected external services, e.g. Arbetsmiljöverket external submission portal (anmalarbetsskada.se), Real SMS/Email gateways, Real OIDC Keycloak>
+Step 1a: Target URL & Dev Server
+  Detected URL:      <target_url, e.g. http://localhost:5173> (<currently running | not running>)
+  Dev Command:       <dev_command, e.g. pnpm dev>
 ```
 
-**Interactive Decision Gate:**
-Prompt the user to verify the safety boundary:
 - If interactive user-prompt tools exist (`ask_question`, `ask_followup_question`), invoke it:
   - **Question:**
     """
-    Step 1/3: Confirm Safety Fence & Dev Environment
+    Step 1a: Where should Iamu run browser tests against your app?
+
+    Detected URL: <target_url> (<currently running | not running>)
+    Dev Command:  <dev_command>
+    """
+  - **Options:**
+    1. "(Recommended) Use <target_url> (start with `<dev_command>`)"
+    2. "<Second detected workspace app URL + dev command, if monorepo; otherwise omit>"
+    3. "Use a different target URL or port"
+    4. "Change the dev startup command"
+- Otherwise (text-only/CLI):
+  Ask: `Where should Iamu test your app? Detected <target_url> (start command: <dev_command>). Reply to confirm, or give the right URL / dev command.`
+
+**If the user picks Option 3 or Option 4 (or writes in a correction):**
+- Ask for the exact URL (e.g. `http://localhost:4000` or a staging URL) and/or dev command, and wait for their reply before proceeding.
+
+**Persist immediately:**
+```bash
+iamu set testability \
+  --target "<confirmed_target_url>" \
+  --dev-command "<confirmed_dev_command>" \
+  --json
+```
 
-    Target URL:    <target_url>
-    Dev Command:   <dev_command>
-    Safe Fixtures: <detected seed scripts or mock handlers>
+#### Step 1b: How Tests Log In / Switch Users (1 question)
 
-    DO NOT WALK (Untestable Boundaries):
-    <detected external services, real SMS/email gateways, external submission portals>
+Next, ask **specifically** how the browser walker should log in or switch roles during tests. Never guess and save `--auth-strategy` or `--access` silently.
 
-    Confirm safety fence and dev environment?
+Output what you found in the codebase first, then invoke `ask_question` in the same turn:
+
+```text
+Step 1b: Test Login & User Switching
+  Detected Auth:     <What code inspection found, e.g. "Dev switcher via localStorage.sf_dev_persona", "Seeded test accounts in prisma/seed.ts (coordinator@site-a.test)", "Login form at /login (no seeded account found)", or "Public routes — no auth guard detected">
+```
+
+- If interactive user-prompt tools exist (`ask_question`, `ask_followup_question`), invoke it:
+  - **Question:**
+    """
+    Step 1b: How should Iamu log in or switch users when running tests?
+
+    Detected in codebase: <concise summary of detected auth guard / switcher / seed accounts>
     """
   - **Options:**
-    1. "[Recommended] Safety boundaries look safe — save fence and proceed"
-    2. "Adjust boundaries (add forbidden external URLs, change dev command or port)"
-    3. "Skip safety fence for now"
+    1. "(Recommended) <Specific mechanism detected in code, e.g. 'Use seeded test account (coordinator@site-a.test)' or 'Use dev persona switcher' or 'No login needed (public app)'>"
+    2. "Interactive login — open Chrome and let me log in manually before the test starts"
+    3. "Use specific test credentials or login instructions (I'll provide them)"
+    4. "No login needed (test public pages only)"
 - Otherwise (text-only/CLI):
-  Step 1/3: Safety Fence & Environment Boundary
-  Target URL:    <target_url>
-  Dev Command:   <dev_command>
-  Safe Fixtures: <detected seed scripts or mock handlers>
-  DO NOT WALK:   <detected external services>
+  Ask: `How should Iamu log in for tests? Detected: <summary>. Reply to confirm, say "interactive" to log in manually in Chrome, or tell me how to sign in.`
 
-  Safety boundaries look safe. I recommend saving fence and proceeding.
-  Proceeding to save safety fence — say "adjust" to change boundaries or "skip" to defer.
+**If the user picks Option 3 (or wants to specify how login works):**
+- Ask: *"Which test account, login URL, or dev bypass should the walker use? (For passwords or tokens, name the environment variable or dev seed rather than pasting production secrets.)"*
+- Wait for their answer before proceeding.
 
-**Action on confirmation (Option 1):**
-Persist the safety fence using `iamu set testability` (never invoke host file creation or edit tools):
+**Persist immediately:**
 ```bash
 iamu set testability \
-  --target "<target_url>" \
-  --dev-command "<dev_command>" \
   --auth-strategy "<dev_switcher | interactive | test_accounts | public>" \
-  [--access "<access mechanism>"] \
+  [--access "<confirmed login or user-switching instructions>"] \
+  --json
+```
+
+#### Step 1c: Untestable Boundaries (only when external side-effects exist)
+
+If code inspection found un-mocked external services or side-effect boundaries (e.g., Stripe checkout, real SMS/email gateways, external government submission portals, live production OAuth), ask one short question to confirm the `DO NOT WALK` fence:
+- Show the detected external boundaries and ask whether to block the walker from touching them (or add others).
+- If no external side-effect integrations exist, do not ask an extra question.
+
+Persist the complete testability summary body via `iamu set testability` (never invoke host file creation or edit tools):
+```bash
+iamu set testability \
+  --target "<confirmed_target_url>" \
+  --dev-command "<confirmed_dev_command>" \
+  --auth-strategy "<confirmed_auth_strategy>" \
+  [--access "<confirmed_access_mechanism>"] \
   [--harnesses "<detected harness 1>, <detected harness 2>"] \
   [--untestable-boundaries "<external dependency 1>, <external dependency 2>"] \
   --body "# Project Testability & Environment
 
 ## Target & Run Instructions
-- Command: <dev command>
-- Base URL: <target_url>
+- Command: <confirmed_dev_command>
+- Base URL: <confirmed_target_url>
 
 ## Auth & Access Boundary
-- <How a walker becomes this persona in dev or test mode>
+- <confirmed_access_mechanism>
 
 ## Reachable Surfaces
 - <List discovered routes/entry points>
@@ -162,6 +200,8 @@ Explain the purpose of project context: traditional tests only assert button cli
 
 Present the discovered domain and project description. Do NOT introduce or ask the user to approve personas or roles at this stage — personas are cast later when designing specific test journeys.
 
+**Treat codebase evidence as a hypothesis, not user approval.** Scan the repo so the user never has to repeat obvious facts, but if the codebase leaves a material gap (who the real primary users are, what high-stakes workflow matters most, or what real-world constraints apply), call out that gap explicitly in your question rather than inventing domain stakes.
+
 **Describe the product, not the environment you explored.** Persona drafting and the advisor read these fields and the description as the truth about the product. Write them as the product its people use in their real work. Leave out everything about how this copy runs, because Step 1 already recorded it in `testability.md`:
 - **Data and build:** seeded, mocked, fixture, sample or fake data; demo, prototype or staging status; where data is stored; frontend or backend architecture; dev servers.
 - **Seed numbers:** headcounts, named teams, stores or sites, and record counts taken from seed or fixture files describe the test data, not the customers. Say who the product is for in general terms ("small and mid-sized companies"). Rules and policies the code enforces (a notice period, an approval threshold) are product behaviour; keep them.
@@ -202,7 +242,7 @@ Host interactive tools (`ask_question`, `ask_followup_question`) render a modal
     Confirm project domain & description?
     """
   - **Options:**
-    1. "[Recommended] Project description is accurate — proceed to design first test"
+    1. "(Recommended) Project description is accurate — proceed to design first test"
     2. "Save project description only (skip scenario creation for now)"
     3. "Adjust domain or description"
 - Otherwise (text-only/CLI):
@@ -215,10 +255,12 @@ Host interactive tools (`ask_question`, `ask_followup_question`) render a modal
   Project Description:
   <1 cohesive paragraph>
 
-  Project description is accurate. I recommend proceeding to design your first test.
-  Proceeding to first test design — say "save only" or describe adjustments to change course.
+  Reply to confirm this project description, say "save only" to skip scenario creation, or tell me what to adjust.
+
+**If the user chooses Option 3 (Adjust domain or description):**
+- Ask what is inaccurate or missing, revise the domain fields and paragraph accordingly, and confirm before saving.
 
-**Action on confirmation (Option 1):**
+**Action on confirmation (Option 1 or after adjustment):**
 Persist the domain context using `iamu set context` (never invoke host file creation or edit tools). Put structured fields in frontmatter and the project description in the markdown body below the `---` via `--body`:
 ```bash
 iamu set context \
@@ -229,18 +271,31 @@ 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."
 
 ---
 
 ### 4b. Design docs (quick; the user may skip it, you may not)
 
-The team's design docs are part of the product's context, like the domain. Iamu reads them wherever they are and never edits them on its own. Run `iamu design detect --json` and always show the user its result, even when every candidate looks unrelated. Never drop a candidate yourself: one in a spike, sandbox or example folder is listed with that note, unticked, and the user decides.
+The team's design docs are part of the product's context, like the domain—and **Iamu gets significantly sharper when it has them**. Without a design doc (`DESIGN.md`), Iamu's designer can only judge screens by generic UI craft; with a recorded `DESIGN.md`, every walkthrough checks your actual token roles, component contracts, form/loading/empty states, and contrast rules, links persona friction to broken rules, and proposes grounded `Before → After` edits when a rule hurts a user.
+
+Iamu reads design docs wherever they are and never edits them on its own. Run `iamu design detect --json` and always show the user its result, even when every candidate looks unrelated. Never drop a candidate yourself: one in a spike, sandbox or example folder is listed with that note, unticked, and the user decides.
 
 - **Found docs** (a `DESIGN.md` in any format, design-system, brand, voice or interaction docs, design sections of `CLAUDE.md` or `AGENTS.md` shown as `CLAUDE.md#<heading>`, a `PRODUCT.md`, token files, a component library): list them once, one line each (kind, path). Show a candidate with a `note` (anything in a sample, export, fixture or spike folder) with its note, unticked. Ask once whether to record them; the user may drop some or add others. On yes, `iamu design sources <paths…>` (in a monorepo, `--applies-to` with the URL prefix or the app's folder each doc covers).
 - **A legacy `iamu/design.md`** (`iamu design status --json` shows `legacy.doc` and no `legacy.migrated_at`): fold it into the same single question. Run `iamu design migrate --json` first, and offer three answers next to the files: **move it** to a plain `DESIGN.md` the team owns (`iamu design migrate --move-to DESIGN.md --apply`), **keep** `iamu/design.md` as it is (`iamu design migrate --apply`, which records the choice so it is not offered again), or **not now** (run nothing; it is offered again next time). Only an explicit "keep" runs `--apply` without a move.
-- **Nothing found:** say so in one line: "No design docs found. The designer reviews each run by general craft until you record some (`iamu-design`)."
-- **No written design doc** (detection found only tokens or components, or nothing, and no design doc is recorded): after the question above, or in its place when there was nothing to record, ask one question the user may skip: "There is no design doc yet. Shall I start one from your code? I fill in your tokens, components and contrast clashes, then ask you a few short questions (who it is for, how it should feel, an accessibility target, states, formats). **Yes** / **not now** / **no**." Yes: follow the `iamu-design` skill, mode E, then carry on with setup. No: run `iamu design template --decline`, so runs stop offering it. Not now: run nothing; it is offered again after the first run.
+- **Nothing found:** say so in one line: "No design docs found. The designer reviews each run by general craft until you record some (`iamu-design`) — strongly recommended so runs check your own tokens, components, and rules."
+- **No written design doc** (detection found only tokens or components, or nothing, and no design doc is recorded): after the question above, or in its place when there was nothing to record, explain in one sentence why a design doc makes Iamu much stronger (*"With a `DESIGN.md`, Iamu's designer checks your own tokens, components, states, and rules on every run instead of only general craft"*), and ask one question the user may skip:
+  - If interactive user-prompt tools exist (`ask_question`, `ask_followup_question`), invoke it:
+    - **Question:** "There is no `DESIGN.md` yet. Iamu gets much sharper with one (every run checks your own tokens, components, states, and rules instead of generic craft). Start one from your code now?"
+    - **Options:**
+      1. "(Recommended) Yes — start `DESIGN.md` from my code now (auto-extracts tokens, components, states & formats, then asks 2–3 quick intent questions)"
+      2. "Not now — finish setup first (keep reminding me to run `iamu-design`)"
+      3. "No — review by general craft only and stop offering `DESIGN.md`"
+  - Otherwise (text-only/CLI):
+    "There is no design doc yet, and Iamu gets much sharper with one (checking your own tokens, components, and rules on every run). Shall I start one from your code? I auto-extract your tokens, components, states, formats and contrast clashes from code, then ask 2–3 quick questions on feel and clash rules. **Yes** (recommended) / **not now** (keep recommending `iamu-design`) / **no**."
+  - **Yes:** follow the `iamu-design` skill, mode E, then carry on with setup.
+  - **Not now:** run nothing; it stays recommended at the end of setup, in `iamu status`, and after runs until a design doc is recorded.
+  - **No:** run `iamu design template --decline`, so runs stop offering it.
 
 Do not assess design docs here, and never write one without the user filling it in (mode E). Never block setup on this step.
 
@@ -250,16 +305,16 @@ Do not assess design docs here, and never write one without the user filling it
 
 Explain the journey model: an Iamu test binds a **Persona** (with habits, pressures, and impatience) to a **Situation** (a realistic high-stakes problem) with an **Evaluation Checkpoint** (a concrete binary question for the AI judge).
 
-Present the proposed test journey, including explicit **Auth Precondition Verification**.
+Split this into two quick questions: first agree on **who and what situation** to test (Step 3a), then confirm **which route and account** the walk starts with (Step 3b).
 
-**Dual-Surface Prompting (Sequencing Rule):**
-You MUST output the baseline test proposal to the chat stream FIRST. In the SAME turn, invoke `ask_question` with the full journey spec embedded in the `question` argument:
+#### Step 3a: Persona & Situation (Baseline Test Proposal)
 
-```text
-Step 3/3: Co-Design Your First Test Journey
-Why this matters: Validates whether a real human with specific operational pressures can complete a critical task without getting blocked or frustrated.
+Identify the top 2–3 high-stakes user workflows in the codebase. Lead with the strongest one in full detail as the recommended `Baseline Test Proposal`, and offer the other 1–2 discovered workflows as direct selectable options in the prompt so the user can switch flows in one click if they want to start elsewhere.
 
-Baseline Test Proposal (WYSIWGW Spec-Sheet):
+Output the proposed journey to the chat stream first, then invoke `ask_question` in the same turn:
+
+```text
+Step 3a: Baseline Test Proposal
   Capability:         <Capability Name> (<What staff can do in this area>)
   Persona:            <Name> (<Role / Title>)
                       • Reality: <Working context, physical habits, tenure, pressures>
@@ -267,40 +322,64 @@ Baseline Test Proposal (WYSIWGW Spec-Sheet):
   Situation:          <Outline Title>
                       • Tension: <Core problem-space tension in X vs Y format — no UI button names>
                       • Evaluation: <Concrete binary yes/partial/no question for evaluator>
-  Walk Surface:       Entry: `<entry_path>` | Target: `<target_url>`
-  Auth Precondition:  <Detected auth mechanism, e.g. "Dev persona switcher (localStorage.sf_dev_persona = 'anna')" or "Public">
   Walker Brief:       "<2–3 sentence first-person test brief that will be written verbatim to disk. States immediate intent and constraints before opening tool. Zero UI terminology.>"
 ```
 
-**CRITICAL: Embed Journey Spec in Interactive Prompt Modal:**
 - If interactive user-prompt tools exist (`ask_question`, `ask_followup_question`), invoke it:
   - **Question:**
     """
-    Step 3/3: Confirm Baseline Test Journey
+    Step 3a: Confirm First Test Scenario
 
-    Capability:        <Capability Name> (<What staff can do in this area>)
-    Persona:           <Name> (<Role / Title>) — Friction: <Diagnostic friction trigger>
-    Situation:         <Outline Title>
-    Core Tension:      <Core problem-space tension in X vs Y format>
-    Evaluation Check:  <Concrete binary yes/partial/no question for evaluator>
-    Walk Surface:      Entry: `<entry_path>` | Target: `<target_url>`
-    Auth Precondition: <Detected auth mechanism>
+    Persona:          <Name> (<Role / Title>) — Friction: <Diagnostic friction trigger>
+    Situation:        <Outline Title> (<Capability Name>)
+    Core Tension:     <Core problem-space tension in X vs Y format>
+    Evaluation Check: <Concrete binary yes/partial/no question for evaluator>
 
     WALKER BRIEF:
     "<2–3 sentence first-person test brief>"
 
-    Scaffold this baseline journey?
+    Test this persona and situation first?
     """
   - **Options:**
-    1. "[Recommended] Scaffold journey with <detected auth mechanism>"
-    2. "Use interactive human login handshake (pause browser for live login)"
-    3. "Switch role / design a different scenario (write-in)"
-    4. "Skip scenario for now"
+    1. "(Recommended) Yes — test <Name> in '<Outline Title>'"
+    2. "Test another flow instead: <Candidate Flow 2 — Role & Situation from codebase>"
+    3. "Test a different user role or workflow (I'll describe it)"
+    4. "Skip scenario creation for now"
 - Otherwise (text-only/CLI):
-  I recommend Option 1: Scaffold journey with <detected auth mechanism>.
-  Proceeding to scaffold baseline journey — say "interactive login", "switch role", or "skip" to adjust.
+  Ask whether to use `<Name>` and `<Outline Title>`, pick `<Candidate Flow 2>`, or describe another role/situation to test first.
+
+**If Option 2 or Option 3 is chosen:** draft the persona and situation for the chosen flow and confirm before continuing to Step 3b.
+
+#### Step 3b: Confirm Starting Route & Persona Login (`entry_path` & `persona.access`)
+
+Now verify the exact landing route and user account for `<Name>` (using the login method established in Step 1b):
+
+```text
+Step 3b: Walk Surface & Persona Login
+  Walk Surface:       Entry: `<entry_path>` | Target: `<confirmed_target_url>`
+  Auth Precondition:  <Specific account/role for <Name> using Step 1b's auth strategy, e.g. "coordinator@site-a.test" or "Interactive manual login" or "Public">
+```
+
+- If interactive user-prompt tools exist (`ask_question`, `ask_followup_question`), invoke it:
+  - **Question:**
+    """
+    Step 3b: Confirm Starting Route & Account for <Name>
+
+    Starting URL:      <confirmed_target_url><entry_path> (entry path: `<entry_path>`)
+    Auth Precondition: <Specific account/role for <Name>, or "Interactive login" / "Public">
+
+    Where should <Name>'s walkthrough start, and as which user?
+    """
+  - **Options:**
+    1. "(Recommended) Start at `<entry_path>` (<confirmed_target_url><entry_path>) as <persona account or auth mode>"
+    2. "Start on a different route (e.g. `/` or `/login`)"
+    3. "Use a different account or role for <Name>"
+- Otherwise (text-only/CLI):
+  Ask: `Start <Name> at <confirmed_target_url><entry_path> as <account/auth>? Reply to confirm, or give the entry path / account to use.`
+
+**If Option 2 or Option 3 is chosen:** ask for the entry path (must start with `/`, e.g. `/dashboard`) or the account/role identifier for `<Name>`, and use their answer below.
 
-**Action on confirmation (Option 1 or Option 2):**
+**Scaffold & Persist Entities:**
 1. **Scaffold Primary Capability** (if not already existing):
    ```bash
    iamu new capability --name "<Capability Name>" --description "<What staff can do in this area>" --json
@@ -311,11 +390,11 @@ Baseline Test Proposal (WYSIWGW Spec-Sheet):
    ```
 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 "<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
-   iamu new scenario --name "<persona-slug>--<outline-slug>" --outline "<outline-slug>" --persona "<persona-slug>" --entry "<entry_path>" --body "<Persona's first-person test brief describing what they intend to achieve>" --json
+   iamu new scenario --name "<persona-slug>--<outline-slug>" --outline "<outline-slug>" --persona "<persona-slug>" --entry "<confirmed_entry_path>" --body "<Persona's first-person test brief describing what they intend to achieve>" --json
    ```
 5. **Validate all entities**:
    ```bash
@@ -343,7 +422,7 @@ Render the output:
   iamu/
   ├── testability.md       [safety fence active: <target_url>]
   ├── context.yml          [domain: <domain>]
-  ├── design/sources.json  [<N> design docs]   (only when recorded)
+  ├── design/sources.json  [<N> design docs]   (when recorded; if no DESIGN.md yet and not declined: [no DESIGN.md yet — run iamu-design to unlock project rule reviews])
   ├── personas/
   │   └── <persona-slug>.md
   ├── outlines/
@@ -357,9 +436,9 @@ Next step:
     iamu-run <persona-slug>--<outline-slug>
 
 Other commands when you're ready:
+• iamu-design   Create or record DESIGN.md from your code (strongly recommended if not set yet: makes every run check your own tokens, components, and rules instead of general craft)
 • iamu-new      Draft a scenario for a different product flow
 • iamu-propose  Brainstorm high-risk workflows and blind spots
-• iamu-design   Record the project's design docs, review a page, decide proposed edits
 • iamu doctor   Diagnose test environment and target health
 <If cloud_linked: true>
 • iamu sync     Sync completed runs and findings to Iamu Cloud

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

@@ -68,22 +68,41 @@ Inspect the project to understand what the system under test already supports:
 4. **Running Dev Server:**
    - Verify the target URL (e.g. `http://localhost:3000`). If a local server is running, check what port it uses.
 
-### 3. Audit Gaps & Present the Strategic Fork
+### 3. Audit Gaps & Confirm Target, Entry & Login
 
 Present an honest, concise audit of what the scenario needs vs. what the system currently provides:
 
 ```markdown
 ### Staging Audit for `<scenario-slug>`
 
-- **Persona Role:** Maria Gomez (Shift Coordinator)
-  - Need: Account with site-coordinator privileges.
-  - Found: `coordinator@site-a.test` in seed scripts.
-- **Entry Route:** `/incidents` (verified in `src/app/(dashboard)/incidents/page.tsx`).
-- **World State:** 5 open incidents, 1 serious and unassigned.
-  - Current DB / Seed: Default seed only creates 0 incidents, or empty demo state.
+- **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_switcher` / `test_accounts` / `interactive` / `public`)
+- **World State:** 5 open incidents, 1 serious and unassigned (Current DB / Seed: 0 incidents)
 ```
 
-Now present the **Strategic Fork** to the user. Do not be an unyielding bureaucrat. Give the user two clear options:
+#### Step 3a: Confirm Target URL, Entry Route & Persona Login
+Never bury the Target URL, Entry Route, or Login mechanism inside a world-state prompt where the user cannot easily override them. Before asking about database seeds, confirm where the walk starts and how it signs in (one focused question):
+
+- If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+  - **Question:** "Start URL & Login for `<scenario-slug>`: Should Iamu start at `<target_url><entry_route>` and sign in via `<detected_access_or_strategy>`?"
+  - **Options:**
+    1. "[Recommended] Confirm `<target_url><entry_route>` & `<detected_access_or_strategy>`"
+    2. "Change Target URL or Entry Route — tell me the URL or `/path`"
+    3. "Change how tests log in as `<persona.name>` (e.g. interactive Chrome login, different test account, or dev switcher)"
+    4. "No login needed (public / unauthenticated flow)"
+- Otherwise, state the recommended Target URL, Entry Route, and Login mechanism and ask the user to confirm or override any of them.
+
+Persist any Target URL, Entry Route, or Login updates immediately:
+```bash
+iamu set testability --target <url> --auth-strategy <strategy> --access "<project-auth-mechanism>"
+iamu set scenario <slug> --entry "/<route>"
+iamu set persona <persona-slug> --access "<account-or-role-key>"
+```
+
+#### Step 3b: Present the Strategic Fork (World State & Seeds)
+
+Now present the **Strategic Fork** for the scenario's world state. Do not be an unyielding bureaucrat. Give the user clear options:
 
 #### Option A: Build Testability (The High-Integrity Path)
 *Recommend this when a clean seed script or preset is easy to add.*
@@ -106,23 +125,10 @@ Now present the **Strategic Fork** to the user. Do not be an unyielding bureaucr
 - Mark `--state-description "No particular data needed"`.
 
 **Dual-Surface Staging Gate (Sequencing Rule):**
-You MUST output the staging options to the chat stream FIRST. In the SAME turn, invoke `ask_question` with the staging options and requirements embedded in the `question` argument:
+You MUST output the staging options to the chat stream FIRST. In the SAME turn, invoke `ask_question` with the world-state options:
 
 - If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
-  - **Question:**
-    """
-    Staging Plan for '<scenario-slug>':
-
-    Entry Route: <route>
-    Required World State: <Description of required world in domain words>
-
-    Staging Options:
-    • Option A (Testability): <concrete seed or mock fixture proposal>
-    • Option B (Semantic Squinting): <squinting rule formula>
-    • Option C (Zero Setup): <why flow is public or self-contained>
-
-    How should we stage '<scenario-slug>' for walkthrough?
-    """
+  - **Question:** "World State for '<scenario-slug>' (<Required World State in domain words>): How should we stage the data?"
   - **Options:**
     1. "[Recommended] Option A: Build Testability (<brief seed proposal>)"
     2. "Option B: Semantic Squinting (test immediately against current dev database)"

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

@@ -29,6 +29,7 @@ When the user asks for project status, lead with an executive tally banner, foll
 
 ```
 Project Status: <P> Personas · <S> Scenarios (<R> Tested, <U> Untested) · <F> Open Findings · <C> Capabilities
+Design Docs:    <recorded design doc paths, or "none (designer reviews by general craft only — run iamu-design so runs check your own design rules)">
 Product Map:    <T> Surfaces (<R> Reached · <U> Unreached) [if explore map exists]
 ```
 
@@ -68,6 +69,7 @@ Conclude with exact copy-pasteable commands:
 ```
 Next actions:
   iamu-run <scenario-slug>              # Run a walkthrough for this scenario
+  iamu-design                           # Record or create DESIGN.md so runs check your own design rules
   iamu-propose                          # Propose missing personas or scenarios
   iamu-new                              # Draft a new scenario or persona
   iamu-findings                         # Triage open findings

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.0",
+  "version": "0.8.0-beta.2",
   "type": "module",
   "description": "Test your product as realistic personas — scenario-driven development CLI",
   "license": "MIT",
@@ -59,8 +59,8 @@
     "typescript": "^5.8.0",
     "vitest": "^4.1.11",
     "@iamu-dev/local-store": "0.1.0",
-    "@iamu/tsconfig": "0.1.0",
-    "@iamu-dev/protocol": "0.1.0"
+    "@iamu-dev/protocol": "0.1.0",
+    "@iamu/tsconfig": "0.1.0"
   },
   "scripts": {
     "build": "tsup && tsc -b --force tsconfig.build.json --emitDeclarationOnly && node scripts/copy-assets.mjs",

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