copilotkit 4.13.0 → 4.14.0

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.13.0 onboard protect
+npx --yes copilotkit@4.14.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.13.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.14.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.13.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -64,7 +64,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.14.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
@@ -74,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.13.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.13.0 onboard read feature/a2ui/implement`.
+Then run `npx --yes copilotkit@4.14.0 onboard read feature/a2ui/implement`.

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

@@ -1,10 +1,13 @@
 # Implement a managed Channel without rewriting a working agent
 
-Delegate implementation to one subagent with the approved plan and fetched official
-Channels guide. Use the already chosen Slack or Teams adapter only as
-`channels add --adapter slack|teams`. Never read, print, synthesize, or add a secret.
-If a required credential variable is missing, stop with that specific setup
-requirement.
+Delegate implementation to one subagent with the approved plan and fetched connect
+guide. Use the already chosen Slack or Teams adapter only as
+`channels add <name> --adapter slack|teams`. For `<name>`, reuse the Channel
+`.copilotkit/channels.json` already declares. Otherwise use the project's directory or
+package name as 3 to 64 lowercase letters, digits, and single hyphens, starting with a
+letter. Never read, print, synthesize, or add a secret.
+If a required credential variable is missing, name that specific setup requirement and
+take the feature stop route below.
 
 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
@@ -16,16 +19,17 @@ On Teams, skip Slack-only tools and the Slack e2e harness. Do not add a CopilotK
 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, sign in
-yourself with `npx --yes copilotkit@4.13.0 login --json`: the same single streaming
+yourself with `npx --yes copilotkit@4.14.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
+already signed in with. If that record carries `user_code`, show the developer the code to
+check against the sign-in page, which works from any device. 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
+`type: completed`. Only when it emits `type: failed`, report the error and take the
+feature stop route below. 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
@@ -33,6 +37,15 @@ start the long-running runtime. Confirm `/info` can return HTTP 200, but treat t
 as capability evidence rather than completed Channel proof. Record changed paths
 and validation results.
 
+If `channels add` blocks with `slack_app_not_created`, its `Create the Slack app` step,
+open its create-app URL exactly once with the operating system's default browser opener:
+`open` on macOS, `xdg-open` on Linux, `Start-Process` in Windows PowerShell. A long URL is
+printed as a file path. Open the URL that file holds. Tell the developer to create the app
+from the prefilled manifest on that page, install it to the workspace, and finish the
+other steps `channels add` printed. When they are done, run `channels add` again with the
+same name. If the opener is unavailable or fails, show the developer the clickable URL
+instead.
+
 ## Connect the Channel to the agent
 
 Wire the Channel runtime to the agent with the connection API named on the documentation
@@ -54,10 +67,18 @@ before you write the connection. Where the selected documentation page itself sh
 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.
 
+A symbol this graph names is not that case. The `framework/<name>` nodes name the
+current connection API for each framework, and one of them is deprecated at its
+entrypoint while still being the documented path: `LangGraphAgent` from
+`@copilotkit/runtime/langgraph` on the LangSmith route. The CopilotKit quickstart
+writes it, the starters this graph clones are built on it, and its own tooltip
+names no replacement. Write what the framework node names. Do not rewrite a cloned
+starter to satisfy this rule, and do not report the page that shows it.
+
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard audit
+npx --yes copilotkit@4.14.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -68,7 +89,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.13.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.14.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -77,14 +98,14 @@ 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.13.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 ## Values this run writes, and the one credential the developer supplies
@@ -112,14 +133,19 @@ 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.
 
+To add a variable mid-run, such as `PORT` when the Channel's lifecycle server and `next dev`
+both default to 3000, append one line to that env file and change no other line. Then
+accept it with `onboard protect --accept-credential --path <path>`, which accepts an added
+variable while every recorded one keeps its value, and run the audit again.
+
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/channels/proof`.
+`npx --yes copilotkit@4.14.0 onboard read feature/channels/proof`.

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

@@ -23,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.13.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.14.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.13.0 onboard audit`.
+failed, and `skipped` when the proof did not run. Then run `npx --yes copilotkit@4.14.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
@@ -54,14 +54,16 @@ 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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
-When the audit passes and the mention proof passed, run
-`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.
+When the audit passes and the mention proof passed, record it first with
+`onboard proof --step round-trip --outcome passed` as above. Then run
+`npx --yes copilotkit@4.14.0 onboard read feature/complete` and complete with
+`--visual-check channels-proof-passed`. The recorded mention and reply are this run's
+proof, so no web app check is missing. Use `--visual-check performed` only when a
+browser drove Slack or Teams web and proved the mention reply. Do not use
+`skipped-no-browser-tool` here: it reports a web app check this run never needed.
 
 If the mention proof did not pass, or a gate cannot run, use the feature stop
 route above. Do not run `onboard complete`.

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.13.0 onboard identify --coding-agent <coding-agent-slug>
+npx --yes copilotkit@4.14.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.13.0 onboard protect
+npx --yes copilotkit@4.14.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. Do not
@@ -47,7 +47,7 @@ This one does not.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -64,12 +64,13 @@ and its install command in the message the developer sees: `nvm install 22` for
 for Python. Offer a custom headless build as a later path. Then route out:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 Do not run login, select Intelligence, or create a credential until the developer
