@kurrent/kcap 0.9.5 → 0.10.0

package/bin/kcap.js

@@ -48,6 +48,157 @@ function probeArgs(updArgs) {
   return ["update", "--check", "--no-update-check", ...channelFlags];
 }
 
+// ── Windows binary-lock handling ────────────────────────────────────────────
+//
+// Windows locks an executing image against overwrite/delete for the process
+// lifetime, and kcap has long-lived native processes: MCP servers (four per
+// open Claude Code session) and the daemon. A plain `npm install -g` therefore
+// dies with EBUSY whenever any agent session is open. But Windows DOES allow
+// renaming/moving a running image within a volume — so `kcap update` moves the
+// exes into a trash directory first (rename-aside), lets npm lay down fresh
+// files at the real path, and sweeps the trash on later launcher runs once the
+// old processes have exited. Running processes keep executing the moved image
+// untouched and pick up the new binary on their next start.
+
+const TRASH_DIR_NAME = ".kcap-trash";
+
+// Trash lives next to node_modules (e.g. %APPDATA%\npm\.kcap-trash): renaming
+// a running image requires the destination to be on the same volume, and a
+// sibling of the install tree guarantees that.
+function trashDirFor(globalRoot) {
+  return path.join(globalRoot, "..", TRASH_DIR_NAME);
+}
+
+// Trash dir as seen from this launcher file, without shelling out to
+// `npm root -g` (too slow for the hook hot path). Returns null when the
+// launcher isn't laid out as a node_modules install.
+function trashDirFromLauncher(launcherDir) {
+  // <root>\node_modules\@kurrent\kcap\bin → <root>\.kcap-trash
+  const nodeModules = path.resolve(launcherDir, "..", "..", "..");
+  if (path.basename(nodeModules) !== "node_modules") return null;
+  return path.join(path.dirname(nodeModules), TRASH_DIR_NAME);
+}
+
+// Best-effort reclaim of exes parked by earlier updates. Deleting a file whose
+// process is still running fails; it just stays for a later sweep.
+function sweepTrash(trashDir) {
+  if (!trashDir) return;
+  let entries;
+  try { entries = fs.readdirSync(trashDir); } catch { return; }
+  for (const f of entries) {
+    try { fs.unlinkSync(path.join(trashDir, f)); } catch {}
+  }
+}
+
+// Move the native exes out of the install tree so npm can replace them.
+// Returns the performed moves so a failed install can restore them. Throws if
+// even a rename is refused (something holds the file exclusively) — after
+// first undoing any move it already made, so a partial failure never leaves
+// the install half-emptied.
+function renameAsideBinaries(binDir, trashDir) {
+  const moved = [];
+  for (const name of ["kcap.exe", "kcap-daemon.exe"]) {
+    const src = path.join(binDir, name);
+    if (!fs.existsSync(src)) continue;
+    try {
+      fs.mkdirSync(trashDir, { recursive: true });
+      const dest = path.join(trashDir, `${name}.${process.pid}.${Date.now()}`);
+      fs.renameSync(src, dest);
+      moved.push({ from: src, to: dest });
+    } catch (e) {
+      restoreMoved(moved);
+      throw e;
+    }
+  }
+  return moved;
+}
+
+// Undo rename-aside after a failed install, so the user isn't left without a
+// binary. Skips any path npm already managed to replace.
+function restoreMoved(moved) {
+  const failures = [];
+  for (const m of moved) {
+    try {
+      if (!fs.existsSync(m.from)) fs.renameSync(m.to, m.from);
+    } catch (e) {
+      failures.push({ ...m, error: e });
+    }
+  }
+
+  if (failures.length) {
+    console.error("Could not restore one or more kcap binaries after a failed update:");
+    for (const f of failures) {
+      console.error(`  ${f.to} -> ${f.from}: ${f.error.message}`);
+    }
+    console.error("You may need to move the files back manually from the .kcap-trash directory.");
+  }
+
+  return failures;
+}
+
+// Pure helper (unit-tested): shape a Win32_Process JSON payload into the kcap
+// processes running from the given install root. ConvertTo-Json unwraps
+// single-element arrays, so `parsed` may be a bare object.
+function filterKcapProcesses(parsed, installRoot) {
+  const list = Array.isArray(parsed) ? parsed : parsed ? [parsed] : [];
+  const root = installRoot.toLowerCase();
+  return list
+    .filter((p) => p && typeof p.ExecutablePath === "string"
+      && p.ExecutablePath.toLowerCase().startsWith(root))
+    .map((p) => ({
+      pid: p.ProcessId,
+      name: path.basename(p.ExecutablePath),
+      role: describeRole(p.CommandLine || p.ExecutablePath || ""),
+    }));
+}
+
+// Pure helper (unit-tested): human label for what a kcap process is, from its
+// command line. MCP servers are the common locker — one per MCP entry in the
+// kcap Claude Code plugin, so four per open session.
+function describeRole(commandLine) {
+  if (/kcap-daemon/i.test(commandLine)) return "daemon";
+  if (/\bmcp\b/i.test(commandLine)) return "MCP server — open Claude Code/agent session";
+  if (/\bdaemon\b/i.test(commandLine)) return "daemon";
+  return "kcap process";
+}
+
+// Enumerate running kcap processes under the install tree (Windows only).
+// Returns null when enumeration itself fails, so callers can degrade to a
+// generic message.
+function listKcapProcesses(installRoot) {
+  try {
+    const script =
+      "Get-CimInstance Win32_Process -Filter \"Name='kcap.exe' OR Name='kcap-daemon.exe'\" | " +
+      "Select-Object ProcessId,ExecutablePath,CommandLine | ConvertTo-Json -Compress";
+    const out = execFileSync("powershell.exe",
+      ["-NoProfile", "-NonInteractive", "-Command", script],
+      { encoding: "utf8", windowsHide: true });
+    return filterKcapProcesses(out.trim() ? JSON.parse(out) : [], installRoot);
+  } catch {
+    return null;
+  }
+}
+
+// Actionable diagnosis for a locked binary: name the processes holding it and
+// say what to do, instead of leaving the user with npm's raw EBUSY. With
+// `onlyIfFound` (the npm-failure path, where the cause may be unrelated —
+// network, registry) it stays silent unless lockers are actually found.
+function printLockedBinaryHelp(globalRoot, onlyIfFound = false) {
+  const procs = listKcapProcesses(path.join(globalRoot, "@kurrent"));
+  if (procs && procs.length) {
+    console.error("The kcap binary is locked by running kcap processes:");
+    for (const p of procs) {
+      console.error(`  PID ${String(p.pid).padEnd(6)} ${p.name}  (${p.role})`);
+    }
+    console.error("MCP servers belong to open Claude Code / agent sessions. Close those");
+    console.error("sessions (and stop the daemon, if running), then re-run `kcap update`.");
+  } else if (!onlyIfFound) {
+    console.error("The kcap binary appears to be locked by a running process (open");
+    console.error("Claude Code sessions run kcap MCP servers; the daemon also counts).");
+    console.error("Close agent sessions and stop the daemon, then re-run `kcap update`.");
+  }
+}
+
 // Everything below actually DOES something (resolves the binary, execs it,
 // runs the update flow), so it's guarded to only run when this file is
 // executed directly — not when `require()`d (e.g. by the test).
