copilotkit 4.28.0 → 4.29.0

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.29.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.29.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.29.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.29.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.29.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.29.0 onboard read stopped/run-failed`. 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,7 @@
 # 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
+`npx --prefer-offline --yes copilotkit@4.29.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 +37,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.29.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.29.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 +68,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.29.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 +78,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.29.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.29.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.29.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 +117,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.29.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 +144,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.29.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 +193,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.29.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,7 +211,7 @@ 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.29.0 onboard read stopped/run-failed`. 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.
@@ -200,7 +222,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.29.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.

package/onboarding/prompts/research/gather.md

@@ -15,16 +15,16 @@ own bookkeeping. Say what the run is doing in the developer's words instead.
 
 Every later command must run from the directory this run is bound to. Elsewhere, the
 command cannot find its run and refuses. Do not report that refusal as a stop. Run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard start --run <onboarding_run_id>` where you are
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard start --run <onboarding_run_id>` where you are
 standing, then run the refused command again.
 
-If you no longer hold the id, run `npx --prefer-offline --yes copilotkit@4.28.0 onboard start` in the
+If you no longer hold the id, run `npx --prefer-offline --yes copilotkit@4.29.0 onboard start` in the
 directory this run started in, with no `--run` and no `--intent`. It reprints the id
 and starts nothing. An id this project does not already hold starts a second
 run, and the work already done stops counting toward the first.
 
 Read only inside the target project directory. Every subagent you spawn inherits that
-limit, including one this graph does not name. Answer a CopilotKit API or configuration
+limit. Answer a CopilotKit API or configuration
 question from the documentation this graph gives you. Another checkout on this machine is
 not a source.
 
@@ -35,7 +35,7 @@ pass.
 
 Telemetry and friction reports follow the CLI telemetry setting the developer controls with
 `copilotkit telemetry` or `DO_NOT_TRACK=1`. Each report is one or two sentences and carries
-no secrets and no source. The feedback commands enforce that setting on every send. Explain it once.
+no secrets and no source. The commands enforce that setting. Explain it once.
 
 The directory this run started in is the run root. Every `--path` argument is read against
 it, so one path names one file from anywhere in the project.
@@ -48,19 +48,33 @@ to the repository root and prints its path.
 
 This rule covers every subagent this run spawns, here and in every later prompt.
 
-Spawning a subagent returns almost at once. That return is the dispatch succeeding, not the
-work finishing: the subagent runs in the background, and its result reaches you as a
-notification. Where your own harness hands you the report from the dispatch itself instead,
-you already hold the result. Either way there is nothing to poll.
+Spawning a subagent returns almost at once. That return is the dispatch, not the result:
+the result reaches you as a notification, or with the dispatch in some harnesses. There is
+nothing to poll.
 
-After you dispatch, do the work that does not depend on the result. For example, dispatch
-the other subagent, or run the preflight that the next prompt gives you. Then end your turn
-and wait for the result. Wherever a prompt in this graph says to wait for a subagent to finish, that is
-what it means. It is a pause, as "Pausing vs stopping" below describes, and not a stop.
+After you dispatch, do the work that does not depend on the result, then end your turn
+and wait for the result. That is what "wait for a subagent to finish" means in this graph.
+It is a pause, as "Pausing vs stopping" below describes, and not a stop.
 
-Do not sleep to pass the time. Not `sleep`, not `/bin/sleep`, not a timer under another
-name, and not a loop that re-checks whether a result arrived. Sleeping tells you nothing
-that waiting for the result does not, and it spends wall clock.
+Do not sleep to pass the time: no `sleep`, no timer, and no loop that re-checks for a
+result. It spends wall clock and tells you nothing.
+
+## When a subagent is refused a command
+
+This rule covers every subagent this run spawns. A subagent whose harness refuses a command
+returns at once with the command, its directory, and the refusal. Then run that command
+yourself, from that directory. Spawn at most one fresh subagent for each refused command,
+with the same handoff and that result. If the fresh subagent is refused a command too,
+spawn no other: do the brief yourself.
+
+Record each research result, since a research subagent runs no onboarding command:
+
+```text
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase subagent-returned --brief inspect-repository --result <ok|refused|failed>
+```
+
+`ok` is `Status: passed`, `failed` is failed or blocked, and `refused` names a refused
+command.
 
 ## Pausing vs stopping
 
@@ -74,7 +88,7 @@ says to file none, follow it, so the run sends one report at most. Nothing else
 A pause keeps the run open. "End your turn and wait for" something means: end this turn.
 When that thing arrives, continue. A pause waits for one of two things:
 
-1. A subagent result. The section above says how to wait for one.
+1. A subagent result, waited for as the section above says.
 2. The developer. Ask the question, then end your turn and wait for the reply. The reply
    is the answer. A developer who replies without choosing, such as "go ahead" or "you
    pick", gives no answer, and the default that the prompt states applies. Where the
@@ -83,54 +97,57 @@ When that thing arrives, continue. A pause waits for one of two things:
 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.29.0 onboard checkpoint --phase awaiting-developer --about <question>
 ```
 
