copilotkit 4.9.4 → 4.9.17

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

@@ -1,6 +1,10 @@
 # Inspect the repository
 
-Inspect the repository without changing it. Find evidence for:
+Work only on the packet you were assigned. Inspect the repository without changing it.
+
+## Project evidence packet
+
+Find evidence for:
 
 - what the project is for, in the project's own words
 - the target app or runtime directory that owns `.env` and the CopilotKit setup
@@ -9,8 +13,18 @@ Inspect the repository without changing it. Find evidence for:
 - current CopilotKit integration and configuration, including whether
   `.copilotkit/project.json` has `projectId`, `projectSlug`, and `clerkOrgId`
 - authentication boundaries
+- initial changed and untracked paths, without file contents
+
+Return the initial changed and untracked paths as paths only. Do not return their
+contents. Do not retain a before-state for them. The CLI captures the baseline that the
+protected-path audit compares against, so nothing later in the run depends on this
+subagent still existing, and a path that can hold secrets is captured as a digest you
+never read.
+
+## Environment evidence packet
+
 - names of required credential variables and whether `.env` has a non-empty
-  `INTELLIGENCE_API_KEY`
+  `CPK_INTELLIGENCE_API_KEY`
 - retain the `.env` modification time for a later comparison without returning it
 - package manager and lockfile
 - required toolchains and their installed versions
@@ -19,6 +33,9 @@ Inspect the repository without changing it. Find evidence for:
   neither can be proved from project files
 - CopilotKit package versions and package compatibility risks
 
+Key every environment finding by its app or runtime directory. Do not combine findings
+from different directories.
+
 For the CopilotKit versions, report the exact installed version of every `@copilotkit/*`
 dependency, read from the lockfile rather than a manifest range, and state whether any of
 them is below 1.64.0. The conversion decides its upgrade from exactly that, and a caret
@@ -34,7 +51,12 @@ command rather than running them one at a time. Split a command only when its re
 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.
+Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
+Use `Status: passed` when the assigned inspection completed, even when a row is `absent` or
+`unproved`. Use `Status: failed` for an inspection error. Use `Status: blocked` when project
+access or an environment limit prevents the inspection.
+Return one row for each assigned item with its status, evidence path, and a short finding.
+Use only `proved`, `absent`, or `unproved` for the status. State each absent or unproved item.
 Do not read, print, or return secret values. For `.env` and `.copilotkit/project.json`
 checks, return only paths, presence checks, and missing field names. Do not read a file
 outside the project directory. Do not run or return another onboarding command. Stop after

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.4 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --yes copilotkit@4.9.17 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
@@ -32,4 +32,5 @@ The default in-memory OSS runner is ephemeral. SQLite, custom, or framework pers
 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.
 
+Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
 Stop after returning the baseline result, process ids and ports used, and evidence paths.

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

@@ -3,11 +3,24 @@
 Use the proof steps and documentation URLs from the approved plan. Follow the documentation
 policy the main coding agent gives you before you start.
 
+During Steps 1 through 8, do not edit source files, configuration files, dependencies, or
+tracked files.
+You can make only operational repairs to project-owned processes, ports, and request options.
+Do not write a path that overlaps a protected path. If a required proof or tool path
+overlaps one, return `Status: blocked` before writing it.
+
 Run the steps below in the order they appear. They are the proof. Do not design a
 different sequence of your own, and do not drop a step because an earlier one looked
 convincing. Step 6 has a web form and a React Native form: run the one that matches this
 journey's frontend, and run only that one.
 
+Where this is a second attempt after a repair, run every step from Step 2 through Step 7
+again. The repair changed tracked files and restarted processes, so the wiring, the agent
+identity, and both preconditions are stale. Step 1 is the exception, and it is carried
+rather than derived a second time. Compare the Step 5a and Step 5b results against the
+failed attempt's before you drive the surface. A repair that leaves the failed precondition
+unchanged has not reached the cause, and that is readable before the most expensive step.
+
 Record the result of every step as you go. A step with nothing recorded did not happen.
 Write each captured file to `.copilotkit/proof/` inside the project and name the path in
 the record. That directory holds regenerable evidence rather than application code. Where
