copilotkit 4.9.1 → 4.9.4

package/onboarding/prompts/frontend/plan.md

@@ -5,9 +5,9 @@ that the repository does not show. Do not change application code in this phase.
 
 Use a gentle wizard. Ask one short question at a time. Do not combine separate choices in
 one question. Put the recommendation first, give its evidence in one sentence, and keep
-the alternatives short. When the frontend is unknown, ask only whether to use the
-recommended frontend. If the developer declines it, ask one follow-up question that lists
-the valid frontend choices. Do not ask about the model or project in this step.
+the alternatives short. When the frontend is unknown, use this rule: Ask one frontend
+question that lists the recommendation and valid choices. Do not ask a yes-or-no question
+first. Do not ask about the model or project in this step.
 
 If the project has a frontend, preserve it and use the matching route below. If the project
 needs a frontend, show the valid choices and one recommendation based on repository
@@ -22,18 +22,13 @@ CopilotKit runtime lives: Next.js hosts it in a route handler, Angular in its SS
 server, and Vue 3, React SPA and React Native reach a runtime that runs as its own
 process.
 
-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. Treat a page as
-unavailable only after a second method also fails.
-
 Use exactly one matching internal route:
 
-1. React SPA: `npx --yes copilotkit@4.9.1 onboard read frontend/react-spa`
-2. Next.js: `npx --yes copilotkit@4.9.1 onboard read frontend/nextjs`
-3. Angular: `npx --yes copilotkit@4.9.1 onboard read frontend/angular`
-4. Vue 3: `npx --yes copilotkit@4.9.1 onboard read frontend/vue`
-5. React Native: `npx --yes copilotkit@4.9.1 onboard read frontend/react-native`
+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`
 
 If no listed frontend fits, run
-`npx --yes copilotkit@4.9.1 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.

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

@@ -4,21 +4,13 @@ Preserve an existing React Native frontend. Use the selected page for a new fron
 
 ## Documentation
 
-- Credentials and plan: `Not applicable`
-- Implementation and validation: https://docs.copilotkit.ai/react-native.md
-- Proof: https://docs.copilotkit.ai/react-native.md
+- https://docs.copilotkit.ai/react-native.md
+- https://docs.copilotkit.ai/troubleshooting/event-inspector.md
 
-Fetch the selected documentation page. Record React Native as the selected frontend and
-keep this URL. Do not use remembered CopilotKit instructions.
+Use the Event Inspector page for proof.
 
-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. Treat a page as
-unavailable only after a second method also fails.
+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`.
 
-If the page supports the selection, run
-`npx --yes copilotkit@4.9.1 onboard read credentials/finalize-plan`.
-
-If a second method also fails, or the page that loads does not support the selection,
-run
-`npx --yes copilotkit@4.9.1 onboard read unsupported/no-validated-path`.
+If the documentation does not support the selection, run
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.

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

@@ -8,20 +8,10 @@ not move the agent into it.
 
 ## Documentation
 
-- Credentials and plan: `Not applicable`
-- Implementation and validation: https://docs.copilotkit.ai/react-spa.md
-- Proof: https://docs.copilotkit.ai/react-spa.md
+- https://docs.copilotkit.ai/react-spa.md
 
-Fetch the selected documentation page. Record React SPA as the selected frontend and
-keep this URL. Do not use remembered CopilotKit instructions.
+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`.
 
-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. Treat a page as
-unavailable only after a second method also fails.
-
-If the page supports the selection, run
-`npx --yes copilotkit@4.9.1 onboard read credentials/finalize-plan`.
-
-If a second method also fails, or a page that loads does not support the selection, run
-`npx --yes copilotkit@4.9.1 onboard read unsupported/no-validated-path`.
+If the documentation does not support the selection, run
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/vue.md

@@ -4,21 +4,14 @@ Preserve an existing Vue 3 frontend. Use the selected page for a new frontend.
 
 ## Documentation
 
-- Credentials and plan: `Not applicable`
-- Implementation and validation: https://docs.copilotkit.ai/vue.md
-- Proof: https://docs.copilotkit.ai/vue.md
+- https://docs.copilotkit.ai/vue.md
+- https://docs.copilotkit.ai/reference/vue/components/CopilotKitProvider.md
+- https://docs.copilotkit.ai/reference/vue/hooks/useAgentContext.md
 
