copilotkit 4.28.0 → 4.30.0

package/onboarding/prompts/frontend/plan.md

@@ -15,18 +15,18 @@ Every rule below is for a run that named neither.
 
 ## Use the recorded frontend
 
-Run `npx --prefer-offline --yes copilotkit@4.28.0 onboard setup-answers` and use its `frontend`. It holds
+Run `npx --prefer-offline --yes copilotkit@4.30.0 onboard setup-answers` and use its `frontend`. It holds
 the answer that `setup/questions` recorded, even after this conversation lost it. If the
 project has a frontend, preserve it and use the matching route below. Do not change
 application code in this phase. If neither settles it, ask one line as the options view
 of `onboard setup-message` does: the recommendation first, in bold, and the alternatives on one `Other:` line, from
 React SPA, Next.js, Angular, Vue 3, React Native, Slack, and Microsoft Teams. Record the answer with
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard setup-answers --frontend <name>`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard setup-answers --frontend <name>`.
 
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about stack-choice
 ```
 
 When the recorded frontend is not Next.js, tell the developer in one sentence where it runs
@@ -38,15 +38,15 @@ words instead.
 
 Use exactly one matching internal route:
 
-1. React SPA: `npx --prefer-offline --yes copilotkit@4.28.0 onboard read frontend/react-spa`
-2. Next.js: `npx --prefer-offline --yes copilotkit@4.28.0 onboard read frontend/nextjs`
-3. Angular: `npx --prefer-offline --yes copilotkit@4.28.0 onboard read frontend/angular`
-4. Vue 3: `npx --prefer-offline --yes copilotkit@4.28.0 onboard read frontend/vue`
-5. React Native: `npx --prefer-offline --yes copilotkit@4.28.0 onboard read frontend/react-native`
-6. Slack or Microsoft Teams: `npx --prefer-offline --yes copilotkit@4.28.0 onboard read feature/channels/start`
+1. React SPA: `npx --prefer-offline --yes copilotkit@4.30.0 onboard read frontend/react-spa`
+2. Next.js: `npx --prefer-offline --yes copilotkit@4.30.0 onboard read frontend/nextjs`
+3. Angular: `npx --prefer-offline --yes copilotkit@4.30.0 onboard read frontend/angular`
+4. Vue 3: `npx --prefer-offline --yes copilotkit@4.30.0 onboard read frontend/vue`
+5. React Native: `npx --prefer-offline --yes copilotkit@4.30.0 onboard read frontend/react-native`
+6. Slack or Microsoft Teams: `npx --prefer-offline --yes copilotkit@4.30.0 onboard read feature/channels/start`
 
 If they chose Slack or Microsoft Teams, tell that node which one they chose so it
 does not ask again.
 
 If no listed frontend fits, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/react-native.md

@@ -6,7 +6,7 @@ This step asks the developer nothing. If the run must wait for the developer any
 the pause first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about other
 ```
 
 React Native has no starter. For a target directory that holds no project, build the new
@@ -25,7 +25,7 @@ documents `useRenderTool`, which is React Native's own hook for drawing a tool t
 already has. That is a different job and needs a tool in the agent.
 
 If the pages support the selection, record React Native and these URLs. Then run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read credentials/finalize-plan`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/react-spa.md

@@ -6,7 +6,7 @@ This step asks the developer nothing. If the run must wait for the developer any
 the pause first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about other
 ```
 
 React SPA has no starter. For a target directory that holds no project, build the new
@@ -26,7 +26,7 @@ that import when Vite leaves the package external.
 - https://docs.copilotkit.ai/react-spa.md
 
 If the page supports the selection, record React SPA and this URL. Then run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read credentials/finalize-plan`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/vue.md

@@ -6,7 +6,7 @@ This step asks the developer nothing. If the run must wait for the developer any
 the pause first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about other
 ```
 
 Vue 3 has no starter. For a target directory that holds no project, build the new
