@iamu-dev/iamu 0.2.0-beta.6 → 0.2.0-beta.9

package/dist/templates/prompts/walk.md

@@ -70,11 +70,9 @@ Continuity: steps form ONE ongoing monologue. From step 2 onward, don't restate
 
 ## Pacing
 
-**Aim for 10-20 steps.** Stop when the primary task verdict is clear — either the persona accomplished their goal or they hit friction that blocks them. A focused 12-step walkthrough with sharp findings is worth more than a 40-step exhaustive tour.
+**Aim for 10-20 steps.** When evaluating a form or journey, inspect all relevant sections across the workflow (e.g., travel details, per diem, deductions, expenses). Do not abandon the walkthrough after logging a single defect — continue through the remaining sections to uncover all distinct compliance and usability gaps before completing. A complete walkthrough with sharp findings across all sections gives the team high-value signal.
 
-Do not try to complete every interaction. If a form has 15 fields, the observation is "this persona would give up at field 4" — note the finding and move on.
-
-Do try key interactions that reveal something: click the main CTA, open a dropdown, check what filters exist. These are cheap observations with high signal.
+Do try key interactions that reveal something: click the main CTA, open a dropdown, check what options or deductions exist. These are cheap observations with high signal.
 
 Follow the persona's motivation. Spend time on what matters to them. When you have enough evidence to answer "would this person come back?" — you're done.
 
@@ -100,6 +98,20 @@ Your browser tooling has limitations that can look like product bugs. Before rec
 
 Do NOT silently suppress findings you suspect are tooling issues. Record them with the caveat — the human triaging can verify.
 
+## Expected state vs product bugs (Empty state & unseeded data)
+
+When an environment is unseeded or test records are missing:
+- An empty table or "No records found" screen is NOT automatically a product bug. If your scenario assumes existing data (e.g. reviewing past entries or auditing submitted claims), check whether the environment simply lacks seed data.
+- If your persona role is a creator (e.g. employee or consultant creating an item), click the creation CTA (e.g. "+ Ny reseräkning", "+ New") and proceed with your task.
+- If your persona role is read-only (e.g. an auditor or manager) and cannot create data, do NOT record false "missing data" bugs against the product. Conclude the walk noting that the environment lacks the required preconditions.
+
+## Semantic squinting (Adapting to environmental mismatch)
+
+Your prompt may include an approximation strategy (e.g. "If Malmö is missing, choose Göteborg").
+- **Squint at the closest match:** When the exact target name, category, or record described in your brief isn't available in this environment, pick the closest available alternative that allows testing the workflow.
+- **Stay in the journey:** Approximation is bounded. Never drift to unrelated modules (e.g. settings, profile, admin panels) just because a specific test record was absent.
+- **Log the approximation:** In your step note (`note`), state clearly that you chose the closest alternative according to your instructions.
+
 ## Portal-rendered UI
 
 Radix / Headless UI / Floating UI render dropdowns and listboxes into portals that do not appear in accessibility snapshots. If an expandable combobox looks empty after click, try: press ArrowDown then Enter, or evaluate a script in the page to probe the DOM. Take a fresh screenshot.

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

@@ -95,9 +95,16 @@ Human Checkpoint: <Concrete binary yes/partial/no question scored at evaluation>
 Roles with Stakes:
 • <Role 1>: <Stake>
 • <Role 2>: <Stake>
+
+Execution Preconditions (resolved at iamu-run):
+• Assumed State: <What records/data should exist, e.g. "Department with existing risk register containing open hazards">
+• Squint Guidance: <How the walker should approximate if exact records are missing, e.g. "If no packaging hazard exists, select any physical safety hazard and proceed with delegation">
+• Reachable Surface: <Entry route matched against iamu/testability.md, e.g. "/incidents/new">
+
+If the situation requires an un-mocked endpoint or missing data fixture to be walkable, offer to scaffold the missing MSW handler (e.g. in `src/mocks/handlers.ts`) or fixture file directly in the codebase before finalizing.
 ```
 
-Ask the user: "Ready to test this draft, or would you like to refine the focus question or circumstances? (Enter to accept, or type adjustments)"
+Ask the user: "Ready to test this draft, or would you like to refine the focus question, preconditions, or circumstances? (Enter to accept, or type adjustments)"
 
 ### 4. Pick or propose personas
 
@@ -164,12 +171,12 @@ The `--role` and `--disposition` flags populate frontmatter directly. If `iamu/c
 
 **4. Scenario** (the binding):
 ```bash
-iamu new scenario --name "maria-gomez--busy-shift-handoff" --outline busy-shift-handoff --persona maria-gomez --json
+iamu new scenario --name "maria-gomez--busy-shift-handoff" --outline busy-shift-handoff --persona maria-gomez [--entry /path/on/the/product] [--state-description "<Assumed state description>"] [--state-approximation "<Squint guidance for walker>"] --body "<First-person brief in persona voice (3–5 sentences)>" --json
 ```
 When the situation begins on a specific page (the persona follows a link from a video, an email, a search result), add `--entry /path/on/the/product` — the run starts there instead of the home page.
