copilotkit 4.28.0 → 4.29.0

package/onboarding/prompts/starter/clone.md

@@ -1,6 +1,6 @@
 # Clone a starter
 
-First run `npx --prefer-offline --yes copilotkit@4.28.0 onboard setup-answers`. It prints the answers that
+First run `npx --prefer-offline --yes copilotkit@4.29.0 onboard setup-answers`. It prints the answers that
 `setup/questions` recorded, even after this conversation lost them: `framework`, `frontend`,
 `vendor`, `project`, `key`, and on the local route `learning`. Take every "recorded" answer
 below from the record, or this conversation when the record lacks it. Do not ask a question
@@ -22,7 +22,7 @@ project to use, or to open the coding agent in a new empty folder.
 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 existing-folder
 ```
 
 Match the selected agent framework and frontend to this table:
@@ -76,7 +76,7 @@ the derived name.
 Only if the developer asks for an existing project, or asks to see the projects they have,
 read the choices:
 
-`npx --prefer-offline --yes copilotkit@4.28.0 project list --json`
+`npx --prefer-offline --yes copilotkit@4.29.0 project list --json`
 
 Then ask which one to use. Do not order the projects by creation time. If the developer
 already gave this answer, do not ask again. Do not read a secret value. Do not show or
@@ -85,7 +85,7 @@ store a secret value.
 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 project-name
 ```
 
 ## Ask where the model credential lives
@@ -119,7 +119,7 @@ stops the clone. Pass the new file with `--model-key-file`, as for any other key
 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-model-credential
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase awaiting-model-credential
 ```
 
 A path the developer names is theirs to give, including one outside the project. A path
@@ -132,7 +132,7 @@ This route skips the plan step that records the path, so record it here, once, b
 the clone:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard classify --starting-state <starting-state> --agent-framework <agent-framework> --frontend <frontend> --model-vendor <model-vendor> --model-vendor-choice <model-vendor-choice>
+npx --prefer-offline --yes copilotkit@4.29.0 onboard classify --starting-state <starting-state> --agent-framework <agent-framework> --frontend <frontend> --model-vendor <model-vendor> --model-vendor-choice <model-vendor-choice>
 ```
 
 - `<starting-state>`: the starting state the research recorded, usually `empty`.
@@ -155,7 +155,7 @@ Do not inspect another entry in the parent directory. Replace each placeholder w
 recorded value. Do not run a placeholder as a shell argument. If the path holds a space,
 put it in double quotes.
 
-`npx --prefer-offline --yes copilotkit@4.28.0 init --dir <absolute-target-directory> --framework <framework-id> --channel none --no-banner --no-key-prompt --create <name> --install`
+`npx --prefer-offline --yes copilotkit@4.29.0 init --dir <absolute-target-directory> --framework <framework-id> --channel none --no-banner --no-key-prompt --create <name> --install`
 
 `--dir` is always the absolute path of the target directory. `init` builds the app in that
 directory and gives the app the directory's name. Do not add `--name`: `init` refuses
@@ -178,23 +178,23 @@ the developer for the right path, or run the command again without the flag.
 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-model-credential
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase awaiting-model-credential
 ```
 
 If you cannot pass the key file to `init`, for example because a sandbox refuses the path,
 clone without `--model-key-file`. Then copy the key from `<target>` with one command:
-`cd <target> && npx --prefer-offline --yes copilotkit@4.28.0 onboard credentials --model-key <VARIABLE> --env-path <key-file> --copy-to <env file> --json`.
+`cd <target> && npx --prefer-offline --yes copilotkit@4.29.0 onboard credentials --model-key <VARIABLE> --env-path <key-file> --copy-to <env file> --json`.
 `<env file>` is `.env`, or `agent/.env` for the Microsoft Agent Framework Python starter.
 The command writes the key into that file without printing it. If the
 command is refused too, ask the developer to run it. Give them exactly this one line:
-`! cd <target> && npx --prefer-offline --yes copilotkit@4.28.0 onboard credentials --model-key <VARIABLE> --env-path <key-file> --copy-to <env file>`.
+`! cd <target> && npx --prefer-offline --yes copilotkit@4.29.0 onboard credentials --model-key <VARIABLE> --env-path <key-file> --copy-to <env file>`.
 The command needs no input. Without `!`, they run the same command in a terminal.
 Do not write a `sed`, `grep`, or `cat` command to copy the key.
 
 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-model-credential
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase awaiting-model-credential
 ```
 
 ### For a recorded local choice
