copilotkit 4.9.50 → 4.9.60

package/onboarding/index.json

@@ -1,5 +1,5 @@
 {
-  "graphTree": "249d03371764b775fd5893026d7869bbf83716d6",
+  "graphTree": "17c99aa34ab1293ba344b5f6ff0f5eb9d05b0055",
   "intentRoots": {
     "add-a2ui": "feature/a2ui/start",
     "add-chat-suggestions": "feature/chat-suggestions/start",

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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 project list --json
+npx --yes copilotkit@4.9.60 project list --json
 ```
 
 Narrow them:
 
 ```text
-npx --yes copilotkit@4.9.50 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.50 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.50 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.50 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.50 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.50 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.50 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.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`
+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.50 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.50 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.50 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.50 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.50 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.50 onboard complete --visual-check <outcome>
-npx --yes copilotkit@4.9.50 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

@@ -18,15 +18,15 @@ without exposing secrets.
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+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.50 onboard read feature/stop
+npx --yes copilotkit@4.9.60 onboard read feature/stop
 ```
 
 Otherwise run
-`npx --yes copilotkit@4.9.50 onboard read feature/a2ui/proof`.
+`npx --yes copilotkit@4.9.60 onboard read feature/a2ui/proof`.

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

@@ -19,16 +19,16 @@ 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
+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.50 onboard checkpoint --phase repair-attempted --attempt 1
+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.50 onboard complete --visual-check performed`. If it could not
+`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`.

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

@@ -12,7 +12,7 @@ development/test commands. It must return paths and secret-safe presence checks
 
 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`.
+`npx --yes copilotkit@4.9.60 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.
@@ -20,7 +20,7 @@ an existing OSS app, and direct the developer to generic `copilotkit onboard sta
 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
+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
@@ -30,7 +30,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.50 onboard read feature/stop
+npx --yes copilotkit@4.9.60 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -49,7 +49,7 @@ 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
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.50 onboard read feature/a2ui/implement`.
+Then run `npx --yes copilotkit@4.9.60 onboard read feature/a2ui/implement`.

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

@@ -14,15 +14,15 @@ Run focused type/test checks and start the app. Record the changed files and val
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+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.50 onboard read feature/stop
+npx --yes copilotkit@4.9.60 onboard read feature/stop
 ```
 
 Otherwise run
-`npx --yes copilotkit@4.9.50 onboard read feature/chat-suggestions/proof`.
+`npx --yes copilotkit@4.9.60 onboard read feature/chat-suggestions/proof`.

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

@@ -12,15 +12,15 @@ project-owned services running.
 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
+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.50 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 Run
-`npx --yes copilotkit@4.9.50 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
+`npx --yes copilotkit@4.9.60 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
 with the real browser-proof outcome.

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

@@ -5,7 +5,7 @@ implementation, and proof to separate subagents and keep all work inside the tar
 
 Before edits, identify the current CopilotKit provider, chat component, message lifecycle,
 agent id, package version, and test/dev commands. Prove the existing OSS round trip with
-`/info`, `npx --yes copilotkit@4.9.50 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --yes copilotkit@4.9.60 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
 and one real frontend request when browser control is available. If there is no proven
 existing CopilotKit chat, leave files unchanged and direct the developer to generic
 onboarding first.
@@ -13,7 +13,7 @@ onboarding 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
+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
@@ -23,7 +23,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.50 onboard read feature/stop
+npx --yes copilotkit@4.9.60 onboard read feature/stop
 ```
 
 Do not run login, provision Intelligence, request a credential, replace the agent, or alter
@@ -40,7 +40,7 @@ that a visible suggestion submits the intended message.
 After approval, report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.50 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.50 onboard read feature/chat-suggestions/implement`.
+Then run `npx --yes copilotkit@4.9.60 onboard read feature/chat-suggestions/implement`.

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

@@ -5,10 +5,72 @@ valid existing Intelligence selection. If it is absent, use the documented strea
 `login --json` session, let the developer select or create the Intelligence project, and
 require the secret-safe project/key provisioning summary before wiring the runtime.
 
-After the project is selected, ask the developer to create or select a stable Learning
-Container in the selected project's dashboard and provide its non-secret id. This is a real
-human gate: stop if they cannot provide it. Do not write a placeholder, a guessed id, or a
-new unsupported CLI command.
+After the project is selected, settle the container from the terminal.
+
+When the plan or the repository already names an id, ask about that one id and nothing else:
+
+```text
+npx --yes copilotkit@4.9.60 learning containers get <id> --json
+```
+
+One call answers it, and no list is needed.
+
+When no id is in hand, survey what the project holds:
+
+```text
+npx --yes copilotkit@4.9.60 learning containers list --json
+```
+
+One call returns at most 500 containers. When `nextCursor` in the result is not null, read
+the next page with `--cursor <nextCursor>` and keep going until it is null. A project whose
+container sits on the second page looks empty to a single call, and the run then adds a
+second container for work the first one already covers.
+
+Report what the read found before asking anyone anything:
+
+```text
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase container-surveyed
+```
+
+Everything after this waits on a person, so a run that stops past this point stopped on a
+decision rather than on a read.
+
+Reuse an existing container when one covers the workflow this run is instrumenting, and ask
+the developer which one when more than one could. Otherwise create one.
+
+Default to one container for this project, and name it after the project. Learning needs
+evidence to work with: the first automatic run wants threads from 15 distinct conversations
+in one container, so splitting a new project across several leaves every one of them below
+the line. One container per end user is the same trap and a harder one, because a project
+holds at most 500 and each user's own container then needs 15 conversations from that one
+person. Route per user only when the developer asks for it, and do it in their selector
+rather than in more containers: `getLearningContainerId` receives the resolved application
+user, so the callback can return a different id per tier or per customer.
+
+Use a descriptive lowercase hyphenated id of 1-64 characters:
+
+```text
+npx --yes copilotkit@4.9.60 learning containers create --id <id> --name <name> --json
+```
+
+An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
+read with `get` and reuse, not a failure to repair and not a reason to pick a new id.
+
+Confirm the id resolves before any file changes, whichever way it was settled. That check is
+the cheap one to keep: a selector wired to an id the platform does not hold returns
+`LEARNING_CONTAINER_NOT_FOUND` on every thread create and every run lock, so a working chat
+breaks on the next message. Stop here if the id does not resolve. Do not write a placeholder
+or a guessed id.
+
+Then report that the container is settled, before any edit:
+
+```text
+npx --yes copilotkit@4.9.60 onboard checkpoint --phase container-settled
+```
+
+Everything above happens between two prompts, so a run that stopped on a developer who could
+not choose, on a taken id, or on an id that never resolved would otherwise report the plan
+and then nothing at all.
 
 Add only the documented managed runtime/thread prerequisites and the selected
 `getLearningContainerId` on the `CopilotKitIntelligence` instance. Return the same stable
@@ -24,21 +86,21 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused tests and
-`npx --yes copilotkit@4.9.50 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.9.60 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record secret-safe evidence.
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.9.50 onboard checkpoint --phase build-validated
+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.50 onboard read feature/stop
+npx --yes copilotkit@4.9.60 onboard read feature/stop
 ```
 
 Otherwise run
-`npx --yes copilotkit@4.9.50 onboard read feature/learning/proof`.
+`npx --yes copilotkit@4.9.60 onboard read feature/learning/proof`.