@iamu-dev/iamu 0.2.0-beta.16 → 0.2.0-beta.17

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

@@ -226,9 +226,22 @@ If `<N> > 0` findings were queued for fix:
 
 - **Executing the queued fixes:**
   When Option 1 is chosen, apply code edits for each queued finding sequentially in the workspace. Verify the changes once (run test/typecheck suite). Update each finding with `iamu triage <slug> --status addressed --note "<summary of fix>"`.
-  Tell the user: "✓ Applied fixes for <N> findings. All marked addressed."
+  Run `iamu validate --all` to verify all entities before reporting done.
 
-Run `iamu validate --all` to verify all entities before reporting done.
+- **Closed-Loop Regression Verification (1-Click):**
+  If the addressed findings belong to a known scenario:
+  - If interactive tool available:
+    - Question: "Fixes applied and validated. Verify them now with a walkthrough re-run?"
+    - Options:
+      1. "[Recommended] Re-run walkthrough for <scenario-slug> to verify fixes hold"
+      2. "Done for now (leave verification for later)"
+  - Otherwise (CLI / text-only):
+    Verify fixes now?
+      1. [Recommended] Re-run walkthrough for <scenario-slug> to verify fixes hold
+      2. Done for now (leave verification for later)
+    Press Enter to re-run [1], select 2:
+
+  When Option 1 is chosen, hand off to `iamu-run <scenario-slug>` to re-run the walkthrough, visit the revisit places, verify resolutions in `canonical.json`, and report the verified delta.
 
 ### 6. Publish and link (linked mode only)
 

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

@@ -200,19 +200,24 @@ Use CLI commands to scaffold entities with valid frontmatter. The CLI generates
 
 **1. Capability** (only if new):
 ```bash
-iamu new capability --name "Incident Reporting" --description "What staff can do when something goes wrong on shift" --json
+iamu new capability --name "Incident Reporting" \
+  --description "What staff can do when something goes wrong on shift" \
+  --paths "/incidents" \
+  --area "Operations" \
+  --json
 ```
 
 **2. Outline** (the situation — problem-space, no UI references):
 ```bash
 iamu new outline --name "Busy shift handoff" \
   --capability incident-reporting \
+  --additional-capabilities team-access \
   --tension "Incident details are fragmented across multiple logs while shift time expires" \
   --narrative "A shift leader needs to hand off a set of open incidents to the incoming supervisor." \
   --human-test "Could the incoming leader act immediately without asking clarifying questions?" \
   --json
 ```
-The `--capability`, `--tension`, `--narrative`, and repeatable `--human-test` flags populate outline frontmatter directly. The outline body stays empty. If specialized fields like `situation_roles` are needed, edit the generated frontmatter.
+The `--capability`, `--additional-capabilities`, `--tension`, `--narrative`, and repeatable `--human-test` flags populate outline frontmatter directly. The outline body stays empty. If specialized fields like `situation_roles` are needed, edit the generated frontmatter.
 
 **3. Persona** (if user picked a new persona to scaffold):
 ```bash

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

@@ -52,7 +52,16 @@ Read existing entities to understand what's already been tested:
 - `iamu/scenarios/` — what's already bound to personas?
 - `iamu/personas/` — who do we already have in our casting panel?
 
-Build a coverage picture: which capabilities have scenarios? Which actors from `context.yml` lack personas? Where are the gaps?
+**Check Live Product Map Coverage:**
+Inspect live surface coverage by checking `iamu status --json` (`explore`) or running `iamu explore coverage --json`:
+- **When an explore map exists:**
+  Extract unreached surfaces (`unreached` array) and `run_only_places`.
+  - **Grounding proposals in unreached topology:** Prioritize proposing scenarios that enter through or traverse these unreached surfaces, pairing them with actors from `context.yml` who have domain tension in those areas.
+  - Set each proposed scenario's `Reachable Surface` and entry route to the unreached surface path.
+- **When no explore map exists:**
+  Proceed with domain context grounding. Note: `Tip: run iamu explore <target_url> to map live surfaces so proposals target real unreached routes.`
+
+Build a coverage picture: which capabilities have scenarios? Which actors from `context.yml` lack personas? Which discovered surfaces have 0 walkthrough coverage? Where are the gaps?
 
 ### 3. Determine focus
 
@@ -60,7 +69,7 @@ Four entry paths based on `$ARGUMENTS`:
 
 - **Persona / Tester panel** (e.g. `iamu-propose "personas"`, `"who else should we test with?"`, `"propose new personas"`) — analyze which actors from `context.yml` lack personas in `iamu/personas/`. Focus proposals on creating durable, diagnostically biased personas for uncovered roles.
 - **Area or capability** (e.g. `iamu-propose "employee provisioning"`) — focus proposals on this area. Match against capabilities and context actors/workflows.
-- **Open-ended** (e.g. `iamu-propose`, `iamu-propose "what's missing?"`) — analyze coverage gaps across both scenarios and persona diversity. Prioritize uncovered capabilities and actors without personas.
+- **Open-ended** (e.g. `iamu-propose`, `iamu-propose "what's missing?"`) — analyze coverage gaps across scenarios, persona diversity, and unreached surfaces from `iamu explore coverage`. Prioritize uncovered capabilities, actors without personas, and unreached live surfaces.
 - **Specific tension** (e.g. `iamu-propose "what happens when the safety coordinator disagrees with HR?"`) — use as seed but ground in context. Verify the tension is real (do these actors and dynamics exist in the domain?).
 
 ### 4. Present candidates (Numbered Cards)
@@ -73,16 +82,23 @@ Lead with existing coverage using clickable links, then render the candidates:
 
 ```
 Existing coverage: <N> scenarios ([<slug1>](iamu/scenarios/<slug1>.md), ...). Uncovered areas: <gaps>.
