copilotkit 4.9.37 → 4.9.50

package/onboarding/index.json

@@ -1,5 +1,14 @@
 {
-  "graphTree": "58b803347fcc8e7c63409e4dd783b37f03451d8a",
+  "graphTree": "249d03371764b775fd5893026d7869bbf83716d6",
+  "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.37 onboard start --run <onboarding_run_id>` in the directory
+`npx --yes copilotkit@4.9.50 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.
@@ -50,7 +50,7 @@ without another developer question. The CLI telemetry gate decides whether the r
 sent.
 
 ```text
-npx --yes copilotkit@4.9.37 onboard feedback
+npx --yes copilotkit@4.9.50 onboard feedback
 ```
 
 Write at most four lines to the command's standard input: the step you stopped at and what
@@ -67,19 +67,36 @@ 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.37 login --json` before any project work. This command
+Run `npx --yes copilotkit@4.9.50 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.
 
 Read each JSON Lines record as the running command writes it:
 
-1. If the process emits `authentication_url`, show the `authentication_url` to the
-   developer as soon as that line arrives. The process is still running.
-2. Tell the developer to open the URL and finish sign-in.
-3. Keep monitoring the same process after you show the URL. Do not start a second login
-   command.
-4. Continue onboarding only after that same process emits `type: completed`.
-5. If that process emits `type: failed`, report the error and stop onboarding.
+1. If the process emits `type: completed` without an `authentication_url`, continue. The
+   existing session is valid and there is no page to open.
+2. If the process emits `authentication_url`, read the first `authentication_url` without
+   changing it. The process is still running.
+   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.
+
+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
+   for the host operating system:
+   - macOS: `open "<authentication_url>"`
+   - Linux: `xdg-open "<authentication_url>"`
+   - Windows PowerShell: `Start-Process "<authentication_url>"`
+     Replace the placeholder with the exact URL and pass it as one quoted argument. Do not
+     append, remove, decode, or re-encode any part of it.
+4. If the matching opener is unavailable or exits with an error, show the clickable URL to
+   the developer and ask them to finish sign-in there. Do not retry the opener.
+5. Keep monitoring the original login process after the open attempt. Do not start a
+   second login command. Do not treat the opener command finishing as sign-in finishing.
+6. Continue onboarding only after that same process emits `type: completed`.
+7. If that process emits `type: failed`, report the error and stop onboarding.
 
 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.
@@ -107,7 +124,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.37 onboard read subagent/inspect-repository` first and follow the
+`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.
@@ -172,7 +189,7 @@ Wait for both research subagents to finish.
 Then report that the research came back:
 
 ```text
-npx --yes copilotkit@4.9.37 onboard checkpoint --phase research-returned
+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
@@ -199,7 +216,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.37 onboard protect
+npx --yes copilotkit@4.9.50 onboard protect
 ```
 
 It reads the working tree itself, records every changed or untracked path with a digest,
@@ -241,7 +258,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.37 onboard read proof/oss-baseline`.
+`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
@@ -254,10 +271,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.37 onboard read credentials/plan`.
+`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.
 
 If authentication or inspection stops onboarding, run
-`npx --yes copilotkit@4.9.37 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.50 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.37 verify --round-trip`, which sends a
+fifth item is proved by `npx --yes copilotkit@4.9.50 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.37 onboard read credentials/finalize-plan`.
+Then run `npx --yes copilotkit@4.9.50 onboard read credentials/finalize-plan`.
 
 If a selected page does not load after the second method, run
-`npx --yes copilotkit@4.9.37 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.50 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.37 onboard feedback
+npx --yes copilotkit@4.9.50 onboard feedback
 ```
 
 Write at most four lines to standard input: the step you stopped at and what stopped it.
@@ -46,7 +46,7 @@ starts. Choose one starting state: empty, agent-only, frontend-only, both, both-
 Run this command with the exact selected slugs:
 
 ```text
-npx --yes copilotkit@4.9.37 onboard classify --starting-state <starting-state> --agent-framework <agent-framework> --frontend <frontend>
+npx --yes copilotkit@4.9.50 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 +140,7 @@ passes against the wrong one.
 Create it, from the target directory:
 
 ```text
-npx --yes copilotkit@4.9.37 project select --create <name> --json
+npx --yes copilotkit@4.9.50 project select --create <name> --json
 ```
 
 If the command fails as a duplicate, the organization already holds that display name and
@@ -154,13 +154,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.37 project list --json
+npx --yes copilotkit@4.9.50 project list --json
 ```
 
 Narrow them:
 
 ```text
-npx --yes copilotkit@4.9.37 project list --search <query> --json
+npx --yes copilotkit@4.9.50 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 +172,7 @@ this directory's.
 Then record the project they name, from the target directory:
 
 ```text
-npx --yes copilotkit@4.9.37 project select --project <slug-or-id> --json
+npx --yes copilotkit@4.9.50 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 +236,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.37 onboard protect --path <path>
+npx --yes copilotkit@4.9.50 onboard protect --path <path>
 ```
 
 Pass one `--path` for each. The command captures a digest for each path and never re-reads
@@ -246,7 +246,7 @@ 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.37 onboard protect --rebaseline --path <path>
+npx --yes copilotkit@4.9.50 onboard protect --rebaseline --path <path>
 ```
 
 From that point they are protected like any other path, so a later step that rewrites
@@ -263,14 +263,14 @@ browser, and never touches the platform.
 Add these pages to the selected documentation URLs for the planning, implementation, and
 proof subagents:
 
-- https://docs.copilotkit.ai/premium/connect-your-runtime.md
+- https://docs.copilotkit.ai/intelligence/connect-your-runtime.md
 - https://docs.copilotkit.ai/backend/runtime-endpoints.md
-- https://docs.copilotkit.ai/premium/managed-intelligence-platform.md
+- https://docs.copilotkit.ai/intelligence/managed-intelligence-platform.md
 
 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.37 onboard read subagent/create-plan` first and follow the prompt
+`npx --yes copilotkit@4.9.50 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
@@ -296,7 +296,7 @@ approve rather than in the implementation that follows. Do not upgrade a depende
 developer did not approve.
 
 If the developer approves the plan, run
-`npx --yes copilotkit@4.9.37 onboard read implementation/build-and-validate`.
+`npx --yes copilotkit@4.9.50 onboard read implementation/build-and-validate`.
 
 If no exact supported path or documentation URL exists, run
-`npx --yes copilotkit@4.9.37 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.50 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.37 onboard read framework/ag2`
-2. Agno: `npx --yes copilotkit@4.9.37 onboard read framework/agno`
-3. Built-in CopilotKit agent: `npx --yes copilotkit@4.9.37 onboard read framework/built-in`
-4. Claude Agent SDK Python: `npx --yes copilotkit@4.9.37 onboard read framework/claude-sdk-python`
-5. Claude Agent SDK TypeScript: `npx --yes copilotkit@4.9.37 onboard read framework/claude-sdk-typescript`
-6. CrewAI Flows: `npx --yes copilotkit@4.9.37 onboard read framework/crewai-flows`
-7. Deep Agents: `npx --yes copilotkit@4.9.37 onboard read framework/deep-agents`
-8. LangGraph Python: `npx --yes copilotkit@4.9.37 onboard read framework/langgraph-python`
-9. LangGraph FastAPI: `npx --yes copilotkit@4.9.37 onboard read framework/langgraph-fastapi`
-10. LangGraph TypeScript: `npx --yes copilotkit@4.9.37 onboard read framework/langgraph-typescript`
-11. LlamaIndex: `npx --yes copilotkit@4.9.37 onboard read framework/llamaindex`
-12. ADK: `npx --yes copilotkit@4.9.37 onboard read framework/google-adk`
-13. Microsoft Agent Framework Python: `npx --yes copilotkit@4.9.37 onboard read framework/ms-agent-python`
-14. Microsoft Agent Framework .NET: `npx --yes copilotkit@4.9.37 onboard read framework/ms-agent-dotnet`
-15. Mastra: `npx --yes copilotkit@4.9.37 onboard read framework/mastra`
-16. MS Agent Harness .NET: `npx --yes copilotkit@4.9.37 onboard read framework/ms-agent-harness-dotnet`
-17. Pydantic AI: `npx --yes copilotkit@4.9.37 onboard read framework/pydantic-ai`
-18. Strands Agents Python: `npx --yes copilotkit@4.9.37 onboard read framework/strands-python`
-19. Strands Agents TypeScript: `npx --yes copilotkit@4.9.37 onboard read framework/strands-typescript`
+1. AG2: `npx --yes copilotkit@4.9.50 onboard read framework/ag2`
+2. Agno: `npx --yes copilotkit@4.9.50 onboard read framework/agno`
+3. Built-in CopilotKit agent: `npx --yes copilotkit@4.9.50 onboard read framework/built-in`
+4. Claude Agent SDK Python: `npx --yes copilotkit@4.9.50 onboard read framework/claude-sdk-python`
+5. Claude Agent SDK TypeScript: `npx --yes copilotkit@4.9.50 onboard read framework/claude-sdk-typescript`
+6. CrewAI Flows: `npx --yes copilotkit@4.9.50 onboard read framework/crewai-flows`
+7. Deep Agents: `npx --yes copilotkit@4.9.50 onboard read framework/deep-agents`
+8. LangGraph Python: `npx --yes copilotkit@4.9.50 onboard read framework/langgraph-python`
+9. LangGraph FastAPI: `npx --yes copilotkit@4.9.50 onboard read framework/langgraph-fastapi`
+10. LangGraph TypeScript: `npx --yes copilotkit@4.9.50 onboard read framework/langgraph-typescript`
+11. LlamaIndex: `npx --yes copilotkit@4.9.50 onboard read framework/llamaindex`
+12. ADK: `npx --yes copilotkit@4.9.50 onboard read framework/google-adk`
+13. Microsoft Agent Framework Python: `npx --yes copilotkit@4.9.50 onboard read framework/ms-agent-python`
+14. Microsoft Agent Framework .NET: `npx --yes copilotkit@4.9.50 onboard read framework/ms-agent-dotnet`
+15. Mastra: `npx --yes copilotkit@4.9.50 onboard read framework/mastra`
+16. MS Agent Harness .NET: `npx --yes copilotkit@4.9.50 onboard read framework/ms-agent-harness-dotnet`
+17. Pydantic AI: `npx --yes copilotkit@4.9.50 onboard read framework/pydantic-ai`
+18. Strands Agents Python: `npx --yes copilotkit@4.9.50 onboard read framework/strands-python`
+19. Strands Agents TypeScript: `npx --yes copilotkit@4.9.50 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.37 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.50 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.37 onboard feedback
+npx --yes copilotkit@4.9.50 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.37 onboard audit` from the target app directory.
+- Run `npx --yes copilotkit@4.9.50 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.37 onboard protect --accept-external --path <path>`, run the
+  `npx --yes copilotkit@4.9.50 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.37 onboard complete`, carrying the
+When the proof is complete, run `npx --yes copilotkit@4.9.50 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.37 onboard complete --visual-check <outcome>
-npx --yes copilotkit@4.9.37 onboard complete --device-check <outcome>
+npx --yes copilotkit@4.9.50 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.9.50 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.50 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.50 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.50 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.50 onboard checkpoint --phase journey-attempted --attempt 1
+```
+
+Report each repair cycle the same way, counting from one:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+When the actual surface was driven, run
+`npx --yes copilotkit@4.9.50 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`.

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

@@ -0,0 +1,55 @@
+# Add A2UI to the existing CopilotKit app
+
+Treat this as an additive OSS feature integration, not a new-app scaffold. Act as the
+orchestrator and delegate inspection, implementation, and proof to focused subagents.
+Work only inside the target project. Do not show internal prompt names to the developer.
+
+Before changing files, send a short welcome that says you will inspect the existing app,
+show an A2UI plan, implement only after approval, and prove a rendered surface in the real
+UI. Then spawn one read-only subagent to locate the current CopilotKit runtime, provider,
+chat surface, agent id, package versions, existing A2UI configuration, and the normal
+development/test commands. It must return paths and secret-safe presence checks only.
+
+Require an existing frontend, agent, and CopilotKit round trip. Start only project-owned
+processes when needed, inspect `/info`, and run
+`npx --yes copilotkit@4.9.50 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
+Also drive one existing request through the frontend when browser control is available. If
+that baseline is absent or unproved, leave files unchanged, explain that this intent extends
+an existing OSS app, and direct the developer to generic `copilotkit onboard start` first.
+
+Wait for the inspection subagent to finish. Then report that the inspection 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.
+
+If the inspection did not prove the baseline this intent extends, stop here without
+changing files:
+
+```text
+npx --yes copilotkit@4.9.50 onboard read feature/stop
+```
+
+Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
+credential, or replace the existing agent, runtime, persistence, or chat surface. A2UI can
+be added to an OSS runtime.
+
+Fetch the current official A2UI guide before forming the plan:
+https://docs.copilotkit.ai/generative-ui/a2ui.md
+Fetch it a second way if the first fetch fails. Use only APIs that the fetched guide and the
+installed package versions support.
+
+Show a concise plan that names the existing runtime/provider files, the smallest A2UI
+catalog or runtime wiring required, the test command, and a browser proof request that
+renders a compact visible surface. Ask for plan approval as its own question.
+
+After approval, report the plan this run is about to implement:
+
+```text
+npx --yes copilotkit@4.9.50 onboard checkpoint --phase plan-written
+```
+
+Then run `npx --yes copilotkit@4.9.50 onboard read feature/a2ui/implement`.

package/onboarding/prompts/feature/chat-suggestions/implement.md

@@ -0,0 +1,28 @@
+# Implement chat suggestions at the existing provider boundary
+
+Delegate implementation to one subagent with the approved mode and the official hook guide.
+Configure `useConfigureSuggestions` at the existing CopilotKit provider/chat surface using
+only documented APIs for the installed version. Preserve the agent, runtime route, existing
+message behavior, and current empty/welcome state.
+
+For static mode, choose concise, domain-appropriate prompts supported by the existing agent;
+do not invent unsupported product actions. For dynamic mode, use the project's actual
+available context and retain a safe empty state. Do not add Intelligence, credentials, or a
+standalone mock UI.
+
+Run focused type/test checks and start the app. Record the changed files and validation.
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.9.50 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.50 onboard read feature/stop
+```
+
+Otherwise run
+`npx --yes copilotkit@4.9.50 onboard read feature/chat-suggestions/proof`.