wdi-method 0.3.0

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

@@ -0,0 +1,183 @@
+---
+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 only** |
+| `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.
+
+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, epics, and stories, 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 |
+| `SPEC.md` | What the wave projected — a SPEC MUST NOT be edited to match; it is re-derived |
+| `waves.yaml` | The wave's size, and whether the correction changes it |
+| Story files | Which stories are `in-progress`, and which are not yet started |
+
+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 wave's stories MUST NOT be handled as a patch. Say so, and let
+the wave be re-cut through `wdi-build`.
+
+A story already `in-progress` MUST NOT have its contract changed. Report it; stopping it and returning it to
+`ready-for-dev` 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.
+
+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 |
+| `waves.yaml`, or anything inside an open wave | `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.
+- V8 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.
+- You MUST NOT apply into a wave that is already closed.
+- `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-help/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: wdi-help
+description: Use when you need to know where the project stands in the delivery flow and which skill comes next. Answers from this project's five gates, not from BMad's phase column.
+---
+
+# WDI Help
+
+`bmad-help` cannot answer "where am I" in this project. Its progress detection globs `output-location`
+paths resolved from `resolve_config.py`, so it is blind to every class-A artifact this project redirects
+into `.what/` and `.how/`. It also lists two required gates — `epics.md` and `sprint-status.yaml` — that
+this project's route never produces, and it is the only BMad skill with no `customize.toml`, so none of
+that can be corrected.
+
+This skill replaces it for position and routing. `bmad-help` remains useful for one thing only: questions
+about BMad itself.
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.control/generated/status` | Which wave is open, which stories sit at which status, which validators are red |
+| `.control/registry/index.yaml` | The global `mode`, and the gate map |
+| `.control/registry/components.yaml` | Per-component `mode`, `risk_accepted`, and `g4_passed` |
+| `.control/registry/waves.yaml` | Wave → release, size, `depends_on` |
+| `.constitution/document/delivery-flow-guide.md` | The five gates and their checklists |
+| `.constitution/method/README.md` | The whole shape, when the caller has never seen the method |
+
+You MUST read `.control/generated/status` rather than counting files yourself. It is generated from the
+registry; hand-counting produces a second answer that will disagree.
+
+## What to answer
+
+Three things, in this order, and nothing else unless asked:
+
+1. **Where the project stands** — the last gate passed, and which gate is next.
+2. **What blocks that gate** — the specific artifact, validator, or blocking question that is not ready.
+3. **Which skill to invoke next** — one skill, named, with its intent, and the reason in a clause.
+
+Keep it under fifteen lines. A routing answer that needs scrolling has failed at its job.
+
+## The one thing that changes the answer
+
+**Read the component's `mode` before routing to G4.** A component at `mode: catalog` skips G4 entirely —
+routing it to `wdi-component` is wrong, and the next step is `wdi-build`. That is the single most common
+mis-route in this flow, because every other gate is the same for every component.
+
+## Routing by what exists
+
+| State | Next |
+|---|---|
+| No registry, or no global `mode` set | `wdi-init` intent `setup` — nothing has started |
+| No `.what/_product-brief/brief.md` | `wdi-problem` — G1 has not started |
+| A brief exists, and no PRD covers the area in play | `wdi-product` intent `prd` |
+| A PRD covers it but the promise has moved | `wdi-product` intent `update` — never a second PRD for the same area |
+| Only the **wording** of an `FR` is wrong | Nobody. Whichever skill is at work fixes it directly; putting it behind a gate is how three earlier corrections were dropped |
+| A PRD exists and the interface is a large part of what it promises | `wdi-ux` — optional, and it lands nothing until a `<pc>` exists |
+| A PRD exists, no `product_components` yet | `wdi-init` intent `component` — the slicing is born here, at the tail of G2 |
+| Components exist, `mode` or `risk_accepted` unset | `wdi-init` intents `mode` and `risk` — both are the owner's, and G4 cannot be read without them |
+| Components exist, no UC catalogue or no spine | `wdi-blueprint` — intent `catalog` first, then `platform` |
+| The blueprint is complete and G3 has not been held | The gate. Read `.control/generated/blueprint.md`, not seven files |
+| G3 passed, a component at `outline`/`guarded`/`deep` has no depth | `wdi-component` |
+| G3 passed, the component is at `mode: catalog` | `wdi-build` — G4 is skipped by design |
+| Depth done and G4 passed for every component the work touches | `wdi-build` — it opens the wave, runs `bmad-spec`, ships each story, closes the wave |
+| A small fix touching no `FR`, `UC`, `AD-N`, or domain model | Fast Path: `bmad-build` directly. It stops and becomes a wave `S` the moment an `FR` is touched |
+| A planning assumption turned out void | `wdi-decision` intent `open` — it proposes, and changes nothing |
+| An accepted `DEC-` has not reached its documents | `wdi-decision` intent `apply` |
+| A bug, a failing test, unexpected behaviour | `wdi-systematic-debugging`, before any fix is proposed |
+| Numbers are wanted before the work is committed | `wdi-report` intent `estimate` |
+
+A brief that exists but is thin is still a brief. You MUST NOT route back to `wdi-problem` because a
+section reads weakly — route there only when the brief is absent, when a change signal invalidates what
+it claims, or when one of its eight required sections is missing outright.
+
+## Rules
+
+- You MUST answer from this project's five gates — G1 Problem · G2 Product · G3 Blueprint · G4 Component ·
+  G5 Release. BMad's `phase` column MUST NOT be used; it mixes two conventions and names gates this
+  project does not run.
+- When a `wdi-*` wrapper exists for a BMad skill, you MUST name the wrapper, never the skill it wraps. The
+  wrapper carries the position check and the content checks; routing past it produces an artifact nothing
+  verifies. Today every BMad skill this method uses has one: `wdi-problem`, `wdi-product`,
+  `wdi-blueprint`, `wdi-build`, `wdi-decision`, `wdi-review`, `wdi-ux`.
+- Only `.control/questions/blocking.md` holds a gate. `external.md` holds go-live and MUST NOT be reported
+  as blocking a design gate; `assumptions.md` holds nothing.
+- You MUST NOT invent progress. If `.control/generated/status` is missing or stale, say so and name
+  `validate.py --generate`.
+- You MUST NOT run other skills on the user's behalf. Name the skill; let them invoke it.
+- When the next step is blocked by a decision rather than by work, route to `wdi-question` or
+  `wdi-decision`, not to a producing skill.
+- When asked about BMad itself — what a BMad skill does, what it writes, which are deprecated — answer
+  from `bmad-skill-register.md`, and only fall back to `bmad-help` for module documentation.
+- When the caller has never seen this method, point at `.constitution/method/README.md` rather than
+  paraphrasing it here.
+
+## When there is no wave open
+
+Say so plainly, then route by the table above. An artifact a later gate produces MUST NOT be reported as
+missing — that is not a gap, it is the plan.

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

