copilotkit 4.8.3 → 4.9.0

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

@@ -1,13 +1,88 @@
 # Implement and validate the plan
 
-Do not implement the plan yourself. Spawn one implementation subagent. Tell it to run
-`npx copilotkit@4.8.3 onboard read subagent/implement-and-validate`.
+Do not implement the plan yourself. Spawn one implementation subagent.
 
-Give the subagent the approved plan, selected framework, frontend, model, repository
-findings, and selected documentation URLs. Wait for the subagent to finish.
+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.
+Wait for the subagent to finish.
 
 If all implementation and validation steps pass, run
-`npx copilotkit@4.8.3 onboard read proof/round-trip`.
+`npx --yes copilotkit@4.9.0 onboard read proof/round-trip`.
 
-If a step fails or the documentation does not support the plan, run
-`npx copilotkit@4.8.3 onboard read unsupported/no-validated-path`.
+If a validation command fails, decide which kind of failure it is before you route.
+
+A failure in a file this run created or changed is a defect in the new work, not a limit
+of this release. Fix it and run the same command again. Do not continue to the next step
+until that command passes. Make at most three repair attempts per command.
+
+Route out only when the failure is not yours to fix: the failure is in code this run did
+not write, or the fix requires changing the developer's existing agent or frontend,
+or the same command still fails after three repair attempts, or the documentation does not
+support the plan. In those cases run
+`npx --yes copilotkit@4.9.0 onboard read unsupported/no-validated-path`.
+
+## Implementation subagent brief
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+When the documentation creates the frontend with the framework's own scaffolder,
+run that scaffolder rather than hand-authoring what it emits.
+Do not re-declare a compiler option it set. Every real project of that framework
+inherits those defaults, so a hand-written replacement measures a configuration no
+developer has. Where the plan needs configuration the scaffolder did not write,
+extend the scaffolder's file and set only what you add.
+
+Where the plan names data the project already holds, share that data with the agent
+through the context API the selected documentation names for this frontend. Then write the agent's instructions to
+refuse to answer about entities the shared context does not carry, and to name what is
+missing instead. An agent with no context and no refusal invents plausible entities, and
+no part of the run errors.
+
+Run the validation commands from the approved plan. Record the changed files, command
+results, and each error. Do not claim that the real user journey works in this phase.
+
+Report the runtime constructor you wrote. Name whether it passes `intelligence` or
+`runner`. A runtime built with `runner` is the SSE runtime and never reads the credential,
+whatever the browser shows.
+
+Gather what you need in as few commands as possible. Combine independent reads into one
+command rather than running them one at a time. Split a command only when its result decides
+what you run next.
+
+Return the implementation result and validation evidence to the main coding agent. Stop
+after you return the result.

package/onboarding/prompts/proof/complete.md

@@ -3,5 +3,66 @@
 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. When the evidence is complete, run
