wdi-method 0.6.30 → 0.6.32

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

@@ -1,6 +1,6 @@
 ---
 name: wdi-build
-description: Use at G5 Release — one spec from open to closed in one supervised run. Opens the spec, hands the owner to-spec and to-tickets, ships every ticket to a green PR through a five-step pipeline, then closes the spec. One invocation, not four.
+description: Use at G5 Release — one spec from open to closed in one supervised run. Opens the spec, drives to-spec and to-tickets, ships every ticket to a green PR through a five-step pipeline, then closes the spec. One invocation, not four.
 ---
 
 # WDI Build
@@ -16,29 +16,37 @@ without them. Thirteen BMad skills are **retired** at this gate and MUST NOT be
 `bmad-spec`, `bmad-build`, `bmad-build-auto`, `bmad-code-review`, `bmad-retrospective`,
 `bmad-agent-dev`, `bmad-create-epics-and-stories`, `bmad-create-story`, `bmad-dev-story`,
 `bmad-dev-auto`, `bmad-quick-dev`, `bmad-sprint-planning`, `bmad-sprint-status`. That is enforced, not
-requested: `install` and `update` lock each one out of model invocation and add a `Skill()` deny rule.
-`bmad-skill-register.md` carries the list and the criterion behind it.
-
-**All five engines are INVOKED, by this skill, through the Skill tool.** Upstream ships `to-spec`,
-`to-tickets` and `implement` with `disable-model-invocation: true`; `wdi-method` strips it from the
-copies this repo owns, so there is no command to hand to the owner and no reading-and-following to do.
-Where an engine needs a decision — the seams, the `to-tickets` quiz — that decision is made before the
-invocation and passed IN it, because an engine that stops to ask inside an unattended run is a run
-that stalls with nobody there to answer.
+requested: `install` and `update` lock each one out of model invocation wherever the host offers a lock
+(`disable-model-invocation`, `.claude/settings.json` deny rules, `opencode.json` `ask`), and the
+`AGENTS.md` block forbids them on every host. `bmad-skill-register.md` carries the list and the
+criterion behind it.
+
+**All six engines are INVOKED, by this skill, through the host's own skill mechanism.** Which mechanism
+that is belongs to the host, not to this skill: a skill tool where the host has one (Claude Code's
+`Skill`, OpenCode's `skill`, Gemini's `activate_skill`), and where the host has none — Kiro, Codex,
+Cursor, and most others — loading the engine is reading its `SKILL.md` **in full, from the repo's
+own copy**, and carrying it out. That is not a workaround on those hosts; it is the only way they load any
+skill. `hosts:` in `.control/wdi-method.yaml` says where this host reads skills. Upstream ships
+`to-spec`, `to-tickets` and `implement` with `disable-model-invocation: true`; `wdi-method` strips it
+from the copies this repo owns, so on every host this skill drives the engines itself and hands no command
+to the owner. Where an engine needs a decision — the seams, the `to-tickets` quiz — that decision is
+made before the invocation and passed IN it, because an engine that stops to ask inside an unattended run
+is a run that stalls with nobody there to answer.
 
 **If an engine will not invoke, stop and say why.** `disable-model-invocation` back in its frontmatter
 is what `npx skills update` does, and the fix is one command: `npx wdi-method engines --fix`, or the
-`wdi-init` / `wdi-upgrade` skill. MUST NOT work around it by pasting the engine's process inline: the
-engine's rules are its own, and a paraphrase of them is not the engine.
+`wdi-init` / `wdi-upgrade` skill. An engine missing from every folder this host reads is the other
+cause, and `npx wdi-method engines` names the `npx skills add --agent` that fixes it. MUST NOT work
+around either by paraphrasing the engine from memory, summarising it into a brief, or reading a copy from
+outside the repo: the engine's rules are its own, and anything short of its whole `SKILL.md` is not the
+engine.
 
 **Under an active mandate the owner's part is `wdi-autopilot`'s.** A `DEC-` of `type: mandate` at
 `status: accepted`, unexpired, moves **every** "the owner runs" and "the owner decides" in this skill to the
 coordinator — G5's checklist and Step 2's *stop and reach the owner* included, which reach the coordinator and