@@ -204,7 +204,7 @@ command instead of the hosted command above. Do not ask the project questions ab
 Local evaluation creates its own empty project, and `init --local` refuses `--create` and
 `--project`.
 
-`npx --prefer-offline --yes copilotkit@4.28.0 init --dir <absolute-target-directory> --framework <framework-id> --channel none --no-banner --no-key-prompt --local --defer-model --install`
+`npx --prefer-offline --yes copilotkit@4.29.0 init --dir <absolute-target-directory> --framework <framework-id> --channel none --no-banner --no-key-prompt --local --defer-model --install`
 
 Use the `learning` answer from the record, or this conversation. Use the default only when
 neither holds one.
@@ -214,12 +214,12 @@ file. The CLI selects the latest stable release. If the developer gave a candida
 manifest for release testing, add `--candidate <manifest.json>`. Otherwise, do not add it.
 The `--dir`, `--no-install` and `--model-key-file` rules above apply here too.
 
-Before `init`, run `npx --prefer-offline --yes copilotkit@4.28.0 onboard local-terms --json`. If `accepted`
+Before `init`, run `npx --prefer-offline --yes copilotkit@4.29.0 onboard local-terms --json`. If `accepted`
 is false, pause here. Give the developer this exact command to run in their own terminal:
-`npx --prefer-offline --yes copilotkit@4.28.0 local accept-terms`. Never accept the agreement yourself.
+`npx --prefer-offline --yes copilotkit@4.29.0 local accept-terms`. Never accept the agreement yourself.
 Report the pause with
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer`, end your turn,
-and wait for "done". Then run `local-terms` again, and continue only when `accepted` is
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase awaiting-developer --about local-terms`, end your
+turn, and wait for "done". Then run `local-terms` again, and continue only when `accepted` is
 true. A local command that fails with `eula_acceptance_required` comes back to this step.
 
 For `learning.guided`, keep `--defer-model`.
@@ -228,7 +228,7 @@ After `init` reports the stack ready:
 Ask the developer to run this command in their own terminal window, in `<target>`:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 local setup
