viepilot 1.14.0 → 2.4.0
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.
- package/CHANGELOG.md +191 -0
- package/README.md +27 -17
- package/bin/viepilot.cjs +19 -9
- package/bin/vp-tools.cjs +193 -0
- package/docs/user/features/adapters.md +74 -0
- package/docs/user/features/hooks.md +93 -0
- package/lib/adapters/antigravity.cjs +33 -0
- package/lib/adapters/claude-code.cjs +42 -0
- package/lib/adapters/codex.cjs +34 -0
- package/lib/adapters/cursor.cjs +32 -0
- package/lib/adapters/index.cjs +28 -0
- package/lib/hooks/brainstorm-staleness.cjs +231 -0
- package/lib/viepilot-config.cjs +103 -0
- package/lib/viepilot-install.cjs +125 -152
- package/package.json +1 -3
- package/skills/vp-audit/SKILL.md +23 -23
- package/skills/vp-auto/SKILL.md +23 -9
- package/skills/vp-brainstorm/SKILL.md +44 -38
- package/skills/vp-crystallize/SKILL.md +25 -19
- package/skills/vp-debug/SKILL.md +4 -4
- package/skills/vp-docs/SKILL.md +8 -8
- package/skills/vp-evolve/SKILL.md +26 -13
- package/skills/vp-info/SKILL.md +24 -24
- package/skills/vp-pause/SKILL.md +7 -7
- package/skills/vp-request/SKILL.md +14 -14
- package/skills/vp-resume/SKILL.md +6 -6
- package/skills/vp-rollback/SKILL.md +4 -4
- package/skills/vp-status/SKILL.md +4 -4
- package/skills/vp-task/SKILL.md +2 -2
- package/skills/vp-ui-components/SKILL.md +14 -14
- package/skills/vp-update/SKILL.md +18 -18
- package/templates/architect/apis.html +11 -10
- package/templates/architect/architect-actions.js +217 -0
- package/templates/architect/architecture.html +8 -7
- package/templates/architect/data-flow.html +5 -4
- package/templates/architect/decisions.html +4 -3
- package/templates/architect/deployment.html +10 -9
- package/templates/architect/erd.html +7 -6
- package/templates/architect/feature-map.html +5 -4
- package/templates/architect/sequence-diagram.html +6 -5
- package/templates/architect/style.css +146 -0
- package/templates/architect/tech-notes.html +3 -2
- package/templates/architect/tech-stack.html +8 -7
- package/templates/architect/user-use-cases.html +8 -7
- package/templates/project/AI-GUIDE.md +49 -49
- package/workflows/audit.md +3 -3
- package/workflows/autonomous.md +70 -5
- package/workflows/brainstorm.md +398 -222
- package/workflows/crystallize.md +51 -33
- package/workflows/debug.md +9 -9
- package/workflows/documentation.md +5 -5
- package/workflows/evolve.md +46 -12
- package/workflows/pause-work.md +2 -2
- package/workflows/request.md +8 -8
- package/workflows/resume-work.md +1 -1
- package/workflows/rollback.md +1 -1
- package/dev-install.sh +0 -150
- package/install.sh +0 -125
package/workflows/brainstorm.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
<purpose>
|
|
2
|
-
Interactive brainstorm session
|
|
3
|
-
|
|
2
|
+
Interactive brainstorm session to gather ideas, requirements, and decisions for the project.
|
|
3
|
+
Allows research inline within the same brainstorm session when needed.
|
|
4
4
|
</purpose>
|
|
5
5
|
|
|
6
6
|
## ViePilot Skill Scope Policy (BUG-004)
|
|
@@ -12,6 +12,17 @@ Cho phép research ngay trong cùng phiên brainstorm khi cần.
|
|
|
12
12
|
|
|
13
13
|
<process>
|
|
14
14
|
|
|
15
|
+
<step name="detect_session_language">
|
|
16
|
+
## 0. Detect Session Language (ENH-032)
|
|
17
|
+
|
|
18
|
+
Read `~/.viepilot/config.json` → set `BRAINSTORM_LANG`:
|
|
19
|
+
- `BRAINSTORM_LANG` = `language.document` from config (default: `en`)
|
|
20
|
+
|
|
21
|
+
Use `BRAINSTORM_LANG` for brainstorm file storage (filenames, generated content).
|
|
22
|
+
If the user writes in a different language during the session, that takes precedence over the config value.
|
|
23
|
+
If `~/.viepilot/config.json` is absent, default to `en` — do not fail.
|
|
24
|
+
</step>
|
|
25
|
+
|
|
15
26
|
<step name="detect_sessions">
|
|
16
27
|
## 1. Detect Previous Sessions
|
|
17
28
|
|
|
@@ -27,38 +38,38 @@ Parse results to get list of existing sessions.
|
|
|
27
38
|
|
|
28
39
|
**If previous sessions exist:**
|
|
29
40
|
```
|
|
30
|
-
|
|
41
|
+
I found previous brainstorm sessions:
|
|
31
42
|
{list sessions with dates}
|
|
32
43
|
|
|
33
|
-
|
|
34
|
-
1.
|
|
35
|
-
2.
|
|
36
|
-
3.
|
|
44
|
+
What would you like to do?
|
|
45
|
+
1. Continue the most recent session
|
|
46
|
+
2. Review a specific session
|
|
47
|
+
3. Create a new brainstorm session
|
|
37
48
|
```
|
|
38
49
|
|
|
39
50
|
**If no sessions:**
|
|
40
|
-
|
|
51
|
+
Automatically create a new session.
|
|
41
52
|
</step>
|
|
42
53
|
|
|
43
54
|
<step name="load_context">
|
|
44
|
-
## 3. Load Context (
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
1.
|
|
48
|
-
2.
|
|
49
|
-
3.
|
|
50
|
-
4.
|
|
51
|
-
5.
|
|
55
|
+
## 3. Load Context (if continuing)
|
|
56
|
+
|
|
57
|
+
If the user chooses to continue:
|
|
58
|
+
1. Read the previous session file
|
|
59
|
+
2. Summarize content already discussed
|
|
60
|
+
3. Identify remaining open questions / action items
|
|
61
|
+
4. Continue from the stopping point
|
|
62
|
+
5. If the session already has a **`## Phases`** section: briefly summarize existing phases; all subsequent updates must **merge** into that section (no silent deletion) unless the user explicitly requests narrowing/expanding scope.
|
|
52
63
|
</step>
|
|
53
64
|
|
|
54
65
|
<step name="brainstorm_mode">
|
|
55
66
|
## 4. Brainstorm Mode
|
|
56
67
|
|
|
57
68
|
### Topics Template
|
|
58
|
-
|
|
69
|
+
Suggested topics to brainstorm:
|
|
59
70
|
|
|
60
71
|
1. **Domain Analysis**
|
|
61
|
-
-
|
|
72
|
+
- Project goals
|
|
62
73
|
- User personas
|
|
63
74
|
- Core use cases
|
|
64
75
|
|
|
@@ -88,128 +99,128 @@ Gợi ý các topics để brainstorm:
|
|
|
88
99
|
- Monitoring
|
|
89
100
|
- Scaling
|
|
90
101
|
|
|
91
|
-
6. **Phase assignment (ENH-030):**
|
|
102
|
+
6. **Phase assignment (ENH-030):** during brainstorm, each feature/capability is assigned to a specific **phase** — Phase 1, Phase 2, Phase 3... Do not use MVP/Post-MVP/Future tiers. If the user has not stated a phase, ask: “Which phase would you like to assign this feature to?”
|
|
92
103
|
|
|
93
104
|
### Interactive Q&A
|
|
94
|
-
|
|
95
|
-
1.
|
|
96
|
-
2.
|
|
97
|
-
3.
|
|
98
|
-
4.
|
|
99
|
-
5.
|
|
100
|
-
|
|
101
|
-
### Landing Page Deep-Dive (
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
1.
|
|
105
|
-
-
|
|
106
|
-
-
|
|
107
|
-
-
|
|
108
|
-
- CTA
|
|
109
|
-
2.
|
|
105
|
+
For each topic:
|
|
106
|
+
1. Ask specific questions
|
|
107
|
+
2. Wait for user response
|
|
108
|
+
3. Synthesize and ask follow-up questions
|
|
109
|
+
4. Suggest alternatives if needed
|
|
110
|
+
5. Record decisions
|
|
111
|
+
|
|
112
|
+
### Landing Page Deep-Dive (activated contextually)
|
|
113
|
+
If the user is brainstorming a landing page / homepage / marketing page:
|
|
114
|
+
|
|
115
|
+
1. Ask follow-up questions to finalize the layout:
|
|
116
|
+
- Main goal of the landing page? (signup, booking demo, download, contact)
|
|
117
|
+
- Primary audience?
|
|
118
|
+
- Visual tone? (minimal, modern, bold, enterprise, playful)
|
|
119
|
+
- Primary CTA and secondary CTA?
|
|
120
|
+
2. Present a layout menu for the user to choose from:
|
|
110
121
|
- Layout A: Hero centric + trust logos + features + CTA
|
|
111
122
|
- Layout B: Problem/Solution + social proof + pricing + FAQ
|
|
112
123
|
- Layout C: Product storytelling + screenshots + testimonials + final CTA
|
|
113
124
|
- Layout D: SaaS conversion + integrations + comparison + onboarding steps
|
|
114
|
-
3.
|
|
115
|
-
4.
|
|
116
|
-
- Layout user
|
|
117
|
-
- Component candidates
|
|
118
|
-
-
|
|
125
|
+
3. Reference `https://21st.dev` to suggest sections/components suited to the chosen layout.
|
|
126
|
+
4. Record clearly in the session:
|
|
127
|
+
- Layout the user chose
|
|
128
|
+
- Component candidates from 21st.dev
|
|
129
|
+
- Reason for choice based on objective + audience
|
|
119
130
|
|
|
120
131
|
### In-session Research Mode
|
|
121
|
-
User
|
|
122
|
-
- Trigger phrases: "research
|
|
123
|
-
-
|
|
124
|
-
1.
|
|
125
|
-
2.
|
|
126
|
-
3.
|
|
127
|
-
4.
|
|
132
|
+
User can request research inline during brainstorm (no skill switch needed):
|
|
133
|
+
- Trigger phrases: "research this", "can you research", "need to research", "find best practice"
|
|
134
|
+
- When triggered:
|
|
135
|
+
1. Define research scope (1-3 sentences)
|
|
136
|
+
2. Quickly gather from appropriate sources (official docs, reference sites, patterns)
|
|
137
|
+
3. Return a short summary: findings, trade-offs, recommendation
|
|
138
|
+
4. Return to the current brainstorm topic with a proposed decision
|
|
128
139
|
|
|
129
|
-
|
|
130
|
-
`
|
|
140
|
+
If the assistant notices a topic has high ambiguity or risk of a wrong decision, the assistant should proactively suggest:
|
|
141
|
+
`This item should be researched quickly before locking in — would you like me to research it now in this session?`
|
|
131
142
|
|
|
132
143
|
### UI Direction Mode (design-in-the-loop; FEAT-002 + FEAT-007)
|
|
133
|
-
|
|
144
|
+
If the user is brainstorming a project with UI/UX or requests a visual design:
|
|
134
145
|
|
|
135
|
-
**Layout —
|
|
146
|
+
**Layout — choose one:**
|
|
136
147
|
|
|
137
|
-
- **Legacy (
|
|
138
|
-
- **Multi-page (
|
|
148
|
+
- **Legacy (single screen):** `.viepilot/ui-direction/{session-id}/index.html` + `style.css` + `notes.md`.
|
|
149
|
+
- **Multi-page (multiple screens):** same session directory, add `pages/{slug}.html` for each page; `index.html` is the **hub** (links to every page). `style.css` is shared.
|
|
139
150
|
|
|
140
|
-
**
|
|
151
|
+
**General rules**
|
|
141
152
|
|
|
142
|
-
1.
|
|
143
|
-
2.
|
|
144
|
-
-
|
|
145
|
-
-
|
|
153
|
+
1. Create a direction workspace for the current session (minimum `style.css` + `notes.md`; HTML per chosen layout).
|
|
154
|
+
2. Each time the user changes a requirement/layout/component:
|
|
155
|
+
- Update HTML/CSS direction directly
|
|
156
|
+
- Record decision + rationale in `notes.md` (single source of truth for design intent)
|
|
146
157
|
|
|
147
|
-
**
|
|
158
|
+
**Required hook (multi-page only)**
|
|
148
159
|
|
|
149
|
-
|
|
160
|
+
When the `pages/` directory exists or any `pages/*.html` is added / renamed / removed:
|
|
150
161
|
|
|
151
|
-
-
|
|
152
|
-
-
|
|
153
|
-
-
|
|
162
|
+
- Update the **hub** `index.html` (nav / list of links to all remaining pages).
|
|
163
|
+
- Immediately update the **`## Pages inventory`** section in `notes.md` (table: Slug | File | Title | Purpose | Key sections | Nav to) — must match 100% of the current `pages/*.html` file set.
|
|
164
|
+
- Do not end a topic / do not consider the UI session “synced” if the inventory diverges from files on disk.
|
|
154
165
|
|
|
155
|
-
3.
|
|
156
|
-
-
|
|
157
|
-
-
|
|
158
|
-
-
|
|
159
|
-
4.
|
|
166
|
+
3. If the user sends references/components (including 21st.dev prompts/links), record clearly:
|
|
167
|
+
- reference source
|
|
168
|
+
- the UI area it applies to (page slug if multi-page)
|
|
169
|
+
- adjustments according to product objectives
|
|
170
|
+
4. Keep the prototype at a directional description level; do not force production-ready code at the brainstorm stage.
|
|
160
171
|
|
|
161
172
|
### Architect Design Mode (FEAT-011)
|
|
162
173
|
|
|
163
|
-
Brainstorm
|
|
174
|
+
Brainstorm system architecture with live HTML generation — a visual workspace for the user to review, edit, and present before running `/vp-crystallize`.
|
|
164
175
|
|
|
165
176
|
#### Activation
|
|
166
177
|
|
|
167
|
-
|
|
178
|
+
Activated when **any one** of the following conditions is met:
|
|
168
179
|
|
|
169
|
-
1. **
|
|
170
|
-
2. **Auto-activate heuristic** (
|
|
171
|
-
3. **
|
|
180
|
+
1. **Explicit flag**: user uses `/vp-brainstorm --architect`
|
|
181
|
+
2. **Auto-activate heuristic** (see below)
|
|
182
|
+
3. **Architecture topic + complexity threshold**: user selects "Architecture" topic in the brainstorm menu AND (service count ≥3 OR ≥1 tech stack suggestion is made)
|
|
172
183
|
|
|
173
|
-
**Auto-activate heuristic**:
|
|
174
|
-
- **Component/service mentions**:
|
|
175
|
-
- **Stack mentions**:
|
|
184
|
+
**Auto-activate heuristic**: during brainstorm, track:
|
|
185
|
+
- **Component/service mentions**: names matching the pattern `{capitalized} Service|API|Module|Layer|Server|Database` (e.g., "UserService", "Payment API", "Data Layer")
|
|
186
|
+
- **Stack mentions**: any keyword from the known stack list (React, Node.js, PostgreSQL, Redis, Kafka, AWS, Docker, etc.)
|
|
176
187
|
|
|
177
|
-
|
|
188
|
+
When **≥3 components** OR **≥1 stack suggestion** is mentioned → prompt:
|
|
178
189
|
|
|
179
190
|
```
|
|
180
|
-
🏗️
|
|
181
|
-
|
|
182
|
-
1.
|
|
183
|
-
2.
|
|
191
|
+
🏗️ I noticed you are designing an architecture with multiple components.
|
|
192
|
+
Activate Architect Design Mode so I can create an HTML visualization?
|
|
193
|
+
1. Yes — create workspace and generate initial HTML
|
|
194
|
+
2. No — continue text-only
|
|
184
195
|
```
|
|
185
196
|
|
|
186
|
-
- **Option 1 (Yes)**:
|
|
187
|
-
- **Option 2 (No)**:
|
|
197
|
+
- **Option 1 (Yes)**: create workspace (directory + files), generate initial HTML from content already discussed, continue in Architect Mode.
|
|
198
|
+
- **Option 2 (No)**: continue text-only brainstorm; heuristic will not prompt again in this session.
|
|
188
199
|
|
|
189
200
|
#### Workspace layout
|
|
190
201
|
|
|
191
202
|
```
|
|
192
203
|
.viepilot/architect/{session-id}/
|
|
193
|
-
index.html # Hub: sidebar nav + tabs →
|
|
204
|
+
index.html # Hub: sidebar nav + tabs → to all sections
|
|
194
205
|
architecture.html # System diagram (graph TD / C4Context) + component descriptions
|
|
195
206
|
data-flow.html # High-level service/event flows (sequenceDiagram / flowchart LR)
|
|
196
207
|
decisions.html # ADR log: Date | Decision | Options | Chosen | Rationale | Status
|
|
197
208
|
tech-stack.html # Layer-by-layer: frontend, backend, infra, data, DevOps
|
|
198
209
|
tech-notes.html # 3 columns: Assumptions | Risks | Open Questions
|
|
199
|
-
feature-map.html # Features
|
|
210
|
+
feature-map.html # Features with tags: layer, phase, priority, status
|
|
200
211
|
erd.html # Database ERD: entities, attributes, relationships (erDiagram) — ENH-027
|
|
201
212
|
user-use-cases.html # User Stories / Use Cases / Actors (flowchart TD) — ENH-028
|
|
202
213
|
sequence-diagram.html # Per-scenario sequences (sequenceDiagram) — ENH-029
|
|
203
214
|
deployment.html # Infra, environments, CI/CD pipeline — ENH-029
|
|
204
215
|
apis.html # Service API listing & design decisions — ENH-029
|
|
205
216
|
style.css # Shared: dark/light CSS vars, .updated highlight, Mermaid container, responsive nav
|
|
206
|
-
notes.md # Machine-readable YAML (
|
|
217
|
+
notes.md # Machine-readable YAML (see schema below)
|
|
207
218
|
```
|
|
208
219
|
|
|
209
|
-
**Mermaid.js** —
|
|
210
|
-
- `architecture.html` → `graph TD`
|
|
211
|
-
- `data-flow.html` → `sequenceDiagram`
|
|
212
|
-
- `feature-map.html` → `mindmap`
|
|
220
|
+
**Mermaid.js** — all diagrams use: `<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js">`
|
|
221
|
+
- `architecture.html` → `graph TD` or `C4Context`
|
|
222
|
+
- `data-flow.html` → `sequenceDiagram` or `flowchart LR`
|
|
223
|
+
- `feature-map.html` → `mindmap` or `quadrantChart`
|
|
213
224
|
- `erd.html` → `erDiagram` (entities, attributes, relationships)
|
|
214
225
|
- `user-use-cases.html` → `flowchart TD` (actors → use case bubbles)
|
|
215
226
|
- `sequence-diagram.html` → `sequenceDiagram` (per-scenario step-by-step)
|
|
@@ -227,34 +238,62 @@ Kích hoạt Architect Design Mode để tôi tạo HTML visualization không?
|
|
|
227
238
|
| `apis.html` | API endpoint design, HTTP methods, request/response contracts |
|
|
228
239
|
|
|
229
240
|
#### Sequence trigger keywords (ENH-029)
|
|
230
|
-
|
|
241
|
+
When the user mentions: `scenario`, `step by step`, `login flow`, `checkout flow`, `detailed interaction`, `sequence`, `interaction diagram` → update `sequence-diagram.html` + update `notes.md ## sequences` section.
|
|
231
242
|
|
|
232
243
|
#### Deployment trigger keywords (ENH-029)
|
|
233
|
-
|
|
244
|
+
When the user mentions: `deploy`, `deployment`, `infrastructure`, `infra`, `environment`, `staging`, `production`, `prod`, `AWS`, `GCP`, `Azure`, `Docker`, `Kubernetes`, `k8s`, `CI/CD`, `pipeline`, `server`, `hosting`, `cloud` → update `deployment.html` + update `notes.md ## deployment` section.
|
|
234
245
|
|
|
235
246
|
#### APIs trigger keywords (ENH-029)
|
|
236
|
-
|
|
247
|
+
When the user mentions: `endpoint`, `API`, `REST`, `GraphQL`, `gRPC`, `route`, `HTTP`, `POST`, `GET`, `PUT`, `DELETE`, `PATCH`, `request`, `response`, `payload`, `auth header` → update `apis.html` + update `notes.md ## apis` section.
|
|
237
248
|
|
|
238
249
|
#### ERD trigger keywords (ENH-027)
|
|
239
|
-
|
|
250
|
+
When the user mentions any keyword: `database`, `entity`, `table`, `schema`, `relation`, `relationship`, `foreign key`, `primary key`, `ERD`, `data model`, `normalization` → update `erd.html` + update `notes.md ## erd` section.
|
|
240
251
|
|
|
241
252
|
#### Use Case trigger keywords (ENH-028)
|
|
242
|
-
|
|
253
|
+
When the user mentions: `user story`, `use case`, `actor`, `persona`, `as a user`, `user flow`, `workflow`, `journey`, `role`, `permission` → update `user-use-cases.html` + update `notes.md ## use_cases` section.
|
|
243
254
|
|
|
244
255
|
#### Dialogue cadence
|
|
245
256
|
|
|
246
|
-
1.
|
|
247
|
-
2.
|
|
248
|
-
3. **`/review-arch`** command → ViePilot
|
|
257
|
+
1. After each **major decision** (tech stack, service boundary, data model) → update the related HTML section + update `notes.md`.
|
|
258
|
+
2. When the user **changes a decision** → **incremental update**: only edit the related section; keep all other sections unchanged. Add `data-updated="true"` attribute + class `.updated` CSS highlight (yellow left border + "updated" badge) to the changed element.
|
|
259
|
+
3. **`/review-arch`** command → ViePilot outputs a summary table of all `decisions` (from `notes.md`) + list of `open_questions` with status; ask the user to confirm before continuing.
|
|
249
260
|
|
|
250
261
|
#### Incremental update rule
|
|
251
262
|
|
|
252
|
-
|
|
253
|
-
-
|
|
254
|
-
- **
|
|
255
|
-
-
|
|
256
|
-
- Update `notes.md` YAML (`updated` date + entry
|
|
257
|
-
-
|
|
263
|
+
When a decision changes:
|
|
264
|
+
- Identify the **related HTML file** (e.g., tech stack change → only edit `tech-stack.html` + `architecture.html`).
|
|
265
|
+
- Do **not** regenerate the entire workspace.
|
|
266
|
+
- Add `data-updated="true"` to the changed `<section>` or `<tr>`.
|
|
267
|
+
- Update `notes.md` YAML (`updated` date + corresponding entry).
|
|
268
|
+
- Preserve `decisions.html` history — only add new rows or update the `status` field (do not delete history).
|
|
269
|
+
|
|
270
|
+
#### Architect Item Actions (ENH-033)
|
|
271
|
+
|
|
272
|
+
Each item in the Architect HTML workspace has a stable ID in the format `[ARCH:{page-slug}:{item-id}]`
|
|
273
|
+
(e.g., `[ARCH:decisions:D1]`, `[ARCH:erd:E2]`, `[ARCH:apis:A4]`).
|
|
274
|
+
|
|
275
|
+
Two buttons appear on hover next to each item in the HTML:
|
|
276
|
+
- **✅ Approve** — copies: `[ARCH:{slug}:{id}] APPROVE — "{title}" on {slug} page. No changes needed.`
|
|
277
|
+
- **✏️ Edit** — copies: `[ARCH:{slug}:{id}] EDIT — "{title}" on {slug} page. Current: "{excerpt}". What should I change?`
|
|
278
|
+
|
|
279
|
+
**When you receive an APPROVE prompt:**
|
|
280
|
+
- Confirm the item is accepted as-is.
|
|
281
|
+
- Do NOT touch any other item or page.
|
|
282
|
+
- Ask if the user wants to continue reviewing other items.
|
|
283
|
+
|
|
284
|
+
**When you receive an EDIT prompt:**
|
|
285
|
+
- Acknowledge the item by its full ID (`[ARCH:{slug}:{id}]`).
|
|
286
|
+
- State what the current content is.
|
|
287
|
+
- Ask the user what they want to change.
|
|
288
|
+
- Apply the change only to that specific item on that specific page.
|
|
289
|
+
|
|
290
|
+
**ISOLATION RULE — CRITICAL:**
|
|
291
|
+
Each action is **strictly scoped** to the named page and item.
|
|
292
|
+
|
|
293
|
+
- Approving `[ARCH:architecture:C2]` does **NOT** approve any item in `erd`, `apis`, `decisions`, or any other page.
|
|
294
|
+
- Editing `[ARCH:decisions:D1]` does **NOT** trigger updates to `architecture`, `erd`, or any other page unless the user explicitly asks for cross-page follow-up.
|
|
295
|
+
- **Never infer or cascade approval/edit across pages.** Each page is an independent artifact namespace.
|
|
296
|
+
- Cross-page impacts (e.g., "this decision affects the ERD") must come from a **separate, explicit** user prompt after the first action is complete.
|
|
258
297
|
|
|
259
298
|
#### notes.md YAML schema
|
|
260
299
|
|
|
@@ -333,47 +372,57 @@ design_decisions:
|
|
|
333
372
|
- decision: Authentication
|
|
334
373
|
choice: "{JWT / Session / OAuth2 / API Key}"
|
|
335
374
|
rationale: "{rationale}"
|
|
375
|
+
|
|
376
|
+
## architect_sync
|
|
377
|
+
- synced_at: "{ISO datetime}"
|
|
378
|
+
source_session: "{ui-direction session-id}"
|
|
379
|
+
trigger: "end-of-session | /sync-arch"
|
|
380
|
+
changes:
|
|
381
|
+
- page: "{slug}"
|
|
382
|
+
item_id: "{data-arch-id}"
|
|
383
|
+
action: "updated | added"
|
|
384
|
+
change: "{brief description, ≤80 chars}"
|
|
336
385
|
```
|
|
337
386
|
|
|
338
387
|
### Background UI Extraction (silent mode) — ENH-026
|
|
339
388
|
|
|
340
|
-
|
|
389
|
+
Runs **silently** in every brainstorm session (no `--ui` flag required). Does not interrupt the main conversation.
|
|
341
390
|
|
|
342
391
|
#### Signal keywords
|
|
343
|
-
|
|
392
|
+
When the assistant detects any keyword (case-insensitive, Vietnamese or English) in the user's message or session summary:
|
|
344
393
|
|
|
345
394
|
> `màu`, `màu sắc`, `color`, `layout`, `màn hình`, `screen`, `page`, `trang`, `button`, `nút`, `form`, `biểu mẫu`, `mobile`, `responsive`, `giao diện`, `UI`, `UX`, `design`, `dashboard`, `sidebar`, `header`, `footer`, `modal`, `popup`, `icon`, `theme`, `typography`, `font`, `spacing`, `grid`, `card`, `component`, `hero`, `banner`
|
|
346
395
|
|
|
347
396
|
#### Threshold & accumulation rule
|
|
348
|
-
-
|
|
349
|
-
-
|
|
350
|
-
- **Non-blocking**:
|
|
351
|
-
-
|
|
397
|
+
- **Count unique keyword occurrences** during the ongoing session.
|
|
398
|
+
- When **≥3 unique signal occurrences** are reached: begin **silent accumulation** — record UI ideas into a `ui_idea_buffer[]` in the session context.
|
|
399
|
+
- **Non-blocking**: does not interrupt the main conversation, does not ask for user confirmation immediately.
|
|
400
|
+
- Each buffer entry records: keyword trigger, utterance context (short summary ≤20 words).
|
|
352
401
|
|
|
353
|
-
#### Surface triggers (
|
|
354
|
-
|
|
355
|
-
- (a) **Topic
|
|
356
|
-
- (b) **User
|
|
357
|
-
- (c) **≥5 signals accumulated**
|
|
402
|
+
#### Surface triggers (when to ask the user)
|
|
403
|
+
Display a confirmation dialogue when any of the following conditions occur:
|
|
404
|
+
- (a) **Topic ends** — user types `/topic` to switch to a new topic or says "next"
|
|
405
|
+
- (b) **User types `/save` or `/review`**
|
|
406
|
+
- (c) **≥5 signals accumulated** in the buffer
|
|
358
407
|
|
|
359
408
|
#### Confirmation dialogue template
|
|
360
409
|
```
|
|
361
|
-
💡
|
|
410
|
+
💡 I detected some UI ideas in this session:
|
|
362
411
|
- {idea 1 extracted from buffer}
|
|
363
412
|
- {idea 2 extracted from buffer}
|
|
364
413
|
...
|
|
365
414
|
|
|
366
|
-
|
|
367
|
-
1.
|
|
368
|
-
2.
|
|
369
|
-
3.
|
|
415
|
+
What would you like to do?
|
|
416
|
+
1. Save to .viepilot/ui-direction/{session-id}/notes.md (background extraction)
|
|
417
|
+
2. Save + activate UI Direction Mode to generate HTML direction
|
|
418
|
+
3. Discard and continue brainstorming
|
|
370
419
|
```
|
|
371
420
|
|
|
372
|
-
**Option 1**:
|
|
421
|
+
**Option 1**: Write `## Background extracted ideas` to `.viepilot/ui-direction/{session-id}/notes.md` (create file/directory if not yet present). Clear buffer. Continue.
|
|
373
422
|
|
|
374
|
-
**Option 2**:
|
|
423
|
+
**Option 2**: Write to notes.md (same as Option 1) **+ fully trigger the `### UI Direction Mode` workflow** (create `index.html`, `style.css`). Clear buffer. Continue in UI Direction Mode.
|
|
375
424
|
|
|
376
|
-
**Option 3**:
|
|
425
|
+
**Option 3**: Keep buffer unchanged (do not clear, do not write). Continue brainstorm. Re-surface at the next trigger.
|
|
377
426
|
|
|
378
427
|
#### Auto-write path (Option 1 + 2)
|
|
379
428
|
```bash
|
|
@@ -385,66 +434,66 @@ mkdir -p .viepilot/ui-direction/{session-id}
|
|
|
385
434
|
|
|
386
435
|
### UI Direction — UX walkthrough & upgrade (FEAT-010)
|
|
387
436
|
|
|
388
|
-
|
|
437
|
+
When inside **`/vp-brainstorm --ui`** or a `.viepilot/ui-direction/{session-id}/` already exists for the current session, the user can invoke:
|
|
389
438
|
|
|
390
|
-
- **`/research-ui`** —
|
|
391
|
-
- **`/research ui`** — **alias**
|
|
439
|
+
- **`/research-ui`** — runs the full pipeline below
|
|
440
|
+
- **`/research ui`** — **alias** of `/research-ui` (space after `research`; does not conflict with `/research {free topic}`)
|
|
392
441
|
|
|
393
|
-
|
|
442
|
+
The user can include one line of context (e.g., product name **Trips**, persona, priority flow) — entered in the same message as the command.
|
|
394
443
|
|
|
395
|
-
|
|
444
|
+
Apply **the phases sequentially** (assistant does not skip a phase unless the user explicitly says “phase 1 only”):
|
|
396
445
|
|
|
397
|
-
#### Phase 1 —
|
|
446
|
+
#### Phase 1 — Simulate end user
|
|
398
447
|
|
|
399
|
-
1.
|
|
400
|
-
2.
|
|
401
|
-
3.
|
|
402
|
-
4.
|
|
403
|
-
5. **
|
|
404
|
-
- **
|
|
405
|
-
- **
|
|
406
|
-
- **
|
|
407
|
-
- **
|
|
408
|
-
- **Empty vs
|
|
409
|
-
- **Viewport**:
|
|
448
|
+
1. Role-play as the **end user** using the prototype (get app name / main screen from `notes.md`, HTML, or user prompt).
|
|
449
|
+
2. List **3–8 specific scenarios** (e.g., first app launch, completing the main task, edge case errors) — prioritize the correct page if multi-page (`pages/*.html`).
|
|
450
|
+
3. For each scenario: describe **behavior** (imagined reading/clicking on the current UI) → record **pain**: ambiguity, missing feedback, too many steps, mismatch with mental model, mobile/a11y concerns, etc.
|
|
451
|
+
4. Synthesize **Voice of pseudo-user** (bullets + severity **low / medium / high**).
|
|
452
|
+
5. **Content stress & layout overflow pass (content stress pass)** — *required in every `/research-ui` run*: after happy/edge behavior, simulate **boundary data** on each key screen/page (or the full hub if single-screen). Consider at minimum **3–6 of the following categories** (choose those relevant to product context; skip inapplicable ones but **note “N/A + reason”**):
|
|
453
|
+
- **Long copy**: headline, subtitle, CTA, input placeholder, tooltip, breadcrumb, long place/person names (Unicode), long emails/URLs.
|
|
454
|
+
- **Volume**: lists/grids with **many elements**, multi-column/row tables, stacked tags/badges, notification stacks, calendars with many events.
|
|
455
|
+
- **Numbers & formats**: very large/small monetary values, long units, time zones/locales (if the product supports them).
|
|
456
|
+
- **Error / validation states**: long error messages, multiple simultaneous errors, inline + banner.
|
|
457
|
+
- **Empty vs fully packed**: no data vs max items; skeleton vs flash of long content.
|
|
458
|
+
- **Viewport**: same stress on **narrow** (mobile) and **wide** (desktop) if the prototype targets multiple screen sizes.
|
|
410
459
|
|
|
411
|
-
**Stress recipes
|
|
460
|
+
**Stress recipes by archetype (ENH-020)** — after applying the checklist above, **lock in 1–2 archetypes** that match the product (from `notes.md` / HTML / user) and apply **at least two recipes** from each selected row (may be rephrased in the session language; **note the archetype** in Stress findings):
|
|
412
461
|
|
|
413
|
-
| Archetype |
|
|
414
|
-
|
|
415
|
-
| **Landing / marketing** | Hero **headline**
|
|
416
|
-
| **App shell / SaaS admin** | **
|
|
417
|
-
| **Form-heavy / wizard** | **
|
|
418
|
-
| **Content / reader** | **
|
|
419
|
-
| **Commerce / booking / marketplace** |
|
|
462
|
+
| Archetype | Stress priorities (suggested recipes) | Notes |
|
|
463
|
+
|-----------|---------------------------------------|-------|
|
|
464
|
+
| **Landing / marketing** | Hero **headline** very short vs very long; **pricing** 3–5 tiers + long feature list per tier; **FAQ** 10–20 items (accordion/stack); **logo / social proof** row of 8–15 logos + long names | Sticky CTA vs long content; section order when overflow |
|
|
465
|
+
| **App shell / SaaS admin** | **Table** many columns + many rows; **filter bar** chip + dropdown overflow; **sidebar** multi-level; **notification** stack / toast overlap | Dense vs comfortable state; frozen column |
|
|
466
|
+
| **Form-heavy / wizard** | Long **label + hint**; **multi-step** 5–7 steps + long breadcrumb; **errors** inline per field + global banner; expandable **optional fields** block | Tab order, submit disabled ambiguity |
|
|
467
|
+
| **Content / reader** | Very long **article**; wide **code block**; **TOC** 20–40 headings; **related** 8–15 cards | Max line length, sidenote, mobile reading |
|
|
468
|
+
| **Commerce / booking / marketplace** | Dense search results **grid**; **price** + long unit + discount; **date/time** + time zone + DST; **seat/room booking** + long availability text | Cart / summary on mobile |
|
|
420
469
|
|
|
421
|
-
Hybrid (
|
|
470
|
+
Hybrid (e.g., marketing + app): **merge recipes** from relevant rows; avoid repeating the same meaningless stress on two identical screens.
|
|
422
471
|
|
|
423
|
-
|
|
424
|
-
6.
|
|
472
|
+
For prototypes with only short sample content: **no requirement** to edit files immediately in Phase 1 — instead **describe assumptions** (“if the title is 120 characters…”) and how the UI would **overflow, ellipsis, scroll, overlap, wrap poorly**.
|
|
473
|
+
6. Also synthesize **Stress findings** (bullets: stress type → observation → severity **low/medium/high**) and merge into the Phase 1 summary for Phase 2.
|
|
425
474
|
|
|
426
475
|
#### Phase 2 — UX designer + research
|
|
427
476
|
|
|
428
|
-
1.
|
|
429
|
-
2. Map pain → **
|
|
430
|
-
3. **Web research**:
|
|
431
|
-
4.
|
|
477
|
+
1. Switch role: **UX/UI designer** receiving feedback from Phase 1 (**including Stress findings**).
|
|
478
|
+
2. Map pain → **design root cause** (short heuristic, missing/incorrect pattern); **prioritize** P0 / P1 / P2 — **prioritize P0** if content stress causes **information loss, mis-clicks, or unusability** (overflow covering CTA, truncated meaningful text, table overflow unreadable).
|
|
479
|
+
3. **Web research**: when benchmarking or industry-standard patterns are needed, run **1–3 queries** (search) → summarize source, takeaway, trade-off.
|
|
480
|
+
4. **Propose specific improvements** (UI components, copy, layout, flow) tied to file/page (`slug` if multi-page).
|
|
432
481
|
|
|
433
|
-
#### Phase 3 —
|
|
482
|
+
#### Phase 3 — Update artifacts
|
|
434
483
|
|
|
435
|
-
1.
|
|
436
|
-
2.
|
|
437
|
-
3. **Multi-page**:
|
|
484
|
+
1. Edit **`index.html`**, **`pages/*.html`**, **`style.css`** per P0 → P1 within the session scope (prototype direction, no forcing production code).
|
|
485
|
+
2. In **`notes.md`**, add or append a **`## UX walkthrough log`** section (one entry per command run): date/scenarios simulated, main pains, **Stress findings** (summary), research links (if any), **intent diff** (bullets), files changed. *Optional:* adjust HTML with **long placeholder/copy** or add a **demo row** to illustrate stress discussed (record in log).
|
|
486
|
+
3. **Multi-page**: after editing a page, keep **`## Pages inventory`** and the **hub** matching 100% of files in `pages/*` (hook FEAT-007).
|
|
438
487
|
|
|
439
|
-
**
|
|
488
|
+
**Relationship with `/research {topic}`**: the **free-form** command only needs a quick research and return to topic; **`/research-ui`** requires **3 phases** + **log entry** + **HTML/CSS edits when proposals are reasonable**.
|
|
440
489
|
|
|
441
|
-
|
|
490
|
+
User reference: `docs/user/features/ui-direction.md`.
|
|
442
491
|
|
|
443
|
-
###
|
|
444
|
-
-
|
|
492
|
+
### End of each topic
|
|
493
|
+
- Summarize decisions
|
|
445
494
|
- List action items
|
|
446
495
|
- Note open questions
|
|
447
|
-
-
|
|
496
|
+
- If the topic adds/changes a capability: update **`## Phases`** in the session draft (or remind the user to `/save`) with the appropriate phase
|
|
448
497
|
</step>
|
|
449
498
|
|
|
450
499
|
<step name="project_meta_intake">
|
|
@@ -454,51 +503,51 @@ Normative contract: **`docs/dev/global-profiles.md`** (`~/.viepilot/profiles/`,
|
|
|
454
503
|
|
|
455
504
|
### 5.1 When this step runs
|
|
456
505
|
|
|
457
|
-
|
|
506
|
+
Runs **before** saving the session in **`Completed`** status or when the user types **`/end`**, **if**:
|
|
458
507
|
|
|
459
|
-
1. **Scope locked**: `## Phases`
|
|
460
|
-
2. **Binding
|
|
508
|
+
1. **Scope locked**: `## Phases` in the session draft already contains real content (all features assigned to a phase) **or** the user has just verbally confirmed scope is finalized.
|
|
509
|
+
2. **Binding missing**: `.viepilot/META.md` does not exist **or** the frontmatter lacks a valid `viepilot_profile_id` (slug `kebab-case` per contract).
|
|
461
510
|
|
|
462
|
-
**
|
|
511
|
+
**Skip by default** (skip intake) when `.viepilot/META.md` already has a valid `viepilot_profile_id` — only ask quickly: *”Keep profile `{id}`? Change profile?”*; if kept → proceed to Save step.
|
|
463
512
|
|
|
464
|
-
### 5.2
|
|
513
|
+
### 5.2 Prepare registry
|
|
465
514
|
|
|
466
|
-
1. `mkdir -p "$HOME/.viepilot/profiles"`
|
|
467
|
-
2.
|
|
515
|
+
1. `mkdir -p "$HOME/.viepilot/profiles"` if needed.
|
|
516
|
+
2. Read `~/.viepilot/profile-map.md` if present to list existing profiles (profile_id, display_name, org_tag).
|
|
468
517
|
|
|
469
|
-
### 5.3 Disambiguation (
|
|
518
|
+
### 5.3 Disambiguation (multiple profiles / multiple orgs)
|
|
470
519
|
|
|
471
|
-
-
|
|
520
|
+
- If the brainstorm reveals **multiple orgs/clients** or **≥2 rows in profile-map** match the suggestion (same `org_tag` or tag): **require** the user to select **one** `profile_id` **or** choose **Create new profile** (new slug, not yet existing).
|
|
472
521
|
|
|
473
|
-
### 5.4 Q&A
|
|
522
|
+
### 5.4 Sequential Q&A (one question per turn)
|
|
474
523
|
|
|
475
|
-
|
|
524
|
+
For each question:
|
|
476
525
|
|
|
477
|
-
1.
|
|
478
|
-
2. User
|
|
479
|
-
3.
|
|
526
|
+
1. Provide a short **Proposal** (1–2 sentences) inferred from the session + phase plan.
|
|
527
|
+
2. User responds **Accept proposal** / **Edit** (record user's version).
|
|
528
|
+
3. Move to the next question.
|
|
480
529
|
|
|
481
|
-
**
|
|
530
|
+
**At minimum** these must be clarified before writing the file (matches body sections in the global contract):
|
|
482
531
|
|
|
483
|
-
|
|
|
484
|
-
|
|
485
|
-
| 1 |
|
|
486
|
-
| 2 | `org_tag`
|
|
487
|
-
| 3 | Branding /
|
|
488
|
-
| 4 |
|
|
489
|
-
| 5 |
|
|
532
|
+
| Order | Question (suggested) | Maps to |
|
|
533
|
+
|-------|----------------------|---------|
|
|
534
|
+
| 1 | Display name for org/client or “personal”? | `display_name` |
|
|
535
|
+
| 2 | Short `org_tag` (e.g., `acme`, `personal`)? | `org_tag` |
|
|
536
|
+
| 3 | Branding / voice (audience, tone)? | body `## Branding & voice` |
|
|
537
|
+
| 4 | Public legal / attribution (if any)? | body `## Legal & attribution` |
|
|
538
|
+
| 5 | Public website (optional)? | frontmatter `website` |
|
|
490
539
|
|
|
491
|
-
|
|
540
|
+
Then: finalize **`profile_id`** = slug filename (`kebab-case`).
|
|
492
541
|
|
|
493
|
-
### 5.5
|
|
542
|
+
### 5.5 Write artifacts (machine + project)
|
|
494
543
|
|
|
495
|
-
1. **`~/.viepilot/profiles/<slug>.md`**: YAML frontmatter
|
|
496
|
-
2. **`~/.viepilot/profile-map.md`**:
|
|
497
|
-
3. **`.viepilot/META.md`**:
|
|
544
|
+
1. **`~/.viepilot/profiles/<slug>.md`**: YAML frontmatter with all required keys (`profile_id`, `display_name`, `org_tag`, `tags`, `last_updated`) + body sections collected. Do **not** write secrets.
|
|
545
|
+
2. **`~/.viepilot/profile-map.md`**: add or update a table row (columns per contract); update `last_used` = current date.
|
|
546
|
+
3. **`.viepilot/META.md`**: create/update from `templates/project/VIEPILOT-META.md` with `viepilot_profile_id: <slug>`.
|
|
498
547
|
|
|
499
|
-
### 5.6
|
|
548
|
+
### 5.6 Record in session file
|
|
500
549
|
|
|
501
|
-
|
|
550
|
+
In the draft / session file, add section:
|
|
502
551
|
|
|
503
552
|
```markdown
|
|
504
553
|
## Project meta intake (FEAT-009)
|
|
@@ -508,17 +557,17 @@ Trong bản nháp / file session, thêm section:
|
|
|
508
557
|
- **binding**: .viepilot/META.md
|
|
509
558
|
```
|
|
510
559
|
|
|
511
|
-
|
|
560
|
+
If skipped (rare): must have a **`## Meta intake waiver`** in the same session file with the **reason** provided by the user.
|
|
512
561
|
|
|
513
|
-
### 5.7
|
|
562
|
+
### 5.7 Continue
|
|
514
563
|
|
|
515
|
-
|
|
564
|
+
After intake is **completed** or a **valid skip** (META already has profile) → proceed to **step 6 — Save Session**.
|
|
516
565
|
</step>
|
|
517
566
|
|
|
518
567
|
<step name="save_session">
|
|
519
568
|
## 6. Save Session
|
|
520
569
|
|
|
521
|
-
|
|
570
|
+
Create/update file: `docs/brainstorm/session-{YYYY-MM-DD}.md`
|
|
522
571
|
|
|
523
572
|
```markdown
|
|
524
573
|
# Brainstorm Session - {YYYY-MM-DD}
|
|
@@ -536,7 +585,7 @@ Tạo/cập nhật file: `docs/brainstorm/session-{YYYY-MM-DD}.md`
|
|
|
536
585
|
### Phase 2
|
|
537
586
|
- {Feature / capability}
|
|
538
587
|
|
|
539
|
-
### Phase 3 (
|
|
588
|
+
### Phase 3 (and beyond)
|
|
540
589
|
- {Feature / capability}
|
|
541
590
|
|
|
542
591
|
## Project meta intake (FEAT-009)
|
|
@@ -546,9 +595,9 @@ Tạo/cập nhật file: `docs/brainstorm/session-{YYYY-MM-DD}.md`
|
|
|
546
595
|
- **profile_path**:
|
|
547
596
|
- **binding** (.viepilot/META.md):
|
|
548
597
|
|
|
549
|
-
_(
|
|
598
|
+
_(Fill after step 5 — Project meta intake; see `docs/dev/global-profiles.md`.)_
|
|
550
599
|
|
|
551
|
-
<!--
|
|
600
|
+
<!-- If skipped: ## Meta intake waiver + reason -->
|
|
552
601
|
|
|
553
602
|
## Architecture diagram applicability inputs
|
|
554
603
|
|
|
@@ -595,15 +644,15 @@ _(Điền sau bước 5 — Project meta intake; xem `docs/dev/global-profiles.m
|
|
|
595
644
|
- Session id: {session-id}
|
|
596
645
|
- Layout: legacy (single `index.html`) | multi-page (`pages/*.html` + hub `index.html`)
|
|
597
646
|
- Files:
|
|
598
|
-
- `.viepilot/ui-direction/{session-id}/index.html` (hub
|
|
647
|
+
- `.viepilot/ui-direction/{session-id}/index.html` (hub or single-screen)
|
|
599
648
|
- `.viepilot/ui-direction/{session-id}/style.css`
|
|
600
649
|
- `.viepilot/ui-direction/{session-id}/notes.md` (must include `## Pages inventory` when `pages/` exists)
|
|
601
650
|
- `.viepilot/ui-direction/{session-id}/pages/*.html` (when multi-page)
|
|
602
651
|
- Preview focus:
|
|
603
652
|
- {layout/flow summary; list each page slug if multi-page}
|
|
604
653
|
|
|
605
|
-
**UX walkthrough log** (optional; FEAT-010 + ENH-019 + ENH-020 —
|
|
606
|
-
- {YYYY-MM-DD}: scenarios exercised → top pains → **Stress findings** (
|
|
654
|
+
**UX walkthrough log** (optional; FEAT-010 + ENH-019 + ENH-020 — when `/research-ui` has been run):
|
|
655
|
+
- {YYYY-MM-DD}: scenarios exercised → top pains → **Stress findings** (summary) → research links → HTML/CSS edits summary
|
|
607
656
|
|
|
608
657
|
---
|
|
609
658
|
|
|
@@ -632,6 +681,129 @@ git push
|
|
|
632
681
|
```
|
|
633
682
|
</step>
|
|
634
683
|
|
|
684
|
+
<step name="architect_delta_sync">
|
|
685
|
+
## 6B. Architect Delta Sync (ENH-034)
|
|
686
|
+
|
|
687
|
+
Bridges the gap between UI Direction Mode and the Architect HTML workspace.
|
|
688
|
+
When a UI brainstorm session surfaces architect-relevant gaps or changes, those
|
|
689
|
+
deltas are parsed and written back to the relevant architect HTML template files.
|
|
690
|
+
|
|
691
|
+
### Trigger conditions
|
|
692
|
+
|
|
693
|
+
Runs when **either** condition is met:
|
|
694
|
+
|
|
695
|
+
1. **End of UI session** — `.viepilot/ui-direction/{session-id}/` exists for the current
|
|
696
|
+
session AND the session contains ≥1 architect keyword hit detected during UI discussion
|
|
697
|
+
(see keyword lists below).
|
|
698
|
+
2. **Manual command** — user types `/sync-arch` at any point in a session.
|
|
699
|
+
|
|
700
|
+
> **Automatic mode (FEAT-012):** If the brainstorm staleness hook is installed
|
|
701
|
+
> (`vp-tools hooks install`), stale architect items are flagged automatically after
|
|
702
|
+
> **each AI response** — no need to type `/sync-arch`. The hook marks items
|
|
703
|
+
> `data-arch-stale="true"` (amber badge) without rewriting content. Install once per machine.
|
|
704
|
+
> See `docs/user/features/hooks.md` for setup.
|
|
705
|
+
|
|
706
|
+
When neither condition is met: skip silently.
|
|
707
|
+
When `/sync-arch` is used explicitly and no gaps are found: output
|
|
708
|
+
`✓ No architect gaps detected in this session.`
|
|
709
|
+
|
|
710
|
+
### Step 1: Locate architect session
|
|
711
|
+
|
|
712
|
+
```bash
|
|
713
|
+
ls .viepilot/architect/ 2>/dev/null
|
|
714
|
+
```
|
|
715
|
+
|
|
716
|
+
- Find `.viepilot/architect/{session-id}/` matching the current session context
|
|
717
|
+
(same date, same project name, or most recent).
|
|
718
|
+
- If **no architect workspace exists**: skip with message:
|
|
719
|
+
`⚠ No architect workspace found. Run /vp-brainstorm --architect first to create one.`
|
|
720
|
+
|
|
721
|
+
### Step 2: Gap detection — scan session for architect keywords by page
|
|
722
|
+
|
|
723
|
+
Use the **existing trigger keyword lists** from Architect Design Mode (defined above) to
|
|
724
|
+
identify which architect pages are affected:
|
|
725
|
+
|
|
726
|
+
| Page | Keywords (excerpt) |
|
|
727
|
+
|------|--------------------|
|
|
728
|
+
| `architecture.html` | service, component, module, layer, boundary, system, integration, C4 |
|
|
729
|
+
| `erd.html` | database, entity, table, schema, relation, foreign key, ERD, data model |
|
|
730
|
+
| `apis.html` | endpoint, API, REST, route, HTTP, POST, GET, PUT, DELETE, request, response |
|
|
731
|
+
| `deployment.html` | deploy, infrastructure, environment, staging, production, CI/CD, pipeline |
|
|
732
|
+
| `data-flow.html` | data flow, event flow, queue, webhook, async, pub/sub |
|
|
733
|
+
| `user-use-cases.html` | user story, use case, actor, persona, as a user, user flow, journey |
|
|
734
|
+
| `sequence-diagram.html` | sequence, step by step, login flow, checkout flow, interaction |
|
|
735
|
+
|
|
736
|
+
For each page where **≥1 keyword is found in the UI brainstorm session output**:
|
|
737
|
+
- Mark as **affected**.
|
|
738
|
+
- Extract the relevant sentences/paragraphs that describe the gap or change.
|
|
739
|
+
|
|
740
|
+
### Step 3: Update HTML for each affected page
|
|
741
|
+
|
|
742
|
+
For each affected page:
|
|
743
|
+
|
|
744
|
+
1. **Read** `.viepilot/architect/{session-id}/{page}.html`
|
|
745
|
+
2. **Identify the target element(s)**:
|
|
746
|
+
- Match the gap context to the nearest `<tr data-arch-id="...">` row or
|
|
747
|
+
`<div class="card" data-arch-id="...">` by comparing gap keywords to the
|
|
748
|
+
item's `data-arch-title` or first cell content.
|
|
749
|
+
- If no exact match: add a **new row** to the relevant `<tbody>` (the most
|
|
750
|
+
appropriate table for the content type) with the gap information.
|
|
751
|
+
3. **Update element content**:
|
|
752
|
+
- For existing rows: update the relevant `<td>` cell with the new/corrected
|
|
753
|
+
information from the brainstorm.
|
|
754
|
+
- For new rows: create `<tr data-arch-id="{PAGE-PREFIX-NEW{n}}"
|
|
755
|
+
data-updated="true" class="updated">` with content from the brainstorm.
|
|
756
|
+
4. **Mark as updated**: add `data-updated="true"` and `class="updated"` to the
|
|
757
|
+
changed element (uses existing `.updated` CSS — yellow left border + badge).
|
|
758
|
+
5. **Add sync note**: add `data-arch-sync-note="{brief reason, ≤60 chars}"` to the
|
|
759
|
+
changed element recording why it was updated.
|
|
760
|
+
|
|
761
|
+
**Do NOT**:
|
|
762
|
+
- Change elements that were NOT identified as gaps.
|
|
763
|
+
- Cascade updates across pages (isolation rule — ENH-033 applies here too).
|
|
764
|
+
- Remove existing data — only update or add.
|
|
765
|
+
|
|
766
|
+
### Step 4: Record delta in notes.md
|
|
767
|
+
|
|
768
|
+
Append under `## architect_sync` section in `.viepilot/architect/{session-id}/notes.md`:
|
|
769
|
+
|
|
770
|
+
```yaml
|
|
771
|
+
## architect_sync
|
|
772
|
+
- synced_at: {ISO datetime}
|
|
773
|
+
source_session: {ui-direction session-id}
|
|
774
|
+
trigger: {end-of-session | /sync-arch}
|
|
775
|
+
changes:
|
|
776
|
+
- page: {slug}
|
|
777
|
+
item_id: {data-arch-id}
|
|
778
|
+
action: {updated | added}
|
|
779
|
+
change: "{brief description of what was updated, ≤80 chars}"
|
|
780
|
+
- page: {slug}
|
|
781
|
+
item_id: {data-arch-id}
|
|
782
|
+
action: updated
|
|
783
|
+
change: "{description}"
|
|
784
|
+
```
|
|
785
|
+
|
|
786
|
+
### Step 5: Output sync report
|
|
787
|
+
|
|
788
|
+
```
|
|
789
|
+
🔄 Architect Sync complete
|
|
790
|
+
|
|
791
|
+
Updated {N} items across {M} pages:
|
|
792
|
+
{page} {item-id} [{action}] — {change}
|
|
793
|
+
...
|
|
794
|
+
|
|
795
|
+
Items marked with data-updated="true" in architect workspace.
|
|
796
|
+
Open .viepilot/architect/{session-id}/ to review changes.
|
|
797
|
+
```
|
|
798
|
+
|
|
799
|
+
If only 1 item changed: single-line summary is sufficient.
|
|
800
|
+
|
|
801
|
+
### notes.md schema update
|
|
802
|
+
|
|
803
|
+
The `## architect_sync` section is **appended** (not replaced) on each sync run.
|
|
804
|
+
Multiple sync entries can exist — each with its own `synced_at` timestamp.
|
|
805
|
+
</step>
|
|
806
|
+
|
|
635
807
|
<step name="suggest_next">
|
|
636
808
|
## 7. Suggest Next Action
|
|
637
809
|
|
|
@@ -654,30 +826,34 @@ This will transform your brainstorm into:
|
|
|
654
826
|
</process>
|
|
655
827
|
|
|
656
828
|
<commands>
|
|
657
|
-
User
|
|
658
|
-
|
|
659
|
-
- `/topic {name}` -
|
|
660
|
-
- `/summary` -
|
|
661
|
-
- `/save` -
|
|
662
|
-
- `/end` -
|
|
663
|
-
- `/questions` -
|
|
664
|
-
- `/research {topic}` -
|
|
665
|
-
- `/research-ui` — UX walkthrough:
|
|
666
|
-
- `/research ui` — alias
|
|
667
|
-
- `/review-arch` — Architect Mode: output
|
|
829
|
+
User can use the following commands during a brainstorm session:
|
|
830
|
+
|
|
831
|
+
- `/topic {name}` - Switch to a new topic
|
|
832
|
+
- `/summary` - View current session summary
|
|
833
|
+
- `/save` - Save progress immediately
|
|
834
|
+
- `/end` - End and save the session (after **step 5 — Project meta intake** when binding is missing; see workflow)
|
|
835
|
+
- `/questions` - View list of open questions
|
|
836
|
+
- `/research {topic}` - Quick research inline in the session and return to current topic
|
|
837
|
+
- `/research-ui` — UX walkthrough: simulate user → designer + research → update UI direction + log (`notes.md`) — only when a UI session exists (FEAT-010)
|
|
838
|
+
- `/research ui` — alias of `/research-ui`
|
|
839
|
+
- `/review-arch` — Architect Mode: output summary table of decisions + open_questions from `notes.md`, confirm before continuing (FEAT-011)
|
|
840
|
+
- `/sync-arch` — Architect Delta Sync (ENH-034): manually trigger architect HTML sync from current UI brainstorm session; scans session for architect gaps → updates relevant architect workspace pages
|
|
841
|
+
- `/hooks-install` — Install the brainstorm staleness hook (FEAT-012): runs `vp-tools hooks install`; one-time setup per machine; auto-marks stale architect items after each AI response
|
|
668
842
|
</commands>
|
|
669
843
|
|
|
670
844
|
<success_criteria>
|
|
671
|
-
- [ ] Session file created
|
|
672
|
-
- [ ] `## Phases` present
|
|
673
|
-
- [ ] Decisions
|
|
845
|
+
- [ ] Session file created with all required sections
|
|
846
|
+
- [ ] `## Phases` present with at least Phase 1 containing real content
|
|
847
|
+
- [ ] Decisions include rationale
|
|
674
848
|
- [ ] Open questions tracked
|
|
675
849
|
- [ ] Action items captured
|
|
676
850
|
- [ ] Landing page topics trigger layout follow-up questions
|
|
677
|
-
- [ ] 21st.dev references
|
|
678
|
-
- [ ] Research
|
|
679
|
-
- [ ] **FEAT-010 + ENH-019 + ENH-020**:
|
|
851
|
+
- [ ] 21st.dev references used when discussing landing pages
|
|
852
|
+
- [ ] Research can be run inline during the brainstorm session when the user requests it
|
|
853
|
+
- [ ] **FEAT-010 + ENH-019 + ENH-020**: In UI Direction, `/research-ui` (or `/research ui`) runs all 3 phases, including **content stress pass** + **archetype stress recipes** + **`## UX walkthrough log`** (Stress findings) when editing prototype
|
|
680
854
|
- [ ] Git committed
|
|
681
|
-
- [ ] **FEAT-009**:
|
|
682
|
-
- [ ] **`## Project meta intake (FEAT-009)`**
|
|
855
|
+
- [ ] **FEAT-009**: If binding is missing and scope is locked — **Project meta intake** (step 5) has been run or a **`## Meta intake waiver`** with reason exists before Completed
|
|
856
|
+
- [ ] **`## Project meta intake (FEAT-009)`** in session: `status` + `profile_id` when completed (or waiver if skipped)
|
|
857
|
+
- [ ] **ENH-034**: If UI session surfaces architect gaps → `architect_delta_sync` step runs; architect HTML updated + `## architect_sync` appended to notes.md
|
|
858
|
+
- [ ] **FEAT-012**: If brainstorm staleness hook installed → stale architect items auto-flagged after each AI response (amber badge); `/hooks-install` sets this up once per machine
|
|
683
859
|
</success_criteria>
|