wdi-method 0.6.30 → 0.6.32

package/kit/.constitution/method/why/artifact-map.md

@@ -1,157 +1,158 @@
----
-status: Reference
----
-
-# Artifact Map — what exists, where, and who owns it
-
-**Opened when:** someone asks *"where does this file go"*, or *"does this document exist at my `mode`"*.
-
-This file **explains**. It does not bind — `../document/*-guide.md` does, and where the two disagree the guide
-wins and the disagreement is a defect to report.
-
-It answers three questions and nothing else: which files exist at each `mode`, who owns each one, and how
-the units of work line up. The **rules** about depth live in `../document/delivery-flow-guide.md`; what is
-here is the map. What `mode` and `risk_accepted` do **together**, cell by cell, is in `mode-risk-map.md`.
-
-## The one thing to read first
-
-Nine things exist at **every** `mode`, including `catalog`, because they belong to the blueprint at G3 and
-the depth knob does not reach the blueprint:
-
-> the use case list · the API list · the table list with its key columns · the screen list · the domain
-> model · the actor list · the spine `AD-N` · C4 L1 + L2 + L3 · cross-component business rules
-
-That is why nobody needs a fifth mode. The request behind wanting one is almost always *"I need at minimum
-the use cases, the API, and the database"* — and all three are already in `catalog`.
-
-## What each mode gives you, cumulatively
-
-| `mode` | What you hold |
-|---|---|
-| `catalog` | The nine above. **Zero extra files per component** |
-| `outline` | + `Decision Summary` · the `LC` list per component · full flows for at most 3 use cases · local business rules |
-| `guarded` | + `Failure Behaviour` for every boundary · `Inherited Constraints` · third-party integration documents · boundary `LC` registered |
-| `deep` | + ABCE robustness analysis · five-lane contract spec per endpoint · data dictionary per column · flow diagrams · state machines · branch scenarios · every `critical` use case gets a full flow |
-
-Marks used below: **always** = present at all four modes, born at G1, G2, or G3 · ✓ = written at that mode
-· skeleton = the file exists carrying headings and frontmatter · — = not written at all.
-
-## `.what/`
-
-| File | Holds | Born | `catalog` | `outline` | `guarded` | `deep` |
-|---|---|---|---|---|---|---|
-| `_product-brief/brief.md` | Problem, users, measure of success, non-goals | G1 | always | always | always | always |
-| `_product-brief/addendum.md` | Depth that does not fit the brief's narrative | G1 | always | always | always | always |
-| `_prd/<initiative>/prd.md` | `CAP` · `FR` · `NFR` · `UJ` · one proof of done per `FR` | G2 | always | always | always | always |
-| `_prd/<initiative>/addendum.md` | Rejected alternatives, option matrices, sizing | G2 | always | always | always | always |
-| `<pc>/04-usecases/EXPERIENCE.md` | The user-facing journey | G2, optional | optional | optional | optional | optional |
-| `business-rules.md` | `BR-N` binding more than one component | G3 | always | always | always | always |
-| **`<pc>/SRS-<pc>.md`** | § Actor Register · **§ UC Catalogue — this is the use case list** · Constraints · Non-Goals · Prerequisite · Assumptions/Risks/TBC | G3 | **always** | always | always | always |
-| `<pc>/03-domain/domain-model.md` | Entities · relations · columns | G3 | always | always | always | always |
-| `<pc>/02-rules/rules-<pc>.md` | Rules binding only this component | G4 | — | ✓ | ✓ | ✓ |
-| `<pc>/04-usecases/UC-<n>-<slug>.md` | One full flow, at most eight steps | G4 | — | max **3** | max **3** | every `critical` UC |
-| `<pc>/03-domain/state-machines.md` | The lifecycle of each multi-state entity | G4 | — | — | — | ✓ |
-| `<pc>/05-scenarios/SCN-<nn>-<slug>.md` | A branch that does not fit its use case file | G4 | — | — | — | ✓ |
-
-**So `SRS-<pc>.md` exists at `mode: catalog`.** It carries the actor list and the use case catalogue. What
-is absent there is the `UC-<n>-<slug>.md` files — the step-by-step flows.
-
-Repealed: `<pc>/01-requirements/` (permanently empty; `FR` live in the PRD and the SRS cites them) and
-`<pc>/supplements/` (existed for `ANX-`).
-
-## `.how/`
-
-| File | Holds | Born | `catalog` | `outline` | `guarded` | `deep` |
-|---|---|---|---|---|---|---|
-| `_platform/ARCHITECTURE-SPINE.md` | `AD-N` — Binds · Prevents · Rule. Invariants only | G3 | always | always | always | always |
-| `_platform/c4-l1-system-context.md` | System, outside actors, outside systems | G3 | always | always | always | always |
-| `_platform/c4-l2-containers.md` | Containers, their technology, their relations, and the PC × container matrix. **Owns the container list** | G3 | always | always | always | always |
-| `_platform/c4-l3-<container>.md` | One file per `built: true` container holding more than one Product Component | G3 | always | always | always | always |
-| **`_platform/inventory-db.md`** | **Table list**: `No` · table · owning component · what it holds · **key columns** | G3 | **always** | always | always | always |
-| **`_platform/inventory-api.md`** | **Endpoint list**: `No` · method · path · owning component · description · status | G3 | **always** | always | always | always |
-| **`_platform/inventory-screen.md`** | **Screen list**: `No` · screen · route · owning component · actor · `UC` served | G3 | **always** | always | always | always |
-| `_platform/cross-cutting.md` | One error envelope for the whole product, and the rest of what is shared | G3 | always | always | always | always |
-| `_platform/design-system.md` | Tokens and base elements | G2, optional | optional | optional | optional | optional |
-| `<pc>/SDD-<pc>.md` § Decision Summary | What this component is built as, and the costliest choices reversed | G4 | skeleton | ✓ | ✓ | ✓ |
-| `<pc>/SDD-<pc>.md` § Structure | The `LC` list and their dependency direction | G4 | skeleton | ✓ | ✓ | ✓ |
-| `<pc>/SDD-<pc>.md` § Inherited Constraints | The `AD-N` binding this component, quoted not paraphrased | G4 | — | — | ✓ | ✓ |
-| **`<pc>/SDD-<pc>.md` § Failure Behaviour** | Per boundary: the other side slow, absent, or lying | G4 | — | — | **✓ every boundary** | ✓ |
-| `<pc>/SDD-<pc>.md` § Robustness Analysis | ABCE per `critical` use case | G4 | — | — | — | ✓ |
-| `<pc>/03-integrations/<name>.md` | A third party: who owns it, and what happens when they change it | G4 | — | — | ✓ if any | ✓ |
-| `<pc>/02-contracts/00-inventory.md` | This component's endpoints, stably numbered | G4 | — | — | — | ✓ |
-| `<pc>/02-contracts/<nn>-<resource>.md` | One endpoint, five lanes: auth · validation · error · rate limit · idempotency | G4 | — | — | — | ✓ |
-| `<pc>/04-components/<name>.md` | Services and jobs | G4 | — | — | — | ✓ |
-| `<pc>/05-model/data-model.md` | Component ERD + **data dictionary per column** | G4 | — | — | — | ✓ |
-| `<pc>/06-flows/<nn>-<flow>.md` | Sequence diagram, only for money, irreversible state, or a third party | G4 | — | — | — | ✓ |
-| `<pc>/01-ux/<screen>.md` | Screens and composites, **field detail per form** | G4 | — | — | — | ✓, or earlier via `wdi-ux` |
-
-Repealed: `_platform/architecture/` (one file does not earn a folder) and `<pc>/supplements/`.
-
-## Registry and derived files
-
-| File | Holds | Present at |
-|---|---|---|
-| `.control/registry/goals.yaml` | `BG` | every mode |
-| `.control/registry/requirements-<slug>.yaml` | `CAP` · `FR` · `NFR` · `UJ`, one file per PRD initiative | every mode |
-| `.control/registry/usecases.yaml` | `UC-N` with `critical` and the `FR` it satisfies | every mode |
-| `.control/registry/components.yaml` → `product_components` | Component · `mode` · `risk_accepted` · `risk_note` · `owns` · `g4_passed` | every mode |
-| `.control/registry/components.yaml` → `containers` | The containers from C4 L2 | every mode |
-| `.control/registry/components.yaml` → `platform_owns` | Entities no Product Component's promise explains. `_platform` is not a component and has no `mode` | every mode |
-| `.control/registry/components.yaml` → `logical_components` | `LC` | boundary from `guarded`; boundary + control at `deep` |
-| `.control/registry/decisions.yaml` · `specs.yaml` · `defects.yaml` · `risks.yaml` · `index.yaml` | Decisions · work · defects · risks · the global `mode` and gate map | every mode |
-| `.how-rendered/blueprint.md` | **The one-page roll-up reviewed at G3** | every mode |
-| `.control/generated/decisions.md` | The flat index of every `DEC-` | every mode |
-| `.control/generated/estimate.md` | The candidate task table | every mode |
-| `.control/generated/rtm` · `status` · `dag` · `components` · `risks` | Traceability and progress | every mode |
-
-## Who owns each file
-
-A skill lands the output of the layer it owns, and landing is part of producing it — never a follow-up
-someone else performs. `../document/corpus-guide.md` holds the binding version of this table.
-
-| Owner | Writes |
-|---|---|
-| `wdi-init` | The registry scaffold, `mode`, `risk_accepted`, component birth, the `SRS`/`SDD` skeletons, the two structure maps |
-| `wdi-problem` | `.what/_product-brief/` |
-| `wdi-product` | `.what/_prd/<initiative>/` |
-| `wdi-blueprint` | `.what/<pc>/` § Actor Register + § UC Catalogue + `03-domain/domain-model.md` · `.what/business-rules.md` · `.control/product-glossary.md` · all of `.how/_platform/` except `design-system.md` |
-| `wdi-component` | `.what/<pc>/` slots `02`–`05` · `.how/<pc>/` except `01-ux/` |
-| `wdi-ux` | `EXPERIENCE.md` · `.how/<pc>/01-ux/` · `.how/_platform/design-system.md` |
-| `wdi-build` | `specs.yaml` · `.scratch/<spec-id>-<slug>/` · `src/` · `web/` |
-| `wdi-decision` | `.control/decisions/` · `decisions.yaml`, and at apply time whatever `touches` names — through each file's owner |
-| `wdi-question` | `.control/questions/` |
-| `wdi-log` | `.control/meetings/` · `.control/project-non-technical-log.md` |
-| `wdi-report` | `.control/reports/<period>.md` |
-| a script | everything in `.control/generated/`, and the three inventories once code exists |
-
-Five skills write **no file at all**, and that is deliberate: `wdi-reconcile`, `wdi-help`, `wdi-explain-to-me`,
-`wdi-report` intent `dispatch`, and `wdi-review` apart from one frontmatter block. What reports MUST NOT
-also change things — otherwise there is nothing left to check with.
-
-## How the units of work line up
-
-`FR` is a **promise** and permanent; a spec is a **unit of work** and temporary; `SPEC.md` is the machine
-contract for one spec — written from size `M` up, and at `S` the tickets are the contract; a ticket is one
-vertical slice one builder takes to a green PR.
-
-One spec = one parent issue, and a ticket is an **issue**, not a sub-task, because its blocking edges are
-what make the frontier visible in the tracker's own UI. **`FR` is not an issue** — it travels as a label,
-because one `FR` can be delivered by tickets in two specs and one ticket can satisfy part of two `FR`.
-
-The binding version of all of this, including why a spec MAY cross components and what has to be true
-first, is in `../document/delivery-flow-guide.md`. It is not restated here.
-
-## What needs no template, and why
-
-Stated so the next completeness audit does not report it again:
-
-| File | Why it has no template |
-|---|---|
-| `.control/generated/*` | Script output. Its shape is code, not a template |
-| `.control/reports/<period>.md` | Rendered by `timeline.py` |
-| `.control/project-non-technical-log.md` | States its own entry shape in its own header, and there is exactly one such file |
-| `SPEC.md` · ticket files | Their shape belongs to `to-spec` and `to-tickets`. WDI owns where they land, not how they read |
-| Registry `*.yaml` | Their shape is the comment block at the head of each file, plus the validator |
-
-Everything else in this map has a template in `../document/templates/` — 26 of them, and every row above is
-covered by one.
+---
+status: Reference
+---
+
+# Artifact Map — what exists, where, and who owns it
+
+**Opened when:** someone asks *"where does this file go"*, or *"does this document exist at my `mode`"*.
+
+This file **explains**. It does not bind — `../document/*-guide.md` does, and where the two disagree the guide
+wins and the disagreement is a defect to report.
+
+It answers three questions and nothing else: which files exist at each `mode`, who owns each one, and how
+the units of work line up. The **rules** about depth live in `../document/delivery-flow-guide.md`; what is
+here is the map. What `mode` and `risk_accepted` do **together**, cell by cell, is in `mode-risk-map.md`.
+
+## The one thing to read first
+
+Nine things exist at **every** `mode`, including `catalog`, because they belong to the blueprint at G3 and
+the depth knob does not reach the blueprint:
+
+> the use case list · the API list · the table list with its key columns · the screen list · the domain
+> model · the actor list · the spine `AD-N` · C4 L1 + L2 + L3 · cross-component business rules
+
+That is why nobody needs a fifth mode. The request behind wanting one is almost always *"I need at minimum
+the use cases, the API, and the database"* — and all three are already in `catalog`.
+
+## What each mode gives you, cumulatively
+
+| `mode` | What you hold |
+|---|---|
+| `catalog` | The nine above. **Zero extra files per component** |
+| `outline` | + `Decision Summary` · the `LC` list per component · full flows for at most 3 use cases · local business rules |
+| `guarded` | + `Failure Behaviour` for every boundary · `Inherited Constraints` · third-party integration documents · boundary `LC` registered |
+| `deep` | + ABCE robustness analysis · five-lane contract spec per endpoint · data dictionary per column · flow diagrams · state machines · branch scenarios · every `critical` use case gets a full flow |
+
+Marks used below: **always** = present at all four modes, born at G1, G2, or G3 · ✓ = written at that mode
+· skeleton = the file exists carrying headings and frontmatter · — = not written at all.
+
+## `.what/`
+
+| File | Holds | Born | `catalog` | `outline` | `guarded` | `deep` |
+|---|---|---|---|---|---|---|
+| `_product-brief/brief.md` | Problem, users, measure of success, non-goals | G1 | always | always | always | always |
+| `_product-brief/addendum.md` | Depth that does not fit the brief's narrative | G1 | always | always | always | always |
+| `_prd/<initiative>/prd.md` | `CAP` · `FR` · `NFR` · `UJ` · one proof of done per `FR` | G2 | always | always | always | always |
+| `_prd/<initiative>/addendum.md` | Rejected alternatives, option matrices, sizing | G2 | always | always | always | always |
+| `experience.md` | The experience every component keeps: foundation, IA, voice, flow map, journeys across components | G2, optional | optional | optional | optional | optional |
+| `<pc>/04-usecases/EXPERIENCE.md` | The user-facing journey | G2, optional | optional | optional | optional | optional |
+| `business-rules.md` | `BR-N` binding more than one component | G3 | always | always | always | always |
+| **`<pc>/SRS-<pc>.md`** | § Actor Register · **§ UC Catalogue — this is the use case list** · Constraints · Non-Goals · Prerequisite · Assumptions/Risks/TBC | G3 | **always** | always | always | always |
+| `<pc>/03-domain/domain-model.md` | Entities · relations · columns | G3 | always | always | always | always |
+| `<pc>/02-rules/rules-<pc>.md` | Rules binding only this component | G4 | — | ✓ | ✓ | ✓ |
+| `<pc>/04-usecases/UC-<n>-<slug>.md` | One full flow, at most eight steps | G4 | — | max **3** | max **3** | every `critical` UC |
+| `<pc>/03-domain/state-machines.md` | The lifecycle of each multi-state entity | G4 | — | — | — | ✓ |
+| `<pc>/05-scenarios/SCN-<nn>-<slug>.md` | A branch that does not fit its use case file | G4 | — | — | — | ✓ |
+
+**So `SRS-<pc>.md` exists at `mode: catalog`.** It carries the actor list and the use case catalogue. What
+is absent there is the `UC-<n>-<slug>.md` files — the step-by-step flows.
+
+Repealed: `<pc>/01-requirements/` (permanently empty; `FR` live in the PRD and the SRS cites them) and
+`<pc>/supplements/` (existed for `ANX-`).
+
+## `.how/`
+
+| File | Holds | Born | `catalog` | `outline` | `guarded` | `deep` |
+|---|---|---|---|---|---|---|
+| `_platform/ARCHITECTURE-SPINE.md` | `AD-N` — Binds · Prevents · Rule. Invariants only | G3 | always | always | always | always |
+| `_platform/c4-l1-system-context.md` | System, outside actors, outside systems | G3 | always | always | always | always |
+| `_platform/c4-l2-containers.md` | Containers, their technology, their relations, and the PC × container matrix. **Owns the container list** | G3 | always | always | always | always |
+| `_platform/c4-l3-<container>.md` | One file per `built: true` container holding more than one Product Component | G3 | always | always | always | always |
+| **`_platform/inventory-db.md`** | **Table list**: `No` · table · owning component · what it holds · **key columns** | G3 | **always** | always | always | always |
+| **`_platform/inventory-api.md`** | **Endpoint list**: `No` · method · path · owning component · description · status | G3 | **always** | always | always | always |
+| **`_platform/inventory-screen.md`** | **Screen list**: `No` · screen · route · owning component · actor · `UC` served | G3 | **always** | always | always | always |
+| `_platform/cross-cutting.md` | One error envelope for the whole product, and the rest of what is shared | G3 | always | always | always | always |
+| `_platform/design-system.md` | Tokens, base elements, and the build patterns every component shares | G2, optional | optional | optional | optional | optional |
+| `<pc>/SDD-<pc>.md` § Decision Summary | What this component is built as, and the costliest choices reversed | G4 | skeleton | ✓ | ✓ | ✓ |
+| `<pc>/SDD-<pc>.md` § Structure | The `LC` list and their dependency direction | G4 | skeleton | ✓ | ✓ | ✓ |
+| `<pc>/SDD-<pc>.md` § Inherited Constraints | The `AD-N` binding this component, quoted not paraphrased | G4 | — | — | ✓ | ✓ |
+| **`<pc>/SDD-<pc>.md` § Failure Behaviour** | Per boundary: the other side slow, absent, or lying | G4 | — | — | **✓ every boundary** | ✓ |
+| `<pc>/SDD-<pc>.md` § Robustness Analysis | ABCE per `critical` use case | G4 | — | — | — | ✓ |
+| `<pc>/03-integrations/<name>.md` | A third party: who owns it, and what happens when they change it | G4 | — | — | ✓ if any | ✓ |
+| `<pc>/02-contracts/00-inventory.md` | This component's endpoints, stably numbered | G4 | — | — | — | ✓ |
+| `<pc>/02-contracts/<nn>-<resource>.md` | One endpoint, five lanes: auth · validation · error · rate limit · idempotency | G4 | — | — | — | ✓ |
+| `<pc>/04-components/<name>.md` | Services and jobs | G4 | — | — | — | ✓ |
+| `<pc>/05-model/data-model.md` | Component ERD + **data dictionary per column** | G4 | — | — | — | ✓ |
+| `<pc>/06-flows/<nn>-<flow>.md` | Sequence diagram, only for money, irreversible state, or a third party | G4 | — | — | — | ✓ |
+| `<pc>/01-ux/<screen>.md` | Screens and composites, **field detail per form** | G4 | — | — | — | ✓, or earlier via `wdi-ux` |
+
+Repealed: `_platform/architecture/` (one file does not earn a folder) and `<pc>/supplements/`.
+
+## Registry and derived files
+
+| File | Holds | Present at |
+|---|---|---|
+| `.control/registry/goals.yaml` | `BG` | every mode |
+| `.control/registry/requirements-<slug>.yaml` | `CAP` · `FR` · `NFR` · `UJ`, one file per PRD initiative | every mode |
+| `.control/registry/usecases.yaml` | `UC-N` with `critical` and the `FR` it satisfies | every mode |
+| `.control/registry/components.yaml` → `product_components` | Component · `mode` · `risk_accepted` · `risk_note` · `owns` · `g4_passed` | every mode |
+| `.control/registry/components.yaml` → `containers` | The containers from C4 L2 | every mode |
+| `.control/registry/components.yaml` → `platform_owns` | Entities no Product Component's promise explains. `_platform` is not a component and has no `mode` | every mode |
+| `.control/registry/components.yaml` → `logical_components` | `LC` | boundary from `guarded`; boundary + control at `deep` |
+| `.control/registry/decisions.yaml` · `specs.yaml` · `defects.yaml` · `risks.yaml` · `index.yaml` | Decisions · work · defects · risks · the global `mode` and gate map | every mode |
+| `.how-rendered/blueprint.md` | **The one-page roll-up reviewed at G3** | every mode |
+| `.control/generated/decisions.md` | The flat index of every `DEC-` | every mode |
+| `.control/generated/estimate.md` | The candidate task table | every mode |
+| `.control/generated/rtm` · `status` · `dag` · `components` · `risks` | Traceability and progress | every mode |
+
+## Who owns each file
+
+A skill lands the output of the layer it owns, and landing is part of producing it — never a follow-up
+someone else performs. `../document/corpus-guide.md` holds the binding version of this table.
+
+| Owner | Writes |
+|---|---|
+| `wdi-init` | The registry scaffold, `mode`, `risk_accepted`, component birth, the `SRS`/`SDD` skeletons, the two structure maps |
+| `wdi-problem` | `.what/_product-brief/` |
+| `wdi-product` | `.what/_prd/<initiative>/` |
+| `wdi-blueprint` | `.what/<pc>/` § Actor Register + § UC Catalogue + `03-domain/domain-model.md` · `.what/business-rules.md` · `.control/product-glossary.md` · all of `.how/_platform/` except `design-system.md` |
+| `wdi-component` | `.what/<pc>/` slots `02`–`05` · `.how/<pc>/` except `01-ux/` |
+| `wdi-ux` | `.what/experience.md` · `EXPERIENCE.md` · `.how/<pc>/01-ux/` · `.how/_platform/design-system.md` |
+| `wdi-build` | `specs.yaml` · `.scratch/<spec-id>-<slug>/` · `src/` · `web/` |
+| `wdi-decision` | `.control/decisions/` · `decisions.yaml`, and at apply time whatever `touches` names — through each file's owner |
+| `wdi-question` | `.control/questions/` |
+| `wdi-log` | `.control/meetings/` · `.control/project-non-technical-log.md` |
+| `wdi-report` | `.control/reports/<period>.md` |
+| a script | everything in `.control/generated/`, and the three inventories once code exists |
+
+Five skills write **no file at all**, and that is deliberate: `wdi-reconcile`, `wdi-help`, `wdi-explain-to-me`,
+`wdi-report` intent `dispatch`, and `wdi-review` apart from one frontmatter block. What reports MUST NOT
+also change things — otherwise there is nothing left to check with.
+
+## How the units of work line up
+
+`FR` is a **promise** and permanent; a spec is a **unit of work** and temporary; `SPEC.md` is the machine
+contract for one spec — written from size `M` up, and at `S` the tickets are the contract; a ticket is one
+vertical slice one builder takes to a green PR.
+
+One spec = one parent issue, and a ticket is an **issue**, not a sub-task, because its blocking edges are
+what make the frontier visible in the tracker's own UI. **`FR` is not an issue** — it travels as a label,
+because one `FR` can be delivered by tickets in two specs and one ticket can satisfy part of two `FR`.
+
+The binding version of all of this, including why a spec MAY cross components and what has to be true
+first, is in `../document/delivery-flow-guide.md`. It is not restated here.
+
+## What needs no template, and why
+
+Stated so the next completeness audit does not report it again:
+
+| File | Why it has no template |
+|---|---|
+| `.control/generated/*` | Script output. Its shape is code, not a template |
+| `.control/reports/<period>.md` | Rendered by `timeline.py` |
+| `.control/project-non-technical-log.md` | States its own entry shape in its own header, and there is exactly one such file |
+| `SPEC.md` · ticket files | Their shape belongs to `to-spec` and `to-tickets`. WDI owns where they land, not how they read |
+| Registry `*.yaml` | Their shape is the comment block at the head of each file, plus the validator |
+
+Everything else in this map has a template in `../document/templates/` — 26 of them, and every row above is
+covered by one.