@@ -0,0 +1,149 @@
+---
+name: wdi-init
+description: Use for anything that must exist before work can start or continue — scaffolding the registries at install, birthing Product Components after G2, setting or changing a component's mode, setting or reviewing its risk_accepted, and refreshing the two structure maps. Five intents. Never writes .what/ or .how/ content beyond a skeleton.
+---
+
+# WDI Init
+
+Five intents, one skill, because all five answer the same question: **what has to exist before the
+next piece of work makes sense?** A registry row, a folder pair, a depth setting, a risk note, a map
+of where things are.
+
+| Intent | Does | Precondition | How often |
+|---|---|---|---|
+| `setup` | Guide the global `mode` setting · scaffold the registries that are still empty · **report** the documents already present, read-only · derive the two structure maps | before G1 | once per project |
+| `component` | Propose the slicing from the brief plus every PRD · birth what is accepted: registry row plus `SRS`/`SDD` skeletons · propose `mode`, `risk_accepted`, `risk_note`, `owns` | **G2 passed** | each time a component is born |
+| `mode` | Change `mode` — global in `index.yaml`, or one component in `components.yaml`. Guided | — | any time |
+| `risk` | Set or review one component's `risk_accepted`, with disclosure of what it touches | the component exists | any time, usually before G4 |
+| `structure` | Re-derive `.control/structure-codebase.md` and `structure-document.md` from the tree on disk | — | when folders change, and at wave close |
+
+## Two boundaries
+
+- It **does not sort, move, or delete** an existing document. Intent `setup` reports what is there and
+  stops. A file that predates the method enters the corpus only through the skill owning its slot —
+  `corpus-guide.md` owns that rule.
+- Retiring or renaming a Product Component that already carries an SRS **is not its authority**. That
+  goes through `wdi-decision`. Birthing is cheap; retiring is not.
+
+## Intent `setup`
+
+1. Read the tree. Report every document already present, by path, with one line on what it looks like.
+   **Read-only.** You MUST NOT move one.
+2. Scaffold the registry files that carry no rows yet. A file that already has rows MUST NOT be
+   rewritten.
+3. Put the global `mode` to the owner. The default is `catalog`; the four values and what each buys are
+   in `delivery-flow-guide.md`, and MUST NOT be restated here.
+4. Run intent `structure`.
+
+## Intent `component`
+
+1. Read the brief and **every** PRD. A slicing proposed from one PRD is a slicing of one PRD.
+2. Propose the list. The naming rule and the presentation rule live in `corpus-guide.md` — a name that
+   states a layer, a service, or a pattern MUST be rejected at proposal time, and additions, changes,
+   and removals MUST be presented separately with the `FR` behind each.
+3. The owner decides. You MUST NOT register a component the owner has not accepted.
+4. For each accepted birth, write in one act:
+   - the `product_components` row in `.control/registry/components.yaml`, carrying `owns:`
+   - `.what/<pc>/SRS-<pc>.md` from `templates/srs.md`
+   - `.how/<pc>/SDD-<pc>.md` from `templates/sdd.md`
+   - the empty slots each kernel's guide names
+5. Run the disclosure below, then propose `mode` and `risk_accepted` per component.
+
+Content SHOULD stay in the kernel until it grows past roughly 400 lines — a suggestion, not a threshold.
+The first slot to be split out SHOULD be `04-usecases/`; it is always the largest.
+
+**Logical Components are not born here.** An `LC` is born by the skill that draws it — `wdi-component`
+intent `design`, or `wdi-ux` for a screen — and `components.yaml` states the entry shape and the `type`
+→ prose-home mapping in its own header. You MAY report an `LC` that looks wrong; you MUST NOT create
+one.
+
+**Neither is `platform_owns`.** An entity that no component's promise explains belongs to `_platform`,
+and `wdi-blueprint` intent `platform` registers it. You MUST name the candidate and the reason, and you
+MUST NOT claim it — and before naming one, you MUST apply the test in `corpus-guide.md`: ask which `FR`
+would have to be withdrawn for the entity to stop being needed. If that `FR` exists, the entity belongs
+to its component, however platform-shaped the table looks.
+
+## Intents `mode` and `risk` — disclose, then propose
+
+`mode` controls **document depth** and nothing else. `risk_accepted` controls **review intensity** and
+nothing else. Their definitions live in `delivery-flow-guide.md`. What this skill owns is the
+conversation around changing them.
+
+**You do not judge. You disclose, then propose.** Read the `FR` that fall to the component, then name
+what it touches:
+
+- money moving
+- personal data
+- an irreversible action
+- a contractual promise to an outside party
+- a third-party integration that cannot be rolled back
+
+Only after that do you propose `mode` and `risk_accepted`.
+
+Raising or lowering `mode` is **free and needs no justification** — it is a preference, and a preference
+does not have to be defended. Setting `mode: catalog` on a sensitive component requires nothing, as long
+as its review stays hard; that combination is the one the split exists to make sayable.
+
+Two things are not free:
+
+- **`risk_accepted: high` on a component that touches any of the five** requires a `DEC-` of
+  `type: risk-acceptance`, and `risk_accepted_by:` pointing at it. V23 checks this. On a component that
+  touches none of them, `high` is free.
+- **An outside party who will demand the artifacts as a deliverable** — a regulator, an auditor, a
+  client through a contract — puts the touched component at `mode: deep` and `risk_accepted: low`,
+  whatever the global setting says. That floor MUST NOT be traded against a preference: the risk there
+  is not the owner's alone to accept.
+
+> The control is not a veto, it is disclosure. The owner MAY choose fast anywhere, but never without
+> knowing what is being staked.
+
+**Lowering `mode` does not delete anything.** A file already written stops being required, and that is
+all. Deleting it throws away knowledge already paid for, and a lowered `mode` is a preference — not a
+statement that the content was wrong.
+
+**Raising `mode` on a component whose code already runs** produces an **as-built record**, not a design.
+`wdi-component` writes it, under the evidence labels `sdd-guide.md` owns.
+
+## Intent `structure`
+
+The rules for what belongs in a map live in `.constitution/structure-guide.md`. This intent applies
+them; it MUST NOT restate them.
+
+1. **Derive from the tree on disk**, honouring `.gitignore`. A map assembled from what the caller says
+   is there is the failure this intent exists to prevent.
+2. Classify each base folder. For the codebase map the only test is deployability — a **container** runs
+   its own code or stores its own data, a **library** is imported by something else, anything else stays
+   a line in the top-level tree or in a non-unit section. Size and importance MUST NOT decide it.
+   Container headings MUST be **exactly the `built: true` containers** in `components.yaml`: every
+   heading is a registered container, and a `built: false` one MUST NOT get a heading because no code of
+   ours lives in it. The match is one-directional, and reading it both ways makes it unsatisfiable.
+3. Draw the convention, not the contents. A shape that repeats MUST be written once with a placeholder.
+4. Mark key files `★` by the four tests in the guide. Borderline files are left out.
+5. Write from `templates/structure-codebase.md` and `templates/structure-document.md`. Template comments
+   and the skeleton block MUST be deleted from the finished file.
+6. Stamp `Verified` with the date and the commit SHA the tree was read at.
+7. Report drift, unclaimed folders, and one-sided Product Components separately. This intent MUST NOT
+   fix them.
+
+It MAY be run **read-only** — derive, report the drift, write nothing. That is the right mode when the
+caller is unsure: a map is cheap to check and expensive to get wrong.
+
+A hand-edited map MUST be treated as drift: re-derive, then say what the hand edit claimed that the tree
+does not support.
+
+## Rules
+
+- You MUST NOT write `.what/` or `.how/` content beyond a skeleton and its frontmatter. Behaviour is
+  `wdi-blueprint` and `wdi-component`; mechanism is `wdi-component`.
+- You MUST NOT write into `.constitution/`.
+- You MUST NOT fill `mode` or `risk_accepted` with a value the owner has not confirmed. Both are the
+  owner's, and a proposal recorded as a decision is the one failure disclosure cannot survive.
+- You MUST NOT create a Product Component because a folder would look tidy. A PC no `FR` points at is a
+  folder with nothing inside it.
+- You MUST NOT put database column types in `03-domain/`. That slot holds the conceptual domain model.
+
+## Output
+
+Intent taken · what was scaffolded, proposed, or refreshed · for `component`, the slicing with the `FR`
+behind each row and what the owner accepted · for `mode` and `risk`, what was disclosed before the
+proposal · for `structure`, the drift found and what was left unfixed.

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