+Use the question the asking prompt names, or else the closest of: `harness-permission`,
+`sign-in`, `setup-answers`, `stack-choice`, `project-name`, `which-project`,
+`env-file-tracked`, `local-connection`, `local-terms`, `existing-folder`,
+`environment-fix`, `uncommitted-file`, `agent-change`, `restore-files`, `thread-id`,
+`scoped-fix`, `feature-binding`, `other`. Report it before every turn that ends while the
+run is open, with `other` if you asked nothing. A run that goes quiet without it reads as
+a run that died.
+
 When the answer or the result arrives, continue from the step that paused. Do not read an
-earlier prompt again, send the welcome again, or start a new run: the run id you hold still
-names this run. A pause is not a stop. It sends no stop report and takes no stop route.
+earlier prompt again, send the welcome again, or start a new run. If you lost the step you
+were on, run `npx --prefer-offline --yes copilotkit@4.29.0 onboard route`. Skip every `subagent/` entry: a
+subagent read that brief. The last step left is that step. Read it again with `onboard read`. A pause is not a stop. It sends no stop report.
 
 ## When a subagent cannot work
 
-This rule also covers every subagent this run spawns, here and in every later prompt.
+This rule covers every subagent too.
 
-A subagent that returns no usable result failed in your harness, not in this graph.
-Delegation buys parallelism and a clean context, not capability: every assignment in this
-run is work you can do yourself, slower. So run that assignment yourself and carry on,
-rather than treating it as the end of the run.
+A subagent that returns no usable result failed in your harness, not in this graph. Every
+assignment in this run is work you can do yourself, slower. So do it yourself and carry
+on. It is not the end of the run.
 
 Both research subagents failing means this harness has no working subagent at all, which
 is worth recording once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase delegation-unavailable
 ```
 
-Then say once, in your own words, that this environment has no working subagents. Say that
-you will do each step yourself, and that the run will take longer than usual.
+Then tell the developer once that this environment has no working subagents, so you do
+each step yourself and the run takes longer.
 
 For the rest of this run, do not spawn a subagent where a prompt tells you to. Read that
 `subagent/` brief yourself and follow it.
 
-Before you ask the developer any setup question, finish every read-only investigation and
-preflight check in this section. The setup message below is the one exception.
-
 Prepare two research assignments. Before you spawn either subagent, run these two
 read-only commands yourself, from the target project directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard read subagent/inspect-repository
-npx --prefer-offline --yes copilotkit@4.28.0 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.29.0 onboard read subagent/inspect-repository
+npx --prefer-offline --yes copilotkit@4.29.0 onboard inspect --json
 ```
 
 Give each research subagent the prompt that the first command returns, the whole JSON that
 the second command returns, and one assignment. Tell it that its handoff already holds both,
-so it runs no onboarding command. A coding agent's permission layer can refuse a registry
-package inside a subagent, even where it lets you run the same command.
-The run then waits for an approval that nobody sees. Require only its assigned packet.
+so it runs no onboarding command: a permission layer can refuse one inside a subagent, and
+the run then waits for an approval nobody sees. Require only its assigned packet.
 
-Give the same JSON to every later subagent that this research spawns, such as a retry, a
-focused directory check, or a conflict verifier.
+Give the same JSON to every later subagent this research spawns, such as a retry.
 
 Start both research subagents in parallel:
 
@@ -149,12 +166,12 @@ names no Channel (as `research/route` lists), and the `onboard inspect` JSON sho
   `detection.agentFramework` has an empty `matched` and an empty `unmatched`.
 
 Once `login --json` has emitted `type: completed`, read the setup questions now:
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read setup/questions`. Record the frontend from
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read setup/questions`. Record the frontend from
 `detection` first.
 Show the message. 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.29.0 onboard checkpoint --phase awaiting-developer --about setup-answers
 ```
 
 Then continue below: the preflight and the merge do not wait for the reply. When the
@@ -168,8 +185,8 @@ the research first.
 The research is under way. Continue to the surface-control preflight while it runs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard read research/preflight
+npx --prefer-offline --yes copilotkit@4.29.0 onboard read research/preflight
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`.

