copilotkit 4.8.4 → 4.9.0

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

@@ -10,8 +10,10 @@ Wait for the subagent to finish.
 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 and configures the tools, run
-`npx copilotkit@4.8.4 onboard read proof/complete`.
+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
+even if a continued-development tool fails. Keep the Skills and MCP results separate from
+the proof result.
 
 If the round trip fails, decide which kind of failure it is before you route. A failure
 caused by a file this run created or changed is a defect in the new work. Send it back to
@@ -19,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 copilotkit@4.8.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.0 onboard read unsupported/no-validated-path`.
 
 ## Proof subagent brief
 
@@ -33,6 +35,11 @@ Use the proof steps and documentation URLs from the approved plan. Fetch every s
 URL in one step before you start, rather than one after another.
 Do not use remembered CopilotKit instructions.
 
+A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
+not a fact about the page. Retrieve the same URL a second way before you judge it. Run
+`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
+documentation gap only after a second method also fails.
+
 Read the port the developer's agent already serves from this project's own
 configuration. Do not assume a default, and do not start a second copy of an agent this
 project is already running. Before you bind any new server, check that the port is free
@@ -40,8 +47,12 @@ and pick another one if it is not. Record every port you used.
 
 Start the agent and the selected frontend.
 
+Leave the agent and frontend servers running after proof. Record each process ID and a
+safe command that stops that process. Record the frontend URL and the commands that start
+both servers again.
+
 With both running, check the wiring in one command before you open a browser:
-`npx copilotkit@4.8.4 verify --json`. Add `--runtime-url` when the runtime is not at
+`npx --yes copilotkit@4.9.0 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
@@ -60,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 copilotkit@4.8.4 verify --round-trip --json`. It sends one request through the
+`npx --yes copilotkit@4.9.0 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
@@ -72,6 +83,11 @@ it.
 Then send one real request through the frontend. Make sure that the request passes through
 CopilotKit and reaches the selected agent.
 
+For a recorded `both-oss` starting state: Compare the final round trip with the recorded
+OSS baseline. The same frontend request must still reach the same agent and produce the
+same kind of user-visible result. The runtime must now report `licenseStatus`, and the
+authenticated Intelligence checks must pass. Record both before and after evidence.
+
 Before you trust the agent, confirm that the process answering is the one in this
 repository. `verify` reports which agents the runtime declares and has nothing to compare
 them against, and `--round-trip` proves an agent answers under the declared id without
@@ -125,15 +141,14 @@ project's data never reaches the agent, the agent receives it and its instructio
 it, the page loads its data after the context was registered, or the run wired a different
 source than the page renders. Fix that cause, then prove again.
 
-Install the continued-development tools while you drive the round trip, not after it. The
-two are independent, so running them one after the other adds minutes to the journey for
-no reason. Fetch the continued-development guide from the main coding agent at the same
-time as the proof documentation.
+Fetch the continued-development guide from the main coding agent with the proof
+documentation. Try the continued-development tools after the application passes proof.
 Use it to install the project-scoped CopilotKit Skills.
 Use it to configure the CopilotKit documentation MCP server for the current coding agent.
 
-Record the installed Skills and the configured MCP server. If either tool step fails, return
-the exact documentation gap or error.
+Do not validate whether the Skills or MCP server installed correctly. Record the command
+result for each attempt. Report each tool result separately. A tool error does not change
+the proof result.
 
 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

package/onboarding/prompts/subagent/create-plan.md

@@ -4,6 +4,11 @@ Use the selected framework, frontend, model, repository findings, and documentat
 from the main coding agent. Fetch every selected URL in one step rather than one after
 another. Do not use remembered CopilotKit instructions.
 
+A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
+not a fact about the page. Retrieve the same URL a second way before you judge it. Run
+`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
+documentation gap only after a second method also fails.
+
 Name the application the project asks for, and plan that application. Each documentation
 page teaches through one worked example, and that example carries a domain of its own.
 The domain belongs to the page. The project's purpose from the repository findings
@@ -19,11 +24,18 @@ Preserve each agent or frontend that already exists.
 
 Plan the runtime to consume the Intelligence credential. The runtime takes an
 `intelligence` option holding a client built from the project key. A runtime given a
