copilotkit 4.26.0 → 4.27.0

package/onboarding/prompts/credentials/write-plan.md

@@ -1,8 +1,8 @@
-# Write the plan and get it approved
+# Write the plan and show it
 
 The project and its credentials are settled. This phase wires the runtime, has a
-subagent write the plan, and asks the developer to approve it. This is the last question
-the run asks them.
+subagent write the plan, and shows the plan to the developer. The run waits for their
+answer only when the plan makes a risky change or still needs the model key.
 
 ## If you stop in this phase
 
@@ -11,14 +11,12 @@ friction command follows the telemetry setting the developer already chose, so i
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 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.
 Pick the category that fits from docs-missing, docs-wrong, docs-sequential, cli-gap,
-sdk-gap, environment, port-collision, credential, validation-loop, and other. Leave
---cost-seconds off. A run that stopped cannot separate one papercut's cost from the cost of
-the whole run, so the estimate is optional on a stop report and only there. Send no secrets,
+sdk-gap, environment, port-collision, credential, validation-loop, and other. Leave --cost-seconds off. Send no secrets,
 source code, logs, or command output. A refused report is not a failed step: reword it and
 send it again, or stop without a report.
 
@@ -72,7 +70,7 @@ page is selected yet, add the one for the frontend selected above to the same li
    Native, so the planner proves the thread with `verify --round-trip` instead.
 
 Spawn one planning subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard read subagent/create-plan` first and follow the
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read subagent/create-plan` 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.
@@ -81,18 +79,18 @@ names, selected documentation URLs, and documentation policy. Give it each findi
 framework route told you to record, such as how the agent connects or a `clone()` finding.
 Some of those rules, such as the `clone()` override, are on no documentation page. On a
 conversion, also give it the frozen criterion. Give the planning subagent the paths that
-had uncommitted changes when the run started, from the repository findings. Wait for the
-subagent to finish.
+had uncommitted changes when the run started, from the repository findings, and the
+`backup` result from `onboard credentials`. Wait for the subagent to finish.
 
 Continue only if the planning result starts with `Status: passed`. For `Status: failed`,
 send the result back to the planning subagent for repair, up to three attempts. For
 `Status: blocked`, or a third failed result, run
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`. A plan this run cannot
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read stopped/run-failed`. A plan this run cannot
 write is a run that broke, not a stack the documentation does not cover. The exception is
 a blocked result that names `unsupported/no-validated-path`: the planning subagent found
 that no page supports the plan, so take the no-supported-path route at the end of this
-prompt instead. Do not show or
-ask for approval of a non-pass plan.
+prompt instead. Do not show a
+non-pass plan.
 
 Make sure that the plan preserves each part that already exists. The plan must name the
 credential variables, the Intelligence runtime wiring, the application the project asks
@@ -100,53 +98,112 @@ for, implementation steps, validation steps, and proof steps. Where the plan upg
 CopilotKit dependencies, it must name the versions it moves, every other pin it has to
 move with them, and the revert it falls back to. It must not contain secret values.
 
-Show only the selected framework, frontend, model, planned file changes with the feature explanations below where applicable, any ignore-file line this run adds, the files the run writes itself, the CopilotKit Skills install as a choice the developer approves or declines, the CopilotKit dependency upgrade and the versions it moves, every other dependency the upgrade moves and the versions it moves them to, any TypeScript upgrade a `tsconfig.json` change needs and the compiler options it removes, validation commands, and proof steps.
+## Show the plan
 
-Explain these benefits in your own words within the planned changes, only when the
-plan includes the feature:
+Show the plan as one short message, one line per item, in this order: the agent, the app
+changes, the packages, Learning, Skills, the notes, and the risky changes last. Leave out a
+line with nothing to say, except the risky changes. When `Risky changes` says `none`:
 