-not a person. Three of them change **shape** as well as owner: the engines run by **read-and-follow** — a builder brief
-that names the engine's `SKILL.md` path and carries out its process — or from a copy in the repo, and the ledger
-names which; the seams, the `to-tickets` quiz, and § When the code turns out to be right are decided by the
+not a person. Two of them change **shape** as well as owner: the seams, the `to-tickets` quiz, and § When the code turns out to be right are decided by the
 coordinator and written to the ledger, one row each; and whatever the mandate lists as `parked` still stops,
-reported for the owner rather than decided. One thing changes **shape** rather than owner: a mandate is one
+reported for the owner rather than decided. The engines are invoked exactly as above, mandate or not. One thing changes **shape** rather than owner: a mandate is one
 unit of work and reaches the active development branch (`policy.development_branch`, default `main`) through **one PR**, so Step 4 commits the ticket to the run branch instead of
 opening a PR per ticket, and Step 5 splits: the coordinator pushes the run branch at every spec close, but
 **the cloud run happens once, at `wdi-autopilot` § Finish** — every intermediate push starts nothing, and
@@ -224,7 +232,7 @@ is not.
 
 ### Step 2 — build
 
-- The owner runs `/implement`, and it MUST be given the ticket and the three brief rules above.
+- This skill invokes `implement` (as § All six engines says), and it MUST be given the ticket and the three brief rules above.
 - It commits to the current branch and **never pushes**. That is its own behaviour and it is what we want; the
   coordinator is the hand that pushes.
 - **`/implement` calls `/code-review` itself, and that call does NOT satisfy Step 3.** It is the builder
@@ -385,8 +393,9 @@ only thing `V19` checked.
 - Amending what a ticket `satisfies` to make a must-fix go away
 - A ticket that slices one layer instead of cutting through all of them, outside a wide refactor
 - Running a wide refactor's batches in parallel
-- Claiming this skill invoked `to-spec`, `to-tickets`, or `implement` — it cannot; the owner runs them, or under
-  a mandate a builder reads and follows them, and the ledger says so
+- Paraphrasing `to-spec`, `to-tickets`, or `implement` from memory, or summarising one into a brief, and
+  calling that the engine — on a host with no skill tool the engine is its whole `SKILL.md`, read from the repo
+- Stopping because the host has no `Skill` tool — that host loads skills by reading them, and so does this skill
 - A builder 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 ticket-closing checklist is answered

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