+npx --prefer-offline --yes copilotkit@4.29.0 local setup
 ```
 
 Do not give it as a `!` line, and do not run it yourself. Its guided model prompt needs a
@@ -237,9 +237,9 @@ changes nothing. The prompt asks for the model and its key, and it saves them pr
 On a running stack, it restarts only Learning. Do not ask for a model file.
 
 Say that the run continues when they reply or resume this session. Report the pause with
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-model-credential`, end your
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase awaiting-model-credential`, end your
 turn, and wait. When the developer replies, run
-`npx --prefer-offline --yes copilotkit@4.28.0 local status --json` from `<target>` and read `learning.configuration`.
+`npx --prefer-offline --yes copilotkit@4.29.0 local status --json` from `<target>` and read `learning.configuration`.
 
 The command installs the local stack, then connects the starter to it. It writes the
 gitignored `.copilotkit/local.json` stack reference and `.copilotkit/project.json` with the
@@ -302,10 +302,10 @@ grep -c '^<VARIABLE>=.' <target>/.env
 a count and never the value.
 
 If a variable is empty, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard credentials --model-key <VARIABLE> --json` from
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard credentials --model-key <VARIABLE> --json` from
 `<target>`, and show the developer `question.ask` word for word. It names the file by its
 full path and the line to add. If they reply with the path of a file that holds the key, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard credentials --model-key <VARIABLE> --env-path <file> --copy-to <question.envFile> --json`
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard credentials --model-key <VARIABLE> --env-path <file> --copy-to <question.envFile> --json`
 from `<target>`. Ask nothing else first. Quote a path that holds a space. The command copies
 the key without printing it. When it reports `ready`, the key is in `question.envFile`. Run
 the check above again, and continue. Follow this paragraph, not the packet's `next`, which is
@@ -333,7 +333,7 @@ The two Microsoft Agent Framework starters keep their key outside `<target>/.env
 When you ask, say that the run continues when they reply or resume this session. Then report the pause and end your turn:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-model-credential
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase awaiting-model-credential
 ```
 
 This is a pause, not a stop. Do not send a stop report, and do not take a stop route.
@@ -349,7 +349,7 @@ Run this from `<target>`, with one `--model-key` for each variable. For the Micr
 Framework Python starter, add `--env-path agent/.env`. Skip it for the .NET starter.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard credentials --model-key <VARIABLE> --json
+npx --prefer-offline --yes copilotkit@4.29.0 onboard credentials --model-key <VARIABLE> --json
 ```
 
 The command never prints a value. If `status` is `ready`, continue. Otherwise do what
@@ -362,7 +362,7 @@ works and the app's model does not: the vendor does not serve the model that
 names, or names another, change `COPILOTKIT_AGENT_MODEL` where `question.ask` says, and
 run the command again.
 
-Then run `npx --prefer-offline --yes copilotkit@4.28.0 onboard read proof/round-trip`.
+Then run `npx --prefer-offline --yes copilotkit@4.29.0 onboard read proof/round-trip`.
 
 If the local command fails, `init` keeps the cloned starter in `<target>`, and its error
 says whether it installed the starter's dependencies, or names the command that does. Do
@@ -375,14 +375,14 @@ available memory, or 40 GiB storage. Tell the developer what to change in Docker
 memory, pass on the amount the message names. Then report the pause and end your turn:
 
 ```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 environment-fix
 ```
 
 When the developer says that Docker is ready, resume from `<target>` with the same model
 choice. If the run used a `--candidate`, add the same one:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 local setup --defer-model --json
+npx --prefer-offline --yes copilotkit@4.29.0 local setup --defer-model --json
 ```
 
 If the run used model settings, replace `--defer-model` with `--model-config <private-file>`.
@@ -390,7 +390,7 @@ Read blockers and the recorded failed step. Do not delete or recreate a failed s
 setup reports the stack ready, connect the starter from `<target>`:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 local connect --approve-connection --json
+npx --prefer-offline --yes copilotkit@4.29.0 local connect --approve-connection --json
 ```
 
 The connection writes `.copilotkit/local.json`, `.copilotkit/project.json`, and the local
@@ -400,6 +400,6 @@ take the route below.
 
 If the command fails, report its exact error and do not claim that the starter is ready.
 Then run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read stopped/run-failed`. The starter is one this
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read stopped/run-failed`. The starter is one this
 graph ships and the stack was chosen from its own supported list, so a command that
 returned an error is a run that broke, not a setup this release does not support.

package/onboarding/prompts/stopped/run-failed.md

@@ -42,13 +42,13 @@ put to them, stop here and send the report 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.29.0 onboard checkpoint --phase awaiting-developer --about scoped-fix
 ```
 
 If they approve it, make that one fix and nothing else. Then come back into this run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard resume --message "<approval>"
+npx --prefer-offline --yes copilotkit@4.29.0 onboard resume --message "<approval>"
 ```
 
 Put the developer's approval in `--message`, in one or two sentences: the fix they
@@ -71,7 +71,7 @@ Send one short report. The friction command follows the telemetry setting the de
 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.29.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped

package/onboarding/prompts/subagent/create-plan.md