-`npx copilotkit@4.8.3 onboard complete`.
+Do not complete onboarding without this evidence.
+
+Report whether the real UI was driven in a browser, 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.
+
+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
+directory: not its path, not its contents, not how long a value in it is, not whether it
+holds one. A path the developer named is theirs to give this run, not this run's to
+record. A friction report leaves the machine, and a completion summary is durable. The
+file's owner chose neither.
+
+The summary is the developer's handoff, not this run's retrospective. Report what was
+built, the round trip and its evidence, the validation commands, where the evidence is,
+and how to start it again. Report a failed check as part of that evidence. Say nothing
+about what this run found awkward in the onboarding graph, the documentation, or the CLI.
+A defect this run hit belongs in the summary only as the thing the developer must do
+about it: keep this version pin, wire this constructor, run this build. It never appears
+as an account of hitting it. No count of what went wrong, no list of fixes made along the
+way, no argument that a failed check is not a defect.
+
+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.
+- How to use https://intelligence.copilotkit.ai to manage the Intelligence installation.
+- The process IDs and stop commands for the running agent and frontend.
+
+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:
+
+```text
+npx --yes copilotkit@4.9.0 onboard friction --category <slug> --cost-seconds <seconds>
+```
+
+Write one or two sentences on the command's standard input. Pick one category from
+docs-missing, docs-wrong, docs-sequential, cli-gap, sdk-gap, environment,
+port-collision, credential, validation-loop, and other. For the seconds, give your
+own estimate of what that one papercut cost this run.
+
+Send no secrets, source code, logs, or command output. The command refuses a report
+that carries any of those, prints the reason, and exits zero. A refused report is not
+a failed step and not a failed onboarding run. Reword it and send it again, or move
+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.
+
+When the evidence is complete, run `npx --yes copilotkit@4.9.0 onboard complete`, carrying
+the visual-check outcome the proof subagent returned:
+
+```text
+npx --yes copilotkit@4.9.0 onboard complete --visual-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.

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

@@ -0,0 +1,59 @@
+# Prove the existing OSS baseline
+
+Do not prove the baseline yourself. Spawn one proof subagent.
+
+Give the subagent the full text of the baseline brief at the end of this prompt, the
+repository findings, and the exact CLI package spec. Wait for the subagent to finish.
+
+Do not change project files before this proof ends. Starting existing development
+processes and their ignored runtime files is allowed.
+
+If the subagent proves the `both-oss` predicate, keep its evidence with the plan. If it
+proves another supported starting state, record that state. In either case, run
+`npx --yes copilotkit@4.9.0 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`.
+
+## Baseline proof subagent brief
+
+Everything below the rule is the subagent's prompt. Give it verbatim.
+
+---
+
+# Prove the existing OSS CopilotKit baseline
+
+Read and run only inside the project directory. Do not edit source, configuration,
+dependencies, or tracked files. Do not read, show, store, or return secret values.
+
+Find the expected agent id from the project. Start the existing agent and frontend only
+when they are not already running. Before using a port, identify its process and working
+directory. Do not stop a process outside this project.
+
+Prove the live runtime in this order:
+
+1. GET `/info` from the project's CopilotKit runtime and require a valid response.
+2. Require `/info` to declare the expected agent id.
+3. Confirm that `licenseStatus` is absent. Its presence means the live runtime uses
+   Intelligence and is not an OSS starting state.
+4. Confirm from project files that the runtime constructor passes a `runner` option rather
+   than an `intelligence` option. A package, import, project file, or key is not use proof.
+5. Run
+   `npx --yes copilotkit@4.9.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   with the runtime URL or auth header options that this project needs. Require exit zero
+   and the JSON `ok` field to be `true`.
+6. Drive one real request through the existing frontend, CopilotKit runtime, and expected
+   agent. Require the existing user-visible result. If no browser tool is available, the
+   round trip is not proved and the state is `unproved`.
+
+Classify the state as `both-oss` only when all six predicates are true: agent present,
+interface present, CopilotKit present, CopilotKit round trip proven, runtime connection
+`oss`, and managed Intelligence not configured. Return each predicate and its secret-safe
+evidence.
+
+The default in-memory OSS runner is ephemeral. SQLite, custom, or framework persistence
+can be durable. Report the persistence that project evidence proves, or `unproved`. Do not
+replace it and do not describe all OSS runs as ephemeral.
+
+Stop after returning the baseline result, process ids and ports used, and evidence paths.

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

@@ -1,16 +1,158 @@
 # Prove the user journey
 
-Do not do the proof work yourself. Spawn one proof subagent. Tell it to run
-`npx copilotkit@4.8.3 onboard read subagent/prove-round-trip`.
+Do not do the proof work yourself. Spawn one proof subagent.
 
-Give the subagent the selected framework, frontend, model, approved plan, selected
-documentation URLs, and validation evidence. Wait for the subagent to finish.
+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.
+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 and configures the tools, run
-`npx copilotkit@4.8.3 onboard read proof/complete`.
+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
+even if a continued-development tool fails. Keep the Skills and MCP results separate from
+the proof result.
 