@@ -26,7 +26,7 @@ page above. Vue has its own `useComponent`, which is not the React package. Take
 that reference page rather than from a Vue generative-UI guide, which is not published.
 
 If the pages support the selection, record Vue 3 and these URLs. Then run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read credentials/finalize-plan`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/implementation/build-and-validate.md

@@ -13,7 +13,7 @@ acted on. Send one short report before you stop. The friction command follows th
 setting the developer already chose, so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.30.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -50,14 +50,14 @@ Any other file the plan does not name comes back as a result that starts with
 developer, not a run that broke. Pause: name the file and why the
 work needs it, then end your turn and wait for the developer's answer. If they allow it,
 spawn a fresh implementation subagent with the same handoff. Add that file to the handoff
-as a path the developer approved, and record it as a departure. If you cannot ask, or the
-developer declines, the failure ending in the route-out rules below applies.
+as a path the developer approved, and record it as a departure. If the developer declines,
+run `npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/declined --message "<their reason>"`. If you cannot ask, the failure ending in the route-out rules below applies.
 
 This prompt pauses for the developer in several places. Before you end your turn to wait
 for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about uncommitted-file
 ```
 
 The existing agent's behavior is never a departure to record and carry on from. It is four
@@ -74,7 +74,7 @@ declines, use the route-out rules below.
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about agent-change
 ```
 
 ## The developer's uncommitted files
@@ -97,12 +97,12 @@ or from an environment variable.
 If the CLI prints `## Stop: this run deleted or moved the developer's work` instead of a
 step, show the developer the list it printed, and run what they choose:
 the `onboard restore` command the tripwire stop prints, which names each deleted file, or
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard tripwire --continue`. Then read the step again. If
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard tripwire --continue`. Then read the step again. If
 you cannot ask, use the route-out rules below. Before you end your turn to wait for the
 developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about restore-files
 ```
 
 ## Implement the plan
@@ -116,7 +116,7 @@ Run this from the target app directory. The developer saw the id in the plan, so
 the first point at which it can be created:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 learning containers create --id <id> --name <name> --json
+npx --prefer-offline --yes copilotkit@4.30.0 learning containers create --id <id> --name <name> --json
 ```
 
 Pass the id the plan names. Take the name from the selected project's own display name, so
@@ -133,7 +133,7 @@ When you start a subagent in the background, tell the developer in one sentence
 does. Then send nothing more until it returns.
 
 Spawn one implementation subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read subagent/implement-and-validate` first and
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read subagent/implement-and-validate` first and
 follow the prompt it returns. Tell it to return at once, and say so, if that read is refused
 or fails, and not to wait for an approval. If it returns that way, stop that subagent. Run
 the same command yourself, then spawn a fresh subagent with the returned prompt and the same
@@ -144,6 +144,22 @@ conversion, also give it the frozen criterion. Give it the paths that had uncomm
 changes when the run started. Require it to implement every step in plan order
 and run the full validation list. Wait for it.
 
+If only its closing `subagent-returned` checkpoint was refused, the subagent finished.
+Record no `refused` return and spawn nothing: run that checkpoint yourself, with the result
+the subagent returned.
+
+If the subagent returns because its harness refused any other command, record that return:
+
+```text
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase subagent-returned --brief implement-and-validate --result refused
+```
+
+Then run that command yourself, from the directory the subagent named. Spawn at most one
+fresh subagent for each refused command, with the same handoff and that command's result.
+If the fresh subagent is refused a command too, spawn no other. Follow the
+`subagent/implement-and-validate` brief yourself, as "When a subagent cannot work" in
+`research/gather` says.
+
 One subagent implements the whole plan. Do not divide the work across concurrent subagents,
 and do not spawn a second subagent to reconcile a split.
 
@@ -167,7 +183,7 @@ Report it and take the failure ending.
 If the implementation result does not start with `Status: passed`, do not continue to proof.
 
 Then run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read proof/round-trip`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read proof/round-trip`.
 
 ## Repair rules
 
@@ -191,13 +207,30 @@ A run that broke takes the failure ending: the failure is in code this run did n
 the same command still fails after three repair attempts, a result starts with
 `Status: blocked` for a reason other than a file the plan does not name or a missing Learning
 Container before the one restart, a missing Learning Container after the one restart, or the
-developer
-declined a file the plan does not name, or the run cannot ask them about it. A defect in a
+run cannot ask the developer about a file the plan does not name. A defect in a
 package this run installed is not a stack CopilotKit does not serve, and a command this run
