copilotkit 4.9.0 → 4.9.2

package/onboarding/prompts/frontend/plan.md

@@ -3,6 +3,12 @@
 Use the repository findings to select the frontend. Ask the developer only for choices
 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.
+
 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
 evidence, then ask the developer to choose.
@@ -23,11 +29,11 @@ unavailable only after a second method also fails.
 
 Use exactly one matching internal route:
 
-1. React SPA: `npx --yes copilotkit@4.9.0 onboard read frontend/react-spa`
-2. Next.js: `npx --yes copilotkit@4.9.0 onboard read frontend/nextjs`
-3. Angular: `npx --yes copilotkit@4.9.0 onboard read frontend/angular`
-4. Vue 3: `npx --yes copilotkit@4.9.0 onboard read frontend/vue`
-5. React Native: `npx --yes copilotkit@4.9.0 onboard read frontend/react-native`
+1. React SPA: `npx --yes copilotkit@4.9.2 onboard read frontend/react-spa`
+2. Next.js: `npx --yes copilotkit@4.9.2 onboard read frontend/nextjs`
+3. Angular: `npx --yes copilotkit@4.9.2 onboard read frontend/angular`
+4. Vue 3: `npx --yes copilotkit@4.9.2 onboard read frontend/vue`
+5. React Native: `npx --yes copilotkit@4.9.2 onboard read frontend/react-native`
 
 If no listed frontend fits, run
-`npx --yes copilotkit@4.9.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.

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

@@ -17,8 +17,8 @@ not a fact about the page. Retrieve the same URL a second way before you judge i
 unavailable only after a second method also fails.
 
 If the page supports the selection, run
-`npx --yes copilotkit@4.9.0 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.2 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.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.

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

@@ -21,7 +21,7 @@ not a fact about the page. Retrieve the same URL a second way before you judge i
 unavailable only after a second method also fails.
 
 If the page supports the selection, run
-`npx --yes copilotkit@4.9.0 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.2 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.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/vue.md

@@ -17,8 +17,8 @@ not a fact about the page. Retrieve the same URL a second way before you judge i
 unavailable only after a second method also fails.
 
 If the page supports the selection, run
-`npx --yes copilotkit@4.9.0 onboard read credentials/finalize-plan`.
+`npx --yes copilotkit@4.9.2 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.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.

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

@@ -8,7 +8,7 @@ documentation URLs.
 Wait for the subagent to finish.
 
 If all implementation and validation steps pass, run
-`npx --yes copilotkit@4.9.0 onboard read proof/round-trip`.
+`npx --yes copilotkit@4.9.2 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.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.
 
 ## Implementation subagent brief
 
@@ -57,8 +57,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

@@ -1,13 +1,20 @@
-# Complete onboarding
+# Close out onboarding
 
 Report the selected framework, frontend, model, and complete round-trip evidence to the developer.
 Report the exact interaction, visible result, validation commands, and evidence locations.
 
 Do not complete onboarding without this evidence.
 
-Report whether the real UI was driven in a browser, using the outcome the proof subagent
+Report whether the real UI was driven on this journey's own surface -- in a browser for a
+web frontend, on a device for React Native -- using the outcome the proof subagent
 returned. Do not soften it and do not leave it out: a run that never drove the UI proved
-the agent, not the browser path, and the developer needs to know which they have.
+the agent, not the surface, and the developer needs to know which they have.
+
+**Whether this run is complete is decided by the command at the end of this prompt, not
+here.** Run it before you write the summary, and let its output decide which summary you
+write. A run whose surface was never driven is blocked, not complete: say so in the first
+line, name the evidence the command lists as missing, and do not describe the run as
+finished, working, or ready. Everything else below applies to either outcome.
 
 Report only the project this run worked in. The summary and every report below describe
 that project and nothing else. Do not name or describe a file outside the project
@@ -29,17 +36,28 @@ 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.2 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.
 
-If the developer permitted external feedback at the start, report each thing that slowed
-this run down. Send at most four reports, worst first:
+Report each thing that slowed this run down. Send at most four reports, worst first. Run
+the friction commands without another developer question. The CLI telemetry gate decides
+whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.0 onboard friction --category <slug> --cost-seconds <seconds>
+npx --yes copilotkit@4.9.2 onboard friction --category <slug> --cost-seconds <seconds>
 ```
 
 Write one or two sentences on the command's standard input. Pick one category from
