copilotkit 4.9.47 → 4.9.60

package/onboarding/index.json

@@ -1,5 +1,14 @@
 {
-  "graphTree": "630f2a1b698d11d931b16475f2decb78cd256de9",
+  "graphTree": "17c99aa34ab1293ba344b5f6ff0f5eb9d05b0055",
+  "intentRoots": {
+    "add-a2ui": "feature/a2ui/start",
+    "add-chat-suggestions": "feature/chat-suggestions/start",
+    "add-learning": "feature/learning/start",
+    "add-open-generative-ui": "feature/open-generative-ui/start",
+    "add-realtime-sync": "feature/realtime-sync/start",
+    "add-rich-threads": "feature/rich-threads/start",
+    "add-voice": "feature/voice/start"
+  },
   "root": "authenticate/start",
   "prompts": [
     {
@@ -60,6 +69,158 @@
       "milestone": "fallback",
       "name": "fallback/best-effort"
     },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/a2ui/proof"
+      ],
+      "milestone": "feature",
+      "name": "feature/a2ui/implement"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/a2ui/proof"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/a2ui/implement"
+      ],
+      "milestone": "feature",
+      "name": "feature/a2ui/start"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/chat-suggestions/proof"
+      ],
+      "milestone": "feature",
+      "name": "feature/chat-suggestions/implement"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/chat-suggestions/proof"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/chat-suggestions/implement"
+      ],
+      "milestone": "feature",
+      "name": "feature/chat-suggestions/start"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/learning/proof"
+      ],
+      "milestone": "feature",
+      "name": "feature/learning/implement"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/learning/proof"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/learning/implement"
+      ],
+      "milestone": "feature",
+      "name": "feature/learning/start"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/open-generative-ui/proof"
+      ],
+      "milestone": "feature",
+      "name": "feature/open-generative-ui/implement"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/open-generative-ui/proof"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/open-generative-ui/implement"
+      ],
+      "milestone": "feature",
+      "name": "feature/open-generative-ui/start"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/realtime-sync/proof"
+      ],
+      "milestone": "feature",
+      "name": "feature/realtime-sync/implement"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/realtime-sync/proof"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/realtime-sync/implement"
+      ],
+      "milestone": "feature",
+      "name": "feature/realtime-sync/start"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/rich-threads/proof"
+      ],
+      "milestone": "feature",
+      "name": "feature/rich-threads/implement"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/rich-threads/proof"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/rich-threads/implement"
+      ],
+      "milestone": "feature",
+      "name": "feature/rich-threads/start"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/stop"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/voice/proof"
+      ],
+      "milestone": "feature",
+      "name": "feature/voice/implement"
+    },
+    {
+      "edges": [],
+      "milestone": "feature",
+      "name": "feature/voice/proof"
+    },
+    {
+      "edges": [
+        "feature/stop",
+        "feature/voice/implement"
+      ],
+      "milestone": "feature",
+      "name": "feature/voice/start"
+    },
     {
       "edges": [
         "frontend/plan",

package/onboarding/prompts/authenticate/start.md

@@ -16,7 +16,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.47 onboard start --run <onboarding_run_id>` in the directory
+`npx --yes copilotkit@4.9.60 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 +30,20 @@ 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 every conversation it holds is kept on the managed Intelligence platform. 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
@@ -50,7 +61,7 @@ without another developer question. The CLI telemetry gate decides whether the r
 sent.
 
 ```text
-npx --yes copilotkit@4.9.47 onboard feedback
+npx --yes copilotkit@4.9.60 onboard feedback
 ```
 
 Write at most four lines to the command's standard input: the step you stopped at and what
@@ -67,7 +78,22 @@ Until now the route out of an unsupported path was the only place that asked for
 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.47 login --json` before any project work. This command
+## Say which coding agent you are
+
+Report your own product with one short slug, such as `codex` or `claude-code`:
+
+```text
+npx --yes copilotkit@4.9.60 onboard identify --coding-agent <coding-agent-slug>
+```
+
+Run it before the sign-in command below. The slug tells the sign-in page which agent
+sent the developer, so the page names you instead of "your coding agent". It labels this
+run and nothing else: it grants no access and gates no step.
+
+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.
+
+Run `npx --yes copilotkit@4.9.60 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 +106,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, which is what lets your app keep every conversation it holds. You can
+   remove the key 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
@@ -124,7 +151,7 @@ Before you ask the developer any setup question, finish every read-only investig
 preflight check in this section.
 
 Prepare two research assignments. Give each research subagent one assignment. Tell it to run
-`npx --yes copilotkit@4.9.47 onboard read subagent/inspect-repository` first and follow the
+`npx --yes copilotkit@4.9.60 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.
@@ -189,7 +216,7 @@ Wait for both research subagents to finish.
 Then report that the research came back:
 
 ```text
-npx --yes copilotkit@4.9.47 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -216,7 +243,7 @@ both workers return the same one target app directory. Both results must start w
 Before you route on, run this from the target app directory:
 
 ```text
-npx --yes copilotkit@4.9.47 onboard protect
+npx --yes copilotkit@4.9.60 onboard protect
 ```
 
 It reads the working tree itself, records every changed or untracked path with a digest,
@@ -258,7 +285,7 @@ settle these three from your own reading of the project. Each one comes from the
 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.47 onboard read proof/oss-baseline`.
+`npx --yes copilotkit@4.9.60 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
@@ -271,10 +298,10 @@ developer nor the repository findings prove what the project is for, ask one gui
 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.47 onboard read credentials/plan`.
+`npx --yes copilotkit@4.9.60 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.
 
 If authentication or inspection stops onboarding, run
-`npx --yes copilotkit@4.9.47 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.60 onboard read unsupported/no-validated-path`.

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.47 verify --round-trip`, which sends a
+fifth item is proved by `npx --yes copilotkit@4.9.60 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.47 onboard read credentials/finalize-plan`.
+Then run `npx --yes copilotkit@4.9.60 onboard read credentials/finalize-plan`.
 
 If a selected page does not load after the second method, run
-`npx --yes copilotkit@4.9.47 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.60 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/credentials/finalize-plan.md

@@ -23,7 +23,7 @@ stop. Run the feedback command without another developer question. The CLI telem
 decides whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.47 onboard feedback
+npx --yes copilotkit@4.9.60 onboard feedback
 ```
 
 Write at most four lines to standard input: the step you stopped at and what stopped it.
@@ -35,18 +35,26 @@ not a route change and does not resume the run.
 ## Record the audit cell
 
 Use the repository findings and selected choices to record the path before project work
-starts. Choose one starting state: empty, agent-only, frontend-only, both, both-oss.
+starts. Choose one starting state: empty, agent-only, frontend-only, both,
+both-copilotkit-unproved, both-oss.
 
 - `empty`: no agent and no frontend.
 - `agent-only`: an agent and no frontend.
 - `frontend-only`: a frontend and no agent.
-- `both`: an agent and frontend that do not have a proved CopilotKit round trip.
+- `both`: an agent and frontend with no CopilotKit integration.
+- `both-copilotkit-unproved`: an agent, a frontend and a CopilotKit integration whose
+  round trip did not prove.
 - `both-oss`: an agent and frontend with the proved OSS CopilotKit baseline.
 
+The last two are the states of a project that has CopilotKit, and the baseline proof
+decides which one is true. A run served `proof/oss-baseline` records one of them. The
+first four say that an agent, a frontend, or the CopilotKit integration is absent, and
+the command refuses one of them from a run that was served that node.
+
 Run this command with the exact selected slugs:
 
 ```text
-npx --yes copilotkit@4.9.47 onboard classify --starting-state <starting-state> --agent-framework <agent-framework> --frontend <frontend>
+npx --yes copilotkit@4.9.60 onboard classify --starting-state <starting-state> --agent-framework <agent-framework> --frontend <frontend>
 ```
 
 Do not continue if a value is refused. Fix the value from the choices that the earlier
@@ -140,7 +148,7 @@ passes against the wrong one.
 Create it, from the target directory:
 
 ```text
-npx --yes copilotkit@4.9.47 project select --create <name> --json
+npx --yes copilotkit@4.9.60 project select --create <name> --json
 ```
 
 If the command fails as a duplicate, the organization already holds that display name and
@@ -154,13 +162,13 @@ Take this branch only when the developer asks for an existing project, or asks t
 projects they have. Read the choices:
 
 ```text
-npx --yes copilotkit@4.9.47 project list --json
+npx --yes copilotkit@4.9.60 project list --json
 ```
 
 Narrow them:
 
 ```text
-npx --yes copilotkit@4.9.47 project list --search <query> --json
+npx --yes copilotkit@4.9.60 project list --search <query> --json
 ```
 
 With `--json` the payload is the only thing on standard output, so it is safe to parse. Do
@@ -172,7 +180,7 @@ this directory's.
 Then record the project they name, from the target directory:
 
 ```text
-npx --yes copilotkit@4.9.47 project select --project <slug-or-id> --json
+npx --yes copilotkit@4.9.60 project select --project <slug-or-id> --json
 ```
 
 The two flags cannot be combined. A slug that does not exist fails and lists the real ones,
@@ -236,7 +244,7 @@ protected path list. Also add each project file that the developer changed for m
 credentials. Record them in the baseline from the target app directory:
 
 ```text
-npx --yes copilotkit@4.9.47 onboard protect --path <path>
+npx --yes copilotkit@4.9.60 onboard protect --path <path>
 ```
 
 Pass one `--path` for each. The command captures a digest for each path and never re-reads
@@ -246,13 +254,39 @@ Then re-capture the files this graph wrote itself. For each path the first captu
 as `deferred` that this run has now written, run:
 
 ```text
-npx --yes copilotkit@4.9.47 onboard protect --rebaseline --path <path>
+npx --yes copilotkit@4.9.60 onboard protect --rebaseline --path <path>
 ```
 
 From that point they are protected like any other path, so a later step that rewrites
 `.env` and drops its key fails the audit rather than passing it. Continue only if every
 result starts with `Status: passed`.
 
+### When the developer writes a credential after the baseline
+
+Asking the developer to place a credential themselves means their edit lands when they get
+to it, and often after the paths above are captured. A later audit then reports the
+environment path as changed. That change is the one this run asked for, so it is not
+damage, and the credential route is how the run says so.
+
+Do not run that route here as a step of its own. Run it only when an audit names the
+environment path. The command below is what to run at that point, from the target app
+directory:
+
+```text
+npx --yes copilotkit@4.9.60 onboard protect --accept-credential --path <environment path>
+```
+
+The command compares the variable names the baseline recorded with the names the file holds
+now. Read its result:
+
+- `Status: passed` means the developer added a credential and every recorded credential is
+  still there. Carry the accepted path into the summary.
+- `credential-lost` means a variable the baseline recorded is gone or empty, and the
+  refusal names it. Do not repair or rewrite the file. Report the named variable and stop
+  onboarding. A run that lost the project key has nothing to prove a round trip with.
+- `unchanged-path` means the file matches its baseline, so nothing was placed in it. That
+  is not a failed step. It answers the question and the run carries on.
+
 ## Wire the runtime to Intelligence
 
 The key in `.env` does nothing on its own. The runtime reads no environment variable for
@@ -270,7 +304,7 @@ proof subagents:
 Fetch them together with the pages already selected rather than on their own.
 
 Spawn one planning subagent. Tell it to run
-`npx --yes copilotkit@4.9.47 onboard read subagent/create-plan` first and follow the prompt
+`npx --yes copilotkit@4.9.60 onboard read subagent/create-plan` 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, selected framework, frontend, model, credential
@@ -295,8 +329,15 @@ An upgrade to a working install is the developer's call, so it belongs in the pl
 approve rather than in the implementation that follows. Do not upgrade a dependency the
 developer did not approve.
 
+When you ask for approval, tell the developer in one line that this is the last thing you
+need from them, and that they can leave the run once they approve. That is a fact about
+this graph rather than a reassurance: no step after approval asks the developer a question,
+and the steps that follow are the longest ones in the run. A developer who does not know
+that waits at the terminal through all of them for a question that never comes. Say it in
+the same message as the plan, and do not turn it into a second question.
+
 If the developer approves the plan, run
-`npx --yes copilotkit@4.9.47 onboard read implementation/build-and-validate`.
+`npx --yes copilotkit@4.9.60 onboard read implementation/build-and-validate`.
 
 If no exact supported path or documentation URL exists, run
-`npx --yes copilotkit@4.9.47 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.60 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/credentials/plan.md

@@ -68,26 +68,26 @@ another framework. Do not show the internal route.
 
 Use exactly one matching internal route:
 
-1. AG2: `npx --yes copilotkit@4.9.47 onboard read framework/ag2`
-2. Agno: `npx --yes copilotkit@4.9.47 onboard read framework/agno`
-3. Built-in CopilotKit agent: `npx --yes copilotkit@4.9.47 onboard read framework/built-in`
-4. Claude Agent SDK Python: `npx --yes copilotkit@4.9.47 onboard read framework/claude-sdk-python`
-5. Claude Agent SDK TypeScript: `npx --yes copilotkit@4.9.47 onboard read framework/claude-sdk-typescript`
-6. CrewAI Flows: `npx --yes copilotkit@4.9.47 onboard read framework/crewai-flows`
-7. Deep Agents: `npx --yes copilotkit@4.9.47 onboard read framework/deep-agents`
-8. LangGraph Python: `npx --yes copilotkit@4.9.47 onboard read framework/langgraph-python`
-9. LangGraph FastAPI: `npx --yes copilotkit@4.9.47 onboard read framework/langgraph-fastapi`
-10. LangGraph TypeScript: `npx --yes copilotkit@4.9.47 onboard read framework/langgraph-typescript`
-11. LlamaIndex: `npx --yes copilotkit@4.9.47 onboard read framework/llamaindex`
-12. ADK: `npx --yes copilotkit@4.9.47 onboard read framework/google-adk`
-13. Microsoft Agent Framework Python: `npx --yes copilotkit@4.9.47 onboard read framework/ms-agent-python`
-14. Microsoft Agent Framework .NET: `npx --yes copilotkit@4.9.47 onboard read framework/ms-agent-dotnet`
-15. Mastra: `npx --yes copilotkit@4.9.47 onboard read framework/mastra`
-16. MS Agent Harness .NET: `npx --yes copilotkit@4.9.47 onboard read framework/ms-agent-harness-dotnet`
-17. Pydantic AI: `npx --yes copilotkit@4.9.47 onboard read framework/pydantic-ai`
-18. Strands Agents Python: `npx --yes copilotkit@4.9.47 onboard read framework/strands-python`
-19. Strands Agents TypeScript: `npx --yes copilotkit@4.9.47 onboard read framework/strands-typescript`
+1. AG2: `npx --yes copilotkit@4.9.60 onboard read framework/ag2`
+2. Agno: `npx --yes copilotkit@4.9.60 onboard read framework/agno`
+3. Built-in CopilotKit agent: `npx --yes copilotkit@4.9.60 onboard read framework/built-in`
+4. Claude Agent SDK Python: `npx --yes copilotkit@4.9.60 onboard read framework/claude-sdk-python`
+5. Claude Agent SDK TypeScript: `npx --yes copilotkit@4.9.60 onboard read framework/claude-sdk-typescript`
+6. CrewAI Flows: `npx --yes copilotkit@4.9.60 onboard read framework/crewai-flows`
+7. Deep Agents: `npx --yes copilotkit@4.9.60 onboard read framework/deep-agents`
+8. LangGraph Python: `npx --yes copilotkit@4.9.60 onboard read framework/langgraph-python`
+9. LangGraph FastAPI: `npx --yes copilotkit@4.9.60 onboard read framework/langgraph-fastapi`
+10. LangGraph TypeScript: `npx --yes copilotkit@4.9.60 onboard read framework/langgraph-typescript`
+11. LlamaIndex: `npx --yes copilotkit@4.9.60 onboard read framework/llamaindex`
+12. ADK: `npx --yes copilotkit@4.9.60 onboard read framework/google-adk`
+13. Microsoft Agent Framework Python: `npx --yes copilotkit@4.9.60 onboard read framework/ms-agent-python`
+14. Microsoft Agent Framework .NET: `npx --yes copilotkit@4.9.60 onboard read framework/ms-agent-dotnet`
+15. Mastra: `npx --yes copilotkit@4.9.60 onboard read framework/mastra`
+16. MS Agent Harness .NET: `npx --yes copilotkit@4.9.60 onboard read framework/ms-agent-harness-dotnet`
+17. Pydantic AI: `npx --yes copilotkit@4.9.60 onboard read framework/pydantic-ai`
+18. Strands Agents Python: `npx --yes copilotkit@4.9.60 onboard read framework/strands-python`
+19. Strands Agents TypeScript: `npx --yes copilotkit@4.9.60 onboard read framework/strands-typescript`
 
 If the project has an agent in another framework, or no listed framework fits, keep the
 developer's current agent and run
-`npx --yes copilotkit@4.9.47 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.60 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/fallback/best-effort.md

@@ -14,7 +14,7 @@ command without another developer question. The CLI telemetry gate decides wheth
 report is sent.
 
 ```text
-npx --yes copilotkit@4.9.47 onboard feedback
+npx --yes copilotkit@4.9.60 onboard feedback
 ```
 
 Write at most four lines to standard input: the step you stopped at and what stopped it.
@@ -56,13 +56,13 @@ stop.
 
 Use these rules for every protected-path check in this fallback:
 
-- Run `npx --yes copilotkit@4.9.47 onboard audit` from the target app directory.
+- Run `npx --yes copilotkit@4.9.60 onboard audit` from the target app directory.
 - If a result starts with `Status: blocked`, stop onboarding and report the printed reason.
   It proved nothing changed, so do not report a preservation failure.
 - If a result reports a changed protected path this run wrote, stop onboarding.
 - If a result reports a changed path that no Files changed section from this run names,
   the change came from outside the run. Accept it by name with
-  `npx --yes copilotkit@4.9.47 onboard protect --accept-external --path <path>`, run the
+  `npx --yes copilotkit@4.9.60 onboard protect --accept-external --path <path>`, run the
   audit again, and name it in the closing report.
 - If no Files changed section from this run covers the step that wrote it, stop
   onboarding. The proof subagent here returns no such section, so a finding it raises is
@@ -115,13 +115,13 @@ application passes proof. Report each tool result separately from the proof resu
 Report the documentation gap and each assumption with the proof evidence. Do not claim
 that the selected documentation proved an inferred step.
 
-When the proof is complete, run `npx --yes copilotkit@4.9.47 onboard complete`, carrying the
+When the proof is complete, run `npx --yes copilotkit@4.9.60 onboard complete`, carrying the
 surface-check result the proof subagent returned. Pass exactly one flag, matching this
 journey's surface:
 
 ```text
-npx --yes copilotkit@4.9.47 onboard complete --visual-check <outcome>
-npx --yes copilotkit@4.9.47 onboard complete --device-check <outcome>
+npx --yes copilotkit@4.9.60 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.60 onboard complete --device-check <outcome>
 ```
 
 `--visual-check` is for a web frontend and takes `performed`, `skipped-no-browser-tool`, or

package/onboarding/prompts/feature/a2ui/implement.md

@@ -0,0 +1,32 @@
+# Implement A2UI without changing the existing OSS architecture
+
+Delegate the change to one implementation subagent. Give it the approved plan, repository
+findings, and the official A2UI guide. It must fetch the guide before editing and preserve
+the existing agent, runtime route, provider, persistence, and chat behavior.
+
+Apply only the smallest documented A2UI wiring that fits this project: configure the runtime
+or provider catalog as the guide requires, add a renderer dependency only when the guide
+requires it, and keep the configuration close to the existing CopilotKit provider/runtime.
+Do not add Intelligence, a license key, a model key, a replacement agent, a fake tool result,
+or a custom visual mock to make the feature appear enabled.
+
+Run the repository's focused typecheck/test command and repair defects in changed files.
+Start the app with its documented command. Confirm `/info` reports the expected A2UI
+capability, but do not treat that flag as proof. Record changed paths and validation output
+without exposing secrets.
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase build-validated
+```
+
+If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
+without further changes:
+
+```text
+npx --yes copilotkit@4.9.60 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.60 onboard read feature/a2ui/proof`.

package/onboarding/prompts/feature/a2ui/proof.md

@@ -0,0 +1,34 @@
+# Prove that A2UI renders for a real user request
+
+Delegate proof to a separate subagent. Start only project-owned services and leave them
+running after proof. First run the existing OSS round trip and inspect `/info`. Read the `a2ui` object, not the
+flat `a2uiEnabled` boolean: A2UI can be scoped to named agents, and the boolean discards
+that, so it reads true on a runtime whose `a2ui.agents` does not include the agent under
+test. Require the run's agent to be in `a2ui.agents`, or the list to be absent. Either way
+the capability is necessary and not sufficient.
+
+In the real frontend, send a small request that naturally asks the existing agent to render
+one compact card or control using A2UI. Require a visible rendered A2UI surface or operation
+in the chat, not only streamed tool arguments, an activity skeleton, or a server log. Record
+the input, visible result, app URL, process IDs, and safe stop commands. If browser control
+is unavailable, report that the browser proof is blocked rather than claiming success.
+
+Fix proof failures caused by changed files, then repeat the same proof. Do not replace the
+user's agent response with a hard-coded UI.
+
+Report each attempt at the proof as it ends, counting from one:
+
+```text
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+When the actual surface was driven, run
+`npx --yes copilotkit@4.9.60 onboard complete --visual-check performed`. If it could not
+be driven because no browser tool is available, run the same command with
+`--visual-check skipped-no-browser-tool`; if it failed, use `--visual-check failed`.