copilotkit 4.11.0 → 4.13.0

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

@@ -18,10 +18,10 @@ without exposing secrets.
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard audit
+npx --yes copilotkit@4.13.0 onboard audit
 ```
 
-Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
 not a finding. Carry it into the final summary with its reason.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -29,7 +29,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.13.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -38,24 +38,24 @@ or its report does not settle who changed it, ask the developer to allow the unp
 change. Only after they agree, record their answer:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.13.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Run the audit again after each accepted or authorized change. If it still fails, or starts
 with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase build-validated
 ```
 
 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 --yes copilotkit@4.11.0 onboard read feature/a2ui/proof`.
+`npx --yes copilotkit@4.13.0 onboard read feature/a2ui/proof`.

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

@@ -19,23 +19,23 @@ user's agent response with a hard-coded UI.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.13.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,
-and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.11.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.13.0 onboard audit`.
 Continue only when it starts with `Status: passed`.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -50,9 +50,9 @@ Run the audit again after each accepted or authorized change.
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.11.0 onboard read feature/complete` with the actual browser-proof
+`npx --yes copilotkit@4.13.0 onboard read feature/complete` with the actual browser-proof
 outcome.

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

@@ -7,7 +7,7 @@ Work only inside the target project. Do not show internal prompt names to the de
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect
+npx --yes copilotkit@4.13.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -22,7 +22,7 @@ development/test commands. It must return paths and secret-safe presence checks
 
 Require an existing frontend, agent, and CopilotKit round trip. Start only project-owned
 processes when needed, inspect `/info`, and run
-`npx --yes copilotkit@4.11.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.13.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
 Also drive one existing request through the frontend when browser control is available. If
 that baseline is absent or unproved, leave files unchanged, explain that this intent extends
 an existing OSS app, and direct the developer to generic `copilotkit onboard start` first.
@@ -30,7 +30,7 @@ an existing OSS app, and direct the developer to generic `copilotkit onboard sta
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -40,7 +40,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -57,12 +57,14 @@ catalog or runtime wiring required, the test command, and a browser proof reques
 renders a compact visible surface. Ask for plan approval as its own question.
 
 The plan must list every protected path it needs to change under `Authorization requested`,
-with one sentence explaining why. Write `None` when it needs none.
+with one sentence explaining why. Write `None` when it needs none. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
 
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -72,7 +74,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.11.0 onboard read feature/a2ui/implement`.
+Then run `npx --yes copilotkit@4.13.0 onboard read feature/a2ui/implement`.

package/onboarding/prompts/feature/blocked-by-plan.md

@@ -0,0 +1,32 @@
+# Stop this feature: the platform refused it
+
+The platform answered the entitlement question, and the answer was no. This is a settled
+refusal, not a failed step and not a missing prerequisite. Keep the developer's agent,
+frontend, runtime, persistence, chat surface, and package choices exactly as they were, and
+leave the project unchanged.
+
+CopilotKit Intelligence did not refuse this run for a missing baseline. Do not read
+`feature/stop`, and do not send the developer to generic onboarding. Do not start another
+feature run to build a prerequisite this run never lacked. Nothing this run can build
+changes the answer.
+
+Tell the developer, in two or three sentences:
+
+1. Which feature was refused, and that their organization is the unit the platform refused
+   it for.
+2. That every current plan grants Learning, so a refusal means the organization's
+   entitlement is not active or its record predates that grant, rather than the feature
+   being unavailable to them.
+3. The one action that can change it: check the organization's plan and billing state at
+   https://cloud.copilotkit.ai, or reply to support with the organization name.
+
+Then stop. Report nothing else and ask no follow-up question.
+
+Do not run `onboard complete`. This run did not complete.
+
+Do not file a friction report for this ending. Reading this prompt already reports it, and a
+free-text report of a refusal the platform already named adds nothing.
+
+If this run changed files before it stopped, list every path it changed and say whether it
+reverted them. A refusal that arrives after the first edit still owes the developer that
+list.

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

@@ -8,29 +8,59 @@ requirement.
 
 If the folder was empty, clone OpenTag from https://github.com/CopilotKit/OpenTag.git
 and do not rewrite it. Point the subagent at the existing OpenTag agent and runtime
