@kurrent/kcap 1.2.0 → 1.3.0-beta.1

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

@@ -1,5 +1,5 @@
 {
   "name": "kcap",
-  "version": "1.2.0",
+  "version": "1.3.0-beta.1",
   "description": "Records and visualizes Claude Code sessions via kcap CLI hooks"
 }

package/kcap/.codex-mcp.json

@@ -10,7 +10,8 @@
     },
     "kcap-flows": {
       "command": "kcap",
-      "args": ["mcp", "flows"]
+      "args": ["mcp", "flows"],
+      "tool_timeout_sec": 600
     },
     "kcap-memory": {
       "command": "kcap",

package/kcap/README.md

@@ -12,9 +12,14 @@ Search and recall past Kurrent Capacitor sessions from inside the agent.
 
 | Tool | Description |
 |------|-------------|
-| `search_sessions` | Free-text + author search over past sessions (and subagent transcripts), defaulted to the cwd's repo |
-| `get_session_summary` | Concise `summary_text` + `plan` for a session |
+| `search_sessions` | Keyword (one to three terms or identifiers) + author search over past sessions (and subagent transcripts), defaulted to the cwd's repo |
+| `list_repo_sessions` | List a repository's sessions you can see, running ones first |
+| `get_session_summary` | Concise `summary_text` + `plan` + `declared_plans` for a session |
+| `list_turns` | Per-turn prose outline for a session |
+| `get_turn` | One turn's full transcript, by session id and turn index |
 | `get_session_transcript` | Speaker-tagged transcript window, with `around_event` drill-in for search hits |
+| `list_repo_plans` | List a repository's declared plans you can see, most recently touched first |
+| `get_declared_plans` | A plan's documents and full task list, by `plan_id` or `session_id` |
 
 Repo-aware: it resolves the cwd to a repo hash at startup, so `search_sessions` defaults to *this* repo.
 

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

@@ -22,7 +22,9 @@ Use the `kcap mcp flows` MCP tools (`start_flow`, `send_to_participant`, `get_fl
 
 ## Long rounds are normal
 
-`round_timeout` is an **inactivity** bound, not a wall-clock cap: a round only fails for taking too long if the participant goes genuinely quiet for that whole stretch — an actively-working participant can legitimately run a round for a long time. If a status check (or `start_flow`/`send_to_participant`) returns the benign "Flow still running" text, that is an expected outcome on a long round, not a problem — re-enter the wait with `get_flow_status(flow_run_id, wait: true)`, which blocks (via bounded, internally-retried checks — never a raw long-poll) until the round finishes or roughly 8 minutes pass, then call it again if it's still running. A round result of **`unclear` now genuinely means the participant went dead or silent** (no activity for the whole inactivity bound, or it crashed/was stopped) — it is no longer a symptom of a merely slow participant; see the `participant_unreachable` and `participant_died`/`participant_stopped` guardrail entries below.
+`round_timeout` is an **inactivity** bound, not a wall-clock cap: a round only fails for taking too long if the participant goes genuinely quiet for that whole stretch — an actively-working participant can legitimately run a round for a long time. If a status check (or `start_flow`/`send_to_participant`) returns the benign "Flow still running" text, that is an expected outcome on a long round, not a problem — re-enter the wait with `get_flow_status(flow_run_id, wait: true)`, which blocks (via bounded, internally-retried checks — never a raw long-poll) until the round finishes or roughly 3.5 minutes pass, then call it again if it's still running. A round result of **`unclear` now genuinely means the participant went dead or silent** (no activity for the whole inactivity bound, or it crashed/was stopped) — it is no longer a symptom of a merely slow participant; see the `participant_unreachable` and `participant_died`/`participant_stopped` guardrail entries below.
+
+**A harness tool timeout is not a flow failure.** `start_flow` and `send_to_participant` block for minutes while the participant works. If your harness aborts the call with its own tool timeout (on Codex the error reads `timed out awaiting tools/call`), the flow is still running server-side. Do not start a new flow and do not investigate — call `get_flow_status(wait: true)`. Without a `flow_run_id` it reads the newest open flow this session started (pass `session_id` for another session's), so it works even when the aborted start never handed you the id or context compaction dropped it; with several open flows it lists them for you to pick from. On a harness that gives the flows server no session identity, it reads the flows started from this workspace on this machine instead.
 
 ## Role-surface safety gate
 
@@ -137,7 +139,7 @@ After applying the role-surface safety gate, if `start_flow` / `send_to_particip
 
 ## Core rules
 
-1. **Start exactly one flow per user task.** Call `start_flow` once and hold the returned `flow_run_id`. Do NOT start a new flow for follow-up rounds — reuse the same ID.
+1. **Start exactly one flow per user task.** Call `start_flow` once and hold the returned `flow_run_id`. Do NOT start a new flow for follow-up rounds — reuse the same ID. If the id is gone (a harness timeout aborted the start, or compaction dropped it), get it back with `get_flow_status(wait: true)` — never by starting another flow.
 2. **After receiving a non-clean result**, address it, then call `send_to_participant` with the same `flow_run_id` and the updated message.
 3. **Do NOT finish the user task while the flow has unresolved results.** Keep iterating until the definition's clean/complete signal.
 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.
@@ -216,7 +218,7 @@ report completion to user
 |---|---|---|---|
 | `start_flow` | Exactly one of `definition_id` (catalog id, e.g. `spec-review`, `code-review`, or a custom catalog id) or `definition_yaml` (inline dynamic definition — see "Composing a dynamic flow"); plus `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) | `vendor` (reserved aliases only — explicit reviewer vendor; omit to use the definition's authored vendor, or your saved `flows.reviewer_vendor` preference if it declares none), `model` (reserved aliases only — explicit reviewer model override; REQUIRES `vendor`, rejected on dynamic/multi-participant starts), `instructions`, `mode` (`context-only` — optional; by default the participant's worktree is mirrored from THIS SESSION's project directory, not from the directory you are working in. 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` (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` | `wait` (`true`/`false`, defaults to `false`) — when `true`, blocks until the round is terminal or roughly 8 minutes pass, instead of returning the current snapshot immediately | Poll or check the current status of a flow run (running, waiting, completed, failed). Use `wait: true` to ride out a long round instead of polling repeatedly yourself. |
+| `get_flow_status` | — | `flow_run_id` (omit to read the newest open flow this session started, or on a harness without a session identity the newest one started from this workspace; several open flows are listed instead), `session_id` (look up another session's flows; defaults to this session), `wait` (`true`/`false`, defaults to `false`) — when `true`, blocks until the round is terminal or roughly 3.5 minutes pass, instead of returning the current snapshot immediately | Poll or check the current status of a flow run (running, waiting, completed, failed). Use `wait: true` to ride out a long round instead of polling repeatedly yourself, and omit `flow_run_id` to recover a flow whose id you never received or lost. |
 | `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. |
 
 ## Example (custom definition)

package/kcap/skills/guided-tour/SKILL.md

@@ -374,12 +374,16 @@ causation, and never a savings figure.
 
 **`What did I leave unfinished in my last session?`** — `search_sessions` with `author: <user>`
 for their most recent session, then `get_session_summary`: the answer lives in the summary's
-Unfinished/Risks section. Quote it with the session id; if the summary has no such section, say
-so plainly rather than inferring one from the transcript.
+Unfinished section. Quote it with the session id. An older summary has a combined Unfinished/Risks
+section instead, which mixes risks and status notes in with the work: report only the concrete
+actions still to do from it and leave the rest out. If there is no such section, or it holds no
+action still to do, say so plainly rather than inferring one from the transcript.
 
 **`Pick up where my last session left off`** — same lookup, then actually resume: load the
-summary's context and unfinished items, restate in two sentences where the work stopped, and ask
-which item to continue with. This one is an action, not a report — end by doing, not describing.
+summary's context and its unfinished actions (found as above), restate in two sentences where the
+work stopped, and ask which action to continue with. If there are none, say no unfinished action
+was recorded and ask what they want to work on next. This one is an action, not a report — end by
+doing, not describing.
 
 **Prompt suggestions you compose** — anywhere you offer a `Prompt ❯` line of your own (rule 5
 next steps, variations, follow-ups), two rules:

package/kcap/skills/plans/SKILL.md

@@ -17,10 +17,13 @@ through the `kcap-plans` MCP tools; nothing infers it. Three rules:
 
 1. **When you write or are handed a plan, spec or design document, declare it.**
    Call `declare_plan_document` with its `kind` (`plan`, `spec` or `design`)
-   and `path`. The file is read locally, hashed, and keyed against the
-   repository root; declaring the same file again from a later session lands
-   on the same plan. When a plan implements a spec, or a spec refines a design,
-   pass the other file as `argues_from` so both attach to one plan.
+   and `path`. The file is read locally, hashed, and keyed against the repository root
+   **and the checkout it sits in**: declaring the same file again from the same
+   checkout lands on the same plan, but from a different worktree or clone it
+   starts a separate one. To continue a plan another session began, see
+   "Resuming a plan" below — do not re-declare its document. When a plan
+   implements a spec, or a spec refines a design, pass the other file as
+   `argues_from` so both attach to one plan.
 2. **When a plan has discrete steps, declare them and update each transition.**
    Call `set_plan_tasks` with the whole ordered list (`title`, optional
    `task_id`, `status`, `note`); re-send the whole list when the steps change,
@@ -28,10 +31,27 @@ through the `kcap-plans` MCP tools; nothing infers it. Three rules:
    task starts, finishes or is skipped, by `task_id` or 1-based `ordinal`, with
    `status` `pending`, `in_progress`, `completed` or `skipped` and a `note`
    when the reason matters. After compaction, `get_plan` returns the list.
+   While a plan's `is_complete` is `false`, never call `set_plan_tasks`
+   on it for any reason — the list would be rebuilt from a view that is
+   missing tasks.
 3. **Keep whatever ledger your own workflow asks for as well.** These tools
    replace the harness's task list, not your notes or any file another
    workflow tells you to maintain.
 
+## Resuming a plan
+
+To continue a plan that an earlier session left unfinished — yours or a teammate's. Finding and reading use the `kcap-sessions` tools; the only writes are the reconciling snapshot in step 3, when one is needed, and the adoption in step 5, always last.
+
+1. **Find it.** `list_repo_plans` lists this repository's open plans. Read each row's `sessions` together: a session that is `active`, not `stale`, and whose `last_touched_at` is recent may still be executing the plan — **ask the user before adopting it**. An active session whose `last_touched_at` is old has most likely moved to other work; a session stays attached to every plan it ever touched, so that alone is no reason to hold back. The default `state: "open"` lists plans with a visible unfinished task; a plan whose visible tasks are done but whose withheld tasks are not is absent from it. When the plan you expect is missing, call `list_repo_plans(state: "all")` and look for rows with `is_complete: false`.
+2. **Read it.** `get_declared_plans(plan_id: …)` for the documents and the full task list.
+3. **Compare the document.** Read the plan file from *this* checkout at its repo-relative `path` and compare it with `content_hash` — the lowercase hex SHA-256 of the file's bytes, as `shasum -a 256` prints it. If it changed, the task list may be out of date. Reconciling it means sending a new snapshot with `set_plan_tasks(plan_id: …)`, and a snapshot **replaces** the list — a task it omits is deleted, a note it omits is cleared:
+   - **`is_complete` is `true`:** reconcile now, **before** step 5, carrying every existing task's `task_id`, `status` and `note` over from step 2. Sent after step 5, the snapshot would carry the resumed task's earlier `pending` status and put it straight back.
+   - **`is_complete` is `false`: never send a snapshot.** Your view is missing someone else's tasks or notes, and a list rebuilt from it would destroy them. Carry on with `update_plan_task`, which changes one task and nothing else, and tell the user the document changed and the list could not be reconciled from your view.
+4. **Verify before continuing.** The ledger records what the earlier session *claimed*. A task left `in_progress` may be half-written: check the working tree and the history since the document's `commit_sha`, when it is set, before picking it up.
+5. **Adopt it.** `update_plan_task(plan_id: …, task_id: …, status: "in_progress")` on the task you are resuming. That attaches this session to the plan and makes it the session's current plan, so later calls can omit `plan_id`. This is always the last write of the procedure.
+
+**Do not call `declare_plan_document` for that plan's file while resuming from a different checkout** — a new worktree, another clone. It would start a second plan, point this session at it, and split the ledger: your progress would land on an empty plan while the original stops moving. Rule 1's "declare a document when you read it" does not apply here. From the same checkout path, declaring it again is harmless.
+
 ## Tool reference
 
 | Tool | Required args | Purpose |
@@ -41,6 +61,8 @@ through the `kcap-plans` MCP tools; nothing infers it. Three rules:
 | `update_plan_task` | `status` and one of `task_id` / `ordinal` (+ `note`, `plan_id`) | Record one transition; the result names the plan. |
 | `get_plan` | — (+ `plan_id`, `session_id`) | Documents, tasks with status and source, progress. |
 
+To read a plan from *another* session, or to find unfinished plans in the repository, use `get_declared_plans` and `list_repo_plans` on the `kcap-sessions` server: they are read-only and do not prompt.
+
 Without `plan_id` every tool acts on the session's current plan — the one it
 most recently wrote to; a session on no plan gets one created by
 `set_plan_tasks` and an empty result from `get_plan`. If a tool cannot resolve

package/kcap/skills/recap/SKILL.md

@@ -10,12 +10,15 @@ description: >-
   "recent changes", "recent sessions", or providing a session ID to review.
   Also covers search/recall asks: "find the session where we…", "which session
   discussed X", "did we ever debug Y", "look up the session about Z", "recall
-  the session that…", "search past sessions for…". Provides instructions for
-  retrieving and searching session history via the kcap CLI and the
-  kcap-sessions MCP tools.
+  the session that…", "search past sessions for…".
+  Also covers declared plans: "continue the plan", "resume the plan", "what's
+  left on the plan", "is the plan finished", "unfinished plans", "what was the
+  last session working through".
+  Provides instructions for retrieving and searching session history via the
+  kcap CLI and the kcap-sessions MCP tools.
 ---
 
-> **For agents:** When the `kcap-sessions` MCP server is available, prefer its tools (`search_sessions`, `list_repo_sessions`, `get_session_summary`, `list_turns`, `get_turn`, `get_session_transcript`) for retrieving past sessions. This CLI-wrapped skill remains a fallback for shell use and when MCP isn't installed.
+> **For agents:** When the `kcap-sessions` MCP server is available, prefer its tools (`search_sessions`, `list_repo_sessions`, `get_session_summary`, `list_turns`, `get_turn`, `get_session_transcript`, `list_repo_plans`, `get_declared_plans`) for retrieving past sessions and the plans they declared. This CLI-wrapped skill remains a fallback for shell use and when MCP isn't installed.
 
 # Session Recap
 
@@ -76,7 +79,8 @@ Returns AI-generated summaries from the most recent ended sessions in the curren
 2. **`## Summary`** — an AI-generated narrative covering:
    - **Context** — why the work was done
    - **Key decisions** — trade-offs and design choices that matter for future work
-   - **Unfinished/Risks** — anything deferred or left incomplete
+   - **Unfinished** — work that remains, one action per bullet
+   - **Risks** — anything flagged as risky or uncertain (older summaries combine these two as **Unfinished/Risks**)
 3. **`## Turns`** — an outline with one line per turn:
    - If the turn has a prose summary, that summary (1-3 sentences).
    - Otherwise, a truncated user-prompt excerpt plus tool/file metadata (tool names, file count).
@@ -98,6 +102,30 @@ For a plain metadata index instead of the outline (turn #, prompt excerpt, tool
 
 **MCP agents:** call `list_turns` to get a session's full turn map (`turn_index`, `prose`, `user_prompt`, `tools`, `files`, token counts), then `get_turn(session_id, turn_index)` for one turn's full transcript. Use `get_session_summary` for the whole-session narrative instead of drilling into individual turns.
 
+## Plans
+
+A session that works from a plan declares it to Capacitor: the documents, an ordered task list, and each task's status. That record outlives the session, so it is how you tell where earlier work stopped. It is reachable only through the `kcap-sessions` MCP tools — `kcap recap` does not print it, and the `## Plan` block above is the plan *text* a session captured, not its task list.
+
+**Finding one.**
+- `list_repo_plans` — the unfinished plans in this repository, most recently touched first. Start here when you have no session id: "what was left unfinished", "is there a plan to continue". The default `state: "open"` lists plans with a visible unfinished task; a plan whose visible tasks are done but whose withheld tasks are not is absent from it. When the plan you expect is missing, call `list_repo_plans(state: "all")` and look for rows with `is_complete: false`.
+- `get_session_summary` — carries `declared_plans`, one pointer per plan that session or its continuation chain declared, when it declared any.
+- `get_declared_plans` — the full task list, by `plan_id` (from either of the above) or by `session_id`.
+
+**Judging whether a plan is done.** Read `progress` and two flags, in this order:
+
+1. `progress.finished` is `true` — the plan is done.
+2. `progress.completed` is less than `progress.total` — the plan is open. What remains is every entry of `tasks` whose status is neither `completed` nor `skipped`; a `list_repo_plans` row has no `tasks`, and gives the first of them as `next_task`.
+3. `is_complete` is `false` — nothing visible remains — possibly nothing visible was declared — but the view is partial; say so and do not call the plan complete.
+4. Otherwise `progress.total_known` is `false` — the session declared documents but never a task list, so completion is unknown. That is not withheld data; do not report it as a partial view. If instead `total_known` is `true`, the server itself reports the plan unfinished — treat it as open and do not infer completion from the totals.
+
+**`is_complete` does not mean the work is done.** It means nothing was withheld from your view, and a half-finished plan usually has `is_complete: true`. `finished` is the field that answers "is it done". If `progress` has no `finished` field, the server predates it: the plan is finished only when `total_known` is true **and** `completed` equals `total` **and** `is_complete` is true.
+
+*Worked example — starting from a session.* `get_declared_plans(session_id: "4f2a…")` returns one plan with `progress: {completed: 2, total: 7, total_known: true, finished: false}` and `is_complete: true`. Branch 2: open, five tasks remain — list them from `tasks`.
+
+*Worked example — starting from a summary.* `get_session_summary` shows `declared_plans: [{plan_id: "9c1e…", completed: 7, total: 7, total_known: true, finished: false, is_complete: false, is_current: true}]`. Not branch 1, not branch 2 — branch 3: all seven visible tasks are done, but the view is partial. Report that; do not report the plan as finished. Drill down with `get_declared_plans(plan_id: "9c1e…")` to see which task and note are withheld.
+
+To pick a plan up and continue it, follow "Resuming a plan" in the `plans` skill.
+
 ## Full Output (`--full`)
 
 The complete transcript with these section types:

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

@@ -19,7 +19,9 @@ These four tools are aliases of the generic flow tools (`start_flow`, `send_to_p
 
 ## Long rounds are normal
 
-`round_timeout` is an **inactivity** bound, not a wall-clock cap: a round only fails for taking too long if the reviewer goes genuinely quiet for that whole stretch — an actively-working reviewer can legitimately run a round for a long time. If a status check (or a `submit_review_round`/`start_review_flow` call) returns the benign "Flow still running" text, that is an expected outcome on a long round, not a problem — re-enter the wait with `get_review_flow_status(flow_run_id, wait: true)`, which blocks (via bounded, internally-retried checks — never a raw long-poll) until the round finishes or roughly 8 minutes pass, then call it again if it's still running. A round result of **`unclear` now genuinely means the reviewer went dead or silent** (no activity for the whole inactivity bound, or it crashed/was stopped) — it is no longer a symptom of a merely slow reviewer, so treat it as a liveness problem (see the `participant_unreachable` and `participant_died`/`participant_stopped` entries below), not as "the review is taking a while."
+`round_timeout` is an **inactivity** bound, not a wall-clock cap: a round only fails for taking too long if the reviewer goes genuinely quiet for that whole stretch — an actively-working reviewer can legitimately run a round for a long time. If a status check (or a `submit_review_round`/`start_review_flow` call) returns the benign "Flow still running" text, that is an expected outcome on a long round, not a problem — re-enter the wait with `get_review_flow_status(flow_run_id, wait: true)`, which blocks (via bounded, internally-retried checks — never a raw long-poll) until the round finishes or roughly 3.5 minutes pass, then call it again if it's still running. A round result of **`unclear` now genuinely means the reviewer went dead or silent** (no activity for the whole inactivity bound, or it crashed/was stopped) — it is no longer a symptom of a merely slow reviewer, so treat it as a liveness problem (see the `participant_unreachable` and `participant_died`/`participant_stopped` entries below), not as "the review is taking a while."
+
+**A harness tool timeout is not a flow failure.** `start_review_flow` and `submit_review_round` block for minutes while the reviewer works. If your harness aborts the call with its own tool timeout (on Codex the error reads `timed out awaiting tools/call`), the flow is still running server-side. Do not start a new flow and do not investigate — call `get_review_flow_status(wait: true)`. Without a `flow_run_id` it reads the newest open flow this session started (pass `session_id` for another session's), so it works even when the aborted start never handed you the id or context compaction dropped it; with several open flows it lists them for you to pick from. On a harness that gives the flows server no session identity, it reads the flows started from this workspace on this machine instead.
 
 ## Role-surface safety gate
 
@@ -130,7 +132,7 @@ After applying the role-surface safety gate, if `start_review_flow` / `submit_re
 
 ## Core rules
 
-1. **Start exactly one flow per user task.** Call `start_review_flow` once and hold the returned `flow_run_id`. Do NOT start a new flow for follow-up rounds — reuse the same ID.
+1. **Start exactly one flow per user task.** Call `start_review_flow` once and hold the returned `flow_run_id`. Do NOT start a new flow for follow-up rounds — reuse the same ID. If the id is gone (a harness timeout aborted the start, or compaction dropped it), get it back with `get_review_flow_status(wait: true)` — never by starting another flow.
 2. **After receiving a `findings` result**, address every finding, then call `submit_review_round` with the updated context and the same `flow_run_id`.
 3. **Do NOT finish the user task while the flow has unresolved findings.** Keep iterating until the reviewer returns `clean`.
 4. **Only call `close_review_flow` after a `clean` result.** Then report completion to the user.
@@ -175,7 +177,7 @@ if findings:
 |---|---|---|---|
 | `start_review_flow` | `kind` (`spec-review`\|`code-review`), `target_kind` (what is being reviewed: `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, e.g. spec name or PR title), `context` (background context: what to focus on, constraints, definition of done) | `vendor` (explicit reviewer vendor; omit to use the definition's authored vendor, or your saved `flows.reviewer_vendor` preference if it declares none), `model` (explicit reviewer model override — REQUIRES `vendor`; only pass it when the user named a model), `instructions`, `mode` (`context-only` — optional) | Once, at the start of a review task. |
 | `submit_review_round` | `flow_run_id`, `context` | `instructions` | After addressing findings. Pass the same `flow_run_id` and the updated context. |
-| `get_review_flow_status` | `flow_run_id` | `wait` (`true`/`false`, defaults to `false`) — when `true`, blocks until the round is terminal or roughly 8 minutes pass, instead of returning the current snapshot immediately | Poll or check the current status of a flow (running, waiting, completed, failed). Use `wait: true` to ride out a long round instead of polling repeatedly yourself. |
+| `get_review_flow_status` | — | `flow_run_id` (omit to read the newest open flow this session started, or on a harness without a session identity the newest one started from this workspace; several open flows are listed instead), `session_id` (look up another session's flows; defaults to this session), `wait` (`true`/`false`, defaults to `false`) — when `true`, blocks until the round is terminal or roughly 3.5 minutes pass, instead of returning the current snapshot immediately | Poll or check the current status of a flow (running, waiting, completed, failed). Use `wait: true` to ride out a long round instead of polling repeatedly yourself, and omit `flow_run_id` to recover a flow whose id you never received or lost. |
 | `close_review_flow` | `flow_run_id` | — | Only after the reviewer returns `clean`. |
 
 ## Example (code review)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kurrent/kcap",
-  "version": "1.2.0",
+  "version": "1.3.0-beta.1",
   "description": "CLI companion for Kurrent Capacitor — records and visualizes Claude Code sessions",
   "license": "SEE LICENSE IN LICENSE.md",
   "repository": {
@@ -14,17 +14,17 @@
     "postinstall": "node bin/postinstall.js"
   },
   "optionalDependencies": {
-    "@kurrent/kcap-darwin-arm64": "1.2.0",
-    "@kurrent/kcap-linux-arm64": "1.2.0",
-    "@kurrent/kcap-linux-musl-arm64": "1.2.0",
-    "@kurrent/kcap-linux-musl-x64": "1.2.0",
-    "@kurrent/kcap-linux-x64": "1.2.0",
-    "@kurrent/kcap-win-x64": "1.2.0"
+    "@kurrent/kcap-darwin-arm64": "1.3.0-beta.1",
+    "@kurrent/kcap-linux-arm64": "1.3.0-beta.1",
+    "@kurrent/kcap-linux-musl-arm64": "1.3.0-beta.1",
+    "@kurrent/kcap-linux-musl-x64": "1.3.0-beta.1",
+    "@kurrent/kcap-linux-x64": "1.3.0-beta.1",
+    "@kurrent/kcap-win-x64": "1.3.0-beta.1"
   },
   "files": [
     "bin/",
     "kcap/"
   ],
-  "kcapReleaseCommit": "d7a1d7225e72573766636da70325ba136bb37566",
-  "kcapReleaseTag": "v1.2.0"
+  "kcapReleaseCommit": "f95e44d81d47ce2bd10c95d45c269951480e9d62",
+  "kcapReleaseTag": "v1.3.0-beta.1"
 }