cool-workflow 0.2.4 → 0.2.6

package/docs/release-tooling.7.md

@@ -169,6 +169,14 @@ LLM step (the reviewer) is **delegated** through CW's agent backend, so whicheve
 model you set up does the review. CW starts the agent argv-style (`shell:false`),
 takes on the agent's own credentials, and pulls in no model SDK — the red line.
 
+The control plane runs the deterministic gate once. It keeps a failed child
+command's short tail on stderr for the operator, but never puts that tail in a
+saved verdict. The reviewer does not run that gate again. It checks judgment
+questions the gate cannot check. A reviewer rejection has exact `REJECTED`,
+`kind: semantic-review`, and numbered facts with repo-relative `file:line`
+places. Other rejection text is invalid reviewer output: the cut stops, no tag
+is made, and it is not a verified code rejection.
+
 ```bash
 # the operator's one-command release (scripts/release-oneclick.js — preflight,
 # gated cut, tag-only push, CI wait, npm confirmation, verdict-record PR):
@@ -320,3 +328,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.2.3
 
 0.2.4
+
+0.2.5
+
+0.2.6

package/docs/routine.7.md

@@ -67,6 +67,28 @@ and fills out the prompt.
 | 0 | Command done |
 | 1 | Error (bad arguments, missing trigger, etc.) |
 
+## EXAMPLES
+
+Long architecture reviews as background routines: use
+`architecture-review-fast` for the foreground user path, then put the full
+`architecture-review` app in line as background work so a deep look-over does
+not get in the way of a back-and-forth session:
+
+```bash
+node scripts/architecture-review-fast.js \
+  --repo /path/to/repo \
+  --question "Is this architecture sound?" \
+  --metrics \
+  --schedule-full
+```
+
+The wrapper makes a one-shot reminder schedule whose `workflowId` is
+`architecture-review`. The schedule prompt carries the foreground fast run id,
+fast report path, and source-context digest/profile, and asks the background
+agent to give back the full review report path and digest. `--metrics` is
+optional and reports foreground time plus agent-spawn and result-cache-hit
+counts for the fast run.
+
 ## SEE ALSO
 
 cw sched — durable run-queue scheduling for workflow runs

package/docs/run-registry-control-plane.7.md

@@ -123,6 +123,11 @@ adds the drive outcome to the result under a `drive` field. The default (no
 gives `drive.status="blocked"` (fail-closed, never a made-up completion); CW
 hands worker execution to your agent and never runs a model itself.
 
+Human output with `--drive` or `--once` prints the drive status, worker counts,
+each drive step, and the terminal commit id when there is one. This makes a
+blocked or failed drive clear without `--json`. Bare `run resume` keeps its old
+text as it is.
+
 ## Queue
 
 `queue add` adds a durable entry to the end of `$CW_HOME/registry/queue.json` with an
@@ -177,6 +182,15 @@ whose top-level integrity block is *absent* — closing the legacy fail-open sea
 where a stripped-integrity archive imported unverified. Unset (the default) keeps
 legacy integrity-less archives byte-identical; the flag is mechanism, not policy.
 
+An operator can also set `CW_MAX_RUN_ARCHIVE_BYTES`,
+`CW_MAX_RUN_ARCHIVE_FILES`, or `CW_MAX_RUN_ARCHIVE_CONTENT_BYTES`. Each value
+has to be a positive safe integer. The first sets a raw file byte limit before
+the archive is read. The second sets a normalized file row limit. The last sets
+the total decoded content byte limit, checked from declared sizes before decode
+and again while content is decoded. A bad setting or over-limit archive stops
+before a run directory is made. With all three unset, import, inspect, restore,
+and offline bundle check keep their present behavior.
+
 The archive's run id becomes a directory name under `DIR/.cw/runs/`, so import
 also refuses any run id that is not a single safe path segment (`[A-Za-z0-9._-]`,
 with no separator and not the `.` or `..` component) and asserts the resolved run
@@ -216,11 +230,20 @@ before importing a bad archive. It is a true preview of import: under
 turn away) also inspects as `ok:false`; with the env unset (default) an absent integrity
 block is only reported, not failed.
 
+The file table is checked before any write. Every row needs a known role, a
+safe size, a sha256 value, and a relative path. Paths are made portable and
+then have to be unique. `state.json`, `import-manifest.json`, and lock files
+are made by the restore work and are not accepted from an archive. A bad row
+or two rows with the same path make inspect, import, and restore fail closed.
+No run directory is made for that input.
+
 **Restore in one fail-closed step.** `run restore PATH --target DIR [--json]`
-does the whole move-a-run-to-another-machine flow as ONE atomic, fail-closed
-step: it integrity-**inspects** the bundle first (writing nothing), **imports**
-it, then reuses the verification `import` already ran — and reports `ok:true`
-ONLY when that verify passes. This closes a real gap: `run import` runs a
+does the whole move-a-run-to-another-machine flow as one atomic, fail-closed
+step. It integrity-**inspects** the bundle first, imports it into a same-disk
+staging tree, and checks the file, telemetry, trust-audit, and run-state records there.
+Only then does it put final paths into state and publish the run with one
+directory rename. It reports `ok:true` only after a check of the published
+tree. This closes a real gap: `run import` runs a
 verification (it re-proves restored file digests, the **telemetry ledger**, and
 the **trust-audit hash chain**) and reports it, but does NOT fail on it — it
 exits `0` even when that chain does not verify. So a run whose telemetry or
@@ -229,13 +252,14 @@ made-up success. `run restore` refuses exactly that: it fails closed on the same
 verification `import` only reports. A bundle that fails the up-front integrity
 inspect is refused **before any import**, so nothing is written and the run is
 never left part-restored; the result carries `imported:null` and `verify:null`.
-A bundle that imports but fails post-import verification is reported with
-`ok:false` too. It exits `1` whenever `ok:false`, so `cw run restore <path>` is a
+A bundle that imports in staging but fails a chain check is reported with
+`ok:false`, `imported:null`, and no final run. A final run with the same id is
+never merged or replaced. A staging write fault is cleaned up. It exits `1`
+whenever `ok:false`, so `cw run restore <path>` is a
 single command that either lands a fully-proven run or refuses with a non-zero
-exit — never a made-up success. The result is structured
+exit — never a made-up success or a half-written final run. The result is structured
 (`{ schemaVersion, ok, target, inspect, imported, verify, registry }`) so it is
-scriptable. `run import` and `run inspect-archive` are unchanged; restore is a
-thin composition of `inspectArchive` + `importRun` (reusing its verification).
+scriptable. `run import` and `run inspect-archive` are unchanged.
 
 MCP gives the same mechanisms as `cw_run_export`, `cw_run_import`,
 `cw_run_verify_import`, `cw_run_inspect_archive`, and `cw_run_restore`; the CLI
@@ -482,3 +506,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.2.3
 
 0.2.4
+
+0.2.5
+
+0.2.6

package/docs/run-retention-reclamation.7.md

@@ -109,16 +109,20 @@ node points to a freed path. Opt out with `--keep-scratch`.
 
 ## Commit snapshots — never reconstructable, always downgrades to verify-only
 
-`commitState` embeds the FULL run into `commits/<id>.json` on every commit, so
-these grow unbounded in both count and per-file size with no cap. Reclaiming them
+`commitState` writes only the commit's own (small, bounded) record into
+`commits/<id>.json` on every commit — it no longer embeds the whole run, so
+these files stay small and do not grow with the run's size. Reclaiming them
 frees the run's superseded, non-`verifierGated` "checkpoint" commit snapshots —
 the run's LATEST commit and every `verifierGated` commit (the actual
 audit-significant milestones) are always kept. `run.commits`' own lightweight
 metadata (id, `verifierGated`, evidence digests, acceptance rationale — everything
 `extractSkeleton` seals) lives in `state.json`, not the snapshot file, so it stays
-fully intact and queryable regardless. Unlike a node snapshot, a commit snapshot is
-a genuine point-in-time capture with no `ReconstructionRecipe` — reclaiming even
+fully intact and queryable regardless. A commit snapshot is treated as never
+reconstructable — there is no `ReconstructionRecipe` for it — so reclaiming even
 one downgrades capability to `verify-only`, never `re-runnable-by-reconstruction`.
+This is left conservative on purpose: even though the snapshot file's content is
+now a strict subset of what `state.json` already keeps durably, the reclaim
+classification does not (yet) treat that as a basis for reconstruction.
 Each reclaimed commit's own `StateNode` had its `snapshot` artifact stripped (not
 re-pointed — there is no retained alternative) before the free, so `prepareFree`'s
 dangling-reference proof covers this kind too. Opt out with `--keep-commits`.
@@ -288,3 +292,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.2.3
 
 0.2.4
+
+0.2.5
+
+0.2.6

package/docs/state-explosion-management.7.md

@@ -328,3 +328,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.2.3
 
 0.2.4
+
+0.2.5
+
+0.2.6

package/docs/team-collaboration.7.md

@@ -264,3 +264,7 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.2.3
 
 0.2.4
+
+0.2.5
+
+0.2.6

package/docs/trust-audit-anchor.7.md

@@ -71,3 +71,7 @@ security-trust-hardening(7), cli-mcp-parity(7), report-verifiable-bundle(7)
 0.2.3
 
 0.2.4
+
+0.2.5
+
+0.2.6

package/docs/web-desktop-workbench.7.md

@@ -10,6 +10,28 @@ speed and the MCP server (JSON-RPC over stdio) showed things for machine context
 Workbench lets a person look at a run quickly — and adds NOTHING else. It works out,
 decides, and keeps nothing that the CLI/MCP cannot already make.
 
+## Simple UI rules
+
+The Workbench follows three public sets of rules:
+
+- FreeBSD [style(9)](https://man.freebsd.org/cgi/man.cgi?query=style&sektion=9)
+  says that usage text has to agree with the man page and that error text has
+  to be easy to find. CW keeps command words and error words clear and fixed.
+- FreeBSD [hier(7)](https://man.freebsd.org/cgi/man.cgi?query=hier&sektion=7)
+  gives each sort of file one place. The Workbench keeps no state; `.cw/`
+  stays the one state source.
+- Homebrew [brew(1)](https://docs.brew.sh/Manpage) puts its essential commands
+  before its full command list, and gives `help`, `doctor`, `info`, and
+  `search`. CW gives one clear next command in place of a hidden recovery
+  action. Homebrew [External Commands](https://docs.brew.sh/External-Commands)
+  also shows how a front door may be added without a change to the tool's
+  inside parts. The Workbench stays a view over present CW capabilities.
+- Codex [Best practices](https://learn.chatgpt.com/guides/best-practices.md)
+  puts context, checks, and review in the work path. Its
+  [app commands](https://learn.chatgpt.com/docs/reference/commands.md) keep
+  search, key movement, and Back/Forward movement close at hand. The
+  Workbench keeps the run and panel in the page address for the same reason.
+
 ## The third front door (mechanism vs policy)
 
 The kernel and the durable `.cw/` state are the MECHANISM. The CLI, the MCP
@@ -85,6 +107,7 @@ The host has least privilege and is local by default:
 
 - it binds the loopback interface `127.0.0.1` ONLY — never a public address
 - it is READ-ONLY: every route is `GET`; any write verb is turned away with `405`
+- a read view makes no audit, metrics, or other derived file under `.cw/`
 - it turns away non-localhost `Host` headers (a DNS-rebinding defense) with `403`
 - it turns away path traversal out of `ui/workbench/` with `403`
 - it serves nothing past the current user's `.cw/` scope and the Run Registry's
@@ -97,9 +120,16 @@ capability core entry that already exists — never a side code path — so it c
 CLI/MCP and is covered by the parity gate.
 
 Authentication is opt-in, not on by default: set `CW_WORKBENCH_TOKEN` and every
-request must carry it as `Authorization: Bearer <token>` or `?token=<token>`
+`/api/*` request must carry it as `Authorization: Bearer <token>` or `?token=<token>`
 (timing-safe compare); left unset, the loopback/read-only/GET-only controls
-above are the only defense and any local process can read. Pass
+above are the only defense and any local process can read. The static UI files
+(`/ui/*`, and `/` when the UI is installed) are served without the token: they
+are fixed code with no run data, and the browser needs them before the page can
+say anything at all. The fallback `/` page (used when the UI is not installed)
+stays behind the token, because it holds the serve descriptor with the repo
+root path. Open the page as `/?token=<token>`: the UI reads the token from the
+page address and adds it to every `/api/*` request; without it the page still
+loads and tells you to reopen it with the token. Pass
 `--require-token` to `cw workbench serve` to fail closed instead: the server
 refuses to start at all unless `CW_WORKBENCH_TOKEN` is already set. This is a
 strict opt-in — leaving it off keeps today's default behavior unchanged.
@@ -113,6 +143,29 @@ cw workbench view <run-id> [--json]         # five-panel WorkbenchRunView for on
 cw workbench serve [--port N] [--scope repo|home] [--once|--json] [--require-token]
 ```
 
+The page address may name one run and one panel:
+
+```text
+#run=<encoded-run-id>&tab=<graph|blackboard|worker|candidate|audit|metrics|collaboration>
+```
+
+The `run` value is needed for a run view. With no `tab`, the page uses
+`graph`. A bad tab name is changed to `graph`. Back, Forward, and page reload
+keep the named view. The Workbench token stays in the page query and is never
+put in this fragment.
+
+The run list and panels work with a keyboard. Left and Right move through the
+panel tabs; Home and End go to the first and last tab. The active tab and its
+panel are joined with the standard ARIA tab and tabpanel links.
+
+When a present panel payload has an `integrity`, `problems`,
+`missingEvidence`, `nextAction`, or `nextActions` fact, the page puts a small
+`What matters` block before the full panel record. It copies only source
+values. It does not make a new state, rank, or action. An empty problem or
+missing-evidence list is shown as `none`. A field with a shape the page does
+not know is left out of the block. The full structured view or JSON stays
+under the block.
+
 `cw workbench serve` with `--once`/`--json` prints the serve descriptor (bind
 host/port, scope, routes) and stops without starting a server; the default starts
 the localhost host (like `schedule daemon`). The MCP tools `cw_workbench_view` and
@@ -282,3 +335,20 @@ _No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes on
 0.2.3
 
 0.2.4
+
+## Workbench UI/host round 2 (Unreleased)
+
+- With `CW_WORKBENCH_TOKEN` set, the page now works: the static UI files are
+  open, and every `/api/*` request stays behind the token (see "Trust
+  boundary" above). The UI reads `?token=` from the page address, and a 401
+  answer tells you to reopen the page with the token.
+- `cw workbench view --json` (and `/api/run/:runId`) gains a `lifecycle` key:
+  the run registry's own state for the run
+  (queued|running|blocked|completed|failed|archived|reclaimed). The key is
+  left out when the run cannot be classified, so those payloads keep their
+  old bytes. The UI shows it as a badge in the run header, with one
+  next-step line when a run is blocked or failed.
+
+0.2.5
+
+0.2.6

package/docs/workflow-app-framework.7.md

@@ -32,6 +32,37 @@ runner owns state transitions, dispatch, result recording, verifier gates,
 commits, and reports. A workflow app owns its own inputs, phases, task
 prompts, evidence needs, and sandbox profile hints.
 
+Every CW workflow keeps to one loop, and the loop maps to real framework
+operations:
+
+| Loop stage | framework operation | Responsibility |
+| --- | --- | --- |
+| Interpret | `plan()` | Load workflow, check inputs, make tasks |
+| Act | `dispatch()` | Move tasks that can run from pending to running |
+| Observe | `recordResult()` | Read Markdown/JSON-RPC result evidence |
+| Adjust | verifier gates | Check evidence and pick the next phase |
+| Checkpoint | `commitState()` | Take a snapshot of state after important changes |
+
+The language split is on purpose: the platform is TypeScript
+(`src/*.ts -> dist/*.js`, strongly typed so it is simple to keep up), while
+workflow apps are plain JavaScript modules (`apps/<app-id>/workflow.js`,
+legacy `workflows/*.workflow.js`) so workflow scripts run without `ts-node`.
+
+Verification and verdict tasks give back a `cw:result` JSON fence:
+
+````text
+```cw:result
+{
+  "summary": "short summary",
+  "findings": [],
+  "evidence": ["/absolute/path/file.ts:42"]
+}
+```
+````
+
+CW says no to high-priority findings without evidence. This keeps agent work
+nearer to engineering output you can look into than to free talk.
+
 The framework is kept small on purpose. The public app helpers are:
 
 - `defineWorkflowApp(definition)`

package/manifest/plugin.manifest.json

@@ -2,7 +2,7 @@
   "_comment": "SINGLE SOURCE OF TRUTH for every vendor manifest. Edit THIS file, then run `npm run gen:manifests`. Do NOT hand-edit the generated vendor manifests (.claude-plugin/, .codex-plugin/, .agents/, .mcp.json) — `npm run gen:manifests -- --check` (run by release:check) will fail if they drift from this source.",
   "identity": {
     "name": "cool-workflow",
-    "version": "0.2.4",
+    "version": "0.2.6",
     "license": "BSD-2-Clause",
     "homepage": "https://github.com/coo1white/cool-workflow",
     "author": {

package/manifest/source-context-profiles.json

@@ -3,7 +3,7 @@
   "profiles": {
     "core": {
       "description": "Default AI source context: runtime source, apps, package metadata, and agent wrappers; generated artifacts, tests, docs, release records, and long logs are manifest-only.",
-      "maxLines": 50000,
+      "maxLines": 52000,
       "include": [
         "plugins/cool-workflow/src/**",
         "plugins/cool-workflow/apps/**",
@@ -25,7 +25,7 @@
     },
     "runtime": {
       "description": "Runtime-kernel source context for state, orchestration, scheduling, execution, and shared types.",
-      "maxLines": 48000,
+      "maxLines": 49000,
       "include": [
         "plugins/cool-workflow/src/**",
         "plugins/cool-workflow/package.json",
@@ -95,7 +95,8 @@
       "include": [
         "AGENTS.md",
         "plugins/cool-workflow/scripts/release-flow.js",
-        "plugins/cool-workflow/scripts/release-gate.sh",
+        "plugins/cool-workflow/scripts/release-gate.js",
+        "plugins/cool-workflow/scripts/release-tags.js",
         "plugins/cool-workflow/scripts/dogfood-release.js",
         "plugins/cool-workflow/scripts/gen-manifests.js",
         "plugins/cool-workflow/scripts/version-sync-check.js",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cool-workflow",
-  "version": "0.2.4",
+  "version": "0.2.6",
   "bin": {
     "cool-workflow": "scripts/cw.js",
     "cw": "scripts/cw.js"
@@ -26,6 +26,8 @@
   "files": [
     ".claude-plugin/",
     ".codex-plugin/",
+    ".gemini-plugin/",
+    ".opencode-plugin/",
     ".mcp.json",
     "manifest/",
     "README.md",
@@ -44,6 +46,7 @@
     "check": "tsc -p tsconfig.json --noEmit",
     "dist:check": "node scripts/dist-drift-check.js",
     "purity:check": "node scripts/purity-gate.js",
+    "lang:check": "node scripts/lang-policy-check.js",
     "golden-path": "node scripts/golden-path.js",
     "dogfood:release": "node scripts/dogfood-release.js",
     "canonical-apps": "node scripts/canonical-apps.js",
@@ -55,7 +58,6 @@
     "bump:version": "node scripts/bump-version.js",
     "new:feature": "node scripts/new-feature.js",
     "forward-ref": "node scripts/forward-ref-docs.js",
-    "verify:container": "node scripts/verify-container-selfref.js",
     "gen:manifests": "node scripts/gen-manifests.js",
     "gen:parity": "node scripts/gen-parity-doc.js",
     "manifest:load-check": "node test/vendor-manifest-load-smoke.js",
@@ -73,7 +75,8 @@
     "test:unit": "node dist/cli.js version > /dev/null && node test/run-unit.js",
     "eval:replay": "tsc -p tsconfig.json && node test/multi-agent-eval-replay-harness-smoke.js",
     "ci": "npm run build && npm run check && npm run test && npm run release:check",
-    "validate:schema": "node scripts/validate-run-state-schema.js"
+    "validate:schema": "node scripts/validate-run-state-schema.js",
+    "bench:workbench:deep": "node ../../scripts/bench/workbench-load.js"
   },
   "devDependencies": {
     "@types/node": "^26.1.1",

package/scripts/agents/agent-adapter-core.js

@@ -490,8 +490,34 @@ function buildFailureDetail({ label, code, childStderr, partialText }) {
   return codeText;
 }
 
+// CW may set CW_AGENT_VENDOR_PIDFILE when it runs a shipped wrapper. We write
+// the vendor child's PID there so CW can reap the vendor if it has to SIGKILL
+// this wrapper on a timeout: a SIGKILL is uncatchable, so the wrapper cannot
+// forward the stop to its vendor child itself, and the vendor would otherwise
+// live on as an orphan and keep spending (see execution-backend/agent.ts). The
+// file is removed as soon as the vendor exits, so a stale PID is never reaped.
+// Best-effort: fs errors are ignored -- reaping is a safety net, not a
+// correctness dependency -- and an arbitrary CW_AGENT_COMMAND that never calls
+// this is simply not covered.
+function recordVendorPid(child, env = process.env) {
+  const pidfile = env.CW_AGENT_VENDOR_PIDFILE;
+  if (!pidfile || !child || !child.pid) return child;
+  try { fs.writeFileSync(pidfile, String(child.pid), "utf8"); } catch { /* best-effort */ }
+  let cleared = false;
+  const clear = () => {
+    if (cleared) return;
+    cleared = true;
+    try { fs.unlinkSync(pidfile); } catch { /* already gone */ }
+  };
+  child.once("close", clear);
+  child.once("exit", clear);
+  process.once("exit", clear);
+  return child;
+}
+
 module.exports = {
   RESULT_CONTRACT,
+  recordVendorPid, // write the vendor child's PID to CW_AGENT_VENDOR_PIDFILE so cw can reap it on a timeout
   buildPrompt,
   streamEnabled,
   traceEnabled,

package/scripts/agents/claude-p-agent.js

@@ -34,7 +34,7 @@ const { spawn, spawnSync } = require("node:child_process");
 // wrappers instead of carrying a private copy. A drifted inline copy (ASCII
 // hyphens silently became em-dashes here) meant claude was sent a different
 // instruction text than the other providers for the same contract.
-const { buildPrompt, createRenderer, persistStderr, toolLabel, summarizeToolResult, buildFailureDetail } = require("./agent-adapter-core");
+const { buildPrompt, createRenderer, persistStderr, toolLabel, summarizeToolResult, buildFailureDetail, recordVendorPid } = require("./agent-adapter-core");
 
 const inputPath = process.argv[2];
 const resultPath = process.argv[3];
@@ -103,6 +103,9 @@ const child = spawn(
   ["-p", prompt, "--output-format", "stream-json", "--verbose", "--allowedTools", "Read,Grep,Glob"],
   { stdio: ["ignore", "pipe", "pipe"] }
 );
+// Record the vendor PID so cw can reap this claude process if it SIGKILLs the
+// wrapper on a timeout (see agent-adapter-core recordVendorPid).
+recordVendorPid(child);
 
 let model;
 let usage;

package/scripts/agents/codex-agent.js

@@ -43,6 +43,7 @@ const {
   flushJsonLines,
   parseJsonLines,
   persistStderr,
+  recordVendorPid,
   writeResult
 } = require("./agent-adapter-core");
 
@@ -133,6 +134,9 @@ const child = spawn("codex", args, {
   stdio: ["pipe", "pipe", "pipe"],
   shell: false
 });
+// Record the vendor PID so cw can reap this codex process if it SIGKILLs the
+// wrapper on a timeout (see agent-adapter-core recordVendorPid).
+recordVendorPid(child);
 
 child.stdin.setDefaultEncoding("utf8");
 child.stdin.end(prompt);

package/scripts/agents/cw-attest-wrap.js

@@ -20,7 +20,7 @@
 // Point CW at it (from plugins/cool-workflow/), keeping your inner agent intact:
 //   CW_AGENT_ATTEST_PRIVKEY=$PWD/cw-attest.key \
 //   CW_AGENT_COMMAND="node $PWD/scripts/agents/cw-attest-wrap.js --manifest {{manifest}} -- \
-//     bash $PWD/scripts/agents/claude-p-agent.sh {{input}} {{result}}"
+//     node $PWD/scripts/agents/claude-p-agent.js {{input}} {{result}}"
 // and configure CW's verify side: CW_AGENT_ATTEST_PUBKEY=$PWD/cw-attest.pub
 //
 // Honest posture: if no private key is set, or the agent reports no usage, the

package/scripts/agents/gemini-agent.js

@@ -24,6 +24,7 @@ const {
   flushJsonLines,
   parseJsonLines,
   persistStderr,
+  recordVendorPid,
   writeResult
 } = require("./agent-adapter-core");
 
@@ -71,6 +72,9 @@ const child = spawn("gemini", args, {
   stdio: ["ignore", "pipe", "pipe"],
   shell: false
 });
+// Record the vendor PID so cw can reap this gemini process if it SIGKILLs the
+// wrapper on a timeout (see agent-adapter-core recordVendorPid).
+recordVendorPid(child);
 
 child.stdout.setEncoding("utf8");
 child.stdout.on("data", (chunk) => {

package/scripts/agents/opencode-agent.js

@@ -29,6 +29,7 @@ const {
   flushJsonLines,
   parseJsonLines,
   persistStderr,
+  recordVendorPid,
   writeResult
 } = require("./agent-adapter-core");
 
@@ -124,6 +125,10 @@ const child = spawn("opencode", args, {
   stdio: ["ignore", "pipe", "pipe"],
   shell: false
 });
+// Record the vendor PID so cw can reap this opencode process (also used by the
+// deepseek wrapper, which re-exports this file) if it SIGKILLs the wrapper on a
+// timeout (see agent-adapter-core recordVendorPid).
+recordVendorPid(child);
 
 child.stdout.setEncoding("utf8");
 child.stdout.on("data", (chunk) => {