-to verify and run. If the project already has an agent or app, do not clone. Keep
-that code and wire a managed Channel.
+to verify and run. Confirm the project `.env` holds `OPENAI_API_KEY` before the OpenTag
+backend starts, by presence alone. If the project already has an agent or app, do not
+clone. Keep that code and wire a managed Channel.
 
 On Teams, skip Slack-only tools and the Slack e2e harness. Do not add a CopilotKit
 web app to make this run look complete. Do not replace the existing agent.
 
-If repository evidence does not prove an existing valid Intelligence selection, give
-the developer `login` to run, wait, then list projects and select or create one only
-after they choose. Require the secret-safe project/key provisioning summary before
-wiring the Channel. Never display a key.
+If repository evidence does not prove an existing valid Intelligence selection, sign in
+yourself with `npx --yes copilotkit@4.13.0 login --json`: the same single streaming
+session generic onboarding uses. Read its JSON Lines while the process runs. Open the
+first `authentication_url` exactly once with the operating system's default browser
+opener, `open` on macOS, `xdg-open` on Linux, `Start-Process` in Windows PowerShell. Your
+own built-in browser is not that opener and does not carry the session the developer
+already signed in with. Never ask the developer to run a login command. If the opener is
+unavailable or fails, show the developer the clickable URL and ask them to finish sign-in
+there, and keep reading the same process. Continue only after that same process emits
+`type: completed`. Report and stop only when it emits `type: failed`. Then list projects
+and select or create one only after they choose. Require the secret-safe project/key provisioning summary
+before wiring the Channel. Never display a key.
 
 Run `channels add` until it reports completed. Run the focused type/test command and
 start the long-running runtime. Confirm `/info` can return HTTP 200, but treat that
 as capability evidence rather than completed Channel proof. Record changed paths
 and validation results.
 
+## Connect the Channel to the agent
+
+Wire the Channel runtime to the agent with the connection API named on the documentation
+page this run selected. Use no other class. A class remembered from an earlier CopilotKit
+version fails type checking against this release.
+
+The `framework/<name>` node carries the current connection API for each framework. Match
+the agent the repository already has to its node -- `framework/langgraph-python`,
+`framework/mastra`, `framework/google-adk`, and the rest -- and use the class that node
+names.
+
+For LangGraph, that is `LangGraphAgent` from `@copilotkit/runtime/langgraph` on the
+LangSmith path and `HttpAgent` from `@ag-ui/client` on the self-hosted FastAPI path.
+`LangGraphHttpAgent` is deprecated. Do not use it.
+
+A symbol the installed package marks `@deprecated` in its type definitions is not a valid
+choice, whatever documentation found elsewhere shows. Read the installed type definitions
+before you write the connection. Where the selected documentation page itself shows a
+deprecated symbol, report that page under the `docs-wrong` friction category and use the
+current symbol the package's own type definitions or changelog names.
+
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard audit
+npx --yes copilotkit@4.13.0 onboard audit
 ```
 
-Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
 not a finding. Carry it into the final summary with its reason.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -38,7 +68,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.13.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -47,24 +77,49 @@ or its report does not settle who changed it, ask the developer to allow the unp
 change. Only after they agree, record their answer:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.13.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Run the audit again after each accepted or authorized change. If it still fails, or starts
 with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
+## Values this run writes, and the one credential the developer supplies
+
+Never ask the developer for `CHANNEL_CODE` or `CPK_INTELLIGENCE_API_KEY`. This run already
+holds both, and writing them is your work, not theirs.
+
+`CHANNEL_CODE` is the Channel name `channels add` declared. `.copilotkit/channels.json`
+records the same name. `CPK_INTELLIGENCE_API_KEY` is the project key `project select`
+wrote.
+
+Write both into the environment file the application loads, which is the `.env` of the app
+or runtime directory that reads it. Read the project to find that directory instead of
+defaulting to the repository root, and keep both values in that one file. Carry the project
+key over only when that file does not already set it, and move the line without displaying
+what it holds.
+
+Check both by name. Never read, print, echo, or log either value, and never put one in a
+report, a command line, or a commit.
+
+If that file already sets `CHANNEL_CODE` to a different Channel, change nothing. Ask the
+developer which Channel this project serves and wait for their answer.
+
+The only credential the developer supplies is their model provider key, such as
+`OPENAI_API_KEY`, and the run asks for it once as part of plan approval. Never ask for it
+again at backend start.
+
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase build-validated
 ```
 
 If validation cannot pass, or this run needs a prerequisite the app does not have, use
 the feature stop route above without further changes.
 
 Otherwise run