@@ -34,6 +47,11 @@ Where the plan named no request, write one that produces the outcome the plan na
 record the request you wrote. Every later step uses these words unchanged, so that the
 browser, the device, and the grounding check all speak about one request.
 
+Where the handoff carries a pinned Step 1 record from a failed attempt, that record is this
+step. Use its request words, expected agent id, entity list, and runtime URL unchanged, and
+do not write a new request. A second attempt that asks a different question proves nothing
+about the failure it was spawned to clear.
+
 ## Step 2 -- Start the agent and the frontend
 
 Read the port the developer's agent already serves from this project's own configuration.
@@ -102,27 +120,23 @@ IPv6 only, so an IPv4 literal fails against the correct port.
 ## Step 4 -- Check the wiring
 
 With both running, check the wiring in one command before you open a browser:
-`npx --yes copilotkit@4.9.4 verify --json`. Add `--runtime-url` when the runtime is not at
+`npx --yes copilotkit@4.9.17 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
-costs a round of debugging to reach an answer this command already gave.
-
-Treat `intelligence_consumed` as the check that matters most here. A journey that finishes
-with the Intelligence credential never read looks complete and proves nothing about the
-paid surface. `api_key_authenticates` passing beside it says the key is real and the
-runtime never used it.
-
-`intelligence_thread_routes` fails when the runtime reports a license but serves no
-thread routes, which means saved Threads cannot load in a browser. The usual cause is a
-handler mounted `mode: "single-route"`: remove that option so the handler serves its full
-route set, and mount it at a catch-all route. If instead that check is `undetermined`
-because the runtime reports no thread-endpoint state, the runtime predates the field.
-Record that and move on -- there is nothing to repair.
+alone: a check reported `undetermined` did not run, and that is not a pass. Repair a failed
+check only within the limits above. Otherwise, return the check and its evidence before the
+browser.
+
+Treat `intelligence_consumed` as the check that matters most here. It proves that the runtime
+used the Intelligence credential. `api_key_authenticates` proves only that the key is valid.
+
+`intelligence_thread_routes` fails when a licensed runtime serves no thread routes. A handler
+mounted `mode: "single-route"` is the usual cause. Return it for implementation to remove the
+option and use a catch-all route. Do not edit it. If the check is `undetermined` because no
+thread-endpoint state exists, the runtime predates the field. Record that and continue.
 
 ## Step 5 -- Prove that the agent runs
 
-Run `npx --yes copilotkit@4.9.4 verify --round-trip --json`. It sends one request through
+Run `npx --yes copilotkit@4.9.17 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
@@ -131,15 +145,75 @@ it again, because an auth-gated app refusing an unauthenticated caller is that a
 working. Do not continue until this passes, and never report a round trip proven without
 it.
 