package/kit/.constitution/method/why/portability.md

@@ -56,9 +56,26 @@ others leaves a method that cannot run:
 | Set | Note |
 |---|---|
 | `.constitution/` | Minus the product articles; `promote` / `install` handle the seam |
-| `.claude/skills/wdi-*/` (and `.agents/skills/wdi-*/` when those agents are selected) | Every wrapper. A wrapper without its guide, or a guide without its wrapper, is half a method |
+| `.<host>/skills/wdi-*/` for every host selected at install | Every wrapper. A wrapper without its guide, or a guide without its wrapper, is half a method |
 | `_bmad/custom/*.toml` | The one most likely to be forgotten. `*.user.toml` stays behind |
-| `AGENTS.md` | The routing table is the method; from `## Code` down is the product. `install` / `update` MUST NOT overwrite an existing `AGENTS.md` |
+| `AGENTS.md`, and each rule file a selected host reads beside it | The routing table is the method; from `## Code` down is the product. `install` / `update` MUST NOT overwrite an existing `AGENTS.md` |
+
+## One method, many hosts
+
+The method runs on every host the installer offers, and each host differs in five ways that matter.
+`lib/platforms.mjs` in the package is the one record of them; `install` writes the selected hosts into
+`.control/wdi-method.yaml` under `hosts:`, and the skills and `validate.py` read them from there.
+
+| Difference | What the method does about it |
+|---|---|
+| **Where skills are read** (`reads:`) | The `wdi-*` skills go to each host's own folder. The six engines MUST be in a folder every selected host reads — Kiro reads only `.kiro/skills` — and `npx wdi-method engines` names the `npx skills add --agent` that puts them there |
+| **How a skill is loaded** | Through the host's own mechanism: a skill tool where it has one, otherwise reading the whole `SKILL.md`. Both are invocation; a paraphrase is neither |
+| **How a person types one** (`invoke:`) | `/name`, `$name`, `/skill:name`, `@name`, or asked for by name. `wdi-help` names the next skill in this host's form |
+| **Manual-only** (`manual_only:`) | Three layers. The host's own lock where it has one (`disable-model-invocation`; `.claude/settings.json` deny rules; `opencode.json` `ask`). A guard line at the top of each manual-only skill. The `AGENTS.md` block, mirrored into every rule file a host reads. On a host with no lock the last two are all there is, and that is the host's limit, not a gap in the install |
+| **A scheduler of its own** (`loop:`) | `wdi-daily-autopilot` and `wdi-autopilot` start it where it exists. Where it does not, they run one iteration per invocation — a shell loop or an OS scheduler is not a substitute |
+
+A host the method dropped is named by `update` and left alone: its folders may hold the product's own
+files too, so removing them is the owner's call.
 
 ## Two directions
 

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

