copilotkit 4.9.50 → 4.10.0

package/onboarding/index.json

@@ -1,5 +1,5 @@
 {
-  "graphTree": "249d03371764b775fd5893026d7869bbf83716d6",
+  "graphTree": "d0d29f5f2ed37dd76f08bb7655e28da124813c2f",
   "intentRoots": {
     "add-a2ui": "feature/a2ui/start",
     "add-chat-suggestions": "feature/chat-suggestions/start",
@@ -13,10 +13,8 @@
   "prompts": [
     {
       "edges": [
-        "subagent/inspect-repository",
-        "proof/oss-baseline",
-        "credentials/plan",
-        "unsupported/no-validated-path"
+        "research/gather",
+        "stopped/run-failed"
       ],
       "milestone": "authenticate",
       "name": "authenticate/start"
@@ -31,9 +29,7 @@
     },
     {
       "edges": [
-        "subagent/create-plan",
-        "implementation/build-and-validate",
-        "unsupported/no-validated-path"
+        "credentials/settle-credentials"
       ],
       "milestone": "credentials",
       "name": "credentials/finalize-plan"
@@ -64,6 +60,23 @@
       "milestone": "credentials",
       "name": "credentials/plan"
     },
+    {
+      "edges": [
+        "credentials/write-plan"
+      ],
+      "milestone": "credentials",
+      "name": "credentials/settle-credentials"
+    },
+    {
+      "edges": [
+        "subagent/create-plan",
+        "stopped/run-failed",
+        "implementation/build-and-validate",
+        "unsupported/no-validated-path"
+      ],
+      "milestone": "credentials",
+      "name": "credentials/write-plan"
+    },
     {
       "edges": [],
       "milestone": "fallback",
@@ -78,7 +91,10 @@
       "name": "feature/a2ui/implement"
     },
     {
-      "edges": [],
+      "edges": [
+        "feature/stop",
+        "feature/complete"
+      ],
       "milestone": "feature",
       "name": "feature/a2ui/proof"
     },
@@ -99,7 +115,10 @@
       "name": "feature/chat-suggestions/implement"
     },
     {
-      "edges": [],
+      "edges": [
+        "feature/stop",
+        "feature/complete"
+      ],
       "milestone": "feature",
       "name": "feature/chat-suggestions/proof"
     },
@@ -111,6 +130,11 @@
       "milestone": "feature",
       "name": "feature/chat-suggestions/start"
     },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/complete"
+    },
     {
       "edges": [
         "feature/stop",
@@ -120,7 +144,10 @@
       "name": "feature/learning/implement"
     },
     {
-      "edges": [],
+      "edges": [
+        "feature/stop",
+        "feature/complete"
+      ],
       "milestone": "feature",
       "name": "feature/learning/proof"
     },
@@ -141,7 +168,10 @@
       "name": "feature/open-generative-ui/implement"
     },
     {
-      "edges": [],
+      "edges": [
+        "feature/stop",
+        "feature/complete"
+      ],
       "milestone": "feature",
       "name": "feature/open-generative-ui/proof"
     },
@@ -162,7 +192,10 @@
       "name": "feature/realtime-sync/implement"
     },
     {
-      "edges": [],
+      "edges": [
+        "feature/stop",
+        "feature/complete"
+      ],
       "milestone": "feature",
       "name": "feature/realtime-sync/proof"
     },
@@ -183,7 +216,10 @@
       "name": "feature/rich-threads/implement"
     },
     {
-      "edges": [],
+      "edges": [
+        "feature/stop",
+        "feature/complete"
+      ],
       "milestone": "feature",
       "name": "feature/rich-threads/proof"
     },
@@ -209,7 +245,10 @@
       "name": "feature/voice/implement"
     },
     {
-      "edges": [],
+      "edges": [
+        "feature/stop",
+        "feature/complete"
+      ],
       "milestone": "feature",
       "name": "feature/voice/proof"
     },
@@ -431,6 +470,7 @@
       "edges": [
         "subagent/implement-and-validate",
         "proof/round-trip",
+        "stopped/run-failed",
         "unsupported/no-validated-path"
       ],
       "milestone": "implementation",
