copilotkit 4.29.0 → 4.30.0

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.29.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.29.0 onboard checkpoint --phase awaiting-developer --about uncommitted-file
+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.29.0 onboard checkpoint --phase awaiting-developer --about agent-change
+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.29.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.29.0 onboard checkpoint --phase awaiting-developer --about restore-files
+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.29.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.29.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
@@ -151,7 +151,7 @@ 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 implement-and-validate --result refused
+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
@@ -183,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.29.0 onboard read proof/round-trip`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read proof/round-trip`.
 
 ## Repair rules
 
@@ -207,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.29.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.29.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.29.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.29.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.29.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.29.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
@@ -25,7 +25,7 @@ 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
+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
@@ -37,7 +37,7 @@ If the fresh subagent is refused a command too, spawn no other. Follow the
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.29.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
@@ -59,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.29.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
@@ -74,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.29.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.
@@ -94,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.29.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.29.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.
@@ -44,7 +61,7 @@ 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
+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
@@ -56,7 +73,7 @@ If the fresh subagent is refused a command too, spawn no other. Follow the
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.29.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
@@ -68,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.29.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
@@ -81,17 +98,17 @@ This prompt pauses for the developer in several places. Before you end your turn
 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
+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.29.0 onboard checkpoint --phase awaiting-developer --about uncommitted-file
+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.29.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
@@ -117,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.29.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.
@@ -144,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.29.0 onboard checkpoint --phase awaiting-developer --about thread-id` 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
@@ -193,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.29.0 onboard checkpoint --phase awaiting-developer --about uncommitted-file
+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
@@ -211,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.29.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
@@ -222,7 +242,7 @@ friction command follows the telemetry setting the developer already chose, so i
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.29.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.

package/onboarding/prompts/research/gather.md

@@ -1,6 +1,6 @@
 # Gather the evidence this run routes on
 
-The developer can still be signing in. Keep reading the login process as
+The developer can still be signing in. When a login process runs, keep reading it as
 `authenticate/start` says while this phase runs. This phase inspects the project and proves
 what this environment can drive. Do not change application code here, and do not ask the
 developer a setup question yet, except the setup message below: every other read-only
@@ -15,10 +15,10 @@ 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.29.0 onboard start --run <onboarding_run_id>` where you are
+`npx --prefer-offline --yes copilotkit@4.30.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.29.0 onboard start` in the
+If you no longer hold the id, run `npx --prefer-offline --yes copilotkit@4.30.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.
@@ -70,7 +70,7 @@ 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>
+npx --prefer-offline --yes copilotkit@4.30.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
@@ -97,10 +97,10 @@ 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.29.0 onboard checkpoint --phase awaiting-developer --about <question>
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about <question>
 ```
 
-Use the question the asking prompt names, or else the closest of: `harness-permission`,
+Use the question the asking prompt names, or else the closest of: `welcome`, `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`,
@@ -110,7 +110,7 @@ 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. If you lost the step you
-were on, run `npx --prefer-offline --yes copilotkit@4.29.0 onboard route`. Skip every `subagent/` entry: a
+were on, run `npx --prefer-offline --yes copilotkit@4.30.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
@@ -125,7 +125,7 @@ Both research subagents failing means this harness has no working subagent at al
 is worth recording once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase delegation-unavailable
 ```
 
 Then tell the developer once that this environment has no working subagents, so you do
@@ -138,8 +138,8 @@ Prepare two research assignments. Before you spawn either subagent, run these tw
 read-only commands yourself, from the target project directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.29.0 onboard read subagent/inspect-repository
-npx --prefer-offline --yes copilotkit@4.29.0 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.30.0 onboard read subagent/inspect-repository
+npx --prefer-offline --yes copilotkit@4.30.0 onboard inspect --json
 ```
 
 Give each research subagent the prompt that the first command returns, the whole JSON that
@@ -165,13 +165,13 @@ names no Channel (as `research/route` lists), and the `onboard inspect` JSON sho
 - A frontend and no agent: `detection.frontend` has a `match`, and
   `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.29.0 onboard read setup/questions`. Record the frontend from
+Once sign-in is done, read the setup questions now:
+`npx --prefer-offline --yes copilotkit@4.30.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.29.0 onboard checkpoint --phase awaiting-developer --about setup-answers
+npx --prefer-offline --yes copilotkit@4.30.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
@@ -185,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.29.0 onboard read research/preflight
+npx --prefer-offline --yes copilotkit@4.30.0 onboard read research/preflight
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/run-failed --reason other`.

package/onboarding/prompts/research/merge.md

@@ -45,17 +45,18 @@ environment row. If either packet gives no match or more than one match, send ea
 worker a focused directory check. Continue only when both workers return the same one target
 app directory. Both results must start with `Status: passed`. Otherwise, use the stop route.
 
-Read the next step only after `login --json` has emitted `type: completed`. If sign-in still
-waits on the developer, end your turn and wait for it: that is a pause.
+Read the next step only after sign-in is done: `onboard begin` confirmed the session, or
+`login --json` emitted `type: completed`. Until then, keep reading the login process. End
+your turn and wait for the developer only after it writes `type: pause`: that is a pause.
 
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase awaiting-developer --about sign-in
+npx --prefer-offline --yes copilotkit@4.30.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.29.0 onboard read research/route`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read research/route`.
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/run-failed --reason other`.

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.29.0 onboard read research/merge
+npx --prefer-offline --yes copilotkit@4.30.0 onboard read research/merge
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/run-failed --reason other`.

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.29.0 onboard read feature/channels/start
+npx --prefer-offline --yes copilotkit@4.30.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.29.0 onboard read proof/oss-baseline`.
+`npx --prefer-offline --yes copilotkit@4.30.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,7 +91,7 @@ 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.29.0 onboard read setup/questions`. That node asks every
+`npx --prefer-offline --yes copilotkit@4.30.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.
 
@@ -102,5 +102,5 @@ the pause with `onboard checkpoint --phase awaiting-developer --about setup-answ
 and do not restate the setup. Their reply continues the run.
 
 If authentication or inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`. Neither says anything
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/run-failed --reason other`. 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.29.0 onboard setup-answers` before you build the
+each one with `npx --prefer-offline --yes copilotkit@4.30.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,17 +31,17 @@ 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.29.0 onboard local-terms --json`.
+On the local route, first run `npx --prefer-offline --yes copilotkit@4.30.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.29.0 onboard setup-message --target <empty|existing> [--language <typescript|python|dotnet>] [--vendor <vendor>]
+npx --prefer-offline --yes copilotkit@4.30.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.
+- `--target`: `empty` for a target with no project yet, else `existing`.
 - `--language` is the project's language, for a project with no agent.
 - `--vendor` is a model vendor the developer named, as `openai`, `anthropic`, `google`, or
   `openai-compatible`.
@@ -52,13 +52,15 @@ 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.29.0 onboard checkpoint --phase awaiting-developer --about setup-answers
+npx --prefer-offline --yes copilotkit@4.30.0 onboard checkpoint --phase awaiting-developer --about setup-answers
 ```
 
-Then end your turn and wait for the developer. When the developer replies, record their
+End your turn and wait. If they decline, such as **no**, run
+`npx --prefer-offline --yes copilotkit@4.30.0 onboard read stopped/declined --message "<their reason>"`.
+Otherwise 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.29.0 onboard read credentials/plan`. If you came here from
+`--accept-defaults`. When it prints `status: settled`, run
+`npx --prefer-offline --yes copilotkit@4.30.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