copilotkit 4.9.0 → 4.9.1

package/onboarding/prompts/proof/complete.md

@@ -1,13 +1,20 @@
-# Complete onboarding
+# Close out onboarding
 
 Report the selected framework, frontend, model, and complete round-trip evidence to the developer.
 Report the exact interaction, visible result, validation commands, and evidence locations.
 
 Do not complete onboarding without this evidence.
 
-Report whether the real UI was driven in a browser, using the outcome the proof subagent
+Report whether the real UI was driven on this journey's own surface -- in a browser for a
+web frontend, on a device for React Native -- using the outcome the proof subagent
 returned. Do not soften it and do not leave it out: a run that never drove the UI proved
-the agent, not the browser path, and the developer needs to know which they have.
+the agent, not the surface, and the developer needs to know which they have.
+
+**Whether this run is complete is decided by the command at the end of this prompt, not
+here.** Run it before you write the summary, and let its output decide which summary you
+write. A run whose surface was never driven is blocked, not complete: say so in the first
+line, name the evidence the command lists as missing, and do not describe the run as
+finished, working, or ready. Everything else below applies to either outcome.
 
 Report only the project this run worked in. The summary and every report below describe
 that project and nothing else. Do not name or describe a file outside the project
@@ -35,11 +42,12 @@ The handoff must include:
 
 State that the servers remain running after proof.
 
-If the developer permitted external feedback at the start, report each thing that slowed
-this run down. Send at most four reports, worst first:
+Report each thing that slowed this run down. Send at most four reports, worst first. Run
+the friction commands without another developer question. The CLI telemetry gate decides
+whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.0 onboard friction --category <slug> --cost-seconds <seconds>
+npx --yes copilotkit@4.9.1 onboard friction --category <slug> --cost-seconds <seconds>
 ```
 
 Write one or two sentences on the command's standard input. Pick one category from
@@ -53,16 +61,34 @@ a failed step and not a failed onboarding run. Reword it and send it again, or m
 on. A run that proves a round trip is complete whether or not it reported friction.
 
 Tell the developer when you send a friction report. Do not quote or summarize the report
-unless the developer asks. If the developer did not permit feedback, do not run a friction
-command.
+unless the developer asks. If the CLI says that telemetry is disabled or unavailable,
+state that the report was not sent and continue without another question.
+
+When the evidence is gathered, run `npx --yes copilotkit@4.9.1 onboard complete`, carrying
+the surface-check outcome the proof subagent returned. Pass exactly one flag, and pass the
+one that matches this journey's surface.
 
-When the evidence is complete, run `npx --yes copilotkit@4.9.0 onboard complete`, carrying
-the visual-check outcome the proof subagent returned:
+For a web frontend -- React SPA, Next.js, Angular, Vue:
 
 ```text
-npx --yes copilotkit@4.9.0 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.1 onboard complete --visual-check <outcome>
 ```
 
-The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`. The command
-prints what a skipped visual check leaves unverified, so pass the outcome you were given
-rather than the one you wanted.
+The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
+
+For React Native:
+
+```text
+npx --yes copilotkit@4.9.1 onboard complete --device-check <outcome>
+```
+
+The outcome is one of `performed`, `skipped-no-device`, or `failed`.
+
+The two flags are not interchangeable and neither takes the other's outcomes. A browser
+proves nothing about a React Native view tree, and a device capture proves nothing about
+browser-origin CORS, so the flag you pass is how this run states which surface it proved.
+
+Pass the outcome you were given rather than the one you wanted. Anything but `performed`
+prints what the missing check leaves unverified and ends this run as blocked. That output
+is the developer's finding, so carry it into the summary rather than restating it as a
+smaller caveat.

package/onboarding/prompts/proof/oss-baseline.md

@@ -10,11 +10,11 @@ processes and their ignored runtime files is allowed.
 
 If the subagent proves the `both-oss` predicate, keep its evidence with the plan. If it
 proves another supported starting state, record that state. In either case, run
-`npx --yes copilotkit@4.9.0 onboard read credentials/plan`.
+`npx --yes copilotkit@4.9.1 onboard read credentials/plan`.
 
 If it cannot identify the running process safely, exposes a secret, or finds a baseline
 failure that cannot be classified, run
