wdi-method 0.6.31 → 0.6.32

package/kit/.constitution/method/document/bmad-skill-register.md

@@ -1,104 +1,107 @@
----
-status: Accepted
----
-
-# BMad Skill Register
-
-**Loaded when:** deciding which BMad skill a piece of work needs, or checking what one writes
-
-This used to be the full catalogue of all 59 installed BMad skills. **That catalogue is retired.** It was a
-copy of somebody else's inventory, it went stale on every BMad update, and nothing in this method read more
-than a dozen of its rows. What binds is the division of labour below; for anything about a BMad skill this
-method does not invoke, ask `bmad-help`, which reads BMad's own documentation.
-
-## Who writes what
-
-| Artifact | Written by | Wrapped in |
-|---|---|---|
-| Product brief | `bmad-product-brief` | `wdi-problem` |
-| PRD | `bmad-prd` | `wdi-product` |
-| UX — `EXPERIENCE.md` + `DESIGN.md` | `bmad-ux` | `wdi-ux` |
-| Architecture spine + the C4 set | `bmad-architecture` | `wdi-blueprint` intent `platform` |
-| **UC catalogue · actors · entities · business rules** | **nothing in BMad** | `wdi-blueprint` writes it itself |
-| **SRS and all of `.what/<pc>/`** | **nothing in BMad** | `wdi-component` writes it itself |
-| **SDD and all of `.how/<pc>/`** | **nothing in BMad** | `wdi-component` writes it itself |
-| Document review | `bmad-review` | `wdi-review` |
-| Course correction | `bmad-correct-course` | `wdi-decision` |
-
-**Everything below G5 left this table.** `SPEC.md`, the tickets, the code, and the code panel are produced
-by `to-spec`, `to-tickets`, `implement`, `tdd`, and `code-review` — engines that are not BMad's. Three of
-the five ship with `disable-model-invocation: true`; `wdi-method` strips it from the copies installed in
-this repo and writes a guard line naming who may drive them, so **`wdi-build` and `wdi-autopilot` invoke
-them directly** and an unattended iteration needs nobody. `wdi-build` owns that pipeline;
-`bmad-guide.md` owns the reasoning.
-
-**The three bold rows are why this method exists.** BMad stops at the promise and starts again at the
-mechanism, and every behaviour in between had no author. Three consequences attach to those artifacts and
-MUST be handled deliberately rather than discovered: no `doc_standards` fires a review, no memlog is born on
-its own, and no template enforces itself.
-
-## No BMad skill is invoked directly
-
-Every one above has a wrapper, and the wrapper is what checks position, verifies the result against the
-guide, and lands the memlog. Routing past it produces an artifact nothing verifies.
-
-**One exception, and it is narrow:** on the Fast Path the owner runs `/implement` directly, with no wrapper.
-A Fast Path that turns out to touch an `FR` MUST stop and become a spec `S`, which puts it back inside
-`wdi-build`.
-
-## What is available but writes nothing
-
-| Skill | Use |
-|---|---|
-| `bmad-advanced-elicitation` · `bmad-party-mode` | Thinking aids. They produce no artifact and MUST NOT be treated as authors |
-| `bmad-deep-recon` | Research, before a brief rests on outside data. Its output stays in `_bmad-output/` permanently and MUST NOT be folded into the brief |
-| `bmad-qa-generate-e2e-tests` | Tests for a feature that **already exists**. `tdd` is test-first for work being built, so this has no replacement here and is NOT retired — but what it writes is a test, never a contract, and it MUST NOT be read as one |
-| `bmad-checkpoint-preview` | A human reading aid over a change, the same class as `bmad-advanced-elicitation`. It MUST NOT be counted as the Step 3 panel: that one is a separate dispatch by a different agent |
-| `bmad-help` | Questions about BMad itself. It MUST NOT be used to answer "where am I" — that is `wdi-help` |
-
-## What is NOT USED, and MUST NOT be
-
-**The criterion, and it binds every row below.** A BMad skill is retired only where this method has a
-**named replacement** for what it produces. Without one it is not retired — it goes in the table above
-instead, as something that may be used but MUST NOT author. Banning a capability with nothing in its
-place is how a method gets worked around rather than followed.
-
-### Retired at G5 — enforced by install and update
-
-**This is enforced, not only stated.** `install` and `update` set `disable-model-invocation: true` on
-every wrapper below and add a `Skill(<name>)` deny rule to `.claude/settings.json`, both re-applied on
-every run because BMad's installer rewrites its own wrappers. A person typing `/bmad-build` still gets
-it: the method retires a default, it does not confiscate a tool. The list lives in
-`bin/wdi-method.js` as `BMAD_RETIRED_G5`, and a test fails when this table and that array disagree.
-
-| Skill | Replaced by | Why |
-|---|---|---|
-| `bmad-spec` | `to-spec` | **Retired.** The contract below G5 is no longer BMad's. Its `_bmad/custom/*.toml` override is withdrawn and `update` removes any still installed |
-| `bmad-build` · `bmad-build-auto` | `implement` · `wdi-autopilot` | **Retired.** `bmad-build` describes itself as implementing "any user intent, requirement, story, bug fix or change request" — the most inviting description in the repo's skill index, for the one thing this method owns most tightly. `bmad-build-auto` is an unattended loop, which is `wdi-autopilot`'s |
-| `bmad-code-review` | `code-review` | **Retired.** The panel at Step 3 is a separate dispatch by a different agent; BMad's own review layers are the builder reviewing itself |
-| `bmad-retrospective` | — | **Retired** with `RTR-` and `V19`. A frozen `RTR-` file stays where it is |
-| `bmad-agent-dev` | `implement` | **Retired.** "Senior software engineer for story execution and code implementation" is `implement`'s sentence |
-| `bmad-create-epics-and-stories` | `to-tickets` | **Retired**, and not merely by preference: the `epics` level between a spec and its tickets is **repealed in code** — `validate.py` reads a flat `tickets:` list. A skill whose only output is a shape nothing reads |
-| `bmad-create-story` · `bmad-dev-story` · `bmad-dev-auto` · `bmad-quick-dev` | `implement` | **Retired.** BMad deprecated all four in favour of `bmad-build`, which is itself retired here. An alias to a retired skill is retired |
-| `bmad-sprint-planning` · `bmad-sprint-status` | the ticket itself | **Retired.** The sprint route keeps status in a hand-edited file; this method reads status from the ticket — `bmad-guide.md` owns the reasoning |
-
-### Not used for other reasons — not enforced, and not G5's
-
-These are outside the enforced list above: nothing locks them, because nothing here replaces them and
-none of them competes for G5's work.
-
-| Skill | Why |
-|---|---|
-| `bmad-editorial-review*` · `bmad-review-*` | Shims onto `bmad-review` lenses. Ask for the lens, not the shim |
-| `bmad-document-project` · `bmad-generate-project-context` | Forward to `bmad-project-context`. This repo's agent instructions are maintained by hand |
-| Any skill named as a **gate condition** | A gate is passed by its checklist and its validators, never by a skill having run |
-
-## The class that decides where output lands
-
-`bmad-guide.md` owns the class definitions; what matters here is that **class B** exists because some skills
-write several things at once that belong to different layers. `bmad-ux` is the case: `EXPERIENCE.md` is a
-promise and `DESIGN.md` is a build detail, and no configuration can send them to two places. Its output
-lands in a neutral folder first, and `wdi-ux` places it.
-
-Which skill lands which output is the ownership table in `corpus-guide.md`, and it MUST NOT be duplicated
-here.
+---
+status: Accepted
+---
+
+# BMad Skill Register
+
+**Loaded when:** deciding which BMad skill a piece of work needs, or checking what one writes
+
+This used to be the full catalogue of all 59 installed BMad skills. **That catalogue is retired.** It was a
+copy of somebody else's inventory, it went stale on every BMad update, and nothing in this method read more
+than a dozen of its rows. What binds is the division of labour below; for anything about a BMad skill this
+method does not invoke, ask `bmad-help`, which reads BMad's own documentation.
+
+## Who writes what
+
+| Artifact | Written by | Wrapped in |
+|---|---|---|
+| Product brief | `bmad-product-brief` | `wdi-problem` |
+| PRD | `bmad-prd` | `wdi-product` |
+| UX — `EXPERIENCE.md` + `DESIGN.md` | `bmad-ux` | `wdi-ux` |
+| Architecture spine + the C4 set | `bmad-architecture` | `wdi-blueprint` intent `platform` |
+| **UC catalogue · actors · entities · business rules** | **nothing in BMad** | `wdi-blueprint` writes it itself |
+| **SRS and all of `.what/<pc>/`** | **nothing in BMad** | `wdi-component` writes it itself |
+| **SDD and all of `.how/<pc>/`** | **nothing in BMad** | `wdi-component` writes it itself |
+| Document review | `bmad-review` | `wdi-review` |
+| Course correction | `bmad-correct-course` | `wdi-decision` |
+
+**Everything below G5 left this table.** `SPEC.md`, the tickets, the code, and the code panel are produced
+by `to-spec`, `to-tickets`, `implement`, `tdd`, and `code-review` — engines that are not BMad's. Three of
+the five ship with `disable-model-invocation: true`; `wdi-method` strips it from the copies installed in
+this repo and writes a guard line naming who may drive them, so **`wdi-build` and `wdi-autopilot` invoke
+them directly** and an unattended iteration needs nobody. `wdi-build` owns that pipeline;
+`bmad-guide.md` owns the reasoning.
+
+**The three bold rows are why this method exists.** BMad stops at the promise and starts again at the
+mechanism, and every behaviour in between had no author. Three consequences attach to those artifacts and
+MUST be handled deliberately rather than discovered: no `doc_standards` fires a review, no memlog is born on
+its own, and no template enforces itself.
+
+## No BMad skill is invoked directly
+
+Every one above has a wrapper, and the wrapper is what checks position, verifies the result against the
+guide, and lands the memlog. Routing past it produces an artifact nothing verifies.
+
+**One exception, and it is narrow:** on the Fast Path the owner runs `/implement` directly, with no wrapper.
+A Fast Path that turns out to touch an `FR` MUST stop and become a spec `S`, which puts it back inside
+`wdi-build`.
+
+## What is available but writes nothing
+
+| Skill | Use |
+|---|---|
+| `bmad-advanced-elicitation` · `bmad-party-mode` | Thinking aids. They produce no artifact and MUST NOT be treated as authors |
+| `bmad-deep-recon` | Research, before a brief rests on outside data. Its output stays in `_bmad-output/` permanently and MUST NOT be folded into the brief |
+| `bmad-qa-generate-e2e-tests` | Tests for a feature that **already exists**. `tdd` is test-first for work being built, so this has no replacement here and is NOT retired — but what it writes is a test, never a contract, and it MUST NOT be read as one |
+| `bmad-checkpoint-preview` | A human reading aid over a change, the same class as `bmad-advanced-elicitation`. It MUST NOT be counted as the Step 3 panel: that one is a separate dispatch by a different agent |
+| `bmad-help` | Questions about BMad itself. It MUST NOT be used to answer "where am I" — that is `wdi-help` |
+
+## What is NOT USED, and MUST NOT be
+
+**The criterion, and it binds every row below.** A BMad skill is retired only where this method has a
+**named replacement** for what it produces. Without one it is not retired — it goes in the table above
+instead, as something that may be used but MUST NOT author. Banning a capability with nothing in its
+place is how a method gets worked around rather than followed.
+
+### Retired at G5 — enforced by install and update
+
+**This is enforced, not only stated — as far as each host allows.** `install` and `update` set
+`disable-model-invocation: true` on every wrapper below (every host that honours the key holds it),
+add a `Skill(<name>)` deny rule to `.claude/settings.json` for Claude Code and `"<name>": "ask"` under
+`permission.skill` in `opencode.json` for OpenCode, all re-applied on every run because BMad's installer
+rewrites its own wrappers. On a host with no lock at all, the `AGENTS.md` method block — mirrored into
+that host's own rule file — is what forbids them. A person typing `/bmad-build` still gets
+it: the method retires a default, it does not confiscate a tool. The list lives in
+`bin/wdi-method.js` as `BMAD_RETIRED_G5`, and a test fails when this table and that array disagree.
+
+| Skill | Replaced by | Why |
+|---|---|---|
+| `bmad-spec` | `to-spec` | **Retired.** The contract below G5 is no longer BMad's. Its `_bmad/custom/*.toml` override is withdrawn and `update` removes any still installed |
+| `bmad-build` · `bmad-build-auto` | `implement` · `wdi-autopilot` | **Retired.** `bmad-build` describes itself as implementing "any user intent, requirement, story, bug fix or change request" — the most inviting description in the repo's skill index, for the one thing this method owns most tightly. `bmad-build-auto` is an unattended loop, which is `wdi-autopilot`'s |
+| `bmad-code-review` | `code-review` | **Retired.** The panel at Step 3 is a separate dispatch by a different agent; BMad's own review layers are the builder reviewing itself |
+| `bmad-retrospective` | — | **Retired** with `RTR-` and `V19`. A frozen `RTR-` file stays where it is |
+| `bmad-agent-dev` | `implement` | **Retired.** "Senior software engineer for story execution and code implementation" is `implement`'s sentence |
+| `bmad-create-epics-and-stories` | `to-tickets` | **Retired**, and not merely by preference: the `epics` level between a spec and its tickets is **repealed in code** — `validate.py` reads a flat `tickets:` list. A skill whose only output is a shape nothing reads |
+| `bmad-create-story` · `bmad-dev-story` · `bmad-dev-auto` · `bmad-quick-dev` | `implement` | **Retired.** BMad deprecated all four in favour of `bmad-build`, which is itself retired here. An alias to a retired skill is retired |
+| `bmad-sprint-planning` · `bmad-sprint-status` | the ticket itself | **Retired.** The sprint route keeps status in a hand-edited file; this method reads status from the ticket — `bmad-guide.md` owns the reasoning |
+
+### Not used for other reasons — not enforced, and not G5's
+
+These are outside the enforced list above: nothing locks them, because nothing here replaces them and
+none of them competes for G5's work.
+
+| Skill | Why |
+|---|---|
+| `bmad-editorial-review*` · `bmad-review-*` | Shims onto `bmad-review` lenses. Ask for the lens, not the shim |
+| `bmad-document-project` · `bmad-generate-project-context` | Forward to `bmad-project-context`. This repo's agent instructions are maintained by hand |
+| Any skill named as a **gate condition** | A gate is passed by its checklist and its validators, never by a skill having run |
+
+## The class that decides where output lands
+
+`bmad-guide.md` owns the class definitions; what matters here is that **class B** exists because some skills
+write several things at once that belong to different layers. `bmad-ux` is the case: `EXPERIENCE.md` is a
+promise and `DESIGN.md` is a build detail, and no configuration can send them to two places. Its output
+lands in a neutral folder first, and `wdi-ux` places it.
+
+Which skill lands which output is the ownership table in `corpus-guide.md`, and it MUST NOT be duplicated
+here.

