@iamu-dev/iamu 0.2.0-beta.2 → 0.2.0-beta.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -44,33 +44,48 @@ Explore the codebase automatically — do NOT ask the user what files to read. B
|
|
|
44
44
|
|
|
45
45
|
Extract these key dimensions:
|
|
46
46
|
|
|
47
|
-
1. **Domain** — what
|
|
48
|
-
2. **Jurisdiction** — country
|
|
49
|
-
3. **
|
|
50
|
-
4. **
|
|
47
|
+
1. **Domain & Purpose** — what this product does, core workflows, and problem space (mandatory).
|
|
48
|
+
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.
|
|
49
|
+
3. **Key Actors & Roles** — the main user archetypes and roles discovered in the codebase (auth models, routes, permissions).
|
|
50
|
+
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.
|
|
51
|
+
5. **Key Terminology (`glossary`)** — 2–4 domain-specific terms or acronyms found in the codebase.
|
|
52
|
+
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:
|
|
51
53
|
- Name and Role
|
|
52
54
|
- Disposition / perspective (patience level, tech literacy, primary friction triggers)
|
|
53
55
|
|
|
54
|
-
|
|
55
|
-
- **Actors** — all identified roles and their responsibilities.
|
|
56
|
-
- **Glossary** — domain-specific terms (helps persona language fidelity).
|
|
57
|
-
- **Access** — if the project documents how to switch user or role in a dev or test environment (a persona switcher, seeded accounts, a storage key), record that mechanism as `access`. It is what lets a walkthrough run as the persona instead of as whoever happens to be signed in. Never record passwords or tokens — name where they live.
|
|
58
|
-
|
|
59
|
-
Do NOT collect architecture (agent reads the codebase directly — tech stack doesn't affect walkthroughs).
|
|
56
|
+
Do NOT collect code architecture (agent reads the codebase directly — tech stack doesn't affect walkthroughs).
|
|
60
57
|
|
|
61
58
|
**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?
|
|
62
59
|
|
|
63
|
-
**Present
|
|
60
|
+
**Present the proposal with clean, structured Markdown for confirmation:**
|
|
64
61
|
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
|
|
62
|
+
```markdown
|
|
63
|
+
### 📋 Discovered Project Context
|
|
64
|
+
|
|
65
|
+
- **Domain & Purpose:** <Concise description of the product and problem space>
|
|
66
|
+
- **Jurisdiction & Rules:** <Country/region and compliance frameworks, or "None identified">
|
|
67
|
+
- **Key Roles Identified:** <List of detected roles and their responsibilities>
|
|
68
|
+
- **Dev Access & Auth:** <Detected mechanism to switch/assume personas in dev, or "Standard login">
|
|
69
|
+
- **Domain Terminology:** <2–4 key terms/acronyms found in the codebase, if any>
|
|
70
|
+
|
|
71
|
+
---
|
|
68
72
|
|
|
69
|
-
Proposed
|
|
70
|
-
|
|
71
|
-
|
|
73
|
+
### 🎭 Proposed Primary Personas
|
|
74
|
+
|
|
75
|
+
#### 1. <Name> — *<Role / Title>*
|
|
76
|
+
- **Context & Usage:** <Where and how they use the app (e.g., mobile on the floor vs. desktop in office)>
|
|
77
|
+
- **Disposition:** <Patience level, technical confidence, key motivations>
|
|
78
|
+
- **Friction Triggers:** <Specific interactions that cause friction, drop-off, or failure>
|
|
79
|
+
|
|
80
|
+
#### 2. <Name> — *<Role / Title>*
|
|
81
|
+
- **Context & Usage:** <Where and how they use the app>
|
|
82
|
+
- **Disposition:** <Patience level, technical confidence, key motivations>
|
|
83
|
+
- **Friction Triggers:** <Specific interactions that cause friction, drop-off, or failure>
|
|
84
|
+
|
|
85
|
+
---
|
|
72
86
|
|
|
73
|
-
|
|
87
|
+
**Next step:**
|
|
88
|
+
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).
|
|
74
89
|
```
|
|
75
90
|
|
|
76
91
|
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.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@iamu-dev/iamu",
|
|
3
|
-
"version": "0.2.0-beta.
|
|
3
|
+
"version": "0.2.0-beta.3",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "Test your product as realistic personas — scenario-driven development CLI",
|
|
6
6
|
"license": "UNLICENSED",
|
|
@@ -58,8 +58,8 @@
|
|
|
58
58
|
"typescript": "^5.8.0",
|
|
59
59
|
"vitest": "^4.1.11",
|
|
60
60
|
"@iamu-dev/local-store": "0.1.0",
|
|
61
|
-
"@iamu/
|
|
62
|
-
"@iamu
|
|
61
|
+
"@iamu-dev/protocol": "0.1.0",
|
|
62
|
+
"@iamu/tsconfig": "0.1.0"
|
|
63
63
|
},
|
|
64
64
|
"scripts": {
|
|
65
65
|
"build": "tsup && tsc -b tsconfig.build.json --emitDeclarationOnly && node scripts/copy-assets.mjs",
|