@@ -43,8 +43,8 @@ NOT start the loop while any row in the first two groups is red.
 | **Engines** | BMad installed; every `wdi-*` skill the run will call present | A wrapper is missing — name it and `npx wdi-method update` |
 | | All six engines present IN this repo — `to-spec` · `to-tickets` · `implement` · `tdd` · `code-review` · `domain-modeling` — with the **path** of each `SKILL.md` | Any missing. `npx skills@latest add mattpocock/skills`; a user-level plugin does not count |
 | | The three flagged engines are **invocable**: no `disable-model-invocation` in the repo's copies | Any still flagged — no skill can invoke it, so Phase 2 would stall. `npx wdi-method engines --fix`, or the `wdi-init` / `wdi-upgrade` skill |
-| | The retired BMad G5 wrappers are locked out of model invocation, and `.claude/settings.json` denies them | Any still invocable. Same fix — BMad's installer restores its wrappers whenever it runs |
-| | This skill and `wdi-build` are themselves invocable — no `skillOverrides` entry in `settings.json` set to `off` or `user-invocable-only` | Either is overridden. Nothing else can start the loop, and the override is silent |
+| | The retired BMad G5 wrappers are locked out of model invocation wherever this host offers a lock (`.claude/settings.json` deny rules, `opencode.json` `ask`) | Any still invocable. Same fix — BMad's installer restores its wrappers whenever it runs |
+| | This skill and `wdi-build` are themselves invocable — on Claude Code, no `skillOverrides` entry in `settings.json` set to `off` or `user-invocable-only` | Either is overridden. Nothing else can start the loop, and the override is silent |
 | | The tracker the engines publish to is configured — `docs/agents/issue-tracker.md`, written once by `/setup-matt-pocock-skills` | Missing. `to-tickets` would stop to ask for it, and this skill never asks; the owner runs the setup before confirming |
 | | Reviewers separate from the builder can be dispatched | The session cannot spawn a second agent and any touched component is `risk_accepted: low` — Step 3 of `wdi-build` would block |
 | | `.constitution/project/codebase-stack-guide.md` names build and test commands, **and the test command exits 0 here** (prefer quiet output flags, e.g. `-- --quiet`, to keep context compact; on non-zero exit, surface the failure details and abort preflight) | Absent or failing. Every ticket's "full suite green once" and the smoke test read it. Found at minute one, not at hour six |
