wdi-method 0.6.30 → 0.6.32

package/kit/skills/wdi-decision/SKILL.md

@@ -1,203 +1,206 @@
----
-name: wdi-decision
-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-.
----
-
-# WDI Decision
-
-Free of stage and free of role: a decision MAY be made at any point by anyone. What is fixed is where its
-output lives — `.control/decisions/DEC-NNN-<slug>.md`, numbered globally from `decisions.yaml`.
-
-Three intents, because deciding, ratifying, and rewriting the documents are three different acts and merging
-them means documents change before anyone approved the change.
-
-| Intent | Does | Who |
-|---|---|---|
-| `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 |
-| `accept` | Raises `draft` → `accepted` | **the Product Owner** — or `wdi-autopilot` under an active mandate, with `accepted_by` naming the mandate |
-| `apply` | Dispatches the owner of every document the decision reaches, checks what came back, fills `touches`, raises `applied` | anyone |
-
-Applying is what **freezes** a decision, not accepting. `decision-guide.md` owns the full ladder and this skill
-MUST NOT restate it.
-
-## The one test, before anything is written
-
-> **If someone asks in three months why it is like this, is the answer readable from the code?**
-
-Yes → it MUST NOT be recorded. No → record it.
-
-**Recording is not mandatory**, and a decision nobody recorded is normal rather than negligence. You MUST NOT
-log it as debt or backfill it later from memory. One case stays mandatory: a decision that **contradicts or
-changes an `AD-N`**.
-
-The old name ADR forced the wrong question — *"is this architectural?"* — and that question threw away exactly
-the decisions most worth keeping, the ones that sound small.
-
-## Intent `open`
-
-### Inputs
-
-Any of these, alone or together: minutes in `.control/meetings/`, an answered question in
-`.control/questions/`, a review or debugging finding, a memlog in `.control/memlog/`, a `wdi-reconcile` conflict.
-
-The memlog is the richest source and the most often forgotten. It is the record of *why* — read it before
-writing the Why section rather than reconstructing the reasoning from the outcome.
-
-### What it writes
-
-Three sections, always: **Decision** (one sentence, present tense, quotable) · **Why** · **Cost** (what becomes
-harder). Alternatives, a reversal trigger, and Trace are required only when the decision reaches a Product
-Component whose `risk_accepted` is `low`; elsewhere an empty one MUST be dropped rather than left as a heading.
-
-Frontmatter carries `touches: []` — empty until applied — and `type:` when it is useful. There is no `layer:`
-and no `component:`; both were classifications demanded before anything was known.
-
-One `type` has a fixed shape: **`mandate`**, the decision `wdi-autopilot` opens at its preflight. Its
-parameters — `from_gate` · `scope` · `parked` · `smoke_test` · `loop` · `expires` — live **only** on its row
-in `decisions.yaml`, under `mandate:`; the file carries Decision, Why, and Cost and points at the row.
-
-A `DEC-` MUST NOT hold an open question. Those go to `wdi-question`.
-
-### A void planning assumption
-
-This is the same intent, with one extra step in front. The trigger is one thing: **a planning assumption turned
-out to be void.** It usually surfaces while building, but its impact reaches back into G2, G3, and G4.
-
-Three things it is **not**:
-
-| Ask | Route |
-|---|---|
-| Something is broken and the cause is unknown | `wdi-systematic-debugging` **first**. A correction built on a guessed cause corrects the wrong thing |
-| A decision exists and documents must follow | intent `apply`. There is no plan to re-cut |
-| Scope grows without invalidating anything | `wdi-product` intent `update`, then the normal flow |
-
-State the void assumption in **one line** before dispatching. A correction whose trigger cannot be stated in one
-line is a re-plan, and it belongs upstream.
-
-Then dispatch `bmad-correct-course`. Do not restate the rules to it — they arrive through `persistent_facts` in
-`_bmad/custom/bmad-correct-course.toml`, including the ban on direct edits. Name the corpus files in scope
-explicitly; it globs its own defaults, which this project does not use.
-
-**Its impact analysis is incomplete by construction** — it knows a PRD and BMad's own planning shapes, and it cannot see
-`.what/<pc>/`, `.how/`, `.control/`, or `.constitution/`. Every one of these MUST be checked here:
-
-| Layer | What to look for |
-|---|---|
-| `.what/_prd/` | The `FR`/`NFR` that no longer holds, and every one depending on it |
-| `.what/<pc>/` | Use cases realising those `FR`, business rules, state lifecycles that lose a state |
-| `.how/_platform/` | An `AD-N` the correction breaks, a container the C4 set no longer describes, an inventory row with nothing behind it |
-| `.how/<pc>/` | Contracts, flows, and Failure Behaviour written against the old promise |
-| the contract | What the spec projected — it MUST NOT be edited to match; it is re-cut |
-| `specs.yaml` | The spec's size, and whether the correction changes it |
-| Ticket files | Which tickets are in progress, and which have not been picked up |
-
-The result is a `DEC-` of **`type: course-correction`**. The `SCP-` code is retired — a course correction is a
-decision, and no second code names the same thing.
-
-A correction cancelling more than **30%** of a spec's tickets MUST NOT be handled as a patch. Say so, and let
-the spec be re-cut through `wdi-build`.
-
-A ticket already in progress MUST NOT have what it asks for changed underneath it. Report it; stopping it and
-returning it to `ready-for-agent` is the coordinator's act.
-
-## Intent `accept`
-
-Only the Product Owner MAY raise a `DEC-` to `accepted`. **An agent MUST NOT accept its own.** When work is
-blocked waiting on one, the block is reported, never resolved by self-approval.
-
-**One delegation, and it is checkable.** Under a `DEC-` of `type: mandate` at `status: accepted` whose
-`expires` has not passed, `wdi-autopilot` MAY accept a decision on the owner's behalf, writing
-`accepted_by: DEC-<mandate>` on the row and `date:` in the file. `mandate-accept` holds the chain: the target is a
-real mandate that **stood** on that date and had not ended by then — expired or superseded, whichever came
-first — and the mandate itself is **never** accepted by delegation.
-That is the one decision whose `accepted_by` is a person and a date, the way `risk_accepted_by` is.
-
-An `accepted` `DEC-` that is still unapplied MAY be corrected in place, with the correction recorded in the
-memlog. Nothing has been built on it, so there is no divergent record to preserve.
-
-## Intent `apply`
-
-**You apply nothing yourself.** Every artifact has an owner, and the owner writes it. A hand-edit here produces
-a change with no author, no input trail, and nothing that verifies it.
-
-Exactly one `DEC-`, at `status: accepted`. You MUST NOT apply one in any other status.
-
-### Step 1 — List the targets before touching one
-
-Name every document the decision reaches, and the skill that owns each, **before** anything is dispatched. A
-list assembled while editing is a list that grows to fit what was already done.
-
-| Target | Dispatch |
-|---|---|
-| `.what/_product-brief/` | `wdi-problem` |
-| `.what/_prd/<initiative>/` | `wdi-product` intent `update` |
-| `.what/<pc>/` § Actor Register · § UC Catalogue · `03-domain/domain-model.md` | `wdi-blueprint` intent `catalog` |
-| `.what/business-rules.md` · `.control/product-glossary.md` | `wdi-blueprint` intent `catalog` |
-| `.how/_platform/` — spine, C4, `cross-cutting.md`, the three inventories | `wdi-blueprint` intent `platform` |
-| `.what/<pc>/` slots `02`–`05` — full flows, local rules, lifecycles, scenarios | `wdi-component` intent `behaviour` |
-| `.how/<pc>/` minus `01-ux/` | `wdi-component` intent `design` |
-| `EXPERIENCE.md` · `.how/<pc>/01-ux/` · `design-system.md` | `wdi-ux` |
-| `components.yaml` — a PC born or changed · `mode` · `risk_accepted` · the two structure maps | `wdi-init`, by intent |
-| `specs.yaml`, or anything inside an open spec | `wdi-build` |
-| `.control/questions/` | `wdi-question` |
-| `.control/project-non-technical-log.md` · `.control/meetings/` | `wdi-log` |
-
-A target with **no row here** MUST be reported as a gap in the method, not given a plausible owner.
-
-Apply in layer order — **`.what/` before `.how/`** — so the lower layer is written against the promise it is
-supposed to serve, not against the one it is about to replace. The retired `layer:` field used to declare that
-order in advance; it is now simply the order.
-
-### Step 2 — Dispatch, one owner at a time
-
-Hand each owner the `DEC-` id and the exact change its layer has to carry. You MUST NOT restate the decision in
-your own words; **quote it.** A paraphrase drifts, and the drift is invisible because both texts read reasonably.
-
-Each owner keeps its own rules — its review, its memlog, its registry entry. You MUST NOT ask an owner to skip
-any of them because the change is small.
-
-### Step 3 — Name the gates
-
-Run the change-control matrix in `delivery-flow-guide.md` and **report** which gates it names. You MUST NOT
-reopen a gate yourself, and you MUST NOT treat a green application as a gate that has already passed.
-
-### Step 4 — Close the trail
-
-- Fill `touches:` with the files that were **actually** changed, in the `DEC-` and in `decisions.yaml`. Raise
-  `status: applied`. **From that point the file MUST NOT be edited** — not the Decision, not the Cost, not a
-  typo in the Why. Documents cite it now.
-- `applied-dec-touches` checks that an `applied` decision names a non-empty `touches`.
-- Regenerate `.control/generated/decisions.md` with `validate.py --generate`. That table is how a decision is
-  found now; searching the memlog for decisions is retired, and the memlog is a run log again.
-- Report what changed, and what the decision implied but was **not** changed.
-
-## Rules
-
-- You MUST NOT widen scope beyond the decision. A neighbouring paragraph that now looks wrong is a finding to
-  report, not a change to make.
-- You MUST NOT introduce a new domain noun. If the decision requires one, it goes through `wdi-blueprint` first.
-- If applying would contradict another `applied` decision, you MUST stop and report the conflict. Two applied
-  decisions that disagree is work for intent `open`, not something to resolve by preferring the newer one.
-- If the decision is unapplicable as written — the document it names no longer exists, or the change was already
-  made differently — you MUST report that instead of improvising.
-- **Apply the whole chain in one pass.** `touches:` names what the decision reaches and the ownership
-  table names who lands each part. Edit all of them, then report once. Checking one file, reporting,
-  waiting, then checking the next is where the time goes — `corpus-guide.md` § One decided change is one
-  edit pass owns the rule.
-- You MUST NOT apply into a spec that is already closed.
-- **Supersession is written on both sides**: `superseded_by` on the retired decision, `supersedes` on the one
-  replacing it. Nothing else about an `applied` decision MAY be touched, and this is the exception — a reader
-  following the old id needs the pointer forward, and for a `type: mandate` that pointer's date is what says
-  when the delegation stopped. Retiring a mandate that accepted decisions without it is a `mandate-accept`
-  finding.
-- `AD-N` is a different thing: a living rule with Binds · Prevents · Rule, edited in place. You MUST NOT convert
-  one into the other.
-- A decision that emerged from a failed third fix attempt MUST say so in Why. That is the signal
-  `wdi-systematic-debugging` exists to raise, and burying it wastes the finding.
-
-## Output
-
-Intent taken. For `open`: the decision in one sentence, its three required sections, and — for a correction —
-the void assumption in one line plus what the scan found that `bmad-correct-course` could not see. For `apply`:
-every target with its owner, what each owner changed, what was reported instead of changed and why, the gates the
-matrix names, and whether `touches` and `applied` were filled.
+---
+name: wdi-decision
+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-.
+---
+
+# WDI Decision
+
+Free of stage and free of role: a decision MAY be made at any point by anyone. What is fixed is where its
+output lives — `.control/decisions/DEC-NNN-<slug>.md`, numbered globally from `decisions.yaml`.
+
+Three intents, because deciding, ratifying, and rewriting the documents are three different acts and merging
+them means documents change before anyone approved the change.
+
+| Intent | Does | Who |
+|---|---|---|
+| `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 |
+| `accept` | Raises `draft` → `accepted` | **the Product Owner** — or `wdi-autopilot` under an active mandate, with `accepted_by` naming the mandate |
+| `apply` | Dispatches the owner of every document the decision reaches, checks what came back, fills `touches`, raises `applied` | anyone |
+
+Applying is what **freezes** a decision, not accepting. `decision-guide.md` owns the full ladder and this skill
+MUST NOT restate it.
+
+## The one test, before anything is written
+
+> **If someone asks in three months why it is like this, is the answer readable from the code?**
+
+Yes → it MUST NOT be recorded. No → record it.
+
+**Recording is not mandatory**, and a decision nobody recorded is normal rather than negligence. You MUST NOT
+log it as debt or backfill it later from memory. One case stays mandatory: a decision that **contradicts or
+changes an `AD-N`**.
+
+The old name ADR forced the wrong question — *"is this architectural?"* — and that question threw away exactly
+the decisions most worth keeping, the ones that sound small.
+
+## Intent `open`
+
+### Inputs
+
+Any of these, alone or together: minutes in `.control/meetings/`, an answered question in
+`.control/questions/`, a review or debugging finding, a memlog in `.control/memlog/`, a `wdi-reconcile` conflict.
+
+The memlog is the richest source and the most often forgotten. It is the record of *why* — read it before
+writing the Why section rather than reconstructing the reasoning from the outcome.
+
+### What it writes
+
+Three sections, always: **Decision** (one sentence, present tense, quotable) · **Why** · **Cost** (what becomes
+harder). Alternatives, a reversal trigger, and Trace are required only when the decision reaches a Product
+Component whose `risk_accepted` is `low`; elsewhere an empty one MUST be dropped rather than left as a heading.
+
+Frontmatter carries `touches: []` — empty until applied — and `type:` when it is useful. There is no `layer:`
+and no `component:`; both were classifications demanded before anything was known.
+
+One `type` has a fixed shape: **`mandate`**, the decision `wdi-autopilot` opens at its preflight. Its
+parameters — `from_gate` · `scope` · `parked` · `smoke_test` · `loop` · `expires` — live **only** on its row
+in `decisions.yaml`, under `mandate:`; the file carries Decision, Why, and Cost and points at the row.
+
+A `DEC-` MUST NOT hold an open question. Those go to `wdi-question`.
+
+### A void planning assumption
+
+This is the same intent, with one extra step in front. The trigger is one thing: **a planning assumption turned
+out to be void.** It usually surfaces while building, but its impact reaches back into G2, G3, and G4.
+
+Three things it is **not**:
+
+| Ask | Route |
+|---|---|
+| Something is broken and the cause is unknown | `wdi-systematic-debugging` **first**. A correction built on a guessed cause corrects the wrong thing |
+| A decision exists and documents must follow | intent `apply`. There is no plan to re-cut |
+| Scope grows without invalidating anything | `wdi-product` intent `update`, then the normal flow |
+
+State the void assumption in **one line** before dispatching. A correction whose trigger cannot be stated in one
+line is a re-plan, and it belongs upstream.
+
+Then dispatch `bmad-correct-course`. Do not restate the rules to it — they arrive through `persistent_facts` in
+`_bmad/custom/bmad-correct-course.toml`, including the ban on direct edits. Name the corpus files in scope
+explicitly; it globs its own defaults, which this project does not use.
+
+**Its impact analysis is incomplete by construction** — it knows a PRD and BMad's own planning shapes, and it cannot see
+`.what/<pc>/`, `.how/`, `.control/`, or `.constitution/`. Every one of these MUST be checked here:
+
+| Layer | What to look for |
+|---|---|
+| `.what/_prd/` | The `FR`/`NFR` that no longer holds, and every one depending on it |
+| `.what/<pc>/` | Use cases realising those `FR`, business rules, state lifecycles that lose a state |
+| `.how/_platform/` | An `AD-N` the correction breaks, a container the C4 set no longer describes, an inventory row with nothing behind it |
+| `.how/<pc>/` | Contracts, flows, and Failure Behaviour written against the old promise |
+| the contract | What the spec projected — it MUST NOT be edited to match; it is re-cut |
+| `specs.yaml` | The spec's size, and whether the correction changes it |
+| Ticket files | Which tickets are in progress, and which have not been picked up |
+
+The result is a `DEC-` of **`type: course-correction`**. The `SCP-` code is retired — a course correction is a
+decision, and no second code names the same thing.
+
+A correction cancelling more than **30%** of a spec's tickets MUST NOT be handled as a patch. Say so, and let
+the spec be re-cut through `wdi-build`.
+
+A ticket already in progress MUST NOT have what it asks for changed underneath it. Report it; stopping it and
+returning it to `ready-for-agent` is the coordinator's act.
+
+## Intent `accept`
+
+Only the Product Owner MAY raise a `DEC-` to `accepted`. **An agent MUST NOT accept its own.** When work is
+blocked waiting on one, the block is reported, never resolved by self-approval.
+
+**One delegation, and it is checkable.** Under a `DEC-` of `type: mandate` at `status: accepted` whose
+`expires` has not passed, `wdi-autopilot` MAY accept a decision on the owner's behalf, writing
+`accepted_by: DEC-<mandate>` on the row and `date:` in the file. `mandate-accept` holds the chain: the target is a
+real mandate that **stood** on that date and had not ended by then — expired or superseded, whichever came
+first — and the mandate itself is **never** accepted by delegation.
+That is the one decision whose `accepted_by` is a person and a date, the way `risk_accepted_by` is.
+
+An `accepted` `DEC-` that is still unapplied MAY be corrected in place, with the correction recorded in the
+memlog. Nothing has been built on it, so there is no divergent record to preserve.
+
+## Intent `apply`
+
+**You apply nothing yourself.** Every artifact has an owner, and the owner writes it. A hand-edit here produces
+a change with no author, no input trail, and nothing that verifies it.
+
+Exactly one `DEC-`, at `status: accepted`. You MUST NOT apply one in any other status.
+
+### Step 1 — List the targets before touching one
+
+Name every document the decision reaches, and the skill that owns each, **before** anything is dispatched. A
+list assembled while editing is a list that grows to fit what was already done.
+
+| Target | Dispatch |
+|---|---|
+| `.what/_product-brief/` | `wdi-problem` |
+| `.what/_prd/<initiative>/` | `wdi-product` intent `update` |
+| `.what/<pc>/` § Actor Register · § UC Catalogue · `03-domain/domain-model.md` | `wdi-blueprint` intent `catalog` |
+| `.what/business-rules.md` · `.control/product-glossary.md` | `wdi-blueprint` intent `catalog` |
+| `.how/_platform/` — spine, C4, `cross-cutting.md`, the three inventories | `wdi-blueprint` intent `platform` |
+| `.what/<pc>/` slots `02`–`05` — full flows, local rules, lifecycles, scenarios | `wdi-component` intent `behaviour` |
+| `.how/<pc>/` minus `01-ux/` | `wdi-component` intent `design` |
+| `.what/experience.md` · `EXPERIENCE.md` · `.how/<pc>/01-ux/` · `design-system.md` | `wdi-ux` |
+| `components.yaml` — a PC born or changed · `mode` · `risk_accepted` · the two structure maps | `wdi-init`, by intent |
+| `specs.yaml`, or anything inside an open spec | `wdi-build` |
+| `.control/questions/` | `wdi-question` |
+| `.control/project-non-technical-log.md` · `.control/meetings/` | `wdi-log` |
+
+A target with **no row here** MUST be reported as a gap in the method, not given a plausible owner.
+
+Apply in layer order — **`.what/` before `.how/`** — so the lower layer is written against the promise it is
+supposed to serve, not against the one it is about to replace. The retired `layer:` field used to declare that
+order in advance; it is now simply the order.
+
+### Step 2 — Dispatch, one owner at a time
+
+Hand each owner the `DEC-` id and the exact change its layer has to carry. You MUST NOT restate the decision in
+your own words; **quote it.** A paraphrase drifts, and the drift is invisible because both texts read reasonably.
+
+Each owner keeps its own rules — its review, its memlog, its registry entry. You MUST NOT ask an owner to skip
+any of them because the change is small.
+
+### Step 3 — Name the gates
+
+Run the change-control matrix in `delivery-flow-guide.md` and **report** which gates it names. You MUST NOT
+reopen a gate yourself, and you MUST NOT treat a green application as a gate that has already passed.
+
+### Step 4 — Close the trail
+
+- Fill `touches:` with the files that were **actually** changed, in the `DEC-` and in `decisions.yaml`. Raise
+  `status: applied`. **From that point the file MUST NOT be edited** — not the Decision, not the Cost, not a
+  typo in the Why. Documents cite it now.
+- `applied-dec-touches` checks that an `applied` decision names a non-empty `touches`.
+- Regenerate `.control/generated/decisions.md` with `validate.py --generate`. That table is how a decision is
+  found now; searching the memlog for decisions is retired, and the memlog is a run log again.
+- Report what changed, and what the decision implied but was **not** changed.
+
+## Rules
+
+- You MUST NOT widen scope beyond the decision. A neighbouring paragraph that now looks wrong is a finding to
+  report, not a change to make.
+- You MUST NOT introduce a new domain noun. If the decision requires one, it goes through `wdi-blueprint` first.
+- If applying would contradict another `applied` decision, you MUST stop and report the conflict. Two applied
+  decisions that disagree is work for intent `open`, not something to resolve by preferring the newer one.
+- If the decision is unapplicable as written — the document it names no longer exists, or the change was already
+  made differently — you MUST report that instead of improvising.
+- **Apply the whole chain in one pass.** `touches:` names what the decision reaches and the ownership
+  table names who lands each part. Edit all of them, then report once. Checking one file, reporting,
+  waiting, then checking the next is where the time goes — `corpus-guide.md` § One decided change is one
+  edit pass owns the rule.
+- You MUST NOT apply into a spec that is already closed.
+- **Supersession is written on both sides**: `superseded_by` on the retired decision, `supersedes` on the one
+  replacing it. Nothing else about an `applied` decision MAY be touched but one trace — appending to
+  `touches` a file the applying commit really changed, in the `DEC-` and in `decisions.yaml`, marked on its
+  line, `decision-guide.md` § *Completing `touches`* — and
+  supersession is the other exception — a reader
+  following the old id needs the pointer forward, and for a `type: mandate` that pointer's date is what says
+  when the delegation stopped. Retiring a mandate that accepted decisions without it is a `mandate-accept`
+  finding.
+- `AD-N` is a different thing: a living rule with Binds · Prevents · Rule, edited in place. You MUST NOT convert
+  one into the other.
+- A decision that emerged from a failed third fix attempt MUST say so in Why. That is the signal
+  `wdi-systematic-debugging` exists to raise, and burying it wastes the finding.
+
+## Output
+
+Intent taken. For `open`: the decision in one sentence, its three required sections, and — for a correction —
+the void assumption in one line plus what the scan found that `bmad-correct-course` could not see. For `apply`:
+every target with its owner, what each owner changed, what was reported instead of changed and why, the gates the
+matrix names, and whether `touches` and `applied` were filled.

package/kit/skills/wdi-explain-to-me/SKILL.md

@@ -6,6 +6,8 @@ disable-model-invocation: true
 
 # WDI Explain To Me
 
+> **Typed by the owner, or not at all.** Run this skill only when the person typed `wdi-explain-to-me` — `/wdi-explain-to-me` or this host's own syntax for it — in the turn that is running. Reached any other way (a description that looked relevant, another skill, a subagent), stop and name it instead. Hosts that can hold a skill to manual-only already do; on the others, this line is the lock.
+
 The owner names a problem. The result is a **decision briefing**: everything needed to decide, with the
 agent doing all of the reading and the owner doing only the deciding.