@@ -22,6 +22,19 @@ override copies.
 List the required credential variable names. Do not read or return credential values.
 Preserve each agent or frontend that already exists.
 
+## When a command is refused
+
+If you are a subagent and your harness refuses a command, return at once. Name the
+command, the directory you ran it from, and the refusal, and run nothing else. Do not wait
+for an approval: nobody sees it. The main coding agent runs the command itself and passes
+the result on. The one wait allowed is a harness escalation request that this brief tells
+you to make for a command. Make that request and wait for its answer.
+
+If your handoff holds a command's result, use it and do not run that command again.
+
+If you are the main coding agent and follow this brief yourself, this section is not for
+you. Do not return: handle a refused command as the run's other prompts say.
+
 ## What the existing agent's behavior is
 
 The existing agent's behavior is four things: its system prompt and instructions, its
@@ -97,7 +110,7 @@ against a dead host, and the failure arrives as an empty-body 404 with no cause
 Ask the CLI for the dependency upgrade, from the target directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard upgrade-plan --json
+npx --prefer-offline --yes copilotkit@4.29.0 onboard upgrade-plan --json
 ```
 
 It reads the installed tree and the registry. Read `status`:
@@ -185,7 +198,7 @@ here is work the developer did not ask for.
 Plan the threads drawer itself: add it from the selected drawer page, where this frontend
 does not already render one. Where this journey's frontend framework ships no threads
 drawer -- React Native --, plan that the thread is proved by
-`npx --prefer-offline --yes copilotkit@4.28.0 verify --round-trip`, which needs no browser. Do not plan a
+`npx --prefer-offline --yes copilotkit@4.29.0 verify --round-trip`, which needs no browser. Do not plan a
 step that opens the managed Intelligence dashboard.
 
 ## Name the files the run writes itself
@@ -325,10 +338,22 @@ change. Say that in the plan.
 
 Do not leave a change that needs approval out of the list to keep the run moving.
 
+## Return the result
+
 Gather what you need in as few commands as possible. Combine independent reads into one
 command rather than running them one at a time. Split a command only when its result decides
 what you run next.
 
+Before you return, record that you are returning:
+
+```text
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase subagent-returned --brief create-plan --result <ok|failed>
+```
+
+The Status line of your result decides the value. Pass `ok` only for `Status: passed`.
+Pass `failed` for `Status: failed` or `Status: blocked`. If your harness refuses this command, say so in your result and return
+anyway: the main coding agent records it.
+
 Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
 Return the plan, the URLs that you read, and each documentation gap. End your turn after you return
 the findings to the main coding agent.

package/onboarding/prompts/subagent/implement-and-validate.md

@@ -89,6 +89,19 @@ approved paths that do not overwrite such a file, unless the plan lists it under
 running the scaffolder. Ask the main coding agent to revise credential setup when a
 required variable is missing. Do not provision another key to repair a scaffold overwrite.
 
+## When a command is refused
+
+If you are a subagent and your harness refuses a command, return at once. Name the
+command, the directory you ran it from, and the refusal, and run nothing else. Do not wait
+for an approval: nobody sees it. The main coding agent runs the command itself and passes
+the result on. The one wait allowed is a harness escalation request that this brief tells
+you to make for a command. Make that request and wait for its answer.
+
+If your handoff holds a command's result, use it and do not run that command again.
+
+If you are the main coding agent and follow this brief yourself, this section is not for
+you. Do not return: handle a refused command as the run's other prompts say.
+
 ## What the existing agent's behavior is
 
 The existing agent's behavior is four things: its system prompt and instructions, its
@@ -136,7 +149,7 @@ Intelligence: declare each exact version in its app's manifest, then install wit
 project's package manager, under the install rule above. Then check the installed tree:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard upgrade-plan --check --json
+npx --prefer-offline --yes copilotkit@4.29.0 onboard upgrade-plan --check --json
 ```
 
 `single` means every direct dependency resolved to one version. `duplicates` names each
