copilotkit 4.10.1 → 4.12.0

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

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

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

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

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

@@ -7,7 +7,7 @@ Work only inside the target project. Do not show internal prompt names to the de
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard protect
+npx --yes copilotkit@4.12.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.10.1 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.12.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.10.1 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.12.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.10.1 onboard read feature/stop
+npx --yes copilotkit@4.12.0 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -57,12 +57,14 @@ catalog or runtime wiring required, the test command, and a browser proof reques
 renders a compact visible surface. Ask for plan approval as its own question.
 
 The plan must list every protected path it needs to change under `Authorization requested`,
-with one sentence explaining why. Write `None` when it needs none.
+with one sentence explaining why. Write `None` when it needs none. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
 
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.12.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -72,7 +74,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.12.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.10.1 onboard read feature/a2ui/implement`.
+Then run `npx --yes copilotkit@4.12.0 onboard read feature/a2ui/implement`.

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

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

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

@@ -12,7 +12,7 @@ to verify and run. If the project already has an agent or app, do not clone. Kee
 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.
+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
@@ -27,10 +27,10 @@ and validation results.
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard audit
+npx --yes copilotkit@4.12.0 onboard audit
 ```
 
-Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
 not a finding. Carry it into the final summary with its reason.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -38,7 +38,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.1 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.12.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -47,24 +47,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.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.12.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.10.1 onboard read feature/stop
+npx --yes copilotkit@4.12.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.12.0 onboard checkpoint --phase build-validated
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, use
+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.10.1 onboard read feature/channels/proof`.
+`npx --yes copilotkit@4.12.0 onboard read feature/channels/proof`.

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

@@ -16,23 +16,23 @@ 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
+npx --yes copilotkit@4.12.0 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
+npx --yes copilotkit@4.12.0 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>
+npx --yes copilotkit@4.12.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 could not run. Then run `npx --yes copilotkit@4.10.1 onboard audit`.
+failed, and `skipped` when the proof did not run. Then run `npx --yes copilotkit@4.12.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 +47,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.10.1 onboard read feature/stop
+npx --yes copilotkit@4.12.0 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
+`npx --yes copilotkit@4.12.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,13 +3,13 @@
 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>
+npx --yes copilotkit@4.12.0 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.
+Treat Slack or Teams as the UI for this run. 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.
@@ -17,16 +17,19 @@ 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
+npx --yes copilotkit@4.12.0 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.
+Keep the exact protected path list it prints and give that list to every subagent. Do not
+write a protected path or an overlapping path unless this run records the approved
+authorization first.
 
-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.
+Before changing files, send a short welcome. Say you will inspect the project, show a
+Channel plan, implement only after approval, and prove a real mention reply.
+
+Ask Slack or Teams as its own question only when the copied prompt did not already
+name one. If it named Slack, use Slack. If it named Teams or Microsoft Teams, use
+Teams. Do not ask 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
@@ -40,7 +43,7 @@ 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
+npx --yes copilotkit@4.12.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -51,7 +54,7 @@ without cloning. Do not switch to a custom build in silence. Name the missing to
 Offer a custom headless build as a later path. Then route out:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard read feature/stop
+npx --yes copilotkit@4.12.0 onboard read feature/stop
 ```
 
 Do not run login, select Intelligence, or create a credential until the developer
@@ -66,12 +69,14 @@ Slack e2e harness. Name focused tests and a real mention proof on the chosen
 provider. Ask for approval separately.
 
 The plan must list every protected path it needs to change under `Authorization requested`,
-with one sentence explaining why. Write `None` when it needs none.
+with one sentence explaining why. Write `None` when it needs none. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
 
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.12.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
@@ -81,7 +86,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.1 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.12.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.10.1 onboard read feature/channels/implement`.
+Then run `npx --yes copilotkit@4.12.0 onboard read feature/channels/implement`.

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

@@ -15,10 +15,10 @@ Run focused type/test checks and start the app. Record the changed files and val
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard audit
+npx --yes copilotkit@4.12.0 onboard audit
 ```
 
-Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
 not a finding. Carry it into the final summary with its reason.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -26,7 +26,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.12.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.10.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.12.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.10.1 onboard read feature/stop
+npx --yes copilotkit@4.12.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.12.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.10.1 onboard read feature/chat-suggestions/proof`.
+`npx --yes copilotkit@4.12.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.10.1 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.12.0 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
+npx --yes copilotkit@4.12.0 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>
+npx --yes copilotkit@4.12.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.10.1 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.12.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.10.1 onboard read feature/stop
+npx --yes copilotkit@4.12.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.10.1 onboard read feature/complete` with the real browser-proof
+`npx --yes copilotkit@4.12.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.10.1 onboard protect
+npx --yes copilotkit@4.12.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.10.1 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --yes copilotkit@4.12.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.10.1 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.12.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.10.1 onboard read feature/stop
+npx --yes copilotkit@4.12.0 onboard read feature/stop
 ```
 
 Do not run login, provision Intelligence, request a credential, replace the agent, or alter
@@ -48,12 +48,14 @@ context-dependent follow-ups. Show an approved-plan-sized diff, a focused test,
 that a visible suggestion submits the intended message.
 
 The plan must list every protected path it needs to change under `Authorization requested`,
-with one sentence explaining why. Write `None` when it needs none.
+with one sentence explaining why. Write `None` when it needs none. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
 
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.12.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -63,7 +65,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.12.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.10.1 onboard read feature/chat-suggestions/implement`.
+Then run `npx --yes copilotkit@4.12.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.10.1 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>
+npx --yes copilotkit@4.12.0 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>
 ```
 
 Use `performed` only when browser control drove the real user-visible surface. Use