@@ -53,16 +71,34 @@ a failed step and not a failed onboarding run. Reword it and send it again, or m
 on. A run that proves a round trip is complete whether or not it reported friction.
 
 Tell the developer when you send a friction report. Do not quote or summarize the report
-unless the developer asks. If the developer did not permit feedback, do not run a friction
-command.
+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.2 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.2 onboard complete --visual-check <outcome>
+```
+
+The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
 
-When the evidence is complete, run `npx --yes copilotkit@4.9.0 onboard complete`, carrying
-the visual-check outcome the proof subagent returned:
+For React Native:
 
 ```text
-npx --yes copilotkit@4.9.0 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.2 onboard complete --device-check <outcome>
 ```
 
-The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`. The command
-prints what a skipped visual check leaves unverified, so pass the outcome you were given
-rather than the one you wanted.
+The outcome is one of `performed`, `skipped-no-device`, or `failed`.
+
+The two flags are not interchangeable and neither takes the other's outcomes. A browser
+proves nothing about a React Native view tree, and a device capture proves nothing about
+browser-origin CORS, so the flag you pass is how this run states which surface it proved.
+
+Pass the outcome you were given rather than the one you wanted. Anything but `performed`
+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.

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.0 onboard read credentials/plan`.
+`npx --yes copilotkit@4.9.2 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.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.2 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.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --yes copilotkit@4.9.2 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

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

@@ -5,13 +5,19 @@ Do not do the proof work yourself. Spawn one proof subagent.
 Give the subagent the full text of the proof brief at the end of this prompt, the selected
 framework, frontend, model, approved plan, selected documentation URLs, and validation
 evidence.
+
+Give it the browser or device control you recorded in the preflight as well. The subagent
+drives the surface and cannot see your environment, so without that finding it spends the
+step discovering what you already know. A subagent told it has no control for the surface
+this frontend needs reports the skip outcome rather than looking for a way around it.
+
 Wait for the subagent to finish.
 
 Give the subagent this guide for continued-development tools:
 https://docs.copilotkit.ai/build-with-agents.md
 
 If the subagent proves the complete round trip, run
-`npx --yes copilotkit@4.9.0 onboard read proof/complete`. The round trip proves core success
+`npx --yes copilotkit@4.9.2 onboard read proof/complete`. The round trip proves core success
 even if a continued-development tool fails. Keep the Skills and MCP results separate from
 the proof result.
 
@@ -21,7 +27,7 @@ the proof subagent to fix and prove again, at most three attempts.
 
 Route out only when the failure is not yours to fix, when the same proof still fails after
 three attempts, or when no evidence of the round trip can be produced. In those cases run
