wdi-method 0.3.0

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

@@ -0,0 +1,203 @@
+---
+name: wdi-blueprint
+description: Use at G3 Blueprint — the one whole-product portrait, written once. Two intents, catalog and platform. Owns the use case catalogue, actors, domain model, cross-component business rules, the glossary, the spine, C4, cross-cutting, and the three inventories. Never writes a single component's depth.
+---
+
+# WDI Blueprint
+
+G3 decides **the whole portrait of the system**: which use cases exist, their entities, their tables, their
+endpoints, their screens, and the invariants that bind everything built from them. Once per product.
+
+Two intents, run in this order:
+
+| Intent | Writes | Wraps |
+|---|---|---|
+| `catalog` | Per `<pc>`: § Actor Register · § UC Catalogue · `03-domain/domain-model.md`. Product level: `.what/business-rules.md` · `.control/product-glossary.md` · `usecases.yaml` | — |
+| `platform` | `.how/_platform/`: the spine · C4 L1/L2/L3 · `cross-cutting.md` · the three inventories. Registry: `containers` | `bmad-architecture` |
+
+**Blueprint content is untouched by `mode` and by `risk_accepted`.** Everything above exists at every mode,
+including `catalog`. That is what keeps the order non-circular: `mode` is first needed at G4.
+
+You MUST NOT write a single component's depth — full UC flows, local rules, failure behaviour, contracts. All
+of that is `wdi-component` at G4. You MUST NOT write a promise; when the blueprint proves a PRD wrong, that is
+`wdi-product`, not a quiet edit here.
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.what/_product-brief/brief.md` | The problem, the primary user, the boundary the portrait MUST respect |
+| `.what/_prd/*/prd.md` — **every one** | Every promise made: the `FR`/`NFR` the portrait has to cover |
+| `.control/registry/components.yaml` | Which components exist, and their `owns:` |
+| `.control/product-glossary.md` | Terms already fixed |
+| `.control/decisions/` | `accepted` and `applied` decisions an `AD-N` usually sits behind |
+| `src/` · `web/` | What actually runs, when this is not a new project |
+| `.constitution/document/srs-guide.md` · `architecture-guide.md` | The rules the result is checked against |
+
+## Step 1 — Position
+
+- The components MUST already exist. If `components.yaml` holds no `product_components`, route to `wdi-init`
+  intent `component` — the slicing is born at the tail of G2, from the brief plus every PRD.
+- `catalog` runs before `platform`. The spine is written against a portrait that exists.
+- If the spine and C4 set already exist, `platform` is an **amendment**, never a create. A second create
+  overwrites what three waves of annotation put there.
+- If the ask is one component's mechanism or its full flows, route to `wdi-component`.
+- If the ask is what the product promises, route to `wdi-product` — an invariant is not a promise.
+
+## Step 2 — Intent `catalog`, in order
+
+The order is binding, and each step is the input to the next. Writing them out of order produces use cases
+whose nouns nobody defined.
+
+1. **Glossary.** Every domain noun, into `.control/product-glossary.md`, alphabetically, each citing the
+   document and section its definition came from. You MUST NOT invent a definition — cite a source, or route
+   the term to `wdi-question`. Two words meaning one thing is **drift**, and it MUST be resolved to one word
+   in the same pass, with the losing synonym corrected in the documents that use it.
+2. **UC Catalogue**, per component. One line per use case: `UC-N` · title · actor · the `FR` it satisfies ·
+   `critical` yes/no. A title MUST be a sentence a user would say, not a system term.
+3. **Actor Register**, per component. It stays in the SRS kernel; it is the SSOT the SDD mirrors.
+4. **Domain model** — entities, relations, columns — into `.what/<pc>/03-domain/domain-model.md`. Conceptual;
+   database column types belong to `.how/`.
+5. **Cross-component business rules** into `.what/business-rules.md`. A rule binding only one component is
+   G4 work and MUST NOT be written here.
+
+`critical` means the use case touches **money, personal data, or an irreversible action**. Nothing else. If
+the count passes a third of a component's use cases, derive it again — `delivery-flow-guide.md` owns the rule
+and it MUST NOT be negotiated.
+
+**A method term MUST NOT be written into `.constitution/method-glossary.md`.** A product term binds one
+project; a method term binds every project the method is installed in. Raise it as a proposal, state where it
+appeared and why the existing vocabulary does not cover it, and hand it to the owner.
+
+## Step 3 — Parallel where there is a key, serial where there is not
+
+This is not theory. In the previous run, 41 cross-component business rules from seven parallel agents had to
+be merged and de-duplicated **serially**, because the target file had no key — and that merge was the most
+expensive part of the pass.
+
+> Parallel fan-out is only for output with a natural key. Output that is a shared list with no key MUST be
+> written by one agent that reads the whole input.
+
+| Work | Parallel? | Key |
+|---|---|---|
+| UC catalogue, actors, entities per component | yes | Product Component |
+| Glossary, cross-component business rules, the spine | **no** | there is none |
+| The three inventories | yes, one agent per source | table · endpoint · screen |
+
+Three guards when running parallel: each agent writes only its own keyed file; shared files are written in one
+serial pass afterwards; the owner reviews the merged result, not N agent reports. Open questions from N agents
+arrive as **one** ranked batch.
+
+## Step 4 — Intent `platform`
+
+Dispatch `bmad-architecture` at **initiative** altitude for the spine. Do not restate the rules to it — they
+arrive through `persistent_facts` in `_bmad/custom/bmad-architecture.toml`, which installs
+`architecture-guide.md` there rather than as `doc_standards` deliberately.
+
+Then verify and land:
+
+| # | Check | Fails when |
+|---|---|---|
+| 1 | Home | The spine landed anywhere but `.how/_platform/ARCHITECTURE-SPINE.md` |
+| 2 | Every `AD-N` carries Binds, Prevents, and Rule | One is blank — an `AD-N` with no Prevents is a preference |
+| 3 | Every `AD-N` is an invariant | Breaking it in one component would not break another. It is a seed, and MUST be marked as one |
+| 4 | Stack, tree, and data shapes marked as seeds | Written as contracts, which makes the spine wrong at the first upgrade |
+| 5 | No alternatives or cost in the spine | Those live in the `DEC-` behind it; a second copy drifts |
+| 6 | Nothing but invariants | A statement affecting one component only — that is its SDD |
+| 7 | Memlog at `.control/memlog/spine.md` | A `.memlog.md` appeared inside `.how/` — `--workspace` was used |
+
+Check 7 MUST be fixed immediately. V16 rejects a memlog inside the corpus.
+
+**Land the C4 set by amending, never overwriting.** The files are living and already carry annotations,
+including a pre-method provenance note that MUST survive. When the incoming set contradicts an annotation
+already there, you MUST stop and report it, and MUST NOT resolve it by preferring the newer drawing. Where a
+C4 file and the spine disagree, the spine wins and the disagreement MUST be reported. One
+`c4-l3-<container>.md` per `built: true` container **holding more than one Product Component**. A
+`built: false` container gets no L3 at all, and a one-PC container needs none because the L2 matrix already
+places it. **Not one of the three waits for a wave** — `architecture-guide.md` owns that.
+
+**Register the containers** in `containers:` in `components.yaml`, in the same act as landing the L2. It is
+not a follow-up, and it unblocks everyone else: an `LC` MUST name its container.
+
+Each container MUST carry `built:` — `true` when we write what is inside it, `false` when we deploy
+someone else's implementation. It decides whether the container gets an L3, an `LC`, and a heading in the
+codebase map (V25). Something whose **runtime we do not deploy** is an external system: it belongs at L1,
+and registering it here promises a codebase-map section that will never exist.
+
+**Fill each PC's `containers:` in the same act, and land the matrix at L2** — the registry is the SSOT and
+the L2 table renders it. A PC MUST list every `built: true` container it lives in; listing only the main
+one is the error the matrix exists to catch. Complete for every PC at G3, untouched by `mode`.
+
+You MUST NOT register a
+`product_component` or a `logical_component`.
+
+**Register what `_platform` owns** in the same pass — a domain entity through `platform_owns`, an inventory
+row through that inventory's `platform_rows:`, an `LC` through its `component:`. The test is in
+`corpus-guide.md` and both halves MUST hold. Each one MUST then be described under `## Milik platform` in
+`cross-cutting.md`, in the same act: V21 checks that second half, because owning something without
+documenting it is taking ownership without taking responsibility.
+
+A judgement the pattern cannot derive MUST live in the artifact it governs, not in a script and not in a
+skill: an inventory's `platform_rows:` and `states:` are declared in that inventory's own frontmatter, so
+re-derivation preserves them. Anywhere else, the next run deletes the owner's decision.
+
+`_platform` is **not** a Product Component. You MUST NOT give it a `mode`, a `risk_accepted`, an SRS, or a
+G4, and you MUST NOT move an entity there because its owner is hard to decide.
+
+## Step 5 — The three inventories
+
+They land in `.how/_platform/` with **one owner: this skill.** No negotiation with `wdi-ux`, and no second
+copy inside any SDD.
+
+| State | How each is born |
+|---|---|
+| No code yet | Written as a **plan** — the tables, endpoints, and screens intended. Nothing can be derived, because there is no source |
+| Code exists | **Derived first** by `.constitution/scripts/inventory.py` — migrations for tables, route registration for endpoints, pages for screens — then compared with the plan. The difference is a **finding**, not hand work |
+
+An inventory MUST NOT be assembled from a README or from route names that look plausible. Numbers are stable:
+a new row takes the next number, never a renumber.
+
+## Step 6 — The roll-up, and what the owner actually reads
+
+Regenerate `.control/generated/blueprint.md` with `validate.py --generate`. It assembles the UC catalogue, the
+actor lists, the domain model, and the three inventories into **one page**.
+
+**That page is what G3 reviews** — not seven files. The catalogue and actors stay in their component kernels as
+their permanent home; the roll-up is a view. One fact, one home, one view.
+
+You MUST NOT hand-write anything under `.control/generated/`.
+
+## Step 7 — Review and questions
+
+- No `doc_standards` fires for an SRS or for the spine. Dispatch `wdi-review`, which reads the lens set from
+  each component's `risk_accepted`.
+- You MUST NOT open G3 on a portrait that has not been through it.
+- Every unresolved to-be-confirmed MUST be filed through `wdi-question`, in **one** ranked batch — into
+  `assumptions.md` by default, `blocking.md` only through its three tests.
+- A decision surfacing while writing goes to `wdi-decision`, never into the document as a parenthetical.
+- An `AD-N` that reverses or narrows an earlier one MUST go through `wdi-decision` first. Editing an `AD-N` in
+  place is how a reversal happens with nobody deciding it.
+
+## Step 8 — A PRD that arrives after G3
+
+The blueprint is **living and amended**, not repeated. `wdi-init` intent `component` births the new
+components, this skill adds their rows to the catalogue and the three inventories, and **G3 reopens over the
+delta only**. The 45-minute session does not run again for one additional initiative.
+
+## Rules
+
+- You MUST NOT write into `.how/<pc>/`, and `design-system.md` in `_platform/` belongs to `wdi-ux`.
+- You MUST NOT regenerate the C4 set from scratch. The loss of annotations is invisible in a diff that reads
+  as a rewrite.
+- You MUST NOT raise `status:`. Status is a stage; the `reviewed:` block is an event.
+- You MUST NOT write a definition into `.constitution/` at all — not the method glossary, not a guide.
+- When the portrait cannot be drawn because a PRD has not settled what it must cover, say so and stop.
+- Memlog: one per Product Component at `.control/memlog/<pc>.md`, plus `.control/memlog/spine.md` for
+  `platform`, through `memlog.py --path`. `--workspace` MUST NOT be used.
+
+## Output
+
+Intents run · the catalogue and inventories as counts, per component · glossary terms written, proposed, and
+rejected with the rule that rejected each · the `AD-N` that are new or changed · what was amended in the C4
+set and what contradicted it · containers registered · plan-versus-code differences reported · whether the
+roll-up regenerated and `wdi-review` ran · the one ranked batch of questions.

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

@@ -0,0 +1,244 @@
+---
+name: wdi-build
+description: Use at G5 Release — one wave from open to closed in one supervised run. Opens the wave, runs bmad-spec, ships every story to a green PR through a five-step pipeline, then closes the wave. One invocation, not four.
+---
+
+# WDI Build
+
+One unit of work, one invocation. A wave used to need four calls — open it, run `bmad-spec`, ship each story,
+close it — and three of those were bookkeeping. They are all in here now, because a unit of work that needs
+four invocations gets three of them skipped.
+
+**REQUIRED SUB-SKILL:** MUST dispatch, wait, and escalate through `orchestration`. Worker CLI/model/effort MUST
+come from the Orca Agent Dispatch tables in the user's Agent Rules; this skill MUST NOT restate them.
+
+The coordinator (this session) holds every judge call, the registries, and every remote git action. Dispatched
+workers hold the spec and the code.
+
+## Precondition, and the one that is easy to miss
+
+| Check | When it fails |
+|---|---|
+| Every component this wave touches has passed G4, **or** sits at `mode: catalog` | Route to `wdi-component`. V22 checks it, and `catalog` skipping G4 is by design, not an exception |
+| An isolated worktree | Isolate first. MUST NOT run in a shared checkout |
+| Every `prd` slug names a real `.what/_prd/<initiative>/` folder | A wave without a promise covering it is a wave nobody agreed to (V17) |
+
+The repo commits straight to `main` and opens a PR only when asked. **Invoking this skill is that ask**, for
+this wave only; it MUST NOT be read as standing permission for the next change.
+
+## Phase 1 — Open the wave
+
+Record it in `.control/registry/waves.yaml`:
+
+| Field | Rule |
+|---|---|
+| `id` | `W<N>`, monotonic, never reused |
+| `release` | MUST be stated. The release↔wave cadence is situational and MUST NOT be inferred from numbering (V17) |
+| `prd` | MUST be stated: which initiative PRDs this wave delivers against. MUST NOT be derived from `release` |
+| `fr` | The `FR` this wave satisfies. Ideally one — an `FR` is human-testable from birth |
+| `size` | `S` · `M` · `L`. MAY be raised mid-flight; MUST NOT be lowered |
+| `depends_on` | At **wave** level. A wave declaring none runs in parallel with its neighbours |
+| `spec_folder` | One per wave, not one per wave × component |
+| `epics` → `stories` | With `satisfies: [UC]`, `depends_on`, `touches`, and test names |
+
+Story **status** MUST NOT be copied into `waves.yaml`. It is read from story-file frontmatter when
+`.control/generated/` regenerates (V18). Two homes for one fact is how registries start lying.
+
+Size does not choose which gates are active — that is `mode`'s job. It governs session merging (`S` merges G4
+and G5 into one 20-minute session) and whether the retrospective runs (`L`).
+
+## Phase 2 — The SPEC
+
+Dispatch `bmad-spec` for the wave, slug `w<N>-<slug>`. **One wave = one `SPEC` = one tracker Task**, with no
+compound joins.
+
+`SPEC.md` is a **projection** of `.what/` + `.how/` onto this wave and MUST NOT introduce anything new. When it
+needs something that is not in either, the gap is upstream: route to `wdi-component` or `wdi-blueprint`, and do
+not let the SPEC invent it.
+
+`SPEC.md` and story files **are not read by humans.** Both are machine contracts, and no review burden MAY be
+moved onto them. `wdi-review` MAY still be dispatched over the SPEC; its trace lands on the wave in
+`waves.yaml`, because `bmad-spec` is the sole author of the file and overwrites hand edits.
+
+## Phase 3 — Ship each story
+
+Steps 1–2 run `bmad-build-auto` under **folder+id dispatch**: the coordinator supplies `spec_folder` and
+`story_id`, and the worker resolves everything else from `{spec_folder}/stories.yaml` and `SPEC.md`.
+
+| # | Step | Engine | Exit condition |
+|---|---|---|---|
+| 1 | Plan | `bmad-build-auto` + `Halt after planning.` | Spec frontmatter reads `status: ready-for-dev` |
+| 2 | Build | `bmad-build-auto` given the spec path | Spec frontmatter reads `status: done` |
+| 3 | Panel | `bmad-code-review` | Panel adjudicated, zero unresolved must-fix |
+| 4 | Publish | — | Branch pushed, PR open, story-closing checklist answered |
+| 5 | CI | — | All checks conclude green on the pushed head SHA |
+
+### Engine rules
+
+- MUST judge a step from the spec's frontmatter `status`. A worker's chat report MUST NOT settle it.
+- Every step MUST go to a **fresh** worker, and a fix round MUST NOT go back to the worker that produced the
+  code. The spec carries everything the next worker needs, and inherited context is how a step stops judging
+  the artifact on its own merits.
+- MUST launch every worker with its Unattended flag, and MUST confirm each started from observed activity —
+  never from a readiness match alone.
+- MUST NOT dispatch to a CLI that cannot spawn subagents. `blocked / no subagents` is a CLI capability failure,
+  not a story failure: re-dispatch the same step on the other CLI in that row.
+- MUST NOT reorder or drop a step. A step with nothing to do MUST be reported as such, not skipped silently.
+- A spec already at `status: blocked` MUST be repaired and its status reset before re-dispatch.
+
+### What every worker brief MUST carry
+
+Three rules this corpus adds. All three MUST be stated in the dispatch of any step that writes code.
+
+- **Debugging is conditional, never a phase.** When a test or build fails and the cause is not known, the
+  worker MUST run `wdi-systematic-debugging` before proposing any fix. A third failed fix attempt is the signal
+  to escalate, not to try a fourth.
+- **The corpus is not the worker's to change.** A worker MUST NOT edit `.what/`, `.how/`, or an `applied`
+  `DEC-`. A deviation from the SDD or an `AD-N` is **reported**, and it becomes a `DEC-` through
+  `wdi-decision` — never absorbed as a code patch.
+- **Verification is run, not assumed.** `go build ./...` and `go test ./...` from `src/`, where `go.mod` lives;
+  `npm run check` from `web/`. A green `korpus.yml` MUST NOT be reported as proof the code compiles.
+
+### Step 1 — plan
+
+- MUST include `Halt after planning.` Without it the worker runs straight through implementation and Step 2
+  loses its gate.
+- Validation is not a separate step. Step-02's READY-FOR-DEVELOPMENT gate verifies the spec, repairs it once,
+  and re-verifies. MUST NOT wrap a second validation loop around it.
+- `blocked / spec failed ready-for-development standard` means that repair did not converge. MUST escalate the
+  failing criteria; MUST NOT hand-patch the spec into a pass.
+- `blocked / intent gap` MUST reach the owner with the worker's unanswered questions verbatim.
+
+### Step 2 — build
+
+- MUST dispatch with the spec file path and the three brief rules above. The worker commits locally and **never
+  pushes**.
+- `blocked / review repair loop exceeded 5 iterations` means its internal loop did not converge. MUST escalate;
+  MUST NOT re-dispatch for a sixth.
+- On `blocked / intent gap` the worker has reverted the code and saved a patch file. MUST retrieve that patch
+  path from the triage log before escalating — the work is recoverable, and losing it costs the whole step.
+
+### Step 3 — panel, then judge
+
+Panel composition follows `risk_accepted`: at `low` a two-reviewer panel is **required** on the code; at
+`medium` and `high` it is available and SHOULD be used when the diff touches money, personal data, or a third
+party. The Agent Rules `bmad-code-review panel` section defines the pairing, and it MUST be followed exactly —
+the worker's own review layers are same-family by construction and never satisfy it.
+
+- MUST adjudicate every contested finding by reading the cited lines. Votes MUST NOT settle a finding. A finding
+  neither reviewer can locate in the diff is dismissed with that reason stated.
+
+**MUST return to Step 2:**
+
+- Breaks a story AC, or contradicts the SPEC, the SDD, an `AD-N`, or an `applied` `DEC-`
+- Wrong behaviour, crash, or data loss reachable from the running app
+- Corpus drift: an `LC` touched but not registered, a contract changed in code but not in `02-contracts/`, a
+  screen added without its `01-ux/` entry
+- An enum value rendered straight to the screen instead of read off its label map
+- Payment or private data reaching a tracked file
+- A weakened guard, or a test that cannot fail — including one asserting a literal instead of the behaviour it
+  claims to cover
+
+**MUST record as follow-up and MUST NOT return to Step 2:** style or naming with no behaviour delta · a
+refactor outside this story's scope · a pre-existing defect this story did not touch · a speculative risk with
+no reachable path.
+
+A must-fix MUST return as a **spec amendment**, never a chat instruction: amend the sections outside
+`<intent-contract>`, append a `## Spec Change Log` entry naming the finding, reset `status` to `ready-for-dev`,
+then re-dispatch. Content inside `<intent-contract>` is the owner's alone; a must-fix rooted there is an intent
+gap and goes to the owner.
+
+Cap: **2 return trips.** MUST re-run the whole panel after each fix round — a fix introduces defects. On hitting
+the cap MUST escalate and MUST NOT open a PR carrying an unresolved must-fix.
+
+### Step 4 — story-closing checklist, then push and PR
+
+The checklist is **three items** now, and it MUST be answered before the PR opens:
+
+1. A decision worth remembering? → `wdi-decision`. A story contradicting an `AD-N` **stops** rather than
+   closing.
+2. A trap for the next agent? → recorded where the next agent will read it.
+3. Test names matching what `waves.yaml` records?
+
+The five items that left this list moved to Phase 4, where the information actually exists.
+
+- MUST run the repository's commit/push audit before `git push`: refuse the forbidden paths, run the guard test,
+  fix content on failure. A failing guard is a finding about the content — MUST NOT weaken the guard or the test.
+- MUST NOT push to `main`/`master`, MUST NOT force-push, MUST NOT merge.
+- The coordinator MUST be the hand that pushes and opens the PR.
+
+### Step 5 — watch CI, then judge
+
+- MUST wait for every check to conclude, then confirm the checks belong to the **pushed head SHA**. A green
+  report from a stale run is a false report.
+- `korpus.yml` validates the corpus, not the code. Build and test evidence comes from Step 2's own runs.
+- Classify each failure before acting: a defect from this change → Step 2, with `wdi-systematic-debugging` when
+  the cause is unknown · infrastructure or flake → re-run **once**, and MUST NOT patch code to mask it; a second
+  identical failure is a defect · a guard failure → fix the content.
+- Cap: 2 return trips. On hitting the cap MUST report red honestly rather than keep pushing.
+
+### Parallel stories
+
+Stories without a `depends_on` path between them MAY run at once, but four conditions MUST hold: each worker in
+its own worktree; V11 green for every pair released together; the first story of an epic already `done` so later
+stories inherit its code map; and no shared registry write in flight.
+
+The pattern that MUST be preferred: run the biggest blocker alone first, let its shape decisions land, then fan
+out.
+
+## Phase 4 — Close the wave
+
+Run in this order and stop at the first failure:
+
+1. **Registry catch-up.** Every `LC` the wave's design named is registered in `components.yaml`, and every
+   `touches` value resolves — V12. This is the moment those questions have answers.
+2. **Inventories refreshed from code.** Run `.constitution/scripts/inventory.py`. The plan-versus-reality
+   difference is reported as a finding; it MUST NOT be patched into agreement by hand.
+3. **Structure maps refreshed** through `wdi-init` intent `structure`, if a base folder was born or removed or a
+   key file moved.
+4. **Distillation.** Every applicable row of the ownership table in `corpus-guide.md` has been landed by its
+   owner. Anything durable in the spec folder leaves it now, or dies with it.
+5. **Retrospective.** On wave `L`, dispatch `bmad-retrospective` and archive `RETROSPECTIVE.md` as
+   `RTR-<wave>.md` in `.control/reports/`. On `S` and `M` it is advisory — V19 says so, and skipping it MUST be
+   stated rather than silent.
+6. **RTM green.** Every traceability row for this wave is closed. New risks are in the risk register with an
+   owner.
+7. Mark the wave `status: closed` in `waves.yaml`.
+
+- You MUST NOT close a wave with an open distillation row. The whole point of an ephemeral working layer is that
+  durable truth leaves it first.
+- You MUST NOT reopen a closed wave to add scope. Scope arriving late opens a new wave, or goes through
+  `wdi-decision` if it invalidates what is already planned.
+- A change invalidating more than 30% of a wave's stories MUST go through `wdi-decision`, not a patch to
+  `waves.yaml`.
+- Fast Path work is recorded as `fastpath` with no gates. If an `FR` turns out to be touched, the work MUST stop
+  and be raised to a wave `S`.
+
+## Red Flags — STOP
+
+- "One reviewer approved, good enough"
+- Judging a step from a chat report instead of the spec's frontmatter `status`
+- Dispatching Step 1 without `Halt after planning.`
+- Editing content inside `<intent-contract>` on the owner's behalf
+- A worker editing `.what/`, `.how/`, or an `applied` `DEC-` to make its code fit
+- Fixing a failing test without knowing why it failed
+- Opening a PR with an unresolved must-fix, or before the story-closing checklist is answered
+- Editing a guard, a test, or an assertion to turn something green
+- Reporting green without checking the head SHA, or reading green `korpus.yml` as a passing build
+- A reviewer from the same CLI family as the builder
+- Dispatching a worker without its Unattended flag
+- Closing the wave without the registry catch-up in Phase 4 — that is where five checklist items now live
+- Letting `SPEC.md` state something `.what/` and `.how/` do not
+
+**Each of these means: stop, return to the step or phase that owns it, or escalate to the owner.**
+
+## Output
+
+MUST follow the Agent Rules `Answer Closing` block, carrying these additions:
+
+- **what was done** — wave, `FR` satisfied, every story with its branch and PR URL, what the code now does
+- **what blocked it** — every step that looped, every dismissed finding and why, anything left red, and every
+  Phase 4 item that did not pass
+- **what comes next** — every finding recorded as follow-up, every entry in a spec's `deferred` list, every
+  story-closing item routed to another skill, and the plan-versus-code inventory differences. A follow-up absent
+  here is a lost finding.

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

@@ -0,0 +1,172 @@
+---
+name: wdi-component
+description: Use at G4 Component — the depth of one Product Component, as deep as that component's mode and no deeper. Two intents, behaviour and design. Owns .what/<pc>/ slots 02-05 and .how/<pc>/ minus 01-ux. Skipped entirely at mode catalog.
+---
+
+# WDI Component
+
+G4 decides **how one Product Component is built, and what the choice costs.** It is the only gate that changes
+shape with `mode`, and the only one that runs more than once for a reason other than a new PRD.
+
+| `mode` | This skill |
+|---|---|
+| `catalog` | **Not run. G4 is skipped.** |
+| `outline` | `behaviour` + `design` **as far as § Structure**, and no further |
+| `guarded` | `behaviour` + `design` |
+| `deep` | `behaviour` + `design` |
+
+This table said `outline` → `behaviour` only until 2026-08-18. It contradicted **Step 4 of this same
+skill**, which starts `Decision Summary` and `Structure` "from `outline`", and it contradicted
+`delivery-flow-guide.md`, which owns the mapping and lists both for `outline`. Read literally, it would
+have left every `outline` component with an SDD that is a template skeleton forever — and V13 would have
+been right to keep flagging it.
+
+Read the component's `mode` from its row in `components.yaml`, falling back to `mode:` in `index.yaml`. Read
+its `risk_accepted` from the same row; it decides the review lenses and nothing else.
+
+**You MUST NOT write more than the component's `mode` demands.** Writing a section the mode does not ask for is
+the failure this gate was rebuilt to stop — it is how 41 of 56 use cases ended up marked `critical` and how the
+previous run stalled. Depth is a preference the owner set, and exceeding it is not diligence.
+
+Stage-3 and Stage-4 work were two skills before and are one now, because they are one gate. The boundary
+between them is intact and it is **horizontal**: `behaviour` writes what the system does, `design` writes how.
+
+## Inputs
+
+| Source | What it answers |
+|---|---|
+| `.control/registry/components.yaml` | This component's `mode`, `risk_accepted`, `risk_note`, `owns` |
+| `.what/<pc>/SRS-<pc>.md` § UC Catalogue · § Actor Register | Which use cases exist, and which are `critical` |
+| `.what/_prd/*/prd.md` | The `FR` this component has to make true |
+| `.what/business-rules.md` | Rules that already bind more than one component |
+| `.how/_platform/inventory-api.md` · `inventory-screen.md` | **The boundary list.** It is already derived; do not derive it again |
+| `.how/_platform/ARCHITECTURE-SPINE.md` | Every `AD-N` that binds this component |
+| `.how/_platform/cross-cutting.md` | The error envelope, and anything else decided once |
+| `.control/decisions/` | `applied` decisions this must not contradict |
+| `.constitution/document/srs-guide.md` · `sdd-guide.md` | The rules the result is checked against |
+| `src/` · `web/` | Only as evidence when the code already exists. Never as a substitute for the SRS |
+
+## Step 1 — Scope, one component
+
+State it in one line before doing anything. A pass MUST NOT write content for several components: an SDD is per
+component by construction, and one pass over two of them inherits the wrong constraints.
+
+| Ask | Scope |
+|---|---|
+| "Take `<pc>` to G4" | One component, both intents as its `mode` demands |
+| "Write the failure behaviour for `<pc>`" | One section of one component |
+| "Is our design consistent?" | Read-only across components — that is `wdi-reconcile`. Route there |
+
+## Step 2 — Preconditions
+
+None of these are yours to create.
+
+| Check | When it fails |
+|---|---|
+| The component is registered with `mode` and `risk_accepted` set | Route to `wdi-init` intents `component`, `mode`, `risk` |
+| Its `mode` is not `catalog` | Stop. G4 is skipped, and the work goes straight to `wdi-build` |
+| G3 has passed | Route to `wdi-blueprint`. Depth written against a moving portrait is rewritten |
+| The spine exists and its `AD-N` are readable | Route to `wdi-blueprint`. You MUST NOT write the spine |
+| For `design`: the container this component runs in is registered | Route to `wdi-blueprint`. An `LC` MUST name its container |
+
+## Step 3 — Intent `behaviour`
+
+Writes `.what/<pc>/`, slots `02`–`05`. You MUST NOT write solution shape: no framework, no table, no endpoint,
+no class, no queue, no file path.
+
+| `mode` | Written |
+|---|---|
+| `outline` · `guarded` | Full flows for the use cases the component exists for, **at most 3**, in `04-usecases/UC-<n>-<slug>.md` · local business rules in `02-rules/rules-<pc>.md` |
+| `deep` | + a full flow for **every** `critical` use case · `03-domain/state-machines.md` · `05-scenarios/SCN-<nn>-<slug>.md` |
+
+A flow is at most **eight steps**. A flow needing more is either two use cases or has started describing
+implementation, and the cap is what makes that visible while it is still cheap to fix. Branches go to
+`05-scenarios/` — at `deep` only — never into a fatter UC file.
+
+A rule that turns out to bind a second component MUST be **promoted** to `.what/business-rules.md` through
+`wdi-blueprint`, not copied. Two copies of one rule is how components start disagreeing about the same policy.
+
+## Step 4 — Intent `design`
+
+Writes `.how/<pc>/`. Two carve-outs that are not negotiable: `01-ux/` belongs to `wdi-ux`, and all of
+`.how/_platform/` belongs to `wdi-blueprint`. You MUST NOT write into either.
+
+Write in this order, stopping at whatever the `mode` does not reach:
+
+1. **`Decision Summary`** — from `outline`. One page: what this component is built as, and the one or two most
+   expensive choices reversed.
+2. **`Structure`** — from `outline`. The `LC` list and the direction of their dependencies.
+3. **`Inherited Constraints`** — from `guarded`. Every `AD-N` reaching this component, **quoted verbatim**. A
+   paraphrase drifts, and the drift is invisible because both texts read reasonably. A design that must deviate
+   does not argue here: it goes to `wdi-decision`, and either the spine changes or the design does.
+4. **`Failure Behaviour`** — from `guarded`, for **every** boundary. The boundary list is the endpoints and
+   screens this component owns in the two platform inventories. Per boundary: what happens when the other side
+   is slow, absent, or lying — timeout, retry policy, what the user sees, what gets logged. "Returns an error"
+   is not an answer.
+5. **`03-integrations/<name>.md`** — from `guarded`, when the component has a third party. It MUST name the
+   owner outside the team, and what happens when they change it without telling anyone.
+6. **The ABCE pass** — `deep` only, in order: Boundary → Control → Entity → Behaviour. It MUST NOT have
+   appeared in the SRS, and below `deep` it MUST NOT be written at all.
+7. **`02-contracts/`, `04-components/`, `05-model/data-model.md`, `06-flows/`** — `deep` only. The contract
+   inventory comes first and specs carry its stable numbers; every spec answers all five lanes, with `none` and
+   a reason where one does not apply. The data model carries a dictionary beside its diagram.
+
+From `guarded` up, every Boundary object MUST become an `LC` in `components.yaml`; at `deep`, Control objects
+too. Registration is checked **when the wave closes** — V12 — not before a story is `ready-for-dev`. You MUST
+NOT register a `container`, and you MUST NOT register `ui-screen` or `ui-composite`.
+
+## Step 5 — Evidence, and the as-built case
+
+Every technical claim about code that already exists MUST name what was read. The four labels — `[ASSUMED]` ·
+`[PARTIAL]` · `[NEEDS CONFIRMATION]` · `[MISSING]` — are mandatory, and their ladder rules are in
+`sdd-guide.md`.
+
+**Raising a component's `mode` after its code runs is the case this matters most for.** What you write then is
+an **as-built record, not a design**, and you MUST NOT raise a claim to verified without naming the file that
+proves it. Two labels MUST be acted on rather than left in the text:
+
+- `[NEEDS CONFIRMATION]` → `wdi-question`, before G4 opens.
+- `[MISSING]` → dispositioned as a `BUG-`, a correction, or planned work. It MUST NOT be deleted; the
+  sentence is the only surviving evidence that somebody once believed the thing existed.
+
+## Step 6 — Drift
+
+Check against the layer above and the code below, and **report** — never edit the other side.
+
+| Found | Where it goes |
+|---|---|
+| Depth needs behaviour the catalogue never listed | `wdi-blueprint` — into the catalogue, before any code |
+| The catalogue promised behaviour this component cannot deliver | `wdi-product`. Do not quietly narrow it here |
+| A contradiction with an `applied` decision or an `AD-N` | `wdi-decision` — a new `DEC-`, never an edit to one already applied |
+| A decision that would bind a second component | `wdi-blueprint` — it is an `AD-N`, not an SDD paragraph |
+| The code does something this document does not describe | Here, as a labelled claim, or as a `BUG-` when the code is wrong |
+
+`wdi-reconcile` is the read-only sweep across all layers. Run it rather than reimplementing it.
+
+## Step 7 — Review
+
+No `doc_standards` fires for an SRS or an SDD. Dispatch `wdi-review`, which reads the lens set from this
+component's `risk_accepted` — `edge-case-hunter` at `low` and `medium`, `structure` + `prose` at `high`, plus a
+two-reviewer code panel at `low`. Slots are part of the artifact; reviewing a kernel alone misses where the
+branches and contracts live.
+
+You MUST NOT open G4 on depth that has not been through it.
+
+## Rules
+
+- A decision taken while writing MUST go to `wdi-decision`, never into the document as a parenthetical. There
+  is no memlog here to catch it.
+- You MUST NOT write into `.what/_prd/`, `.what/business-rules.md`, `.how/_platform/`, or `.how/<pc>/01-ux/`.
+- You MUST NOT raise `status:`. Status is a stage; the `reviewed:` block is an event.
+- You MUST NOT lower or raise the component's `mode` to fit what you want to write. That is `wdi-init`, and it
+  is the owner's call.
+- `bmad-spec` runs **after** this, never before, and it MUST NOT introduce anything these documents do not say.
+- Memlog: `.control/memlog/<pc>.md`, through `memlog.py --path`. `--workspace` MUST NOT be used.
+- Questions arrive as **one** ranked batch at the gate, not as they surface.
+
+## Output
+
+Component and its `mode` and `risk_accepted` · which intents ran · what was written per slot and **what the
+mode deliberately left unwritten** · the `AD-N` inherited · the `LC` registered and their types · evidence
+labels outstanding by kind · drift found and where it was routed · whether `wdi-review` ran · the one ranked
+batch of questions.