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

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

@@ -99,29 +99,20 @@ Prompt the user to verify the safety boundary:
     2. "Adjust boundaries (add forbidden external URLs, change dev command or port)"
     3. "Skip safety fence for now"
 - Otherwise (text-only/CLI):
-
-```text
-Confirm safety fence and dev environment?
-  1. [Recommended] Safety boundaries look safe — save fence and proceed
-  2. Adjust boundaries (add forbidden external URLs, change dev command or port)
-  3. Skip safety fence for now
-
-Reply '1' to accept [default], select 2-3, or tell me what to adjust:
-```
+  Safety boundaries look safe. I recommend saving fence and proceeding.
+  Proceeding to save safety fence — say "adjust" to change boundaries or "skip" to defer.
 
 **Action on confirmation (Option 1):**
-Write `iamu/testability.md`:
-```markdown
----
-target_url: <target_url>
-dev_command: <dev_command>
-auth_strategy: <dev_switcher | interactive | test_accounts | public>
-access: <How a walker becomes a given user: the switching mechanism, e.g. 'In the page, run localStorage.setItem("dev_persona", "<persona access>") and reload.' Omit when unknown. Never passwords or tokens.>
-harnesses:
-  - <detected harnesses>
----
-
-# Project Testability & Environment
+Persist the safety fence using `iamu set testability` (never invoke host file creation or edit tools):
+```bash
+iamu set testability \
+  --target "<target_url>" \
+  --dev-command "<dev_command>" \
+  --auth-strategy "<dev_switcher | interactive | test_accounts | public>" \
+  [--access "<access mechanism>"] \
+  [--harnesses "<detected harness 1>, <detected harness 2>"] \
+  [--untestable-boundaries "<external dependency 1>, <external dependency 2>"] \
+  --body "# Project Testability & Environment
 
 ## Target & Run Instructions
 - Command: <dev command>
@@ -137,7 +128,8 @@ harnesses:
 - <List existing MSW mock files, DB seed scripts, or fixture directories>
 
 ## Untestable Boundaries (Do Not Walk)
-- <List un-mocked external dependencies and external submission portals>
+- <List un-mocked external dependencies and external submission portals>" \
+  --json
 ```
 
 ---
@@ -171,33 +163,20 @@ Prompt the user to verify the project description:
     2. "Save project description only (skip scenario creation for now)"
     3. "Adjust domain or description"
 - Otherwise (text-only/CLI):
-
-```text
-Confirm project domain & description?
-  1. [Recommended] Project description is accurate — proceed to design first test
-  2. Save project description only (skip scenario creation for now)
-  3. Adjust domain or description
-
-Reply '1' to accept [default], select 2-3, or tell me what to adjust:
-```
+  Project description is accurate. I recommend proceeding to design your first test.
+  Proceeding to first test design — say "save only" or describe adjustments to change course.
 
 **Action on confirmation (Option 1):**
-Write `iamu/context.yml`. Put structured fields in frontmatter and the project description in the markdown body below the `---`:
-```yaml
----
-schema_version: 1
-domain: <domain>
-# industry: <industry>               # optional
-# jurisdiction: <jurisdiction>       # strictly optional - omit if standard web app
-# governed_by:                      # strictly optional - omit if not regulated
-#   - name: <statutory regulation>
-#     authority_level: regulation
----
-
-<The substantive 1–2 paragraph project description and core user workflows>
+Persist the domain context using `iamu set context` (never invoke host file creation or edit tools). Put structured fields in frontmatter and the project description in the markdown body below the `---` via `--body`:
+```bash
+iamu set context \
+  --domain "<domain>" \
+  [--industry "<industry>"] \
+  --body "<The substantive 1–2 paragraph project description and core user workflows>" \
+  --json
 ```
 
-*If user chooses Option 2 (Save context only):* write `context.yml` and exit cleanly:
+*If user chooses Option 2 (Save context only):* run `iamu set context ...` as above, and exit cleanly:
 "✓ Project context initialized. When you're ready to create your first test journey, run `/iamu:new`."
 
 ---
@@ -213,6 +192,7 @@ Step 3/3: Co-Design Your First Test Journey
 Why this matters: Validates whether a real human with specific operational pressures can complete a critical task without getting blocked or frustrated.
 
 Baseline Test Proposal (WYSIWGW Spec-Sheet):
+  Capability:         <Capability Name> (<What staff can do in this area>)
   Persona:            <Name> (<Role / Title>)
                       • Reality: <Working context, physical habits, tenure, pressures>
                       • Friction: <Diagnostic friction, skepticism, bounce trigger>
@@ -234,31 +214,27 @@ Prompt the user to verify the scenario and its auth precondition:
     3. "Switch role / design a different scenario (write-in)"
     4. "Skip scenario for now"
 - Otherwise (text-only/CLI):
-
-```text
-Scaffold this baseline journey?
-  1. [Recommended] Scaffold journey with <detected auth mechanism>
-  2. Use interactive human login handshake (pause browser for live login)
-  3. Switch role / design a different scenario
-  4. Skip scenario for now
-
-Reply '1' to accept [default], select 2-4, or tell me what to adjust:
-```
+  I recommend Option 1: Scaffold journey with <detected auth mechanism>.
+  Proceeding to scaffold baseline journey — say "interactive login", "switch role", or "skip" to adjust.
 
 **Action on confirmation (Option 1 or Option 2):**