+Product map: <R>/<T> surfaces reached · <U> unreached ([view](iamu explore coverage)).
 
 1. <Short situation name> (<Actor from context>)
+   • Capability: <Capability slug, e.g. billing-invoicing>
+   • Entry route: <Unreached route from map, e.g. /billing/invoices/new>
    • Tension: <1-line human/domain tension>
    • Stress-tests: <What this reveals about the product>
 
 2. <Short situation name> (<Actor from context>)
+   • Capability: <Capability slug, e.g. team-access>
+   • Entry route: <Unreached route from map, e.g. /team/roles/custom>
    • Tension: <1-line human/domain tension>
    • Stress-tests: <What this reveals about the product>
 
 3. <Short situation name> (<Actor from context>)
+   • Capability: <Capability slug, e.g. incident-response>
+   • Entry route: <Unreached route from map, e.g. /incidents/export>
    • Tension: <1-line human/domain tension>
    • Stress-tests: <What this reveals about the product>
 
@@ -141,7 +157,7 @@ Ground rules for generation:
 
 ### 5. Selection and Handoff
 
-- **User picks a scenario candidate (e.g. "1" or Enter)** → Immediately invoke `iamu-new` in **Fast-Path Scenario Mode** passing the selected candidate title, actor, tension, and evaluation checkpoint as structured arguments. Do NOT allow `iamu-new` to restart seed brainstorming. It must present the single Scenario Spec-Sheet directly for instant 1-click persistence.
+- **User picks a scenario candidate (e.g. "1" or Enter)** → Immediately invoke `iamu-new` in **Fast-Path Scenario Mode** passing the selected candidate title, actor, primary capability slug (`--capability`), entry path (`--entry`), tension, and evaluation checkpoint as structured arguments. Do NOT allow `iamu-new` to restart seed brainstorming. It must present the single Scenario Spec-Sheet directly for instant 1-click persistence.
 - **User picks a persona candidate** → Immediately invoke `iamu-new` in **Standalone Persona Mode** with the candidate's name, role, disposition, and friction triggers to scaffold directly into `iamu/personas/<slug>.md`.
 - **User refines** → regenerate candidates applying the requested adjustments.
 - **User rejects all** → ask what domain area or actor they want to explore. Loop back to step 4.

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

@@ -144,7 +144,27 @@ After bind + brief, the scenario is ready to execute. Continue to step 3.
 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. If `localhost` is unreachable, prompt the user to boot their dev server (e.g. `npm run dev`) or ask before launching it, so the walker does not fail against an unstarted port.
+**Dev Server Preflight Check:**
+Verify target reachability before launching the walker with `iamu doctor --target <url>` (or a fast HTTP probe).
+If the target is a local URL (e.g. `http://localhost:*`, `http://127.0.0.1:*`) and is unreachable:
+1. Inspect `iamu/testability.md` for `Command:` under `## Target & Run Instructions` (or check `package.json` for a `dev` or `start` script).
+2. Prompt the user:
+   - If interactive tool available:
+     - Question: "Target URL <url> is unreachable. Boot dev server now?"
+     - Options:
+       1. "[Recommended] Boot dev server in background (`<dev_command>`) and proceed"
+       2. "I will start the dev server manually (wait for port)"
+       3. "Specify a different target URL"
+   - Otherwise (CLI / text-only):
+     Target URL <url> is unreachable. Boot dev server now?
+       1. [Recommended] Boot dev server in background (`<dev_command>`) and proceed
+       2. I will start the dev server manually (wait for port)
+       3. Specify a different target URL
+     Press Enter to boot dev server [1], select 2-3:
+3. If Option 1 is chosen:
+   - Launch `<dev_command>` in the background as a managed daemon process.
+   - Poll `<url>` with HTTP requests until it responds (timeout: 30s).
+   - Once reachable, proceed immediately to the walkthrough.
 
 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.
 
