wdi-method 0.6.30 → 0.6.32

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

@@ -1,162 +1,167 @@
----
-name: wdi-product
-description: Use at G2 Product — when a PRD is created or an existing promise changes. Two intents, prd and update. Checks position, dispatches bmad-prd, verifies the result against prd-guide.md, and lands the memlog. Never writes the PRD itself.
----
-
-# WDI Product
-
-G2 decides **what is built, and how it feels to use.** `bmad-prd` writes the PRD.
-
-This wrapper exists because `bmad-prd` was the only writer of a primary artifact in this method with no WDI
-wrapper at all — so nothing checked its position, nothing verified its result against the guide, and nothing
-landed its memlog where the next run would read it. Those three gaps were paid for at G2 every time.
-
-You MUST NOT write or edit `prd.md` yourself. If a check fails, name what is missing and re-dispatch.
-
-| Intent | When |
-|---|---|
-| `prd` | A functional area a reader would not think to look for in an existing PRD |
-| `update` | Anything else — the default, and by a wide margin |
-
-## Inputs
-
-| Source | What it answers |
-|---|---|
-| `.what/_product-brief/brief.md` | The problem, the primary user, the boundary the PRD MUST respect |
-| `.what/_prd/*/prd.md` | Which initiatives already have a PRD, and what each already promises |
-| `.control/registry/goals.yaml` | The `BG` this initiative serves |
-| `.control/registry/requirements-*.yaml` | Every initiative's `FR`/`NFR`/`UJ`, so the next id continues the product's sequence |
-| `.control/decisions/` | `applied` decisions the PRD MUST already reflect |
-| `.constitution/method/document/prd-guide.md` | The rules the result is checked against |
-| `.control/product-glossary.md` | Terms already fixed |
-
-## Step 1 — Position, and `update` is the default
-
-The decision this skill exists for. The test is the **reader**, not the calendar:
-
-> Would someone looking for this promise open an existing document?
-
-Yes → `update`, however large the change. No → `prd`. A PRD MUST NOT be split because it grew long, and a
-release is never a reason on its own. `prd-guide.md` owns the full table.
-
-Three asks that are not this skill:
-
-| Ask | Route |
-|---|---|
-| The problem itself has changed | `wdi-problem` — a re-cut plan under a wrong problem is wasted work |
-| Only the **wording** of an `FR` is wrong, while the promise is the same | The skill already at work fixes it directly. See below |
-| A planning assumption turned out to be void | `wdi-decision`, which wraps `bmad-correct-course` |
-
-## Step 2 — Wording is not a promise
-
-The split that ended three corrections in "reported but not fixed". `prd-guide.md` owns it; what this skill
-owns is refusing to run for the wrong half.
-
-| What changed | Who does it |
-|---|---|
-| A wrong cross-reference, a retired term, a word inconsistent with an `applied` decision — **the promise is the same** | Whichever skill is already at work. Memlog records it; **one** Revision History row per pass, never one per correction |
-| Scope, the proof of done, an `FR` retired or born | This skill, intent `update` |
-
-You MUST NOT accept a wording correction as an `update` run. Doing so puts a trivial fix behind a gate, and
-that is exactly how the three earlier ones were dropped.
-
-## Step 3 — Dispatch
-
-Invoke `bmad-prd` with the detected intent, scoped to **one initiative**. Do not restate the rules to it —
-they arrive through `persistent_facts` and `doc_standards` in `_bmad/custom/bmad-prd.toml`.
-
-Name the brief and, for `update`, the existing PRD and every `applied` decision that reaches it. The skill
-globs its own default locations, which this project redirects.
-
-## Step 4 — Land the requirements
-
-Each feature's **Realizes:** line cites `FR-N`/`NFR-N` ids. The template gives the statement, the proof
-of done, and the enforcer no home inside `prd.md` any more — write them straight into
-`.control/registry/requirements-<slug>.yaml` — the slug being this PRD's own folder name — on the id's own row, as part of producing this PRD. The `CAP` row goes in the same file: one feature is one capability, and a feature lives in exactly one PRD. This is
-landing, not editing `prd.md`: the same duty `wdi-problem` Step 4 carries for `BG-N`.
-
-An `update` run that adds or changes a promise lands the same way — the registry row changes, the PRD
-keeps citing the id, and Revision History (Step 6 below) records what changed for a reader.
-
-## Step 5 — Verify
-
-| # | Check | Fails when |
-|---|---|---|
-| 1 | Home | Anything outside `.what/_prd/<initiative>/`, or a folder still named `ISI-slug-inisiatif` |
-| 2 | Ids allocated from the registry | `FR-1` restarted, or an id invented in prose |
-| 3 | Every `FR` names its `capability`; every `NFR` names its `goal` | `chain-links` has nothing to check |
-| 4 | Every `FR`'s statement and proof of done, every `NFR`'s statement and `enforced_by`, live only in `requirements-<slug>.yaml` | Full prose written in `prd.md` instead of, or as well as, the registry row from Step 4 |
-| 5 | Cross-Cutting NFRs (§6) and Constraints and Guardrails (§7) both present | An absent section reads as "not checked" |
-| 6 | No solution shape | A framework, a table, or a transport named in `prd.md` rather than in `addendum.md` |
-| 7 | §1 Why This Initiative states a delta against the brief's `Why`, not a restatement of it | The product's own vision written out again on the first PRD |
-| 8 | No Document Purpose, Glossary, Non-Goals, Open Questions, or Assumptions Index section | Any of the five appeared instead of being routed to its real home — see `prd-guide.md` |
-| 9 | One Revision History row for this run, written for someone not in the room | Zero rows, several rows, or a row that says "Updated §4.2" |
-| 10 | Memlog at `.control/memlog/prd-<slug>.md`, slug matching the folder | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
-| 11 | `bmad-review` ran through `doc_standards` on `prd.md` and `addendum.md` | It did not fire |
-
-Check 10 MUST be fixed immediately rather than reported. `memlog-home` rejects a memlog inside the corpus.
-
-## Step 6 — `owns:`, and the collision it prevents
-
-A new or changed `FR` that claims write authority over a domain entity MUST be checked against `owns:` in
-`components.yaml`. An entity has exactly one owning Product Component; an `FR` from another PRD that needs to
-change it MUST point at the owner's `FR` rather than promising to write it itself. `entity-one-writer` checks this, and the
-collision has already happened once for real.
-
-Report a collision. You MUST NOT resolve it by widening one PRD's claim.
-
-## Step 7 — Impact
-
-A changed promise changes what other documents can still claim. Check, and **report** — never edit.
-
-| Found | Where it goes |
-|---|---|
-| A `UC` realising an `FR` whose promise moved | `wdi-component` intent `behaviour`, or `wdi-blueprint` when the catalogue line itself changes |
-| A blueprint inventory row with nothing promising it any more | `wdi-blueprint` |
-| A contradiction with an `applied` decision | `wdi-decision` — a new `DEC-`, never an edit to one already applied |
-| A component born by this initiative | `wdi-init` intent `component` |
-
-Then run the change-control matrix in `delivery-flow-guide.md` and **report** which gates reopen. You MUST
-NOT reopen one yourself.
-
-### Withdrawing a promise — the row stays
-
-A `BG` · `CAP` · `FR` · `NFR` the product stops promising is **marked, never deleted**. Deleting it is
-how a repo ended up with twelve `refs-resolve` findings: two capabilities were withdrawn by decision,
-their rows removed, and eight `DEC-` rows still named them — six of the eight having genuinely served
-them at the time, which `corpus-guide.md` forbids editing away.
-
-1. The withdrawal is a **decision first**. Route to `wdi-decision`; you MUST NOT withdraw a promise on
-   your own authority, and `withdrawn_by` needs that `DEC-` id to point at.
-2. Then mark the row, in place, in its own `requirements-<slug>.yaml`:
-   `status: withdrawn` and `withdrawn_by: DEC-NNN`. Everything else on the row is left as it was — it
-   is a record of what was promised, not a draft.
-3. Withdraw **down the chain in the same pass**: an `FR` under a withdrawn `CAP`, an `NFR` under it,
-   a `UC` satisfying a withdrawn `FR`. `withdrawn-recorded` reports a live row left hanging off a
-   withdrawn one, and that finding is the whole point — a half-withdrawn chain still promises half of
-   something.
-4. The id is **spent**. `id-allocated-once` counts a withdrawn row, so the number is never handed to
-   anything else.
-
-What you MUST NOT do: delete the row, renumber around the gap, or edit a `DEC-` that served it.
-`corpus-guide.md` § *A withdrawn promise STAYS in the registry* owns the rule.
-
-## Rules
-
-- You MUST NOT write a second PRD for an area that already has one. The reader test decides, and its answer
-  is `update` far more often than it feels.
-- You MUST NOT open G2 on a PRD that has not been through check 11. Gate time is for deciding, not
-  proofreading.
-- The gate reads `prd.md` and `EXPERIENCE.md` together. A PRD that passes while the experience side is
-  missing has answered half of what G2 decides.
-- Every unresolved `[ASSUMPTION]` MUST be filed through `wdi-question` before the gate opens.
-- You MUST NOT raise `status:`. Status is a stage; the `reviewed:` block is an event, and `wdi-review` writes
-  it.
-- When the PRD cannot promise what was asked, say so and stop. Route to `wdi-problem`; do not quietly narrow
-  the ask.
-
-## Output
-
-Intent dispatched · what the promise now is in one line · the requirements landed in Step 4 · the result of
-all eleven checks naming the failures · the `owns:` check · impact found and where it was routed · the gates
-the matrix names · open questions filed.
+---
+name: wdi-product
+description: Use at G2 Product — when a PRD is created or an existing promise changes. Two intents, prd and update. Checks position, dispatches bmad-prd, verifies the result against prd-guide.md, and lands the memlog. Never writes the PRD itself.
+---
+
+# WDI Product
+
+G2 decides **what is built, and how it feels to use.** `bmad-prd` writes the PRD.
+
+This wrapper exists because `bmad-prd` was the only writer of a primary artifact in this method with no WDI
+wrapper at all — so nothing checked its position, nothing verified its result against the guide, and nothing
+landed its memlog where the next run would read it. Those three gaps were paid for at G2 every time.
+
+You MUST NOT write or edit `prd.md` yourself. If a check fails, name what is missing and re-dispatch.
+
+| Intent | When |
+|---|---|
+| `prd` | A functional area a reader would not think to look for in an existing PRD |
+| `update` | Anything else — the default, and by a wide margin |
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.what/_product-brief/brief.md` | The problem, the primary user, the boundary the PRD MUST respect |
+| `.what/_prd/*/prd.md` | Which initiatives already have a PRD, and what each already promises |
+| `.control/registry/goals.yaml` | The `BG` this initiative serves |
+| `.control/registry/requirements-*.yaml` | Every initiative's `FR`/`NFR`/`UJ`, so the next id continues the product's sequence |
+| `.control/decisions/` | `applied` decisions the PRD MUST already reflect |
+| `.constitution/method/document/prd-guide.md` | The rules the result is checked against |
+| `.control/product-glossary.md` | Terms already fixed |
+
+## Step 1 — Position, and `update` is the default
+
+The decision this skill exists for. The test is the **reader**, not the calendar:
+
+> Would someone looking for this promise open an existing document?
+
+Yes → `update`, however large the change. No → `prd`. A PRD MUST NOT be split because it grew long, and a
+release is never a reason on its own. `prd-guide.md` owns the full table.
+
+Three asks that are not this skill:
+
+| Ask | Route |
+|---|---|
+| The problem itself has changed | `wdi-problem` — a re-cut plan under a wrong problem is wasted work |
+| Only the **wording** of an `FR` is wrong, while the promise is the same | The skill already at work fixes it directly. See below |
+| A planning assumption turned out to be void | `wdi-decision`, which wraps `bmad-correct-course` |
+
+## Step 2 — Wording is not a promise
+
+The split that ended three corrections in "reported but not fixed". `prd-guide.md` owns it; what this skill
+owns is refusing to run for the wrong half.
+
+| What changed | Who does it |
+|---|---|
+| A wrong cross-reference, a retired term, a word inconsistent with an `applied` decision — **the promise is the same** | Whichever skill is already at work. Memlog records it; **one** Revision History row per pass, never one per correction |
+| Scope, the proof of done, an `FR` retired or born | This skill, intent `update` |
+
+You MUST NOT accept a wording correction as an `update` run. Doing so puts a trivial fix behind a gate, and
+that is exactly how the three earlier ones were dropped.
+
+## Step 3 — Dispatch
+
+Invoke `bmad-prd` with the detected intent, scoped to **one initiative**. Do not restate the rules to it —
+they arrive through `persistent_facts` and `doc_standards` in `_bmad/custom/bmad-prd.toml`.
+
+Name the brief and, for `update`, the existing PRD and every `applied` decision that reaches it. The skill
+globs its own default locations, which this project redirects.
+
+## Step 4 — Land the requirements
+
+Each feature's **Realizes:** line cites `FR-N`/`NFR-N` ids. The template gives the statement, the proof
+of done, and the enforcer no home inside `prd.md` any more — write them straight into
+`.control/registry/requirements-<slug>.yaml` — the slug being this PRD's own folder name — on the id's own row, as part of producing this PRD. The `CAP` row goes in the same file: one feature is one capability, and a feature lives in exactly one PRD. This is
+landing, not editing `prd.md`: the same duty `wdi-problem` Step 4 carries for `BG-N`.
+
+An `update` run that adds or changes a promise lands the same way — the registry row changes, the PRD
+keeps citing the id, and Revision History (Step 6 below) records what changed for a reader.
+
+## Step 5 — Verify
+
+| # | Check | Fails when |
+|---|---|---|
+| 1 | Home | Anything outside `.what/_prd/<initiative>/`, or a folder still named `ISI-slug-inisiatif` |
+| 2 | Ids allocated from the registry | `FR-1` restarted, or an id invented in prose |
+| 3 | Every `FR` names its `capability`; every `NFR` names its `goal` | `chain-links` has nothing to check |
+| 4 | Every `FR`'s statement and proof of done, every `NFR`'s statement and `enforced_by`, live only in `requirements-<slug>.yaml` | Full prose written in `prd.md` instead of, or as well as, the registry row from Step 4 |
+| 5 | Cross-Cutting NFRs (§6) and Constraints and Guardrails (§7) both present | An absent section reads as "not checked" |
+| 6 | No solution shape | A framework, a table, or a transport named in `prd.md` rather than in `addendum.md` |
+| 7 | §1 Why This Initiative states a delta against the brief's `Why`, not a restatement of it | The product's own vision written out again on the first PRD |
+| 8 | No Document Purpose, Glossary, Non-Goals, Open Questions, or Assumptions Index section | Any of the five appeared instead of being routed to its real home — see `prd-guide.md` |
+| 9 | One Revision History row for this run, written for someone not in the room | Zero rows, several rows, or a row that says "Updated §4.2" |
+| 10 | Memlog at `.control/memlog/prd-<slug>.md`, slug matching the folder | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
+| 11 | `bmad-review` ran through `doc_standards` on `prd.md` and `addendum.md` | It did not fire |
+
+Check 10 MUST be fixed immediately rather than reported. `memlog-home` rejects a memlog inside the corpus.
+
+## Step 6 — `owns:`, and the collision it prevents
+
+A new or changed `FR` that claims write authority over a domain entity MUST be checked against `owns:` in
+`components.yaml`. An entity has exactly one owning Product Component; an `FR` from another PRD that needs to
+change it MUST point at the owner's `FR` rather than promising to write it itself. `entity-one-writer` checks this, and the
+collision has already happened once for real.
+
+Report a collision. You MUST NOT resolve it by widening one PRD's claim.
+
+## Step 7 — Impact
+
+A changed promise changes what other documents can still claim. Check, and **report** — never edit.
+
+| Found | Where it goes |
+|---|---|
+| A `UC` realising an `FR` whose promise moved | `wdi-component` intent `behaviour`, or `wdi-blueprint` when the catalogue line itself changes |
+| A blueprint inventory row with nothing promising it any more | `wdi-blueprint` |
+| A contradiction with an `applied` decision | `wdi-decision` — a new `DEC-`, never an edit to one already applied |
+| A component born by this initiative | `wdi-init` intent `component` |
+
+Then run the change-control matrix in `delivery-flow-guide.md` and **report** which gates reopen. You MUST
+NOT reopen one yourself.
+
+### Withdrawing a promise — the row stays
+
+A `BG` · `CAP` · `FR` · `NFR` the product stops promising is **marked, never deleted**. Deleting it is
+how a repo ended up with twelve `refs-resolve` findings: two capabilities were withdrawn by decision,
+their rows removed, and eight `DEC-` rows still named them — six of the eight having genuinely served
+them at the time, which `corpus-guide.md` forbids editing away.
+
+1. The withdrawal is a **decision first**. Route to `wdi-decision`; you MUST NOT withdraw a promise on
+   your own authority, and `withdrawn_by` needs that `DEC-` id to point at.
+2. Then mark the row, in place, in its own `requirements-<slug>.yaml`:
+   `status: withdrawn` and `withdrawn_by: DEC-NNN`. Everything else on the row is left as it was — it
+   is a record of what was promised, not a draft.
+3. Withdraw **down the chain in the same pass**: an `FR` under a withdrawn `CAP`, an `NFR` under it,
+   a `UC` satisfying a withdrawn `FR`. `withdrawn-recorded` reports a live row left hanging off a
+   withdrawn one, and that finding is the whole point — a half-withdrawn chain still promises half of
+   something.
+4. The id is **spent**. `id-allocated-once` counts a withdrawn row, so the number is never handed to
+   anything else.
+
+What you MUST NOT do: delete the row, renumber around the gap, or edit a `DEC-` that served it.
+`corpus-guide.md` § *A withdrawn promise STAYS in the registry* owns the rule.
+
+## Rules
+
+- You MUST NOT write a second PRD for an area that already has one. The reader test decides, and its answer
+  is `update` far more often than it feels.
+- You MUST NOT open G2 on a PRD that has not been through check 11. Gate time is for deciding, not
+  proofreading.
+- The gate reads `prd.md` and the experience together — `.what/experience.md` for what holds across components, the run's `EXPERIENCE.md` for the rest. A PRD that passes while the experience side is
+  missing has answered half of what G2 decides.
+- Every unresolved `[ASSUMPTION]` MUST be filed through `wdi-question` before the gate opens.
+- You MUST NOT raise `status:`. Status is a stage; the `reviewed:` block is an event, and `wdi-review` writes
+  it.
+- When the PRD cannot promise what was asked, say so and stop. Route to `wdi-problem`; do not quietly narrow
+  the ask.
+
+## Step 8 — Record the gate
+
+Ask the owner whether G2 passed. Write `G2` into `gates_passed` only on their explicit *yes* —
+`delivery-flow-guide.md` § *Recording a gate that passed*. `wdi-init` intent `component` reads it next.
+
+## Output
+
+Intent dispatched · what the promise now is in one line · the requirements landed in Step 4 · the result of
+all eleven checks naming the failures · the `owns:` check · impact found and where it was routed · the gates
+the matrix names · open questions filed · whether G2 was recorded.

package/kit/skills/wdi-prune-or-archive/SKILL.md

@@ -6,6 +6,8 @@ disable-model-invocation: true
 
 # WDI Prune or Archive
 
+> **Typed by the owner, or not at all.** Run this skill only when the person typed `wdi-prune-or-archive` — `/wdi-prune-or-archive` 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.
+
 Standalone housekeeping skill for closed specifications. Moves completed spec directories to
 `.archive/specs/<spec-folder>/` or prunes completed tickets from disk using `lifecycle.py`, while
 strictly preserving requirement traceability and RTM metadata in `.control/registry/specs.yaml`.