-1. **Scaffold Persona**:
+1. **Scaffold Primary Capability** (if not already existing):
    ```bash
-   iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --body "<2-4 sentence narrative detailing technical habits, patience level, and specific friction triggers>" [--access "<account-or-role>"] --json
+   iamu new capability --name "<Capability Name>" --description "<What staff can do in this area>" --json
    ```
 2. **Scaffold Situation Outline**:
    ```bash
-   iamu new outline --name "<Outline Title>" --tension "<Core Tension>" --human-test "<Concrete yes/partial/no evaluation question>" --narrative "<2-3 sentence problem-space narrative without UI terms>" --json
+   iamu new outline --name "<Outline Title>" --capability "<capability-slug>" --tension "<Core Tension>" --human-test "<Concrete yes/partial/no evaluation question>" --narrative "<2-3 sentence problem-space narrative without UI terms>" --json
+   ```
+3. **Scaffold Persona**:
+   ```bash
+   iamu new persona --name "<Name>" --role "<Role>" --disposition "<Disposition>" --body "<2-4 sentence narrative detailing technical habits, patience level, and specific friction triggers>" [--access "<account-or-role>"] --json
    ```
-3. **Scaffold Bound Scenario**:
+4. **Scaffold Bound Scenario**:
    ```bash
    iamu new scenario --name "<persona-slug>--<outline-slug>" --outline "<outline-slug>" --persona "<persona-slug>" --entry "<entry_path>" --body "<Persona's first-person test brief describing what they intend to achieve>" --json
    ```
-4. **Validate all entities**:
+5. **Validate all entities**:
    ```bash
    iamu validate --all
    ```
@@ -325,6 +301,7 @@ If login times out or fails:
 - **Clean terminal formatting.** Do not wrap agent briefings in markdown code fences (` ``` `). Use fixed column alignment for attributes and clean tree diagrams for generated files.
 - **Non-regulated software is the default.** Do not invent or force regulations (`governed_by`) on apps, developer tools, or consumer software. If the codebase has no compliance documentation, omit `governed_by` entirely.
 - **Explore automatically.** Read the codebase before asking the user anything. The user should only need to confirm or correct, not describe their own project from scratch.
-- **Context on disk is load-bearing.** Once step 4 writes `iamu/context.yml`, every downstream skill (`iamu-new`, `iamu-run`) auto-loads it.
+- **Context on disk is load-bearing.** Once `iamu set context` writes `iamu/context.yml`, every downstream skill (`iamu-new`, `iamu-run`) auto-loads it.
+- **Never invoke host Edit or Write tools.** Always scaffold or modify configuration and entities via `iamu set` and `iamu new` shell commands. Host tool edits trigger modal confirmation tripwires for the user.
 - **Handle re-runs gracefully.** An already-scaffolded project is a no-op on scaffold, a refresh on context/personas/scenarios (if the user opts in), and a re-prompt on cloud link.
 - **Handle errors gracefully.** Unreachable file → note it, move on. Unreachable cloud → report and let the user retry or defer.

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

@@ -105,6 +105,17 @@ Now present the **Strategic Fork** to the user. Do not be an unyielding bureaucr
 - State: "This situation reads a public page and requires no pre-existing world state."
 - Mark `--state-description "No particular data needed"`.
 
+**Interactive Decision Gate:**
+- If your environment provides an interactive user-prompt tool (e.g. `ask_question`, `ask_followup_question`), invoke it:
+  - Question: "How should we stage '<scenario-slug>' for walkthrough?"
+  - Options:
+    1. "[Recommended] Option A: Build Testability (<brief seed proposal>)"
+    2. "Option B: Semantic Squinting (test immediately against current dev database)"
+    3. "Option C: Zero Setup Needed (public or self-contained flow)"
+- Otherwise (in CLI or text-only environments):
+  I recommend Option A: Build Testability (<brief seed proposal>).
+  Proceeding with testability setup — say "squint" for Option B, or "zero setup" for Option C to change course.
+
 ### 4. Apply & Persist Staging
 
 Once the user chooses (or confirms):

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

@@ -57,7 +57,7 @@ The directory `iamu/.prompts/` contains internal prompt templates (`persona.md`,
 
 For a project-status question, add one line on the cloud from `iamu status --json` (`mode`, `sync`, `requests`) and `iamu auth status --json` (`authenticated`):
 
-- **Linked** → `Cloud: linked — <url from iamu open --print>`, then only what needs action: unpushed changes (`sync.pending_new` + `sync.pending_updates` + `walkthroughs.pending`, and `sync.local_deletions.count`) → `iamu sync`; `requests.open` above zero → `<N> team requests — iamu-findings`.
+- **Linked** → `Cloud: linked — [Open Project in Iamu Cloud](<url from iamu open --print>)`, then only what needs action: unpushed changes (`sync.pending_new` + `sync.pending_updates` + `walkthroughs.pending`, and `sync.local_deletions.count`) → `iamu sync`; `requests.open` above zero → `<N> team requests — iamu-findings`.
 - **Linked, no credentials** → `Cloud: linked, but this machine has no credentials — iamu auth login.`
 - **Local-only** → `Cloud: local-only.` Nothing more; no upgrade pitch.
 

package/dist/ui/symbols.d.ts

@@ -8,4 +8,5 @@ export declare const symbols: {
     info: string;
     dot: string;
     question: string;
+    step: string;
 };

package/package.json

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