@@ -0,0 +1,107 @@
+---
+name: wdi-log
+description: Use when a fact from outside the code has to be recorded — a meeting that finished, or a non-technical fact that constrains what may be built. Two intents, meeting and fact. Routes decisions and open questions to their own skills.
+---
+
+# WDI Log
+
+Free of stage and free of role. Two intents, because both record **a fact that came from outside the code** and
+neither belongs to any gate.
+
+| Intent | Owns | Home |
+|---|---|---|
+| `meeting` | What a meeting decided and left open | `.control/meetings/YYYY-MM-DD-<slug>.md` |
+| `fact` | A non-technical fact that constrains what may be built, used, or promised | `.control/project-non-technical-log.md` |
+
+They share a shape and a failure mode: both are tempting places to record something that belongs somewhere with
+an owner. Neither MAY absorb a decision or an open question.
+
+## Intent `meeting`
+
+### What the note MUST carry
+
+| Section | Content |
+|---|---|
+| Attendees and date | Who was actually there, not who was invited |
+| What was decided | Each decision as one sentence, stated as what now holds |
+| What was left open | Each unresolved item, with who can resolve it |
+| Action items | Grouped by role, each with an owner |
+| `## DEC` | Links to the decisions this meeting produced — filled after `wdi-decision` runs |
+
+The `## DEC` back-link makes the trail run both ways. Minutes whose decisions have no `DEC-`, and a `DEC-` with
+no minutes behind it, are both traceability gaps the audit surfaces later at a worse time.
+
+### Rules
+
+- It MUST NOT write the decision itself. That goes to `wdi-decision` intent `open`, which numbers it globally.
+  Minutes say what was **discussed**; a `DEC-` says what was **chosen** and what it cost.
+- It MUST NOT write to `.what/` or `.how/`. A meeting changes documents only through `wdi-decision` intent
+  `apply`.
+- It MUST NOT record an open question only in the note. Those go to `wdi-question`, so they land in one of four
+  lists rather than scattered across meetings nobody rereads.
+- Record what was decided, not what was discussed. A transcript is not minutes, and nobody rereads one.
+- A decision recorded with no owner and no consequence MUST be treated as an open question instead. "We agreed
+  to look into it" is not a decision.
+- Client commitments MUST be recorded verbatim where the wording matters. Paraphrasing a commitment is how a
+  scope dispute starts.
+
+## Intent `fact`
+
+`.control/project-non-technical-log.md` is the authority on **what may be recorded** — its content boundary, its
+closed category list, and the table of facts belonging to another home. Read it before acting; this skill MUST
+NOT restate those rules and MUST NOT override them. What this skill owns is **how** the file is read and written.
+
+### Looking one up
+
+1. Read the Berlaku table in full. It is short by design and MUST NOT be sampled with grep alone — a fact retired
+   last week reads as current when only its row is seen.
+2. Check Tidak Berlaku Lagi for the same subject. A superseded entry names its replacement.
+3. If the answer is absent, **say it is absent.** You MUST NOT infer a fact from a commit message, from
+   `.control/memlog/`, or from a sibling repo and report it as recorded — those are leads for registering, not
+   answers.
+
+An entry marked `[BELUM DIKONFIRMASI]` MUST be reported with that tag attached, never flattened into a plain
+fact.
+
+### Registering one
+
+1. Apply the log's content boundary first. A fact that fails it is refused here and MUST NOT be softened to fit —
+   say which rule refused it and where it belongs.
+2. **Route before writing.** If the fact is a decision expensive to reverse, an open question, a meeting outcome,
+   a domain term, or an infrastructure asset detail, its own skill or repo runs first. A row here MAY then hold
+   only the consequence for this product, pointing at that home.
+3. Assign the next `NT-NNN` from the highest id ever used, including retired ones. An id MUST NOT be reused.
+4. Fill every column. `Akibat` MUST name something in this repo — a gate, an `FR`, a prerequisite, a file.
+   `Sumber` MUST name a person, a repo and path, or another entry id.
+5. A fact whose source is hearsay MUST be written with `[BELUM DIKONFIRMASI]` **and** filed through
+   `wdi-question` in the same run. Recording it and leaving it unowned is the failure this step exists to stop.
+
+**One fact, one row.** A single event producing several facts — a domain bought, and a launch date it makes
+possible — MUST become several rows, because they stop holding at different times.
+
+### Updating one
+
+A fact that changed is **never** edited in place, and its row is never deleted.
+
+1. Move the old row to Tidak Berlaku Lagi, filling `Berhenti berlaku` with the date and `Digantikan` with the new
+   id.
+2. Register the new fact as a fresh `NT-NNN`.
+3. Follow the old row's `Akibat` and check whatever it named. A fact that stops holding usually leaves a document
+   behind that still assumes it; that document MUST be raised, and if it sits under an `applied` decision, routed
+   to `wdi-decision` intent `apply`.
+
+Correcting a typo or a wrong `Sumber` is not an update in this sense and MAY be edited in place.
+
+## Rules
+
+- Terms MUST match `.control/product-glossary.md`. A note that coins a new domain noun MUST propose it through
+  `wdi-blueprint`, not leave two words meaning the same thing.
+- This skill MUST NOT write any file other than the two it owns. Every other file it touches is reached through
+  the skill that owns it.
+- `.control/structure-document.md` MUST NOT be edited to reflect a new entry — it maps folders, not rows, and
+  `wdi-init` intent `structure` re-derives it.
+
+## Output
+
+Intent taken · what was recorded, in one line · what was **routed** rather than recorded, and to which skill ·
+for `fact`, the `NT-` id and what its `Akibat` names.

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

