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

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

@@ -99,6 +99,9 @@ Roles with Stakes:
 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, preconditions, or circumstances? (Enter to accept, or type adjustments)"

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

@@ -33,7 +33,7 @@ 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?
@@ -41,6 +41,11 @@ Read `iamu/context.yml`. Extract and hold:
 - **Governed_by** — regulations and standards (if applicable). These create structural tensions in regulated domains.
 - **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:

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.
 

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

@@ -59,7 +59,8 @@ Synthesize the project into a cohesive, substantive narrative (1–2 paragraphs)
 - Key user journeys and operational characteristics (e.g. mobile floor use, audit deadlines).
 - Market, geography, and specific compliance frameworks (only if evident).
 
-Do NOT collect code architecture (agent reads the codebase directly — tech stack doesn't affect walkthroughs).
+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`.
 
 **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:
@@ -71,7 +72,6 @@ Do NOT collect code architecture (agent reads the codebase directly — tech sta
 - **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):**
 
@@ -124,6 +124,39 @@ Once the user confirms the narrative description:
    - `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.
 
+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:
+
+   ```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>
+   ```
+
+   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:
 

package/package.json

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