-`runner` option instead is the SSE runtime. It never reads the key, threads are not
-durable, and the Inspector reads the project as locked. The two options cannot be
+`runner` option instead is the OSS runtime. It never reads the Intelligence key, and the
+Inspector reads the project as locked. The default in-memory OSS runner is ephemeral.
+SQLite, custom, or framework persistence can be durable. The two options cannot be
 combined. Take the constructor from the connect-your-runtime page. Where a framework
 quickstart shows a `runner` option instead, the connect-your-runtime page wins.
 
+When the starting state is `both-oss`, use its recorded live baseline evidence. Preserve
+the working agent, frontend, CopilotKit integration, and OSS behavior. Plan only the
+project selection, Intelligence runtime configuration, and authenticated proof needed for
+the conversion. Preserve the existing persistence and user-visible request. Do not
+rebuild a path that already works.
+
 Where the SDK requires an application-level value that the repository cannot supply, such
 as an end-user identity for threads, use one clearly marked local placeholder and name what
 production requires instead. Do not stop onboarding to ask the developer for it.

package/onboarding/prompts/subagent/implement-and-validate.md

@@ -4,6 +4,11 @@ Use only the approved plan and the selected documentation URLs. Fetch every URL
 step, before you change the project, rather than one after another.
 Do not use remembered CopilotKit instructions.
 
+A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
+not a fact about the page. Retrieve the same URL a second way before you judge it. Run
+`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
+documentation gap only after a second method also fails.
+
 Add only the props, options, and imports that appear in the fetched documentation. A
 remembered API from an earlier CopilotKit version will fail type checking against this
 release, so do not decorate a documented example with anything it does not show.
@@ -20,6 +25,11 @@ file outside the project directory: not for a credential, and not for an API que
 fetched documentation answers. A missing credential is the main coding agent's to ask
 for.
 
+For a recorded `both-oss` baseline, preserve the existing agent, frontend, CopilotKit
+integration, user-visible request, and runtime behavior. Do not replace the existing
+persistence. Change only the approved project selection and Intelligence runtime wiring.
+Run the recorded baseline checks after the change and report any regression.
+
 When the documentation creates the frontend with the framework's own scaffolder,
 run that scaffolder rather than hand-authoring what it emits.
 Do not re-declare a compiler option it set. Every real project of that framework

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

@@ -0,0 +1,35 @@
+# Prove the existing OSS CopilotKit baseline
+
+Read and run only inside the project directory. Do not edit source, configuration,
+dependencies, or tracked files. Do not read, show, store, or return secret values.
+
+Find the expected agent id from the project. Start the existing agent and frontend only
+when they are not already running. Before using a port, identify its process and working
+directory. Do not stop a process outside this project.
+
+Prove the live runtime in this order:
+
+1. GET `/info` from the project's CopilotKit runtime and require a valid response.
+2. Require `/info` to declare the expected agent id.
+3. Confirm that `licenseStatus` is absent. Its presence means the live runtime uses
+   Intelligence and is not an OSS starting state.
+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`,
+   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
+   agent. Require the existing user-visible result. If no browser tool is available, the
+   round trip is not proved and the state is `unproved`.
+
+Classify the state as `both-oss` only when all six predicates are true: agent present,
+interface present, CopilotKit present, CopilotKit round trip proven, runtime connection
+`oss`, and managed Intelligence not configured. Return each predicate and its secret-safe
+evidence.
+
+The default in-memory OSS runner is ephemeral. SQLite, custom, or framework persistence
+can be durable. Report the persistence that project evidence proves, or `unproved`. Do not
+replace it and do not describe all OSS runs as ephemeral.
+
+Stop after returning the baseline result, process ids and ports used, and evidence paths.

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

@@ -4,6 +4,11 @@ Use the proof steps and documentation URLs from the approved plan. Fetch every s
 URL in one step before you start, rather than one after another.
 Do not use remembered CopilotKit instructions.
 
+A fetch tool that refuses a URL, or fails to reach it, reports a limit of the tool and
+not a fact about the page. Retrieve the same URL a second way before you judge it. Run
+`curl -fsSL <url>`, or read the same page without the `.md` suffix. Report a
+documentation gap only after a second method also fails.
+
 Read the port the developer's agent already serves from this project's own
 configuration. Do not assume a default, and do not start a second copy of an agent this
 project is already running. Before you bind any new server, check that the port is free