package/kit/.constitution/method/scripts/validate.py

@@ -1976,10 +1976,65 @@ def corpus_in_git(c: Corpus, r: Result) -> None:
             pass
 
 
-ENGINE_HOMES = (".claude", ".agents", ".agent", ".cursor", ".codex")
 ENGINE_FLAGGED = ("to-spec", "to-tickets", "implement")
 ENGINE_SKILLS = ENGINE_FLAGGED + ("tdd", "code-review", "domain-modeling")
 FLAG_RE = re.compile(r"^disable-model-invocation\s*:\s*true", re.M)
+STAMP = Path(".control") / "wdi-method.yaml"
+HOST_ID_RE = re.compile(r"^\s+-\s+id:\s*([A-Za-z0-9_.-]+)\s*$")
+HOST_READS_RE = re.compile(r"^\s+reads:\s*\[(.*)\]\s*$")
+
+
+def _skill_roots(root: Path) -> list[Path]:
+    """Every folder in the repo that may hold skills — matched by PATTERN, not by a list of hosts.
+
+    The list this replaced named five folders while the installer offered forty hosts, so engines
+    installed for Kiro, Cline, or Trae were reported as no engines at all. Every `.<host>/skills` at
+    the root counts, plus every directory a host in the stamp's `hosts:` is recorded to read.
+    """
+    found: dict[str, Path] = {}
+    try:
+        entries = sorted(root.iterdir())
+    except OSError:
+        entries = []
+    for entry in entries:
+        if entry.name.startswith(".") and entry.name != ".git" and (entry / "skills").is_dir():
+            found[f"{entry.name}/skills"] = entry / "skills"
+    for reads in _stamp_hosts(root).values():
+        for rel in reads:
+            if (root / rel).is_dir():
+                found.setdefault(rel, root / rel)
+    return list(found.values())
+
+
+def _stamp_hosts(root: Path) -> dict[str, list[str]]:
+    """`hosts:` from `.control/wdi-method.yaml` — host id → the skill folders it reads.
+
+    The installer writes it from `lib/platforms.mjs`; this reads it so the two never keep separate
+    lists. An older stamp has no `hosts:`, and the check then falls back to "anywhere in the repo".
+    """
+    path = root / STAMP
+    if not path.is_file():
+        return {}
+    out: dict[str, list[str]] = {}
+    current = None
+    in_hosts = False
+    for line in path.read_text(encoding="utf-8", errors="replace").splitlines():
+        if re.match(r"^hosts:\s*$", line):
+            in_hosts = True
+            continue
+        if in_hosts and line.strip() and not line.startswith(" "):
+            break
+        if not in_hosts:
+            continue
+        m = HOST_ID_RE.match(line)
+        if m:
+            current = m.group(1)
+            out[current] = []
+            continue
+        m = HOST_READS_RE.match(line)
+        if m and current:
+            out[current] = [s.strip().strip('"').strip("'") for s in m.group(1).split(",") if s.strip()]
+    return out
 
 
 def _engine_files(root: Path, name: str) -> list[Path]:
