Wdi Daily Autopilot

---
name: wdi-daily-autopilot
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 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]`).
  `default` indicates the current coordinating session executes self code-review directly.
- `[peer]` — independent peer reviewer runner or model identifier.
- `[interval]` — optional loop interval matching `^\d+[smhd]$` (e.g., `5m`, `10m`, `15m`). Defaults
  to `10m` when omitted.
- `--skip-peer-review` / `--no-review` — bypasses the secondary peer review pass. MUST NOT disable
  coordinator self code-review, TDD cycles, or automated test suites, and is refused when any touched
  component has `risk_accepted: low` (§2 Guardrail).

## 0. Precondition

Confirm `.control/registry/index.yaml` exists in the repo root. If it does not, this is not a WDI
Method product repo — report that and stop.

## 1. Parse Arguments and Flags

Parse inputs unambiguously using these rules:
1. Check for review bypass flags: `--skip-peer-review` or `--no-review`. If present, mark peer review
   as bypassed.
2. Check for an interval token matching `^\d+[smhd]$`. If found, assign it to `<interval>`; otherwise
   default `<interval>` to `10m`.
3. For remaining positional arguments:
   - If 1 argument remains: assign to `<peer>`, and default `<self-review>` to `default`.
   - If 2 arguments remain: assign first to `<self-review>` and second to `<peer>`.
   - If 0 arguments remain: read defaults from `.control/custom-dispatch.yaml` if present, else default
     both to `default`.

## 2. Resolve Runner Configuration

Inspect the repository for `.control/custom-dispatch.yaml` (if not found in the current working directory and running inside a linked git worktree, resolve it from the main repository root via `(git rev-parse --git-common-dir)/..`):
- **If `.control/custom-dispatch.yaml` exists**:
  Read `runners:`, `roles:`, and `review_policy:`.
  - If `review_policy.peer_review` is explicitly `false`, or if `roles.reviewer` is set to `none`, mark peer review as bypassed.
  - If `<peer>` was not explicitly specified on the command line, use `roles.reviewer`. If resolved `<peer>` is `none`,
    mark peer review as bypassed (coordinator self-review only).
  - If `roles.deep_analyst` is `none`, document review and architecture analysis are handled by the main reviewer or
    coordinator directly, without dispatching a separate deep analyst process.
  - `roles.builder` is fixed to `coordinator`: the coordinating session implements code directly inside the active run worktree (ensuring tight TDD cycles, direct verification, and eliminating delegation/handoff hallucinations). Coding delegation (whether `in-session` subagents or external builder runners) is prohibited in the daily routine.
    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 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**:
  Resolve reviewer dispatch through the caller's active CLI environment.

## 3. Mandate Verification & Preflight Requirement

Per `wdi-autopilot` § Preflight, unattended loop iterations **require an active accepted mandate** in
`.control/registry/decisions.yaml` whose expiry date has not lapsed. A loop MUST NOT self-authorize
its own mandate.

1. Check if an active accepted mandate exists:
   - An active mandate MUST have BOTH `type: mandate` and `status: accepted` with an unexpired `expires:` date
     (`today <= expires`) and no `superseded_by:` or `status: superseded`.
   - **Primary lookup ($O(1)$):** Read `.control/generated/status.yaml` and inspect `mandates:`:
     - If `mandates.resolution: one`: the active mandate is `mandates.active_mandate.id` (with its verified `expires` and `status`). Proceed directly to step 3.
     - If `mandates.resolution: ambiguous`: stop and report immediately to the maintainer naming all `mandates.active_ids` (fail-closed; MUST NOT guess or choose between them).
     - If `mandates.resolution: none`: proceed to step 2 (Preflight).
   - **Fallback lookup (when `status.yaml` does not exist or lacks `mandates:`):**
     - MUST NOT run a broad search for `type:\s*mandate` across `decisions.yaml` (which matches dozens of historical
       `applied` mandates and overflows the tool output limit with hundreds of lines).
     - Query specifically for an active mandate entry using multiline search (e.g. `Grep` with
       `pattern: "type:\s*mandate[\s\S]{1,100}?status:\s*accepted|status:\s*accepted[\s\S]{1,100}?type:\s*mandate", multiline: true`).
       Once a candidate match is found, verify its individual decision block to confirm `expires:` is present,
       valid, and unexpired.
     - **Fail-closed on multiple active mandates:** If more than 1 active accepted mandate is found, stop and
       report immediately to the maintainer (fail-closed; MUST NOT guess or choose between them).
   - MUST NOT call `Read` on the entire 1000+ line `decisions.yaml` file. When reading the latest decision ID
     to determine the next candidate `DEC-` ID, read only the tail (e.g. the last 50-80 lines) of `decisions.yaml`.
2. **If no active accepted mandate exists:**
   - Execute `wdi-autopilot` Door 1 (Preflight) in this interactive turn.
   - When checking open work to include in the mandate, query `specs.yaml` selectively (e.g. `Grep` for
     `status:\s*(open|ready-for-dev)`) instead of reading all historical closed specs into context.
     Inspect the candidate spec's folder using the `spec_folder:` path from `specs.yaml` (MUST NOT run
     broad recursive searches on all of `.scratch/`).
   - Run validator preflight via `uv run .constitution/method/scripts/validate.py --check --baseline`
     (or `--generate --baseline`). If `.github/validate-baseline.txt` exists in the repo, the `--baseline` flag
     guarantees that accepted repository baseline findings are recognized as green.
   - When verifying the preflight test suite from `codebase-stack-guide.md`, run tests with quiet output flags
     if supported (e.g. `-- --quiet` or standard concise runner flags) to avoid flooding the context window
     with hundreds of verbose pass lines.
   - **Fail-closed on test failure:** If the test suite command exits non-zero, immediately surface the failure
     summary (the failing test names and error excerpt) and abort preflight; a mandate MUST NOT be opened on a
     failing test suite.
   - Present the one-page preflight summary and wait for the owner's explicit confirmation.
   - Once confirmed, write the accepted mandate row into `decisions.yaml` and initialize its ledger.
3. **If an active accepted mandate already exists:** Proceed directly to compose and launch the loop.

## 4. Compose the Routine Mandate

Fill the standing five-point routine template:

```markdown
Execute all FR/Tickets/Specs to completion under the active mandate:
1. Coding & Implementation: author code directly as coordinator in the active worktree. No coding delegation — coordinator alone implements application and test changes following TDD red-to-green cycles. Boundary: coordinator edits application and test files only during ticket coding, and defers commits to step 5. Builder MUST NOT commit, push, merge, alter git branches, or write to .control/registry/ or .control/memlog/.
2. Code review: perform code review — self code-review by coordinator, and peer review: <resolved peer command | "none due to config">.
3. Testing & Verification: coordinator alone runs the authoritative test suite (from codebase-stack-guide.md) directly on the active worktree after the coding pass and verifies red-to-green evidence before staging or committing.
4. Reviews and peer analysis: delegate document and architecture review to <resolved peer command | "coordinator self-review (peer review: none due to config)"> — follow wdi-review criteria for any touched architecture or spec documents.
5. Worktree isolation & Integration: coordinator alone isolates ticket implementation into the run worktree, writes ledger decisions in .control/memlog/, stages/commits, and merges per wdi-autopilot. Peer review: <"peer reviewer inspects worktree without interfering with active build processes" | "none due to config">.
```

If peer review was bypassed (via `roles.reviewer: none`, `review_policy.peer_review: false`, or `--skip-peer-review`),
explicitly record `peer review: none due to config` in items 2, 4, and 5, instructing the coordinator to perform direct
self-review and self-verification without external peer dispatch.

## 5. Launch

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