@@ -151,7 +164,7 @@ If the check finds duplicates or the baseline regresses, put the manifests and l
 back, leave Intelligence unwired, and report what failed:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard upgrade-plan --revert --json
+npx --prefer-offline --yes copilotkit@4.29.0 onboard upgrade-plan --revert --json
 ```
 
 Then end your turn. Never add an `overrides`, `resolutions`, or `pnpm.overrides` block to
@@ -183,11 +196,16 @@ project does not hold, and the rendered result looks the same either way.
 Run the full validation list. Record changed files, command results, and errors. Do not
 claim that the real user journey works in this phase.
 
+Your validation stops at `verify`. The proof step runs the round trip and records the
+proof, once. Do not run `verify --round-trip`, `onboard proof-check`, or `onboard proof`.
+Where the validation list names the round trip, leave it to the proof step and say so in
+the Validation section.
+
 Where the plan names a Learning Container id, check that the container exists first. Run
 this from the target app directory, before you write any selector:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 learning containers get <id> --json
+npx --prefer-offline --yes copilotkit@4.29.0 learning containers get <id> --json
 ```
 
 `"status": "success"` means the container exists. An `error.code` of
@@ -220,6 +238,16 @@ Gather what you need in as few commands as possible. Combine independent reads i
 command rather than running them one at a time. Split a command only when its result decides
 what you run next.
 
+Before you return, record that you are returning:
+
+```text
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase subagent-returned --brief implement-and-validate --result <ok|failed>
+```
+
+The Status line of your result decides the value. Pass `ok` only for `Status: passed`.
+Pass `failed` for `Status: failed` or `Status: blocked`. If your harness refuses this command, say so in your result and return
+anyway: the main coding agent records it.
+
 Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
 Return exactly four sections: Status, Files changed, Validation, and Blockers. Then end
 your turn.

package/onboarding/prompts/subagent/inspect-repository.md

@@ -8,13 +8,13 @@ Your handoff holds the JSON of this command, which the main coding agent ran fro
 target project directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.29.0 onboard inspect --json
 ```
 
 Read that JSON. Do not run the command again. If the handoff holds no inspection JSON, run
-the command yourself. If your harness refuses it, return at once with no packet. Say that
-the harness refused the command, name it, and do not wait for an approval. That is not
-`Status: blocked`: the main coding agent can run the command and do this work itself.
+the command yourself. If your harness refuses it, return with no packet, as "When a command
+is refused" below says. That is not `Status: blocked`: the main coding agent can run the
+command and do this work itself.
 
 The JSON answers the deterministic half of both packets exactly, from the same code
 `copilotkit verify` uses: the project record by presence, and, for each app or runtime
@@ -48,6 +48,19 @@ target directory that holds no project yet, and `no-declared-dependency` for a p
 where no directory declares one. Report that reason as the finding. Do not report that
 the inspection found nothing.
 
+## When a command is refused
+
+If you are a subagent and your harness refuses a command, return at once. Name the
+command, the directory you ran it from, and the refusal, and run nothing else. Do not wait
+for an approval: nobody sees it. The main coding agent runs the command itself and passes
+the result on. The one wait allowed is a harness escalation request that this brief tells
+you to make for a command. Make that request and wait for its answer.
+
+If your handoff holds a command's result, use it and do not run that command again.
+
+If you are the main coding agent and follow this brief yourself, this section is not for
+you. Do not return: handle a refused command as the run's other prompts say.
+
 ## Project evidence packet
 
 Find evidence for:

package/onboarding/prompts/subagent/prove-oss-baseline.md

@@ -3,6 +3,19 @@
 Read and run only inside the project directory. Do not edit source, configuration,
 dependencies, or tracked files. Do not read, show, store, or return secret values.
 
+## When a command is refused
+
+If you are a subagent and your harness refuses a command, return at once. Name the
+command, the directory you ran it from, and the refusal, and run nothing else. Do not wait
+for an approval: nobody sees it. The main coding agent runs the command itself and passes
+the result on. The one wait allowed is a harness escalation request that this brief tells
+you to make for a command. Make that request and wait for its answer.
+
+If your handoff holds a command's result, use it and do not run that command again.
+
+If you are the main coding agent and follow this brief yourself, this section is not for
+you. Do not return: handle a refused command as the run's other prompts say.
+
 Find the expected agent id from the project. Start the existing agent and frontend only
 when they are not already running. Before using a port, identify its process and working
 directory. Do not stop a process outside this project.
@@ -35,7 +48,7 @@ Prove the live runtime in this order:
 4. Confirm from project files that the runtime constructor passes a `runner` option rather
    than an `intelligence` option. A package, import, project file, or key is not use proof.
 5. Run
-   `npx --prefer-offline --yes copilotkit@4.28.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --prefer-offline --yes copilotkit@4.29.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
    with the runtime URL or auth header options that this project needs. Add
    `--runtime-url <url>` when the report names a runtime URL the dev server does not
    serve. Require exit zero