@@ -11,8 +16,12 @@ and pick another one if it is not. Record every port you used.
 
 Start the agent and the selected frontend.
 
+Leave the agent and frontend servers running after proof. Record each process ID and a
+safe command that stops that process. Record the frontend URL and the commands that start
+both servers again.
+
 With both running, check the wiring in one command before you open a browser:
-`npx copilotkit@4.8.4 verify --json`. Add `--runtime-url` when the runtime is not at
+`npx --yes copilotkit@4.9.0 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
@@ -31,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 copilotkit@4.8.4 verify --round-trip --json`. It sends one request through the
+`npx --yes copilotkit@4.9.0 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
@@ -43,6 +52,11 @@ it.
 Then send one real request through the frontend. Make sure that the request passes through
 CopilotKit and reaches the selected agent.
 
+For a recorded `both-oss` starting state: Compare the final round trip with the recorded
+OSS baseline. The same frontend request must still reach the same agent and produce the
+same kind of user-visible result. The runtime must now report `licenseStatus`, and the
+authenticated Intelligence checks must pass. Record both before and after evidence.
+
 Before you trust the agent, confirm that the process answering is the one in this
 repository. `verify` reports which agents the runtime declares and has nothing to compare
 them against, and `--round-trip` proves an agent answers under the declared id without
@@ -96,15 +110,14 @@ project's data never reaches the agent, the agent receives it and its instructio
 it, the page loads its data after the context was registered, or the run wired a different
 source than the page renders. Fix that cause, then prove again.
 
-Install the continued-development tools while you drive the round trip, not after it. The
-two are independent, so running them one after the other adds minutes to the journey for
-no reason. Fetch the continued-development guide from the main coding agent at the same
-time as the proof documentation.
+Fetch the continued-development guide from the main coding agent with the proof
+documentation. Try the continued-development tools after the application passes proof.
 Use it to install the project-scoped CopilotKit Skills.
 Use it to configure the CopilotKit documentation MCP server for the current coding agent.
 
-Record the installed Skills and the configured MCP server. If either tool step fails, return
-the exact documentation gap or error.
+Do not validate whether the Skills or MCP server installed correctly. Record the command
+result for each attempt. Report each tool result separately. A tool error does not change
+the proof result.
 
 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

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

@@ -1,16 +1,29 @@
-# No validated path in this release
+# Stop without a supported path
 
-Stop onboarding without making more repository changes. Keep the developer's current agent,
-frontend, authentication, and package choices.
+Keep the developer's current agent, frontend, authentication, and package choices.
 
 Explain the exact step that failed. State whether authentication, project selection, project
-credentials, the journey, a documentation URL, implementation, validation, or proof caused
-the stop. Do not invent an adapter or claim that an untested path works.
+credentials, the journey, a documentation URL, implementation, validation, or the round
+trip caused the route change. Do not say a path works when this release does not support it.
 
-If useful, send one short report:
+Stop onboarding without making more repository changes by default.
+
+The documentation-gap exception applies only before implementation starts. If implementation,
+validation, or proof already started, do not use the documentation-gap exception.
+
+If the only cause is a failed documentation URL or missing documentation, use the exception.
+Tell the developer about the gap. Then make a best-effort plan from the official pages that
+are available. Search the broader official CopilotKit documentation before you infer an API.
+Mark each step that the selected pages do not prove. Do not treat the documentation gap as
+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`.
+
+If the developer permitted external feedback at the start, you can send one short report:
 
 ```text
-npx copilotkit@4.8.4 onboard feedback
+npx --yes copilotkit@4.9.0 onboard feedback
 ```
 
 Write the feedback message to the command's standard input, in at most four lines.
@@ -18,5 +31,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. Stop after the explanation or optional feedback. This
-unsupported outcome does not complete onboarding.
+finished, never from here. If the developer did not permit feedback, do not run the
+command.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "copilotkit",
-  "version": "4.8.4",
+  "version": "4.9.0",
   "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 ? "47c5510b4909f6728288ecf28d7b14cd14922d33" : "main";
+  return true ? "bf2068734bcc42b9dc9999b183d0fd07a673f713" : "main";
 }
 
 // apps/cli/src/services/agentcore-config.ts