@@ -0,0 +1,90 @@
+---
+name: wdi-problem
+description: Use at G1 Problem — when the product brief is created, updated, or validated. Checks position and preconditions, dispatches bmad-product-brief, then verifies the result against brief-guide.md and the template. Never writes the brief itself.
+---
+
+# WDI Problem
+
+G1 decides **what the problem is, whose it is, and why it earns work.** `bmad-product-brief` writes the
+brief; this skill decides whether it should run at all, hands it the right intent, and checks what came
+back. Both halves matter: the override TOML controls **where** the artifact lands, and nothing in BMad
+checks **what is in it**.
+
+You MUST NOT write or edit `brief.md` yourself. If a check fails, name what is missing and re-dispatch — a
+hand-patched brief makes the memlog lie about how it got that way.
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.what/_product-brief/brief.md` | Whether a brief already exists, and what intent applies |
+| `.constitution/document/brief-guide.md` | The rules the result is checked against |
+| `.constitution/document/templates/brief.md` | The required shape |
+| `_bmad-output/brainstorming/` · `forge/` · `planning-artifacts/` | Raw material available to feed in |
+| `.control/product-glossary.md` | Terms already fixed, so the brief does not invent competing ones |
+
+## Step 1 — Position
+
+- If `brief.md` exists, the intent is **update** or **validate**, never **create**. A second create would
+  overwrite the singleton.
+- If a wave is open and the ask is a scope change rather than a problem change, this is the wrong skill.
+  Route to `wdi-decision`, which wraps `bmad-correct-course`.
+- If the ask is about one initiative rather than the product, route to `wdi-product`.
+
+## Step 2 — Preconditions
+
+None of these block. Each is a question you MUST put to the owner before dispatching, once.
+
+| Check | Why it matters |
+|---|---|
+| Is there raw material worth feeding in? | Exploration output in `_bmad-output/` is invisible to the skill unless it is named |
+| Does the claim rest on outside data? | Market size, competitor, stack choice — those want `bmad-deep-recon` first |
+| Is the primary user already obvious? | If not, discovery is not finished and the brief will stall at the gate |
+
+## Step 3 — Dispatch
+
+Invoke `bmad-product-brief` with the detected intent. Do not restate the rules to it — they arrive through
+`persistent_facts` and `doc_standards` in `_bmad/custom/bmad-product-brief.toml`. Repeating them here would
+create a second copy that drifts.
+
+Name the raw-material files explicitly in the handoff. The skill globs its own output locations, and this
+project redirects them.
+
+## Step 4 — Verify
+
+Check the returned brief against the guide. Report every failure; fix none of them by hand.
+
+| # | Check | Fails when |
+|---|---|---|
+| 1 | Home | Anything landed outside `.what/_product-brief/` |
+| 2 | Eight required sections present | The template's "drop what does not earn its place" was applied to one of them |
+| 3 | Exactly one `primary` in Who This Serves | Zero, or more than one |
+| 4 | Goals numbered `BG-N` | Numbered `G1`–`G4`, which collides with the gates |
+| 5 | Scope Out written as items | Left implicit |
+| 6 | Memlog at `.control/memlog/brief.md` | A `.memlog.md` appeared inside `.what/` — `--workspace` was used |
+| 7 | No raw material folded in | Research or brainstorming prose copied into the brief instead of cited |
+| 8 | No Product Component list | A slicing was written at G1; it belongs to `wdi-init` intent `component`, after G2 |
+| 9 | `bmad-review` structure + prose ran | `doc_standards` did not fire |
+
+Check 6 MUST be fixed immediately rather than reported. A `.memlog.md` inside `.what/` is corpus pollution,
+and every later run compounds it.
+
+## Rules
+
+- You MUST NOT land anything from `_bmad-output/` into the corpus beyond the brief itself. Every other
+  output has its owner in the table in `corpus-guide.md`, and for exploration output the answer is that it
+  stays put.
+- You MUST NOT delete an exploration run folder after feeding it in. The `update` intents re-read the
+  original inputs.
+- You MUST NOT open G1 on a brief that has not been through check 9. Gate time is for deciding.
+- A brief concluding the idea is not worth building is a **pass**. You MUST report it as one rather than
+  offering to rework it.
+- Every unresolved `[ASSUMPTION]` MUST be filed through `wdi-question` before the gate opens — into
+  `assumptions.md` by default, `blocking.md` only through the three tests that file states.
+- When the ask is about the Product Component slicing, this is the wrong skill at any point. Before the list
+  exists it belongs to `wdi-init` intent `component`; after G3 a correction goes through `wdi-decision`.
+
+## Output
+
+A short report: intent dispatched, what the brief now claims in one line, and the result of all nine checks
+— naming the failures, not summarising them away.