-approves the plan. Fetch the official Channels guide before planning:
-https://docs.copilotkit.ai/channels.md
+approves the plan. Fetch the connect guide for the chosen provider before planning:
+https://docs.copilotkit.ai/slack/connect.md for Slack,
+https://docs.copilotkit.ai/teams/connect.md for Teams.
 Retry it a second way if needed.
 
 For an empty folder, OpenTag runs its own agent on `OPENAI_API_KEY`. State that before the
@@ -81,9 +82,9 @@ 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
-Slack e2e harness. Name focused tests and a real mention proof on the chosen
-provider. Ask for approval separately.
+only `channels add <name> --adapter slack|teams`, with the project's directory or package
+name as `<name>`. On Teams, skip Slack-only tools and the 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. Authorization covers
@@ -93,7 +94,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.14.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
@@ -103,7 +104,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.13.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.13.0 onboard read feature/channels/implement`.
+Then run `npx --yes copilotkit@4.14.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.13.0 onboard audit
+npx --yes copilotkit@4.14.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.13.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.14.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.13.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/chat-suggestions/proof`.
+`npx --yes copilotkit@4.14.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.13.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.14.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.13.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.14.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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.13.0 onboard read feature/complete` with the real browser-proof
+`npx --yes copilotkit@4.14.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.13.0 onboard protect
+npx --yes copilotkit@4.14.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.13.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --yes copilotkit@4.14.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.13.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.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.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.14.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.13.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.13.0 onboard read feature/chat-suggestions/implement`.
+Then run `npx --yes copilotkit@4.14.0 onboard read feature/chat-suggestions/implement`.

package/onboarding/prompts/feature/complete.md

@@ -3,9 +3,27 @@
 Use the outcome the proof step observed. Run:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>
+npx --yes copilotkit@4.14.0 onboard complete --visual-check <performed|skipped-no-browser-tool|channels-proof-passed|failed>
 ```
 
+Use `channels-proof-passed` for a Slack or Teams run that recorded a passed round-trip proof
+and drove no browser: the provider mention and the reply are the proof. The command refuses
+it when this run recorded no passed round trip.
+
 Use `performed` only when browser control drove the real user-visible surface. Use
 `skipped-no-browser-tool` only when no browser tool was available. Use `failed` when the
 browser proof ran but did not prove the feature.
+
+## Report friction before completing
+
+Before `onboard complete`, send the friction this run mentioned to the developer, one
+report each, at most four, costliest first:
+
+```text
+npx --yes copilotkit@4.14.0 onboard friction --category <slug> --cost-seconds <seconds>
+```
+
+Write one or two sentences on standard input, with no secrets, source, or logs. Pick the
+category from docs-missing, docs-wrong, docs-sequential, cli-gap, sdk-gap, environment,
+port-collision, credential, validation-loop, or other. Mentioning friction without sending
+it leaves this run incomplete.

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.13.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/blocked-by-plan
+npx --yes copilotkit@4.14.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.13.0 learning containers get <id> --json
+npx --yes copilotkit@4.14.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.13.0 learning containers list --json
+npx --yes copilotkit@4.14.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.13.0 onboard checkpoint --phase container-surveyed
+npx --yes copilotkit@4.14.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.13.0 learning containers default-id --json
+npx --yes copilotkit@4.14.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.13.0 learning containers create --id <id> --name <name> --json
+npx --yes copilotkit@4.14.0 learning containers create --id <id> --name <name> --json
 ```
 
 An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
@@ -118,13 +118,13 @@ read with `get` and reuse, not a failure to repair and not a reason to pick a ne
 Confirm the id resolves before any file changes, whichever way it was settled. That check is
 the cheap one to keep: a selector wired to an id the platform does not hold returns
 `LEARNING_CONTAINER_NOT_FOUND` on every thread create and every run lock, so a working chat
-breaks on the next message. Stop here if the id does not resolve. Do not write a placeholder
+breaks on the next message. If the id does not resolve, take the feature stop route below. Do not write a placeholder
 or a guessed id.
 
 Then report that the container is settled, before any edit:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase container-settled
+npx --yes copilotkit@4.14.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.13.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.14.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.13.0 onboard audit
+npx --yes copilotkit@4.14.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.13.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.14.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.13.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.14.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.13.0 onboard read feature/learning/proof`.
+`npx --yes copilotkit@4.14.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.13.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --yes copilotkit@4.14.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.13.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.14.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.13.0 onboard audit`. Continue only when it starts with
+`npx --yes copilotkit@4.14.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.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.13.0 onboard read feature/complete` with the actual surface
+`npx --yes copilotkit@4.14.0 onboard read feature/complete` with the actual surface
 outcome.