@@ -512,8 +532,34 @@ When the user asks to review findings one by one:
      Tell the user: "✓ Applied fixes for <K> findings. All marked addressed."
 
    - Run `iamu validate --all`.
-   - In linked mode, run `iamu sync --json` once so teammates see the triage decisions.
-   - Suggest re-running the walkthrough: `iamu-run <scenario-slug>` to verify fixes.
+
+   - **Closed-Loop Regression Verification (1-Click):**
+     Immediately prompt the user to verify the fixes hold in practice:
+     - If interactive tool available:
+       - Question: "Fixes applied and validated. Verify them now with a walkthrough re-run?"
+       - Options:
+         1. "[Recommended] Re-run walkthrough to verify fixes hold"
+         2. "Done for now (leave verification for later)"
+     - Otherwise (CLI / text-only):
+       Verify fixes now?
+         1. [Recommended] Re-run walkthrough to verify fixes hold
+         2. Done for now (leave verification for later)
+       Press Enter to re-run [1], select 2:
+
+     When Option 1 is chosen:
+     1. Start the verification run: `iamu start-run <scenario-slug> --target <target> --json`. Note: `start-run` automatically pulls all awaiting findings into `revisit` places in `walkthrough.json`.
+     2. Walk through the scenario, ensuring the persona visits the revisit places.
+     3. Assemble the run with `iamu complete <run-id> --json`. The canonical assembly compares against the baseline run and outputs `verification` (`resolved`, `persists`, `new_findings`).
+     4. Report the verification verdict:
+        ```text
+        Verification Complete:
+          Scenario: <scenario-slug>
+          Baseline run: <baseline_run_id>
+          Verified fixes: ✓ <N> resolved
+          Regressions: 0 new findings
+        ```
+     5. If any finding persists or a regression occurred, present only the remaining items for follow-up triage.
+     6. In linked mode, run `iamu sync --json` once so teammates see the verified decisions.
 
 #### B. Direct Batch Actions ("fix 1 and 2", "fix all critical")
 Read the finding details from the canonical JSON (already in context), inspect the code, make the edits, and update frontmatter to `triage_status: addressed` with `triage_note`.

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
+Product Map:    <T> Surfaces (<R> Reached · <U> Unreached) [if explore map exists]
 ```
 
 **Personas:**
@@ -40,6 +41,14 @@ Project Status: <P> Personas · <S> Scenarios (<R> Tested, <U> Untested) · <F>
 **Findings:**
 • `1` [CRITICAL · hinders] Submit fails opaquely on empty field — [`view`](iamu/findings/<slug>.md)
 
+**Awaiting Verification (Needs a Re-run):**
+If `iamu status` reports fixes awaiting a re-run:
+• [`<scenario-slug>`](iamu/scenarios/<scenario-slug>.md) — <N> fixes awaiting verification from a re-run (`iamu-run <scenario-slug>`)
+
+**Product Map & Unreached Surfaces:**
+If `iamu status --json` has `explore` data:
+• <T> surfaces mapped (<R> reached, <U> unreached) — run `iamu explore coverage` to inspect blind spots or `/iamu:propose` to target unreached surfaces.
+
 ### 3. Ignore internal templates
 
 The directory `iamu/.prompts/` contains internal prompt templates (`persona.md`, `outline.md`, etc.). These are NOT project entities. Never list them or explain them to the user.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iamu-dev/iamu",
-  "version": "0.2.0-beta.16",
+  "version": "0.2.0-beta.17",
   "type": "module",
   "description": "Test your product as realistic personas — scenario-driven development CLI",
   "license": "UNLICENSED",
@@ -43,16 +43,6 @@
   "engines": {
     "node": ">=22"
   },
-  "scripts": {
-    "build": "tsup && tsc -b --force tsconfig.build.json --emitDeclarationOnly && node scripts/copy-assets.mjs",
-    "clean": "node -e \"fs.rmSync('dist', { recursive: true, force: true }); fs.rmSync('tsconfig.tsbuildinfo', { force: true }); fs.rmSync('tsconfig.build.tsbuildinfo', { force: true })\"",
-    "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"
-  },
   "dependencies": {
     "@clack/prompts": "^1.8.1",
     "@modelcontextprotocol/sdk": "^1.26.0",
@@ -62,14 +52,24 @@
     "zod": "^3.25.0"
   },
   "devDependencies": {
-    "@iamu-dev/local-store": "workspace:*",
-    "@iamu-dev/protocol": "workspace:*",
-    "@iamu/tsconfig": "workspace:*",
     "@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"
+    "vitest": "^4.1.11",
+    "@iamu-dev/local-store": "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",
+    "clean": "node -e \"fs.rmSync('dist', { recursive: true, force: true }); fs.rmSync('tsconfig.tsbuildinfo', { force: true }); fs.rmSync('tsconfig.build.tsbuildinfo', { force: true })\"",
+    "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"
   }
-}
+}