wdi-method 0.6.1 → 0.6.4
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/README.md +58 -7
- package/bin/wdi-method.js +144 -0
- package/kit/.constitution/method/README.md +1 -1
- package/kit/.constitution/method/document/decision-guide.md +208 -199
- package/kit/.constitution/method/document/delivery-flow-guide.md +412 -409
- package/kit/.constitution/method/document/templates/decision.md +6 -1
- package/kit/.constitution/method/method-glossary.md +183 -182
- package/kit/.constitution/method/scripts/validate.py +102 -2
- package/kit/.constitution/method/why/README.md +2 -1
- package/kit/.constitution/method/why/portability.md +98 -98
- package/kit/skills/wdi-autopilot/SKILL.md +375 -0
- package/kit/skills/wdi-build/SKILL.md +371 -357
- package/kit/skills/wdi-decision/SKILL.md +197 -187
- package/kit/skills/wdi-help/SKILL.md +110 -100
- package/kit/skills/wdi-question/SKILL.md +176 -170
- package/kit/skills/wdi-upgrade/SKILL.md +8 -0
- package/kit-overlay/AGENTS.md +227 -217
- package/kit-overlay/README.md +1 -1
- package/kit-overlay/portability.md +98 -98
- package/package.json +1 -1
- package/scaffold/docs/agents/domain.md +36 -0
- package/scaffold/docs/agents/issue-tracker.md +43 -0
|
@@ -1,187 +1,197 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: wdi-decision
|
|
3
|
-
description: Use when a decision worth remembering has been made, when one has to be carried into the documents it governs, or when a planning assumption turns out to be void. Three intents — open, accept, apply. Wraps bmad-correct-course. Produces a globally numbered DEC-.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# WDI Decision
|
|
7
|
-
|
|
8
|
-
Free of stage and free of role: a decision MAY be made at any point by anyone. What is fixed is where its
|
|
9
|
-
output lives — `.control/decisions/DEC-NNN-<slug>.md`, numbered globally from `decisions.yaml`.
|
|
10
|
-
|
|
11
|
-
Three intents, because deciding, ratifying, and rewriting the documents are three different acts and merging
|
|
12
|
-
them means documents change before anyone approved the change.
|
|
13
|
-
|
|
14
|
-
| Intent | Does | Who |
|
|
15
|
-
|---|---|---|
|
|
16
|
-
| `open` | Writes a `DEC-` at `status: draft`. Also the entry point for a void planning assumption, which is where `bmad-correct-course` is dispatched | anyone |
|
|
17
|
-
| `accept` | Raises `draft` → `accepted` | **the Product Owner
|
|
18
|
-
| `apply` | Dispatches the owner of every document the decision reaches, checks what came back, fills `touches`, raises `applied` | anyone |
|
|
19
|
-
|
|
20
|
-
Applying is what **freezes** a decision, not accepting. `decision-guide.md` owns the full ladder and this skill
|
|
21
|
-
MUST NOT restate it.
|
|
22
|
-
|
|
23
|
-
## The one test, before anything is written
|
|
24
|
-
|
|
25
|
-
> **If someone asks in three months why it is like this, is the answer readable from the code?**
|
|
26
|
-
|
|
27
|
-
Yes → it MUST NOT be recorded. No → record it.
|
|
28
|
-
|
|
29
|
-
**Recording is not mandatory**, and a decision nobody recorded is normal rather than negligence. You MUST NOT
|
|
30
|
-
log it as debt or backfill it later from memory. One case stays mandatory: a decision that **contradicts or
|
|
31
|
-
changes an `AD-N`**.
|
|
32
|
-
|
|
33
|
-
The old name ADR forced the wrong question — *"is this architectural?"* — and that question threw away exactly
|
|
34
|
-
the decisions most worth keeping, the ones that sound small.
|
|
35
|
-
|
|
36
|
-
## Intent `open`
|
|
37
|
-
|
|
38
|
-
### Inputs
|
|
39
|
-
|
|
40
|
-
Any of these, alone or together: minutes in `.control/meetings/`, an answered question in
|
|
41
|
-
`.control/questions/`, a review or debugging finding, a memlog in `.control/memlog/`, a `wdi-reconcile` conflict.
|
|
42
|
-
|
|
43
|
-
The memlog is the richest source and the most often forgotten. It is the record of *why* — read it before
|
|
44
|
-
writing the Why section rather than reconstructing the reasoning from the outcome.
|
|
45
|
-
|
|
46
|
-
### What it writes
|
|
47
|
-
|
|
48
|
-
Three sections, always: **Decision** (one sentence, present tense, quotable) · **Why** · **Cost** (what becomes
|
|
49
|
-
harder). Alternatives, a reversal trigger, and Trace are required only when the decision reaches a Product
|
|
50
|
-
Component whose `risk_accepted` is `low`; elsewhere an empty one MUST be dropped rather than left as a heading.
|
|
51
|
-
|
|
52
|
-
Frontmatter carries `touches: []` — empty until applied — and `type:` when it is useful. There is no `layer:`
|
|
53
|
-
and no `component:`; both were classifications demanded before anything was known.
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
|
85
|
-
|
|
86
|
-
|
|
|
87
|
-
|
|
|
88
|
-
|
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
|
130
|
-
|
|
131
|
-
| `.
|
|
132
|
-
| `.
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
1
|
+
---
|
|
2
|
+
name: wdi-decision
|
|
3
|
+
description: Use when a decision worth remembering has been made, when one has to be carried into the documents it governs, or when a planning assumption turns out to be void. Three intents — open, accept, apply. Wraps bmad-correct-course. Produces a globally numbered DEC-.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# WDI Decision
|
|
7
|
+
|
|
8
|
+
Free of stage and free of role: a decision MAY be made at any point by anyone. What is fixed is where its
|
|
9
|
+
output lives — `.control/decisions/DEC-NNN-<slug>.md`, numbered globally from `decisions.yaml`.
|
|
10
|
+
|
|
11
|
+
Three intents, because deciding, ratifying, and rewriting the documents are three different acts and merging
|
|
12
|
+
them means documents change before anyone approved the change.
|
|
13
|
+
|
|
14
|
+
| Intent | Does | Who |
|
|
15
|
+
|---|---|---|
|
|
16
|
+
| `open` | Writes a `DEC-` at `status: draft`. Also the entry point for a void planning assumption, which is where `bmad-correct-course` is dispatched | anyone |
|
|
17
|
+
| `accept` | Raises `draft` → `accepted` | **the Product Owner** — or `wdi-autopilot` under an active mandate, with `accepted_by` naming the mandate |
|
|
18
|
+
| `apply` | Dispatches the owner of every document the decision reaches, checks what came back, fills `touches`, raises `applied` | anyone |
|
|
19
|
+
|
|
20
|
+
Applying is what **freezes** a decision, not accepting. `decision-guide.md` owns the full ladder and this skill
|
|
21
|
+
MUST NOT restate it.
|
|
22
|
+
|
|
23
|
+
## The one test, before anything is written
|
|
24
|
+
|
|
25
|
+
> **If someone asks in three months why it is like this, is the answer readable from the code?**
|
|
26
|
+
|
|
27
|
+
Yes → it MUST NOT be recorded. No → record it.
|
|
28
|
+
|
|
29
|
+
**Recording is not mandatory**, and a decision nobody recorded is normal rather than negligence. You MUST NOT
|
|
30
|
+
log it as debt or backfill it later from memory. One case stays mandatory: a decision that **contradicts or
|
|
31
|
+
changes an `AD-N`**.
|
|
32
|
+
|
|
33
|
+
The old name ADR forced the wrong question — *"is this architectural?"* — and that question threw away exactly
|
|
34
|
+
the decisions most worth keeping, the ones that sound small.
|
|
35
|
+
|
|
36
|
+
## Intent `open`
|
|
37
|
+
|
|
38
|
+
### Inputs
|
|
39
|
+
|
|
40
|
+
Any of these, alone or together: minutes in `.control/meetings/`, an answered question in
|
|
41
|
+
`.control/questions/`, a review or debugging finding, a memlog in `.control/memlog/`, a `wdi-reconcile` conflict.
|
|
42
|
+
|
|
43
|
+
The memlog is the richest source and the most often forgotten. It is the record of *why* — read it before
|
|
44
|
+
writing the Why section rather than reconstructing the reasoning from the outcome.
|
|
45
|
+
|
|
46
|
+
### What it writes
|
|
47
|
+
|
|
48
|
+
Three sections, always: **Decision** (one sentence, present tense, quotable) · **Why** · **Cost** (what becomes
|
|
49
|
+
harder). Alternatives, a reversal trigger, and Trace are required only when the decision reaches a Product
|
|
50
|
+
Component whose `risk_accepted` is `low`; elsewhere an empty one MUST be dropped rather than left as a heading.
|
|
51
|
+
|
|
52
|
+
Frontmatter carries `touches: []` — empty until applied — and `type:` when it is useful. There is no `layer:`
|
|
53
|
+
and no `component:`; both were classifications demanded before anything was known.
|
|
54
|
+
|
|
55
|
+
One `type` has a fixed shape: **`mandate`**, the decision `wdi-autopilot` opens at its preflight. Its
|
|
56
|
+
parameters — `from_gate` · `scope` · `parked` · `smoke_test` · `loop` · `expires` — live **only** on its row
|
|
57
|
+
in `decisions.yaml`, under `mandate:`; the file carries Decision, Why, and Cost and points at the row.
|
|
58
|
+
|
|
59
|
+
A `DEC-` MUST NOT hold an open question. Those go to `wdi-question`.
|
|
60
|
+
|
|
61
|
+
### A void planning assumption
|
|
62
|
+
|
|
63
|
+
This is the same intent, with one extra step in front. The trigger is one thing: **a planning assumption turned
|
|
64
|
+
out to be void.** It usually surfaces while building, but its impact reaches back into G2, G3, and G4.
|
|
65
|
+
|
|
66
|
+
Three things it is **not**:
|
|
67
|
+
|
|
68
|
+
| Ask | Route |
|
|
69
|
+
|---|---|
|
|
70
|
+
| Something is broken and the cause is unknown | `wdi-systematic-debugging` **first**. A correction built on a guessed cause corrects the wrong thing |
|
|
71
|
+
| A decision exists and documents must follow | intent `apply`. There is no plan to re-cut |
|
|
72
|
+
| Scope grows without invalidating anything | `wdi-product` intent `update`, then the normal flow |
|
|
73
|
+
|
|
74
|
+
State the void assumption in **one line** before dispatching. A correction whose trigger cannot be stated in one
|
|
75
|
+
line is a re-plan, and it belongs upstream.
|
|
76
|
+
|
|
77
|
+
Then dispatch `bmad-correct-course`. Do not restate the rules to it — they arrive through `persistent_facts` in
|
|
78
|
+
`_bmad/custom/bmad-correct-course.toml`, including the ban on direct edits. Name the corpus files in scope
|
|
79
|
+
explicitly; it globs its own defaults, which this project does not use.
|
|
80
|
+
|
|
81
|
+
**Its impact analysis is incomplete by construction** — it knows a PRD and BMad's own planning shapes, and it cannot see
|
|
82
|
+
`.what/<pc>/`, `.how/`, `.control/`, or `.constitution/`. Every one of these MUST be checked here:
|
|
83
|
+
|
|
84
|
+
| Layer | What to look for |
|
|
85
|
+
|---|---|
|
|
86
|
+
| `.what/_prd/` | The `FR`/`NFR` that no longer holds, and every one depending on it |
|
|
87
|
+
| `.what/<pc>/` | Use cases realising those `FR`, business rules, state lifecycles that lose a state |
|
|
88
|
+
| `.how/_platform/` | An `AD-N` the correction breaks, a container the C4 set no longer describes, an inventory row with nothing behind it |
|
|
89
|
+
| `.how/<pc>/` | Contracts, flows, and Failure Behaviour written against the old promise |
|
|
90
|
+
| the contract | What the spec projected — it MUST NOT be edited to match; it is re-cut |
|
|
91
|
+
| `specs.yaml` | The spec's size, and whether the correction changes it |
|
|
92
|
+
| Ticket files | Which tickets are in progress, and which have not been picked up |
|
|
93
|
+
|
|
94
|
+
The result is a `DEC-` of **`type: course-correction`**. The `SCP-` code is retired — a course correction is a
|
|
95
|
+
decision, and no second code names the same thing.
|
|
96
|
+
|
|
97
|
+
A correction cancelling more than **30%** of a spec's tickets MUST NOT be handled as a patch. Say so, and let
|
|
98
|
+
the spec be re-cut through `wdi-build`.
|
|
99
|
+
|
|
100
|
+
A ticket already in progress MUST NOT have what it asks for changed underneath it. Report it; stopping it and
|
|
101
|
+
returning it to `ready-for-agent` is the coordinator's act.
|
|
102
|
+
|
|
103
|
+
## Intent `accept`
|
|
104
|
+
|
|
105
|
+
Only the Product Owner MAY raise a `DEC-` to `accepted`. **An agent MUST NOT accept its own.** When work is
|
|
106
|
+
blocked waiting on one, the block is reported, never resolved by self-approval.
|
|
107
|
+
|
|
108
|
+
**One delegation, and it is checkable.** Under a `DEC-` of `type: mandate` at `status: accepted` whose
|
|
109
|
+
`expires` has not passed, `wdi-autopilot` MAY accept a decision on the owner's behalf, writing
|
|
110
|
+
`accepted_by: DEC-<mandate>` on the row and `date:` in the file. `mandate-accept` holds the chain: the target is a
|
|
111
|
+
real mandate, accepted, unexpired on that date — and the mandate itself is **never** accepted by delegation.
|
|
112
|
+
That is the one decision whose `accepted_by` is a person and a date, the way `risk_accepted_by` is.
|
|
113
|
+
|
|
114
|
+
An `accepted` `DEC-` that is still unapplied MAY be corrected in place, with the correction recorded in the
|
|
115
|
+
memlog. Nothing has been built on it, so there is no divergent record to preserve.
|
|
116
|
+
|
|
117
|
+
## Intent `apply`
|
|
118
|
+
|
|
119
|
+
**You apply nothing yourself.** Every artifact has an owner, and the owner writes it. A hand-edit here produces
|
|
120
|
+
a change with no author, no input trail, and nothing that verifies it.
|
|
121
|
+
|
|
122
|
+
Exactly one `DEC-`, at `status: accepted`. You MUST NOT apply one in any other status.
|
|
123
|
+
|
|
124
|
+
### Step 1 — List the targets before touching one
|
|
125
|
+
|
|
126
|
+
Name every document the decision reaches, and the skill that owns each, **before** anything is dispatched. A
|
|
127
|
+
list assembled while editing is a list that grows to fit what was already done.
|
|
128
|
+
|
|
129
|
+
| Target | Dispatch |
|
|
130
|
+
|---|---|
|
|
131
|
+
| `.what/_product-brief/` | `wdi-problem` |
|
|
132
|
+
| `.what/_prd/<initiative>/` | `wdi-product` intent `update` |
|
|
133
|
+
| `.what/<pc>/` § Actor Register · § UC Catalogue · `03-domain/domain-model.md` | `wdi-blueprint` intent `catalog` |
|
|
134
|
+
| `.what/business-rules.md` · `.control/product-glossary.md` | `wdi-blueprint` intent `catalog` |
|
|
135
|
+
| `.how/_platform/` — spine, C4, `cross-cutting.md`, the three inventories | `wdi-blueprint` intent `platform` |
|
|
136
|
+
| `.what/<pc>/` slots `02`–`05` — full flows, local rules, lifecycles, scenarios | `wdi-component` intent `behaviour` |
|
|
137
|
+
| `.how/<pc>/` minus `01-ux/` | `wdi-component` intent `design` |
|
|
138
|
+
| `EXPERIENCE.md` · `.how/<pc>/01-ux/` · `design-system.md` | `wdi-ux` |
|
|
139
|
+
| `components.yaml` — a PC born or changed · `mode` · `risk_accepted` · the two structure maps | `wdi-init`, by intent |
|
|
140
|
+
| `specs.yaml`, or anything inside an open spec | `wdi-build` |
|
|
141
|
+
| `.control/questions/` | `wdi-question` |
|
|
142
|
+
| `.control/project-non-technical-log.md` · `.control/meetings/` | `wdi-log` |
|
|
143
|
+
|
|
144
|
+
A target with **no row here** MUST be reported as a gap in the method, not given a plausible owner.
|
|
145
|
+
|
|
146
|
+
Apply in layer order — **`.what/` before `.how/`** — so the lower layer is written against the promise it is
|
|
147
|
+
supposed to serve, not against the one it is about to replace. The retired `layer:` field used to declare that
|
|
148
|
+
order in advance; it is now simply the order.
|
|
149
|
+
|
|
150
|
+
### Step 2 — Dispatch, one owner at a time
|
|
151
|
+
|
|
152
|
+
Hand each owner the `DEC-` id and the exact change its layer has to carry. You MUST NOT restate the decision in
|
|
153
|
+
your own words; **quote it.** A paraphrase drifts, and the drift is invisible because both texts read reasonably.
|
|
154
|
+
|
|
155
|
+
Each owner keeps its own rules — its review, its memlog, its registry entry. You MUST NOT ask an owner to skip
|
|
156
|
+
any of them because the change is small.
|
|
157
|
+
|
|
158
|
+
### Step 3 — Name the gates
|
|
159
|
+
|
|
160
|
+
Run the change-control matrix in `delivery-flow-guide.md` and **report** which gates it names. You MUST NOT
|
|
161
|
+
reopen a gate yourself, and you MUST NOT treat a green application as a gate that has already passed.
|
|
162
|
+
|
|
163
|
+
### Step 4 — Close the trail
|
|
164
|
+
|
|
165
|
+
- Fill `touches:` with the files that were **actually** changed, in the `DEC-` and in `decisions.yaml`. Raise
|
|
166
|
+
`status: applied`. **From that point the file MUST NOT be edited** — not the Decision, not the Cost, not a
|
|
167
|
+
typo in the Why. Documents cite it now.
|
|
168
|
+
- `applied-dec-touches` checks that an `applied` decision names a non-empty `touches`.
|
|
169
|
+
- Regenerate `.control/generated/decisions.md` with `validate.py --generate`. That table is how a decision is
|
|
170
|
+
found now; searching the memlog for decisions is retired, and the memlog is a run log again.
|
|
171
|
+
- Report what changed, and what the decision implied but was **not** changed.
|
|
172
|
+
|
|
173
|
+
## Rules
|
|
174
|
+
|
|
175
|
+
- You MUST NOT widen scope beyond the decision. A neighbouring paragraph that now looks wrong is a finding to
|
|
176
|
+
report, not a change to make.
|
|
177
|
+
- You MUST NOT introduce a new domain noun. If the decision requires one, it goes through `wdi-blueprint` first.
|
|
178
|
+
- If applying would contradict another `applied` decision, you MUST stop and report the conflict. Two applied
|
|
179
|
+
decisions that disagree is work for intent `open`, not something to resolve by preferring the newer one.
|
|
180
|
+
- If the decision is unapplicable as written — the document it names no longer exists, or the change was already
|
|
181
|
+
made differently — you MUST report that instead of improvising.
|
|
182
|
+
- **Apply the whole chain in one pass.** `touches:` names what the decision reaches and the ownership
|
|
183
|
+
table names who lands each part. Edit all of them, then report once. Checking one file, reporting,
|
|
184
|
+
waiting, then checking the next is where the time goes — `corpus-guide.md` § One decided change is one
|
|
185
|
+
edit pass owns the rule.
|
|
186
|
+
- You MUST NOT apply into a spec that is already closed.
|
|
187
|
+
- `AD-N` is a different thing: a living rule with Binds · Prevents · Rule, edited in place. You MUST NOT convert
|
|
188
|
+
one into the other.
|
|
189
|
+
- A decision that emerged from a failed third fix attempt MUST say so in Why. That is the signal
|
|
190
|
+
`wdi-systematic-debugging` exists to raise, and burying it wastes the finding.
|
|
191
|
+
|
|
192
|
+
## Output
|
|
193
|
+
|
|
194
|
+
Intent taken. For `open`: the decision in one sentence, its three required sections, and — for a correction —
|
|
195
|
+
the void assumption in one line plus what the scan found that `bmad-correct-course` could not see. For `apply`:
|
|
196
|
+
every target with its owner, what each owner changed, what was reported instead of changed and why, the gates the
|
|
197
|
+
matrix names, and whether `touches` and `applied` were filled.
|