@@ -57,8 +57,8 @@ NOT start the loop while any row in the first two groups is red.
 | **Settings** | `scope` — the `FR` ids to deliver, or `all` | — (default `all` open `FR`) |
 | | `parked` — what stops for the owner instead of being decided: any of `promise` · `ad-n` · `sensitive` | — (default **`ad-n`**, and nothing else. `decision-guide.md` says narrowing an invariant MUST NOT be softened further, so removing it is the owner's to say out loud — not a default they never saw) |
 | | `smoke_test` — `agent` or `owner` | — (default `agent`, and **`owner` when `codebase-stack-guide.md` names no way to run the app** — an agent cannot smoke-test what it cannot launch) |
-| | `loop` — the interval between iterations | — (default `5m`) |
-| | `expires` — the date the mandate lapses | — (default 7 days from today; a `/loop` task expires then too) |
+| | `loop` — the interval between iterations | — (default `5m`). On a host with no scheduler of its own (`loop: none` in `hosts:`) the row reads **once** — see § Starting the loop |
+| | `expires` — the date the mandate lapses | — (default 7 days from today; a scheduled task expires then too) |
 | | Where the ledger and the final report will be written | — |
 | | The **run branch** — `autopilot/<mandate-id>`, using the next free `DEC-` id from `decisions.yaml`, which the mandate then takes — and that the run will open **one** PR from it | The branch already exists with commits nobody can account for |
 | **Runtime** | The session runs with permission prompts bypassed | Cannot be verified from inside the session. Printed as a line the owner confirms |
@@ -69,15 +69,16 @@ the same rule the installer follows. A preflight that asks fourteen questions on
 
 ### The engines are invoked — there is no route to find
 
-`to-spec`, `to-tickets` and `implement` ship with `disable-model-invocation: true`, which blocks the Skill
-tool for this session and every subagent, and no setting lifts it: the gate reads the frontmatter and
-consults nothing else. Two releases of this skill worked around that by reading the engine's `SKILL.md`
-and carrying out its process. **That route is retired.** The engines are installed in the repo, the
-installer strips the flag from the repo's own copies, and `wdi-build` invokes them like any other skill.
+`to-spec`, `to-tickets` and `implement` ship with `disable-model-invocation: true`. Where the host
+honours that key it blocks every model-initiated load, and no setting lifts it. The engines are installed
+in the repo, the installer strips the flag from the repo's own copies, and `wdi-build` invokes them like
+any other skill — through the host's own skill mechanism, which on a host with no skill tool is reading the
+engine's whole `SKILL.md` from the repo (`wdi-build` § All six engines).
 
-What preflight checks is therefore not *which route exists* but *whether the flag is back* — `npx skills
-update` restores the author's file byte for byte, and `engines-invocable` in `validate.py` is red when it
-has. A stalled Phase 2 three hours into an unattended run is what this replaces.
+What preflight checks is therefore not *which route exists* but *whether the flag is back* and *whether
+this host can see the engines* — `npx skills update` restores the author's file byte for byte, an engine
+installed for one host is invisible to another, and `engines-invocable` in `validate.py` is red for both.
+A stalled Phase 2 three hours into an unattended run is what this replaces.
 
 The `to-tickets` quiz — granularity and blocking edges — is still **answered by this skill**: ticket
 count from the size table in `delivery-flow-guide.md`, edges from `depends_on` and `touches`. The answers
@@ -96,19 +97,31 @@ On the owner's confirmation, and not before:
    `smoke_test` · `loop` · `expires` — live **only** on its row in `decisions.yaml`; the file carries
    Decision, Why, and Cost, and points at the row. One fact, one home.
 2. Write the ledger header — see § The ledger.
-3. Start the loop. In Claude Code, invoke the `loop` skill with `<interval> /wdi-autopilot`. Where that is
-   not available, print the command for the owner to type, and name the alternative the platform has:
+3. Start the loop — § Starting the loop.
 
-```
-/loop 5m /wdi-autopilot
-```
+### Starting the loop
+
+The loop is the **host's own scheduler**, and nothing else counts: a shell `while`, an OS cron job, or a
+second agent firing this one is not a loop this skill starts. Read this host's `loop:` from `hosts:` in
+`.control/wdi-method.yaml` (the entry whose `id` is the host running this session):
+
+| `loop:` | What this skill does |
+|---|---|
+| `{kind: command, how: …}` | Types the command, filling `{interval}` and `{prompt}` (`/wdi-autopilot`) — e.g. `/loop 5m /wdi-autopilot` on Claude Code |
+| `{kind: scheduler, how: …}` | Creates the schedule the way `how` names it, with the same interval and prompt |
+| `none` | **Runs one iteration now**, in this turn (Door 2), and reports that this host has no scheduler: the next iteration starts when the owner invokes this skill again. The mandate, the ledger, and the branch carry over unchanged, so each invocation resumes where the last stopped |
+
+A host missing from `hosts:` (an old stamp) is treated as `none`. The `none` row is not a lesser run: one
+iteration works as far as it safely can, exactly as a scheduled one does, and stops only at the same three
+stops.
 
 The interval is the **pause between** iterations, not the length of one. An iteration that outlives it
-finishes first; the next firing waits.
+finishes first; the next firing waits. "Cancel the loop", wherever this skill says it, means cancelling
+that scheduled task; where there is none, it means nothing further is started.
 
 **Session survivability across environments:**
 - **Linux / Remote SSH:** Run inside a session manager such as `tmux` (`tmux new -s autopilot`) or `screen` before starting the loop. Disconnecting SSH or closing the terminal then leaves the autonomous loop running unharmed.
-- **Windows (PowerShell / Windows Terminal):** `tmux` is not native to Windows PowerShell. Run the session in a dedicated persistent Windows Terminal tab or window left active, or via background subagent tools (`run_in_background`). Do not invoke or require `tmux` on Windows environments.
+- **Windows (PowerShell / Windows Terminal):** `tmux` is not native to Windows PowerShell. Run the session in a dedicated persistent Windows Terminal tab or window left active. Do not invoke or require `tmux` on Windows environments.
 
 ## Door 2 — One iteration