-cannot get to pass is not one either. In those cases run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`.
+cannot get to pass is not one either. In those cases run:
+
+```text
+npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/run-failed --reason <reason> --message "<one line>"
+```
+
+The read refuses to serve the ending without `--reason`, because the command that failed
+is usually your own, such as `next build`, `tsc` or `pytest`, and the CLI cannot see it.
+Pick the one reason that fits what stopped the run:
+
+- `build`: the app's build or dev server failed.
+- `typecheck`: the type checker failed, such as `tsc` or `mypy`.
+- `dependency-install`: a package install or resolve failed.
+- `model-call`: a call to the model provider failed or was refused.
+- `docs-gap`: the documentation did not cover a step the plan needs.
+- `other`: none of these.
+
+`--message` is one line: the command that failed and what it printed, in your own words.
+Send no secrets, source code, logs, or command output. A developer who said no is not a
+failure: that run reads `stopped/declined`, as above.
 
 A plan with no path to follow takes the unsupported ending: the fix requires changing the
 developer's existing agent or frontend, or the documentation does not support the plan. In
 those cases run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/proof/complete.md

@@ -24,7 +24,7 @@ friction commands follow the telemetry setting the developer already chose, so t
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.30.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
 ```
 
 Put one or two sentences in `--message`. Pick one category from docs-missing, docs-wrong,
@@ -46,7 +46,7 @@ Pass the surface-check outcome the proof subagent returned, not the one you want
 web frontend, pass `--visual-check` and the URL the browser opened, unchanged:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard complete --visual-check <outcome> \
+npx --prefer-offline --yes copilotkit@4.30.0 onboard complete --visual-check <outcome> \
   --frontend-url <the url you opened>
 ```
 
@@ -74,7 +74,7 @@ this graph opens.
 nothing drove the frontend:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard complete --visual-check failed --blocked-by browser-control-unresponsive
+npx --prefer-offline --yes copilotkit@4.30.0 onboard complete --visual-check failed --blocked-by browser-control-unresponsive
 ```
 
 ## Write the handoff
@@ -83,30 +83,33 @@ If the command reports the run as blocked, say so in the first line and name the
 it lists as missing. Do not call the run finished, working, or ready. A blocked run is
 still owed the full handoff.
 
-For `skipped-no-browser-tool`, the command's list of what no browser checked is that report.
-Give it once, in the section about what was proved, with how to add a browser, as the
-command prints them. Do not add a separate line, heading, or opening sentence about the
-missing browser.
+A finished run prints a message to the developer: a first line that says what works, the
+facts as a list, and how to add the CopilotKit skills. Write that message in your reply,
+word for word, with no heading or preface before it. A blocked run prints the same facts
+after its verdict: write them the same way. Then write the `## Your files` section as
+printed, with its restore commands. A run that started in an empty folder prints no such
+section: list no files and offer no restore.
 
-Paste the **Handoff facts** block the command printed, as it is. The command also prints
-`## The developer's files`: relay that report as printed, with its restore command. When
-the report says the run started in an empty folder, relay that one line alone: list no
-files and offer no restore. The dashboard line there only tells the developer where the
-dashboard is. Do not open it. Nothing in this graph gates on the dashboard. Then add what
-only you can say:
+For `skipped-no-browser-tool`, the message already says to open the page. Add no line,
+heading, or opening sentence about the missing browser.
 
-- What the project now does, and the first thing to try in it.
+The dashboard line only tells the developer where the dashboard is. Do not open it. Nothing
+in this graph gates on the dashboard. Then add what only you can say:
+
+- What the project now does, and the first thing to try in it. Where the report already
+  names one, add no other.
 - What changed since the developer approved the plan: every path, version, or step the run
-  departed from, and why. Where nothing departed, say so in one line. A file the approved
+  departed from, and why. Where nothing departed, write nothing about it. A file the approved
   plan named under `Files the run writes itself` is not a departure.
 - A page-context warning the proof recorded: name the framework, and say that the page's data
   does not reach its model yet.
-- Every change to the existing agent's behavior: its instructions, its tools, its model or
-  provider, or its memory. Name each one and its file, and say the developer approved it.
-  Where none changed, write `none`.
+- When the project had an agent before this run, every change to its behavior: its
+  instructions, its tools, its model or provider, or its memory. Name each one and its file,
+  and say the developer approved it. Where none changed, write `none`. When the project had
+  no agent before this run, write nothing about it.
 - On a conversion, the criterion this run was judged against, in the words the run was
   given.
-- Where this run proved Rich Threads: they keep messages, generative UI, tool interactions,
+- Where this run proved AG-UI Streams: they keep messages, generative UI, tool interactions,
   and application state, so users can return to earlier work. The same conversations give
   Automatic Learning its evidence.
 - Where the facts name a Learning Container: new conversations go to it. Automatic

