copilotkit 4.9.2 → 4.9.17

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

@@ -1,65 +1,85 @@
 # Implement and validate the approved plan
 
-Use only the approved plan and the selected documentation URLs. Fetch every URL in one
-step, before you change the project, rather than one after another.
-Do not use remembered CopilotKit instructions.
+Implement every step of the approved plan in plan order, and run the full validation list.
+Do not repeat the full repository inspection.
 
-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.
+Do not change a protected path.
+Do not change a path that overlaps a protected path. Paths overlap when they are equal or
+either path is an ancestor directory on a path-segment boundary. `apps/a` overlaps
+`apps/a/src`, but not `apps/ab`. `app.ts` does not overlap `app.tsx`.
+
+Change only the files and directories the approved plan names as changeable. If the work
+requires a file the plan does not name, stop and return the blocker. Do not run a
+repository-wide formatter.
+
+Before validation, read the protected path list. Inspect the current changed and untracked
+paths. Keep protected paths out of the run path set. Compare every changed path with the
+paths the plan named. Here, a changed path means one in the run path set. If a changed path
+is outside them, return `Status: blocked` before validation. Run the approved validation
+commands one at a time. Fix validation and proof defects only in the paths the plan named.
+
+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.
 
 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.
+release. Do not add details that the fetched documentation omits.
 
-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.
+The documentation supplies the wiring. The project supplies the application. Use that
+wiring in the project's domain. Do not copy an example's agent name, tools, or data.
 
-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.
+Preserve each existing agent and frontend. Add only missing parts and the CopilotKit
+connection. Do not read, show, store, or return secrets. Do not read a file outside the
+project directory: not for a credential, and not for an API question the fetched
+documentation answers. Ask the main coding agent for a missing credential.
+
+An existing `README.md` is the developer's, not this run's. Leave it exactly as you found
+it: not the title, not a section, not a line. Where this run has documentation to write,
+write it to a new file and name that file when you report the result. On an empty project
+the README is the whole of the brief -- the only place the developer said what they
+wanted, and the thing they read this run's result against -- so the rule binds hardest
+where the file looks emptiest.
 
 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.
-
-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.
-
-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,
+integration, user-visible request, runtime behavior, and persistence. Do not replace the
+existing persistence. Change only the approved project selection, CopilotKit dependency
+upgrade, Intelligence runtime wiring, and the approved threads drawer: the drawer belongs
+in that list because the approved plan already named it, not because this step invents a
+new one. After wiring, run the recorded baseline checks and report any regression.
+
+Where the plan names a CopilotKit dependency upgrade:
+
+1. Apply the planned CopilotKit dependency upgrade before you wire Intelligence.
+2. Report each `@copilotkit/*` version before and after the upgrade.
+3. Then re-run the recorded baseline checks.
+
+If the baseline regresses, restore the manifest and lockfile to their recorded state, leave
+Intelligence unwired, and report the regression with the failing check. Stop. Where the plan
+names no dependency change, report that the installed versions met the floor.
+
+When the documentation uses the framework's 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.
+Do not re-declare a compiler option it set.
+If the plan needs more configuration, 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 documented context API. Tell the agent to refuse to answer about entities the shared
+context does not carry and to name what is missing.
+
+An empty context set is a condition to state rather than an input to work around. Keep
+these two cases apart in the instructions you write. The context set holds no records:
+the answer says the page sent none. The context set holds records and none of them match
+the request: the answer says the request names something the page does not hold, and
+names what the page did send. An agent that runs the two together reads an empty page as
+a page to fill in.
 
-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.
+Where a tool renders one of those records, take every field of the record from the
+context set. A field the model is allowed to fill is a field it fills, so an optional
+field on that tool's schema turns an empty context set into a well-formed record the
+project does not hold, and the rendered result looks the same either way.
 
-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.
+Run the full validation list. Record changed files, command results, and errors. 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,
@@ -69,5 +89,5 @@ Gather what you need in as few commands as possible. Combine independent reads i
 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.
+Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
+Return exactly four sections: Status, Files changed, Validation, and Blockers. Stop.

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

@@ -1,18 +1,41 @@
 # 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
-- any existing agent framework
-- any existing frontend
-- current CopilotKit packages and configuration
+- the target app or runtime directory that owns `.env` and the CopilotKit setup
+- whether the target project directory contains any entries
+- any existing agent framework and frontend
+- current CopilotKit integration and configuration, including whether
+  `.copilotkit/project.json` has `projectId`, `projectSlug`, and `clerkOrgId`
 - authentication boundaries
-- names of required credential variables, without reading their values
+- 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
+  `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
 - declared ports and whether each port is available
+- whether the runtime constructor uses a `runner` option, an `intelligence` option, or
+  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
@@ -28,7 +51,13 @@ 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.
-Do not read, print, or return secret values. Do not read a file outside the project
-directory. Do not run or return another onboarding command. Stop after returning the
-findings to the main coding agent.
+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
+returning the findings to the main coding agent.

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.2 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

@@ -1,25 +1,32 @@
 # Prove the complete round trip
 
-Use the proof steps and documentation URLs from the approved plan. Fetch every selected
-URL in one step before you start, rather than one after another.
-Do not use remembered CopilotKit instructions.
+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
 a browser or device tool writes to a location of its own, keep that location and record
 it instead.
 
-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.
-
 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.
@@ -40,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.
@@ -108,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.2 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.2 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
@@ -137,30 +145,96 @@ 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.
-
-Use the surface control the main coding agent recorded for your environment. Do not add a
-browser driver or a device tool 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 the surface this journey needs, skip this step rather than
-installing one, and report the skip outcome named below.
+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
+nothing here for you to go looking for. Do not add a browser driver or a device tool to this
+project: a devDependency and a browser download land in the diff and tax a repository that
+never asked for one, which is a different thing from the server registered against the
+coding agent. If nothing in your environment can drive the surface this journey needs, skip
+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
-request never exercises. Use a browser MCP server already configured for the coding agent
-you are running as, the same way step 9 configures the CopilotKit documentation MCP
-server.
+request never exercises. Drive it with the browser control step 6 named.
 
 1. Open the frontend URL from step 2 and wait for the page to finish loading.
 2. Take one page snapshot. Record whether the CopilotKit surface is on the page. A page
@@ -171,7 +245,8 @@ server.
    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.
@@ -221,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.2 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.2 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.2",
+  "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 ? "e432fd161b9114fb15080dbd9d9208e29f5e8960" : "main";
+  return true ? "f08f478cf73c46d34e8db03dedcc61f695f9b9b5" : "main";
 }
 
 // apps/cli/src/services/agentcore-config.ts