package/onboarding/prompts/research/merge.md

@@ -51,11 +51,11 @@ waits on the developer, end your turn and wait for it: that is a pause.
 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.29.0 onboard checkpoint --phase awaiting-developer --about sign-in
 ```
 
 When both research results are merged and sign-in is done, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read research/route`.
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read research/route`.
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`.

package/onboarding/prompts/research/preflight.md

@@ -32,8 +32,8 @@ Where the device probe found no booted device, that is the whole finding.
 Then merge the research:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard read research/merge
+npx --prefer-offline --yes copilotkit@4.29.0 onboard read research/merge
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`.

package/onboarding/prompts/research/route.md

@@ -21,7 +21,7 @@ On any one of them, run this before you read the three findings below, and witho
 the purpose question:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard read feature/channels/start
+npx --prefer-offline --yes copilotkit@4.29.0 onboard read feature/channels/start
 ```
 
 Name the provider to that node so it does not ask again. A `/slack` page names Slack. A
@@ -82,7 +82,7 @@ settle these three from your own reading of the project. Each one comes from the
 packets or it is not proved.
 
 If all three are proved, prove the live starting state before any project file changes. Run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read proof/oss-baseline`.
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read proof/oss-baseline`.
 
 Route there before any other question to the developer. The questions after this prompt
 select a framework and a frontend that the findings already name, so a developer who
@@ -91,16 +91,16 @@ application is what that node protects. Whether it works is what the proof decid
 these three findings.
 
 For every other combination of the three, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read setup/questions`. That node asks every
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read setup/questions`. That node asks every
 remaining setup question in one message, including what the project is for when nothing
 proves it.
 
 On a blank folder the setup message can go out before the research ends. If the setup
 message is already out and the developer has not replied, record what the findings settle
 with `onboard setup-answers`, then end your turn and send the developer nothing. Report
-the pause with `onboard checkpoint --phase awaiting-developer` first. Do not remind them,
+the pause with `onboard checkpoint --phase awaiting-developer --about setup-answers` first. Do not remind them,
 and do not restate the setup. Their reply continues the run.
 
 If authentication or inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`. Neither says anything
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`. Neither says anything
 about whether this project's stack is supported, which is not yet known at this point.

package/onboarding/prompts/setup/questions.md

@@ -6,7 +6,7 @@ Never ask for the key itself: the message asks only for the file that holds it.
 ## Record what the findings already answer
 
 Do not ask the developer for a fact that the repository or their request answers. Record
-each one with `npx --prefer-offline --yes copilotkit@4.28.0 onboard setup-answers` before you build the
+each one with `npx --prefer-offline --yes copilotkit@4.29.0 onboard setup-answers` before you build the
 message, so the message leaves it out:
 
 - An agent the project already has: `--framework <name>` with its vendor and the choice
@@ -31,14 +31,14 @@ For an existing app on the managed route, the command reads the app's project it
 env-file and project lines are in the same message as the key. That read creates no project
 and writes no file. If the command prints `status: stopped`, do what its `next` says.
 
-On the local route, first run `npx --prefer-offline --yes copilotkit@4.28.0 onboard local-terms --json`.
+On the local route, first run `npx --prefer-offline --yes copilotkit@4.29.0 onboard local-terms --json`.
 If it reports `signed-out` or `unavailable`, follow its `next`. Do not add its
 `question.ask` yourself: the setup message already carries the agreement line.
 
 From the target app directory, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard setup-message --target <empty|existing> [--language <typescript|python|dotnet>] [--vendor <vendor>]
+npx --prefer-offline --yes copilotkit@4.29.0 onboard setup-message --target <empty|existing> [--language <typescript|python|dotnet>] [--vendor <vendor>]
 ```
 
 - `--target empty` for a target with no project yet, `existing` for one with a project.
@@ -52,14 +52,14 @@ your own reply word for word. The developer does not see your tool output. Befor
 put the one short line `next` names, and add nothing else. 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.29.0 onboard checkpoint --phase awaiting-developer --about setup-answers
 ```
 
 Then end your turn and wait for the developer. When the developer replies, record their
 answers with `onboard setup-answers`, and run `onboard setup-message` again with
 `--accept-defaults`, as `next` says. When it prints `status: settled`, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read credentials/plan`. If you came here from
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read credentials/plan`. If you came here from
 `research/gather` before the research merged, do not read `credentials/plan` yet: finish the
 research. If it returns and the developer has not replied, record what the findings settle
 with `onboard setup-answers`, then end your turn and send the developer nothing. Report
-the pause with `onboard checkpoint --phase awaiting-developer` first.
+the same pause first.