@hecer/yoke 1.12.0 → 1.14.0

package/.claude-plugin/plugin.json

@@ -2,12 +2,12 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "yoke",
   "displayName": "Yoke",
-  "version": "1.12.0",
-  "description": "Cross-agent coding harness: one curated skill canon (TDD, brainstorming, plans, reviews, shipping, design verification) plus mechanical safety gates and an autonomous loop via the yoke CLI.",
+  "version": "1.13.0",
+  "description": "Cross-agent coding harness for Claude, Codex, Gemini, Qwen, OpenCode, Kilo and Pi: one curated skill canon plus mechanical safety gates and an autonomous loop via the yoke CLI.",
   "author": { "name": "HECer", "url": "https://github.com/HECer" },
   "homepage": "https://github.com/HECer/yoke#readme",
   "repository": "https://github.com/HECer/yoke",
   "license": "MIT",
-  "keywords": ["harness", "cross-agent", "tdd", "code-review", "autonomous-loop", "codex", "gemini-cli", "qwen-code"],
+  "keywords": ["harness", "cross-agent", "tdd", "code-review", "autonomous-loop", "codex", "gemini-cli", "qwen-code", "opencode", "kilo", "pi"],
   "skills": "./canon/skills/"
 }

package/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "yoke",
-  "version": "1.12.0",
-  "description": "Cross-agent coding discipline, mechanical gates, and release workflows",
+  "version": "1.13.0",
+  "description": "Cross-agent coding discipline, mechanical gates, and release workflows for seven supported harnesses",
   "skills": "./canon/skills/",
   "hooks": "./hooks/hooks.json"
 }

package/CHANGELOG.md

@@ -1,5 +1,46 @@
 # Changelog
 
+## 1.14.0 — 2026-09-09
+
+### Added
+- Add a local-first workspace control room that ranks registered projects by attention, activity, recorded tokens, reported cost, acceptance, or name, with composable search, status filters, UTC scopes, and restorable view links.
+- Add workspace and project analytics with time buckets, token/call/duration/outcome summaries, provider/model/agent/role/phase/run rankings, usage comparisons, and visible measurement coverage.
+- Add project live operations for task and phase state, worker metadata, bounded event timelines, safe-boundary pause/resume, append-only operator notes, and queued change requests.
+- Add a responsive dashboard shell with dark/light themes, keyboard and reduced-motion support, explicit loading/empty/error/stale states, and readable narrow-screen navigation.
+
+### Changed
+- Base dashboard views on durable local history and versioned events while keeping unknown, partial, corrupt, unavailable, and stale telemetry explicit instead of treating it as zero.
+- Keep dashboard controls on the existing loop/goal runner and lock boundaries; browser requests remain typed, same-origin, loopback-only, and unable to execute arbitrary shell commands.
+
+### Fixed
+- Scope dashboard loop verification to the intended local project and retain focused coverage for dashboard authorization, path safety, partial history, concurrency, navigation, and control behavior.
+- Improve light-theme contrast for the active navigation state and keep long project names inside desktop and mobile navigation areas.
+
+### Migration and validation limits
+- No migration is required. Start the local view with `yoke dashboard --no-register`, then register projects with `yoke projects add <path>` as needed. Existing dashboard settings remain local and authoritative.
+- Validated with the dashboard tests, TypeScript lint/build, canonical manifest validation, release metadata checks, package dry run, and real local browser screenshots at desktop and mobile sizes.
+- Dashboard data is limited to explicitly registered local projects and retained local telemetry. It does not provide remote multi-user access, reconstruct missing history, prove requested models were used, or execute arbitrary browser-supplied commands. Pause/resume operates only at existing safe loop/goal boundaries.
+- This release targets npm package 1.14.0; npm publication is triggered by the matching published GitHub release and verified separately.
+
+## 1.13.0 — 2026-09-08
+
+### Added
+- Add first-class OpenCode, Kilo and Pi coding-agent adapters across setup, retrofit, loop execution, reviews, quality critics/repairs, goals, PRD affinity and adaptive routing.
+- Generate idiomatic OpenCode/Kilo skill packages, `AGENTS.md` instructions, merged MCP config and read-only reviewer agents; generate Pi skill packages and project settings without inventing unsupported MCP or sub-agent features.
+- Support provider/model/variant selection for OpenCode and Kilo, and provider/model/thinking selection for Pi. Preserve provider and variant identity in routing evidence and dashboard status.
+- Parse OpenCode/Kilo JSON text and per-step usage/cost events and Pi JSONL assistant/usage events, retaining partial or unknown measurements instead of treating them as free calls.
+
+### Changed
+- Extend the shared agent contract and all CLI validation/help text from four to seven supported harnesses: Claude, Codex, Gemini, Qwen, OpenCode, Kilo and Pi.
+- Add JSONC-aware merging for existing Kilo configuration files so comments, trailing commas and user-owned settings survive retrofit.
+- Add OpenCode/Kilo/Pi capability-tier routing defaults and carry provider/variant choices into parallel workers and quality candidate comparison.
+
+### Migration and validation limits
+- Run `yoke retrofit . --agent=opencode,kilo,pi` to add the new native artifacts, or use `--agent=all` for all seven harnesses. Install and authenticate each external CLI separately; Yoke does not bundle runtimes or credentials.
+- OpenCode and Kilo safe execution uses their headless approval mode, while Pi uses explicit tool allowlists. None provides the same OS-level sandbox boundary as Codex/Gemini; Pi has no native MCP, sub-agent or plan layer. See [OpenCode, Kilo and Pi](docs/HARNESSES.md) before using `unsafe`.
+- Regression fixtures cover invocation, routing, quality configuration, retrofit, host detection, result parsing and telemetry. No authenticated provider matrix, production sandbox equivalence, or model-quality/cost benchmark is claimed for these harnesses. Provider streams that omit final usage events remain partial or unknown.
+- This release targets npm package 1.13.0; publication is triggered by the matching published GitHub release and verified separately.
+
 ## 1.12.0 — 2026-09-08
 
 ### Fixed