@@ -1,174 +1,179 @@
----
-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 `review-trace` 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/method/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`. G3 has passed by now, so the answer exists — an `LC` written here MUST carry it. Only a screen `LC` born at G2 is allowed an empty one, and G3 fills it |
-
-## 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 spec closes** — `lc-registered` — not before a ticket is picked up. 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 is **written into the document as its own content**, stated as what now
-  holds. Never as a parenthetical aside — there is no memlog here to catch one. It goes to `wdi-decision`
-  only when no design document has a home for it, or it touches an `AD-N`; `decision-guide.md` § A
-  decision's first home owns that split.
-- 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.
-- The spec's contract is cut **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.
+---
+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 `review-trace` 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/method/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` is in `gates_passed` | Route to `wdi-blueprint`. Depth written against a moving portrait is rewritten. A missing record is asked of the owner, never inferred from the spine existing |
+| 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`. G3 has passed by now, so the answer exists — an `LC` written here MUST carry it. Only a screen `LC` born at G2 is allowed an empty one, and G3 fills it |
+
+## 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 spec closes** — `lc-registered` — not before a ticket is picked up. 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.
+
+## Step 8 — Record the gate
+
+Ask the owner whether G4 passed for this component. Write today's date into its `g4_passed` only on
+their explicit *yes* — `delivery-flow-guide.md` § *Recording a gate that passed*. `spec-after-g4` reads it.
+
+## Rules
+
+- A decision taken while writing is **written into the document as its own content**, stated as what now
+  holds. Never as a parenthetical aside — there is no memlog here to catch one. It goes to `wdi-decision`
+  only when no design document has a home for it, or it touches an `AD-N`; `decision-guide.md` § A
+  decision's first home owns that split.
+- 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.
+- The spec's contract is cut **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 · whether G4 was recorded.

package/kit/skills/wdi-daily-autopilot/SKILL.md

@@ -1,15 +1,17 @@
 ---
 name: wdi-daily-autopilot
-description: Compose and launch the autonomous daily loop routine (default 10m interval) with self code-review and peer-review runners resolved from local configuration. Invoke as `/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review|--no-review]` (`[self-review]` alias `[in-session]`).
+description: Compose and launch the autonomous daily loop routine (default 10m interval, on the host's own scheduler; once where the host has none) with self code-review and peer-review runners resolved from local configuration. Invoke as `/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review|--no-review]` (`[self-review]` alias `[in-session]`).
 disable-model-invocation: true
 ---
 
 # WDI Daily Autopilot Launch
 
+> **Typed by the owner, or not at all.** Run this skill only when the person typed `wdi-daily-autopilot` — `/wdi-daily-autopilot` 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.
+
 Composes the autonomous daily engineering routine, verifies or initiates the owner-accepted mandate
 required by `wdi-autopilot`, resolves coordinator self code-review and independent peer-review dispatch
-from local configuration or agent rules, and launches the execution via `/loop <interval>` (default
-`10m`).
+from local configuration or agent rules, and launches the execution on the host's own scheduler (default
+`10m`) — or, on a host that has none, runs one iteration now.
 
 `/wdi-daily-autopilot [self-review] [peer] [interval] [--skip-peer-review|--no-review]`:
 - `[self-review]` — coordinator self code-review pass model (`default` or explicit model slug; alias `[in-session]`).
@@ -53,9 +55,10 @@ Inspect the repository for `.control/custom-dispatch.yaml` (if not found in the
     Guardrail: coordinator direct implementation MUST NOT eliminate independent peer review when any component the mandate touches has `risk_accepted: low`. There `low` is the hardest review: `wdi-build` Step 3 requires a two-reviewer panel of agents that are not the builder (`delivery-flow-guide.md`). The coordinator MUST NOT honour a peer-review bypass (`roles.reviewer: none`, `review_policy.peer_review: false`, `--skip-peer-review`, or `--no-review`) when any touched component has `risk_accepted: low`: stop and report which components block it (fail-closed). When every touched component is `medium` or `high`, the bypass is allowed, and the choice MUST be recorded in the mandate text (step 4) and in the ledger.
   - Resolve runner dispatch by `type:` for reviewer and deep analyst:
     - `auto`: Evaluates whether the runner's target model is reachable in-session from the active
-      session profile (per the caller's global agent collaboration rules). Dispatches in-session via `Agent`
-      if reachable; falls back to shell-out using `command` if unreachable in-session.
-    - `in-session`: Dispatches strictly via in-session `Agent` subagent.
+      session profile (per the caller's global agent collaboration rules). Dispatches through this host's
+      own read-only subagent tooling if reachable; falls back to shell-out using `command` if unreachable in-session.
+    - `in-session`: Dispatches strictly through this host's own subagent tooling (read-only). A host with
+      none cannot satisfy it — stop and report (fail-closed).
     - `shell-out`: Executes the external shell-out `command` (single-string command). If `command` is absent
       or empty, stop and report immediately (fail-closed).
 - **If `.control/custom-dispatch.yaml` does not exist**:
@@ -123,17 +126,25 @@ self-review and self-verification without external peer dispatch.
 
 ## 5. Launch
 
-Invoke the `loop` skill with `<resolved interval> /wdi-autopilot <composed text from step 4>`. This
-starts the loop execution.
+Read this host's `loop:` from `hosts:` in `.control/wdi-method.yaml` (the entry whose `id` is the host
+running this session) and launch the way `wdi-autopilot` § Starting the loop says:
+
+- **`kind: command` or `kind: scheduler`** — start the host's own scheduler with `<resolved interval>` and
+  the prompt `/wdi-autopilot <composed text from step 4>` (the host's own invocation syntax, `invoke:` in
+  the same entry, replaces `/wdi-autopilot` where it differs).
+- **`none`** (or the host is not in `hosts:`) — do not look for a substitute: no shell loop, no OS
+  scheduler, no second agent. Run **one** iteration of `wdi-autopilot` now, in this turn, with the composed
+  text. The mandate the owner already accepted (step 3) is the go-ahead; nothing more is asked.
 
 ## 6. Verify Immediate Execution
 
-Before finishing, verify that `/wdi-autopilot` was invoked in this same turn for the first iteration
-rather than remaining idle until the first cron interval tick. If it did not run immediately, invoke
-`/wdi-autopilot` now to start the first iteration.
+Before finishing, verify that `wdi-autopilot` ran its first iteration in this same turn rather than
+waiting for the first scheduled tick. If it did not, run it now.
 
 ## 7. Report and Stop
 
 Report the resolved configuration (in-session mechanism, peer review status, active mandate ID, and
-loop interval), confirm that the loop is active, and stop. MUST NOT intervene in or micromanage
-subsequent loop iterations.
+loop interval — or `once: this host has no scheduler`), and stop. Where a schedule is running, MUST NOT
+intervene in or micromanage subsequent iterations. Where it ran once, the report ends with the one line
+the owner needs: invoke this skill again to run the next iteration — the mandate, ledger, and run branch
+carry over.

package/kit/skills/wdi-daily-what-to-build/SKILL.md

@@ -6,6 +6,8 @@ disable-model-invocation: true
 
 # WDI Daily What-to-Build Triage
 
+> **Typed by the owner, or not at all.** Run this skill only when the person typed `wdi-daily-what-to-build` — `/wdi-daily-what-to-build` 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.
+
 Daily entry point for "I just tested something by hand, now what." Classifies the notes (new feature,
 fix, removal, or green), authors the resulting spec or ticket through this repo's own `wdi-build` flow,
 dispatches an independent second opinion grounded in the *original* notes, folds that feedback back in,
@@ -107,9 +109,10 @@ Reviewer resolution:
 - If `.control/custom-dispatch.yaml` exists in the repo root (or in the main repository root via `(git rev-parse --git-common-dir)/..` when running inside a linked git worktree): inspect `runners:` and `roles.reviewer`.
   A runner definition specifies `type:` (`auto`, `in-session`, or `shell-out`):
   - `auto` (recommended): Evaluates whether the runner's target model is reachable in-session from the active
-    session profile (per the caller's global agent collaboration rules). Dispatches in-session via the `Agent`
-    tool in read-only mode if reachable; falls back to shell-out using `command` if unreachable in-session.
-  - `in-session`: Dispatches strictly via the in-session `Agent` tool using a read-only subagent type.
+    session profile (per the caller's global agent collaboration rules). Dispatches through this host's own
+    subagent tooling in read-only mode if reachable; falls back to shell-out using `command` if unreachable in-session.
+  - `in-session`: Dispatches strictly through this host's own subagent tooling, read-only. A host with none
+    cannot satisfy it — stop and report (fail-closed).
   - `shell-out`: Dispatches strictly via external shell `command` (single-string command, passing the review packet path).
     A shell-out reviewer MUST be invoked with its read-only flag where supported (e.g. `--trust-tools=fs_read` for
     `kiro-cli`, `--mode plan` for `cursor-agent`).
@@ -124,11 +127,11 @@ Reviewer resolution:
     killing). Record in the final report: `peer review: fell back to coordinator self-review after timeout/failure`.
     MUST NOT fabricate or synthesize unread reviewer output as if it were faithfully received.
 - In the absence of a custom runner file: follow the caller's configured agent collaboration setup
-  (e.g., in-session read-only subagent via the `Agent` tool if reachable, or the caller's configured CLI
+  (e.g., a read-only subagent through this host's own tooling if reachable, or the caller's configured CLI
   environment).
 
-When the dispatched reviewer has no native Skill tool, instruct it to read and follow the target
-guide directly as plain markdown instructions.
+The reviewer loads the target guide the way its host loads any instruction: through its skill tool where
+it has one, otherwise by reading the guide in full. MUST NOT hand it a summary in the guide's place.
 
 ## 5. Coordinator fold-in, stamping, and validation
 

package/kit/skills/wdi-daily-what-to-test/SKILL.md

@@ -6,6 +6,8 @@ disable-model-invocation: true
 
 # WDI Daily What-to-Test
 
+> **Typed by the owner, or not at all.** Run this skill only when the person typed `wdi-daily-what-to-test` — `/wdi-daily-what-to-test` or this host's own syntax for it — in the turn that is running. Reached any other way (a description that looked relevant, another skill, a subagent), stop and name it instead. Hosts that can hold a skill to manual-only already do; on the others, this line is the lock.
+
 The post-merge daily verification step after a `wdi-autopilot` or ticket delivery run merges: lands
 back on the active development branch, safely prunes stale merged worktrees and task branches while
 strictly preserving protected branches, configures the application where it needs to be for platform