wdi-method 0.3.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/LICENSE +21 -0
- package/README.md +203 -0
- package/bin/wdi-method.js +906 -0
- package/kit/.constitution/README.md +66 -0
- package/kit/.constitution/codebase/brownfield-guide.md +18 -0
- package/kit/.constitution/codebase/conventions-guide.md +18 -0
- package/kit/.constitution/codebase/stack-guide.md +18 -0
- package/kit/.constitution/constitution.md +135 -0
- package/kit/.constitution/document/architecture-guide.md +209 -0
- package/kit/.constitution/document/bmad-guide.md +151 -0
- package/kit/.constitution/document/bmad-skill-register.md +71 -0
- package/kit/.constitution/document/brief-guide.md +94 -0
- package/kit/.constitution/document/corpus-guide.md +341 -0
- package/kit/.constitution/document/decision-guide.md +134 -0
- package/kit/.constitution/document/delivery-flow-guide.md +338 -0
- package/kit/.constitution/document/prd-guide.md +202 -0
- package/kit/.constitution/document/sdd-guide.md +206 -0
- package/kit/.constitution/document/srs-guide.md +147 -0
- package/kit/.constitution/document/templates/addendum.md +71 -0
- package/kit/.constitution/document/templates/architecture-spine.md +100 -0
- package/kit/.constitution/document/templates/brief.md +110 -0
- package/kit/.constitution/document/templates/c4.md +77 -0
- package/kit/.constitution/document/templates/contract.md +52 -0
- package/kit/.constitution/document/templates/cross-cutting.md +80 -0
- package/kit/.constitution/document/templates/decision.md +64 -0
- package/kit/.constitution/document/templates/design-system.md +67 -0
- package/kit/.constitution/document/templates/flow.md +51 -0
- package/kit/.constitution/document/templates/integration.md +69 -0
- package/kit/.constitution/document/templates/inventory.md +69 -0
- package/kit/.constitution/document/templates/lc.md +47 -0
- package/kit/.constitution/document/templates/lifecycle.md +52 -0
- package/kit/.constitution/document/templates/meeting.md +47 -0
- package/kit/.constitution/document/templates/model.md +55 -0
- package/kit/.constitution/document/templates/oq.md +45 -0
- package/kit/.constitution/document/templates/prd.md +226 -0
- package/kit/.constitution/document/templates/questions.md +75 -0
- package/kit/.constitution/document/templates/rtr.md +61 -0
- package/kit/.constitution/document/templates/rules.md +47 -0
- package/kit/.constitution/document/templates/scn.md +40 -0
- package/kit/.constitution/document/templates/sdd.md +146 -0
- package/kit/.constitution/document/templates/srs.md +149 -0
- package/kit/.constitution/document/templates/structure-codebase.md +129 -0
- package/kit/.constitution/document/templates/structure-document.md +90 -0
- package/kit/.constitution/document/templates/uc.md +69 -0
- package/kit/.constitution/document/templates/ux.md +77 -0
- package/kit/.constitution/document/ux-guide.md +99 -0
- package/kit/.constitution/language-guide.md +69 -0
- package/kit/.constitution/method/README.md +169 -0
- package/kit/.constitution/method/artifact-map.md +155 -0
- package/kit/.constitution/method/portability.md +91 -0
- package/kit/.constitution/method/rationale.md +246 -0
- package/kit/.constitution/method-glossary.md +169 -0
- package/kit/.constitution/project/README.md +68 -0
- package/kit/.constitution/repo-guide.md +97 -0
- package/kit/.constitution/scripts/inventory.py +527 -0
- package/kit/.constitution/scripts/timeline.py +665 -0
- package/kit/.constitution/scripts/validate.py +1579 -0
- package/kit/.constitution/structure-guide.md +202 -0
- package/kit/assets/bmad-custom/bmad-advanced-elicitation.toml +15 -0
- package/kit/assets/bmad-custom/bmad-architecture.toml +31 -0
- package/kit/assets/bmad-custom/bmad-build-auto.toml +10 -0
- package/kit/assets/bmad-custom/bmad-build.toml +52 -0
- package/kit/assets/bmad-custom/bmad-code-review.toml +12 -0
- package/kit/assets/bmad-custom/bmad-correct-course.toml +27 -0
- package/kit/assets/bmad-custom/bmad-deep-recon.toml +11 -0
- package/kit/assets/bmad-custom/bmad-prd.toml +42 -0
- package/kit/assets/bmad-custom/bmad-product-brief.toml +34 -0
- package/kit/assets/bmad-custom/bmad-retrospective.toml +9 -0
- package/kit/assets/bmad-custom/bmad-spec.toml +15 -0
- package/kit/assets/bmad-custom/bmad-ux.toml +19 -0
- package/kit/assets/bmad-custom/config.toml +6 -0
- package/kit/skills/wdi-blueprint/SKILL.md +203 -0
- package/kit/skills/wdi-build/SKILL.md +244 -0
- package/kit/skills/wdi-component/SKILL.md +172 -0
- package/kit/skills/wdi-decision/.gitkeep +0 -0
- package/kit/skills/wdi-decision/SKILL.md +183 -0
- package/kit/skills/wdi-help/.gitkeep +0 -0
- package/kit/skills/wdi-help/SKILL.md +98 -0
- package/kit/skills/wdi-init/SKILL.md +149 -0
- package/kit/skills/wdi-log/SKILL.md +107 -0
- package/kit/skills/wdi-problem/SKILL.md +90 -0
- package/kit/skills/wdi-product/SKILL.md +127 -0
- package/kit/skills/wdi-question/.gitkeep +0 -0
- package/kit/skills/wdi-question/SKILL.md +88 -0
- package/kit/skills/wdi-reconcile/.gitkeep +0 -0
- package/kit/skills/wdi-reconcile/SKILL.md +146 -0
- package/kit/skills/wdi-report/SKILL.md +205 -0
- package/kit/skills/wdi-review/SKILL.md +118 -0
- package/kit/skills/wdi-systematic-debugging/SKILL.md +193 -0
- package/kit/skills/wdi-systematic-debugging/references/condition-based-waiting.md +115 -0
- package/kit/skills/wdi-systematic-debugging/references/defense-in-depth.md +122 -0
- package/kit/skills/wdi-systematic-debugging/references/find-polluter.sh +72 -0
- package/kit/skills/wdi-systematic-debugging/references/root-cause-tracing.md +169 -0
- package/kit/skills/wdi-ux/SKILL.md +145 -0
- package/kit-overlay/AGENTS.md +196 -0
- package/kit-overlay/README.md +66 -0
- package/kit-overlay/constitution.md +135 -0
- package/kit-overlay/portability.md +91 -0
- package/kit-overlay/repo-guide.md +97 -0
- package/lib/agents-block.mjs +52 -0
- package/lib/identity.mjs +65 -0
- package/package.json +37 -0
- package/scaffold/.control/decisions/.gitkeep +0 -0
- package/scaffold/.control/generated/.gitkeep +2 -0
- package/scaffold/.control/meetings/.gitkeep +0 -0
- package/scaffold/.control/memlog/.gitkeep +0 -0
- package/scaffold/.control/product-glossary.md +21 -0
- package/scaffold/.control/project-non-technical-log.md +23 -0
- package/scaffold/.control/questions/answered.md +11 -0
- package/scaffold/.control/questions/assumptions.md +15 -0
- package/scaffold/.control/questions/blocking.md +21 -0
- package/scaffold/.control/questions/external.md +11 -0
- package/scaffold/.control/registry/components.yaml +21 -0
- package/scaffold/.control/registry/decisions.yaml +6 -0
- package/scaffold/.control/registry/defects.yaml +3 -0
- package/scaffold/.control/registry/index.yaml +46 -0
- package/scaffold/.control/registry/requirements.yaml +15 -0
- package/scaffold/.control/registry/risks.yaml +5 -0
- package/scaffold/.control/registry/usecases.yaml +6 -0
- package/scaffold/.control/registry/waves.yaml +5 -0
- package/scaffold/.control/structure-codebase.md +19 -0
- package/scaffold/.control/structure-document.md +25 -0
|
@@ -0,0 +1,169 @@
|
|
|
1
|
+
# Root Cause Tracing
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
Bugs often manifest deep in the call stack (git init in wrong directory, file created in wrong location, database opened with wrong path). Your instinct is to fix where the error appears, but that's treating a symptom.
|
|
6
|
+
|
|
7
|
+
**Core principle:** Trace backward through the call chain until you find the original trigger, then fix at the source.
|
|
8
|
+
|
|
9
|
+
## When to Use
|
|
10
|
+
|
|
11
|
+
```dot
|
|
12
|
+
digraph when_to_use {
|
|
13
|
+
"Bug appears deep in stack?" [shape=diamond];
|
|
14
|
+
"Can trace backwards?" [shape=diamond];
|
|
15
|
+
"Fix at symptom point" [shape=box];
|
|
16
|
+
"Trace to original trigger" [shape=box];
|
|
17
|
+
"BETTER: Also add defense-in-depth" [shape=box];
|
|
18
|
+
|
|
19
|
+
"Bug appears deep in stack?" -> "Can trace backwards?" [label="yes"];
|
|
20
|
+
"Can trace backwards?" -> "Trace to original trigger" [label="yes"];
|
|
21
|
+
"Can trace backwards?" -> "Fix at symptom point" [label="no - dead end"];
|
|
22
|
+
"Trace to original trigger" -> "BETTER: Also add defense-in-depth";
|
|
23
|
+
}
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
**Use when:**
|
|
27
|
+
- Error happens deep in execution (not at entry point)
|
|
28
|
+
- Stack trace shows long call chain
|
|
29
|
+
- Unclear where invalid data originated
|
|
30
|
+
- Need to find which test/code triggers the problem
|
|
31
|
+
|
|
32
|
+
## The Tracing Process
|
|
33
|
+
|
|
34
|
+
### 1. Observe the Symptom
|
|
35
|
+
```
|
|
36
|
+
Error: git init failed in ~/project/packages/core
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
### 2. Find Immediate Cause
|
|
40
|
+
**What code directly causes this?**
|
|
41
|
+
```typescript
|
|
42
|
+
await execFileAsync('git', ['init'], { cwd: projectDir });
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
### 3. Ask: What Called This?
|
|
46
|
+
```typescript
|
|
47
|
+
WorktreeManager.createSessionWorktree(projectDir, sessionId)
|
|
48
|
+
→ called by Session.initializeWorkspace()
|
|
49
|
+
→ called by Session.create()
|
|
50
|
+
→ called by test at Project.create()
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
### 4. Keep Tracing Up
|
|
54
|
+
**What value was passed?**
|
|
55
|
+
- `projectDir = ''` (empty string!)
|
|
56
|
+
- Empty string as `cwd` resolves to `process.cwd()`
|
|
57
|
+
- That's the source code directory!
|
|
58
|
+
|
|
59
|
+
### 5. Find Original Trigger
|
|
60
|
+
**Where did empty string come from?**
|
|
61
|
+
```typescript
|
|
62
|
+
const context = setupCoreTest(); // Returns { tempDir: '' }
|
|
63
|
+
Project.create('name', context.tempDir); // Accessed before beforeEach!
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## Adding Stack Traces
|
|
67
|
+
|
|
68
|
+
When you can't trace manually, add instrumentation:
|
|
69
|
+
|
|
70
|
+
```typescript
|
|
71
|
+
// Before the problematic operation
|
|
72
|
+
async function gitInit(directory: string) {
|
|
73
|
+
const stack = new Error().stack;
|
|
74
|
+
console.error('DEBUG git init:', {
|
|
75
|
+
directory,
|
|
76
|
+
cwd: process.cwd(),
|
|
77
|
+
nodeEnv: process.env.NODE_ENV,
|
|
78
|
+
stack,
|
|
79
|
+
});
|
|
80
|
+
|
|
81
|
+
await execFileAsync('git', ['init'], { cwd: directory });
|
|
82
|
+
}
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
**Critical:** Use `console.error()` in tests (not logger - may not show)
|
|
86
|
+
|
|
87
|
+
**Run and capture:**
|
|
88
|
+
```bash
|
|
89
|
+
npm test 2>&1 | grep 'DEBUG git init'
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
**Analyze stack traces:**
|
|
93
|
+
- Look for test file names
|
|
94
|
+
- Find the line number triggering the call
|
|
95
|
+
- Identify the pattern (same test? same parameter?)
|
|
96
|
+
|
|
97
|
+
## Finding Which Test Causes Pollution
|
|
98
|
+
|
|
99
|
+
If something appears during tests but you don't know which test:
|
|
100
|
+
|
|
101
|
+
Use the bisection script `find-polluter.sh` in this directory:
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
./find-polluter.sh '.git' 'src/**/*.test.ts'
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Runs tests one-by-one, stops at first polluter. See script for usage.
|
|
108
|
+
|
|
109
|
+
## Real Example: Empty projectDir
|
|
110
|
+
|
|
111
|
+
**Symptom:** `.git` created in `packages/core/` (source code)
|
|
112
|
+
|
|
113
|
+
**Trace chain:**
|
|
114
|
+
1. `git init` runs in `process.cwd()` ← empty cwd parameter
|
|
115
|
+
2. WorktreeManager called with empty projectDir
|
|
116
|
+
3. Session.create() passed empty string
|
|
117
|
+
4. Test accessed `context.tempDir` before beforeEach
|
|
118
|
+
5. setupCoreTest() returns `{ tempDir: '' }` initially
|
|
119
|
+
|
|
120
|
+
**Root cause:** Top-level variable initialization accessing empty value
|
|
121
|
+
|
|
122
|
+
**Fix:** Made tempDir a getter that throws if accessed before beforeEach
|
|
123
|
+
|
|
124
|
+
**Also added defense-in-depth:**
|
|
125
|
+
- Layer 1: Project.create() validates directory
|
|
126
|
+
- Layer 2: WorkspaceManager validates not empty
|
|
127
|
+
- Layer 3: NODE_ENV guard refuses git init outside tmpdir
|
|
128
|
+
- Layer 4: Stack trace logging before git init
|
|
129
|
+
|
|
130
|
+
## Key Principle
|
|
131
|
+
|
|
132
|
+
```dot
|
|
133
|
+
digraph principle {
|
|
134
|
+
"Found immediate cause" [shape=ellipse];
|
|
135
|
+
"Can trace one level up?" [shape=diamond];
|
|
136
|
+
"Trace backwards" [shape=box];
|
|
137
|
+
"Is this the source?" [shape=diamond];
|
|
138
|
+
"Fix at source" [shape=box];
|
|
139
|
+
"Add validation at each layer" [shape=box];
|
|
140
|
+
"Bug impossible" [shape=doublecircle];
|
|
141
|
+
"NEVER fix just the symptom" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
|
|
142
|
+
|
|
143
|
+
"Found immediate cause" -> "Can trace one level up?";
|
|
144
|
+
"Can trace one level up?" -> "Trace backwards" [label="yes"];
|
|
145
|
+
"Can trace one level up?" -> "NEVER fix just the symptom" [label="no"];
|
|
146
|
+
"Trace backwards" -> "Is this the source?";
|
|
147
|
+
"Is this the source?" -> "Trace backwards" [label="no - keeps going"];
|
|
148
|
+
"Is this the source?" -> "Fix at source" [label="yes"];
|
|
149
|
+
"Fix at source" -> "Add validation at each layer";
|
|
150
|
+
"Add validation at each layer" -> "Bug impossible";
|
|
151
|
+
}
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
**NEVER fix just where the error appears.** Trace back to find the original trigger.
|
|
155
|
+
|
|
156
|
+
## Stack Trace Tips
|
|
157
|
+
|
|
158
|
+
**In tests:** Use `console.error()` not logger - logger may be suppressed
|
|
159
|
+
**Before operation:** Log before the dangerous operation, not after it fails
|
|
160
|
+
**Include context:** Directory, cwd, environment variables, timestamps
|
|
161
|
+
**Capture stack:** `new Error().stack` shows complete call chain
|
|
162
|
+
|
|
163
|
+
## Real-World Impact
|
|
164
|
+
|
|
165
|
+
From debugging session (2025-10-03):
|
|
166
|
+
- Found root cause through 5-level trace
|
|
167
|
+
- Fixed at source (getter validation)
|
|
168
|
+
- Added 4 layers of defense
|
|
169
|
+
- 1847 tests passed, zero pollution
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: wdi-ux
|
|
3
|
+
description: Use when UX is produced or landed — dispatching bmad-ux for a PRD scope, then landing DESIGN.md, EXPERIENCE.md, the design system, and the screen registry into the layers they belong to. Optional, and it rides on G2. Never writes UX content itself.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# WDI UX
|
|
7
|
+
|
|
8
|
+
`bmad-ux` writes the UX. This skill decides whether it should run, hands it the scope, checks what
|
|
9
|
+
came back, and — because `bmad-ux` is **class B** — lands its output into the two layers it splits
|
|
10
|
+
across. No other skill MAY land these files.
|
|
11
|
+
|
|
12
|
+
Two acts, and a pass MAY do either or both: **run** the UX, and **land** it. They are separated because
|
|
13
|
+
they become possible at different moments. A run belongs to G2, where the PRD is fresh. Landing needs a
|
|
14
|
+
Product Component to land into, and that list is not born until the tail of G2.
|
|
15
|
+
|
|
16
|
+
You MUST NOT write or edit `DESIGN.md` or `EXPERIENCE.md` yourself. If a check fails, name what is
|
|
17
|
+
missing and re-dispatch — a hand-patched UX document makes the memlog lie about how it got that way.
|
|
18
|
+
The content rules are in `ux-guide.md` and MUST NOT be restated here.
|
|
19
|
+
|
|
20
|
+
## Inputs
|
|
21
|
+
|
|
22
|
+
| Source | What it answers |
|
|
23
|
+
|---|---|
|
|
24
|
+
| `.what/_prd/<initiative>/prd.md` | The promises the UX has to make usable — `FR`, `NFR`, `UJ-N` |
|
|
25
|
+
| `.what/_product-brief/brief.md` | The primary user, and the boundary the UX MUST respect |
|
|
26
|
+
| `.constitution/document/ux-guide.md` | The rules the result is checked against |
|
|
27
|
+
| `.constitution/document/templates/ux.md` | The required shape of each half |
|
|
28
|
+
| `.control/registry/components.yaml` | Whether the Product Components and containers a landing needs exist |
|
|
29
|
+
| `.constitution/document/templates/design-system.md` | The shape of the product-level tokens file |
|
|
30
|
+
| `.control/product-glossary.md` | Terms already fixed, so the screens do not invent competing ones |
|
|
31
|
+
| `_bmad-output/ux/` | An earlier run — the input to *land*, and to intent *update* |
|
|
32
|
+
| `.how/_platform/design-system.md` | Tokens and base components already agreed |
|
|
33
|
+
|
|
34
|
+
## Step 1 — Position
|
|
35
|
+
|
|
36
|
+
- UX is **optional**. It earns a run when the interface is a substantial part of what the PRD
|
|
37
|
+
promises; it MUST NOT be run to fill a slot. Say so and stop when a run buys nothing.
|
|
38
|
+
- The order is `wdi-product` → `wdi-ux`. A UX run with no PRD in scope is designing a promise nobody
|
|
39
|
+
made; route to `wdi-product` first.
|
|
40
|
+
- If the ask is a new capability rather than how an agreed one feels, this is the wrong skill — route
|
|
41
|
+
to `wdi-product` intent `update`.
|
|
42
|
+
- If the ask is how the system behaves internally, route to `wdi-blueprint` for the catalogue, or
|
|
43
|
+
`wdi-component` for a full flow.
|
|
44
|
+
|
|
45
|
+
## Step 2 — Mode
|
|
46
|
+
|
|
47
|
+
Read `_bmad-output/ux/` and `components.yaml`, then state the mode in one line before acting.
|
|
48
|
+
|
|
49
|
+
| State | Mode |
|
|
50
|
+
|---|---|
|
|
51
|
+
| No run for this scope | **run** — Step 3, then Step 5 for whatever is landable |
|
|
52
|
+
| A run exists, finalised, nothing landed | **land** — Step 5 only |
|
|
53
|
+
| A run exists and the PRD has changed under it | **run** intent *update*, then Step 5 |
|
|
54
|
+
| A run exists, landed, and a `<pc>` has since been born | **land** — the deferred half, Step 5 |
|
|
55
|
+
|
|
56
|
+
## Step 3 — Dispatch
|
|
57
|
+
|
|
58
|
+
Invoke `bmad-ux` with the detected intent. Do not restate the rules to it — they arrive through
|
|
59
|
+
`doc_standards` and `persistent_facts` in `_bmad/custom/bmad-ux.toml`, and a second copy here would
|
|
60
|
+
drift.
|
|
61
|
+
|
|
62
|
+
State the scope as **one PRD initiative**, and name the input files explicitly; the skill globs its
|
|
63
|
+
own default locations, which this project redirects. A scope spanning several initiatives MUST be
|
|
64
|
+
split into one run each — the run folder is a singleton per scope, and two initiatives in one folder
|
|
65
|
+
cannot be landed separately later.
|
|
66
|
+
|
|
67
|
+
## Step 4 — Verify
|
|
68
|
+
|
|
69
|
+
Check what came back against the guide. Report every failure; fix none of them by hand.
|
|
70
|
+
|
|
71
|
+
| # | Check | Fails when |
|
|
72
|
+
|---|---|---|
|
|
73
|
+
| 1 | Landing zone | Anything was written into `.what/` or `.how/` by the run itself |
|
|
74
|
+
| 2 | Two documents, split correctly | A layout, component, or token sits in `EXPERIENCE.md`; a promise sits first in `DESIGN.md` |
|
|
75
|
+
| 3 | Journeys reference `UJ-N` | The PRD's journeys were restated under new names |
|
|
76
|
+
| 4 | Every screen has an empty and an error state | Only the populated state was designed |
|
|
77
|
+
| 5 | Every user-facing noun is in the glossary | A new noun appeared — route it through `wdi-blueprint`, which owns the glossary, in this pass |
|
|
78
|
+
| 6 | No new capability | The run designed something no `FR` promises — route to `wdi-product`, and MUST NOT land it |
|
|
79
|
+
| 7 | Every `[ASSUMPTION]` filed | An assumption sits in the text with nothing in `.control/questions/` behind it |
|
|
80
|
+
| 8 | Memlog at `.control/memlog/ux.md` | A `.memlog.md` appeared inside the corpus — `--workspace` was used |
|
|
81
|
+
| 9 | `bmad-review` structure + prose ran at finalize | `doc_standards` did not fire |
|
|
82
|
+
|
|
83
|
+
Check 8 is the one that MUST be fixed immediately rather than reported. A `.memlog.md` inside `.what/`
|
|
84
|
+
or `.how/` is corpus pollution, and V16 rejects it.
|
|
85
|
+
|
|
86
|
+
## Step 5 — Land, at two speeds
|
|
87
|
+
|
|
88
|
+
Nothing is landed until the run is finalised. The homes are in `corpus-guide.md`; what is decided
|
|
89
|
+
here is **when each one becomes possible**.
|
|
90
|
+
|
|
91
|
+
| Output | Lands into | Possible once |
|
|
92
|
+
|---|---|---|
|
|
93
|
+
| Tokens and base components | `.how/_platform/design-system.md` | The run is final — it crosses components by definition |
|
|
94
|
+
| `EXPERIENCE.md` | `.what/<pc>/04-usecases/` | The `<pc>` is registered in `components.yaml` |
|
|
95
|
+
| `DESIGN.md` | `.how/<pc>/01-ux/` | The `<pc>` is registered **and** its container exists |
|
|
96
|
+
| Each screen | an `LC` of type `ui-screen` in `components.yaml` | Same as `DESIGN.md` — an `LC` MUST name its container. Registration is checked at wave close, V12 |
|
|
97
|
+
|
|
98
|
+
- A half that is not yet landable MUST stay in `_bmad-output/ux/` and be reported as deferred. At G2
|
|
99
|
+
that is the normal outcome, not a failure: the slicing is born at the tail of G2 and containers at G3.
|
|
100
|
+
- You MUST NOT create a Product Component or a container to make a landing possible. A PC comes from
|
|
101
|
+
`wdi-init` intent `component` and a container from `wdi-blueprint` intent `platform`.
|
|
102
|
+
- One run MAY land across several Product Components. Split by which `<pc>` the content serves; a
|
|
103
|
+
screen whose `<pc>` is ambiguous MUST be raised through `wdi-question`, not assigned by guess.
|
|
104
|
+
- Registering the screens is part of landing `DESIGN.md`, in the same act. A screen in `01-ux/`
|
|
105
|
+
without its `components.yaml` entry has been half-landed, and V12 catches it at a worse moment.
|
|
106
|
+
- `.how/_platform/` otherwise belongs to `wdi-blueprint`. `design-system.md` is the one file in it you
|
|
107
|
+
own, and it has its own template; you MUST NOT touch any other.
|
|
108
|
+
- The run folder MUST NOT be deleted after landing. Intent *update* reads it again.
|
|
109
|
+
|
|
110
|
+
## Step 6 — Impact
|
|
111
|
+
|
|
112
|
+
A landed UX changes what other documents can still claim. Check, and **report** — never edit.
|
|
113
|
+
|
|
114
|
+
| Found | Where it goes |
|
|
115
|
+
|---|---|
|
|
116
|
+
| A flow the PRD does not promise | `wdi-product` intent `update`, before it is designed |
|
|
117
|
+
| A behaviour the SRS never stated | `wdi-blueprint` for a catalogue line, `wdi-component` for a flow |
|
|
118
|
+
| A pattern that forces a technology choice | `wdi-decision` — a `DEC-`, not a note in `DESIGN.md` |
|
|
119
|
+
| A screen contradicting an `applied` `DEC-` | `wdi-decision` — a new `DEC-`, never an edit to one already applied |
|
|
120
|
+
|
|
121
|
+
`wdi-reconcile` is the read-only sweep across all layers. Run it rather than reimplementing it.
|
|
122
|
+
|
|
123
|
+
## Step 7 — Memlog
|
|
124
|
+
|
|
125
|
+
Everything in a UX pass — the run and the landing — logs to `.control/memlog/ux.md`, through
|
|
126
|
+
`memlog.py --path`. `--workspace` MUST NOT be used.
|
|
127
|
+
|
|
128
|
+
## Rules
|
|
129
|
+
|
|
130
|
+
- Content MUST NOT be edited while it is being landed. Splitting one document across the homes its
|
|
131
|
+
row names is not editing; changing a sentence to fit its new home is, and it goes back through
|
|
132
|
+
`bmad-ux`.
|
|
133
|
+
- You MUST NOT open G2 on UX that has not been through check 9. Gate time is for deciding.
|
|
134
|
+
- You MUST NOT raise `status:` as part of landing. Status is a stage; the `reviewed:` block is an
|
|
135
|
+
event, and `wdi-review` writes it.
|
|
136
|
+
- You MUST NOT land anything into a wave that is already closed. The wave is reopened through
|
|
137
|
+
`wdi-build`, or the gap is filed through `wdi-question`.
|
|
138
|
+
- When the UX concludes the PRD promised something that cannot be made usable, say so and stop. Route
|
|
139
|
+
to `wdi-product`; do not quietly narrow the promise in `EXPERIENCE.md`.
|
|
140
|
+
|
|
141
|
+
## Output
|
|
142
|
+
|
|
143
|
+
A short report: mode taken, scope run, the result of all nine checks naming the failures, what landed
|
|
144
|
+
and where, what was deferred and what has to exist before it can land, screens registered, impact
|
|
145
|
+
found and where it was routed, and open questions raised.
|
|
@@ -0,0 +1,196 @@
|
|
|
1
|
+
# Agent Rules — {product}
|
|
2
|
+
|
|
3
|
+
<!-- BEGIN:wdi-method -->
|
|
4
|
+
This repo uses **WDI Method**. It wraps BMad; it does not replace it. This marked
|
|
5
|
+
block is owned by the WDI Method package and is **replaced on every update**.
|
|
6
|
+
Product rules belong **outside** it (extra boundaries, `## Code`, stack notes).
|
|
7
|
+
A fact written inside this block will be overwritten.
|
|
8
|
+
|
|
9
|
+
Product identity lives in `.control/registry/index.yaml` (`product.name`, optional
|
|
10
|
+
`product.client`). G1 confirms it. This file MUST NOT become a second source of the name.
|
|
11
|
+
|
|
12
|
+
## Install and update
|
|
13
|
+
|
|
14
|
+
BMad first, then WDI Method. In the product repo:
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
npx bmad-method install
|
|
18
|
+
npx github:wiradigitalid/wdi-method
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
No subcommand opens the installer TUI. It detects an existing install and offers
|
|
22
|
+
**update**. Non-interactive:
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
npx github:wiradigitalid/wdi-method install --yes
|
|
26
|
+
npx github:wiradigitalid/wdi-method update --yes
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
BMad: https://github.com/bmad-code-org/BMAD-METHOD
|
|
30
|
+
WDI Method: https://github.com/wiradigitalid/wdi-method
|
|
31
|
+
|
|
32
|
+
A method file MUST NOT be invented here. If a rule is wrong, fix it in the WDI
|
|
33
|
+
Method package, then update.
|
|
34
|
+
|
|
35
|
+
This file is loaded every session; everything else is loaded **lazily**, only when
|
|
36
|
+
the task matches.
|
|
37
|
+
|
|
38
|
+
## Language
|
|
39
|
+
|
|
40
|
+
Prose in this repo is Bahasa Indonesia; a technical term the industry writes in English MUST be left
|
|
41
|
+
in English — an Indonesian equivalent MUST NOT be invented. Which language a **name** is written in —
|
|
42
|
+
code identifiers, files, database columns — is governed by `.constitution/language-guide.md`.
|
|
43
|
+
|
|
44
|
+
The agent-instruction files are the exception the Rule-Writing Standard already claims: `AGENTS.md`,
|
|
45
|
+
`CLAUDE.md`, and everything under `.constitution/`. Nothing else in this repo is one — `.control/`,
|
|
46
|
+
`.what/`, and `.how/` are product content and MUST stay Bahasa Indonesia, and translating them MUST
|
|
47
|
+
NOT be proposed as tidying. A literal value written into an Indonesian document — a marker such as
|
|
48
|
+
`[TIDAK ADA]`, an answer option such as `ya / tidak / ubah` — stays Indonesian wherever it appears,
|
|
49
|
+
including inside an English guide.
|
|
50
|
+
|
|
51
|
+
A **registry value** is a machine-facing key and stays English: `mode: catalog`, `status: applied`,
|
|
52
|
+
`risk_accepted: low`. Those names are used as written in prose too — one thing, one name.
|
|
53
|
+
|
|
54
|
+
## The thing in your hand → its folder
|
|
55
|
+
|
|
56
|
+
Read this instead of reasoning about what `.what/` and `.how/` mean.
|
|
57
|
+
|
|
58
|
+
| The thing in your hand | Its folder |
|
|
59
|
+
|---|---|
|
|
60
|
+
| A rule, a guide, a template — how we work | `.constitution/` |
|
|
61
|
+
| The explanation of a rule, never a rule itself | `.constitution/method/` |
|
|
62
|
+
| A decision, an open question, a registry, a structure map, minutes | `.control/` |
|
|
63
|
+
| The brief, a PRD, a use case, a business rule — what is promised | `.what/` |
|
|
64
|
+
| The spine, C4, an inventory, an SDD, a contract — how it is built | `.how/` |
|
|
65
|
+
| A skill run's working output, and documents that predate the method | `_bmad-output/` |
|
|
66
|
+
| Scratch that empties when the task closes | `.work/` |
|
|
67
|
+
| The application | named under `## Code` below |
|
|
68
|
+
|
|
69
|
+
## Layer boundaries
|
|
70
|
+
|
|
71
|
+
| Layer | Answers | MUST NOT hold |
|
|
72
|
+
|---|---|---|
|
|
73
|
+
| `.constitution/` | How we work | State, decisions, product content |
|
|
74
|
+
| `.control/` | What currently holds and what has been decided | Rules |
|
|
75
|
+
| `.what/` | What is promised | Solution shape — tables, endpoints, technology |
|
|
76
|
+
| `.how/` | How it is built | Promises to the user |
|
|
77
|
+
| `_bmad-output/` | Work in progress; committed, not curated | Anything still correct after its wave has passed |
|
|
78
|
+
| `.work/` | Scratch; emptied when a task closes | Secrets, commercial figures, anything meant as authority |
|
|
79
|
+
|
|
80
|
+
The placement test: **is this file still correct after its wave has passed?** Yes → the corpus. No →
|
|
81
|
+
`_bmad-output/`. In doubt → `document/corpus-guide.md`.
|
|
82
|
+
|
|
83
|
+
The method does not use a `docs/` layer for corpus or rules. A leftover `docs/` folder is inventory
|
|
84
|
+
to sort, not a second home.
|
|
85
|
+
|
|
86
|
+
## Depth and review intensity — two fields, never merged
|
|
87
|
+
|
|
88
|
+
| Field | Where | Controls |
|
|
89
|
+
|---|---|---|
|
|
90
|
+
| `mode` | `index.yaml` globally, `components.yaml` per component | **Document depth**, and only that. `catalog` · `outline` · `guarded` · `deep`; default `catalog` |
|
|
91
|
+
| `risk_accepted` | `components.yaml` per component | **Review intensity**, and only that. `low` · `medium` · `high` |
|
|
92
|
+
|
|
93
|
+
Per-component `mode` wins over global, and there is no third scope — `mode` MUST NOT be overridden per
|
|
94
|
+
wave or per `SPEC.md`. A component at `mode: catalog` **skips G4 entirely**. Neither field MUST be
|
|
95
|
+
derived from the other: one component MAY be thin on purpose and reviewed the hardest.
|
|
96
|
+
`document/delivery-flow-guide.md` owns both; `method/rationale.md` says why they are separate.
|
|
97
|
+
|
|
98
|
+
## The five gates and the fifteen skills
|
|
99
|
+
|
|
100
|
+
| Gate | Decides | Skill |
|
|
101
|
+
|---|---|---|
|
|
102
|
+
| **G1 Problem** | What the problem is, whose it is, why it earns work | `wdi-problem` |
|
|
103
|
+
| **G2 Product** | What is built, and how it feels to use | `wdi-product` · optional `wdi-ux` |
|
|
104
|
+
| **G3 Blueprint** | The whole portrait, once per product | `wdi-blueprint` |
|
|
105
|
+
| **G4 Component** | How one component is built — **skipped at `catalog`** | `wdi-component` |
|
|
106
|
+
| **G5 Release** | Whether it is done and proven | `wdi-build` |
|
|
107
|
+
|
|
108
|
+
Before G1 and at the tail of G2: `wdi-init`, five intents — `setup` · `component` · `mode` · `risk` ·
|
|
109
|
+
`structure`.
|
|
110
|
+
|
|
111
|
+
Any time: `wdi-decision` · `wdi-question` · `wdi-log` · `wdi-help` · `wdi-reconcile` · `wdi-review` ·
|
|
112
|
+
`wdi-report` · `wdi-systematic-debugging`.
|
|
113
|
+
|
|
114
|
+
**No BMad skill is invoked directly.** Each has a wrapper, and the wrapper is what checks position,
|
|
115
|
+
verifies the result, and lands the memlog.
|
|
116
|
+
|
|
117
|
+
## What MUST NOT be done
|
|
118
|
+
|
|
119
|
+
- A method file MUST NOT be invented or patched here to improve the method. If a rule is wrong, it is
|
|
120
|
+
fixed in the WDI Method package, then brought here with `npx wdi-method update`.
|
|
121
|
+
- A file in `_bmad-output/prior-knowledge/` MUST NOT be copied into `.what/` or `.how/`. It enters
|
|
122
|
+
the corpus only through the skill that owns the slot.
|
|
123
|
+
- `.control/generated/` MUST NOT be written by hand — it is the output of `validate.py` and
|
|
124
|
+
`timeline.py`.
|
|
125
|
+
- The two structure maps in `.control/` MUST NOT be edited by hand — `wdi-init` intent `structure`
|
|
126
|
+
re-derives them.
|
|
127
|
+
- A `DEC-` with status `applied` MUST NOT be edited, except to record its supersession — status moves
|
|
128
|
+
to `superseded` and names its replacement. A change of mind produces a new `DEC-`.
|
|
129
|
+
- A file in `.constitution/method/` MUST NOT be cited as the reason to reject a change. It is
|
|
130
|
+
`status: Reference` — it explains, it does not bind, and where it disagrees with a guide the guide
|
|
131
|
+
wins and the disagreement is a defect.
|
|
132
|
+
- More than the component's `mode` demands MUST NOT be written. Exceeding the depth the owner set is
|
|
133
|
+
not diligence.
|
|
134
|
+
- `.claude/skills/bmad-*/customize.toml` MUST NOT be edited — it is overwritten on every BMad update;
|
|
135
|
+
customise through `_bmad/custom/`.
|
|
136
|
+
|
|
137
|
+
## Routing — load a guide when the task matches
|
|
138
|
+
|
|
139
|
+
| Task | Load |
|
|
140
|
+
|---|---|
|
|
141
|
+
| Wanting the whole method in five minutes | `.constitution/method/README.md` |
|
|
142
|
+
| About to change a rule, and needing to know what breaks | `.constitution/method/rationale.md` |
|
|
143
|
+
| Asking whether a document exists at this `mode`, or where a file goes | `.constitution/method/artifact-map.md` |
|
|
144
|
+
| Unsure whether a file may exist in this repo | `.constitution/repo-guide.md` |
|
|
145
|
+
| Unsure where a file lives | `.constitution/document/corpus-guide.md` |
|
|
146
|
+
| Unsure what a method term means | `.constitution/method-glossary.md` |
|
|
147
|
+
| Unsure about a domain term | `.control/product-glossary.md` |
|
|
148
|
+
| Looking for a non-technical fact — a domain, an account, a legal entity, a locked date | `.control/project-non-technical-log.md` |
|
|
149
|
+
| Naming anything — a code identifier, a file, a database column | `.constitution/language-guide.md` |
|
|
150
|
+
| Asking "which gate now, what next" | `.constitution/document/delivery-flow-guide.md` · skill `wdi-help` |
|
|
151
|
+
| Setting or changing `mode` or `risk_accepted` | `.constitution/document/delivery-flow-guide.md` · skill `wdi-init` |
|
|
152
|
+
| Invoking a BMad skill | `.constitution/document/bmad-guide.md` · `document/bmad-skill-register.md` |
|
|
153
|
+
| Writing or reviewing a product brief | `.constitution/document/brief-guide.md` |
|
|
154
|
+
| Writing or reviewing a PRD | `.constitution/document/prd-guide.md` |
|
|
155
|
+
| Writing or reviewing UX | `.constitution/document/ux-guide.md` |
|
|
156
|
+
| Writing or reviewing an SRS | `.constitution/document/srs-guide.md` |
|
|
157
|
+
| Writing or reviewing an SDD | `.constitution/document/sdd-guide.md` |
|
|
158
|
+
| Writing the spine, an `AD-N`, C4, or one of the three inventories | `.constitution/document/architecture-guide.md` |
|
|
159
|
+
| Opening, accepting, or applying a `DEC-` | `.constitution/document/decision-guide.md` |
|
|
160
|
+
| Writing or reading a structure map | `.constitution/structure-guide.md` |
|
|
161
|
+
| Looking for where code lives, or placing new code | `.control/structure-codebase.md` |
|
|
162
|
+
| Looking for where a document lives | `.control/structure-document.md` |
|
|
163
|
+
| Writing or reviewing code | `.constitution/codebase/stack-guide.md` · `conventions-guide.md` · `brownfield-guide.md` |
|
|
164
|
+
|
|
165
|
+
All three `codebase/*-guide.md` start as `status: Draft`. While they are, their contents MAY be read
|
|
166
|
+
as guidance but MUST NOT be used to reject a change.
|
|
167
|
+
|
|
168
|
+
The two structure maps MUST NOT be installed as `doc_standards` — they are facts, not standards. Nor
|
|
169
|
+
MUST anything in `.constitution/method/`; `status: Reference` forbids it.
|
|
170
|
+
|
|
171
|
+
## Bugs, decisions, questions
|
|
172
|
+
|
|
173
|
+
- A bug, a failing test, or unexpected behaviour → skill `wdi-systematic-debugging`, **before** any
|
|
174
|
+
fix is proposed.
|
|
175
|
+
- A decision worth remembering → skill `wdi-decision` → `.control/decisions/`. Recording is **not
|
|
176
|
+
mandatory**: if the answer to *why is it like this* is readable from the code, it MUST NOT be
|
|
177
|
+
recorded. One case is mandatory — contradicting an `AD-N`.
|
|
178
|
+
- Something that cannot be decided now → skill `wdi-question` → `.control/questions/`. The default
|
|
179
|
+
class is `assumptions.md`, not `blocking.md`; filing something as blocking "to be safe" is the
|
|
180
|
+
habit that produced unreadable question lists.
|
|
181
|
+
- A non-technical fact that constrains the build → skill `wdi-log` intent `fact` →
|
|
182
|
+
`.control/project-non-technical-log.md`.
|
|
183
|
+
|
|
184
|
+
## Method policy
|
|
185
|
+
|
|
186
|
+
- A skill MUST NOT be invoked automatically. Name the one that fits and wait for the owner's
|
|
187
|
+
go-ahead — this holds even when the skill's own description says it must be used. Reading a
|
|
188
|
+
skill as reference is fine.
|
|
189
|
+
- `.work/` is not production code. It MUST NOT be imported by the application, and MUST be
|
|
190
|
+
excluded when searching for code.
|
|
191
|
+
<!-- END:wdi-method -->
|
|
192
|
+
|
|
193
|
+
## Code
|
|
194
|
+
|
|
195
|
+
Rewrite this section for the product. Stack, how to run tests, and known pitfalls belong here.
|
|
196
|
+
`wdi-init` intent `structure` derives `.control/structure-codebase.md`; do not duplicate that map.
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: Reference
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# `.constitution/` — index
|
|
6
|
+
|
|
7
|
+
Method files arrive from the public WDI Method package via `npx wdi-method install`
|
|
8
|
+
or `update`. Load [`constitution.md`](constitution.md) before acting. Guides are
|
|
9
|
+
loaded **lazily** — only when the task matches, and every guide states when on its
|
|
10
|
+
own **Loaded when:** line.
|
|
11
|
+
|
|
12
|
+
Every file here carries a `status:` — Article 4 owns the five values. Only `Accepted` binds;
|
|
13
|
+
`Reference` explains and MUST NOT be cited to reject a change. A template carries no status of its
|
|
14
|
+
own, because its frontmatter belongs to the artifact it produces.
|
|
15
|
+
|
|
16
|
+
A file this product added (one that is not in the snapshot) stays here across `update` and MUST be
|
|
17
|
+
listed from `constitution.md` Article 2 or from `AGENTS.md` routing — this index is overwritten on
|
|
18
|
+
every update.
|
|
19
|
+
|
|
20
|
+
## `method/` — the explanation, `status: Reference`
|
|
21
|
+
|
|
22
|
+
Never a rule. When it disagrees with a guide, the guide wins and the disagreement is a defect.
|
|
23
|
+
|
|
24
|
+
| File | Opened when |
|
|
25
|
+
|---|---|
|
|
26
|
+
| [`method/README.md`](method/README.md) | You want the whole shape in five minutes — five gates, two settings, fifteen skills, WDI ↔ BMad |
|
|
27
|
+
| [`method/artifact-map.md`](method/artifact-map.md) | "Where does this file go", or "does this document exist at my `mode`" |
|
|
28
|
+
| [`method/rationale.md`](method/rationale.md) | Before changing a rule, to know what you would break |
|
|
29
|
+
| [`method/portability.md`](method/portability.md) | Which files are the method and which are the product; how promote and install move them |
|
|
30
|
+
|
|
31
|
+
## Cross-domain
|
|
32
|
+
|
|
33
|
+
| File | Loaded when |
|
|
34
|
+
|---|---|
|
|
35
|
+
| [`repo-guide.md`](repo-guide.md) | Adding a file that is neither code nor corpus; the content boundary, `.work/`, cross-repo references |
|
|
36
|
+
| [`language-guide.md`](language-guide.md) | Naming anything — a code identifier, a code file, a document file |
|
|
37
|
+
| [`method-glossary.md`](method-glossary.md) | Unsure what a method term means — layer, wave, Product Component, ID code |
|
|
38
|
+
| [`structure-guide.md`](structure-guide.md) | Writing or checking the two structure maps in `.control/` |
|
|
39
|
+
|
|
40
|
+
## `document/` — document rules
|
|
41
|
+
|
|
42
|
+
| File | Governs |
|
|
43
|
+
|---|---|
|
|
44
|
+
| [`corpus-guide.md`](document/corpus-guide.md) | Where a file lives. Read before the other guides |
|
|
45
|
+
| [`delivery-flow-guide.md`](document/delivery-flow-guide.md) | Five gates, `mode`, `risk_accepted`, the gate checklists, units of work, wave size, Fast Path, the story-closing checklist, change control |
|
|
46
|
+
| [`bmad-guide.md`](document/bmad-guide.md) | How BMad skills are used here; classes A–D, the read-write map, memlog |
|
|
47
|
+
| [`bmad-skill-register.md`](document/bmad-skill-register.md) | The installed BMad skills with the documents each reads and writes |
|
|
48
|
+
| [`brief-guide.md`](document/brief-guide.md) · [`prd-guide.md`](document/prd-guide.md) · [`ux-guide.md`](document/ux-guide.md) | The G1 and G2 artifacts |
|
|
49
|
+
| [`srs-guide.md`](document/srs-guide.md) · [`sdd-guide.md`](document/sdd-guide.md) | The G3 and G4 artifacts, per Product Component |
|
|
50
|
+
| [`architecture-guide.md`](document/architecture-guide.md) | The architecture spine, `AD-N`, C4, and the three inventories |
|
|
51
|
+
| [`decision-guide.md`](document/decision-guide.md) | `DEC-`: the one test for recording at all, shape, global numbering, the `draft → accepted → applied` ladder, supersession |
|
|
52
|
+
| [`templates/`](document/templates/) | Templates, one per kind of document; they MUST be copied, and MUST NOT be reproduced from memory |
|
|
53
|
+
|
|
54
|
+
## `codebase/` — code rules
|
|
55
|
+
|
|
56
|
+
All three are written by the **project**, not the kit. While `Draft`, their contents MAY be read as
|
|
57
|
+
guidance but MUST NOT be used to reject a change.
|
|
58
|
+
|
|
59
|
+
[`stack-guide.md`](codebase/stack-guide.md) · [`conventions-guide.md`](codebase/conventions-guide.md) · [`brownfield-guide.md`](codebase/brownfield-guide.md)
|
|
60
|
+
|
|
61
|
+
## `scripts/`
|
|
62
|
+
|
|
63
|
+
`validate.py` — registry gates and the `.control/generated/` generator. `timeline.py` — the time
|
|
64
|
+
dimension from git history. `inventory.py` — derives the three inventories from code and reports the
|
|
65
|
+
difference against the plan; it MUST NOT patch either side into agreement. All three run through
|
|
66
|
+
`uv run`.
|