copilotkit 4.9.4 → 4.9.24

package/onboarding/prompts/frontend/angular.md

@@ -5,24 +5,37 @@ Preserve an existing Angular frontend. Use the selected page for a new frontend.
 Use the starter shortcut only if all these facts are true: the target directory contains
 no entries, its name is a valid `init` project name, and the selected framework is ADK.
 If all three facts are true, record Angular as the selected frontend. Then run
-`npx --yes copilotkit@4.9.4 onboard read starter/clone` before you fetch documentation.
+`npx --yes copilotkit@4.9.24 onboard read starter/clone` before you fetch documentation.
 
 ## Documentation
 
 - https://docs.copilotkit.ai/angular.md
 - https://docs.copilotkit.ai/angular/inspector.md
 - https://docs.copilotkit.ai/reference/angular/directives/CopilotKitAgentContext.md
+- https://docs.copilotkit.ai/angular/guides/frontend-tools-generative-ui.md
 
 Take the frontend-context step from the directive page. The agent-framework page shows
 the React hook, and Angular shares the same context through this directive instead.
 Use the Inspector page for proof.
 
+Angular has no `useComponent`. Render the terminal component with `registerComponent` from
+`@copilotkit/angular`, from the generative-UI guide above. The component is an ordinary
+`ToolRenderer`: it takes a required `toolCall` signal input and reads `toolCall().args`.
+The framework page shows the React hook. This function is Angular's equivalent, and the
+two are the same tool to the agent, so nothing changes on the agent side.
+
+`registerComponent` takes no `handler`, because the component only displays. If the
+installed `@copilotkit/angular` does not export it, use `registerFrontendTool` with the
+same `component` and `handler: async () => {}` instead, and record that substitution. Do
+not give the handler a body: a display-only tool that returns a value writes it into the
+thread as the tool's result.
+
 Angular CLI 22 requires Node `^22.22.3 || ^24.15.0 || >=26`. Check the Node version before
 you create or build an Angular project. If the installed version is lower, select a
 supported version first and use it for every later command in this project.
 
 If the pages support the selection, record Angular and these URLs. Then run
-`npx --yes copilotkit@4.9.4 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.24 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/nextjs.md

@@ -15,7 +15,7 @@ These TypeScript options have starters: Claude Agent SDK TypeScript, LangGraph T
 Mastra, and Strands Agents TypeScript. The .NET option is Microsoft Agent Framework .NET.
 
 If all shortcut conditions are true, record Next.js as the selected frontend. Then run
-`npx --yes copilotkit@4.9.4 onboard read starter/clone` before you fetch documentation.
+`npx --yes copilotkit@4.9.24 onboard read starter/clone` before you fetch documentation.
 
 ## Documentation
 
@@ -27,7 +27,7 @@ agent as the default agent, which is correct only for a project that has no agen
 Do not replace the developer's existing agent with the built-in agent.
 
 If the page supports the selection, record Next.js and this URL. Then run
-`npx --yes copilotkit@4.9.4 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.24 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/plan.md

@@ -24,11 +24,11 @@ process.
 
 Use exactly one matching internal route:
 
-1. React SPA: `npx --yes copilotkit@4.9.4 onboard read frontend/react-spa`
-2. Next.js: `npx --yes copilotkit@4.9.4 onboard read frontend/nextjs`
-3. Angular: `npx --yes copilotkit@4.9.4 onboard read frontend/angular`
-4. Vue 3: `npx --yes copilotkit@4.9.4 onboard read frontend/vue`
-5. React Native: `npx --yes copilotkit@4.9.4 onboard read frontend/react-native`
+1. React SPA: `npx --yes copilotkit@4.9.24 onboard read frontend/react-spa`
+2. Next.js: `npx --yes copilotkit@4.9.24 onboard read frontend/nextjs`
+3. Angular: `npx --yes copilotkit@4.9.24 onboard read frontend/angular`
+4. Vue 3: `npx --yes copilotkit@4.9.24 onboard read frontend/vue`
+5. React Native: `npx --yes copilotkit@4.9.24 onboard read frontend/react-native`
 
 If no listed frontend fits, run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/react-native.md

@@ -9,8 +9,13 @@ Preserve an existing React Native frontend. Use the selected page for a new fron
 
 Use the Event Inspector page for proof.
 
+Render the terminal component with `useComponent` from `@copilotkit/react-native`. The
+package re-exports it from react-core, and it behaves as it does on the web. The page also
+documents `useRenderTool`, which is React Native's own hook for drawing a tool the agent
+already has. That is a different job and needs a tool in the agent.
+
 If the pages support the selection, record React Native and these URLs. Then run