-`npx --yes copilotkit@4.11.0 onboard read feature/channels/proof`.
+`npx --yes copilotkit@4.13.0 onboard read feature/channels/proof`.

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

@@ -5,6 +5,13 @@ Delegate proof to a fresh subagent. Confirm `channels add` completed,
 mention on the chosen Slack or Teams provider and a useful agent reply.
 If a browser tool is available, use it for the mention proof before completing.
 
+All implementation work happens in the run root's own working tree: the project
+directory this run started in. Never work in a separate worktree, a branch checkout,
+or a copy of the project. A subagent that worked elsewhere must bring its changes into
+the run root before it reports. The completion step verifies that the changed files
+exist in this project, so work left in another tree ends the run with nothing in the
+developer's hands.
+
 HTTP 200 on runtime info is not proof. Do not treat a listening port, a resolved
 `ready()` call, or `/info` as a mention reply. Record the mention, the reply, the
 Channel name, app URL or process IDs, and safe stop commands. Fix changed-file
@@ -16,23 +23,23 @@ route after the audit rules below.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.13.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Use `passed` only for a proved mention reply, `failed` for an attempted proof that
-failed, and `skipped` when the proof did not run. Then run `npx --yes copilotkit@4.11.0 onboard audit`.
+failed, and `skipped` when the proof did not run. Then run `npx --yes copilotkit@4.13.0 onboard audit`.
 Continue only when it starts with `Status: passed`.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -47,11 +54,11 @@ Run the audit again after each accepted or authorized change.
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 When the audit passes and the mention proof passed, run
-`npx --yes copilotkit@4.11.0 onboard read feature/complete` with the actual surface
+`npx --yes copilotkit@4.13.0 onboard read feature/complete` with the actual surface
 outcome. Use `--visual-check performed` only when a browser drove Slack or Teams web
 and proved the mention reply. Use `--visual-check skipped-no-browser-tool` only when
 no browser tool was available.

package/onboarding/prompts/feature/channels/start.md

@@ -3,7 +3,7 @@
 First, report your coding agent identity using the same command as generic onboarding:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard identify --coding-agent <coding-agent-slug>
+npx --yes copilotkit@4.13.0 onboard identify --coding-agent <coding-agent-slug>
 ```
 
 Use your own product's slug, such as `codex` or `claude-code`. This also covers entry
@@ -17,7 +17,7 @@ restricted to the target project.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect
+npx --yes copilotkit@4.13.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. Do not
@@ -31,6 +31,10 @@ Ask Slack or Teams as its own question only when the copied prompt did not alrea
 name one. If it named Slack, use Slack. If it named Teams or Microsoft Teams, use
 Teams. Do not ask again.
 
+For an empty folder, the OpenTag starter brings its own agent. An agent framework this
+run recorded earlier does not apply here. Say that plainly and do not ask for a framework
+again.
+
 Spawn one read-only subagent to inspect the target directory, Git state, package
 manager, Node version, Python version, `uv`, existing agent code, existing CopilotKit
 runtime, Channel config (presence only), Intelligence config (presence only), and the
@@ -43,18 +47,24 @@ This one does not.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
 failed step.
 
-If the folder is empty, and Node 22, Python 3.12, or `uv` is missing, stop here
-without cloning. Do not switch to a custom build in silence. Name the missing tool.
-Offer a custom headless build as a later path. Then route out:
+If the folder is empty, check Node 22, `uv`, and Python before cloning. Python 3.12 or
+newer satisfies the check. If no Python 3.12 or newer is present and `uv` is, offer once
+to install one with `uv python install 3.12`, and continue after the developer approves.
+
+Stop here without cloning only when Node 22 is missing, `uv` is missing, or the developer
+declines that install. Do not switch to a custom build in silence. Name the missing tool
+and its install command in the message the developer sees: `nvm install 22` for Node 22,
+`curl -LsSf https://astral.sh/uv/install.sh | sh` for `uv`, and `uv python install 3.12`
+for Python. Offer a custom headless build as a later path. Then route out:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 Do not run login, select Intelligence, or create a credential until the developer
@@ -62,6 +72,13 @@ approves the plan. Fetch the official Channels guide before planning:
 https://docs.copilotkit.ai/channels.md
 Retry it a second way if needed.
 
