copilotkit 4.9.4 → 4.9.17

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

@@ -1,97 +1,63 @@
 # Implement and validate the plan
 
-Do not implement the plan yourself. Spawn one implementation subagent.
+Do not implement the plan yourself. Use the step order in the approved plan.
 
-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. Give it the documentation policy recorded during framework selection.
-Wait for the subagent to finish.
+## Protected-path audit
 
-If all implementation and validation steps pass, run
-`npx --yes copilotkit@4.9.4 onboard read proof/round-trip`.
+Run the audit from the target app directory:
 
-If a validation command fails, decide which kind of failure it is before you route.
+```text
+npx --yes copilotkit@4.9.17 onboard audit
+```
 
-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.
+It compares every protected path with the digest the CLI captured for it. Its result starts
+with `Status: passed`, `Status: failed`, or `Status: blocked`. The audit passes only when
+the result starts with `Status: passed`.
 
-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.4 onboard read unsupported/no-validated-path`.
+`Status: failed` names each protected path that changed and how. If an audit reports a
+changed protected path, use the route-out rules. Never repair, reset, or revert a protected
+path. Also do not retry the audit: it reads files, so a second run of it answers the same.
 
-## Implementation subagent brief
+`Status: blocked` means the audit has no baseline to read. A blocked audit compared
+nothing and proved nothing changed. It is not a preservation failure: do not report a
+protected path as changed. Report the printed reason and use the route-out rules.
 
-Everything below the rule is the subagent's prompt. Give it verbatim.
+A non-pass audit never continues the run. Do not send an audit result to a repair worker.
 
----
+Spawn one implementation subagent. Tell it to run
+`npx --yes copilotkit@4.9.17 onboard read subagent/implement-and-validate` first and follow
+the prompt it returns. If that read fails because the subagent cannot use the shell, stop that
+subagent. Run the same command yourself, then spawn a fresh subagent with the returned prompt
+and the same handoff. Give it the plan, selected framework, frontend, model, exact target app
+directory, selected documentation URLs, and the
+documentation policy recorded during framework selection or conversion planning. On a
+conversion, also give it the frozen criterion. Give it the protected path list. Require it
+to implement every step in plan order and run the full validation list. Wait for it.
 
-# Implement and validate the approved plan
+One subagent implements the whole plan. Do not divide the work across concurrent subagents,
+and do not spawn a second subagent to reconcile a split.
 
-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.
+If the implementation result does not start with `Status: passed`, do not continue to proof.
+Run the protected-path audit after the implementation subagent passes. If any protected path
+changed, use the route-out rules. Continue to proof only when that audit passes.
 
-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.
+After the selected implementation path passes, run
+`npx --yes copilotkit@4.9.17 onboard read proof/round-trip`.
 
-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.
+## Repair rules
 
-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.
+If a result starts with `Status: failed`, or a validation command fails, first
+decide which kind of failure it is before you route.
 
-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.
+A failure in a file this run created or changed is a defect in the new work. Send it to the
+implementation subagent. Before you run the next command, repeat the failed command. Make at
+most three repair attempts per command. After the repair passes, continue on the same
+implementation path.
 
-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.
+## Route-out rules
 
-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.
-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.
+Route out for `Status: blocked`. Route out only when the failure is not yours to fix: the
+failure is in code this run did not write, the fix requires changing the developer's existing
+agent or frontend, 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.17 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/proof/complete.md

@@ -40,12 +40,14 @@ The handoff must include:
 - 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.
+- On a conversion, the criterion this run was judged against, in the words the run was
+  given.
 
 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
+`npx --yes copilotkit@4.9.17 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.
@@ -57,7 +59,7 @@ the friction commands without another developer question. The CLI telemetry gate
 whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.4 onboard friction --category <slug> --cost-seconds <seconds>
+npx --yes copilotkit@4.9.17 onboard friction --category <slug> --cost-seconds <seconds>
 ```
 
 Write one or two sentences on the command's standard input. Pick one category from
@@ -74,14 +76,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.4 onboard complete`, carrying
+When the evidence is gathered, run `npx --yes copilotkit@4.9.17 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.4 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.17 onboard complete --visual-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
@@ -89,7 +91,7 @@ The outcome is one of `performed`, `skipped-no-browser-tool`, or `failed`.
 For React Native:
 
 ```text
-npx --yes copilotkit@4.9.4 onboard complete --device-check <outcome>
+npx --yes copilotkit@4.9.17 onboard complete --device-check <outcome>
 ```
 
 The outcome is one of `performed`, `skipped-no-device`, or `failed`.
@@ -107,7 +109,7 @@ If the round trip proved and something after it still blocked this run, add `--b
 to the same command:
 
 ```text
-npx --yes copilotkit@4.9.4 onboard complete --visual-check performed --blocked-by <cause>
+npx --yes copilotkit@4.9.17 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

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

@@ -1,59 +1,24 @@
 # 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 prove the baseline yourself. Spawn one proof subagent. Tell it to run
+`npx --yes copilotkit@4.9.17 onboard read subagent/prove-oss-baseline` first and follow the
+prompt it returns. If that read fails because the subagent cannot use the shell, stop that
+subagent. Run the same command yourself, then spawn a fresh subagent with the returned prompt
+and the same handoff. Give it the repository findings and 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.4 onboard read credentials/plan`.
+If the subagent proves the `both-oss` predicate, keep its evidence with the plan and run
+`npx --yes copilotkit@4.9.17 onboard read conversion/plan`. That project already works.
+What it needs is the conversion, not a build.
+
+If it proves another supported starting state, record that state and run
+`npx --yes copilotkit@4.9.17 onboard read credentials/plan`. This prompt is served
+whenever a project looks like an OSS integration, so a baseline that did not prove is an
+ordinary starting state rather than a failure.
 
 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.4 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.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
-   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.
+`npx --yes copilotkit@4.9.17 onboard read unsupported/no-validated-path`.