package/README.md

@@ -1,15 +1,15 @@
 <div align="center">
 
-<h1><img src="https://raw.githubusercontent.com/HECer/yoke/v1.12.0/docs/assets/yoke-logo.png" alt="Yoke" width="100" height="63"></h1>
+<h1><img src="https://raw.githubusercontent.com/HECer/yoke/v1.14.0/docs/assets/yoke-logo.png" alt="Yoke" width="100" height="63"></h1>
 
-<!-- yoke:version:start -->1.12.0<!-- yoke:version:end -->
-<!-- yoke:tests:start -->1213<!-- yoke:tests:end -->
+<!-- yoke:version:start -->1.14.0<!-- yoke:version:end -->
+<!-- yoke:tests:start -->1258<!-- yoke:tests:end -->
 <!-- yoke:skills:start -->34<!-- yoke:skills:end -->
-<!-- yoke:agents:start -->Claude | Codex | Gemini | Qwen<!-- yoke:agents:end -->
+<!-- yoke:agents:start -->Claude | Codex | Gemini | Qwen | OpenCode | Kilo | Pi<!-- yoke:agents:end -->
 
-### One harness, four agents — and zero trust in "done."
+### One harness, seven agents — and zero trust in "done."
 
-**Yoke** installs one curated canon of skills, **mechanical safety gates**, and tool wiring into any project — natively for **Claude Code, OpenAI Codex CLI, Gemini CLI, and Qwen Code**. Its opt-in loop implements and verifies stories before committing. Independent review and browser proofs run when configured; screenshots and videos require the browser smoke gate.
+**Yoke** installs one curated canon of skills, **mechanical safety gates**, and tool wiring into any project — natively for **Claude Code, OpenAI Codex CLI, Gemini CLI, Qwen Code, OpenCode, Kilo, and Pi coding agent**. Its opt-in loop implements and verifies stories before committing. Independent review and browser proofs run when configured; screenshots and videos require the browser smoke gate.
 
 [![npm](https://img.shields.io/npm/v/%40hecer%2Fyoke?logo=npm&color=CB3837)](https://www.npmjs.com/package/@hecer/yoke)
 [![npm downloads](https://img.shields.io/npm/dm/%40hecer%2Fyoke?logo=npm)](https://www.npmjs.com/package/@hecer/yoke)
@@ -17,8 +17,8 @@
 [![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](#-license)
 ![Node](https://img.shields.io/badge/node-%E2%89%A520-339933?logo=node.js&logoColor=white)
 ![TypeScript](https://img.shields.io/badge/TypeScript-3178C6?logo=typescript&logoColor=white)
-![Tests](https://img.shields.io/badge/tests-1213%20defined-blue.svg)
-![Agents](https://img.shields.io/badge/agents-Claude%20%7C%20Codex%20%7C%20Gemini%20%7C%20Qwen-8A2BE2)
+![Tests](https://img.shields.io/badge/tests-1258%20defined-blue.svg)
+![Agents](https://img.shields.io/badge/agents-Claude%20%7C%20Codex%20%7C%20Gemini%20%7C%20Qwen%20%7C%20OpenCode%20%7C%20Kilo%20%7C%20Pi-8A2BE2)
 ![Built with TDD](https://img.shields.io/badge/built%20with-TDD%20%2B%20review-ff69b4.svg)
 
 **Install:** [`npm i -g @hecer/yoke`](https://www.npmjs.com/package/@hecer/yoke)
@@ -27,7 +27,9 @@
 
 > **TL;DR** — `yoke setup .` asks six questions and installs the native harness for your agent. `yoke new my-app --idea="..."` bootstraps a project and drafts its story backlog. `yoke loop run my-app --isolate --review` then implements it behind hard gates: **clean tree → acceptance criteria → your real tests green → an independent model approves → commit**. Add `--parallel=N` for dependency-aware workers, or declare a reference and add `--quality` for a bounded critic/repair gauntlet. If any blocking gate is red, nothing is committed. Proof lives in `.yoke/proof/<story>/`.
 
-**New in 1.12.0:** [Qwen Code hardening and explicit DeepSeek/Kimi API model profiles](docs/QWEN-MODEL-SUPPORT.md). Since 1.10.0, Yoke also includes [dashboard search, filters and period comparisons](docs/DASHBOARD-EVOLUTION.md), [batch task assessments with separate planning models](docs/CAPABILITY-ROUTING.md), and [Windows sandbox preflight and process supervision](docs/WINDOWS-RUNNER-VALIDATION.md). Existing routing settings remain authoritative. See the [changelog](CHANGELOG.md) for migration and validation limits.
+**New in 1.13.0:** first-class [OpenCode, Kilo and Pi integrations](docs/HARNESSES.md), including native headless invocation, provider/model/variant routing, retrofit artifacts, role configuration and provider telemetry. [Qwen Code hardening and explicit DeepSeek/Kimi API model profiles](docs/QWEN-MODEL-SUPPORT.md) remain available. Since 1.10.0, Yoke also includes [dashboard search, filters and period comparisons](docs/DASHBOARD-EVOLUTION.md), [batch task assessments with separate planning models](docs/CAPABILITY-ROUTING.md), and [Windows sandbox preflight and process supervision](docs/WINDOWS-RUNNER-VALIDATION.md). Existing routing settings remain authoritative. See the [changelog](CHANGELOG.md) and the [harness integration guide](docs/HARNESSES.md) for limitations and setup.
+
+OpenCode, Kilo and Pi are real CLI integrations, not bundled runtimes or credentials. OpenCode/Kilo use their JSON headless modes and local MCP configuration; Pi uses JSONL and explicit tool allowlists, but has no native MCP, sub-agent or plan layer. Read the [integration guide](docs/HARNESSES.md) before selecting a permission profile.
 
 ### One dashboard, multiple projects
 
@@ -38,11 +40,11 @@ yoke projects add /path/to/backend
 yoke dashboard --no-register
 ```
 
-Open the printed `http://127.0.0.1:...` URL. Each registered project has its own goals, tasks and evidence. The dashboard shows available worker state, per-task duration estimates, planned start offsets, input/output tokens, costs and unknown measurements. You can request a goal pause at a safe boundary.
+Open the printed `http://127.0.0.1:...` URL. Each registered project has its own goals, tasks and evidence. The dashboard is a local control room with an overview/ranking screen, project live view, bounded **History explorer**, and Workspace analytics by UTC time bucket. It shows worker state, agent/provider/model/variant/role/phase metadata when recorded, per-task duration estimates, planned start offsets, input/output tokens, reported costs, outcomes, and explicit unknown or partial measurements. Dark and light themes, keyboard navigation, responsive layouts, and reduced-motion handling are included.
 
-The dashboard includes attention-first project search and filters, restorable view links, and usage comparisons against the preceding period. See [dashboard behavior and measurement limits](docs/DASHBOARD-EVOLUTION.md).
+The dashboard includes attention-first project search and filters, project ranking by attention, last activity, token usage, reported cost, acceptance, or name, restorable view links, and usage comparisons against the preceding period. From a project’s live view you can request a safe-boundary pause or resume, add an operator note, and use **Queue a change** for the next planning boundary. See [dashboard behavior and measurement limits](docs/DASHBOARD-EVOLUTION.md) and the [dashboard overhaul contract](docs/DASHBOARD-OVERHAUL.md).
 
-Projects are registered explicitly; this version does not automatically discover every process or aggregate other computers. Start/resume and budget changes use the CLI. Missing history appears as unknown; time ranges are empirical estimates, not exact deadlines.
+Projects are registered explicitly; this version does not automatically discover every process or aggregate other computers. Dashboard controls call the existing goal/loop pause and resume boundaries and never execute arbitrary shell commands. Change requests are append-only pending inbox entries, not immediate code changes. The server stays loopback-only and POST actions require same-origin session authorization; the local Yoke process remains the authority for execution. Missing history appears as unknown; time ranges are empirical estimates, not exact deadlines. Read the [overhaul contract](docs/DASHBOARD-OVERHAUL.md) for data limits and non-goals.
 
 ### Verified goals and efficient execution
 
@@ -100,7 +102,7 @@ Agentic coding in 2026 fails in four well-documented ways. Yoke answers each one
 | 🌀 **Overnight loops going off the rails** | Raw Ralph-loop users "wake up to broken codebases that don't compile" | Yoke is **"Ralph, but with gates"**: clean-worktree gate, acceptance-criteria gate, green-tests gate, review gate, per-story worktree isolation, idle-timeout watchdog, single-flight lock, commit integrity. |
 | 😵 **Review fatigue** | AI adoption nearly doubles PR volume and review time; humans start skimming | **`yoke review`**: a second model writes a schema-validated pass/fail verdict — chainable into verify, pre-push, or CI. Cross-model review catches what self-review misses. |
 
-**Who it's for:** anyone driving Claude Code, Codex CLI, Gemini CLI, or Qwen Code on real projects — especially if you use more than one, want autonomous runs you can trust, or are tired of "done" meaning "probably". Greenfield (`yoke new`) and brownfield (`yoke retrofit`) both work.
+**Who it's for:** anyone driving Claude Code, Codex CLI, Gemini CLI, Qwen Code, OpenCode, Kilo or Pi on real projects — especially if you use more than one, want autonomous runs you can trust, or are tired of "done" meaning "probably". Greenfield (`yoke new`) and brownfield (`yoke retrofit`) both work.
 
 **Who it's not for:** if you want a chat pair-programmer with no process, you don't need a harness. Yoke is for shipping with discipline.
 
@@ -155,7 +157,7 @@ The canon is also packaged as a Claude Code plugin — the repo is its own marke
 /plugin install yoke@yoke
 ```
 
-That gives you all canon skills under the `yoke:` namespace (e.g. `yoke:tdd`, `yoke:review`) inside Claude Code — no retrofit needed. The `yoke` CLI (loop, gates, retrofit for Codex/Gemini/Qwen) still comes from `npm i -g @hecer/yoke`. Gemini CLI users can likewise `gemini extensions install https://github.com/HECer/yoke`.
+That gives you all canon skills under the `yoke:` namespace (e.g. `yoke:tdd`, `yoke:review`) inside Claude Code — no retrofit needed. The `yoke` CLI (loop, gates, retrofit for Codex/Gemini/Qwen/OpenCode/Kilo/Pi) still comes from `npm i -g @hecer/yoke`. Gemini CLI users can likewise `gemini extensions install https://github.com/HECer/yoke`.
 
 For Codex, no preinstalled skill is required: run `npx @hecer/yoke setup .` in a terminal, or
 ask Codex to run the six-question Yoke setup flow. The retrofit writes native skills to
@@ -182,7 +184,7 @@ Auto-upgrade is deliberately **not** the default: a gate harness shouldn't chang
 
 ## 🤖 Driving it through an agent
 
-Yoke is meant to be operated *by* your coding agent — after a retrofit, the agent has the skills, the safety policy, and the routing, so it knows the methodology. Copy-paste prompts (identical wording works for Claude Code, Codex CLI, Gemini CLI, and Qwen Code):
+Yoke is meant to be operated *by* your coding agent — after a retrofit, the agent has the skills, the safety policy, and the routing, so it knows the methodology. Copy-paste prompts (identical wording works for Claude Code, Codex CLI, Gemini CLI, Qwen Code, OpenCode, Kilo, and Pi):
 
 > **Set it up** — *"Set up Yoke in this project. Ask me the Yoke setup questions one at a time with your recommendation, then run `yoke setup . --yes` with the selected host, agents, code graph, loop, runner, and decision policy. Commit in my configured identity."*
 
@@ -206,10 +208,10 @@ Yoke's CLI is deterministic and chainable by design: an agent (or a shell `&&`)
 | `yoke projects add\|list\|remove` | Register a project, list registrations or remove a reference by ID | `0` · `2` invalid/unavailable |
 | `yoke check [dir] [--json] [--requirement=] [--protect [--refresh]]` | Execute acceptance checks or explicitly pin their infrastructure | `0` passed/pinned · `1` failed · `2` unverified/unavailable |
 | `yoke goal set\|run\|resume\|pause\|status\|handoff\|budget [dir]` | Durable objectives, provider handoff, protected checks and checkpoint budgets | run/resume: `0` complete · `1` unfinished · `2` unavailable |
-| `yoke setup [dir] [--yes] [--host=] [--agent=] [--runner=] [--code-graph=] [--decision-policy=] [--loop\|--no-loop] [--routing\|--no-routing] [--model-provider=deepseek,kimi]` | Shared setup for Claude, Codex, Gemini and Qwen; optional DeepSeek/Kimi API profiles run through Qwen | `0` · `1` invalid setup |
+| `yoke setup [dir] [--yes] [--host=] [--agent=] [--runner=] [--code-graph=] [--decision-policy=] [--loop\|--no-loop] [--routing\|--no-routing] [--model-provider=deepseek,kimi]` | Shared setup for all seven harnesses; optional DeepSeek/Kimi API profiles run through Qwen | `0` · `1` invalid setup |
 | `yoke validate [canonDir]` | Validate the canon (schema, frontmatter, templates) | `0` valid · `1` errors |
 | `yoke new <dir> [--idea=] [--agent=] [--runner=] [--loop]` | Greenfield bootstrap: git init → scaffold → retrofit → context → PRD (drafted from `--idea`) → committed | `0` · `1` usage / non-empty dir / draft failed (scaffold survives) · `2` draft agent unavailable |
-| `yoke retrofit [dir] [--agent=claude,codex,gemini,qwen\|all] [--code-graph=graphify\|serena] [--loop]` | Install/update the harness for the selected agents, non-destructively | `0` |
+| `yoke retrofit [dir] [--agent=claude,codex,gemini,qwen,opencode,kilo,pi\|all] [--code-graph=graphify\|serena] [--loop]` | Install/update the harness for the selected agents, non-destructively | `0` |
 | `yoke prd draft [dir] --idea= [--runner=] [--force]` | Idea → 5–12 stories with testable acceptance criteria | `0` · `1` invalid/guarded · `2` agent unavailable |
 | `yoke prd check [dir]` | PRD lint gate (schema, dependencies, cycles, duplicate ids, acceptance) | `0` valid · `1` violations |
 | `yoke change add\|status [dir] [--idea=]` | Queue a change at any time; the loop turns it into append-only stories at the next safe boundary | `0` · `1` invalid inbox/request |
@@ -229,7 +231,7 @@ Three excellent projects, three different jobs. Honest version:
 | | [superpowers](https://github.com/obra/superpowers) (obra) | [gstack](https://github.com/garrytan/gstack) (Garry Tan) | **Yoke** |
 |---|---|---|---|
 | **What it is** | The canonical *skills methodology*: brainstorm → plan → TDD → review as composable skills | A *software factory* for Claude Code: ~40 role skills (QA, CSO, ship…) + a real Chromium browser layer | A *cross-agent harness*: one canon → native installs, plus a gated autonomous loop |
-| **Agents** | Claude Code first | Claude Code + hosts like Codex/Cursor/Kiro — **no Gemini CLI** | **Claude Code, Codex CLI, Gemini CLI** from one source of truth |
+| **Agents** | Claude Code first | Claude Code + hosts like Codex/Cursor/Kiro — **no Gemini CLI** | **Claude Code, Codex CLI, Gemini CLI, Qwen Code, OpenCode, Kilo, Pi** from one source of truth |
 | **Enforcement** | Advisory — skills *describe* the discipline; following them is up to the agent | Skill-driven; browser QA is genuinely real | **Mechanical** — gates live in code: clean tree, acceptance criteria, green tests, review verdict, commit integrity |
 | **Autonomy** | Interactive sessions | Interactive slash-commands (`/qa`, `/ship`, …) | Opt-in **Ralph loop** with watchdog, worktree isolation, single-flight lock, per-story proofs |
 | **Visual QA** | — | **Best-in-class**: live browser daemon (Chromium/CDP) with deep interactive QA | Built-in `flow-smoke` gate: screenshots always, video on failure, labelled per story — lighter, but *enforced* and cross-agent |
@@ -237,7 +239,7 @@ Three excellent projects, three different jobs. Honest version:
 | **Footprint** | Markdown skills (plugin) | ~230 MB with browser runtime; hourly auto-update | Node CLI + markdown canon; Playwright only if you use flow-smoke, resolved **from your project** |
 | **License** | MIT | MIT | MIT |
 
-**They compose — use all three where they're strongest.** Yoke's canon *ships* the superpowers methodology natively for all four agents (13 skills, [attributed](canon/skills/ATTRIBUTION.md)). And if gstack is installed, `yoke retrofit` detects it and adds a routing note to `CLAUDE.md` telling Claude to prefer gstack's live-browser `/qa`, `/cso`, and ship pipeline for what Yoke deliberately doesn't bundle — no dependency, no conflict, and Codex/Gemini artifacts stay uniform.
+**They compose — use all three where they're strongest.** Yoke's canon *ships* the superpowers methodology natively for all seven agents (13 skills, [attributed](canon/skills/ATTRIBUTION.md)). And if gstack is installed, `yoke retrofit` detects it and adds a routing note to `CLAUDE.md` telling Claude to prefer gstack's live-browser `/qa`, `/cso`, and ship pipeline for what Yoke deliberately doesn't bundle — no dependency, no conflict, and non-Claude artifacts stay uniform.
 
 **Choose Yoke when** you run more than one agent, want autonomy you can audit (gates + proofs + logs), or want one place to maintain your team's methodology. **Choose gstack when** you live 100% in Claude Code and want the deepest interactive browser QA. **Choose superpowers when** you want the methodology alone, interactively, in Claude Code — or just use it *through* Yoke.
 
@@ -254,11 +256,17 @@ flowchart TD
     Skill --> Codex["Codex CLI<br/>AGENTS.md · config.toml · RTK.md"]
     Skill --> Gemini["Gemini CLI<br/>GEMINI.md · commands · settings.json"]
     Skill --> Qwen["Qwen Code<br/>QWEN.md · skills · settings.json"]
+    Skill --> OpenCode["OpenCode<br/>AGENTS.md · opencode.json · .opencode/skills"]
+    Skill --> Kilo["Kilo<br/>AGENTS.md · kilo.jsonc · .kilo/skills"]
+    Skill --> Pi["Pi<br/>AGENTS.md · .pi/settings.json · .pi/skills"]
     Loop["🤖 yoke loop — autonomous Ralph loop<br/>gates · verify · review · isolation · proofs"]
     Claude -. drives .-> Loop
     Codex -. drives .-> Loop
     Gemini -. drives .-> Loop
     Qwen -. drives .-> Loop
+    OpenCode -. drives .-> Loop
+    Kilo -. drives .-> Loop
+    Pi -. drives .-> Loop
 ```
 
 Three layers — **Canon** (`yoke validate`) → **Retrofit** (`yoke retrofit`) → **Loop** (`yoke loop`) — on top of a durable **Context layer** (`yoke context`).
@@ -271,6 +279,9 @@ Three layers — **Canon** (`yoke validate`) → **Retrofit** (`yoke retrofit`)
 | **Codex** | Complete skill packages under `.agents/skills/`, per-skill implicit-invocation policy, `AGENTS.md`, `RTK.md`, `.codex/config.toml`, native hooks, reusable `.codex/agents/*.toml`, and package plugin metadata |
 | **Gemini** | Complete skill packages under `.gemini/skills/`, an auto-invocation index, `GEMINI.md`, `.gemini/commands/*.toml`, and `.gemini/settings.json` (MCP + `AGENTS.md` context) |
 | **Qwen** | Complete skill packages under `.qwen/skills/`, `QWEN.md`, `.qwen/settings.json`, native invocation restrictions, and an RTK PreToolUse retry guard |
+| **OpenCode** | Complete skill packages under `.opencode/skills/`, shared `AGENTS.md`, merged `opencode.json` (instructions + local MCP), and `.opencode/agents/yoke-reviewer.md` |
+| **Kilo** | Complete skill packages under `.kilo/skills/`, shared `AGENTS.md`, merged `kilo.jsonc` (instructions + local MCP), and `.kilo/agents/yoke-reviewer.md` |
+| **Pi** | Complete skill packages under `.pi/skills/`, shared `AGENTS.md`, and merged `.pi/settings.json`; Pi's tool allowlists are applied at invocation time |
 
 > **rtk integration:** Claude receives its PreToolUse hook; Codex receives a native hook adapter around `rtk hook check`; Gemini retains instruction-mode fallback where its CLI has no equivalent command-rewrite lifecycle.
 
@@ -285,13 +296,14 @@ Three layers — **Canon** (`yoke validate`) → **Retrofit** (`yoke retrofit`)
 
 ## 🧰 What's in the canon — 34 skills
 
-`yoke retrofit` installs all of these into each agent natively. Provenance is credited in [`canon/skills/ATTRIBUTION.md`](canon/skills/ATTRIBUTION.md).
+`yoke retrofit` installs all of these into each selected agent natively. Provenance is credited in [`canon/skills/ATTRIBUTION.md`](canon/skills/ATTRIBUTION.md).
 
-To stop overlapping skills from auto-invoking against each other, `canon/AGENTS.md` carries a **skill routing & precedence** block (methodology before role; one canonical entrypoint per concern — e.g. pre-merge code review is always `review`), emitted into all four agents.
+To stop overlapping skills from auto-invoking against each other, `canon/AGENTS.md` carries a **skill routing & precedence** block (methodology before role; one canonical entrypoint per concern — e.g. pre-merge code review is always `review`), emitted into all seven agents.
 
 Each manifest entry also declares `invocation: auto|manual`. Retrofit translates that intent into
 the provider's native controls: Claude and Qwen disable model invocation for manual skills, Codex writes
-`agents/openai.yaml`, and Gemini lists only automatic skills in its generated index. Validation
+`agents/openai.yaml`, Gemini lists only automatic skills in its generated index, and OpenCode/Kilo/Pi
+receive complete project-local skill packages. Validation
 rejects conflicting package metadata and broken local Markdown links before anything is installed.
 
 **Process / methodology** — *superpowers-derived discipline (13)*
@@ -587,16 +599,16 @@ new projects should use `decisionPolicy: auto|critical`.
 worker profiles, automatic execution keeps the selected parent. When enabled, the selected
 parent remains the strong planner/controller. Before each bounded story it receives only the
 story, acceptance criteria, and at most three eligible worker profiles, then returns one
-machine-readable choice. The worker can be a cheaper/faster Claude, Codex, or Gemini profile;
+machine-readable choice. The worker can be a cheaper/faster profile for any configured harness;
 `SELF` keeps difficult work on the parent. Explicit project rules skip the controller.
-Loop runners disable native delegation in Codex, Claude, Gemini and Qwen so it cannot multiply
+Loop runners disable native delegation in Codex, Claude, Gemini, Qwen, OpenCode and Kilo so it cannot multiply
 the Yoke worker budget. Integration retains its execution slot until the candidate lands.
 
 **Provider support:** adaptive routing uses Yoke's shared provider adapter and works with Claude
-Code, Codex CLI, Gemini CLI, and Qwen Code, including mixed-provider worker lists. Internal contract tests
-cover invocation and routing behavior for all four providers. The measured performance evidence
-below is intentionally **Codex-only**; it does not claim equivalent Claude, Gemini or Qwen savings
-until authenticated, repeated in-the-wild runs exist for those providers.
+Code, Codex CLI, Gemini CLI, Qwen Code, OpenCode, Kilo and Pi, including mixed-provider worker lists.
+Internal contract tests cover invocation and routing behavior for all seven providers. The measured
+performance evidence below is intentionally **Codex-only**; it does not claim equivalent savings
+until authenticated, repeated in-the-wild runs exist for each provider.
 
 ```yaml
 runner:
@@ -892,7 +904,7 @@ canon/            # the source of truth — harness-agnostic
 src/
   canon/          # manifest schema + validator (yoke validate)
   change/         # append-only change inbox · planning · independent coverage review
-  retrofit/       # detect · plan · apply · planners (claude/codex/gemini) · tools
+  retrofit/       # detect · plan · apply · planners (all seven harnesses) · tools
   loop/           # prd · gates · runner · verify · git/worktree · loop · run-command · lock · cleanup
   quality/        # reference collection · blind critic · bounded repair · candidate comparison
   new/            # yoke new — greenfield bootstrap
@@ -913,7 +925,7 @@ release provenance.
 ## 🧪 Development
 
 ```bash
-npm test          # vitest (1213 tests)
+npm test          # vitest (1258 tests)
 npm run build     # tsc, no emit errors
 npm run yoke -- validate canon
 ```

package/canon/loop/prd.schema.md

@@ -8,7 +8,7 @@ The loop is driven by a continuous PRD backlog. Each story:
   priority: 1            # lower = higher priority
   needs: []              # optional dependency IDs; no unknown IDs, self-links, or cycles
   area: api              # optional collision domain for parallel scheduling
-  agent: codex           # optional claude|codex|gemini affinity
+  agent: codex           # optional supported harness affinity
   acceptance:
     - id: valid-request-returns-200
       text: The endpoint returns 200 for a valid request.
@@ -42,7 +42,7 @@ dispatch blocks missing or stale assessments. See [capability routing](../../doc
 
 Stories without `needs`, `area`, or `agent` retain serial behavior. A story is ready only when
 every ID in `needs` passes. The scheduler orders ready work by priority, avoids simultaneously
-active areas, and uses `agent` as an affinity hint.
+active areas, and uses `agent` as a supported harness affinity hint.
 
 The backlog is continuous, not a release object. A momentary stop condition is every story
 having `passes: true`; if configured, `completion.command` must then prove the integrated

package/canon/manifest.yaml

@@ -1,6 +1,6 @@
 name: yoke-canon
-version: 1.12.0
-agents: [claude, codex, gemini, qwen]
+version: 1.14.0
+agents: [claude, codex, gemini, qwen, opencode, kilo, pi]
 skills:
   - { id: tdd, path: skills/tdd, kind: methodology, invocation: auto }
   - { id: yoke-retrofit, path: skills/yoke-retrofit, kind: methodology, invocation: auto }

package/canon/skills/authoring-prd/SKILL.md

@@ -21,7 +21,7 @@ new stories; they do not require a release object.
 7. Resolve planning questions before unattended execution. `yoke prd check` rejects unresolved
    placeholders; critical irreversible choices use the structured decision channel.
 8. Use `needs` only for hard prerequisites, `area` for collision domains, and `agent` only as
-   a Claude/Codex/Gemini affinity hint.
+   a supported harness affinity hint.
 9. Keep planning on the start model. Add an `assessment` to each story: `taskClass`
    (`mechanical`, `implementation`, `debugging`, `architecture`), `difficulty`, `uncertainty`,
    `risk`, `scope`, `testability` (each `low`, `medium`, `high`), a concise `reason`, and

package/canon/skills/yoke-retrofit/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: yoke-retrofit
-description: Use when asked to "retrofit", "yoke this project", or set up the Yoke harness in a project — runs the shared setup wizard and configures the same behavior for Claude, Codex, and Gemini.
+description: Use when asked to "retrofit", "yoke this project", or set up the Yoke harness in a project — runs the shared setup wizard and configures the same behavior for the supported Yoke harnesses.
 ---
 
 # Yoke Retrofit
 
 Set up or update Yoke through the shared `yoke setup` contract.
 
-1. Inspect the project and identify the current host (`claude`, `codex`, or `gemini`).
+1. Inspect the project and identify the current host (`claude`, `codex`, `gemini`, `qwen`, `opencode`, `kilo`, or `pi`).
 2. Ask these setup questions one at a time and give a direct recommendation:
    - target agents (recommend the current host; use `all` for deliberately cross-agent projects),
    - code-graph tool,

package/canon/skills/yoke-workflow/SKILL.md

@@ -5,7 +5,7 @@ description: Use when the user asks Yoke to plan and build a feature, run storie
 
 # Yoke Workflow
 
-Provide the same interaction contract in Claude, Codex, and Gemini.
+Provide the same interaction contract in every supported Yoke harness.
 
 1. Read `.yoke/config.yaml`. If it is missing, offer `yoke setup . --host=<current-agent>` and run the setup flow before planning.
 2. Plan before starting the loop. Inspect the project, then ask one focused question at a time only where the answer changes product behavior, scope, architecture, security, data ownership, external cost, or an irreversible choice. Include a recommended answer. Resolve routine implementation details yourself.

package/canon/tools/graphify.md

@@ -1,3 +1,3 @@
 # Tool: graphify (code-graph)
 
-MIT, multimodal code/doc graph. Wired as an MCP server for all three agents (stdio). Prefer symbol/graph lookups over reading whole files. Caveat: heuristic edges (INFERRED/AMBIGUOUS) and a static index that can go stale — rebuild on significant changes.
+MIT, multimodal code/doc graph. Wired as an MCP server for Claude, Codex, Gemini, Qwen, OpenCode and Kilo (stdio). Pi has no native MCP layer. Prefer symbol/graph lookups over reading whole files. Caveat: heuristic edges (INFERRED/AMBIGUOUS) and a static index that can go stale — rebuild on significant changes.

package/canon/tools/playwright-mcp.md

@@ -1,3 +1,3 @@
 # Tool: Playwright MCP (browser / dogfooding)
 
-Microsoft Playwright MCP, Apache-2.0. Wired as an MCP server for all three agents — the only browser tool with native MCP parity across Claude/Codex/Gemini. Used for QA, dogfooding user flows, screenshots, and deploy verification.
+Microsoft Playwright MCP, Apache-2.0. Wired as an MCP server for the harnesses that support native MCP configuration (Claude, Codex, Gemini, Qwen, OpenCode and Kilo). Pi has no native MCP layer, so Pi projects use the portable skills and explicit Yoke gates instead. Used for QA, dogfooding user flows, screenshots, and deploy verification.

package/canon/tools/serena.md

@@ -2,7 +2,7 @@
 
 MIT, MCP-first. The alternative to graphify, selected via `yoke retrofit --code-graph=serena`. Serena uses real language servers (LSP) for symbol-accurate, cross-file retrieval and refactoring (`find_symbol`, `find_referencing_symbols`, rename/move) — no static index that goes stale, so it will not miss a reference.
 
-Wired as an MCP server for all three agents. Best for large, strongly-typed codebases (TypeScript, Python, Go) doing systematic refactoring, where missing a caller is costly.
+Wired as an MCP server for Claude, Codex, Gemini, Qwen, OpenCode and Kilo. Pi has no native MCP layer. Best for large, strongly-typed codebases (TypeScript, Python, Go) doing systematic refactoring, where missing a caller is costly.
 
 Caveat: needs one language server per language (can be fiddly on Windows for exotic languages) and requires `uv`. The launch command is a best-effort template — adjust to your install, e.g. `uvx --from git+https://github.com/oraios/serena serena-mcp-server`.
 

package/dist/agents/catalog.js

@@ -0,0 +1,7 @@
+import { AgentSchema } from './contracts.js';
+/** Single source of truth for CLI help, setup prompts, and default resolution. */
+export const SUPPORTED_AGENTS = AgentSchema.options;
+export const AGENT_LIST = SUPPORTED_AGENTS.join(',');
+export function isSupportedAgent(value) {
+    return SUPPORTED_AGENTS.includes(value);
+}

package/dist/agents/contracts.js

@@ -1,9 +1,11 @@
 import { z } from 'zod';
-export const AgentSchema = z.enum(['claude', 'codex', 'gemini', 'qwen']);
+export const AgentSchema = z.enum(['claude', 'codex', 'gemini', 'qwen', 'opencode', 'kilo', 'pi']);
 export const PermissionProfileSchema = z.enum(['safe', 'unsafe', 'read-only']);
 export const ModelSelectionSchema = z.object({
+    provider: z.string().regex(/^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$/).optional(),
     model: z.string().regex(/^[A-Za-z0-9][A-Za-z0-9._:/-]{0,127}$/).optional(),
     reasoningEffort: z.string().regex(/^[A-Za-z0-9][A-Za-z0-9_-]{0,31}$/).optional(),
+    variant: z.string().regex(/^[A-Za-z0-9][A-Za-z0-9_-]{0,31}$/).optional(),
     nativeMultiAgent: z.boolean().optional(),
     bare: z.boolean().optional(),
 });

package/dist/agents/host.js

@@ -9,6 +9,10 @@ export function detectHostAgent(env = process.env) {
         return 'gemini';
     if (env.QWEN_CODE || env.QWEN_CODE_SESSION_ID || env.QWEN_CLI)
         return 'qwen';
+    if (env.OPENCODE_CLIENT || env.OPENCODE_CONFIG || env.OPENCODE_CONFIG_DIR)
+        return 'opencode';
+    if (env.KILO_CLIENT || env.KILO_CONFIG || env.KILO_CONFIG_DIR)
+        return 'kilo';
     if (env.CODEX_HOME)
         return 'codex';
     if (env.CLAUDE_CONFIG_DIR)

package/dist/agents/process-streams.js

@@ -20,6 +20,9 @@ export function createTelemetryAccumulator(agent) {
     let trailing = '';
     let telemetry = { usageAvailable: false };
     let reportedModels = [];
+    const stepTotals = agent === 'opencode' || agent === 'kilo'
+        ? { input: 0, output: 0, cached: 0, cacheWrite: 0, reasoning: 0, cost: 0, hasInput: false, hasOutput: false, hasCached: false, hasCacheWrite: false, hasReasoning: false, hasCost: false }
+        : undefined;
     const update = (lines) => {
         for (const line of lines) {
             const next = parseProviderTelemetry(agent, [line]);
@@ -31,6 +34,35 @@ export function createTelemetryAccumulator(agent) {
             // never add it to earlier results or to assistant-message snapshots.
             if (next.tokens || next.partialUsage)
                 telemetry = next;
+            if (stepTotals && isStepFinish(line)) {
+                const usage = next.tokens ?? next.partialUsage;
+                if (usage) {
+                    if (usage.inputTokens !== undefined) {
+                        stepTotals.input += usage.inputTokens;
+                        stepTotals.hasInput = true;
+                    }
+                    if (usage.outputTokens !== undefined) {
+                        stepTotals.output += usage.outputTokens;
+                        stepTotals.hasOutput = true;
+                    }
+                    if (usage.cachedInputTokens !== undefined) {
+                        stepTotals.cached += usage.cachedInputTokens;
+                        stepTotals.hasCached = true;
+                    }
+                    if (usage.cacheWriteInputTokens !== undefined) {
+                        stepTotals.cacheWrite += usage.cacheWriteInputTokens;
+                        stepTotals.hasCacheWrite = true;
+                    }
+                    if (usage.reasoningOutputTokens !== undefined) {
+                        stepTotals.reasoning += usage.reasoningOutputTokens;
+                        stepTotals.hasReasoning = true;
+                    }
+                    if (usage.totalCostUsd !== undefined) {
+                        stepTotals.cost += usage.totalCostUsd;
+                        stepTotals.hasCost = true;
+                    }
+                }
+            }
         }
     };
     return {
@@ -43,6 +75,26 @@ export function createTelemetryAccumulator(agent) {
             if (trailing)
                 update([trailing]);
             trailing = '';
+            if (stepTotals && (stepTotals.hasInput || stepTotals.hasOutput)) {
+                const latest = telemetry.tokens;
+                const inputTokens = stepTotals.hasInput ? stepTotals.input : latest?.inputTokens;
+                const outputTokens = stepTotals.hasOutput ? stepTotals.output : latest?.outputTokens;
+                const partialUsage = {
+                    ...(inputTokens !== undefined ? { inputTokens } : {}),
+                    ...(outputTokens !== undefined ? { outputTokens } : {}),
+                    ...(stepTotals.hasCached ? { cachedInputTokens: stepTotals.cached } : latest?.cachedInputTokens !== undefined ? { cachedInputTokens: latest.cachedInputTokens } : {}),
+                    ...(stepTotals.hasCacheWrite ? { cacheWriteInputTokens: stepTotals.cacheWrite } : latest?.cacheWriteInputTokens !== undefined ? { cacheWriteInputTokens: latest.cacheWriteInputTokens } : {}),
+                    ...(stepTotals.hasReasoning ? { reasoningOutputTokens: stepTotals.reasoning } : latest?.reasoningOutputTokens !== undefined ? { reasoningOutputTokens: latest.reasoningOutputTokens } : {}),
+                    ...(stepTotals.hasCost ? { totalCostUsd: stepTotals.cost } : latest?.totalCostUsd !== undefined ? { totalCostUsd: latest.totalCostUsd } : {}),
+                    ...(latest?.model ? { model: latest.model } : {}),
+                };
+                if (inputTokens !== undefined && outputTokens !== undefined) {
+                    telemetry = { usageAvailable: true, tokens: { ...partialUsage, inputTokens, outputTokens } };
+                }
+                else {
+                    telemetry = { usageAvailable: false, partialUsage };
+                }
+            }
             if (telemetry.tokens) {
                 const { model: _model, ...tokens } = telemetry.tokens;
                 return { usageAvailable: telemetry.usageAvailable, tokens: { ...tokens, ...(reportedModels.length === 1 ? { model: reportedModels[0] } : {}) },
@@ -52,3 +104,13 @@ export function createTelemetryAccumulator(agent) {
         },
     };
 }
+function isStepFinish(line) {
+    try {
+        const value = JSON.parse(line);
+        const part = value.part && typeof value.part === 'object' ? value.part : undefined;
+        return value.type === 'step_finish' || part?.type === 'step-finish';
+    }
+    catch {
+        return false;
+    }
+}

package/dist/agents/process.js

@@ -58,7 +58,32 @@ export function startProviderProcess(agent, invocation, options = {}) {
         catch {
             return true;
         }
-        if (startedAt.startsWith('unverified:') || processIncarnation(processPid) !== startedAt)
+        // A slow or unavailable Windows identity query must not strand the exact
+        // child process Yoke just spawned. The live ChildProcess handle proves
+        // ownership more strongly than a late PID lookup. Terminate that exact
+        // handle immediately and ask taskkill asynchronously to catch descendants;
+        // waiting synchronously for taskkill can itself exceed the provider timeout
+        // on a heavily loaded Windows host. If the identity was verified, retain the
+        // PID-reuse guard for cleanup records.
+        if (startedAt.startsWith('unverified:')) {
+            if (child.exitCode !== null || child.signalCode !== null || child.killed)
+                return true;
+            try {
+                const killed = child.kill('SIGKILL');
+                if (killed && process.platform === 'win32') {
+                    try {
+                        const tree = spawn('taskkill', ['/PID', String(processPid), '/T', '/F'], { stdio: 'ignore', windowsHide: true });
+                        tree.unref();
+                    }
+                    catch { /* direct child termination already succeeded */ }
+                }
+                return killed;
+            }
+            catch {
+                return false;
+            }
+        }
+        if (processIncarnation(processPid) !== startedAt)
             return false;
         return killProcessTreeForCleanup(processPid);
     });
@@ -76,6 +101,7 @@ export function startProviderProcess(agent, invocation, options = {}) {
     let completionTimer;
     let recordFailure;
     let terminationConfirmed = false;
+    let forcedTerminationAttempted = false;
     let settled = false;
     let resolveCompletion = () => { };
     const completion = new Promise(resolveCompletionValue => {
@@ -119,14 +145,24 @@ export function startProviderProcess(agent, invocation, options = {}) {
         stderrTruncated: stderr.truncated,
         telemetry: telemetry.finish(),
     });
+    const forceTerminateExactChild = () => {
+        if (child.exitCode !== null || child.signalCode !== null || child.killed)
+            return;
+        try {
+            child.kill('SIGKILL');
+        }
+        catch { /* the tree killer may have won the race */ }
+    };
     const finalize = (exitCode) => {
         if (settled)
             return;
         supervision.flush();
         // Windows can emit close before taskkill's process-tree state is observable.
         // Reconfirm here so successful termination does not leave a stale ownership record.
-        if (termination && pid !== undefined && !terminationConfirmed) {
+        if (termination && pid !== undefined && !terminationConfirmed && !forcedTerminationAttempted) {
             terminationConfirmed = terminateProcessTree(pid, true);
+            if (terminationConfirmed)
+                forceTerminateExactChild();
         }
         const details = evidence();
         if (recordFailure) {
@@ -154,8 +190,12 @@ export function startProviderProcess(agent, invocation, options = {}) {
         if (pid !== undefined)
             terminationConfirmed = terminateProcessTree(pid, false);
         forceTimer = setTimeout(() => {
-            if (pid !== undefined && !settled)
+            if (pid !== undefined && !settled) {
+                forcedTerminationAttempted = true;
                 terminationConfirmed = terminateProcessTree(pid, true);
+                if (terminationConfirmed)
+                    forceTerminateExactChild();
+            }
             // Allow close/pipe draining to confirm termination before the bounded fallback.
             if (!settled)
                 completionTimer = setTimeout(() => {