-`npx --yes copilotkit@4.9.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.
 
 ## Proof subagent brief
 
@@ -35,63 +41,90 @@ Use the proof steps and documentation URLs from the approved plan. Fetch every s
 URL in one step before you start, rather than one after another.
 Do not use remembered CopilotKit instructions.
 
+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.
+
+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.
 
-Read the port the developer's agent already serves from this project's own
-configuration. Do not assume a default, and do not start a second copy of an agent this
-project is already running. Before you bind any new server, check that the port is free
-and pick another one if it is not. Record every port you used.
+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.
 
-Start the agent and the selected frontend.
+## Step 1 -- Read what the proof needs
 
-Leave the agent and frontend servers running after proof. Record each process ID and a
-safe command that stops that process. Record the frontend URL and the commands that start
-both servers again.
+Read all of this from the approved plan in one pass, before you start anything:
 
-With both running, check the wiring in one command before you open a browser:
-`npx --yes copilotkit@4.9.0 verify --json`. Add `--runtime-url` when the runtime is not at
-`http://localhost:3000/api/copilotkit`. Read the individual checks rather than the summary
-alone: a check reported `undetermined` did not run, and that is not a pass. Fix anything
-that is not a pass before the browser, because a browser failure stacked on broken wiring
-costs a round of debugging to reach an answer this command already gave.
+- the exact request to send through the frontend, in the words the plan gave it,
+- the user-visible result that request has to produce,
+- the expected agent id,
+- where the project's own data lives, and which entities the answer has to name,
+- the start command for the agent and for the frontend, from the plan where it named
+  one and from the project's own scripts otherwise,
+- the runtime URL.
 
-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.
+Where the plan named no request, write one that produces the outcome the plan named, and
+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.
 
-`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.
+## Step 2 -- Start the agent and the frontend
 
-Then prove that the agent actually runs, which is the gate for this node:
-`npx --yes copilotkit@4.9.0 verify --round-trip --json`. It sends one request through the
-runtime and reads the answer back from the thread, so it separates an agent that is
-configured from an agent that works. Use `--agent <id>` when the runtime declares more
-than one. If it reports `user-not-identified`, this project's `identifyUser` reads a
-session the CLI does not carry: pass what it reads with `--header "Name: value"` and run
-it again, because an auth-gated app refusing an unauthenticated caller is that app
-working. Do not continue until this passes, and never report a round trip proven without
-it.
+Read the port the developer's agent already serves from this project's own configuration.
+Do not assume a default, and do not start a second copy of an agent this project is
+already running. Before you bind any new server, check that the port is free and pick
+another one if it is not. Record every port you used.
+
+The table names what each frontend's own scaffolder writes, for recognizing a port in a
+started process's output. The project's configuration wins over the table.
+
+| Frontend     | Dev server the scaffolder writes |
+| ------------ | -------------------------------- |
+| Next.js      | `next dev`, port 3000            |
+| React SPA    | Vite, port 5173                  |
+| Vue 3        | Vite, port 5173                  |
+| Angular      | `ng serve`, port 4200            |
+| React Native | Metro, port 8081                 |
+
+Where this project's runtime runs as a process of its own, the frontend documentation
+puts it on port 8200. Use the runtime URL from step 1 rather than that number.
+
+Start each server in the background with the project's own script. Then wait for it to
+answer rather than for a fixed number of seconds:
 
-Then send one real request through the frontend. Make sure that the request passes through
-CopilotKit and reaches the selected agent.
+```bash
+ready=
+for _ in $(seq 90); do
+  curl -fs -o /dev/null "<url>" && ready=1 && break
+  sleep 1
+done
+[ "$ready" = 1 ] && echo "up" || echo "no answer from <url> after 90 seconds"
+```
 
-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.
+Read the loop's own last line rather than assuming it ended because the server answered.
+A server that never answered has written the reason to its own output, and reading that
+output is faster than starting it again.
+
+Leave the agent and frontend servers running after proof. Record each process ID and a
+safe command that stops that process. Record the frontend URL and the commands that start
+both servers again.
+
+## Step 3 -- Identify the process that answered
 
 Before you trust the agent, confirm that the process answering is the one in this
 repository. `verify` reports which agents the runtime declares and has nothing to compare
 them against, and `--round-trip` proves an agent answers under the declared id without
-proving which deployment did, so this comparison is yours. A health endpoint that returns success proves only that something listens on
+proving which deployment did, so this comparison is yours. A health endpoint that returns
+success proves only that something listens on
 that port. An agent from earlier work often still holds it, and a stale process answers
 as though it were the new one. Ask the running agent which graph or agent id it serves
 and compare that with the id declared in this project.
@@ -109,23 +142,112 @@ by one.
 Address a local agent by host name rather than by an IP literal. Some local agents bind
 IPv6 only, so an IPv4 literal fails against the correct port.
 
-Drive the real UI in a browser whenever your environment can, and make sure that the
-frontend receives working generative UI from the agent. Prefer this: it is the only step
-that covers realtime delivery to a browser, browser-origin CORS and CSP, the frontend
-provider being wired to this runtime, and a generative UI component actually rendering,
-and no command-line check reaches any of them.
+## 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
+`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.
 