-If the round trip fails or lacks evidence, run
-`npx copilotkit@4.8.3 onboard read unsupported/no-validated-path`.
+If the round trip fails, decide which kind of failure it is before you route. A failure
+caused by a file this run created or changed is a defect in the new work. Send it back to
+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`.
+
+## Proof subagent brief
+
+Everything below the rule is the subagent's prompt. Give it verbatim.
+
+---
+
+# 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.
+
+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.
+
+Start the agent and the selected frontend.
+
+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.
+
+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.
+
+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.
+
+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.
+
+Then send one real request through the frontend. Make sure that the request passes through
+CopilotKit and reaches the selected agent.
+
+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.
+
+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
+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.
+
+If they do not match, find out whose process it is before you signal anything.
+`lsof -ti :<port> -sTCP:LISTEN` gives the process id, and `lsof -a -p <pid> -d cwd` gives
+the directory it runs in. Stop it only when that directory is inside this project, and
+stop its children before the parent so nothing survives by reparenting. A holder outside
+this project belongs to other work: leave it running, report it, and bind to another port.
+Never stop a process because its command line matches a name. One `pkill` pattern reaches
+every project on the machine and takes down work that has nothing to do with this run.
+Never continue against a process you cannot identify, and never report a round trip proven
+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.
+
+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.
+
+Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for this step.
+
+Record the input, visible result, relevant process status, and evidence locations. Do not
+return secret values.
+
+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
+describe -- and confirm the answer names those and no others. Record the entities you
+compared. Where the outcome of this journey references no project data, record that
+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.
+
+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.
+Use it to configure the CopilotKit documentation MCP server for the current coding agent.
+
+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.
+
+Gather what you need in as few commands as possible. Combine independent reads into one
+command rather than running them one at a time. Split a command only when its result decides
+what you run next.
+
+Return the proof or the exact failed step to the main coding agent, together with the
+visual-check outcome. Stop after you return the result.

package/onboarding/prompts/subagent/create-plan.md

@@ -1,14 +1,81 @@
 # Create the onboarding plan
 
 Use the selected framework, frontend, model, repository findings, and documentation URLs
-from the main coding agent. Fetch each selected URL. Do not use remembered CopilotKit
-instructions.
+from the main coding agent. Fetch every selected URL in one step 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.
+
+Name the application the project asks for, and plan that application. Each documentation
+page teaches through one worked example, and that example carries a domain of its own.
+The domain belongs to the page. The project's purpose from the repository findings
+decides what gets built. Where the two differ, the project wins. Where the repository
+never states a purpose, say so in the plan and ask the developer before you adopt the
+domain of an example.
+
+Read only inside the project directory. Answer an API question from the documentation
+URLs you were given, not from another checkout on this machine.
 
 List the required credential variable names. Do not read or return credential values.
 Preserve each agent or frontend that already exists.
 
+Plan the runtime to consume the Intelligence credential. The runtime takes an
+`intelligence` option holding a client built from the project key. A runtime given a
+`runner` option instead is the OSS runtime. It never reads the Intelligence key, and the
+Inspector reads the project as locked. The default in-memory OSS runner is ephemeral.
+SQLite, custom, or framework persistence can be durable. The two options cannot be
+combined. Take the constructor from the connect-your-runtime page. Where a framework
+quickstart shows a `runner` option instead, the connect-your-runtime page wins.
+
+When the starting state is `both-oss`, use its recorded live baseline evidence. Preserve
+the working agent, frontend, CopilotKit integration, and OSS behavior. Plan only the
+project selection, Intelligence runtime configuration, and authenticated proof needed for
+the conversion. Preserve the existing persistence and user-visible request. Do not
+rebuild a path that already works.
+
+Where the SDK requires an application-level value that the repository cannot supply, such
+as an end-user identity for threads, use one clearly marked local placeholder and name what
+production requires instead. Do not stop onboarding to ask the developer for it.
+
+Check whether the existing agent performs unattended side effects, such as paging, sending
+notifications, writing to an external system, or creating tickets. If it does, the new
+conversational surface must not trigger them. Wrap only the reasoning steps, or require an
+explicit developer confirmation before the side effect can run. Name each side effect you
+found and state how the plan avoids it.
+
+If the value of the journey depends on data the project already holds, name that data,
+name where it lives, and name how it reaches the agent. Rendering a list in the DOM does
+not give the agent access to it. An agent wired without the page's data answers from
+entities it invents, and the answer looks correct. Take the frontend-context step from
+the selected documentation. Where no selected page documents it for this framework or
+frontend, record that as a documentation gap rather than guessing the API.
+
+Where that data exists, name the entities the proof compares against: the ids, names, or
+records the project holds and the answer has to reference. Where the outcome references
+no project data, say so in the plan, so that the proof asks for evidence this journey can
+produce.
+
 Create one plan for implementation, validation, and proof. Name each file or area that can
 change. Name the commands that can validate the result.
+Name the commands or user path that prove a real generative-UI round trip.
+
+Keep a production build out of the validation commands. A type check plus the real round
+trip is the proof, and the round trip runs in development mode. Name the production build
+as a follow-up for the developer instead. Never raise a bundle budget or relax a lint rule
+to make a build pass during onboarding.
+
+The type check runs against the project's own configuration. If the project has no
+type-check command, add one that uses the configuration the project already has.
+Do not add compiler strictness the project did not have. Nothing later in the run is
+allowed to weaken type safety, so a stricter gate named here is one the run cannot get
+back out of.
+
+Gather what you need in as few commands as possible. Combine independent reads into one
+command rather than running them one at a time. Split a command only when its result decides
+what you run next.
 
 Return the plan, the URLs that you read, and each documentation gap. Stop after you return
 the findings to the main coding agent.

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

@@ -1,13 +1,58 @@
 # Implement and validate the approved plan
 
-Use only the approved plan and the selected documentation URLs. Fetch each URL before you
-change the project. Do not use remembered CopilotKit instructions.
+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.
+
+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.
+
+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.
 
 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.
+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.
+
+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.
+
+When the documentation creates the frontend with the framework's own scaffolder,
+run that scaffolder rather than hand-authoring what it emits.
+Do not re-declare a compiler option it set. Every real project of that framework
+inherits those defaults, so a hand-written replacement measures a configuration no
+developer has. Where the plan needs configuration the scaffolder did not write,
+extend the scaffolder's file and set only what you add.
+
+Where the plan names data the project already holds, share that data with the agent
+through the context API the selected documentation names for this frontend. Then write the agent's instructions to
+refuse to answer about entities the shared context does not carry, and to name what is
+missing instead. An agent with no context and no refusal invents plausible entities, and
+no part of the run errors.
 
 Run the validation commands from the approved plan. Record the changed files, command
 results, and each error. Do not claim that the real user journey works in this phase.
 
+Report the runtime constructor you wrote. Name whether it passes `intelligence` or
+`runner`. A runtime built with `runner` is the SSE runtime and never reads the credential,
+whatever the browser shows.
+
+Gather what you need in as few commands as possible. Combine independent reads into one
+command rather than running them one at a time. Split a command only when its result decides
+what you run next.
+
 Return the implementation result and validation evidence to the main coding agent. Stop
 after you return the result.

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

@@ -2,13 +2,23 @@
 
 Inspect the repository without changing it. 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
 - authentication boundaries
 - names of required credential variables, without reading their values
-- the commands or user path that can prove a real generative-UI round trip
+
+A project states what it is for in its `README.md`, in its package description, or in
+the prompt of an agent it already has. Quote that statement rather than rewriting it. An
+empty project carries it in the README alone, and that makes the README the whole of the
+evidence. State the purpose as unproved when the project never says.
+
+Gather what you need in as few commands as possible. Combine independent reads into one
+command rather than running them one at a time. Split a command only when its result decides
+what you run next.
 
 Return the 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 run or return another
-onboarding command. Stop after returning the findings to the main coding agent.
+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.

package/onboarding/prompts/subagent/prove-oss-baseline.md

@@ -0,0 +1,35 @@
+# Prove the existing OSS CopilotKit baseline
+
+Read and run only inside the project directory. Do not edit source, configuration,
+dependencies, or tracked files. Do not read, show, store, or return secret values.
+
+Find the expected agent id from the project. Start the existing agent and frontend only
+when they are not already running. Before using a port, identify its process and working
+directory. Do not stop a process outside this project.
+
+Prove the live runtime in this order:
+
+1. GET `/info` from the project's CopilotKit runtime and require a valid response.
+2. Require `/info` to declare the expected agent id.
+3. Confirm that `licenseStatus` is absent. Its presence means the live runtime uses
+   Intelligence and is not an OSS starting state.
+4. Confirm from project files that the runtime constructor passes a `runner` option rather
+   than an `intelligence` option. A package, import, project file, or key is not use proof.
+5. Run
+   `npx --yes copilotkit@4.9.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   with the runtime URL or auth header options that this project needs. Require exit zero
+   and the JSON `ok` field to be `true`.
+6. Drive one real request through the existing frontend, CopilotKit runtime, and expected
+   agent. Require the existing user-visible result. If no browser tool is available, the
+   round trip is not proved and the state is `unproved`.
+
+Classify the state as `both-oss` only when all six predicates are true: agent present,
+interface present, CopilotKit present, CopilotKit round trip proven, runtime connection
+`oss`, and managed Intelligence not configured. Return each predicate and its secret-safe
+evidence.
+
+The default in-memory OSS runner is ephemeral. SQLite, custom, or framework persistence
+can be durable. Report the persistence that project evidence proves, or `unproved`. Do not
+replace it and do not describe all OSS runs as ephemeral.
+
+Stop after returning the baseline result, process ids and ports used, and evidence paths.