-Fetch the selected documentation page. Record Vue 3 as the selected frontend and keep
-this URL. Do not use remembered CopilotKit instructions.
+Use the component page for the provider setup. Use the hook page for frontend context.
 
-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. Treat a page as
-unavailable only after a second method also fails.
+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`.
 
-If the page supports the selection, run
-`npx --yes copilotkit@4.9.1 onboard read credentials/finalize-plan`.
-
-If a second method also fails, or the page that loads does not support the selection,
-run
-`npx --yes copilotkit@4.9.1 onboard read unsupported/no-validated-path`.
+If the documentation does not support the selection, run
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.

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

@@ -4,11 +4,11 @@ Do not implement the plan yourself. Spawn one implementation subagent.
 
 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.
+documentation URLs. Give it the documentation policy recorded during framework selection.
 Wait for the subagent to finish.
 
 If all implementation and validation steps pass, run
-`npx --yes copilotkit@4.9.1 onboard read proof/round-trip`.
+`npx --yes copilotkit@4.9.4 onboard read proof/round-trip`.
 
 If a validation command fails, decide which kind of failure it is before you route.
 
@@ -20,7 +20,7 @@ Route out only when the failure is not yours to fix: the failure is in code this
 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.1 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
 
 ## Implementation subagent brief
 
@@ -30,14 +30,8 @@ Everything below the rule is the subagent's prompt. Give it verbatim.
 
 # 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.
-
-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.
+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
@@ -57,8 +51,23 @@ 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.
+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,
 run that scaffolder rather than hand-authoring what it emits.

package/onboarding/prompts/proof/complete.md

@@ -36,9 +36,19 @@ The handoff must include:
 
 - The URL of the running app.
 - The command that starts the app in the future.
-- How to use the CopilotKit Inspector.
+- The debugging surface this journey's frontend can reach, named below.
 - How to use https://intelligence.copilotkit.ai to manage the Intelligence installation.
 - The process IDs and stop commands for the running agent and frontend.
+- The `@copilotkit/*` versions this conversion changed, and what they were before.
+
+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
+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.
 
 State that the servers remain running after proof.
 
@@ -47,7 +57,7 @@ the friction commands without another developer question. The CLI telemetry gate
 whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.1 onboard friction --category <slug> --cost-seconds <seconds>
+npx --yes copilotkit@4.9.4 onboard friction --category <slug> --cost-seconds <seconds>
 ```
 
 Write one or two sentences on the command's standard input. Pick one category from
@@ -64,14 +74,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.1 onboard complete`, carrying
+When the evidence is gathered, run `npx --yes copilotkit@4.9.4 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.1 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.4 onboard complete --visual-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
@@ -79,7 +89,7 @@ The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
 For React Native:
 
 ```text
-npx --yes copilotkit@4.9.1 onboard complete --device-check <outcome>
+npx --yes copilotkit@4.9.4 onboard complete --device-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-device`, or `failed`.
@@ -92,3 +102,20 @@ Pass the outcome you were given rather than the one you wanted. Anything but `pe
 prints what the missing check leaves unverified and ends this run as blocked. That output
 is the developer's finding, so carry it into the summary rather than restating it as a
 smaller caveat.
+
+If the round trip proved and something after it still blocked this run, add `--blocked-by`
+to the same command:
+
+```text
+npx --yes copilotkit@4.9.4 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.
+
+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,
+the process IDs, and the versions this conversion changed.

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

@@ -10,11 +10,11 @@ processes and their ignored runtime files is allowed.
 
 If the subagent proves the `both-oss` predicate, keep its evidence with the plan. If it
 proves another supported starting state, record that state. In either case, run
-`npx --yes copilotkit@4.9.1 onboard read credentials/plan`.
+`npx --yes copilotkit@4.9.4 onboard read credentials/plan`.
 
 If it cannot identify the running process safely, exposes a secret, or finds a baseline
 failure that cannot be classified, run
-`npx --yes copilotkit@4.9.1 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
 
 ## Baseline proof subagent brief
 
@@ -40,7 +40,7 @@ Prove the live runtime in this order:
 4. Confirm from project files that the runtime constructor passes a `runner` option rather
    than an `intelligence` option. A package, import, project file, or key is not use proof.
 5. Run
-   `npx --yes copilotkit@4.9.1 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `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