package/onboarding/prompts/proof/oss-baseline.md

@@ -1,7 +1,7 @@
 # Prove the existing OSS baseline
 
 Do not prove the baseline yourself. Spawn one proof subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read subagent/prove-oss-baseline` first and follow
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read subagent/prove-oss-baseline` first and follow
 the prompt it returns. Tell it to return at once, and say so, if that read is refused or
 fails, and not to wait for an approval. If it returns that way, stop that subagent. Run the
 same command yourself, then spawn a fresh subagent with the returned prompt and the same
@@ -18,10 +18,26 @@ for a substitute.
 
 Wait for the subagent to finish.
 
+If only its closing `subagent-returned` checkpoint was refused, the subagent finished.
+Record no `refused` return and spawn nothing: run that checkpoint yourself, with the result
+the subagent returned.
+
+If the subagent returns because its harness refused any other command, record that return:
+
+```text
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase subagent-returned --brief prove-oss-baseline --result refused
+```
+
+Then run that command yourself, from the directory the subagent named. Spawn at most one
+fresh subagent for each refused command, with the same handoff and that command's result.
+If the fresh subagent is refused a command too, spawn no other. Follow the
+`subagent/prove-oss-baseline` brief yourself, as "When a subagent cannot work" in
+`research/gather` says.
+
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard proof --step oss-baseline --outcome <passed|failed|skipped> [--predicate <1-6>]
+npx --prefer-offline --yes copilotkit@4.30.0 onboard proof --step oss-baseline --outcome <passed|failed|skipped> [--predicate <1-6>]
 ```
 
 Report the gate whatever it returned. Use the list below. A proof that never ran is `skipped`, not failed. The command prints one line and sends
@@ -43,7 +59,7 @@ Do not change project files before this proof ends. Starting existing developmen
 processes and their ignored runtime files is allowed.
 
 If the subagent proves the `both-oss` predicate, keep its evidence with the plan and run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read conversion/plan`. That project already works.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read conversion/plan`. That project already works.
 What it needs is the conversion, not a build.
 
 A failed baseline does not end the run, and this step does not repair it. Decide which
@@ -58,7 +74,7 @@ pass. This proof only reads.
 A failed baseline whose cause is in the project is the starting state of this project. So
 is an operational failure still there after the third attempt. Record the starting state
 `both-copilotkit-unproved` and run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read credentials/plan`. This prompt is served
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read credentials/plan`. This prompt is served
 whenever a project looks like an OSS integration, so a baseline that did not prove is an
 ordinary starting state rather than a failure. The build that follows fixes the
 integration, and `proof/round-trip` proves the result, with its own bounded repair cycle.
@@ -78,5 +94,5 @@ operational. Run the proof again, three times in total, then record the starting
 above and go on. Both causes lead to the same plan.
 
 If the proof cannot identify the running process safely, or it exposes a secret, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`. Neither means the
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/run-failed --reason other`. Neither means the
 project is unsupported: each means this run did not establish what it needed to.

package/onboarding/prompts/proof/round-trip.md

@@ -1,7 +1,24 @@
 # Prove the user journey
 
-Do not do the proof work yourself. Spawn one proof subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read subagent/prove-round-trip` first and follow the
+Run the proof checks once yourself first, from the target app directory:
+
+```text
+npx --prefer-offline --yes copilotkit@4.30.0 onboard proof-check --json
+```
+
+Add `--server <directory>=<command>` for an agent that the approved plan starts outside the
+app. When the runtime declares more than one agent, add `--agent <id>` with the agent id
+from the approved plan.
+<!-- sandboxed-harness -->
+If your harness runs commands in a sandbox, request escalation for this command.
+<!-- /sandboxed-harness -->
+If it prints an `earlyReport`, show that text to the developer as it is, and go on. Do not
+repair anything on this result. Give its result to the first proof subagent only, not to
+one spawned after a repair. If your harness refuses the command, go on without it.
+
+Apart from that one command, do not do the proof work yourself. Spawn one proof
+subagent. Tell it to run
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read subagent/prove-round-trip` first and follow the
 prompt it returns. Tell it to return at once, and say so, if that read is refused or fails,
 and not to wait for an approval. If it returns that way, stop that subagent. Run the same
 command yourself, then spawn a fresh subagent with the returned prompt and the same handoff.
@@ -37,10 +54,26 @@ the run.
 Wait for the subagent to finish. Its result arrives as a notification. Do not sleep to
 pass the time.
 
+If only its closing `subagent-returned` checkpoint was refused, the subagent finished.
+Record no `refused` return and spawn nothing: run that checkpoint yourself, with the result
+the subagent returned.
+
+If the subagent returns because its harness refused any other command, record that return:
+
+```text
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase subagent-returned --brief prove-round-trip --result refused
+```
+
+Then run that command yourself, from the directory the subagent named. Spawn at most one
+fresh subagent for each refused command, with the same handoff and that command's result.
+If the fresh subagent is refused a command too, spawn no other. Follow the
+`subagent/prove-round-trip` brief yourself, as "When a subagent cannot work" in
+`research/gather` says.
+
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.30.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Report the gate whatever it returned. A proof that never ran is `skipped`, not failed. A
@@ -52,7 +85,7 @@ the next one starts. Until then, `onboard proof-check` counts the next failure a
 If the CLI prints `## Stop: this run deleted or moved the developer's work` instead of a
 step, show the developer the list it printed, and run what they choose:
 the `onboard restore` command the tripwire stop prints, which names each deleted file, or
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard tripwire --continue`. Then read the step again. If
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard tripwire --continue`. Then read the step again. If
 you cannot ask, use the route-out rules below.
 
 Never repair, reset, or revert a file the developer changed outside this run. That holds for