+### Step 5a -- Prove that the page's data reaches the model
+
+`verify --round-trip` sends `context: []` and asks a question that needs no context. It
+passes against an agent the page's data never reaches, and that is the right job for an
+install check. Nothing else before the browser reads that path, so a page whose data the
+agent never sees answers fluently over a record it invented, and the first thing to notice
+is a card in a screenshot.
+
+Where this journey shares page data with the agent, prove that path here. Read the context
+entries this project's frontend publishes, from its own context call. Read the tool
+declarations it registers as well, and carry both the way the page carries them, so that
+the agent sees the request the browser sends rather than a thinner one. Send the same run
+body twice, to `<runtime>/agent/<agent id>/run`: once carrying the context entries the page
+publishes, and once carrying `context: []`. Use the step 1 request both times. Record the
+streamed events from each, and name both capture paths.
+
+Read the two answers against each other. The run carrying the page's context has to name
+the project's own records. The run carrying an empty context has to say the page sent
+nothing. Two answers that describe the same record mean the context changed nothing, and
+the page's data is not reaching the model.
+
+Return the cause and both captures on a failed comparison. Do not open a browser on a
+failed comparison, and do not edit the project here.
+
+Where this journey shares no page data with the agent, record that and continue.
+
+### Step 5b -- Prove that the plan's component is wired to a tool call
+
+The plan ends at a component this frontend registers itself, through `useComponent` or
+Angular's `registerComponent`. Both declare a tool from the frontend and forward it to the
+agent in the run body, so the component paints only where three things line up: the
+frontend registers the name, the run carries the declaration, and the agent calls it.
+
+Nothing reports a gap between them. A tool call the frontend registers no component for
+paints an empty message, and a generative-UI payload naming a surface or a catalog the
+frontend does not know falls to a surface nothing draws. Neither writes anything to the
+browser console, so the browser step reports a finished turn, a blank card, and no error
+to read.
+
+Read the registrations this project's frontend declares, by name. Send the step 1 request
+to the route step 5a used, carrying those declarations, and read the tool calls out of
+that run's own events. The agent has to call one of the names the frontend registered. An
+agent that calls nothing, or calls a name no registration matches, is a wiring gap for
+implementation to close rather than a proof repair. Return the name and the frontend file
+you read, before the browser.
+
+Where this journey renders a tool the agent owns rather than one the frontend declares,
+pair the called names against the frontend's renderers the same way. For A2UI, also
+compare the catalog id this project's provider registers with the catalog id the agent's
+payload names. Record every pair you matched.
+
 ## Step 6 -- Drive the surface
 
 Now send one real request through the running frontend, on this journey's own surface.
 Make sure that the request passes through CopilotKit and reaches the selected agent, and
-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.
+that the frontend renders the plan's component through this frontend's own registration --
+the `useComponent` hook, or Angular's `registerComponent` -- over entities the project
+holds. Streamed text alone is not this step's outcome, whatever it says.
+
+This is the step that covers realtime delivery, the frontend provider being wired to this
+runtime, and the 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.
+
+For a recorded `both-oss` starting state, this step has no component to render. Send the
+same request the baseline recorded, require the same kind of user-visible result the
+baseline produced, and require that the thread for that request is listed in the drawer.
+Where this journey's frontend framework ships no threads drawer -- React Native --, find
+that thread in the managed Intelligence dashboard and record which of the two you proved.
 
 Use the surface control the main coding agent recorded for your environment. It either had
 one already or registered one before this step, so that finding is the answer and there is
@@ -151,6 +225,12 @@ this step rather than installing one, and report the skip outcome named below.
 
 Never report a result you did not see, on either surface.
 
+A rendered result is not proof yet. Record this step's outcome after step 7 has compared
+that result with the project's own data, not before: a card nothing compared is a card
+whose fields nobody has read. Where that comparison fails and sends you back to a cause,
+the attempt that failed it is `failed` and stays in the record with its own capture,
+under a name that says what it was.
+
 ### Step 6a -- Web frontends: React SPA, Next.js, Angular, Vue 3
 
 The surface is a browser, and it also covers browser-origin CORS and CSP, which a CLI
@@ -165,7 +245,8 @@ request never exercises. Drive it with the browser control step 6 named.
    submit it.
 5. Wait for the assistant turn to finish rather than for a fixed number of seconds. The
    turn is finished when the streamed text stops growing and the generative UI component
-   has rendered.
+   has rendered. For a recorded `both-oss` starting state, this step has no component, and
+   the turn is finished when the streamed text stops growing.
 6. Take one screenshot of the finished turn and record where you wrote it.
 7. Read the browser console a second time, and record every error that step 3 did not
    already list. Those belong to the request.