-- Threads drawer: users can switch between conversations and return to earlier work
-  with their messages, generative UI, tool interactions, and application state restored.
-- Learning Container: it groups the conversations Automatic Learning learns from.
-  As people use the app, Automatic Learning can find recurring patterns and propose
-  reusable Skills to help the agent improve. The developer can review the supporting
-  conversations and decide which Skills to approve.
+```text
+Plan: no approval needed. Reply **stop** at any time.
+
+- Agent: built-in CopilotKit agent on Groq (openai/gpt-oss-120b)
+- App changes: runtime route, provider, chat with order status cards and a Threads drawer (7 files)
+- Packages added: @copilotkit/runtime and @copilotkit/react-core 1.78.0, @ai-sdk/openai, zod. No upgrades.
+- Learning: new container order-assistant
+- Skills: CopilotKit skills into .agents/skills/ (say **no Skills** to skip)
+- Note: the fixed test user identity works only in development (this app has no sign-in)
+
+Risky changes: none. `onboard restore` puts back what the backup holds.
+```
+
+- App changes: what the app gains, and how many files change.
+- Packages: each package added, with the CopilotKit version. Name each version a move
+  changes, or end with "No upgrades."
+- Learning: the container id, or that Learning is not available to this organization.
+- Skills: the `Skills install` line, or "in place".
+- A note is only for something that changes behavior or security, such as a local
+  placeholder, a side effect the plan blocks, a TypeScript upgrade, or an ignore-file line
+  this run adds.
 
-These explanations are required content, not fixed wording. They explain the existing
-plan. They do not add features, implementation steps, or a separate message or question.
+Leave out what a feature does, the validation and proof steps, and the files the run
+writes itself. They stay in the plan.
 
-Carry the developer's answer on the Skills install into the implementation and proof
-handoffs. Approving the plan without a word on the Skills approves the install.
+A plan with a risky change puts its risky lines at the top, from the plan's `Risky
+changes` section, and waits:
 
-An upgrade to a working install is the developer's call, so it belongs in the plan they
-approve rather than in the implementation that follows. Do not upgrade a dependency the
-developer did not approve.
+```text
+Plan: reply **go** to make the risky changes below, or name the ones to leave out. Reply **stop** at any time.
+
+Risky changes:
+- package.json: moves @copilotkit/react-core from 1.70.2 to 1.78.0, which Intelligence needs
+
+- Agent: ...
+
+`onboard restore` puts back what the backup holds.
+```
 
-If the plan carries a missing model key, name the variable and its file in the approval
-message. Ask the developer to add the key before they approve.
+The Skills install is not a risky change, so the plan does not wait for it. If the developer
+says no to it, at any point, carry that into the implementation and proof handoffs. If the
+no arrives after the install, tell the developer that the install wrote `.agents/skills/`
+and its links in `.claude/skills/`, and that deleting both removes it.
 
-When you ask for approval, tell the developer in one line that this is the last thing you
-need from them, and that if you need them to approve a command, or something blocks you, you
-will ask them here. Do not predict whether that will happen: no step after approval asks the
-developer a question unless a step cannot be built as approved, but a harness can still hold
-a command for approval. Say it in the same message as the plan, and do not turn it into a
-second question.
+An upgrade to a working install is the developer's call. Do not upgrade a dependency the
+plan does not name.
 
-Before you end your turn to wait for the answer, report the pause, each time you show the
-plan:
+## Go on, or wait for one answer
+
+Check `Risky changes` first. Where the plan makes one of these and does not list it, send
+the plan back to the planning subagent: a write outside the project, any CopilotKit
+dependency version change, and a backup that is `partial` or `failed`.
+
+When `Risky changes` says `none`, do not wait for an answer. Send the plan message and
+start the build at once, in the same turn, with the read at the end of this section. Do not
+ask the developer to approve the plan, and do not end your turn.
+
+Otherwise, the plan's first line asks the risky-change question, as above. A reply
+such as "go" approves every risky change except an untrack: only an answer to that line
+approves an untrack. Add one line: this is the last thing you need from them, unless a command needs their
+approval or something blocks you. Before you end your turn to
+wait for the answer, report the pause, each time you show the plan:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-plan-approval
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-plan-approval
 ```
 
