opencode-workflow-guard 1.15.5 → 1.16.0

package/README.md

@@ -46,7 +46,7 @@ WORKFLOW_GUARD_LIVE_E2E=1 npm run test:install # Also run policy probes with Ope
 The plugin enforces **24 deterministic policy rules** across four main pillars:
 
 * **Branch & History Protection:** Enforces feature-branch workflows (blocks edits/commits on `main`/`master`), hard-blocks direct or forced pushes to protected branches, enforces mergeability pre-flight checks, enforces secondary review approval (bound to the reviewed worktree content) before PR creation by default, and requires PR changelogs / changesets.
-* **Task & Verification Discipline:** Gates file mutations on active `todowrite` tasks with subagent inheritance, blocks concurrent direct edits to the same canonical file across sessions, requires same-session fresh reads before `edit`/`write` can replace existing files, blocks silent task deletion, enforces fresh test verification evidence before task completion, and journals completion claims vs. verification mismatches.
+* **Task & Verification Discipline:** Gates file mutations on active `todowrite` tasks with subagent inheritance, requires each task's own recorded work before it can be marked completed (with an audited `[read-only]` marker for review and investigation tasks), blocks concurrent direct edits to the same canonical file across sessions, requires same-session fresh reads before `edit`/`write` can replace existing files, blocks silent task deletion, and enforces fresh test verification evidence before task completion.
 * **Secrets & Workspace Confinement:** Confines edit tools and recognized shell/git mutations within the workspace root (including symlink and `../` escape checks), scrubs sensitive environment variables in agent subshells, and redacts `.env` reads with safe schema masks. Arbitrary executables are not OS-sandboxed; use containers or filesystem isolation when hard confinement is required.
 * **Destructive CLI & Environment Safety:** Intercepts destructive cloud/database/infrastructure commands, stops script laundering and interpreter evasion, blocks TTY hangs (`vim`, `nano`, `sudo`), and guards against dangerous package manager flags.
 
@@ -76,6 +76,7 @@ The context modules — project memory, Socratic learning, and recovery checkpoi
 |---|---|
 | [**Policy Reference**](docs/policies.md) | Comprehensive specification of all 24 enforced policies, invariants, and the proactive tool surface (`guard_*`, `project_memory_*`, `learning_*`) |
 | [**Installation & Configuration**](docs/installation.md) | Setup options, global vs. local install, worktree isolation, and project configuration |
+| [**Static Policy Posture**](docs/policy-posture.md) | Emitting host-level policies for invariants a repository cannot lift: both host envelopes (`experimental.policies` on 2.0.x, top-level `policies` on 2.1.x), precedence, and residual risk |
 | [**Managed Deployment**](docs/managed-deployment.md) | Administrator-managed OpenCode policy, platform locations, and startup diagnostics |
 | [**Troubleshooting**](docs/troubleshooting.md) | Diagnosing policy blocks, common false positives, and emergency override procedures |
 | [**Testing Architecture**](docs/testing.md) | Test harness design, adversarial regression matrix, and CI verification |

package/bin/opencode-workflow-guard.mjs

@@ -2,15 +2,23 @@
 
 import { existsSync, mkdirSync, readFileSync, rmSync, writeFileSync } from "node:fs";
 import { homedir } from "node:os";
-import { dirname, join } from "node:path";
-import { parse, modify, applyEdits } from "jsonc-parser";
+import { join } from "node:path";
+import { preparePluginUpdate, PACKAGE_NAME } from "../src/lib/config-writer.mjs";
 
-const PACKAGE_NAME = "opencode-workflow-guard";
 const PACKAGE_VERSION = JSON.parse(readFileSync(new URL("../package.json", import.meta.url), "utf8")).version;
 const SERVER_SPEC = `${PACKAGE_NAME}@${PACKAGE_VERSION}`;
 const TUI_SPEC = SERVER_SPEC;
 const LEGACY_TUI_SPEC = "opencode-workflow-guard/tui";
 
+const USAGE = `Usage:
+  opencode-workflow-guard setup [--major 1|2]
+  opencode-workflow-guard policies --print [--format both|2.0|next]
+
+setup writes \`plugins\` for OpenCode 2 (the default) and \`plugin\` for OpenCode 1.
+An existing config's key wins unless --major is passed.
+\`policies\` defaults to both, which the 2.0.x and 2.1.x hosts each read under
+their own key. Pass --format to pin one host.`;
+
 function configHome() {
 	return process.env.XDG_CONFIG_HOME || join(homedir(), ".config");
 }
@@ -27,49 +35,62 @@ function restoreConfig(path, previous) {
 	else writeFileSync(path, previous);
 }
 
