copilotkit 4.10.0 → 4.10.1

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.10.0 onboard protect
+npx --yes copilotkit@4.10.1 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.10.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.10.1 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.10.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -62,7 +62,7 @@ with one sentence explaining why. Write `None` when it needs none.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.10.1 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 +72,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.10.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.10.0 onboard read feature/a2ui/implement`.
+Then run `npx --yes copilotkit@4.10.1 onboard read feature/a2ui/implement`.

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

@@ -0,0 +1,70 @@
+# 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.
+
+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.
+
+On Teams, skip Slack-only tools and the Slack e2e harness. Do not add a CopilotKit
+web app to make this intent 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.
+
+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.
+
+After validation and each repair, run:
+
+```text
+npx --yes copilotkit@4.10.1 onboard audit
+```
+
+Continue only when it starts with `Status: passed`. A path under `Authorized to change:` 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
+with the implementation subagent's `Files changed` section. If that section does not name
+the path, accept the developer's external change:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --accept-external --path <path>
+```
+
+For an env file where the developer placed a requested credential, use
+`onboard protect --accept-credential --path <path>` instead. If the subagent names the path,
+or its report does not settle who changed it, ask the developer to allow the unplanned
+change. Only after they agree, record their answer:
+
+```text
+npx --yes copilotkit@4.10.1 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.10.1 onboard read feature/stop
+```
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.10.1 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.10.1 onboard read feature/channels/proof`.

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

@@ -0,0 +1,60 @@
+# Prove a real mention reply on the chosen provider
+
+Delegate proof to a fresh subagent. Confirm `channels add` completed,
+`channels status` is clean, and the named Channel is `online`. Then require a real
+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.
+
+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
+defects and repeat.
+
+If a gate cannot run, do not complete this run. Name the gate. Use the feature stop
+route after the audit rules below.
+
+Report each attempt at the proof as it ends, counting from one:
+
+```text
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+After the final attempt, report the gate exactly once:
+
+```text
+npx --yes copilotkit@4.10.1 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 could not run. Then run `npx --yes copilotkit@4.10.1 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
+with the proof subagent's `Files changed` section. If that section does not name the path,
+run `onboard protect --accept-external --path <path>`, or
+`onboard protect --accept-credential --path <path>` for an env file where the developer
+placed a requested credential. If the subagent names the path, or its report does not settle
+who changed it, ask the developer to allow it. Only after they agree, run
+`onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"`.
+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.10.1 onboard read feature/stop
+```
+
+When the audit passes and the mention proof passed, run
+`npx --yes copilotkit@4.10.1 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.
+
+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

@@ -0,0 +1,87 @@
+# Add a managed Channel for Slack or Microsoft Teams
+
+First, report your coding agent identity using the same command as generic onboarding:
+
+```text
+npx --yes copilotkit@4.10.1 onboard identify --coding-agent <coding-agent-slug>
+```
+
+Use your own product's slug, such as `codex` or `claude-code`. This also covers entry
+commands that omit `--coding-agent`. It needs no login, browser, or project setup.
+
+Treat Slack or Teams as the UI for this intent. A CopilotKit web app is not required.
+Empty folders, agent-only folders, and existing CopilotKit apps are all valid starts.
+Orchestrate with separate read-only, implementation, and proof subagents, each
+restricted to the target project.
+
+Before any subagent or project process runs, capture the developer's existing work:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+approved authorization before implementation.
+
+Before changing files, send a short welcome. Say you will inspect the project, ask
+Slack or Teams, show a Channel plan, implement only after approval, and prove a real
+mention reply. Then ask Slack or Teams as its own question.
+
+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
+normal test/dev commands. It must return paths and secret-safe presence checks only.
+
+Do not stop because the project has no CopilotKit web app. Do not send a missing web
+app to the feature stop path. Other feature intents still need a CopilotKit baseline.
+This one does not.
+
+Wait for the inspection subagent to finish. Then report that the inspection came back:
+
+```text
+npx --yes copilotkit@4.10.1 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:
+
+```text
+npx --yes copilotkit@4.10.1 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
+Retry it a second way if needed.
+
+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.
+
+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.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
+
+```text
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
+```
+
+Then run `npx --yes copilotkit@4.10.1 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.10.0 onboard audit
+npx --yes copilotkit@4.10.1 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to change:` 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.10.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.10.1 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.10.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/chat-suggestions/proof`.
+`npx --yes copilotkit@4.10.1 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.10.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.10.1 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.10.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.10.0 onboard read feature/complete` with the real browser-proof
+`npx --yes copilotkit@4.10.1 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.10.0 onboard protect
+npx --yes copilotkit@4.10.1 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.10.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --yes copilotkit@4.10.1 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.10.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 Do not run login, provision Intelligence, request a credential, replace the agent, or alter
@@ -53,7 +53,7 @@ with one sentence explaining why. Write `None` when it needs none.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.10.1 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 +63,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.10.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.10.0 onboard read feature/chat-suggestions/implement`.
+Then run `npx --yes copilotkit@4.10.1 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.10.0 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>
+npx --yes copilotkit@4.10.1 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