-`npx --yes copilotkit@4.9.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.1 onboard read unsupported/no-validated-path`.
 
 ## Baseline proof subagent brief
 
@@ -40,7 +40,7 @@ Prove the live runtime in this order:
 4. Confirm from project files that the runtime constructor passes a `runner` option rather
    than an `intelligence` option. A package, import, project file, or key is not use proof.
 5. Run
-   `npx --yes copilotkit@4.9.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --yes copilotkit@4.9.1 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
    with the runtime URL or auth header options that this project needs. Require exit zero
    and the JSON `ok` field to be `true`.
 6. Drive one real request through the existing frontend, CopilotKit runtime, and expected

package/onboarding/prompts/proof/round-trip.md

@@ -11,7 +11,7 @@ Give the subagent this guide for continued-development tools:
 https://docs.copilotkit.ai/build-with-agents.md
 
 If the subagent proves the complete round trip, run
-`npx --yes copilotkit@4.9.0 onboard read proof/complete`. The round trip proves core success
+`npx --yes copilotkit@4.9.1 onboard read proof/complete`. The round trip proves core success
 even if a continued-development tool fails. Keep the Skills and MCP results separate from
 the proof result.
 
@@ -21,7 +21,7 @@ the proof subagent to fix and prove again, at most three attempts.
 
 Route out only when the failure is not yours to fix, when the same proof still fails after
 three attempts, or when no evidence of the round trip can be produced. In those cases run
-`npx --yes copilotkit@4.9.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.1 onboard read unsupported/no-validated-path`.
 
 ## Proof subagent brief
 
@@ -52,7 +52,7 @@ safe command that stops that process. Record the frontend URL and the commands t
 both servers again.
 
 With both running, check the wiring in one command before you open a browser:
-`npx --yes copilotkit@4.9.0 verify --json`. Add `--runtime-url` when the runtime is not at
+`npx --yes copilotkit@4.9.1 verify --json`. Add `--runtime-url` when the runtime is not at
 `http://localhost:3000/api/copilotkit`. Read the individual checks rather than the summary
 alone: a check reported `undetermined` did not run, and that is not a pass. Fix anything
 that is not a pass before the browser, because a browser failure stacked on broken wiring
@@ -71,7 +71,7 @@ because the runtime reports no thread-endpoint state, the runtime predates the f
 Record that and move on — there is nothing to repair.
 
 Then prove that the agent actually runs, which is the gate for this node:
-`npx --yes copilotkit@4.9.0 verify --round-trip --json`. It sends one request through the
+`npx --yes copilotkit@4.9.1 verify --round-trip --json`. It sends one request through the
 runtime and reads the answer back from the thread, so it separates an agent that is
 configured from an agent that works. Use `--agent <id>` when the runtime declares more
 than one. If it reports `user-not-identified`, this project's `identifyUser` reads a
@@ -109,20 +109,32 @@ by one.
 Address a local agent by host name rather than by an IP literal. Some local agents bind
 IPv6 only, so an IPv4 literal fails against the correct port.
 
-Drive the real UI in a browser whenever your environment can, and make sure that the
-frontend receives working generative UI from the agent. Prefer this: it is the only step
-that covers realtime delivery to a browser, browser-origin CORS and CSP, the frontend
-provider being wired to this runtime, and a generative UI component actually rendering,
-and no command-line check reaches any of them.
+Drive the real UI on this journey's own surface, and make sure that the frontend receives
+working generative UI from the agent. This is the step that covers realtime delivery, the
+frontend provider being wired to this runtime, and a generative UI component actually
+rendering, and no command-line check reaches any of them. It is not optional polish: a run
+that skips it has proven the agent and not the journey, and the graph ends such a run as
+blocked rather than complete.
 
-Use a browser MCP server already configured for the coding agent you are running as, the
-same way the CopilotKit documentation MCP server below is configured. Do not add a browser
-driver to this project: a devDependency and a browser download land in the diff and tax a
-repository that never asked for one. If nothing in your environment can drive a
-browser, skip this step rather than installing one, and never report a visual result you
-did not see.
+For a web frontend, that surface is a browser, and it also covers browser-origin CORS and
+CSP, which a CLI request never exercises. Use a browser MCP server already configured for
+the coding agent you are running as, the same way the CopilotKit documentation MCP server
+below is configured. Do not add a browser driver to this project: a devDependency and a
+browser download land in the diff and tax a repository that never asked for one. If nothing
+in your environment can drive a browser, skip this step rather than installing one.
 
-Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for this step.
+Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for a web
+frontend.
+
+For React Native, that surface is a device or emulator, and a browser cannot stand in for
+it. Run the app on a booted emulator, drive the same request, and capture the terminal
+state with `adb exec-out screencap -p`. Read `adb logcat` as well: a redbox is a runtime
+failure the terminal output never shows. If no device or emulator is available, skip this
+step rather than substituting a browser.
+
+Report exactly one of `performed`, `skipped-no-device`, or `failed` for React Native.
+
+Never report a result you did not see, on either surface.
 
 Record the input, visible result, relevant process status, and evidence locations. Do not
 return secret values.
@@ -155,4 +167,4 @@ command rather than running them one at a time. Split a command only when its re
 what you run next.
 
 Return the proof or the exact failed step to the main coding agent, together with the
-visual-check outcome. Stop after you return the result.
+surface-check outcome and which surface it speaks for. Stop after you return the result.

package/onboarding/prompts/subagent/inspect-repository.md

@@ -8,6 +8,10 @@ Inspect the repository without changing it. Find evidence for:
 - current CopilotKit packages and configuration
 - authentication boundaries
 - names of required credential variables, without reading their values
+- package manager and lockfile
+- required toolchains and their installed versions
+- declared ports and whether each port is available
+- CopilotKit package versions and package compatibility risks
 
 A project states what it is for in its `README.md`, in its package description, or in
 the prompt of an agent it already has. Quote that statement rather than rewriting it. An
@@ -16,7 +20,8 @@ evidence. State the purpose as unproved when the project never says.
 
 Gather what you need in as few commands as possible. Combine independent reads into one
 command rather than running them one at a time. Split a command only when its result decides
-what you run next.
+what you run next. Keep this preflight read-only. Do not install packages, stop processes,
+or change a port. Check only the toolchains and ports that repository files require.
 
 Return the file paths and a short finding for each item. State each absent or unproved item.
 Do not read, print, or return secret values. Do not read a file outside the project

package/onboarding/prompts/subagent/prove-oss-baseline.md

@@ -16,7 +16,7 @@ Prove the live runtime in this order:
 4. Confirm from project files that the runtime constructor passes a `runner` option rather
    than an `intelligence` option. A package, import, project file, or key is not use proof.
 5. Run
-   `npx --yes copilotkit@4.9.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --yes copilotkit@4.9.1 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
    with the runtime URL or auth header options that this project needs. Require exit zero
    and the JSON `ok` field to be `true`.
 6. Drive one real request through the existing frontend, CopilotKit runtime, and expected

package/onboarding/prompts/subagent/prove-round-trip.md

@@ -21,7 +21,7 @@ safe command that stops that process. Record the frontend URL and the commands t
 both servers again.
 
 With both running, check the wiring in one command before you open a browser:
-`npx --yes copilotkit@4.9.0 verify --json`. Add `--runtime-url` when the runtime is not at
+`npx --yes copilotkit@4.9.1 verify --json`. Add `--runtime-url` when the runtime is not at
 `http://localhost:3000/api/copilotkit`. Read the individual checks rather than the summary
 alone: a check reported `undetermined` did not run, and that is not a pass. Fix anything
 that is not a pass before the browser, because a browser failure stacked on broken wiring
@@ -40,7 +40,7 @@ because the runtime reports no thread-endpoint state, the runtime predates the f
 Record that and move on — there is nothing to repair.
 
 Then prove that the agent actually runs, which is the gate for this node:
-`npx --yes copilotkit@4.9.0 verify --round-trip --json`. It sends one request through the
+`npx --yes copilotkit@4.9.1 verify --round-trip --json`. It sends one request through the
 runtime and reads the answer back from the thread, so it separates an agent that is
 configured from an agent that works. Use `--agent <id>` when the runtime declares more
 than one. If it reports `user-not-identified`, this project's `identifyUser` reads a
@@ -78,20 +78,32 @@ by one.
 Address a local agent by host name rather than by an IP literal. Some local agents bind
 IPv6 only, so an IPv4 literal fails against the correct port.
 