@@ -87,11 +238,18 @@ if (require.main === module) {
     try { fs.chmodSync(binaryPath, 0o755); } catch {}
   }
 
+  // Reclaim exes parked by a previous rename-aside update, now that their
+  // processes may have exited. Cheap when there's nothing to do (one stat).
+  if (process.platform === "win32") {
+    sweepTrash(trashDirFromLauncher(__dirname));
+  }
+
   // `kcap update` for npm-global installs is driven HERE, in the Node launcher,
   // not by the native binary. The OS locks an executable image for the whole
-  // process lifetime but a script only during load — so by driving the upgrade
-  // from this script (with the native binary not running) npm can overwrite the
-  // binary even on Windows, with no temp-file/rename/detached-helper dance.
+  // process lifetime but a script only during load — so with the short-lived
+  // probe exited, npm can overwrite the binary in place on macOS/Linux; on
+  // Windows the long-lived MCP/daemon processes are handled by rename-aside
+  // (see the binary-lock section above).
   // `--check` (JSON probe) and `--help` fall through to the native binary.
   {
     const updArgs   = process.argv.slice(3);
@@ -132,10 +290,12 @@ function runUpdate(binaryPath, updArgs) {
     globalRoot = execFileSync("npm", ["root", "-g"], { encoding: "utf8", ...npmOpts }).trim();
   } catch {}
 
+  let realGlobalRoot = null;
   let isGlobalNpm = false;
   try {
     if (globalRoot) {
-      const root = fs.realpathSync(globalRoot) + path.sep;
+      realGlobalRoot = fs.realpathSync(globalRoot);
+      const root = realGlobalRoot + path.sep;
       isGlobalNpm = fs.realpathSync(__filename).startsWith(root);
     }
   } catch {}
@@ -174,28 +334,21 @@ function runUpdate(binaryPath, updArgs) {
     // Couldn't determine — fall through and let npm decide (it's idempotent).
   }
 
-  // Windows preflight: a running kcap-daemon.exe locks the binary, so `npm install`
-  // would FAIL to overwrite it. Detect a running daemon and abort with instructions
-  // BEFORE attempting the (doomed) install. macOS/Linux can replace the file in place,
-  // so this guard is Windows-only.
-  if (process.platform === "win32") {
-    try {
-      const status = execFileSync(binaryPath, ["daemon", "status"], { encoding: "utf8" });
-      if (/running \(PID/i.test(status)) {
-        console.error("A kcap daemon is running and locks the binary, so the update can't");
-        console.error("replace it. Stop it first, then re-run `kcap update`:");
-        console.error("  kcap daemon service stop   (if installed as a service)");
-        console.error("  kcap daemon stop           (otherwise)");
-        process.exit(1);
-      }
-    } catch {
-      // status probe failed (no daemon / old binary) — fall through to the normal install.
-    }
+  // Detect a running daemon up front (short-lived child; it exits before npm
+  // runs). Used only for the post-update notice — the update itself no longer
+  // needs the daemon stopped on any platform. `--no-update-check` keeps this
+  // child's "update available" nudge from landing mid-update.
+  let daemonRunning = false;
+  try {
+    const status = execFileSync(binaryPath, ["daemon", "status", "--no-update-check"], { encoding: "utf8" });
+    daemonRunning = /running \(PID/i.test(status);
+  } catch {
+    // status probe failed (no daemon / old binary) — treat as not running.
   }
 
   // Fail clearly instead of half-installing under a root-owned prefix.
   try {
-    fs.accessSync(globalRoot, fs.constants.W_OK);
+    fs.accessSync(realGlobalRoot, fs.constants.W_OK);
   } catch {
     console.error(`Cannot write to the global npm directory (${globalRoot}).`);
     console.error("Re-run with the permissions you installed kcap with, or reinstall");
@@ -203,13 +356,31 @@ function runUpdate(binaryPath, updArgs) {
     process.exit(1);
   }
 
+  // Windows: move the (possibly executing) exes out of npm's way. See the
+  // binary-lock section above for why rename works when overwrite doesn't.
+  let moved = [];
+  if (process.platform === "win32") {
+    try {
+      moved = renameAsideBinaries(path.dirname(binaryPath), trashDirFor(realGlobalRoot));
+    } catch (e) {
+      // Even a rename was refused — something holds the file exclusively
+      // (AV scan, exclusive open). renameAsideBinaries already rolled back its
+      // partial moves; diagnose instead of letting npm EBUSY.
+      console.error(`Could not move the current kcap binary aside: ${e.message}`);
+      printLockedBinaryHelp(realGlobalRoot);
+      process.exit(1);
+    }
+  }
+
   const res = spawnSync("npm", ["install", "-g", resolveInstallSpec(info)], {
     stdio: "inherit",
     windowsHide: true,
     ...npmOpts,
   });
   if (res.status !== 0) {
+    restoreMoved(moved);
     console.error("npm install failed; kcap was not updated.");
+    if (process.platform === "win32") printLockedBinaryHelp(realGlobalRoot, /* onlyIfFound */ true);
     process.exit(res.status == null ? 1 : res.status);
   }
 
@@ -219,23 +390,30 @@ function runUpdate(binaryPath, updArgs) {
   require("./refresh").runRefreshes(fs.realpathSync(__filename));
   console.log("kcap updated.");
 
-  // macOS/Linux: a running daemon self-detects the new binary and restarts when idle.
-  // Just inform the user (best-effort; never fail the update for this). On Windows the
-  // doomed install was already aborted by the preflight above, so this only runs on Unix.
-  if (process.platform !== "win32") {
-    try {
-      const status = execFileSync(binaryPath, ["daemon", "status"], { encoding: "utf8" });
-      if (/running \(PID/i.test(status)) {
-        console.log("A kcap daemon is running; it will restart automatically when idle to");
-        console.log("pick up the new version. Check with `kcap daemon status`, or apply now");
-        console.log("with `kcap daemon restart --force`.");
-      }
-    } catch {
-      // best-effort notice only
+  // A running daemon keeps executing the old image until restarted. On
+  // macOS/Linux it self-detects the new binary and restarts when idle; on
+  // Windows self-detection is off (the running image was moved, not replaced),
+  // so the user applies it explicitly.
+  if (daemonRunning) {
+    if (process.platform === "win32") {
+      console.log("A kcap daemon is running and still uses the old version. Apply the");
+      console.log("update with `kcap daemon restart` (add --force if agents are running).");
+    } else {
+      console.log("A kcap daemon is running; it will restart automatically when idle to");
+      console.log("pick up the new version. Check with `kcap daemon status`, or apply now");
+      console.log("with `kcap daemon restart --force`.");
     }
   }
 
   process.exit(0);
 }
 
-module.exports = { resolveInstallSpec, probeArgs };
+module.exports = {
+  resolveInstallSpec,
+  probeArgs,
+  trashDirFor,
+  trashDirFromLauncher,
+  filterKcapProcesses,
+  describeRole,
+  restoreMoved,
+};

package/kcap/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "kcap",
-  "version": "0.9.5",
+  "version": "0.10.0",
   "description": "Records and visualizes Claude Code sessions via kcap CLI hooks"
 }

package/kcap/skills/agent-flows/SKILL.md

@@ -50,25 +50,31 @@ If `start_flow` / `send_to_participant` are not among the tools available in thi
 4. **Only call `close_flow` after the clean signal.** The run stays open until you explicitly close it — don't rely on it closing itself. Then report completion to the user.
 5. **If participant output is unclear or requires user input**, pause and ask the user before proceeding.
 6. **Never start a nested flow.** If you are the hosted participant (see above), do not call these tools yourself.
-7. **Single participant.** In Phase D every flow definition has exactly one participant, `reviewer`. `send_to_participant` with any other `participant` value is rejected by the server, which names the valid participant in its error.
+7. **Address each role independently.** A flow definition declares one or more participant roles in its `participants` map (single-participant definitions use `reviewer`). A multi-participant `start_flow` returns no round — nothing has launched yet. Call `send_to_participant(flow_run_id, participant=<role>, message=…)` naming the role you want to address; its first message launches that role's agent lazily. Only one round is in flight per role at a time — sending to a role that's still working on a round gets a `409` naming the busy round — but every OTHER role stays addressable in the meantime. Sending an unknown role is rejected by the server, which names the valid roles in its error.
 8. **For a code review flow (`definition_id: "code-review"`), do NOT ask the participant to run tests.** CI covers test execution; participant feedback is on correctness, design, and adherence to conventions.
 9. **State where your changes live.** The participant's worktree is mirrored from the working tree you LAUNCHED from (your cwd's git root) — nothing else. If any part of the changeset lives elsewhere (another git worktree, another repository, a different machine) or is not in that tree, say so explicitly in `context`/`message` and inline the relevant diffs or file contents — or pass `mode: "context-only"` so the participant treats your context as the sole source of truth. The participant is instructed to flag referenced changes it cannot find in its worktree; incomplete context wastes a full round.
 
+## Pending messages
+
+Participants can push you out-of-band notes between rounds — observations that don't warrant a full round result (e.g. "found something odd, still looking"). These ride along as `pending_messages` on `start_flow` (a single-participant start returns round 1's result, which can already carry them), `get_flow_status`, `send_to_participant`/`submit_review_round`, and `close_flow` responses, rendered as a list of `from <role> [<id>]: <text>` entries. React to each message **once, by its `<id>`**, the moment you see it. Delivery is acknowledged after rendering, so a message normally never reappears — but if that acknowledgment fails, the SAME message (same id) is redelivered on a later call: treat a repeated id as already handled, never react to it twice. `close_flow`'s response can carry final pending messages too — often the last thing a participant tells you — so read them before you report completion to the user.
+
 ## Guardrail errors
 
 The server enforces per-run budgets; watch for these in tool error responses:
 
 - **`400` containing `max_rounds (N) reached for this run — close the flow.`** — the run is still **open**, it's just hit its round cap. Stop submitting further rounds, summarize what you have, and call `close_flow`.
-- **`400` containing `budget_exceeded: …`** — the run has **already failed** and the participant agent has stopped. Report this to the user; do NOT retry and do NOT call `close_flow` — closing a failed run overwrites the failure status in the read model (the projector flips `failed` → `closed`), hiding what went wrong.
-- **A round that exceeds the definition's `round_timeout`** lands as a terminal **`unclear`** round, with the timeout explained in its result text — if you check round status programmatically, look for `unclear` and read the text for the timeout reason. The run itself stays open — you may submit another round or close the flow.
+- **`400` containing `budget_exceeded: …`** — the run has **already failed** and all participant agents have stopped. Report this to the user; do NOT retry and do NOT call `close_flow` — closing a failed run overwrites the failure status in the read model (the projector flips `failed` → `closed`), hiding what went wrong.
+- **A round that exceeds the definition's `round_timeout`** lands as a terminal **`unclear`** round, with the timeout explained in its result text — if you check round status programmatically, look for `unclear` and read the text for the timeout reason. The run itself stays open — you may submit another round to that role or close the flow.
 - **Idle runs are auto-reaped** after the definition's `idle_ttl` (server default 24h). Don't rely on this — always call `close_flow` yourself once you're done, whether the outcome was clean or you're abandoning the task.
 - **`400` starting `no_daemon_available:`** — no connected daemon has the repo checked out. Tell the user to run `kcap agent` on a machine with the repo cloned (or pass an explicit `daemon_name` + `repo_path`).
 - **`400` starting `daemon_outdated:`** — the daemon's kcap is too old to host flow participants. Tell the user to update (`npm i -g @kurrent/kcap`) and restart `kcap agent`.
-- **`400` starting `participant_unavailable:`** — the participant agent died and automatic relaunch is not available yet. Close this flow and start a new one, carrying your context forward; re-submitting will keep failing.
-- **A round result of `unclear` whose text is exactly `participant_died` or `participant_stopped`** — the participant agent crashed or was stopped mid-round. The run stays open but has no live participant: close the flow and start a new one.
+- **`400` containing `participant_unreachable`** — that role's agent is in an ambiguous liveness state (its daemon disconnected or is restarting), so the server won't guess whether it's still alive rather than risk a duplicate launch. Retry the send shortly, or ask the user to stop the participant (dashboard/API) and then re-send to force a fresh relaunch.
+- **A round result of `unclear` whose text is exactly `participant_died` or `participant_stopped`** — that role's agent crashed or was stopped mid-round. The run stays **open**: address the same role again with `send_to_participant` and it relaunches automatically — the fresh agent has **no memory of prior rounds**, so restate any context it needs in your message; its earlier spend still counts against the run budget. No need to close and restart the flow. Other roles are unaffected and remain addressable in the meantime.
 
 ## Workflow
 
+Single-participant definitions start eagerly — round 1 runs as part of `start_flow`:
+
 ```
 start_flow(definition_id, target_kind, target_ref, target_title, context)
   → participant returns a result: kind findings (with the result text) | kind clean
@@ -86,12 +92,36 @@ if findings:
   report completion to user
 ```
 
+Multi-participant definitions start round-less — you address each role yourself, and the run is clean only in aggregate:
+
+```
+start_flow(definition_id, target_kind, target_ref, target_title, context)
+  → no round yet — roles have not launched
+
+send_to_participant(flow_run_id, participant="reviewer", message=…)
+  → launches the reviewer's agent; returns kind findings | clean
+
+send_to_participant(flow_run_id, participant="tester", message=…)
+  → launches the tester's agent independently — no need to wait on the reviewer's round;
+    returns kind findings | clean
+
+# a role with an open round in flight 409s if you send to it again — address the OTHER
+# role(s) in the meantime, then come back once its round completes
+
+loop until every addressed role's latest round is clean and none is in flight:
+  address whichever role(s) still have findings
+  send_to_participant(flow_run_id, participant=<that role>, message=…)
+
+close_flow(flow_run_id)   # only once reviewer AND tester are both clean
+report completion to user
+```
+
 ## Tool reference
 
 | Tool | Required args | Optional args | When to call |
 |---|---|---|---|
 | `start_flow` | `definition_id` (e.g. `spec-review`, `code-review`, or a custom catalog id), `target_kind` (what is being worked on: `spec`, `code`, `pr`, `branch`, `file`, etc.), `target_ref` (a path, branch name, or PR URL/number that identifies the target), `target_title` (short human-readable title), `context` (background context: what to focus on, constraints, definition of done) | `instructions`, `mode` (`context-only` — optional; by default, on the same machine, the participant's worktree is mirrored from your working tree including uncommitted changes, so it reads the actual source. Pass `context-only` to opt out and treat the submitted context as authoritative) | Once, at the start of a flow task. |
-| `send_to_participant` | `flow_run_id`, `participant` (Phase D flows have a single participant: `reviewer`), `message` | `instructions`, `async` (defaults to `true`) | After addressing a non-clean result. Pass the same `flow_run_id` and the updated message. |
+| `send_to_participant` | `flow_run_id`, `participant` (role name declared in the flow definition's `participants` map; single-participant definitions use `reviewer` — an unknown role is rejected, naming the valid ones), `message` | `instructions`, `async` (defaults to `true`) | After addressing a non-clean result for that role, or to launch a role for the first time. Pass the same `flow_run_id`, the role's name, and the updated message. |
 | `get_flow_status` | `flow_run_id` | — | Poll or check the current status of a flow run (running, waiting, completed, failed). |
 | `close_flow` | `flow_run_id` | — | Only after the definition's clean signal — or when abandoning the task early; the run otherwise stays open until closed. |
 
@@ -121,3 +151,42 @@ send_to_participant(
 close_flow(flow_run_id="flow_abc123")
 # Report to user: flow complete, all findings resolved
 ```
+
+## Example (two roles: reviewer + tester)
+
+`review-and-test`'s `participants` map declares `reviewer` and `tester` — each is addressed independently, and neither's `send_to_participant` waits on the other's round:
+
+```
+# Step 1 — start; multi-participant, so no round comes back yet
+start_flow(
+  definition_id="review-and-test",
+  target_kind="branch",
+  target_ref="feature/add-null-check",
+  target_title="Add null check on user input",
+  context="Review the diff on this branch and write/run tests for the new code path."
+)
+# → returns flow_run_id, e.g. "flow_xyz789"; no round in the response
+
+# Step 2 — address both roles; each launches lazily on its first message.
+# These are independent — send to tester without waiting for the reviewer's round.
+send_to_participant(flow_run_id="flow_xyz789", participant="reviewer", message="…")
+  # → launches the reviewer; returns kind findings: missing null check on line 42
+send_to_participant(flow_run_id="flow_xyz789", participant="tester", message="…")
+  # → launches the tester; returns kind clean: added a null-input test case, passing
+
+# Step 3 — only the reviewer had findings; fix them and send a follow-up to JUST that role
+send_to_participant(
+  flow_run_id="flow_xyz789",
+  participant="reviewer",
+  message="Fixed null check on line 42. Updated diff attached."
+)
+# → reviewer returns kind clean
+
+# Step 4 — close only once EVERY addressed role's latest round is clean and none is
+# in flight: reviewer clean + tester clean (from step 2, still current) = aggregate clean.
+# One role going clean does not end the run by itself — track each role's latest result
+# from your own send_to_participant responses; the run's status only reads "clean" once
+# every addressed role's latest round is clean and none is in flight (the aggregate rule).
+close_flow(flow_run_id="flow_xyz789")
+# Report to user: flow complete, review and tests both clean
+```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kurrent/kcap",
-  "version": "0.9.5",
+  "version": "0.10.0",
   "description": "CLI companion for Kurrent Capacitor — records and visualizes Claude Code sessions",
   "license": "SEE LICENSE IN LICENSE.md",
   "repository": {
@@ -14,12 +14,12 @@
     "postinstall": "node bin/postinstall.js"
   },
   "optionalDependencies": {
-    "@kurrent/kcap-darwin-arm64": "0.9.5",
-    "@kurrent/kcap-linux-x64": "0.9.5",
-    "@kurrent/kcap-linux-arm64": "0.9.5",
-    "@kurrent/kcap-linux-musl-x64": "0.9.5",
-    "@kurrent/kcap-linux-musl-arm64": "0.9.5",
-    "@kurrent/kcap-win-x64": "0.9.5"
+    "@kurrent/kcap-darwin-arm64": "0.10.0",
+    "@kurrent/kcap-linux-x64": "0.10.0",
+    "@kurrent/kcap-linux-arm64": "0.10.0",
+    "@kurrent/kcap-linux-musl-x64": "0.10.0",
+    "@kurrent/kcap-linux-musl-arm64": "0.10.0",
+    "@kurrent/kcap-win-x64": "0.10.0"
   },
   "files": [
     "bin/",