@@ -10,7 +10,7 @@ After the project is selected, settle the container from the terminal.
 When the plan or the repository already names an id, ask about that one id and nothing else:
 
 ```text
-npx --yes copilotkit@4.10.0 learning containers get <id> --json
+npx --yes copilotkit@4.10.1 learning containers get <id> --json
 ```
 
 One call answers it, and no list is needed.
@@ -18,7 +18,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.10.0 learning containers list --json
+npx --yes copilotkit@4.10.1 learning containers list --json
 ```
 
 One call returns at most 500 containers. When `nextCursor` in the result is not null, read
@@ -29,7 +29,7 @@ second container for work the first one already covers.
 Report what the read found before asking anyone anything:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase container-surveyed
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase container-surveyed
 ```
 
 Everything after this waits on a person, so a run that stops past this point stopped on a
@@ -50,7 +50,7 @@ user, so the callback can return a different id per tier or per customer.
 Use a descriptive lowercase hyphenated id of 1-64 characters:
 
 ```text
-npx --yes copilotkit@4.10.0 learning containers create --id <id> --name <name> --json
+npx --yes copilotkit@4.10.1 learning containers create --id <id> --name <name> --json
 ```
 
 An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
@@ -65,7 +65,7 @@ or a guessed id.
 Then report that the container is settled, before any edit:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase container-settled
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase container-settled
 ```
 
 Everything above happens between two prompts, so a run that stopped on a developer who could
@@ -86,13 +86,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.10.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.10.1 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.10.0 onboard audit
+npx --yes copilotkit@4.10.1 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
@@ -103,7 +103,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.10.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.10.1 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -112,24 +112,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.10.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/learning/proof`.
+`npx --yes copilotkit@4.10.1 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.10.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --yes copilotkit@4.10.1 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
@@ -31,24 +31,24 @@ takes its container before its first agent run. So the container starts empty on
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.10.1 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.10.0 onboard audit`. Continue only when it starts with
+`npx --yes copilotkit@4.10.1 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
@@ -63,9 +63,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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.10.0 onboard read feature/complete` with the actual surface
+`npx --yes copilotkit@4.10.1 onboard read feature/complete` with the actual surface
 outcome.

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

@@ -7,7 +7,7 @@ subagents. Work only inside the target project and preserve its existing agent a
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard protect
+npx --yes copilotkit@4.10.1 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -23,7 +23,7 @@ onboarding.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -63,7 +63,7 @@ with one sentence explaining why. Write `None` when it needs none.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -73,7 +73,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.10.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.10.0 onboard read feature/learning/implement`.
+Then run `npx --yes copilotkit@4.10.1 onboard read feature/learning/implement`.

package/onboarding/prompts/feature/open-generative-ui/implement.md

@@ -16,7 +16,7 @@ validation results without secrets.
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard audit
+npx --yes copilotkit@4.10.1 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
@@ -27,7 +27,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.10.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.10.1 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -36,24 +36,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.10.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.10.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.1 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.10.0 onboard read feature/open-generative-ui/proof`.
+`npx --yes copilotkit@4.10.1 onboard read feature/open-generative-ui/proof`.