@@ -1990,8 +2045,8 @@ def _engine_files(root: Path, name: str) -> list[Path]:
     one finding read as two.
     """
     seen: dict[Path, Path] = {}
-    for home in ENGINE_HOMES:
-        path = root / home / "skills" / name / "SKILL.md"
+    for home in _skill_roots(root):
+        path = home / name / "SKILL.md"
         if not path.is_file():
             continue
         try:
@@ -2037,6 +2092,16 @@ def engines_invocable(c: Corpus, r: Result) -> None:
         if not installed[name]:
             r.fail("engines-invocable", name, "is not installed in this repo — G5 needs all six, and "
                               "a user-level plugin does not count: its files are not this repo's to unlock")
+    # Present somewhere is not present for every host. Kiro reads `.kiro/skills` and nothing else, so
+    # an engine only in `.agents/skills` leaves `wdi-build` unable to run there.
+    for host, reads in _stamp_hosts(c.root).items():
+        for name in ENGINE_SKILLS:
+            if not installed[name]:
+                continue
+            if not any((c.root / rel / name / "SKILL.md").is_file() for rel in reads):
+                r.fail("engines-invocable", name,
+                       f"is not in any folder {host} reads ({', '.join(reads)}) — that host cannot "
+                       f"run it. `npx wdi-method engines` names the `npx skills add --agent` to use")
     for name in ENGINE_FLAGGED:
         for path in installed[name]:
             if FLAG_RE.search(_frontmatter(path.read_text(encoding="utf-8", errors="replace"))):

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

@@ -146,7 +146,7 @@ Named for the **gate they serve**, so *"which skill do I run"* is answered by *"
 | Skill | Its trigger |
 |---|---|
 | `wdi-daily-what-to-build` | Hand-testing notes to turn into a reviewed spec or ticket. Stops before code, commit, or push |
-| `wdi-daily-autopilot` | Start the daily loop: checks for an accepted mandate (preflight if none), resolves reviewers, launches `/loop` over `wdi-autopilot` |
+| `wdi-daily-autopilot` | Start the daily loop: checks for an accepted mandate (preflight if none), resolves reviewers, starts the host's own scheduler over `wdi-autopilot` (one iteration where the host has none) |
 | `wdi-daily-what-to-test` | After a merge: sync, prune merged branches, prepare the app, build the hand-test checklist |
 | `wdi-prune-or-archive` | Closed specs to archive or prune, through `lifecycle.py` |
 

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
 

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-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.