-`--outline` is required. `--persona` is optional (omit for drafts). Write the first-person brief as the markdown body — 3–5 sentences in the persona's voice.
+`--outline` is required. `--persona` is optional (omit for drafts). Pass `--state-description` and `--state-approximation` if preconditions were defined in step 3 to populate the scenario's `state:` frontmatter automatically.
 
-For drafts (no persona): omit `--persona`, omit the brief body.
+For drafts (no persona): omit `--persona`, omit `--body`.
 
 ### 7. Summarize
 

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

@@ -33,15 +33,19 @@ If context is thin (few actors, sparse notes), say so upfront — "your context
 
 ## Steps
 
-### 1. Load domain context
+### 1. Load domain context & testability boundaries
 
 Read `iamu/context.yml`. Extract and hold:
 - **Domain + industry** — what world does this product operate in?
 - **Actors** — real roles with real responsibilities. These are scenario and persona seed material.
 - **Governed_by** — regulations and standards (if applicable). These create structural tensions in regulated domains.
-- **Glossary** — domain vocabulary. Scenarios and personas must use these terms, not generic UI words.
 - **Notes body** — extended context, often containing workflow descriptions, pain points, organizational dynamics.
 
+Read `iamu/testability.md` (if present) to enforce execution boundaries:
+- **Reachable surfaces:** Ground candidates in reachable routes. Avoid proposing scenarios for product areas with no navigable surfaces.
+- **Untestable boundaries:** Strictly avoid proposing scenarios in flows documented as untestable (e.g. un-mocked live payment gateways, SMS dispatch, third-party SSO).
+- **Mocks & Fixtures:** Note which candidates require existing database seeds or mock handlers.
+
 ### 2. Load existing coverage
 
 Read existing entities to understand what's already been tested:
@@ -116,7 +120,7 @@ Next action:
 Ground rules for generation:
 
 - **Start from the actor's week, not the feature list.** What does this person actually do on a Tuesday? What goes wrong? What requires judgment?
-- **Use domain vocabulary from the glossary.** If the glossary says "skyddsombud" not "safety representative," use "skyddsombud."
+- **Use authentic domain vocabulary.** Speak in the language of the domain and the product UI (e.g., "skyddsombud" rather than generic "safety representative"), avoiding abstract test jargon.
 - **Prefer mundane frequency over dramatic edge cases.** The scenario that happens every week reveals more than the one that happens once a year.
 - **Structural tensions come from the domain, not from product limitations.** A real tension: "the regulation requires immediate reporting but the coordinator handles 3 sites." A fake tension: "the CSV upload has a 50-row limit."
 - **Never mention the product, its UI, its features, or its limitations.** The scenario exists in the domain. The product encounter happens during the walkthrough.

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

@@ -113,7 +113,11 @@ After bind + brief, the scenario is ready to execute. Continue to step 3.
 
 ### 3. Target
 
-**Web** — ask for the target URL (live product, staging, or localhost). If the scenario has a default `target_url` in its frontmatter, offer that with a confirm.
+**Web** — determine the target URL:
+1. If the user passed an explicit target or the scenario has `target_url`, use that.
+2. Otherwise, check `iamu/testability.md` for `target_url`.
+3. If still unconfigured, prompt the user for the target URL (live product, staging, or localhost).
+Verify target reachability and dev server health with `iamu doctor --target <url>` before launching.
 
 Where the walk *starts* is part of the situation, not of the environment: a persona arriving from a video, an email or a search result lands on a specific page, not the home page. If the scenario has `entry_path`, `iamu start-run` resolves it against the target — pass the product's base URL as `--target`. If it has none but the situation clearly begins on a particular page, set `entry_path` in the scenario frontmatter first (a path like `/en/episodes/1`, never a full URL), so this run and every later one start there. A walk started on the wrong page reports the detour as a finding.
 