-After the approval, run the same `onboard credentials --model-key` check again when the plan
-carries a missing model key. On `ready`, continue. If the key is still missing, ask the
-developer `question.ask` in those words. Report the pause with
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-model-credential`, end
+When the developer leaves a risky change out, send the plan back to the planning subagent
+without it. Show the new plan the same way.
+
+If the plan carries a missing model key, the run cannot build without it, so wait for it
+even when `Risky changes` says `none`. Name the variable and its file in the plan message,
+and ask the developer to add the key. Ask the risky-change question in the same message, if
+there is one. When the plan has no risky change, report the pause with
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-model-credential`
+instead. When the developer answers, run the same `onboard credentials --model-key` check
+again. On `ready`, continue. If the key is still missing, ask the developer `question.ask`
+in those words. Report the pause with
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-model-credential`, end
 your turn, and run the check again when they answer.
 
-If the developer approves the plan, run
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard read implementation/build-and-validate`.
+When the plan needs no answer, or after the developer answers, run
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read implementation/build-and-validate`.
 
 If no exact supported path or documentation URL exists, run
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read unsupported/no-validated-path`.
+
+## If the developer replies **stop**
+
+If the developer replies **stop** at any point after the plan, stop the subagent that is
+running. Ask whether to put back every file this run changed or deleted. Say that files the
+run added stay, and that the restore also undoes any edit the developer made to those files
+during the run. Before you end your turn to wait for the answer, report the pause:
+
+```text
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
+```
+
+If they say yes, run `npx --prefer-offline --yes copilotkit@4.27.0 onboard restore --force`. The run has
+not ended yet, so without `--force` the restore cannot tell the run's edits from the
+developer's and skips every changed file. Show the developer what it restored and what it
+skipped. If they say no, change nothing. Then send the stop report from the start of this
+prompt with the category `other`, and stop onboarding.

package/onboarding/prompts/deployment/choose-local.md

@@ -9,15 +9,15 @@ A local request can arrive after this run created a hosted project: `init --crea
 Tell the developer that this run already created a hosted project, so it stays managed.
 Return to the step you were on.
 
-First run `npx --prefer-offline --yes copilotkit@4.26.0 local --help`. If it does not list `setup`
+First run `npx --prefer-offline --yes copilotkit@4.27.0 local --help`. If it does not list `setup`
 ("Configure model access and install or resume the local stack"), this release has no
 local evaluation. Tell the developer so, and keep managed. If this run has not recorded
-managed yet, run `npx --prefer-offline --yes copilotkit@4.26.0 onboard deployment --choice managed`.
+managed yet, run `npx --prefer-offline --yes copilotkit@4.27.0 onboard deployment --choice managed`.
 Then return to “Check sign-in” in the start prompt. If a login process from it still
 runs, keep reading that process and start no second one. Otherwise record the choice:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard deployment --choice local
+npx --prefer-offline --yes copilotkit@4.27.0 onboard deployment --choice local
 ```
 
 Explain these conditions before sign-in:
@@ -25,9 +25,9 @@ Explain these conditions before sign-in:
 - This is self-hosting on the developer's machine, for evaluation. The CLI does not
   install into a cluster. To self-host in their own cluster, they follow the Helm guide
   (https://docs.copilotkit.ai/intelligence/self-hosting.md).
-- The developer supplies Docker with 4 CPUs, 12 GiB of memory available to containers,
+- The developer supplies Docker with 4 CPUs, 4 GiB of memory available to containers,
   and 40 GiB free storage for this stack, after other workloads. Docker keeps part of its
-  memory limit for itself, so the limit must be 14 GiB or more.
+  memory limit for itself, so the limit must be 6 GiB or more.
 - The CLI installs Threads, Learning, Channels, the dashboard, CLI-approved local sign-in,
   databases, and persistent object storage. Memory and analytics are excluded.
 - CopilotKit sign-in issues a renewable plan-based license. Local dashboard
@@ -41,15 +41,17 @@ candidate manifest. If the developer gives a candidate manifest path for release
 testing, record it for setup. Do not substitute a chart tag or a checkout build.
 Never ask the developer to paste credentials into the conversation.
 
-Collect the model choice for Learning. The first proof does not need a Learning model,
-and Learning starts its first run only after 15 conversations. Offer these choices:
+Do not ask for the Learning model here. The first proof does not need one, and Learning
+starts its first run only after 15 conversations, so the setup message asks it later with
+the other setup questions. A run that skips that message takes the default. These are the
+choices:
 
 1. Configure later, the default. Install with `--defer-model`. In the closing report, write
    "Learning configuration incomplete". Name the command that adds the model later:
-   `npx --prefer-offline --yes copilotkit@4.26.0 local setup`, run in a terminal in the app directory.
+   `npx --prefer-offline --yes copilotkit@4.27.0 local setup`, run in a terminal in the app directory.
 2. Guided setup. If the developer named Learning as a goal, offer it first. Install
    the stack with `--defer-model`. After the stack is ready, the developer runs
-   `npx --prefer-offline --yes copilotkit@4.26.0 local setup` in their own terminal window, in the app
+   `npx --prefer-offline --yes copilotkit@4.27.0 local setup` in their own terminal window, in the app
    directory. Never give it as a `!` line: its guided prompt needs a terminal, and a coding
    agent's shell has none. The prompt asks for the model and its key, and it saves them
    privately. On a running stack, it restarts only Learning. Do not ask the developer to
@@ -57,13 +59,8 @@ and Learning starts its first run only after 15 conversations. Offer these choic
 3. A private model file that the developer has already. Pass its path with
    `--model-config <file>`. Do not read or print the file.
 
-Before you end your turn to wait for the developer, report the pause:
-
-```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
-```
-
-Record the model choice, and any candidate path, in the plan, but no secret values.
+If the developer already named one of them, record it. Record the model choice, and any
+candidate path, in the plan, but no secret values.
 Create no cluster and change no app files at this step. The developer can still decline sign-in.
 If declined, take the failure path below.
 
@@ -74,7 +71,7 @@ If the managed sign-in message was already sent, send this once and no other sig
 message: “You asked to run it locally, so this project gets no managed CopilotKit project.
 Signing in only gets the renewable evaluation license.”
 
-Otherwise run `npx --prefer-offline --yes copilotkit@4.26.0 login --json`. Follow the streaming sign-in
+Otherwise run `npx --prefer-offline --yes copilotkit@4.27.0 login --json`. Follow the streaming sign-in
 protocol from “Check sign-in” in the start prompt: open the first authentication URL
 once, keep the same process running, and continue only after its completed record.
 When the first authentication URL arrives, send this message in place of the managed
@@ -82,9 +79,9 @@ sign-in message: “Sign in to get the renewable evaluation license. Your local
 will use CLI approval.”
 On failed or declined sign-in, take the failure path below.
 
-After sign-in completes, report it: `npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase sign-in-settled`.
+After sign-in completes, report it: `npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase sign-in-settled`.
 Then continue with
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard read research/gather`, unless research already started.
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read research/gather`, unless research already started.
 If it already started, return to the step you were on. `starter/clone` and
 `credentials/finalize-plan` each have a branch for a recorded local choice.
 Keep the local choice and collected paths in the run's plan and worker context.
@@ -92,4 +89,4 @@ Keep the local choice and collected paths in the run's plan and worker context.
 ## Failure path
 
 If sign-in fails or is declined, stop before cluster creation.
-Run `npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`.
+Run `npx --prefer-offline --yes copilotkit@4.27.0 onboard read stopped/run-failed`.

package/onboarding/prompts/deployment/local-evaluation.md

@@ -6,37 +6,61 @@ framework and existing code. Do not run the full init command from this graph.
 
 ## Approve the app connection
 
-Before changing files, show a short plan with the exact app directory and these writes:
+The connection writes these in the exact app directory:
 
 - `.gitignore` and the gitignored `.copilotkit/local.json` stack reference.
-- `.env`: `INTELLIGENCE_API_URL`, `INTELLIGENCE_GATEWAY_WS_URL`,
-  `CPK_INTELLIGENCE_API_KEY`, and `SL_ENABLED`.
+- The app's env file: `INTELLIGENCE_API_URL`, `INTELLIGENCE_GATEWAY_WS_URL`,
+  `CPK_INTELLIGENCE_API_KEY`, and `SL_ENABLED`. The CLI picks the file: `.env`, or the
+  ignored env file the app already keeps its project key in.
 - `.copilotkit/project.json`: the local project selection.
 
-Explain that local setup creates an empty local project. It copies no hosted data.
-Prior connection settings are saved in private CLI state before the app changes.
-`local cancel` restores only settings that still match this setup's writes and reports
-conflicting setting names. It preserves later edits and the stack's data.
+Local setup creates an empty local project. It copies no hosted data. Prior connection
+settings are saved in private CLI state before the app changes. `local cancel` restores only
+settings that still match this setup's writes and reports conflicting setting names. It
+preserves later edits and the stack's data.
 
-Get approval for the local installation and these connection writes. Ask the developer
-before you edit one of these files that has uncommitted changes. Approval for a scaffold alone
-does not authorize replacing an existing app's connection.
+Run `npx --prefer-offline --yes copilotkit@4.27.0 onboard setup-answers`. It holds the setup message's
+answers, even after this conversation lost them. Take each answer below from the record,
+or this conversation when the record lacks it. A field the record lacks is not a "no".
+
+First, the files with uncommitted changes. Write to a file with uncommitted changes only
+when `uncommittedWrites` is `approved`. If it is `declined`, ask the developer to commit
+those changes, and wait. If neither the record nor this conversation answers it and one of
+these files has uncommitted changes, ask about those files on one line, and record the
+answer with `onboard setup-answers --uncommitted-writes <approved|declined>`.
+
+Then the connection. If `connection` is `approved`, the developer approved the local
+connection line in the setup message, so do not ask again: name the app directory and
+these writes in one short message, and go on to the installer.
+
+Otherwise, with no `connection` answer in the record, or this conversation, show the writes
+above and get approval for the local installation and these connection writes. Record it
+with `onboard setup-answers --connection approved`. Approval for a scaffold alone does not
+authorize replacing an existing app's connection.
 
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 ## Run the shared installer
 
-From the exact app directory, use the collected model choice:
+From the exact app directory, use the `learning` answer from the record, or this
+conversation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 local setup --defer-model --json
+npx --prefer-offline --yes copilotkit@4.27.0 local setup --defer-model --json
 ```
 
-For supplied model access, replace `--defer-model` with `--model-config <private-file>`.
+For `learning.file`, replace `--defer-model` with `--model-config <learning.file>`.
+Before setup, run `npx --prefer-offline --yes copilotkit@4.27.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.27.0 local accept-terms`. Never accept the agreement yourself.
+Report the pause with
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer`, 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.
 The CLI selects the latest stable release. Add `--candidate <manifest.json>` only when the
 developer gave a candidate manifest for release testing.
 Do not print or read the model file into the conversation. Do not install or manage Docker.
@@ -51,7 +75,7 @@ A copied app needs explicit `--share-stack`. Do not infer sharing from a copied
 After setup reports the stack ready, run the approved connection step from that directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 local connect --approve-connection --json
+npx --prefer-offline --yes copilotkit@4.27.0 local connect --approve-connection --json
 ```
 
 Read the local `.copilotkit/project.json` for its project ID and slug. Do not run hosted
@@ -65,13 +89,13 @@ Use the existing Threads round-trip proof against this local project. Verify a r
 message, reply, and saved conversation. Installation readiness alone is not that proof.
 
 Learning needs valid model settings for this installation. A previous local installation
-proves nothing about these settings. If the developer chose guided setup, wait until the
-stack is ready. Then:
+proves nothing about these settings. If the developer chose guided setup, in the record or
+this conversation, wait until the stack is ready. Then:
 
 Ask the developer to run this command in their own terminal window, in the app directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 local setup
+npx --prefer-offline --yes copilotkit@4.27.0 local setup
 ```
 
 Do not give it as a `!` line, and do not run it yourself. Its guided model prompt needs a
@@ -80,9 +104,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.26.0 onboard checkpoint --phase awaiting-model-credential`, end your
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-model-credential`, end your
 turn, and wait. When the developer replies, run
-`npx --prefer-offline --yes copilotkit@4.26.0 local status --json` and read `learning.configuration`.
+`npx --prefer-offline --yes copilotkit@4.27.0 local status --json` and read `learning.configuration`.
 
 If the model is still missing or was deferred, report “Learning configuration incomplete”
 and name the same command, run in a terminal window. No Learning run is required to finish
@@ -96,6 +120,6 @@ must not block Threads, the dashboard, or later Learning configuration.
 If the developer cancels the connection, run `local cancel --json` from the app directory.
 Report conflict names only. Keep the stack unless deletion is separately confirmed.
 
-Continue with `npx --prefer-offline --yes copilotkit@4.26.0 onboard read credentials/settle-credentials`.
+Continue with `npx --prefer-offline --yes copilotkit@4.27.0 onboard read credentials/settle-credentials`.
 For this local route, skip the hosted selection-result checks and use the local project
 record. Continue the existing implementation and proof paths against local endpoints.

package/onboarding/prompts/fallback/best-effort.md

@@ -14,7 +14,7 @@ you stop. The friction command follows the telemetry setting the developer alrea
 so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 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.
@@ -61,7 +61,7 @@ or frontend, stop onboarding.
 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.26.0 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, stop onboarding. Never repair, reset, or revert a file the developer changed
 outside this run.
 
@@ -110,25 +110,27 @@ that the selected documentation proved an inferred step.
 Record what the proof returned before you complete:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 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>
 ```
 
-When the proof is complete, run `npx --prefer-offline --yes copilotkit@4.26.0 onboard complete`, carrying the
+When the proof is complete, run `npx --prefer-offline --yes copilotkit@4.27.0 onboard complete`, carrying the
 surface-check result the proof subagent returned. Pass exactly one of `--visual-check` or
 `--device-check`, matching this journey's surface:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard complete --visual-check <outcome>
-npx --prefer-offline --yes copilotkit@4.26.0 onboard complete --device-check <outcome>
+npx --prefer-offline --yes copilotkit@4.27.0 onboard complete --visual-check <outcome>
+npx --prefer-offline --yes copilotkit@4.27.0 onboard complete --device-check <outcome>
 ```
 
 `--visual-check` is for a web frontend and takes `performed`, `skipped-no-browser-tool`, or
 `failed`. `--device-check` is for React Native and takes `performed`, `skipped-no-device`,
 or `failed`. `failed` and `skipped-no-device` end this run as blocked, and the command's
 output names the evidence that is missing. Report it that way. The command also prints
-`## The developer's files`: relay that report as printed, with its restore command. `skipped-no-browser-tool`
-completes the run when the round trip was recorded as `passed`, and the output names what
-no browser checked. Without that record it blocks.
+`## 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. `skipped-no-browser-tool` completes the run when the round
+trip was recorded as `passed`, and the output names what no browser checked. Without that
+record it blocks.
 
 If the proof passed and something after it still blocked this run, add
 `--blocked-by <cause>` to the same command, with one of `inspector`, `plan-excluded-capability`,

package/onboarding/prompts/feature/a2ui/implement.md

@@ -24,7 +24,7 @@ That result is a question for the developer. Name the file and why the work need
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 Then end your turn and wait for the developer's answer. If they allow it, spawn a fresh
@@ -34,16 +34,16 @@ cannot ask, or the developer declines, take the feature stop route below.
 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.26.0 onboard tripwire --continue`. Then read the step again.
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard tripwire --continue`. Then read the step again.
 
 To route out and stop:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.27.0 onboard read feature/stop
 ```
 
 If validation cannot pass, or this intent needs a prerequisite the app does not have, use
 the feature stop route above without further changes.
 
 Otherwise run
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard read feature/a2ui/proof`.
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read feature/a2ui/proof`.

package/onboarding/prompts/feature/a2ui/plan.md

@@ -12,7 +12,7 @@ The approval is a wait for the developer. Before you end your turn to wait, repo
 pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 A turn that ends while the run waits is a pause, not a stop, even when your harness ends it.
@@ -49,7 +49,7 @@ renders a compact visible surface. Ask for approval as its own question.
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-plan-approval
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-plan-approval
 ```
 
 Ask the developer before you edit a file that has uncommitted changes. List those files in
@@ -57,4 +57,4 @@ the plan under `Uncommitted files`, each with one sentence explaining why, or wr
 `git status` names them. The CLI records no consent: the approved plan is the record. The
 plan must not delete, move, or rename one of those files.
 
-Then run `npx --prefer-offline --yes copilotkit@4.26.0 onboard read feature/a2ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.27.0 onboard read feature/a2ui/implement`.

package/onboarding/prompts/feature/a2ui/proof.md

@@ -25,7 +25,7 @@ That result is a question for the developer. Name the file and why the fix needs
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
 ```
 
 Then end your turn and wait for the developer's answer. If they allow it, spawn a fresh
@@ -35,13 +35,13 @@ or the developer declines, take the feature stop route below.
 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.26.0 onboard tripwire --continue`. Then read the step again.
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard tripwire --continue`. Then read the step again.
 
 Report the outcome of each attempt as it ends, before any repair. The command counts the
 attempts and the repairs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 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>
 ```
 
 Use `passed` only for a proved A2UI surface, `failed` for an attempted proof that failed,
@@ -50,9 +50,9 @@ and `skipped` when the proof could not run.
 To route out and stop:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.26.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.27.0 onboard read feature/stop
 ```
 
 When the proof is recorded, run
-`npx --prefer-offline --yes copilotkit@4.26.0 onboard read feature/complete` with the actual browser-proof
+`npx --prefer-offline --yes copilotkit@4.27.0 onboard read feature/complete` with the actual browser-proof
 outcome.