-`npx --yes copilotkit@4.9.4 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.24 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/react-spa.md

@@ -11,7 +11,7 @@ not move the agent into it.
 - https://docs.copilotkit.ai/react-spa.md
 
 If the page supports the selection, record React SPA and this URL. Then run
-`npx --yes copilotkit@4.9.4 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.24 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/vue.md

@@ -7,11 +7,16 @@ Preserve an existing Vue 3 frontend. Use the selected page for a new frontend.
 - https://docs.copilotkit.ai/vue.md
 - https://docs.copilotkit.ai/reference/vue/components/CopilotKitProvider.md
 - https://docs.copilotkit.ai/reference/vue/hooks/useAgentContext.md
+- https://docs.copilotkit.ai/reference/vue/hooks/useComponent.md
 
 Use the component page for the provider setup. Use the hook page for frontend context.
 
+Render the terminal component with `useComponent` from `@copilotkit/vue/v2`, from the hook
+page above. Vue has its own `useComponent`, which is not the React package. Take it from
+that reference page rather than from a Vue generative-UI guide, which is not published.
+
 If the pages support the selection, record Vue 3 and these URLs. Then run
-`npx --yes copilotkit@4.9.4 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.24 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/implementation/build-and-validate.md

@@ -1,97 +1,63 @@
 # Implement and validate the plan
 
-Do not implement the plan yourself. Spawn one implementation subagent.
+Do not implement the plan yourself. Use the step order in the approved plan.
 
-Give the subagent the full text of the implementation brief at the end of this prompt, the
-approved plan, selected framework, frontend, model, repository findings, and selected
-documentation URLs. Give it the documentation policy recorded during framework selection.
-Wait for the subagent to finish.
+## Protected-path audit
 
-If all implementation and validation steps pass, run
-`npx --yes copilotkit@4.9.4 onboard read proof/round-trip`.
+Run the audit from the target app directory:
 
-If a validation command fails, decide which kind of failure it is before you route.
+```text
+npx --yes copilotkit@4.9.24 onboard audit
+```
 
-A failure in a file this run created or changed is a defect in the new work, not a limit
-of this release. Fix it and run the same command again. Do not continue to the next step
-until that command passes. Make at most three repair attempts per command.
+It compares every protected path with the digest the CLI captured for it. Its result starts
+with `Status: passed`, `Status: failed`, or `Status: blocked`. The audit passes only when
+the result starts with `Status: passed`.
 
-Route out only when the failure is not yours to fix: the failure is in code this run did
-not write, or the fix requires changing the developer's existing agent or frontend,
-or the same command still fails after three repair attempts, or the documentation does not
-support the plan. In those cases run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`Status: failed` names each protected path that changed and how. If an audit reports a
+changed protected path, use the route-out rules. Never repair, reset, or revert a protected
+path. Also do not retry the audit: it reads files, so a second run of it answers the same.
 
-## Implementation subagent brief
+`Status: blocked` means the audit has no baseline to read. A blocked audit compared
+nothing and proved nothing changed. It is not a preservation failure: do not report a
+protected path as changed. Report the printed reason and use the route-out rules.
 
-Everything below the rule is the subagent's prompt. Give it verbatim.
+A non-pass audit never continues the run. Do not send an audit result to a repair worker.
 
----
+Spawn one implementation subagent. Tell it to run
+`npx --yes copilotkit@4.9.24 onboard read subagent/implement-and-validate` first and follow
+the prompt it returns. If that read fails because the subagent cannot use the shell, stop that
+subagent. Run the same command yourself, then spawn a fresh subagent with the returned prompt
+and the same handoff. Give it the plan, selected framework, frontend, model, exact target app
+directory, selected documentation URLs, and the
+documentation policy recorded during framework selection or conversion planning. On a
+conversion, also give it the frozen criterion. Give it the protected path list. Require it
+to implement every step in plan order and run the full validation list. Wait for it.
 
-# Implement and validate the approved plan
+One subagent implements the whole plan. Do not divide the work across concurrent subagents,
+and do not spawn a second subagent to reconcile a split.
 
-Use only the approved plan and the selected documentation URLs. Follow the documentation
-policy the main coding agent gives you before you change the project.
+If the implementation result does not start with `Status: passed`, do not continue to proof.
+Run the protected-path audit after the implementation subagent passes. If any protected path
+changed, use the route-out rules. Continue to proof only when that audit passes.
 
-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.
+After the selected implementation path passes, run
+`npx --yes copilotkit@4.9.24 onboard read proof/round-trip`.
 
-The documentation supplies the wiring. The project supplies the application. That rule
-governs props, options, and imports, and it stops there. A documentation example names a
-domain of its own to make itself readable. Build what the plan names, in the project's
-own domain, from the wiring the page shows. Do not carry the page's example domain into
-the project: not its agent name, not its tools, not its data.
+## Repair rules
 
-Preserve each agent or frontend that already exists. Add only the missing parts and the
-CopilotKit connection. Do not read, show, store, or return secret values. Do not read a
-file outside the project directory: not for a credential, and not for an API question the
-fetched documentation answers. A missing credential is the main coding agent's to ask
-for.
+If a result starts with `Status: failed`, or a validation command fails, first
+decide which kind of failure it is before you route.
 
-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, the approved CopilotKit
-dependency upgrade, and the Intelligence runtime wiring.
-Run the recorded baseline checks again after the Intelligence wiring and report any
-regression.
+A failure in a file this run created or changed is a defect in the new work. Send it to the
+implementation subagent. Before you run the next command, repeat the failed command. Make at
+most three repair attempts per command. After the repair passes, continue on the same
+implementation path.
 
-Apply the planned CopilotKit dependency upgrade before you wire Intelligence, as its own
-step, and record each version it changed. Then re-run the recorded baseline checks. A
-regression at this point can only be the upgrade, which is why it is checked here rather
-than after the wiring.
+## Route-out rules
 
-If the baseline regresses, restore the manifest and lockfile to their recorded state,
-leave Intelligence unwired, and report the regression with the failing check. A
-half-upgraded project with no working chat is worse than the one this run was given, and
-finishing the wiring on top of a broken baseline hides which change broke it.
-
-Report each `@copilotkit/*` version before and after the upgrade. Where the plan named no
-dependency change, say that the installed versions already met the floor.
-
-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
-inherits those defaults, so a hand-written replacement measures a configuration no
-developer has. Where the plan needs configuration the scaffolder did not write,
-extend the scaffolder's file and set only what you add.
-
-Where the plan names data the project already holds, share that data with the agent
-through the context API the selected documentation names for this frontend. Then write the agent's instructions to
-refuse to answer about entities the shared context does not carry, and to name what is
-missing instead. An agent with no context and no refusal invents plausible entities, and
-no part of the run errors.
-
-Run the validation commands from the approved plan. Record the changed files, command
-results, and each error. Do not claim that the real user journey works in this phase.
-
-Report the runtime constructor you wrote. Name whether it passes `intelligence` or
-`runner`. A runtime built with `runner` is the SSE runtime and never reads the credential,
-whatever the browser shows.
-
-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.
-
-Return the implementation result and validation evidence to the main coding agent. Stop
-after you return the result.
+Route out for `Status: blocked`. Route out only when the failure is not yours to fix: the
+failure is in code this run did not write, the fix requires changing the developer's existing
+agent or frontend, the same command still fails after three repair attempts, or the
+documentation does not support the plan. In those cases run
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/proof/complete.md

@@ -37,15 +37,30 @@ The handoff must include:
 - The URL of the running app.
 - The command that starts the app in the future.
 - The debugging surface this journey's frontend can reach, named below.
-- How to use https://intelligence.copilotkit.ai to manage the Intelligence installation.
+- How to use https://intelligence.copilotkit.ai to manage the Intelligence
+  installation. Do not open it. This item makes the developer aware the dashboard is
+  there, and it is a sentence to write rather than a check to perform. Nothing in this
+  graph gates on the dashboard, so a dashboard this run never opened is not a finding,
+  not a caveat, and not a blocker.
 - The process IDs and stop commands for the running agent and frontend.
 - The `@copilotkit/*` versions this conversion changed, and what they were before.
+- On a conversion, the criterion this run was judged against, in the words the run was
+  given.
+- Any path this run created that git does not ignore, and what to do with each.
+
+A run leaves paths beside the credential file. Tool output such as `.playwright-mcp/` and
+`.langgraph_api/` is regenerable, so the developer normally wants it ignored.
+`.copilotkit/` is not debris: `project.json` and `channels.json` are the project's own
+declared state and belong in the commit, while `.copilotkit/artifacts/` holds regenerable
+manifests and does not. Name each path and say which of the two it is. Do not add an
+ignore line for any of them yourself. None of these carries a secret, unlike the
+credential path, so the developer decides.
 
 Name the debugging surface this journey's frontend can reach, rather than the one the rest
 of the documentation leads with. For a web frontend it is the CopilotKit Inspector. For
 React Native there is no Inspector: it is a browser overlay built on a DOM custom element,
 and `@copilotkit/react-native` does not ship it. Give a mobile developer
-`npx --yes copilotkit@4.9.4 verify --round-trip`, the runtime's own log, the AG-UI
+`npx --yes copilotkit@4.9.24 verify --round-trip`, the runtime's own log, the AG-UI
 Event Inspector in the CopilotKit VS Code extension, and the Intelligence thread view
 instead. Naming the Inspector to a developer who cannot open it costs them the time it
 takes to conclude their own wiring is broken.
@@ -57,7 +72,7 @@ the friction commands without another developer question. The CLI telemetry gate
 whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.4 onboard friction --category <slug> --cost-seconds <seconds>
+npx --yes copilotkit@4.9.24 onboard friction --category <slug> --cost-seconds <seconds>
 ```
 
 Write one or two sentences on the command's standard input. Pick one category from
@@ -74,14 +89,14 @@ Tell the developer when you send a friction report. Do not quote or summarize th
 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.4 onboard complete`, carrying
+When the evidence is gathered, run `npx --yes copilotkit@4.9.24 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.
 
 For a web frontend -- React SPA, Next.js, Angular, Vue:
 
 ```text
-npx --yes copilotkit@4.9.4 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.24 onboard complete --visual-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
@@ -89,7 +104,7 @@ The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
 For React Native:
 
 ```text
-npx --yes copilotkit@4.9.4 onboard complete --device-check <outcome>
+npx --yes copilotkit@4.9.24 onboard complete --device-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-device`, or `failed`.
@@ -107,14 +122,18 @@ If the round trip proved and something after it still blocked this run, add `--b
 to the same command:
 
 ```text
-npx --yes copilotkit@4.9.4 onboard complete --visual-check performed --blocked-by <cause>
+npx --yes copilotkit@4.9.24 onboard complete --visual-check performed --blocked-by <cause>
 ```
 
-The cause is one of `hosted-dashboard` for a managed dashboard that did not load or refused
-a sign-in, `inspector` for a debugging surface that did not open, `plan-excluded-capability`
-for a capability the approved plan had already excluded for this framework, and `other` for
-anything else. Pick `other` rather than leaving the flag off. The command ends the run as
-blocked and prints what the blocker leaves unverified.
+The cause is one of `inspector` for a debugging surface that did not open,
+`plan-excluded-capability` for a capability the approved plan had already excluded for this
+framework, and `other` for anything else. Pick `other` rather than leaving the flag off.
+The command ends the run as blocked and prints what the blocker leaves unverified.
+
+The managed Intelligence dashboard is not among these, because nothing in this graph asks a
+run to open it. A run that records a blocker for a surface it was never sent to looks worse
+than an identical run that wrote the same handoff sentence, and the two are then not
+comparable.
 
 This is the flag for a journey that worked. It is not a way to report an unsupported path,
 and a blocked run here is still owed the full handoff above: the URL, the start command,

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

@@ -1,59 +1,24 @@
 # Prove the existing OSS baseline
 
-Do not prove the baseline yourself. Spawn one proof subagent.
-
-Give the subagent the full text of the baseline brief at the end of this prompt, the
-repository findings, and the exact CLI package spec. Wait for the subagent to finish.
+Do not prove the baseline yourself. Spawn one proof subagent. Tell it to run
+`npx --yes copilotkit@4.9.24 onboard read subagent/prove-oss-baseline` first and follow the
+prompt it returns. If that read fails because the subagent cannot use the shell, stop that
+subagent. Run the same command yourself, then spawn a fresh subagent with the returned prompt
+and the same handoff. Give it the repository findings and exact CLI package spec. Wait for the
+subagent to finish.
 
 Do not change project files before this proof ends. Starting existing development
 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.4 onboard read credentials/plan`.
+If the subagent proves the `both-oss` predicate, keep its evidence with the plan and run
+`npx --yes copilotkit@4.9.24 onboard read conversion/plan`. That project already works.
+What it needs is the conversion, not a build.
+
+If it proves another supported starting state, record that state and run
+`npx --yes copilotkit@4.9.24 onboard read credentials/plan`. This prompt is served
+whenever a project looks like an OSS integration, so a baseline that did not prove is an
+ordinary starting state rather than a failure.
 
 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.4 onboard read unsupported/no-validated-path`.
-
-## Baseline proof subagent brief
-
-Everything below the rule is the subagent's prompt. Give it verbatim.
-
----
-
-# 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.4 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.
+`npx --yes copilotkit@4.9.24 onboard read unsupported/no-validated-path`.