@@ -127,19 +131,30 @@ Record it as a target string the run can carry, for example `sim://<device-name>
 
 **Then verify the starting state before spawning anyone.** Launch the app and take ONE screenshot confirming the product is where the scenario assumes it starts. Wait a few seconds after launch first: a screen rendered before its state lands shows the wrong thing, and verifying too early makes the verification itself lie — in the direction of "the harness is broken", which costs a debugging detour or, worse, waves a real seeding bug through.
 
-**Web: check the product is ready, not just up.** A server that answers is not a product that has its data. Before spawning the walker, confirm the thing the scenario depends on actually exists — the list the persona will open is populated, the seeded records are there, background setup (seeding, migrations, indexing) has finished. Use the project's documented readiness signal if it has one; otherwise look at one screen or one API response yourself. A walk started too early reports "the feature is missing" as a critical finding, and nothing in the walker's view distinguishes that from a real defect.
+**Expected State & Semantic Squinting — verify environment before walking.** A scenario testing triage, review, or audits requires a populated, realistic system.
+1. **Expected State:** If the scenario defines `state.description`, verify the landing screen matches what the persona expects to see (e.g. populated register, open incidents). If the screen is completely blank and the persona cannot self-seed, stop early and report the run as blocked by missing preconditions rather than logging false product bugs.
+2. **Data Squinting & Approximation:** If the exact record described in the narrative is absent (e.g. no "damaged conveyor belt" hazard), the walker must follow `state.approximation` — "squint" at the real data, pick the closest plausible record (e.g. an active mechanical or safety hazard), and proceed with the evaluation/delegation workflow.
+   - **Squinting Guardrail:** Squinting is bounded to semantically related items within the same domain workflow. It does NOT permit drifting to unrelated modules (e.g. switching from risk assessment to user profile settings). If no plausible record exists, declare the run blocked.
+3. **Empty State Fallback:**
+   - If the database is empty and the persona role has creation rights (e.g. Manager or Reporter), the persona may create the minimal viable record in-character to proceed with the core test.
+   - If the persona role is read-only or subordinate (cannot self-seed), stop and report the run as blocked by preconditions.
 
 **Access — how the walker becomes this persona.** A walk as a forklift driver that runs with an administrator's session reports nothing true about what the driver can see or reach. Access is recorded in two places, and `iamu instructions walk` (step 4) returns both as `access`:
 
 - `access.project` — from `iamu/context.yml` `access`: HOW switching user is done in this product (a dev persona switcher, a storage key, seeded test accounts, a login form). Written once per project.
 - `access.persona` — from the persona file's `access`: WHICH user this persona is (an account name, a role, a switcher key).
 
-If both are present, use them as they are. If either is missing, fill the gap now and SAVE it so no later run has to ask:
-
-1. Check the project's own agent docs (`CLAUDE.md`, `AGENTS.md`, anything they point to for the dev environment) for a documented way to switch user or role.
-2. Map the persona to the closest account or role the product actually has. If nothing fits, say so — a persona the product cannot represent is itself worth telling the user.
-3. If the docs are silent, ask the user once. "No login, everyone is the same user" is a valid answer.
-4. Write what you learned: the mechanism into `iamu/context.yml` as `access:`, the persona's own key into `iamu/personas/<slug>.md` frontmatter as `access:`. Passwords and tokens never go in either — name where they live (an env var, a vault entry) instead.
+**Interactive Auth Handshake (for enterprise auth, SSO, 2FA, BankID):**
+If 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.** Press Enter once you reach the dashboard to hand control to the walker...
+3. Wait for the user to confirm, then let the walker drive the authenticated session.
+
+If automated switching exists:
+1. Check the project's own agent docs (`CLAUDE.md`, `AGENTS.md`) for a documented way to switch user or role.
+2. Map the persona to the closest account or role the product actually has. If nothing fits, say so.
+3. Write what you learned: the mechanism into `iamu/context.yml` as `access:`, the persona's own key into `iamu/personas/<slug>.md` frontmatter as `access:`. Passwords and tokens never go in either — name where they live (an env var, a vault entry) instead.
 
 Carry the result into the walking prompt as the `## Access` section: the exact steps to become the persona, with the instruction to do them BEFORE the first recorded step.
 

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