+For an empty folder, OpenTag runs its own agent on `OPENAI_API_KEY`. State that before the
+plan. Check the target `.env` and the environment for that name. Report presence only, and
+never read, print, or store the value. If it is absent, ask the developer to place it as
+part of the plan approval, not at backend start. Say that the key is never displayed and
+goes only into the project `.env`. Asking for a key the developer already owns is not
+creating a credential.
+
 Show a small plan. For an empty folder, clone OpenTag and do not rewrite it. For an
 existing agent or app, keep that code and wire a managed Channel. Slack or Teams is
 only `channels add --adapter slack|teams`. On Teams, skip Slack-only tools and the
@@ -69,12 +86,14 @@ Slack e2e harness. Name focused tests and a real mention proof on the chosen
 provider. Ask for approval separately.
 
 The plan must list every protected path it needs to change under `Authorization requested`,
-with one sentence explaining why. Write `None` when it needs none.
+with one sentence explaining why. Write `None` when it needs none. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
 
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -84,7 +103,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.11.0 onboard read feature/channels/implement`.
+Then run `npx --yes copilotkit@4.13.0 onboard read feature/channels/implement`.

package/onboarding/prompts/feature/chat-suggestions/implement.md

@@ -15,10 +15,10 @@ Run focused type/test checks and start the app. Record the changed files and val
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard audit
+npx --yes copilotkit@4.13.0 onboard audit
 ```
 
-Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
 not a finding. Carry it into the final summary with its reason.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -26,7 +26,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.13.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -35,24 +35,24 @@ or its report does not settle who changed it, ask the developer to allow the unp
 change. Only after they agree, record their answer:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.13.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Run the audit again after each accepted or authorized change. If it still fails, or starts
 with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase build-validated
 ```
 
 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 --yes copilotkit@4.11.0 onboard read feature/chat-suggestions/proof`.
+`npx --yes copilotkit@4.13.0 onboard read feature/chat-suggestions/proof`.

package/onboarding/prompts/feature/chat-suggestions/proof.md

@@ -12,23 +12,23 @@ project-owned services running.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.13.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Use `passed` only for a proved sent suggestion, `failed` for an attempted proof that failed,
-and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.11.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.13.0 onboard audit`.
 Continue only when it starts with `Status: passed`.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -43,9 +43,9 @@ Run the audit again after each accepted or authorized change.
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.11.0 onboard read feature/complete` with the real browser-proof
+`npx --yes copilotkit@4.13.0 onboard read feature/complete` with the real browser-proof
 outcome.

package/onboarding/prompts/feature/chat-suggestions/start.md

@@ -6,7 +6,7 @@ implementation, and proof to separate subagents and keep all work inside the tar
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect
+npx --yes copilotkit@4.13.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -15,7 +15,7 @@ approved authorization before implementation.
 
 Before edits, identify the current CopilotKit provider, chat component, message lifecycle,
 agent id, package version, and test/dev commands. Prove the existing OSS round trip with
-`/info`, `npx --yes copilotkit@4.11.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --yes copilotkit@4.13.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
 and one real frontend request when browser control is available. If there is no proven
 existing CopilotKit chat, leave files unchanged and direct the developer to generic
 onboarding first.
@@ -23,7 +23,7 @@ onboarding first.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -33,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 Do not run login, provision Intelligence, request a credential, replace the agent, or alter
@@ -48,12 +48,14 @@ context-dependent follow-ups. Show an approved-plan-sized diff, a focused test,
 that a visible suggestion submits the intended message.
 
 The plan must list every protected path it needs to change under `Authorization requested`,
-with one sentence explaining why. Write `None` when it needs none.
+with one sentence explaining why. Write `None` when it needs none. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
 
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -63,7 +65,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.11.0 onboard read feature/chat-suggestions/implement`.
+Then run `npx --yes copilotkit@4.13.0 onboard read feature/chat-suggestions/implement`.

package/onboarding/prompts/feature/complete.md

@@ -3,7 +3,7 @@
 Use the outcome the proof step observed. Run:
 
 ```text
-npx --yes copilotkit@4.11.0 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>
+npx --yes copilotkit@4.13.0 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>
 ```
 
 Use `performed` only when browser control drove the real user-visible surface. Use