@@ -215,32 +296,60 @@ instead, and do not invent a comparison to pass this step.
 An answer that renders correctly over entities the project does not hold looks the same as
 a correct one in a browser, in a screenshot, and in a video, so this comparison is the only
 stage that separates them. An answer that names an entity the project does not hold is a
-failed proof, not a passing one. Find which of these it is before you change anything: the
-project's data never reaches the agent, the agent receives it and its instructions ignore
-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.
+failed proof, not a passing one.
+
+An empty context set is the first case to rule out. Where the context the agent received
+held no records, the answer had to say so, and a rendered record over an empty context set
+is a fabrication rather than a near miss: the card is well formed, the prose reply agrees
+with it, and nothing in the answer marks the gap.
+
+Find which of these it is before you change anything: the project's data never reaches the
+agent, the agent receives it and its instructions ignore it, the page loads its data after
+the context was registered, or the run wired a different source than the page renders.
+Return the cause and its evidence. Do not edit it during proof.
 
 ## Step 8 -- Compare with the recorded OSS baseline
 
 Run this step only 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.
+with the recorded OSS baseline against the criterion the conversion prompt froze. 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. A thread for that request must be persisted and visible. Record both
+before and after evidence, and record that the criterion was `conversion-v1`.
+
+For every other starting state, record Step 8 as not applicable.
+
+The application edit ban ends only after Step 8 passes or is recorded as not applicable.
+Step 9 can write only the tool files named by its guide.
 
 ## Step 9 -- Set up the continued-development tools
 
 Fetch the continued-development guide from the main coding agent with the proof
 documentation. Try the continued-development tools after the application passes proof.
+
+Tell the developer what the skills install writes into this project before you run it: a
+`.agents/skills` directory holding one folder per CopilotKit skill, linked into
+`.claude/skills`. Both sit in the working tree, so the install shows up in `git status`
+and can land in a commit. You cannot know whether this project keeps those directories in
+version control, so name them before you write them rather than after.
+
 Use it to install the project-scoped CopilotKit Skills.
 Use it to configure the CopilotKit documentation MCP server for the current coding agent.
+That registration goes in the coding agent's own configuration for this project, not in
+the working tree.
 
-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.
+Check whether each install succeeded and record what you found. Record the command result
+for each attempt. Report the Skills result and the MCP result separately from the proof
+result. A tool error does not change the proof result: this journey proved or it did not,
+whatever these two tools did.
 
 ## Step 10 -- Return the result
 
+Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
+Use `Status: passed` when the proof attempt completed with `performed`,
+`skipped-no-browser-tool`, or `skipped-no-device`. The parent records a skip through the
+standard blocked completion route. Use `Status: failed` for a failed proof step. Use
+`Status: blocked` when a safety or access limit stops the attempt before a surface outcome.
 Return the proof or the exact failed step to the main coding agent, together with the
 input, the visible result, the relevant process status, the evidence locations, the
 surface-check outcome, and which surface that outcome speaks for. Do not return secret

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

@@ -17,14 +17,22 @@ are available. Search the broader official CopilotKit documentation before you i
 Mark each step that the selected pages do not prove. Do not treat the documentation gap as
 proof that the requested integration is unsupported.
 
+Before you show the best-effort plan, require this complete packet:
+
+- Name the exact target project directory and protected path list.
+- Define the ordered implementation steps with outcomes and dependencies.
+- Name the exact paths each step changes.
+- Give the full validation command list.
+- Give the ordered proof rules.
+
 After the developer approves the best-effort plan, run
-`npx --yes copilotkit@4.9.4 onboard read fallback/best-effort`.
+`npx --yes copilotkit@4.9.17 onboard read fallback/best-effort`.
 
 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.4 onboard feedback
+npx --yes copilotkit@4.9.17 onboard feedback
 ```
 
 Write the feedback message to the command's standard input, in at most four lines.

package/package.json

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

package/release/release-tool.js

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