@@ -68,5 +81,15 @@ The default in-memory OSS runner is ephemeral. SQLite, custom, or framework pers
 can be durable. Report the persistence that project evidence proves, or `unproved`. Do not
 replace it and do not describe all OSS runs as ephemeral.
 
+Before you return, record that you are returning:
+
+```text
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase subagent-returned --brief prove-oss-baseline --result <ok|failed>
+```
+
+The Status line of your result decides the value. Pass `ok` only for `Status: passed`.
+Pass `failed` for `Status: failed` or `Status: blocked`. If your harness refuses this command, say so in your result and return
+anyway: the main coding agent records it.
+
 Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
 End your turn after returning the baseline result, process ids and ports used, and evidence paths.

package/onboarding/prompts/subagent/prove-round-trip.md

@@ -50,6 +50,19 @@ Gather what you need in as few commands as possible. Combine independent reads i
 command rather than running them one at a time. Split a command only when its result decides
 what you run next.
 
+## When a command is refused
+
+If you are a subagent and your harness refuses a command, return at once. Name the
+command, the directory you ran it from, and the refusal, and run nothing else. Do not wait
+for an approval: nobody sees it. The main coding agent runs the command itself and passes
+the result on. The one wait allowed is a harness escalation request that this brief tells
+you to make for a command. Make that request and wait for its answer.
+
+If your handoff holds a command's result, use it and do not run that command again.
+
+If you are the main coding agent and follow this brief yourself, this section is not for
+you. Do not return: handle a refused command as the run's other prompts say.
+
 ## Step 1 -- Read what the proof needs
 
 Read all of this from the approved plan in one pass, before you start anything:
@@ -76,7 +89,7 @@ about the failure it was spawned to clear.
 Run this from the target app directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.28.0 onboard proof-check --json
+npx --prefer-offline --yes copilotkit@4.29.0 onboard proof-check --json
 ```
 
 It starts each app's `dev` script unless a server from that app already listens, and
@@ -132,7 +145,7 @@ Otherwise sort `firstFailure`, and run the command again after each repair:
   asking. Read the port from the log, not from the plan, and record it:
 
   ```text
