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

package/dist/index.js

@@ -823,7 +823,14 @@ var init_scenario = __esm({
       reviews: z15.array(z15.string().min(1).max(64)).max(16).default([]),
       baseline_score: z15.number().min(0).max(100).nullish(),
       current_score: z15.number().min(0).max(100).nullish(),
-      target_score: z15.number().min(0).max(100).default(95)
+      target_score: z15.number().min(0).max(100).default(95),
+      /** Environment state preconditions and approximation guidance. */
+      state: z15.object({
+        /** Description of data/records expected to exist in the environment. */
+        description: z15.string().max(2048).nullish(),
+        /** Guidance on how to squint or approximate if exact records are absent. */
+        approximation: z15.string().max(2048).nullish()
+      }).nullish()
     });
   }
 });
@@ -12304,15 +12311,6 @@ function mcpJson(cmd) {
     2
   );
 }
-function vscodeMcpJson(cmd) {
-  return JSON.stringify(
-    {
-      servers: { iamu: { type: "stdio", command: cmd[0], args: cmd.slice(1) } }
-    },
-    null,
-    2
-  );
-}
 function detectHosts(projectRoot) {
   return HOST_ADAPTERS.filter(
     (host) => host.detectionPaths.some((p) => existsSync3(join3(projectRoot, p)))
@@ -12361,13 +12359,17 @@ var init_registry = __esm({
       {
         name: "GitHub Copilot",
         value: "github-copilot",
-        detectionPaths: [".vscode", ".github/copilot-instructions.md"],
-        supportsSkills: false,
-        getSkillsDir: () => "",
-        getCommandPath: (root, id) => join3(root, ".github", "prompts", `iamu-${id}.prompt.md`),
-        formatCommand: descOnlyFormat,
-        getMcpConfigPath: (root) => join3(root, ".vscode", "mcp.json"),
-        formatMcpConfig: vscodeMcpJson
+        detectionPaths: [
+          ".github/copilot-instructions.md",
+          ".github/skills",
+          ".copilot"
+        ],
+        supportsSkills: true,
+        getSkillsDir: (root) => join3(root, ".github", "skills"),
+        getCommandPath: (root, id) => join3(root, ".github", "skills", `iamu-${id}`, "SKILL.md"),
+        formatCommand: richFormat,
+        getMcpConfigPath: (root) => join3(root, ".mcp.json"),
+        formatMcpConfig: mcpJson
       },
       {
         name: "Cline",
@@ -12549,6 +12551,14 @@ function isCliWrittenSkill(path28) {
     return false;
   }
 }
+function isCliWrittenPrompt(path28) {
+  try {
+    const content = readFileSync3(path28, "utf-8");
+    return content.includes("iamu") || /^generatedBy:/m.test(content);
+  } catch {
+    return false;
+  }
+}
 function planSkillFiles(hosts, projectRoot, version) {
   const skillTemplates = loadSkillTemplates(version);
   const files = [];
@@ -12577,6 +12587,19 @@ function planSkillFiles(hosts, projectRoot, version) {
           }
         }
       }
+      if (host.value === "github-copilot") {
+        for (const cmd of commandsFromSkills(skillTemplates)) {
+          const legacyPrompt = join4(
+            projectRoot,
+            ".github",
+            "prompts",
+            `iamu-${cmd.id}.prompt.md`
+          );
+          if (isCliWrittenPrompt(legacyPrompt)) {
+            files.push({ host, path: legacyPrompt, content: null });
+          }
+        }
+      }
     } else {
       for (const cmd of commandsFromSkills(skillTemplates)) {
         files.push({
@@ -12601,6 +12624,15 @@ function detectInstalledHosts(projectRoot) {
       const skillDir = join4(host.getSkillsDir(projectRoot), "iamu-setup");
       if (existsSync5(skillDir)) return true;
     }
+    if (host.value === "github-copilot") {
+      const legacyPrompt = join4(
+        projectRoot,
+        ".github",
+        "prompts",
+        "iamu-setup.prompt.md"
+      );
+      if (existsSync5(legacyPrompt)) return true;
+    }
     return false;
   });
 }
@@ -16320,7 +16352,10 @@ var init_browse_actions = __esm({
         usage: "goto <url>",
         minArgs: 1,
         run: async (p, args) => {
-          await p.goto(args[0], { waitUntil: "domcontentloaded" });
+          await p.goto(args[0], {
+            waitUntil: "domcontentloaded",
+            timeout: 1e4
+          });
         }
       },
       click: {
@@ -16481,6 +16516,12 @@ var init_browse_driver = __esm({
       commandLine: (pid) => readProcessCommandLine(pid),
       kill(pid) {
         try {
+          if (process.platform !== "win32") {
+            try {
+              process.kill(-pid, "SIGTERM");
+            } catch {
+            }
+          }
           process.kill(pid, "SIGTERM");
         } catch {
         }
@@ -16857,6 +16898,8 @@ function chromeArgs(opts, port, headless) {
     `--window-size=${opts.width ?? "1280"},${opts.height ?? "900"}`,
     "--no-first-run",
     "--no-default-browser-check",
+    "--password-store=basic",
+    "--use-mock-keychain",
     ...headless ? ["--headless=new", "--disable-dev-shm-usage", "--disable-gpu"] : [],
     ...shouldDisableSandbox() ? ["--no-sandbox"] : [],
     "about:blank"
@@ -18533,13 +18576,21 @@ function defaultFrontmatter(type2, id, slug, name, opts) {
         url: opts.url,
         authority_level: opts.authority ?? "informational"
       };
-    case "scenario":
+    case "scenario": {
+      const stateObj = opts.stateDescription || opts.stateApproximation ? {
+        state: {
+          ...opts.stateDescription ? { description: opts.stateDescription } : {},
+          ...opts.stateApproximation ? { approximation: opts.stateApproximation } : {}
+        }
+      } : {};
       return {
         ...base,
         outline: opts.outline ?? null,
         persona: opts.persona ?? null,
-        ...opts.entry ? { entry_path: opts.entry } : {}
+        ...opts.entry ? { entry_path: opts.entry } : {},
+        ...stateObj
       };
+    }
     default:
       return base;
   }
@@ -18933,6 +18984,17 @@ function composeWalkerPrompt(p) {
     "",
     "## First-person brief",
     p.brief ?? "",
+    ...p.context ? ["", "## Product domain & regulatory context", p.context.trim()] : [],
+    ...p.state?.description || p.state?.approximation ? [
+      "",
+      "## Expected state & semantic squinting",
+      p.state.description ? `Expected state: ${p.state.description}` : "",
+      p.state.approximation ? `Approximation strategy: ${p.state.approximation}` : "",
+      "Squinting Guardrails:",
+      "\u2022 If the exact target record/option is not available, apply the approximation strategy above to pick the closest plausible entity within the domain flow.",
+      "\u2022 Squinting does NOT permit drifting to unrelated settings, account profiles, or off-target pages. Stay strictly within the scenario journey.",
+      "\u2022 If the system is completely empty or unseeded, and your persona role cannot create data, do NOT report false product bugs about the empty state. Note that preconditions are unseeded/blocked."
+    ].filter(Boolean) : [],
     ...revisitSection(p.revisit ?? []),
     "",
     "## Access",
@@ -19081,7 +19143,8 @@ async function instructionsWalk(opts) {
   const result = {
     scenario: {
       slug: sfm.slug,
-      brief: scenario.body.trim() || null
+      brief: scenario.body.trim() || null,
+      state: sfm.state ?? null
     },
     persona: {
       slug: sfm.persona,
@@ -19135,7 +19198,9 @@ async function instructionsWalk(opts) {
       runDirPath,
       projectRoot,
       surface: opts.surface ?? "browse",
-      viewport
+      viewport,
+      state: sfm.state ?? null,
+      context: contextYml
     }) : null
   };
   if (opts.json) {
@@ -19147,6 +19212,11 @@ async function instructionsWalk(opts) {
   console.log(`  ${chalk26.dim("scenario:")}  ${sfm.slug}`);
   console.log(`  ${chalk26.dim("persona:")}   ${pfm.name} (${pfm.role})`);
   console.log(`  ${chalk26.dim("outline:")}   ${ofm.title}`);
+  if (sfm.state?.description || sfm.state?.approximation) {
+    console.log(
+      `  ${chalk26.dim("state:")}     ${sfm.state.description ? sfm.state.description : sfm.state.approximation ?? ""}`
+    );
+  }
   if (targetUrl) console.log(`  ${chalk26.dim("target:")}    ${targetUrl}`);
   console.log(
     `  ${chalk26.dim("access:")}    ${projectAccess || personaAccess ? `${projectAccess ? "project" : ""}${projectAccess && personaAccess ? " + " : ""}${personaAccess ? "persona" : ""}` : "not recorded (walker would run as whoever is signed in)"}`
@@ -20822,6 +20892,12 @@ function registerProjectCommands(program) {
   ).option("--outline <slug>", "Outline slug (scenario only)").option("--persona <slug>", "Persona slug (scenario only)").option(
     "--entry <path>",
     "Where the situation starts, as a path on the product, e.g. /en/episodes/1 (scenario only)"
+  ).option(
+    "--state-description <text>",
+    "Assumed environment data/records state (scenario only)"
+  ).option(
+    "--state-approximation <text>",
+    "Guidance on how persona should approximate/squint if records are missing (scenario only)"
   ).option("--url <url>", "Document the source cites (source only, required)").option(
     "--authority <level>",
     "legislation | regulation | standard | company_policy | guideline | informational (source only, default informational)"

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,13 @@ 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">
 ```
 
-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 +168,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

@@ -39,7 +39,6 @@ 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.
 
 ### 2. Load existing coverage
@@ -116,7 +115,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

@@ -127,19 +127,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,131 @@ 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:**
+Do NOT collect code architecture (agent reads the codebase directly — tech stack doesn't affect walkthroughs).
 
-```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.
+- **Do NOT ask upfront about auth mechanics (`access`) or compliance frameworks (`governed_by`).** Infer if obvious, otherwise leave them blank.
 
----
+**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.
+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.
 
-### 3. Capture domain context and scaffold personas
+### 3. Capture domain context and seed personas (Two-Phase Confirmation)
 
-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.
-
-2. **Branch on what you find:**
-
-   - **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):**
+#### Phase B: Persona Casting (Opt-In & Separate Confirmation)
+Immediately after saving `iamu/context.yml`, ask the user if they want to seed baseline personas:
 
-   Use the CLI to scaffold valid persona entities with schema-compliant UUIDs, slugs, frontmatter, and narrative body in a single command:
+> 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>
+
+---
+
+**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
    ```
-
-   If `iamu/context.yml` specifies an `access` mechanism, pass `--access "<role>"` matching an existing product account/role.
-
-   Once all confirmed personas are created, run validation once:
+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.7",
   "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"
   }
 }