copilotkit 4.15.0 → 4.16.0

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 --prefer-offline --yes copilotkit@4.15.0 onboard identify --coding-agent <coding-agent-slug>
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -64,7 +64,7 @@ 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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 Do not run login, select Intelligence, or create a credential until the developer
@@ -94,7 +94,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.16.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
@@ -104,7 +104,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase plan-written
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/channels/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/chat-suggestions/proof`.
+`npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/complete` with the real browser-proof
+`npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase plan-written
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/chat-suggestions/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard complete --visual-check <performed|skipped-no-browser-tool|channels-proof-passed|failed>
+npx --prefer-offline --yes copilotkit@4.16.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
@@ -20,7 +20,7 @@ Before `onboard complete`, send the friction this run mentioned to the developer
 report each, at most four, costliest first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.16.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
 ```
 
 Put one or two sentences in `--message`, with no secrets, source, or logs. Pick the

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 --prefer-offline --yes copilotkit@4.15.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.16.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: 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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 learning containers get <id> --json
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 learning containers list --json
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase container-surveyed
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 learning containers default-id --json
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 learning containers create --id <id> --name <name> --json
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase container-settled
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/learning/proof`.
+`npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard audit`. Continue only when it starts with
+`npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/complete` with the actual surface
+`npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.16.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -38,7 +38,7 @@ status:
   before the capture, the inspection, and any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase plan-written
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/learning/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.16.0 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 --prefer-offline --yes copilotkit@4.15.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.16.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` 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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.16.0 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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/open-generative-ui/proof`.
+`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/open-generative-ui/proof`.

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

@@ -13,23 +13,23 @@ the missing visual proof honestly.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.16.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Use `passed` only for a proved generated UI, `failed` for an attempted proof that failed,
-and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.15.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.16.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
@@ -44,9 +44,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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/complete` with the outcome actually
+`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/complete` with the outcome actually
 observed.

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

@@ -6,7 +6,7 @@ implementation, and proof subagents, all restricted to the target project direct
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.16.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -16,7 +16,7 @@ approved authorization before implementation.
 Before edits, have a research subagent identify the current CopilotKit runtime route,
 provider/chat component, agent id, package versions, existing middleware, sandbox/CSP
 constraints, and normal test/dev commands. Prove the existing app first with `/info`,
-`npx --prefer-offline --yes copilotkit@4.15.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`npx --prefer-offline --yes copilotkit@4.16.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
 and a real frontend request when browser control is available. If the app is not an existing
 OSS CopilotKit app with a proven round trip, change nothing and direct the developer to the
 generic onboarding path first.
@@ -24,7 +24,7 @@ generic onboarding path first.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -34,7 +34,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 Do not sign in, select an Intelligence project, create credentials, change the existing
@@ -56,7 +56,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.16.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
@@ -66,7 +66,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase plan-written
+npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/open-generative-ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/open-generative-ui/implement`.

package/onboarding/prompts/feature/realtime-sync/implement.md

@@ -17,14 +17,14 @@ 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 --prefer-offline --yes copilotkit@4.15.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.16.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record changed paths and secret-safe validation
 evidence.
 
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.16.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -35,7 +35,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.16.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -44,24 +44,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 --prefer-offline --yes copilotkit@4.15.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.16.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 --prefer-offline --yes copilotkit@4.15.0 onboard read feature/realtime-sync/proof`.
+`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/realtime-sync/proof`.