-Drive the real UI in a browser whenever your environment can, and make sure that the
-frontend receives working generative UI from the agent. Prefer this: it is the only step
-that covers realtime delivery to a browser, browser-origin CORS and CSP, the frontend
-provider being wired to this runtime, and a generative UI component actually rendering,
-and no command-line check reaches any of them.
+Drive the real UI on this journey's own surface, and make sure that the frontend receives
+working generative UI from the agent. This is the step that covers realtime delivery, the
+frontend provider being wired to this runtime, and a generative UI component actually
+rendering, and no command-line check reaches any of them. It is not optional polish: a run
+that skips it has proven the agent and not the journey, and the graph ends such a run as
+blocked rather than complete.
 
-Use a browser MCP server already configured for the coding agent you are running as, the
-same way the CopilotKit documentation MCP server below is configured. Do not add a browser
-driver to this project: a devDependency and a browser download land in the diff and tax a
-repository that never asked for one. If nothing in your environment can drive a
-browser, skip this step rather than installing one, and never report a visual result you
-did not see.
+For a web frontend, that surface is a browser, and it also covers browser-origin CORS and
+CSP, which a CLI request never exercises. Use a browser MCP server already configured for
+the coding agent you are running as, the same way the CopilotKit documentation MCP server
+below is configured. Do not add a browser driver to this project: a devDependency and a
+browser download land in the diff and tax a repository that never asked for one. If nothing
+in your environment can drive a browser, skip this step rather than installing one.
 
-Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for this step.
+Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for a web
+frontend.
+
+For React Native, that surface is a device or emulator, and a browser cannot stand in for
+it. Run the app on a booted emulator, drive the same request, and capture the terminal
+state with `adb exec-out screencap -p`. Read `adb logcat` as well: a redbox is a runtime
+failure the terminal output never shows. If no device or emulator is available, skip this
+step rather than substituting a browser.
+
+Report exactly one of `performed`, `skipped-no-device`, or `failed` for React Native.
+
+Never report a result you did not see, on either surface.
 
 Record the input, visible result, relevant process status, and evidence locations. Do not
 return secret values.
@@ -124,4 +136,4 @@ command rather than running them one at a time. Split a command only when its re
 what you run next.
 
 Return the proof or the exact failed step to the main coding agent, together with the
-visual-check outcome. Stop after you return the result.
+surface-check outcome and which surface it speaks for. Stop after you return the result.

package/onboarding/prompts/unsupported/no-validated-path.md

@@ -18,12 +18,13 @@ Mark each step that the selected pages do not prove. Do not treat the documentat
 proof that the requested integration is unsupported.
 
 After the developer approves the best-effort plan, run
-`npx --yes copilotkit@4.9.0 onboard read fallback/best-effort`.
+`npx --yes copilotkit@4.9.1 onboard read fallback/best-effort`.
 
-If the developer permitted external feedback at the start, you can send one short report:
+Send one short report. Run the feedback command without another developer question. The
+CLI telemetry gate decides whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.0 onboard feedback
+npx --yes copilotkit@4.9.1 onboard feedback
 ```
 
 Write the feedback message to the command's standard input, in at most four lines.
@@ -31,5 +32,5 @@ Send no secrets, source code, logs, or command output. The command refuses a rep
 that carries any of those, prints the reason, and exits zero. A refused report is not
 a failed step. Reword it and send it again, or stop without a report. The command
 prints what it sent. This is the channel for a stop. Report friction only from a run that
-finished, never from here. If the developer did not permit feedback, do not run the
-command.
+finished, never from here. If the CLI says that telemetry is disabled or unavailable,
+state that the report was not sent and stop without another question.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "copilotkit",
-  "version": "4.9.0",
+  "version": "4.9.1",
   "type": "module",
   "repository": {
     "type": "git",

package/release/release-tool.js

@@ -14695,7 +14695,7 @@ import * as path4 from "node:path";
 
 // apps/cli/src/config.ts
 function getTemplateRef() {
-  return true ? "bf2068734bcc42b9dc9999b183d0fd07a673f713" : "main";
+  return true ? "2ad03320fe1f0834b138113fffe791781e5b226e" : "main";
 }
 
 // apps/cli/src/services/agentcore-config.ts