copilotkit 4.25.1 → 4.27.0

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.25.1 onboard read subagent/prove-round-trip` first and follow the
+`npx --prefer-offline --yes copilotkit@4.27.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.
@@ -41,7 +41,7 @@ pass the time.
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.27.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
@@ -53,7 +53,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.25.1 onboard tripwire --continue`. Then read the step again. If
+`npx --prefer-offline --yes copilotkit@4.27.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
@@ -66,11 +66,11 @@ This prompt pauses for the developer in several places. Before you end your turn
 for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 If the proof result starts with `Status: passed`, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read proof/complete`. A performed surface outcome with
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read proof/complete`. A performed surface outcome with
 the full round trip is core success even if a continued-development tool fails. 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
@@ -97,7 +97,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.25.1 onboard checkpoint --phase awaiting-model-credential`, and
+`npx --prefer-offline --yes copilotkit@4.27.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.
@@ -124,7 +124,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.25.1 onboard checkpoint --phase awaiting-developer` and end your
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer` 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
@@ -173,7 +173,7 @@ files the developer allowed, and the developer's answer on the Skills install.
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 Restart each project-owned process changed by the repair. Then spawn a fresh proof subagent
@@ -191,7 +191,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.25.1 onboard read stopped/run-failed`. The stack is supported:
+`npx --prefer-offline --yes copilotkit@4.27.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.
@@ -202,7 +202,7 @@ friction command follows the telemetry setting the developer already chose, so i
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.27.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

@@ -14,10 +14,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.25.1 onboard start --run <onboarding_run_id>` where you are
+`npx --prefer-offline --yes copilotkit@4.27.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.25.1 onboard start` in the
+If you no longer hold the id, run `npx --prefer-offline --yes copilotkit@4.27.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.
@@ -82,7 +82,7 @@ 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.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 When the answer or the result arrives, continue from the step that paused. Do not read an
@@ -102,7 +102,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.25.1 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase delegation-unavailable
 ```
 
 Then say once, in your own words, that this environment has no working subagents. Say that
@@ -118,8 +118,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.25.1 onboard read subagent/inspect-repository
-npx --prefer-offline --yes copilotkit@4.25.1 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.27.0 onboard read subagent/inspect-repository
+npx --prefer-offline --yes copilotkit@4.27.0 onboard inspect --json
 ```
 
 Give each research subagent the prompt that the first command returns, the whole JSON that
@@ -140,8 +140,8 @@ Start both research subagents in parallel:
 The research is under way. Continue to the surface-control preflight while it runs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard read research/preflight
+npx --prefer-offline --yes copilotkit@4.27.0 onboard read research/preflight
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.27.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.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 When both research results are merged and sign-in is done, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read research/route`.
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read research/route`.
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.27.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.25.1 onboard read research/merge
+npx --prefer-offline --yes copilotkit@4.27.0 onboard read research/merge
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.27.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.25.1 onboard read feature/channels/start
+npx --prefer-offline --yes copilotkit@4.27.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.25.1 onboard read proof/oss-baseline`.
+`npx --prefer-offline --yes copilotkit@4.27.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,10 +91,10 @@ 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.25.1 onboard read setup/questions`. That node asks every
+`npx --prefer-offline --yes copilotkit@4.27.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.
 
 If authentication or inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`. Neither says anything
+`npx --prefer-offline --yes copilotkit@4.27.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.