copilotkit 4.12.0 → 4.13.0

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

@@ -8,26 +8,56 @@ 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.12.0 onboard audit
+npx --yes copilotkit@4.13.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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
@@ -76,7 +93,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.12.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
@@ -86,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.12.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.12.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,7 +15,7 @@ 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.12.0 onboard audit
+npx --yes copilotkit@4.13.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.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.12.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.12.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.12.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.12.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.12.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.12.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
@@ -55,7 +55,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.12.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
@@ -65,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.12.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.12.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.12.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

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

@@ -16,7 +16,7 @@ command without another developer question. Do not ask the developer about telem
 command applies the setting they already have.
 
 ```text
-npx --yes copilotkit@4.12.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.13.0 onboard friction --phase stop --category <slug>
 ```
 
 Write one or two sentences to standard input: the step you stopped at and what stopped it.
@@ -41,7 +41,7 @@ settled refusal rather than a missing baseline, so stop here, before any file ch
 take its own ending:
 
 ```text
-npx --yes copilotkit@4.12.0 onboard read feature/blocked-by-plan
+npx --yes copilotkit@4.13.0 onboard read feature/blocked-by-plan
 ```
 
 `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -55,7 +55,7 @@ then, so the read below is where its refusal surfaces.
 When the plan or the repository already names an id, ask about that one id and nothing else:
 
 ```text
-npx --yes copilotkit@4.12.0 learning containers get <id> --json
+npx --yes copilotkit@4.13.0 learning containers get <id> --json
 ```
 
 One call answers it, and no list is needed.
@@ -63,7 +63,7 @@ One call answers it, and no list is needed.
 When no id is in hand, survey what the project holds:
 
 ```text
-npx --yes copilotkit@4.12.0 learning containers list --json
+npx --yes copilotkit@4.13.0 learning containers list --json
 ```
 
 One call returns at most 500 containers. When `nextCursor` in the result is not null, read
@@ -74,7 +74,7 @@ second container for work the first one already covers.
 Report what the read found before asking anyone anything:
 
 ```text
-npx --yes copilotkit@4.12.0 onboard checkpoint --phase container-surveyed
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase container-surveyed
 ```
 
 Everything after this waits on a person, so a run that stops past this point stopped on a
@@ -95,7 +95,7 @@ user, so the callback can return a different id per tier or per customer.
 Ask the CLI for the id rather than spelling one yourself:
 
 ```text
-npx --yes copilotkit@4.12.0 learning containers default-id --json
+npx --yes copilotkit@4.13.0 learning containers default-id --json
 ```
 
 It derives the project-scoped id from the selected project's slug, reads the local project
@@ -109,7 +109,7 @@ run that spells the id differently gives one project two containers, each below
 above on its own. One command is what keeps the two spellings identical.
 
 ```text
-npx --yes copilotkit@4.12.0 learning containers create --id <id> --name <name> --json
+npx --yes copilotkit@4.13.0 learning containers create --id <id> --name <name> --json
 ```
 
 An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
@@ -124,7 +124,7 @@ or a guessed id.
 Then report that the container is settled, before any edit:
 
 ```text
-npx --yes copilotkit@4.12.0 onboard checkpoint --phase container-settled
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase container-settled
 ```
 
 Everything above happens between two prompts, so a run that stopped on a developer who could
@@ -145,13 +145,13 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused tests and
-`npx --yes copilotkit@4.12.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.13.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record secret-safe evidence.
 
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.12.0 onboard audit
+npx --yes copilotkit@4.13.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -162,7 +162,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.12.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
@@ -171,24 +171,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.12.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.12.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.12.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.12.0 onboard read feature/learning/proof`.
+`npx --yes copilotkit@4.13.0 onboard read feature/learning/proof`.

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

@@ -7,7 +7,7 @@ Container. Confirm the thread remains associated with the expected user.
 One command decides it:
 
 ```text
-npx --yes copilotkit@4.12.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --yes copilotkit@4.13.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
 ```
 
 It reads the thread back from the platform, so it answers for any runtime mount, and it
@@ -32,24 +32,24 @@ same threshold. Existing threads do not join automatically just because a contai
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.12.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.12.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.12.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 Container assignment, `failed` for an attempted proof that
 failed, and `skipped` when the proof could not run. Then run
-`npx --yes copilotkit@4.12.0 onboard audit`. Continue only when it starts with
+`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
@@ -64,9 +64,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.12.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.12.0 onboard read feature/complete` with the actual surface
+`npx --yes copilotkit@4.13.0 onboard read feature/complete` with the actual surface
 outcome.

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

@@ -11,7 +11,7 @@ friction command without another developer question. Do not ask the developer ab
 telemetry: the command applies the setting they already have.
 
 ```text
-npx --yes copilotkit@4.12.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.13.0 onboard friction --phase stop --category <slug>
 ```
 
 Write one or two sentences to standard input: the step you stopped at and what stopped it.
@@ -38,7 +38,7 @@ status:
   before the capture, the inspection, and any edit:
 
 ```text
-npx --yes copilotkit@4.12.0 onboard read feature/blocked-by-plan
+npx --yes copilotkit@4.13.0 onboard read feature/blocked-by-plan
 ```
 
 - `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -59,7 +59,7 @@ again: it has no answer, so it carries the question forward rather than ending o
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.12.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
@@ -75,7 +75,7 @@ onboarding.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.12.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
@@ -85,7 +85,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.12.0 onboard read feature/stop
+npx --yes copilotkit@4.13.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -117,7 +117,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.12.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
@@ -127,7 +127,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.12.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.12.0 onboard read feature/learning/implement`.
+Then run `npx --yes copilotkit@4.13.0 onboard read feature/learning/implement`.