-Use a browser MCP server already configured for the coding agent you are running as, the
-same way the CopilotKit documentation MCP server below is configured. Do not add a browser
-driver 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 a
-browser, skip this step rather than installing one, and never report a visual result you
-did not see.
+## Step 5 -- Prove that the agent runs
 
-Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for this step.
+Run `npx --yes copilotkit@4.9.2 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
+session the CLI does not carry: pass what it reads with `--header "Name: value"` and run
+it again, because an auth-gated app refusing an unauthenticated caller is that app
+working. Do not continue until this passes, and never report a round trip proven without
+it.
 
-Record the input, visible result, relevant process status, and evidence locations. Do not
-return secret values.
+## 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.
+
+Never report a result you did not see, on either surface.
+
+### 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.
+
+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
+   that renders without it is a wiring failure rather than a proof to retry.
+3. Read the browser console before you type anything, and record every error already
+   there. An error at this point belongs to page load rather than to the request.
+4. Enter the step 1 request into the CopilotKit input, in the words step 1 recorded, and
+   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.
+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.
+8. Read the network requests. Record every request the page made to the runtime endpoint
+   and the status each returned. An answer on the page with no successful request to this
+   runtime behind it came from something else, and that is a failed proof rather than a
+   passing one.
+9. Record one line for the finished turn: the time, the page URL, the element you read
+   the answer from, and what that element showed.
+
+Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for a web
+frontend.
+
+### Step 6b -- React Native
+
+The surface is a device or emulator, and a browser cannot stand in for it.
+
+1. List the booted devices in one command: `adb devices -l`. With no booted device this
+   step is `skipped-no-device`. Do not substitute a browser.
+2. Build and install the app on the booted device with the project's own script, which
+   an Expo or React Native CLI project names in `package.json`.
+3. Clear the log buffer before the request: `adb logcat -c`.
+4. Open the CopilotKit surface in the running app and enter the step 1 request, in the
+   words step 1 recorded.
+5. Wait for the assistant turn to finish rather than for a fixed number of seconds.
+6. Capture the terminal state with
+   `adb exec-out screencap -p > .copilotkit/proof/surface.png`, and record that path.
+7. Read the log for the request with `adb logcat -d -t 500`. A redbox is a runtime failure
+   the terminal state never shows.
+8. Record one line for the finished turn: the time, the platform, the device id, the
+   screen you were on, and what that screen showed.
+
+An Android emulator reaches a runtime on the host machine at `10.0.2.2` rather than at
+`localhost`. A request that fails against the runtime with nothing in the runtime's own
+log is that, rather than a broken runtime.
+
+Report exactly one of `performed`, `skipped-no-device`, or `failed` for React Native.
+
+## Step 7 -- Check the answer against the project's data
 
 Where the answer is meant to be about data the project holds, check it against that data.
 Read the entities the project holds -- the ids, names, or records the answer claims to
@@ -141,6 +263,16 @@ project's data never reaches the agent, the agent receives it and its instructio
 it, the page loads its data after the context was registered, or the run wired a different
 source than the page renders. Fix that cause, then prove again.
 
+## 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.
+
+## 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.
 Use it to install the project-scoped CopilotKit Skills.
@@ -150,9 +282,9 @@ Do not validate whether the Skills or MCP server installed correctly. Record the
 result for each attempt. Report each tool result separately. A tool error does not change
 the proof result.
 
-Gather what you need in as few commands as possible. Combine independent reads into one
-command rather than running them one at a time. Split a command only when its result decides
-what you run next.
+## Step 10 -- Return the result
 
 Return the proof or the exact failed step to the main coding agent, together with the
-visual-check outcome. Stop after you return the result.
+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
+values. Stop after you return the result.

package/onboarding/prompts/starter/clone.md

@@ -0,0 +1,67 @@
+# Clone a starter
+
+Use this shortcut only when the repository findings prove that the target project
+directory contains no entries. If the directory contains a file or directory, do not use
+this shortcut.
+
+Match the selected agent framework and frontend to this table:
+
+| Agent framework                  | Frontend | Framework ID                       |
+| -------------------------------- | -------- | ---------------------------------- |
+| Agno                             | Next.js  | `agno`                             |
+| Claude Agent SDK Python          | Next.js  | `claude-sdk-python`                |
+| Claude Agent SDK TypeScript      | Next.js  | `claude-sdk-typescript`            |
+| CrewAI Flows                     | Next.js  | `flows`                            |
+| LangGraph Python                 | Next.js  | `langgraph-py`                     |
+| LangGraph TypeScript             | Next.js  | `langgraph-js`                     |
+| LlamaIndex                       | Next.js  | `llamaindex`                       |
+| ADK                              | Next.js  | `adk`                              |
+| ADK                              | Angular  | `adk-angular`                      |
+| Microsoft Agent Framework Python | Next.js  | `microsoft-agent-framework-py`     |
+| Microsoft Agent Framework .NET   | Next.js  | `microsoft-agent-framework-dotnet` |
+| Mastra                           | Next.js  | `mastra`                           |
+| Pydantic AI                      | Next.js  | `pydantic-ai`                      |
+| Strands Agents Python            | Next.js  | `aws-strands-py`                   |
+| Strands Agents TypeScript        | Next.js  | `aws-strands-ts`                   |
+
+Each Framework ID selects a starter that the CLI ships with Intelligence. Do not infer a
+different pair from a similar name. AG2 does not use this shortcut because its starter does
+not include Intelligence.
+
+Get the target directory name from its path. The project name must contain 1 to 30
+lowercase letters, numbers, or hyphens. It must not start or end with a hyphen. If the
+selected pair is not in the table, or the directory name is not valid, stop the shortcut.
+Do not run `init`. Treat this result as a failed shortcut and follow the final failure
+instruction in this prompt.
+
+If the developer did not name an Intelligence project, list the available projects:
+
+`npx --yes copilotkit@4.9.2 project list --json`
+
+Ask the developer to select a project or give a name for a new project. If the developer
+already gave this answer, do not ask again. Do not read a secret value. Do not show or
+store a secret value.
+
+Run the command from the parent directory. Do not inspect another entry in the parent
+directory. Replace each placeholder with the recorded value. Do not run a placeholder as
+a shell argument.
+
+`npx --yes copilotkit@4.9.2 init --name <project-name> --framework <framework-id> --channel none --no-banner --project <slug-or-id> --install`
+
+If the developer wants a new project, use `--create <name>` instead of
+`--project <slug-or-id>`. If the developer asked to skip the dependency install, use
+`--no-install` instead of `--install`. Do not wait for an interactive prompt. Pass every
+answer as a flag.
+
+The command clones the starter into the empty target directory. It also connects the
+starter to the developer's Intelligence project. The earlier login phase supplies the
+account. The command does not need terminal input.
+
+If the command succeeds, do not rebuild the starter by hand. Inspect only the generated
+paths inside the target directory. Record the files, install result, project connection,
+and validation commands. Then run
+`npx --yes copilotkit@4.9.2 onboard read proof/round-trip`.
+
+If the command fails, report its exact error and do not claim that the starter is ready.
+Then run
+`npx --yes copilotkit@4.9.2 onboard read unsupported/no-validated-path`.