@@ -446,7 +486,7 @@
         "subagent/prove-oss-baseline",
         "conversion/plan",
         "credentials/plan",
-        "unsupported/no-validated-path"
+        "stopped/run-failed"
       ],
       "milestone": "proof",
       "name": "proof/oss-baseline"
@@ -455,19 +495,42 @@
       "edges": [
         "subagent/prove-round-trip",
         "proof/complete",
-        "unsupported/no-validated-path"
+        "stopped/run-failed"
       ],
       "milestone": "proof",
       "name": "proof/round-trip"
     },
+    {
+      "edges": [
+        "subagent/inspect-repository",
+        "research/route",
+        "stopped/run-failed"
+      ],
+      "milestone": "research",
+      "name": "research/gather"
+    },
+    {
+      "edges": [
+        "proof/oss-baseline",
+        "credentials/plan",
+        "stopped/run-failed"
+      ],
+      "milestone": "research",
+      "name": "research/route"
+    },
     {
       "edges": [
         "proof/round-trip",
-        "unsupported/no-validated-path"
+        "stopped/run-failed"
       ],
       "milestone": "starter",
       "name": "starter/clone"
     },
+    {
+      "edges": [],
+      "milestone": "stopped",
+      "name": "stopped/run-failed"
+    },
     {
       "edges": [],
       "milestone": "subagent",

package/onboarding/prompts/authenticate/start.md

@@ -1,5 +1,26 @@
 # Start CopilotKit onboarding
 
+## First, say which coding agent you are
+
+Run this before anything else in this prompt, including the welcome message below:
+
+```text
+npx --yes copilotkit@4.10.0 onboard identify --coding-agent <coding-agent-slug>
+```
+
+Report your own product with one short slug, such as `codex` or `claude-code`.
+
+It runs first because it is how this run reports that it started working. It needs no
+browser, no session, and no project, so nothing below it can prevent it. Every rule after
+this point can stop a run instead, and a run that stops before this command leaves no
+trace that it ever began. The slug also tells the sign-in page which agent sent the
+developer, so the page names you instead of "your coding agent".
+
+The prompt the developer copied used to ask them to pass this. It asked a human to read
+an instruction written for you, so it lives here now.
+
+## How to run this onboarding
+
 Act only as the orchestrator. Rely on subagents for all project work.
 Give every project task to a subagent.
 Do not inspect, change, implement, or validate the project yourself.
@@ -16,7 +37,7 @@ Every later command must run from the directory this run started in. A command r
 somewhere else, such as a sibling of that directory, is refused rather than answered,
 because the run it belongs to cannot be found from there. That refusal is a step to take,
 not a stop to report: run
-`npx --yes copilotkit@4.9.50 onboard start --run <onboarding_run_id>` in the directory
+`npx --yes copilotkit@4.10.0 onboard start --run <onboarding_run_id>` in the directory
 you are now in, which binds it to the same run, then run the refused command again. Do not
 start a run without that id. A run started without it is a second run, and the work already
 done stops counting toward the first.
@@ -30,9 +51,21 @@ answer they cannot get, and it hides the documentation gap that blocks them.
 Send this exact message once, as your first message in this onboarding run, before
 anything else:
 
-Welcome to CopilotKit. I will check sign-in, inspect your project, recommend a setup, and
-show you a plan before I change files. After you approve the plan, I will build the
-integration, prove the full round trip, and leave the app running with its URLs.
+Welcome to CopilotKit. By the end of this run your own application talks to an AI agent,
+and its chat history stays. A user can close the tab, come back, and reopen any past
+conversation in full. The managed Intelligence platform is what keeps them. I prove that
+round trip in the running app before I call it done. You finish with working software and
+the evidence that it works.
+
+I will check sign-in, inspect your project, recommend a setup, and show you a plan before I
+change files. After you approve the plan, I will build the integration, prove the full round
+trip, and leave the app running with its URLs.
+
+Everything I need from you comes before that approval: sign-in, a few short setup questions,
+and the plan itself. After you approve it, you can walk away. Building and proving the
+integration is the long part of this run, and I work through it without you. You hear from
+me next when the app is running and I hand you its URLs, or when something stops me and I
+tell you what it was.
 
 That message belongs to the run, not to this prompt. If you already sent it in this run, do
 not send it again, including on a second read of this prompt. It has no value after the
@@ -45,29 +78,32 @@ CLI telemetry setting when a later step tries to send a report.
 
 This run reports its own stops. If you stop this run at any point, send one short report
 before you stop. That covers a stop this prompt names, a stop a later prompt names, and a
-stop no prompt anticipated, including one your own harness causes. Run the feedback command
-without another developer question. The CLI telemetry gate decides whether the report is
+stop no prompt anticipated, including one your own harness causes. Run the friction command without another developer question. The CLI telemetry gate decides whether the report is
 sent.
 
 ```text
-npx --yes copilotkit@4.9.50 onboard feedback
+npx --yes copilotkit@4.10.0 onboard friction --phase stop --category <slug>
 ```
 
-Write at most four lines to the command's standard input: the step you stopped at and what
-stopped it. Send no secrets, source code, logs, or command output. The command refuses a
+Write one or two sentences to standard input: the step you stopped at and what stopped it.
+Pick the category that fits from docs-missing, docs-wrong, docs-sequential, cli-gap,
+sdk-gap, environment, port-collision, credential, validation-loop, and other. Leave
+--cost-seconds off. A run that stopped cannot separate one papercut's cost from the cost
+of the whole run, so the estimate is optional on a stop report and only there. 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. Reword it and send it again, or stop without a report.
 
 Reporting a stop is not a route change. It does not resume the run, it is not a question
 for the developer, and it does not replace whatever the rule that stopped you says to do
-next: send the report, then stop. Report friction only from a run that finished, never from
-a stop.
+next: send the report, then stop.
 
 Until now the route out of an unsupported path was the only place that asked for a report,
 so a stop anywhere else left no trace at all. A stop nobody hears about is a stop this
 graph cannot fix.
 
-Run `npx --yes copilotkit@4.9.50 login --json` before any project work. This command
+## Check sign-in
+
+Run `npx --yes copilotkit@4.10.0 login --json` before any project work. This command
 checks the current session. It starts sign-in only as needed. Treat this as a long-lived
 streaming process. Do not wait for the command to exit before you read its standard output.
 
@@ -80,8 +116,9 @@ Read each JSON Lines record as the running command writes it:
    When that first URL arrives, send this exact message once. Do not send it when the
    existing session is already valid, and do not add a feature list or another explanation:
 
-   I will open a sign-in page so I can create a project and API key. You can remove the key
-   later to disconnect this workspace.
+   I will open a sign-in page. Signing in gives this project a managed CopilotKit project
+   and its API key. That key is what lets your users reopen past conversations. You can
+   remove it later to disconnect this workspace.
 
 3. Open the first `authentication_url` exactly once with the operating system's default
    browser. Run the opener separately from the long-lived login process. Use the command
@@ -101,180 +138,9 @@ Read each JSON Lines record as the running command writes it:
 Do not use `whoami` for this check. It has no JSON output and some failures exit with code
 zero. Do not put account tokens or credentials in the conversation.
 
-## How to wait for a subagent
-
-This rule covers every subagent this run spawns, here and in every later prompt.
-
-Spawning a subagent returns almost at once. That return is the dispatch succeeding, not the
-work finishing: the subagent runs in the background, and its result reaches you as a
-notification. Where your own harness hands you the report from the dispatch itself instead,
-you already hold the result. Either way there is nothing to poll.
-
-After you dispatch, do the work that does not depend on the result -- dispatch the other
-subagent, run the preflight below -- and then stop and wait. Wherever a prompt in this graph
-says to wait for a subagent to finish, that is what it means.
-
-Do not sleep to pass the time. Not `sleep`, not `/bin/sleep`, not a timer under another
-name, and not a loop that re-checks whether a result has arrived. Sleeping tells you nothing
-that waiting for the result does not, and it spends wall clock, which is one of the things
-this journey is measured on. One recorded run spent most of two hours asleep between
-dispatches that had all returned in seconds.
-
-Before you ask the developer any setup question, finish every read-only investigation and
-preflight check in this section.
-
-Prepare two research assignments. Give each research subagent one assignment. Tell it to run
-`npx --yes copilotkit@4.9.50 onboard read subagent/inspect-repository` 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. Require only its assigned packet.
-
-Start both research subagents in parallel:
-
-1. Spawn one research subagent. Assign it the project evidence packet.
-2. Spawn a second research subagent. Assign it the environment evidence packet.
-3. Start both research subagents. Then continue.
-
-Continue to the surface-control preflight.
-
-Prove whether your coding-agent environment has browser or device control. Do not assume it
-either way, and do not report what you expect to be true: a run that guesses here records a
-capability the rest of the graph then trusts. Use a browser or device tool already
-configured for the coding agent you are running as, the same way a later step uses the
-CopilotKit documentation server. With a browser tool, open one inert page such as
-`about:blank` and read its title. With a device tool and no browser, list the booted devices
-in one command: `adb devices -l`. Record the outcome of that attempt: `available` when the
-tool answered, `unavailable` when there was none to call or the page did not open. Use
-the control that matches the selected surface later.
-
-Where the browser probe answered, register nothing. The harness came equipped and the run
-owes it no setup.
-
-Where no browser tool answered, register one for the coding agent you are running as, then
-run the same probe again and record what the second attempt did. Register this server:
-
-```text
-npx --yes @playwright/mcp@latest --browser chrome --isolated --output-dir <project>/.copilotkit/proof/browser
-```
-
-Replace `<project>` with the absolute path of the target project directory. The server is
-registered against the coding agent rather than against a directory, so a relative path here
-resolves wherever that server happens to start.
-
-`--browser chrome` drives the Google Chrome the developer already has, so this downloads no
-browser. `--isolated` keeps the profile in memory, so it never touches their own Chrome
-profile. `--output-dir` is what keeps the snapshots and screenshots out of the developer's
-repository root: without it this server writes them to `.playwright-mcp/` beside their code,
-which a project that never asked for a browser has no reason to carry, and which the graph's
-own evidence rule already has a place for. Register it the way your own harness registers a
-server, which is the mechanism a later step uses for the CopilotKit documentation server.
-
-Tell the developer in one line what you registered, that it drives their installed Chrome,
-and that it lives in this coding agent's configuration rather than in their repository. Do
-not ask them to approve it, and do not ask a second question about it.
-
-Do not add a browser or device driver to the project. A driver added there is a
-devDependency and a browser download in the diff of a repository that never asked for one,
-which is a different thing from a server registered against the coding agent.
-
-Where the second probe still does not answer -- no Chrome to drive, no network, or a
-harness that cannot register a server -- record `unavailable` and carry it. Do not keep
-trying, and do not ask the developer about this tool limit.
-
-Registering a server does not boot a device. Where the device probe found none, that is the
-whole finding, and a browser is not a substitute for a device.
-
-Wait for both research subagents to finish.
-
-Then report that the research came back:
-
-```text
-npx --yes copilotkit@4.9.50 onboard checkpoint --phase research-returned
-```
-
-A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
-failed step.
-
-Continue only if both research results start with `Status: passed`. For `Status: failed`,
-retry only that packet with its failed items, up to three attempts. For `Status: blocked`,
-or a third failed result, use the stop route at the end of this prompt.
-
-Merge both evidence packets by item. On a conflict, spawn one fresh read-only verifier with
-the item, both cited findings, and the research limits. Require its result to start with
-`Status: passed`, `Status: failed`, or `Status: blocked`. Use only a passed cited result. Do
-not inspect the project to settle the conflict yourself. Use the stop route for a non-pass
-verifier result.
-
-Match environment evidence to the target app directory from the project packet. Require one
-target app directory and one matching environment row. If either packet gives no match or
-more than one match, send each research worker a focused directory check. Continue only when
-both workers return the same one target app directory. Both results must start with
-`Status: passed`. Otherwise, use the stop route.
-
-## Capture the protected-path baseline
-
-Before you route on, run this from the target app directory:
-
-```text
-npx --yes copilotkit@4.9.50 onboard protect
-```
-
-It reads the working tree itself, records every changed or untracked path with a digest,
-and prints the list. Require its result to start with `Status: passed`.
-
-Use the printed list as the protected path list for the rest of the run. Do not assemble
-that list yourself, and do not ask a subagent to hold it: every later audit reads the
-captured baseline back from the CLI, so no step depends on a subagent that has since
-finished.
-
-Paths printed as `deferred` are the ones onboarding itself writes, `.env` and
-`.copilotkit/project.json`. Every audit reports them and none fails on them until the step
-that writes them re-captures them, so a run whose only untracked files are the two this
-graph exists to create is never stopped by them.
-
-If the result starts with `Status: blocked`, report the printed reason and use the stop
-route at the end of this prompt.
-
-## What the merged findings must contain
-
-If a repository file exists, each finding must cite it. For an empty project, the subagents
-must cite the directory check and report absent parts.
-
-The findings must cover what the project is for, the agent, frontend, CopilotKit setup,
-authentication, credential names, and validation path. Do not ask the developer for facts
-that the repository answers.
-
-## Route on the merged findings
-
-Read the route off the merged findings. Three of them decide it, and you already hold all
-three:
-
-1. an agent is present,
-2. a frontend is present,
-3. a CopilotKit integration is present.
-
-Do not infer a working OSS path from packages, imports, project files, or keys, and do not
-settle these three from your own reading of the project. Each one comes from the merged
-packets or it is not proved.
-
-If all three are proved, prove the live starting state before any project file changes. Run
-`npx --yes copilotkit@4.9.50 onboard read proof/oss-baseline`.
-
-Route there before you ask the developer anything else. The questions after this prompt
-select a framework and a frontend that the findings already name, so a developer who
-answers them has answered for work the next node exists to check. Their existing
-application is what that node protects. Whether it works is what the proof decides, not
-these three findings.
-
-For every other combination of the three, take one more step first. If neither the
-developer nor the repository findings prove what the project is for, ask one guided
-question about the user outcome. This asks what the developer wants to build before you
-select a framework. Give two or three short examples and offer a minimal starter. Record
-the answer and give it to each later subagent. Then run
-`npx --yes copilotkit@4.9.50 onboard read credentials/plan`.
-
-Do not ask that question on the route above. A project carrying all three states its
-purpose in the application it already serves.
+When sign-in is settled, run
+`npx --yes copilotkit@4.10.0 onboard read research/gather`.
 
-If authentication or inspection stops onboarding, run
-`npx --yes copilotkit@4.9.50 onboard read unsupported/no-validated-path`.
+If sign-in stops onboarding, run
+`npx --yes copilotkit@4.10.0 onboard read stopped/run-failed`. It says nothing about
+whether this project's stack is supported, which is not yet known at this point.

package/onboarding/prompts/conversion/plan.md

@@ -100,7 +100,7 @@ of this journey, and a drawer that lists nothing is not a reason to mint one. Li
 tokens stay a self-hosted concern.
 
 Where this journey's frontend framework ships no threads drawer -- React Native --, the
-fifth item is proved by `npx --yes copilotkit@4.9.50 verify --round-trip`, which sends a
+fifth item is proved by `npx --yes copilotkit@4.10.0 verify --round-trip`, which sends a
 real request and reads the answer back off the thread it landed on. The run says which of
 the two it proved. Do not send a run to the managed Intelligence dashboard to prove this.
 An authenticated browser session at a hosted dashboard is the one thing an agent-driven run
@@ -116,7 +116,7 @@ and passed -- so a run scored on either one was scored on the same fact. Every r
 resolves that condition from, while `licenseStatus` is a compatibility projection of it
 for older thread surfaces and outlives them only until those surfaces go.
 
-Then run `npx --yes copilotkit@4.9.50 onboard read credentials/finalize-plan`.
+Then run `npx --yes copilotkit@4.10.0 onboard read credentials/finalize-plan`.
 
 If a selected page does not load after the second method, run
-`npx --yes copilotkit@4.9.50 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.10.0 onboard read unsupported/no-validated-path`.