-  npx --prefer-offline --yes copilotkit@4.28.0 onboard runtime-url --url <runtime-url>
+  npx --prefer-offline --yes copilotkit@4.29.0 onboard runtime-url --url <runtime-url>
   ```
 
   `<runtime-url>` is the project's runtime URL, or the plan's, with its port replaced by the
@@ -239,7 +252,7 @@ shows it. Send the same run
 body twice: once carrying the context entries the page
 publishes, and once carrying the same entries with one value changed. Use the step 1
 request both times. Write each body to a JSON file in `.copilotkit/proof/`, and send it with
-`npx --prefer-offline --yes copilotkit@4.28.0 verify --send-run <file> --agent <agent id> --json`.
+`npx --prefer-offline --yes copilotkit@4.29.0 verify --send-run <file> --agent <agent id> --json`.
 The command sends the body to `<runtime>/agent/<agent id>/run` and reads the events the run
 streams. It writes them to `<file name>.events.jsonl` beside the body, and prints that path
 with the answer text and the tool calls. Do not send a run with `curl` and read its events
@@ -317,7 +330,7 @@ For a recorded `both-oss` starting state, this step has no component to render.
 same request the baseline recorded, require the same kind of user-visible result the
 baseline produced, and require that the thread for that request is listed in the drawer.
 Where this journey's frontend framework ships no threads drawer -- React Native --, prove
-that thread with `npx --prefer-offline --yes copilotkit@4.28.0 verify --round-trip`, which reads the
+that thread with `npx --prefer-offline --yes copilotkit@4.29.0 verify --round-trip`, which reads the
 answer back off the thread and needs no browser. Where the proof checks needed `--thread`,
 prove the thread for this request with `verify --thread <id>` instead. Record which of the
 two you proved.
@@ -347,7 +360,7 @@ limit can be ten minutes. You cannot interrupt a call while it runs, so the limi
 what you do after one. If a browser call took longer than 60 seconds to return, the browser
 control is unresponsive. Do not call the browser again in this attempt. A second call to a
 hung tool waits as long as the first one did. Run
-`npx --prefer-offline --yes copilotkit@4.28.0 verify --frontend-url <the frontendUrl the proof checks resolved> --json` once,
+`npx --prefer-offline --yes copilotkit@4.29.0 verify --frontend-url <the frontendUrl the proof checks resolved> --json` once,
 and record the `frontend_assets_served` result. Report the outcome `failed` with the cause
 `browser-control-unresponsive`. The application is not at fault on this evidence: every
 step before the browser proved the runtime without one, and no repair to the project can
@@ -357,7 +370,7 @@ reach the tool.
    the page to finish loading. Do not retype the host, and do not substitute a URL a tool
    offers you by default. Where the page loads but its styling is missing or the chat
    control is dead, run
-   `npx --prefer-offline --yes copilotkit@4.28.0 verify --frontend-url <the url you opened> --json`
+   `npx --prefer-offline --yes copilotkit@4.29.0 verify --frontend-url <the url you opened> --json`
    before you diagnose anything else. A dev server can serve its page and refuse every
    static chunk behind it, and on screen that is indistinguishable from a broken
    integration. The `frontend_assets_served` check tells the two apart.
@@ -466,6 +479,16 @@ For every other starting state, record Step 8 as not applicable.
 
 ## Step 9 -- Return the result
 
+Before you return, record that you are returning:
+
+```text
+npx --prefer-offline --yes copilotkit@4.29.0 onboard checkpoint --phase subagent-returned --brief prove-round-trip --result <ok|failed>
+```
+
+The Status line of your result decides the value. Pass `ok` only for `Status: passed`.
+Pass `failed` for `Status: failed` or `Status: blocked`. If your harness refuses this command, say so in your result and return
+anyway: the main coding agent records it.
+
 Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
 Use `Status: passed` when the proof attempt completed with `performed`,
 `skipped-no-browser-tool`, `skipped-no-device`, or `skipped-cloned-starter`. The parent

package/onboarding/prompts/unsupported/no-validated-path.md

@@ -36,17 +36,17 @@ Before you show the best-effort plan, require this complete packet:
 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-plan-approval
 ```
 
 After the developer approves the best-effort plan, run
-`npx --prefer-offline --yes copilotkit@4.28.0 onboard read fallback/best-effort`.
+`npx --prefer-offline --yes copilotkit@4.29.0 onboard read fallback/best-effort`.
 
 Send one short report. The friction command follows the telemetry 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.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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "copilotkit",
-  "version": "4.28.0",
+  "version": "4.29.0",
   "type": "module",
   "engines": {
     "node": ">=20.9.0"