-function matchesPackageSpec(entry, spec) {
-	const value = Array.isArray(entry) ? entry[0] : entry;
-	return typeof value === "string" && (value === spec || value.startsWith(`${spec}@`));
-}
-function preparePluginUpdate(path, schema, spec, legacySpec) {
-	const source = existsSync(path) ? readFileSync(path, "utf8") : `{
-  "$schema": "${schema}"
-}\n`;
-	const errors = [];
-	const config = parse(source, errors, { allowTrailingComma: true, disallowComments: false });
-	if (errors.length > 0 || !config || typeof config !== "object" || Array.isArray(config)) {
-		throw new Error(`Cannot update invalid config: ${path}`);
+/**
+ * Static policy posture. Prints to stdout only.
+ *
+ * A plugin that writes another tool's configuration has moved the static rails
+ * back inside the thing they are meant to outlive. So: emit, never install.
+ */
+async function runPolicies() {
+	const args = process.argv.slice(3);
+	const formats = ["both", "2.0", "next"];
+	let print = false;
+	let format = "both";
+	for (let i = 0; i < args.length; i++) {
+		const arg = args[i];
+		if (arg === "--print") print = true;
+		else if (arg === "--format") {
+			format = args[++i];
+			if (!formats.includes(format)) throw new Error(`Unknown --format '${format}'. Use both, 2.0 or next.`);
+		} else if (arg.startsWith("--format=")) {
+			format = arg.slice("--format=".length);
+			if (!formats.includes(format)) throw new Error(`Unknown --format '${format}'. Use both, 2.0 or next.`);
+		} else throw new Error(`Unknown argument '${arg}'.`);
 	}
-	if (config.plugin !== undefined && !Array.isArray(config.plugin)) {
-		throw new Error(`Cannot update ${path}: "plugin" must be an array`);
-	}
-	const plugins = config.plugin ?? [];
-	const hasSpec = plugins.some((entry) => matchesPackageSpec(entry, PACKAGE_NAME));
-	const updatedPlugins = legacySpec
-		? plugins.filter((entry) => !matchesPackageSpec(entry, legacySpec))
-		: plugins;
-	if (updatedPlugins.length !== plugins.length) {
-		if (!hasSpec) updatedPlugins.push(spec);
-		return applyEdits(source, modify(source, ["plugin"], updatedPlugins, {
-			formattingOptions: { insertSpaces: true, tabSize: 2 },
-		}));
-	}
-	if (hasSpec) return undefined;
-	return applyEdits(source, modify(source, ["plugin", plugins.length], spec, {
-		formattingOptions: { insertSpaces: true, tabSize: 2 },
-	}));
+	if (!print) throw new Error("Refusing to write config. Pass --print and place the block yourself.");
+	const { renderPolicyPosture } = await import(new URL("../src/lib/policy-posture.ts", import.meta.url).href);
+	process.stdout.write(renderPolicyPosture({ format }));
 }
 
-if (process.argv[2] !== "setup" || process.argv.length > 3) {
-	console.error("Usage: opencode-workflow-guard setup");
+if (process.argv[2] === "policies") {
+	try {
+		await runPolicies();
+	} catch (error) {
+		console.error(error instanceof Error ? error.message : String(error));
+		console.error(USAGE);
+		process.exitCode = 1;
+	}
+} else if (process.argv[2] !== "setup") {
+	console.error(USAGE);
 	process.exitCode = 1;
 } else {
 	try {
+		const args = process.argv.slice(3);
+		let explicitMajor;
+		for (let i = 0; i < args.length; i++) {
+			const arg = args[i];
+			const raw = arg === "--major" ? args[++i] : arg.startsWith("--major=") ? arg.slice("--major=".length) : undefined;
+			if (raw === undefined) throw new Error(`Unknown argument '${arg}'.`);
+			if (raw !== "1" && raw !== "2") throw new Error(`Unknown --major '${raw}'. Use 1 or 2.`);
+			explicitMajor = Number(raw);
+		}
 		const base = join(configHome(), "opencode");
 		const serverPath = existingConfig(base, "opencode");
 		const tuiPath = existingConfig(base, "tui");
-		const serverUpdate = preparePluginUpdate(serverPath, "https://opencode.ai/config.json", SERVER_SPEC);
-		const tuiUpdate = preparePluginUpdate(tuiPath, "https://opencode.ai/tui.json", TUI_SPEC, LEGACY_TUI_SPEC);
+		const serverUpdate = preparePluginUpdate(serverPath, "https://opencode.ai/config.json", SERVER_SPEC, undefined, explicitMajor);
+		// `tui.json` keeps the singular `plugin` key on both majors: OpenCode 2
+		// reads that key and migrates it into `cli.json.plugins`.
+		const tuiUpdate = preparePluginUpdate(tuiPath, "https://opencode.ai/tui.json", TUI_SPEC, LEGACY_TUI_SPEC, explicitMajor, "plugin");
 		const serverBefore = existsSync(serverPath) ? readFileSync(serverPath, "utf8") : undefined;
 		const tuiBefore = existsSync(tuiPath) ? readFileSync(tuiPath, "utf8") : undefined;
 		mkdirSync(base, { recursive: true });

package/docs/installation.md

@@ -6,9 +6,52 @@
 
 ## Requirements
 
-- **OpenCode >= 1.18** (V1: requires the `GET /session/:id/todo` endpoint and the V1 `PluginModule` loader) or **OpenCode 2.x** (V2: loads through the `@opencode/plugin` API; the current todo list is reconstructed from the session message history because V2 has no todo endpoint).
+- **OpenCode >= 1.18** (V1: requires the `GET /session/:id/todo` endpoint and the V1 `PluginModule` loader) or **OpenCode 2.x** (V2: loads through the `@opencode/plugin` API; the current todo list is reconstructed from session message history, or read from the native `todowrite` on 2.1.x when `experimental.todo` is enabled).
 - **Node.js >= 22.18** or **Bun** (for running test scripts directly).
 
+### Version Qualification
+
+The guard declares exact host dependency versions, so an unreviewed host API can
+never float in. A host release is qualified only when it appears in this table
+with the seats that were actually exercised against it. An unlisted version is
+unqualified by definition, which does not mean it is broken; it means nobody has
+verified it.
+
+| Guard | OpenCode qualified | Hook seats exercised | Notes |
+|---|---|---|---|
+| 1.16.x | 2.0.15 | `permission.hook("evaluate")`, `tool.hook("execute.before"/"execute.after")`, `session.hook("context")`, `experimental.text.complete`, command registration, `mcp.list`, `worktree` client | Unit and package-loader verified. Live model-driven probes reached the provider and were classified `live unavailable` (`Model unavailable: openrouter/openrouter/auto`), so no guard verdict was produced. |
+| 1.16.x | 2.1.3 | `permission.hook("evaluate")`, `tool.hook(...)`, `session.hook(...)`, `experimental.text.complete`, command registration, `mcp.list`, `worktree` client, `todowrite` behind `experimental.todo` | Package-loader and headless-runtime verified (`npm run test:install`: 30 passed). Live host probe confirmed `ctx.tool.list()` exposes `todowrite` with `experimental.todo: true` and omits it when false. Live static-policy denial canary produced `Blocked by configuration policy`. |
+| 1.16.x | 1.18.32 (`@opencode-ai/plugin`) | V1 `PluginModule` loader, native todo endpoint | Compatibility export only; unit-tested, no live host probe. |
+
+The 2.1.3 pins require the 2.1.x package set. `@opencode/plugin` and
+`@opencode/ai` are pinned to `2.1.3`, which depends on `effect@4.0.1` and
+requires `@opentui/solid >=0.6.6`; the guard pins `0.6.6`. A 2.0.x pin set on a
+2.1.x host fails to load at all: the plugin imports an `effect` path the host no
+longer provides, and the host reports `failed to load plugin` while every
+policy stays inert.
+
+`guard_status` reports `pluginVersion`, `qualifiedHostVersion`, and the live
+`hostVersion`, so a mismatch is visible at runtime rather than surfacing as a
+silently inert hook.
+
+### Dependency Audit Overrides
+
+Two transitive dependencies are pinned above the range their parent declares, to
+clear advisories that would otherwise ship:
+
+| Package | Parent constraint | Override | Why |
+|---|---|---|---|
+| `solid-js` | `@opentui/solid@0.6.6` peer-pins exactly `1.9.12` | `1.9.17` | `1.9.12` requires `seroval ~1.5.0`, which carries memory-exhaustion and thenable-assimilation advisories. `1.9.17` requires `seroval ~1.6.8`, which is patched. The TUI imports `solid-js` directly, so the bump is also the version the guard actually runs. |
+| `toml` | `effect@4.0.0-beta.83` (via `@opencode-ai/plugin`) requires `^4.1.1` | `5.0.1` | `toml <=5.0.0` carries three quadratic-complexity denial-of-service advisories. `5.0.1` keeps the same single `parse` export the caller uses. The guard itself never parses TOML; this is host plumbing. |
+
+Both are `overrides` entries in `package.json`, and `npm audit` reports zero
+vulnerabilities for this repository. `npm overrides` apply only to the root
+project, so they protect this repository's install and its CI, not a consumer's
+transitive tree. A consumer that installs the published package resolves the
+parent-declared ranges unless it declares the same overrides itself. Revisit both
+when `@opentui/solid` or `@opencode-ai/plugin` widen their ranges, and drop the
+override rather than carrying it forward.
+
 ---
 
 ## Installation Methods
@@ -27,7 +70,7 @@ OpenCode 2 documents `opencode plugin add <package>` as the command to install a
 
 Use the same two commands to upgrade after a Workflow Guard release. Keep the explicit version in OpenCode's configuration rather than relying on a bare package name or `@latest`: OpenCode caches npm plugins, and an already-populated `@latest` cache key may continue resolving to the version that originally populated it. An explicit new version creates a new package-cache key without manually deleting OpenCode's cache.
 
-If you only want the server guard without the TUI companion, add the package to your project's `opencode.json` (or global `~/.config/opencode/opencode.json`). OpenCode 2 uses the plural `plugins` key; OpenCode 1.x uses the singular `plugin` key (V2 normalizes the singular form in memory, but the native shape is `plugins`):
+If you only want the server guard without the TUI companion, add the package to your project's `opencode.json` (or global `~/.config/opencode/opencode.json`). OpenCode 2 reads only the plural `plugins` key; OpenCode 1.x uses the singular `plugin` key. A singular key in an OpenCode 2 config is dropped by the config schema without an error, so the guard will appear configured and never load:
 
 ```json
 {
@@ -40,11 +83,43 @@ If you only want the server guard without the TUI companion, add the package to
 
 OpenCode automatically installs configured npm plugins and their dependencies at startup. The npm package contains both server and TUI entrypoints, but OpenCode activates them from separate configuration files. See [OpenCode's npm plugin documentation](https://opencode.ai/docs/plugins/#from-npm) and [plugin installation behavior](https://opencode.ai/docs/plugins/#how-plugins-are-installed).
 
+### 2. Self-Configuring `setup` Command
+
+The package ships a `setup` command that writes the plugin entry into the global
+configuration for you:
+
+```bash
+opencode-workflow-guard setup            # OpenCode 2: writes `plugins`
+opencode-workflow-guard setup --major 1  # OpenCode 1: writes `plugin`
+```
+
+The command detects the target from the existing config: a `plugins` key means
+OpenCode 2, a `plugin` key means OpenCode 1, and a fresh config defaults to
+OpenCode 2. `--major` overrides the detection. The two keys are not
+interchangeable: OpenCode 2's config schema drops a singular `plugin` key
+without an error, so writing the wrong one produces a config that looks
+configured and loads nothing. The writer refuses to clobber an unparseable
+config or a non-array plugin key.
+
+`tui.json` is the exception to the key rule. Its schema reads singular `plugin`
+on both majors, and OpenCode 2 migrates that key into `cli.json.plugins`. So
+`--major 2` writes `plugins` to the server config and still writes `plugin` to
+`tui.json`; a plural key there is silently ignored and the TUI badge never
+loads.
+
+### Configure The Guard In One Location Only
+
+Name the guard in exactly one place per OpenCode process: either the global configuration (`~/.config/opencode/opencode.json[c]`, `plugins` on 2.x or `plugin` on 1.x) or a project configuration, never both. OpenCode 2 merges plugin arrays instead of replacing them, so listing `opencode-workflow-guard` globally and again in a project's `.opencode/opencode.json` loads the same entrypoint twice under two ids. Two instances register duplicate hooks and duplicate tool definitions, which evaluates and audits every tool call twice, lets one instance overwrite the other's tool-description enrichment, and primes the process-global workspace latch from two roots in the same tick.
+
+The guard detects the duplicate instead of failing silently: the first instance for a given (module path, workspace root) pair owns enforcement, and a later instance registers no hooks or tools. The duplicate is recorded at warn level in the server log and as an audit record (`tool: "plugin.instance"`, `reason: "duplicate_plugin_load"`) in `workflow-guard.jsonl`, so `grep 'loading plugin.*workflow-guard'` on a fresh server log showing two lines is a configuration error, not a supported setup. As a second layer, the first instance to reach a given (session, call, tool) claims its policy decision, so a guard loaded from two distinct paths (an npm cache copy plus a source checkout) still produces one decision per call.
+
+A repository that ships its own `.opencode/opencode.json` with a `plugin`/`plugins` entry is the usual source of the second copy. Remove the entry there and let the global configuration carry the guard. Because OpenCode settings are tamper-protected from agent edits, that file must be changed by the operator.
+
 A configured bare package name is resolved through Node's parent-directory lookup from OpenCode's configuration location: any `node_modules` above that location that contains a copy of the package (a pnpm-managed home directory, a manual `npm install`, or a workspace dependency) is loaded instead, shadowing both OpenCode's own plugin cache and a global `npm install -g` — updating the wrong copy leaves an old version running while the update appears to succeed, and OpenCode's own plugin-update check can fail with only a server-log record (`NpmInstallFailedError`). Update the copy that actually loads (for a pnpm-managed home directory: `pnpm add opencode-workflow-guard@<version>` in that directory, or remove the dependency so OpenCode manages its own copy), then restart the background service (`opencode service restart`) — the plugin loads there, so a TUI-only restart is not enough. Verify what loaded: `guard_status` reports the loaded version as `pluginVersion`, the startup app log states `Workflow Guard v<version> plugin initialized`, and the server log records the resolved module path in its `loading plugin` entry.
 
 ---
 
-### 2. Manual Local-File Installation (Server Plugin)
+### 3. Manual Local-File Installation (Server Plugin)
 
 The npm package entrypoint uses OpenCode's V1 plugin module shape (`{ id, server }`). For a source checkout, keep the modular server source outside the auto-loaded `plugins/` directory and add a small adapter with the same module shape:
 
@@ -59,7 +134,7 @@ OpenCode automatically discovers the adapter from the project-level `.opencode/p
 
 ---
 
-### 3. TUI Visual Indicator (Prompt Box Badge)
+### 4. TUI Visual Indicator (Prompt Box Badge)
 
 To enable the static `Workflow Guard 🛡️` prompt-bar badge, with block details reported separately through warning toasts:
 

package/docs/managed-deployment.md

@@ -4,7 +4,7 @@ For organization-managed installations, deploy workflow-guard together with Open
 
 As documented by OpenCode, managed configuration has the highest configuration precedence. Place `opencode.json` or `opencode.jsonc` in `/etc/opencode/` on Linux, `/Library/Application Support/opencode/` on macOS, or `%ProgramData%\opencode` on Windows. macOS can additionally use the `ai.opencode.managed` preference domain through MDM. Verify the resolved host configuration with `opencode debug config`.
 
-A typical managed configuration should restrict organization-level capabilities, for example with `enabled_providers`, `disabled_providers`, `experimental.policies`, and `permission`. Install workflow-guard through your controlled OpenCode distribution or configuration alongside those settings, and pin/review the package version according to your normal software-supply-chain process.
+A typical managed configuration should restrict organization-level capabilities, for example with `enabled_providers`, `disabled_providers`, `experimental.policies` (2.0.x) or top-level `policies` (2.1.x), and `permission`. Install workflow-guard through your controlled OpenCode distribution or configuration alongside those settings, and pin/review the package version according to your normal software-supply-chain process.
 
 Workflow Guard's project `profile` is a convenience for optional workflow defaults, not a security level. The `interactive` default and `autonomous` profile enforce the same core safety invariants; `autonomous` currently enables recovery checkpoints by default. Explicit project feature settings override profile defaults. Ralph mode is orchestration-adjacent and therefore remains disabled unless the project explicitly sets `ralphMode: true`; selecting `autonomous` does not enable it.
 

package/docs/policies.md

@@ -1,6 +1,8 @@
 # Enforced Policies & Guardrails
 
-`opencode-workflow-guard` enforces workflow discipline through **deterministic TypeScript hooks** (`tool.execute.before`, `experimental.session.compacting`, `shell.env`, `permission.ask`, and `event` journaling) - not prompt rules that LLMs can ignore.
+`opencode-workflow-guard` enforces workflow discipline through **deterministic TypeScript hooks** - not prompt rules that LLMs can ignore.
+
+On OpenCode 1.x those hooks are `tool.execute.before`, `experimental.session.compacting`, `shell.env`, `permission.ask`, and `event` journaling. On OpenCode 2.x they are `tool.hook("execute.before"/"execute.after")`, `session.hook("context"/"compaction"/"prompt")`, `command.transform`, `permission.hook("evaluate")`, `shell.hook("create.before")`, and `event.subscribe()`. V1 plugin implementations do not run on OpenCode 2, so the two lists describe separate entrypoints, not alternatives for the same host.
 
 It is a policy and enforcement layer, not an agent harness. Policies may constrain actions, record or explain decisions, and preserve bounded context; they do not plan, prioritize, delegate, or autonomously sequence work. Where Workflow Guard resumes an idle session, it only enforces already-owned todo lifecycle state and does not choose what the agent works on next.
 
@@ -9,11 +11,16 @@ It is a policy and enforcement layer, not an agent harness. Policies may constra
 ## Policy Reference
 
 ### 1. Task Breakdown & Lifecycle (`todowrite`)
-- **Pre-edit Gate:** All file-editing tools (`edit`, `write`, `apply_patch`) are blocked while the session's effective todo list is known and contains no active task. On OpenCode 1.x the list comes from the native todo system (`todowrite`, persisted at `GET /session/:id/todo`). On OpenCode 2.x there is no todo endpoint and no builtin `todowrite`, so the list is reconstructed from the newest applied `todowrite` tool call in the session history (ACP agents may supply that tool). The gate distinguishes a **definitively empty** list (a `todowrite` part exists and reports no active task → still blocked) from an **undeterminable** one (no `todowrite` part exists at all, i.e. no todo capability, or the history cannot be read → the gate fails open). This keeps builtin-only V2 sessions usable instead of deadlocking every edit forever.
+- **Pre-edit Gate:** All file-editing tools (`edit`, `write`, `apply_patch`) are blocked while the session's effective todo list is known and contains no active task. On OpenCode 1.x the list comes from the native todo system (`todowrite`, persisted at `GET /session/:id/todo`). On OpenCode 2.x before 2.1.0 the builtin tool registry has no `todowrite`, and there is no todo endpoint, so the list is reconstructed from the newest applied `todowrite` tool call in the session history (ACP agents may supply that tool). OpenCode 2.1.x reintroduces a builtin `todowrite` behind the `experimental.todo` config key; the guard detects that capability by probing the host tool registry rather than inferring it from history. Verified on 2.1.3: `ctx.tool.list()` exposes `todowrite` when the flag is on, and omits it when off. The gate distinguishes a **definitively empty** list (the capability exists and reports no active task → still blocked) from an **undeterminable** one (no todo capability, or the history cannot be read → the gate fails open and records that once per session at warn level). This keeps builtin-only V2 sessions usable instead of deadlocking every edit forever.
 - **Flexible Task Execution:** Tasks can be completed in any order as work concludes without artificial sequential blockers, maintaining maximum pair-programming DX.
 - **No Silent Deletion:** Each `todowrite` update replaces the complete list. Active tasks must remain in subsequent updates until they are explicitly marked `completed` or `cancelled`.
+- **Per-Task Completion Evidence (enforced):** Because a `todowrite` call replaces the whole list, a model can mark work `completed` without doing it. A task may therefore enter `completed` only when the session recorded at least one file mutation inside that task's active window. One mutation cannot vouch for several completions, so N completions require N mutations counted from the earliest of them, and mutations spent before a task became active never count toward it. A blocked write names the task and the remedy, and the check runs in simulation too, so `guard_why` predicts the gate instead of reporting a falsely permissive verdict. A finished or dropped task releases its window, so reusing the same task text starts clean. Tasks are matched to their prior occurrences by count, so duplicate text cannot hide a new completion behind an already-completed item; the mutation counter records permitted mutation calls, not confirmed byte changes.
+  - **Planned late:** a task first observed already `completed` has no window to judge, so it is scored against the session's mutation history instead. This is the deliberate path for an agent that did the work before writing the list, and it stays bounded by the one-mutation-per-completion rule.
+  - **Read-only escape:** a task whose text carries `[read-only]` (also `[read_only]` / `[read only]`) completes without a mutation, because review, investigation, and reading are legitimate work that changes no file. The marker is an annotation, not part of task identity, so it can be appended to an already-planned task without reading as a deletion. Every use is journaled as `todo_completed_read_only`, so relabeling real work as read-only is visible in the audit trail rather than silent; that journal is the only counterweight in a repository with no detectable verify command. Work that was deliberately dropped uses `cancelled` instead.
+  - `guard_status` reports `taskEvidence` (`active`, `completed`, `tasksWithoutRecordedWork`, `readOnlyTasks`) so the requirement is visible before it blocks anything. This is not task authority: fresh verification evidence and the review gate remain the authority on finalization.
+- **Todo Capability Visibility:** Because the gate depends on the host exposing `todowrite` at all, `guard_status` reports `todoCapability` (`available` / `unavailable` / `unknown`), so a fail-open gate is visible rather than decorative.
 - **No Silent Early Exit:** When an owning session becomes `session.idle` with unfinished native todos, the guard asynchronously asks OpenCode to resume the existing run. This enforces the session's existing lifecycle state: Workflow Guard does not choose the next task, reorder work, create work, or delegate it. Ordinary automatic continuations are capped at three consecutive attempts and the budget resets on genuine user input. User-initiated interrupts (Esc) surface as `MessageAbortedError` and suspend automatic continuation for that session until genuine user input arrives, mirroring the ralph `user_stopped` semantics. The independently opt-in `ralphMode` uses `ralphMaxIterations` (1-100, default 10) instead; genuine user input terminates an active Ralph run, and unfinished work at the budget limit reports `budget_exhausted` rather than inferring a policy block. Ralph remains disabled by default under every operation profile. Use OpenCode's native `question` tool when user feedback or a decision is required; question and permission interactions wait inside the active run rather than producing an idle completion.
-- **Subagent Inheritance & Role Confinement:** Subagents automatically inherit active tasks from their parent session via the `parentID` hierarchy. Subagents spawned with read-only roles (`reviewer`, `planner`, `advisor`, `critic`, `explorer`, `scout`, `evaluator`) are hard-confined: file mutations, lifecycle tools, and mutating shell commands are strictly blocked.
+- **Subagent Inheritance & Role Confinement:** Subagents automatically inherit active tasks from their parent session via the `parentID` hierarchy. Subagents spawned with read-only roles (`reviewer`, `planner`, `advisor`, `critic`, `explorer`, `scout`, `evaluator`) are hard-confined: file mutations, lifecycle tools, and mutating shell commands are strictly blocked. On OpenCode 2 the confinement is two-layered: `session.hook("context")` deletes the mutating tools (`write`, `edit`, `patch`, `apply_patch`, `shell`, `bash`, `execute`, `todowrite`, `subagent`/`task`, worktree lifecycle tools) from that role's per-request tool snapshot, and `execute.before` stays as the backstop for tools supplied outside the snapshot (ACP agents, nested Code Mode calls). The pruning is journaled as `session.context` / `read_only_role_tools_pruned`.
 - **Handoff Safety:** An idle subagent whose effective todos are inherited from its parent is not auto-continued. Inherited work belongs to the parent and can be handed back normally.
 - **Durable Planning Context Discovery:** `guard_next_tasks` prefers a repository-root `TODO.md`; when it is absent, it reads conventional `ROADMAP.md`, `PLAN.md`, `TASKS.md`, `BACKLOG.md`, their `docs/` counterparts, and Markdown files under `docs/plans/`. The tool exposes candidate planning context without selecting, prioritizing, or sequencing tasks. These files never replace OpenCode's native runtime todo state.
 - **Subagent Mutation Budget:** Subagent sessions are protected by a mutation safety budget (`maxSubagentMutations` in project config or `WORKFLOW_GUARD_MAX_SUBAGENT_MUTATIONS` env, default 100) to terminate runaway edit loops deterministically.
@@ -54,6 +61,7 @@ It is a policy and enforcement layer, not an agent harness. Policies may constra
 - MCP tools that mutate live GitHub or Azure/DevOps systems (`create`, `update`, `delete`, `merge`, `push`, `close`, etc.) are blocked.
 - Server names are tokenized on all non-alphanumerics, so `mcp__azure-devops__...`, `mcp__gh__...` and flat legacy names (`azure_devops_*`) are matched.
 - Read-only tools (`get`, `list`, `search`, `query`, etc.) are permitted.
+- On OpenCode 2 the guarded server set is widened from the host's own MCP roster (`ctx.mcp.list()`), refreshed on `mcp.tools.changed`, so a renamed or enterprise instance of a guarded product is still matched. Widening is one-way by design: removing a server adds nothing, and the static token list stays the floor, because tool names are model-supplied text and this is a live-system rail.
 
 ### 6. Settings Tamper Guard
 - Prevents the agent from weakening its own permission gates **via shell or edit tools**:
@@ -82,6 +90,7 @@ It is a policy and enforcement layer, not an agent harness. Policies may constra
 - `mv` sources are validated too: moving a file from outside the workspace (or a protected settings/plugin file to an innocuous name) is blocked, since `mv` mutates the source.
 - External repository git writes (`git -C /other-repo commit`, `git --git-dir=/other-repo/.git push`, `GIT_DIR=/other-repo/.git git push`, `GIT_WORK_TREE=...`) are also confined to the workspace.
 - The boundary has **no override**: `WORKFLOW_GUARD_ALLOW_LIVE=1` covers live-system commands only and never weakens the workspace confinement.
+- **The boundary is bound once, then only the host may widen it.** A session adopts its workspace from its own first tool-call context (a call-argument path, or the host-provided per-call worktree). After that, a path outside the boundary is foreign state: the boundary policy refuses mutations there, and the path never re-anchors the session. Only an explicit host-declared per-call worktree widens a bound session, because worktree isolation and relay flows set it deliberately. A subagent is bound by the same rule through its nearest bound ancestor: with no direct binding of its own it already inherits the parent's workspace for policy decisions, so its first foreign read is refused as a widening rather than adopted as a first bind. Every granted widening is journaled (`workspace.binding` / `workspace_rebind_host_worktree`) and every refused one is journaled with the read-or-mutation label (`workspace.binding` / `workspace_rebind_refused`). This closes the defect where one allowed read of a file in another repository moved the entire write boundary into that repository, because `external_directory` defaults to allow.
 
 ### 9. Script-Laundering Guard
 - Content written via `edit`, `write`, or `apply_patch` is scanned for destructive CLI commands.
@@ -115,10 +124,13 @@ It is a policy and enforcement layer, not an agent harness. Policies may constra
 ### 14. Audit Trail & Permission Journaling
 - Every block/allow decision is appended to `~/.local/state/opencode/workflow-guard/workflow-guard.jsonl` (XDG_STATE_HOME respected) with a timestamp, session id, tool name, decision, subagent/parent session attribution, and reason - a durable record.
 - Permission prompts are journaled at request time via the typed `permission.ask` plugin hook, and `permission.replied` outcomes (including rejections) are preserved instead of being labeled as allows.
+- On OpenCode 2, the V2 plugin also *decides* at that seat: `ctx.permission.hook("evaluate")` maps the host's normalized `action`/`resources` back onto the policy core and sets `effect = "deny"` with an attributable message, so the tool never starts. Shell resources feed the shell, git, destructive, and workspace policies. `read` resources feed the secret policy. `edit`/`write`/`patch`/`apply_patch` resources feed the boundary, tamper, secret, protected-branch, and todo policies. Guarded MCP servers (`GitHub`, `Azure DevOps`) feed the MCP policy.
+- The seat can only tighten. An explicit configured `deny` is final and never reaches the hook, and an unmapped host action (`external_directory`, `glob`, `grep`, `webfetch`, `websearch`, `question`, `subagent`) is left to host policy. If the seat itself throws, it fails closed with a deny instead of becoming a pass.
+- `execute.before` is kept as the second, last-resort seat: it sees raw tool input, so todo lifecycle, stale-write observations, and post-edit snapshots stay there, and its thrown message carries the specific remediation text to the model.
 - `client.app.log()` complements the on-disk trail with in-app logs.
 
 ### 15. Compaction State & Policy Context Preservation
-- Integrates with OpenCode's `experimental.session.compacting` hook to inject bounded active policy state into `output.context` before context summarization:
+- Integrates with OpenCode's compaction hook to inject bounded active policy state before context summarization: `experimental.session.compacting` on OpenCode 1.x, `session.hook("compaction")` on OpenCode 2.x (stable in the installed 2.1.3 typings):
   - Caps injected continuity context at 8,000 characters, preserving operational guard state first and filling the remaining budget with active tasks, review follow-ups, and fresh local project memory.
   - Active `todowrite` tasks with status badges and subagent hierarchy attribution.
   - Active Git branch name and protected branch status.
@@ -192,7 +204,8 @@ Besides enforcement hooks, the guard registers companion tools in OpenCode:
 
 ### `guard_worktree_cleanup`
 - Commits a final snapshot of any remaining changes (`chore(worktree): auto-snapshot before cleanup`, excluding the plugin-created `node_modules` symlink) and then removes the worktree directory with `git worktree remove --force`.
-- **Ownership validation:** only registered worktrees of the current repository under the configured worktree storage directory can be cleaned up; arbitrary directories, other repositories' worktrees, and the primary working tree are refused. A failed `git worktree remove` is an error, never a fallback to raw directory deletion.
+- **Ownership validation:** only registered worktrees of the current repository are cleaned up. The path must be under the configured worktree storage directory, or be declared by the host's own worktree inventory (`ctx.worktree.list()` on OpenCode 2). Arbitrary directories, other repositories' worktrees, and the primary working tree are refused. A failed `git worktree remove` is an error, never a fallback to raw directory deletion.
+- On OpenCode 2, creation goes through the host worktree API when it is available, so the worktree lands in the operator's configured `worktree.directory` and appears in host inventory. The host's answer is validated independently (existing directory, registered worktree of this repository, not the primary tree) and any failure falls back to the guard's git path. Removal never delegates to the host: its `remove` takes a `force` flag with no snapshot step, so it could destroy uncommitted work that this policy preserves. After a successful removal the guard asks the host to refresh its inventory.
 - **Idempotent for prunable entries:** a registered worktree whose directory is already gone (manual removal, a crashed add, external cleanup) is deregistered (`git worktree prune`, reported with its exit status on failure) and reported as cleaned, so stale admin entries that `git worktree list` shows as prunable can be cleared through the tool. The prune is repo-wide for the current repository: every worktree whose directory is missing at that moment is deregistered, so a temporarily unavailable path's admin entry can be dropped (worktree contents are never touched; use `git worktree repair` if a path returns).
 - **Lossless by construction:** if the snapshot commit cannot be established (failing hook, missing identity, lock error), cleanup aborts and the worktree is left fully intact.
 
@@ -200,7 +213,9 @@ Besides enforcement hooks, the guard registers companion tools in OpenCode:
 - All spawned git commands run with a sanitized environment: inherited git context variables (`GIT_INDEX_FILE`, `GIT_DIR`, `GIT_WORK_TREE`, ...) are stripped so the tools resolve the repository from their working directory alone. This makes them safe to invoke from inside git hooks, which export those variables.
 
 ### Inspection Tools
+### `guard_status`
 - `guard_status`, `guard_audit`, `guard_why`, `guard_review_rubric`, `record_review`, `guard_review_followups`, and `guard_review_followup_resolve` provide runtime introspection of guardrail state, audit entries, block explanations, reviewer rubric definitions, reviewer decisions, and durable local review debt. `guard_status` also exposes the effective Ralph opt-in, iteration budget, and calling-session outcome when applicable, a read-only `gitHygiene` snapshot (local branches already merged into the mainline, prunable worktree admin entries, and the current branch's base-behind distance — hygiene itself stays manual: the guard reports, it never prunes or deletes branches), and `pluginVersion`, the version of the loaded guard package, so a stale installation is visible.
+- On OpenCode 2 the same report is also reachable as the server-side `/guard-status` command (`ctx.command.transform`), which delivers the JSON as a synthetic message with no model turn. That path needs no separately installed TUI companion.
 - **Priority-Ranked Review Gate:** Secondary review approval (`requireReview`) is enforced by default during PR preflight (`gh pr create` / `az repos pr create`). Before creating a pull request, a secondary reviewer subagent must evaluate the changes using `guard_review_rubric` and record approval with `record_review`. Approvals that include active P0 (blocker) or P1 (major defect) issues are rejected until blockers are resolved. Projects can opt out via `.opencode/workflow-guard.json` (`{ "requireReview": false }`) or environment variable `WORKFLOW_GUARD_REQUIRE_REVIEW=0`. Conversely, `WORKFLOW_GUARD_REQUIRE_REVIEW=1` forces the review requirement regardless of project config.
 - **Review binding is content, not session identity:** a recorded approval satisfies the PR preflight when its binding (same repository, same commit hash, same tracked-content worktree fingerprint) matches the tree the PR would publish - regardless of which session records the verdict or creates the PR. Reviewers record from subagent sessions (binding the verdict to their parent or their own directory) and sessions can move between directories (`session_move`) or spawn subagents from other roots, so keying the gate on the PR-creating session's ID made the documented flow impossible to satisfy from linked worktrees. Freshness is scoped to the reviewed diff (tracked content): untracked scratch-file cleanup and mutations in sibling worktrees cannot invalidate an approval, while any tracked edit or new commit does.
 - **`record_review` accepts any recorder session:** reviewer agents configured with a read-only toolset (e.g. glob/grep/read/webfetch only) cannot call `record_review` themselves, so the tool no longer rejects root/orchestrator sessions; the verdict binds to the recording session's resolved directory, the tool result echoes that binding, and the audit entry (`record_review.verdict`) records the binding key and recorder lineage (`recorderRole: root | subagent`). Prefer relaying through an independent secondary reviewer subagent; the tool result reminds the recorder when it runs from a root session. A verdict recorded against a directory without a computable tracked fingerprint (not a git repository) is rejected loudly and never recorded.

package/docs/policy-posture.md

@@ -0,0 +1,171 @@
+# Static Policy Posture
+
+Workflow Guard has three enforcement seats. Two of them live inside the plugin:
+
+| Seat | Runs in | Removed by |
+|---|---|---|
+| `ctx.permission.hook("evaluate")` | the plugin | uninstalling or disabling the plugin |
+| `execute.before` | the plugin | uninstalling or disabling the plugin |
+| static configuration policies | the host | editing the config that carries them |
+
+Static policies are the only layer a repository cannot lift. A project cannot
+grant itself a permission the host denies in global config, because the host
+resolves static policy before any plugin hook runs. That is the whole point of
+this surface, and it is also why the plugin refuses to install it for you.
+
+## Emit, do not install
+
+```
+opencode-workflow-guard policies --print
+opencode-workflow-guard policies --print --format 2.0
+opencode-workflow-guard policies --print --format next
+```
+
+The command writes JSONC to stdout and nothing else. It refuses to run without
+`--print`. A plugin that can write the configuration holding its own static
+rails has moved those rails back inside the plugin, so the operator places the
+block.
+
+The default is `both`, which emits each rule under the key its host reads:
+
+| Format | Envelope | Rule action | Host that reads it |
+|---|---|---|---|
+| `both` (default) | `experimental.policies` and top-level `policies` | `permission` and `tool.use` | 2.0.x and 2.1.x |
+| `2.0` | `experimental.policies` | `permission` | 2.0.x only |
+| `next` | top-level `policies` | `tool.use` | 2.1.x only |
+
+The envelopes are not interchangeable, and neither host warns about the one it
+does not read. OpenCode 2.0.x evaluates `experimental.policies` with
+`action === "permission"` and ignores a top-level `policies` array entirely.
+OpenCode 2.1.x evaluates the top-level `policies` array with
+`action === "tool.use"` and ignores `experimental.policies`. A single-key block
+therefore looks applied on the other host and enforces nothing.
+
+Both hosts read only their own key, so carrying both cannot double-apply a rule
+or make them conflict. `--format 2.0` and `--format next` exist for a pinned
+host; `both` is the default because the silent no-op is the failure this
+surface exists to prevent.
+
+Schema acceptance is not runtime acceptance. `@opencode/schema` 2.0.10 admits a
+top-level `policies` array that the 2.0.15 runtime never reads, so a decode test
+grades the block as valid while the host enforces nothing. The envelope table
+above is verified by live denial canaries on both hosts, in the acceptance
+section below.
+
+## What is emitted
+
+| Rule | Action | Resource | Why |
+|---|---|---|---|
+| protected trunk push | `shell` | `git push * main`, `git push * master`, `git push * HEAD:main`, `git push * HEAD:master` | trunk must stay protected when the plugin is absent |
+| live control plane write | `edit` | `*/.config/opencode/*`, `/etc/opencode/*`, `/Library/Application Support/opencode/*` | an agent that can edit the control plane can rewrite its own constraints |
+| secret material read | `read` | `*/.ssh/*`, `*id_rsa*` | private keys should never enter a model context |
+| external directory widening | `external_directory` | `*` | `external_directory` defaults to allow; denying it is what makes the write boundary a boundary |
+| Code Mode surface | `execute` | `*` | removes the nested tool surface where the host asserts the action |
+
+Every emitted rule is a denial. A posture that granted access would be a second,
+weaker policy engine in a config file, and the plugin already owns that job.
+
+The control-plane rule starts with `*/` rather than `~/` on purpose: 2.0.x
+expands `~` and `$HOME` only for the `permissions` key, not for
+`experimental.policies`, so a tilde resource would never match an absolute path.
+`*/.config/opencode/*` is version-independent and covers every home directory.
+
+Two of these are judgement calls rather than obvious wins, so drop them
+deliberately if they conflict with normal work:
+
+- `external_directory: *` denies every path outside the active project. Cross
+  repository reads then require an explicit later `allow` rule. That is the
+  strict posture, and it is the one the write-confinement work assumes.
+- `execute: *` removes Code Mode. The qualified hosts (2.0.15 and 2.1.3)
+  register no `execute` tool and never assert an `execute` permission action,
+  so the rule is inert on both and Code Mode stays available. On a host that
+  does assert the action, the rule removes a surface whose nested tool calls
+  this guard does not evaluate. The plugin's read-only tool pruning and
+  `execute.before` remain the coverage today.
+
+## Precedence
+
+Highest authority first:
+
+| Authority | Source |
+|---|---|
+| 0 | managed preferences and Console policies |
+| 2 | `OPENCODE_CONFIG_CONTENT` |
+| 3 | `/etc/opencode` |
+| 4 | `~/.config/opencode` |
+| 5 | project `opencode.json(c)` |
+
+Within one ruleset the last matching rule wins. Across documents the earlier
+authority wins. Two consequences matter when you place the block:
+
+1. Put it in the system or global config (authority 3 or 4), never in a project
+   file. A project file is the scope the rules are meant to outrank.
+2. If you add broad `allow` rules for local workflows, place these denies after
+   them in the same file. A deny that lands earlier is shadowed.
+
+On 2.0.x, the host builds its rule list by reversing the document order and
+then taking the last match per resource, so a global document beats a project
+document for the same resource. Verified in the 2.0.15 binary
+(`opencode.config.policy`).
+
+## Residual risk
+
+Read this before treating the block as a sandbox.
+
+- Policies do not sandbox plugin code. A plugin can still do anything the
+  process can do.
+- A process that can write the file carrying these rules can remove them. File
+  ownership and permissions are the control there, not policy.
+- Shell patterns match the whole command string. `cd /tmp && git push origin
+  main` does not match `git push * main`, and neither does an exotic refspec
+  spelled differently. The static floor covers the direct forms only. This gap
+  is covered by a regression test, which asserts the evasion succeeds so the
+  limit stays visible.
+- A denied provider is blocked on the normal path only. Alternate paths are not
+  covered by `provider.use` policies.
+- Effect values are `allow` and `deny`. There is no `ask` at this seat, which is
+  why the emitted rules deny rather than prompt.
+
+## Acceptance status
+
+**Status: RUN.** The canary installs the emitted block into an isolated project
+config and drives a real model turn that calls the denied tool. It is run once
+per host.
+
+| Host | Emitted block | Probed rule | Result |
+|---|---|---|---|
+| 2.0.15 | `--format 2.0` | `shell:printf*` | `Blocked by configuration policy` |
+| 2.1.3 | `--format 2.0` | `shell:printf*` | **executed** (silent no-op) |
+| 2.0.15 | `--format next` | `shell:printf*` | **executed** (silent no-op) |
+| 2.1.3 | `--format next` | `shell:printf*` | `Blocked by configuration policy` |
+| 2.0.15 | default (`both`) | `read:*id_rsa*` | `Blocked by configuration policy` |
+| 2.1.3 | default (`both`) | `read:*id_rsa*` | `Blocked by configuration policy` |
+
+The two silent no-ops are the defect this section exists to prevent, and they
+are why the default emits both envelopes. A single-key block is not merely
+unverified on the other host. It is actively misleading there, because the
+config loads and reports no error.
+
+Two limits on the canary, so nobody over-reads it:
+
+- The `write` tool is gated by the `edit` permission action on 2.1.3 but not on
+  2.0.15, so a `write` canary would not have proved the `edit` rule on both.
+  The `read` rule was chosen for the cross-host proof because both hosts map it
+  identically.
+- The `execute` invariant stays inert on both qualified hosts, because neither
+  registers an `execute` tool. Its canary cannot pass until a host asserts the
+  action, and the rule is documented as inert rather than claimed as coverage.
+
+Placing the block in a live control-plane path stays out of scope for an agent:
+the tamper policy refuses that write, and that refusal is correct. The canary
+uses an isolated project config instead, which exercises the same evaluator.
+
+The emitted resources are also asserted against a replica of the host matcher in
+`test/test.mts`, and both envelopes are required to reach the same verdict for
+every probed resource.
+
+To run the canary yourself, install the block into `~/.config/opencode`, then
+attempt a denied action in a live session and confirm the message names
+configuration policy rather than the plugin. Use the default (`both`) envelope
+unless you have pinned the host, and check the result on the host you actually
+run.

package/docs/testing.md

@@ -24,7 +24,7 @@ Packs the npm tarball, installs it into an isolated project to verify the modula
 npm run test:install # package install + provider-free OpenCode loader check
 WORKFLOW_GUARD_LIVE_E2E=1 npm run test:install # also run model-driven policy probes with OpenCode's most recently selected model
 ```
-Package and loader checks remain deterministic. Live probes explicitly select the first entry in OpenCode's persisted recent-model state (`${XDG_STATE_HOME:-~/.local/state}/opencode/model.json`) instead of silently inheriting the configured default model. Set `WORKFLOW_GUARD_LIVE_MODEL=provider/model` to override that selection; provider credentials still come from the normal OpenCode environment. If the selected model provider rejects a live prompt before guard behavior can run because credits, rate limits, capacity, or overload make the provider unavailable, that live case is reported as unavailable rather than as a guard failure. Other live-runtime failures still fail the suite.
+Package and loader checks remain deterministic. Live probes explicitly select the first entry in OpenCode's persisted recent-model state (`${XDG_STATE_HOME:-~/.local/state}/opencode/model.json`) instead of silently inheriting the configured default model. Set `WORKFLOW_GUARD_LIVE_MODEL=provider/model` to override that selection; provider credentials still come from the normal OpenCode environment. If the selected model provider rejects a live prompt before guard behavior can run because credits, rate limits, capacity, overload, or an unresolvable model make the provider unavailable, that live case is reported as unavailable rather than as a guard failure. The classifier matches the host's literal `Model unavailable:` error line rather than the bare phrase, so model prose cannot mask a real guard regression. Other live-runtime failures still fail the suite.
 
 ### 4. Full Verification Suite
 Runs typecheck, unit tests, and live runtime installation tests in sequence:
@@ -53,4 +53,7 @@ npm run test:all
 | **Completion Claims & Tool Honesty** | Verifies the claims-vs-evidence detector (missing/failing/stale/fresh states), `experimental.text.complete` journaling, and `tool.definition` enrichment idempotence. |
 | **Compaction & TUI Feedback** | Verifies active task injection in `experimental.session.compacting`, the static TUI badge, guard block warning toasts, and clean error propagation. |
 | **Runtime Instance Isolation** | Verifies concurrent plugin instances keep workspace root and SDK client state isolated via `runWithRuntimeState`. |
+| **V2 Todo Capability** | Verifies the `todowrite` registry probe (`available` / `unavailable` / `unknown`), that an empty history gates only when planning is possible, the once-per-session fail-open warning and audit record, and `todoCapability` in `guard_status`. |
+| **Per-Task Completion Evidence** | Verifies a task cannot move to `completed` without a mutation in its own window, that one mutation cannot vouch for several completions, that staggered windows reject a claim whose window saw no work, that mutations before a task became active never count, that `[read-only]` completes freely and is journaled, that the marker can be appended to an already-planned task without tripping the no-silent-deletion rule, that duplicate content cannot hide a new completion, and that `guard_why` reports the same verdict while moving no window. |
+| **Static Policy Posture** | Verifies the emitted posture is deny-only, emits both host envelopes (`experimental.policies`/`permission` for 2.0.x, top-level `policies`/`tool.use` for 2.1.x), requires both to reach the same verdict for every probed resource, and matches the intended commands under a replica of the host's whole-string glob matcher, including the compound-command evasion it does not cover. |
 | **Modular Exports & Shape** | Verifies V1 `PluginModule` `{ id, server }` structure, modular policy imports, and `output.args` hook contract. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-workflow-guard",
-  "version": "1.15.5",
+  "version": "1.16.0",
   "description": "Deterministic workflow and safety policy enforcement for OpenCode",
   "license": "MIT",
   "type": "module",
@@ -36,6 +36,9 @@
     "guard",
     "workflow"
   ],
+  "engines": {
+    "node": ">=22.18"
+  },
   "scripts": {
     "test": "node test/run-test.mjs",
     "test:install": "node test/test-e2e.mts",
@@ -47,15 +50,19 @@
     "prepublishOnly": "npm run typecheck"
   },
   "dependencies": {
-    "@opencode-ai/plugin": "latest",
-    "@opencode/plugin": "latest",
-    "@opentui/solid": "latest",
-    "jsonc-parser": "latest",
-    "@opencode/ai": "latest"
+    "@opencode-ai/plugin": "1.18.32",
+    "@opencode/plugin": "2.1.3",
+    "@opentui/solid": "0.6.6",
+    "jsonc-parser": "3.3.1",
+    "@opencode/ai": "2.1.3"
   },
   "devDependencies": {
-    "@changesets/cli": "latest",
-    "@types/node": "latest",
-    "typescript": "latest"
+    "@changesets/cli": "3.0.3",
+    "@types/node": "26.6.2",
+    "typescript": "7.0.2"
+  },
+  "overrides": {
+    "solid-js": "1.9.17",
+    "toml": "5.0.1"
   }
 }