@@ -34,7 +34,7 @@ Check whether `iamu/config.json` already exists:
 
 ### 2. Understand the project
 
-Explore the codebase automatically — do NOT ask the user what files to read. Build a **project-context summary** (3–6 sentences) the downstream skills will use as grounding. Read the following files when present:
+Explore the codebase automatically — do NOT ask the user what files to read. Build a **substantive project description** that serves as the foundation for all downstream analysis (personas, scenarios, and walkthroughs). Read the following files when present:
 
 - `README.md`, `CLAUDE.md`, `agents.md`
 - Package manifests — `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod`
@@ -42,114 +42,164 @@ Explore the codebase automatically — do NOT ask the user what files to read. B
 - `docs/`, OpenAPI / JSON / GraphQL schemas, `src/`-style source directories
 - `.env.example`
 
-Extract these key dimensions:
+**Quality Standard for Project Context (Knowledgeable Observer):**
+Write as an objective domain expert describing the business and its users, NOT marketing jargon, cookie notices, or tech stack. Do NOT hedge with "appears to be" or "seems to".
 
-1. **Domain & Purpose** — what this product does, core workflows, and problem space (mandatory).
-2. **Jurisdiction & Regulations (`governed_by`)** — country/region and specific compliance frameworks (AFS 2023:2, GDPR, HIPAA, ISO 27001, etc.). **Strictly optional:** only extract if the repo explicitly references legal or compliance standards. Do NOT invent regulations for standard apps.
-3. **Key Actors & Roles** — the main user archetypes and roles discovered in the codebase (auth models, routes, permissions).
-4. **Dev Access & Auth** — how personas switch or log in during local dev/test (e.g. dev persona switcher, seeded accounts, storage key, mock headers). Essential for walkthrough automation.
-5. **Key Terminology (`glossary`)** — 2–4 domain-specific terms or acronyms found in the codebase.
-6. **Primary Personas** — determine the 1–2 most critical user archetypes that stress-test this product (e.g. End User / Frontline vs. Admin / Compliance, or First-Timer vs. Power User). Propose:
-   - Name and Role
-   - Disposition / perspective (patience level, tech literacy, primary friction triggers)
+The description MUST capture four substantive dimensions:
+1. **What the product fundamentally IS** — core workflow, product type, and problem space.
+2. **Who actually uses it and what they come here to do** — enumerate the real user journeys (e.g. reporting incidents, triaging risks, delegating actions, auditing).
+3. **What makes THIS product specific** — geography, jurisdiction, regulatory mandates, or business model.
+4. **Operational characteristics** — how users physically and organizationally encounter the software (e.g. deskless frontline mobile workers in high-hazard environments, strict statutory completion deadlines, immutable audit trails).
 