@@ -62,14 +95,20 @@ developer's, however right the diagnosis is and however small the fix. Ask the d
 allow the change, or route out. Never send it to a repair worker without their answer.
 
 This prompt pauses for the developer in several places. Before you end your turn to wait
-for the developer, report the pause:
+for the developer, report the pause. For the tripwire choice:
+
+```text
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about restore-files
+```
+
+For a file the plan does not name:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about uncommitted-file
 ```
 
 If the proof result starts with `Status: passed`, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read proof/complete`. A skipped
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read proof/complete`. A skipped
 surface outcome still enters `proof/complete`. The CLI records `skipped-cloned-starter` and
 `skipped-no-browser-tool` after a passed round trip as complete, and `skipped-no-device` as
 blocked. Do not describe a
@@ -95,7 +134,7 @@ credentials step found the model key missing, or the vendor refused it, and the
 started nothing. Do not send it to a repair worker. Run the `onboard credentials` command
 that its detail names, and act on its answer as `credentials/settle-credentials` says. Ask
 the developer its question, report the pause with
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-model-credential`, and
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-model-credential`, and
 end your turn. When the key settles, run the proof subagent again. If you have not recorded
 this attempt yet, record it first, with the outcome it ended with. This attempt does not
 count toward the three.
@@ -122,7 +161,7 @@ fault, so this is not a route-out. Ask the developer to send one message in the
 thread, and to give you that thread's id. Give them the app URL and the request words from
 the result. Tell them where the id is: in the browser's network tools, the request the page
 sends to the runtime URL carries `threadId` in its body. Report the pause with
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer` and end your
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about thread-id` and end your
 turn. When the developer gives the id, start a new proof subagent with
 the full original proof handoff, the pinned Step 1 record, and the thread id. Tell it to run
 the proof checks with `--thread <id>`. This attempt does not count toward the three. Use the
@@ -171,7 +210,7 @@ the files the developer allowed.
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about uncommitted-file
 ```
 
 Restart each project-owned process changed by the repair. Then spawn a fresh proof subagent
@@ -189,10 +228,13 @@ takes the developer path above instead.
 
 Route out only when the failure is not yours to fix, when the same proof still fails after
 three attempts, or when no evidence of the round trip can be produced. In those cases run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`. The stack is supported:
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/run-failed --reason <reason>`. The stack is supported:
 this run did not finish, which is a different ending and a different report. All three are
 about the round trip itself. A round trip that proved is not one of them, whatever failed
-after it.
+after it. For `<reason>`, pick the one of `model-call`, `build`, `typecheck`,
+`dependency-install`, `docs-gap`, or `other` that names what stopped the round trip.
+When the developer declined what the proof needs, the run did not break: run
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/declined --message "<their reason>"` instead.
 
 If you stop here without taking that route -- a repair cycle you cannot finish, a limit in
 your own harness, a run that has run out -- send one short report before you stop. The
@@ -200,7 +242,7 @@ friction command follows the telemetry setting the developer already chose, so i
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.30.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.