-Do NOT collect code architecture (agent reads the codebase directly — tech stack doesn't affect walkthroughs).
+*Example of target substance:*
+> "IA-systemet is Sweden's national work environment and safety incident management platform, utilized by thousands of Swedish enterprises to comply with statutory systematic work environment requirements (AML / AFS). It enables frontline employees to quickly log near-misses (tillbud), workplace accidents (olycksfall), and risk observations from desktop or mobile devices in the field. Core user journeys include real-time hazard reporting, line manager root-cause investigations, safety committee review, and action plan delegation with statutory compliance tracking."
 
-**If there is no code (greenfield, design phase):** ask the user: what does this project do, who are the users, what domain, and are there any specific regulations?
+Synthesize the project into a cohesive, substantive narrative (1–2 paragraphs):
+- What the product fundamentally is, its primary domain, and who uses it.
+- Key user journeys and operational characteristics (e.g. mobile floor use, audit deadlines).
+- Market, geography, and specific compliance frameworks (only if evident).
 
-**Present the proposal with clean, structured Markdown for confirmation:**
+Audit testability without cluttering the domain context:
+Inspect `package.json` dev scripts, existing mock harnesses (MSW, seed scripts), auth route guards (`middleware.ts`, ProtectedRoute, session hooks), and page/route directories (`app/`, `src/routes/`). Use these findings to populate `iamu/testability.md`.
 
-```markdown
-### 📋 Discovered Project Context
+**If there is no code (greenfield, design phase, or test sandbox):** do NOT interrogate the user with a multi-part survey or ask for dev auth plumbing. Ask for a single entry point:
+> No local codebase detected. To seed context, provide one of:
+> - A target URL (staging, production, or docs — e.g., `https://app.example.com`)
+> - A one-sentence description of what this product does
+> - Or type `"sandbox"` to seed a pre-configured B2B SaaS demo
 
-- **Domain & Purpose:** <Concise description of the product and problem space>
-- **Jurisdiction & Rules:** <Country/region and compliance frameworks, or "None identified">
-- **Key Roles Identified:** <List of detected roles and their responsibilities>
-- **Dev Access & Auth:** <Detected mechanism to switch/assume personas in dev, or "Standard login">
-- **Domain Terminology:** <2–4 key terms/acronyms found in the codebase, if any>
+**Autonomous Enrichment:**
+- **URL provided:** Fetch or search public marketing/docs for that site. Automatically extract the substantive narrative, core user journeys, and key actors. If industry regulations are obvious (e.g., healthcare/HIPAA, Swedish workplace safety/AML), include them in the narrative.
+- **One-sentence summary provided:** Immediately expand into a full substantive narrative using domain knowledge.
+- **"sandbox" provided:** Seed a standard B2B SaaS narrative with Admin and End-User roles.
 
----
+**Present ONLY the narrative description for user confirmation (Do NOT include metadata bullets or personas):**
 
-### 🎭 Proposed Primary Personas
-
-#### 1. <Name> — *<Role / Title>*
-- **Context & Usage:** <Where and how they use the app (e.g., mobile on the floor vs. desktop in office)>
-- **Disposition:** <Patience level, technical confidence, key motivations>
-- **Friction Triggers:** <Specific interactions that cause friction, drop-off, or failure>
+```markdown
+### 📋 Discovered Project Context
 
-#### 2. <Name> — *<Role / Title>*
-- **Context & Usage:** <Where and how they use the app>
-- **Disposition:** <Patience level, technical confidence, key motivations>
-- **Friction Triggers:** <Specific interactions that cause friction, drop-off, or failure>
+<1–2 cohesive paragraphs written as a knowledgeable observer: what the product fundamentally is, who actually uses it, key user journeys, operational reality (e.g. mobile floor use, audit deadlines), and regulatory/market context. No marketing fluff, no hedging, no tech stack descriptions, and no bullet points.>
 
 ---
 
 **Next step:**
-Reply **"yes"** to save this context to `iamu/context.yml` and scaffold these personas, or tell me what to adjust (e.g., change roles, edit domain, or add/skip personas).
+Reply **"yes"** to save this context to `iamu/context.yml`, or tell me what to adjust.
 ```
 
-Wait for the user to confirm or correct before writing. The user only needs to verify domain and choose whether to accept, edit, suggest alternative personas, or defer persona creation.
-
-### 3. Capture domain context and scaffold personas
-
-Persist the step-2 summary as structured fields so every scenario draft and walkthrough loads the same grounding. Downstream skills auto-read this file.
-
-1. Check existing state by reading `iamu/context.yml` directly.
+Wait for the user to confirm or correct before writing. The user only needs to verify the narrative description and choose whether to accept or edit.
 
-2. **Branch on what you find:**
+### 3. Capture domain context and seed personas (Two-Phase Confirmation)
 
-   - **Empty / not present** → synthesize structured fields from step 2 and write `iamu/context.yml` with your file-editing tool (not a shell heredoc — it avoids permission prompts).
-   - **Present but thin** (missing domain) → show what's missing and offer to fill it. User picks **refine** or **replace**.
-   - **Present and complete** (domain set) → show summary and ask "Use as-is, refine, or replace?" Default is **skip**.
-
-3. **Write `iamu/context.yml`**:
+#### Phase A: Persist Context
+Once the user confirms the narrative description:
+1. Derive the structured frontmatter fields (`domain`, `actors`, `jurisdiction`, `governed_by`) from the confirmed text, and write `iamu/context.yml` with your file-editing tool. Put structured fields in frontmatter and the substantive narrative in the markdown body below the `---`:
 
    ```yaml
    ---
    schema_version: 1
-   domain: e-commerce storefront
-   # jurisdiction: EU / US          # optional
-   # governed_by:                    # strictly optional - omit if not regulated
-   #   - name: GDPR
+   domain: workplace safety management
+   # jurisdiction: Sweden / EU          # optional
+   # governed_by:                       # strictly optional - omit if not regulated
+   #   - name: AFS 2023:2
    #     authority_level: regulation
    actors:
      - name: Store Admin
        role: Manages catalog, inventory, and order fulfillment
      - name: First-Time Buyer
        role: Explores products, adds to cart, and checks out
-   glossary:
-     - term: SKU
-       definition: Stock Keeping Unit
    access: >-
      No login in dev. In the page, set localStorage "dev_persona" to the
      persona's access value and reload.
    ---
+
+   <The substantive 1–2 paragraph project description and core user journeys>
    ```
 
    Rules:
    - `domain` — one line. Mandatory.
+   - Body markdown (below `---`) — substantive description and user journeys. Downstream skills read this as extended grounding.
    - `jurisdiction` — optional. Only if evident or relevant.
-   - `governed_by[]` — strictly optional. Order by authority (legislation > regulation > standard > company_policy > guideline > informational). Specific names, not categories. Omit entirely if no regulations apply.
+   - `governed_by[]` — strictly optional. Order by authority. Omit entirely if no regulations apply.
    - `actors[]` — all identified roles and their responsibilities.
-   - `glossary[]` — domain terms only. Thin is better than padded with generic terms.
-   - `access` — optional. Only what the docs actually say; leave it out rather than guess. `iamu-run` fills it in on the first walk if it is missing.
+   - `access` — optional. Only what the docs actually say; leave it out rather than guess.
    - Do NOT add `industry` or `architecture` — these don't affect walkthroughs.
 
-4. **Scaffold confirmed personas (unless `skip-personas` selected):**
+2. Persist the technical testability and execution contract to `iamu/testability.md`:
+   Scaffold the target environment, auth mechanisms, discovered surfaces, mock harnesses, and untestable boundaries discovered from the code:
 
-   Use the CLI to scaffold valid persona entities with schema-compliant UUIDs, slugs, frontmatter, and narrative body in a single command:
-   ```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
+   ```markdown
+   ---
+   target_url: http://localhost:3000
+   dev_command: <detected dev script, e.g. pnpm dev or pnpm dev:mock>
+   auth_strategy: <dev_switcher | interactive | test_accounts | public>
+   harnesses:
+     - <detected harnesses, e.g. msw, seed>
+   ---
+
+   # Project Testability & Environment
+
+   ## Target & Run Instructions
+   - Command: <dev command>
+   - Base URL: <target_url>
+
+   ## Auth & Access Boundary
+   - <How a walker becomes this persona in dev or test mode>
+
+   ## Reachable Surfaces
+   - <List discovered routes/entry points, e.g. /login, /dashboard, /incidents>
+
+   ## Mocks & Data Fixtures
+   - <List existing MSW mock files, DB seed scripts, or fixture directories>
+
+   ## Untestable Boundaries (Do Not Walk)
+   - <List un-mocked external dependencies, e.g. live Stripe charges, SMS 2FA, external SSO>
    ```
 
-   If `iamu/context.yml` specifies an `access` mechanism, pass `--access "<role>"` matching an existing product account/role.
+   Keep `context.yml` strictly about domain reality (which the Walker subagent reads), and `testability.md` strictly about developer testability and execution boundaries (which orchestrator skills read).
+
+#### Phase B: Persona Casting (Opt-In & Separate Confirmation)
+Immediately after saving `iamu/context.yml`, ask the user if they want to seed baseline personas:
+
+> Context saved to `iamu/context.yml`.
+> 
+> Would you like to seed 1–2 baseline personas to your casting panel now?
+> Reply **"yes"** to propose personas, or **"skip"** to create scenarios directly via `iamu-new`.
+
+**If the user chooses "yes":**
+Propose 1–2 primary personas grounded in the confirmed actors and operational characteristics:
+
+```markdown
+### 🎭 Proposed Primary Personas
+
+#### 1. <Name> — *<Role / Title>*
+- **Context & Usage:** <Where and how they use the app (e.g. mobile on the floor vs. desktop in office)>
+- **Disposition:** <Patience level, technical confidence, key motivations>
+- **Friction Triggers:** <Specific interactions that cause friction, drop-off, or failure>
+
+#### 2. <Name> — *<Role / Title>*
+- **Context & Usage:** <Where and how they use the app>
+- **Disposition:** <Patience level, technical confidence, key motivations>
+- **Friction Triggers:** <Specific interactions that cause friction, drop-off, or failure>
+
+---
 
-   Once all confirmed personas are created, run validation once:
+**Next step:**
+Reply **"yes"** to scaffold these personas into `iamu/personas/`, or tell me what to adjust.
+```
+
+Wait for the user to confirm or adjust. Once confirmed:
+1. Scaffold personas using the CLI:
+   ```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
+   ```
+2. Validate once:
    ```bash
    iamu validate --all
    ```
+3. Confirm: "Context saved and personas seeded in iamu/personas/. Run `iamu-new` to draft your first scenario."
 
-5. Confirm: "Context saved and personas seeded in iamu/personas/. Run `iamu-new` to draft your first scenario." (or "Context saved. Run `iamu-new` to draft your first scenario." if personas were skipped).
+**If the user chooses "skip":**
+Confirm: "Context saved. Run `iamu-new` to draft your first scenario."
 
 ### 4. Offer cloud link (optional)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iamu-dev/iamu",
-  "version": "0.2.0-beta.6",
+  "version": "0.2.0-beta.9",
   "type": "module",
   "description": "Test your product as realistic personas — scenario-driven development CLI",
   "license": "UNLICENSED",
@@ -54,11 +54,12 @@
   "devDependencies": {
     "@types/node": "^22.0.0",
     "@vitest/coverage-v8": "^4.1.11",
+    "google-auth-library": "^11.1.0",
     "tsup": "^8.5.1",
     "typescript": "^5.8.0",
     "vitest": "^4.1.11",
-    "@iamu-dev/protocol": "0.1.0",
     "@iamu-dev/local-store": "0.1.0",
+    "@iamu-dev/protocol": "0.1.0",
     "@iamu/tsconfig": "0.1.0"
   },
   "scripts": {
@@ -67,6 +68,8 @@
     "typecheck": "tsc --noEmit",
     "test": "vitest run",
     "test:coverage": "vitest run --coverage",
+    "eval:walkthroughs": "vitest run --config vitest.benchmark.config.ts",
+    "eval:gemini": "node dist/eval/gemini-eval-cli.js",
     "pack:dry-run": "npm pack --dry-run"
   }
 }

package/dist/commands/start-run.d.ts

@@ -1,52 +0,0 @@
-import { type BuildMetadata, type RunViewport, type ScenarioFrontmatter } from "@iamu-dev/protocol";
-/**
- * The URL a run starts at: `--target` (or the scenario's `target_url`)
- * as the base, with the scenario's `entry_path` resolved against it.
- * Returns an error message instead when there is nothing usable.
- */
-export declare function resolveStartUrl(target: string | undefined, scenario: Pick<ScenarioFrontmatter, "target_url" | "entry_path">): {
-    url: string;
-} | {
-    error: string;
-};
-/**
- * Fast preflight probe to check if the target URL answers HTTP requests.
- * Times out quickly (default: 1000ms) to avoid stalling walkthrough initialization.
- */
-export declare function checkTargetReachable(url: string, timeoutMs?: number): Promise<{
-    reachable: boolean;
-    error?: string;
-}>;
-/**
- * The build as one line: label, branch, commit and CI provider. A dirty
- * tree shows next to the commit, so a re-run after an uncommitted fix
- * visibly walks a different build.
- *
- * @example
- * ```ts
- * formatBuild({ git_sha: "90e2444…", git_dirty: true, worktree_hash: "3fa9c1d2e4b5" });
- * // "90e2444 + uncommitted changes (3fa9c1…)"
- * ```
- */
-export declare function formatBuild(build: BuildMetadata): string;
-/**
- * A run viewport as one line.
- *
- * @example
- * ```ts
- * formatViewport({ device: "desktop", width: 1280, height: 800, source: "persona-tags" });
- * // "desktop 1280×800 (from persona tags)"
- * ```
- */
-export declare function formatViewport(v: RunViewport): string;
-export interface StartRunOptions {
-    target?: string;
-    build?: string;
-    env?: string;
-    json?: boolean;
-    check?: boolean;
-    walker?: string;
-    judge?: string;
-    matcher?: string;
-}
-export declare function startRun(scenarioSlug: string, opts: StartRunOptions): Promise<void>;