copilotkit 4.13.0 → 4.14.0

package/onboarding/index.json

@@ -1,5 +1,5 @@
 {
-  "graphTree": "4f56a5f7891360d7a7d73ae2fd1d3ed4d6753a8b",
+  "graphTree": "3bdef9cbf4b02632fc8dfaa2a5b51cde7a2269eb",
   "intentRoots": {
     "add-a2ui": "feature/a2ui/start",
     "add-chat-suggestions": "feature/chat-suggestions/start",

package/onboarding/prompts/authenticate/start.md

@@ -15,15 +15,11 @@ does is hidden from the developer.
 Run this before anything else in this prompt, including the welcome message below:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard identify --coding-agent <coding-agent-slug>
+npx --yes copilotkit@4.14.0 onboard identify --coding-agent <coding-agent-slug>
 ```
 
 Report your own product with one short slug, such as `codex` or `claude-code`.
 
-It runs first because it is how this run reports that it started working. It needs no
-browser, no session, and no project, so nothing below it can prevent it. Every rule after
-this point can stop a run instead.
-
 ## How to run this onboarding
 
 Act only as the orchestrator. Rely on subagents for all project work.
@@ -42,10 +38,10 @@ printed once.
 Every later command must run from the directory this run started in. A command run
 somewhere else is refused, because the run it belongs to cannot be found from there. That
 refusal is a step, not a stop to report: run
-`npx --yes copilotkit@4.13.0 onboard start --run <onboarding_run_id>` where you are
+`npx --yes copilotkit@4.14.0 onboard start --run <onboarding_run_id>` where you are
 standing, then run the refused command again.
 
-If you no longer hold the id, run `npx --yes copilotkit@4.13.0 onboard start` in the
+If you no longer hold the id, run `npx --yes copilotkit@4.14.0 onboard start` in the
 directory this run started in, with no `--run` and no `--intent`. It reprints the id of the
 run under way and starts nothing. An id this project does not already hold starts a second
 run, and the work already done stops counting toward the first.
@@ -80,6 +76,11 @@ integration is the long part of this run, and I work through it without you. You
 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.
 
+If your harness makes the developer approve commands before they run, replace "you can walk
+away" through "without you." with: "I will ask you to approve some commands while I build.
+Keep this window open until the app runs." Decide this from your own approval policy, not
+from your coding-agent slug.
+
 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.
 
@@ -90,9 +91,8 @@ run says so once instead of asking again at each report.
 
 ## Where commands run
 
-Run every command from the directory this run started in. That directory is the run root,
-and every `--path` argument is read against it rather than against wherever you are
-standing, so one path names one file from anywhere in the project.
+The directory this run started in is the run root. Every `--path` argument is read against
+it, so one path names one file from anywhere in the project.
 
 One command is deliberately different. `project select` writes the credential into the
 `.env` beside the directory it runs in, because that is the file the application process
@@ -103,12 +103,12 @@ record to the repository root by itself and prints where it put it.
 
 This run reports its own stops. If you stop this run at any point, send one short report
 before you stop. That covers a stop this prompt names, a stop a later prompt names, and a
-stop no prompt anticipated, including one your own harness causes. Run the friction
-command without another developer question: it applies the telemetry setting the developer
-already set.
+stop no prompt anticipated, including one your own harness causes. A turn that ends while
+the run waits is a pause, not a stop, even when your harness ends it. Run the friction
+command without another developer question.
 
 ```text
-npx --yes copilotkit@4.13.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.14.0 onboard friction --phase stop --category <slug>
 ```
 
 Write one or two sentences to standard input: the step you stopped at and what stopped it.
@@ -124,14 +124,14 @@ next: send the report, then stop.
 
 ## Check sign-in
 
-Run `npx --yes copilotkit@4.13.0 login --json` before any project work. This command
+Run `npx --yes copilotkit@4.14.0 login --json` before any project work. This command
 checks the current session. It starts sign-in only as needed. Treat this as a long-lived
 streaming process. Do not wait for the command to exit before you read its standard output.
 
 Read each JSON Lines record as the running command writes it:
 
-1. If the process emits `type: completed` without an `authentication_url`, continue. The
-   existing session is valid and there is no page to open.
+1. If the process emits `type: completed` without an `authentication_url`, continue: the
+   existing session is valid.
 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
@@ -141,27 +141,38 @@ Read each JSON Lines record as the running command writes it:
    and its API key. That key is what lets your users reopen past conversations. You can
    remove it later to disconnect this workspace.
 
+   If it carries `user_code`, add: `Check that the page shows this code: <user_code>`.
+
 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:
+   browser. Your own built-in browser is not that opener and does not carry the session
+   the developer already signed in with. 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.
+     Pass the exact URL as one quoted argument, unchanged.
 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.
+   the developer and ask them to finish sign-in there. Show any `user_code` too. The page
+   works from any device. 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.
+7. On `type: failed` with `reason: expired`, ask once whether to retry. If yes, start one
+   new `login --json`.
+8. If that process emits `type: failed`, report the error and stop onboarding.
+
+If your harness ends the login process or your turn before the process emits
+`type: completed` or `type: failed`, that is a pause, not a failed sign-in. If the process
+still runs, end your turn and wait for the developer to say they signed in, then read the
+same process. If the process ended, run `login --json` again and handle a new
+`authentication_url` as above. Step 5 forbids a second login only while the first one runs.
 
-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.
+Do not use `whoami` for this check. Do not put account tokens or credentials in the
+conversation.
 
 When sign-in is settled, run
-`npx --yes copilotkit@4.13.0 onboard read research/gather`.
+`npx --yes copilotkit@4.14.0 onboard read research/gather`.
 
 If sign-in stops onboarding, run
-`npx --yes copilotkit@4.13.0 onboard read stopped/run-failed`. It says nothing about
+`npx --yes copilotkit@4.14.0 onboard read stopped/run-failed`. It says nothing about
 whether this project's stack is supported, which is not yet known at this point.

package/onboarding/prompts/conversion/plan.md

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

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

@@ -7,10 +7,11 @@ or frontend question here. Ask the developer only for choices that the repositor
 show. Do not change application code in this phase. Do not read, show, store, or request
 a secret value.
 
-Use a gentle wizard. Ask one short question at a time. Do not combine separate choices in
-one question. Put the recommendation first, give its evidence in one sentence, and keep
-the alternatives short. When project selection is unknown, ask only which project to
-use. Keep final plan approval as its own later question.
+Use a gentle wizard. Ask one short question at a time. End your turn and wait for each
+answer. Do not combine separate choices in one question. Put the recommendation first,
+give its evidence in one sentence, and keep the alternatives short. When project selection
+is unknown, ask only which project to use. Keep final plan approval a separate, later
+question.
 
 ## If you stop in this phase
 
@@ -23,7 +24,7 @@ developer question. Do not ask the developer about telemetry: the command applie
 setting they already have.
 
 ```text
-npx --yes copilotkit@4.13.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.14.0 onboard friction --phase stop --category <slug>
 ```
 
 Write one or two sentences to standard input: the step you stopped at and what stopped it.
@@ -58,7 +59,7 @@ 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.13.0 onboard classify --starting-state <starting-state> --agent-framework <agent-framework> --frontend <frontend>
+npx --yes copilotkit@4.14.0 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
@@ -155,7 +156,7 @@ passes against the wrong one.
 Create it, from the target directory, passing the port research settled:
 
 ```text
-npx --yes copilotkit@4.13.0 project select --create <name> \
+npx --yes copilotkit@4.14.0 project select --create <name> \
   --runtime-url http://localhost:<port>/api/copilotkit --json
 ```
 
@@ -173,13 +174,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.13.0 project list --json
+npx --yes copilotkit@4.14.0 project list --json
 ```
 
 Narrow them:
 
 ```text
-npx --yes copilotkit@4.13.0 project list --search <query> --json
+npx --yes copilotkit@4.14.0 project list --search <query> --json
 ```
 
 With `--json` the payload is the only thing on standard output, so it is safe to parse. Do
@@ -192,7 +193,7 @@ Then record the project they name, from the target directory, with the same
 `--runtime-url`:
 
 ```text
-npx --yes copilotkit@4.13.0 project select --project <slug-or-id> \
+npx --yes copilotkit@4.14.0 project select --project <slug-or-id> \
   --runtime-url http://localhost:<port>/api/copilotkit --json
 ```
 
@@ -222,7 +223,8 @@ After project reuse or a warning-free selection result, send the environment
 research subagent a focused follow-up check. Give it the exact target app directory and both
 credential paths. Require it to report these facts without values:
 
-- The project-record path has non-empty `projectId`, `projectSlug`, and `clerkOrgId` fields.
+- The project-record path has non-empty `projectId` and `projectSlug` fields. Unless
+  `COPILOTKIT_DEPLOYMENT` is `self-hosted`, it also has a non-empty `clerkOrgId` field.
 - The environment path has a non-empty `CPK_INTELLIGENCE_API_KEY` entry.
 - If project selection ran, its selected slug matches `projectSlug`.
 - If project selection ran, the `.env` file was created or its modification time advanced.
@@ -236,4 +238,4 @@ project-record path and environment path as the credential setup path list. Do n
 to the baseline yet.
 
 When project selection is settled, run
-`npx --yes copilotkit@4.13.0 onboard read credentials/settle-credentials`.
+`npx --yes copilotkit@4.14.0 onboard read credentials/settle-credentials`.

package/onboarding/prompts/credentials/plan.md

@@ -20,7 +20,7 @@ If the target directory holds no project and the copied prompt came from the Sla
 Microsoft Teams docs page, do not ask the framework question. The Channel starter brings
 its own agent, so an answer here decides nothing. Tell the developer that the Channel
 starter decides the agent, then run
-`npx --yes copilotkit@4.13.0 onboard read frontend/plan`.
+`npx --yes copilotkit@4.14.0 onboard read frontend/plan`.
 
 Use a gentle wizard. Ask one short question at a time. Do not combine separate choices in
 one question. Put the recommendation first, give its evidence in one sentence, and keep
@@ -74,26 +74,26 @@ another framework. Do not show the internal route.
 
 Use exactly one matching internal route:
 
-1. AG2: `npx --yes copilotkit@4.13.0 onboard read framework/ag2`
-2. Agno: `npx --yes copilotkit@4.13.0 onboard read framework/agno`
-3. Built-in CopilotKit agent: `npx --yes copilotkit@4.13.0 onboard read framework/built-in`
-4. Claude Agent SDK Python: `npx --yes copilotkit@4.13.0 onboard read framework/claude-sdk-python`
-5. Claude Agent SDK TypeScript: `npx --yes copilotkit@4.13.0 onboard read framework/claude-sdk-typescript`
-6. CrewAI Flows: `npx --yes copilotkit@4.13.0 onboard read framework/crewai-flows`
-7. Deep Agents: `npx --yes copilotkit@4.13.0 onboard read framework/deep-agents`
-8. LangGraph Python: `npx --yes copilotkit@4.13.0 onboard read framework/langgraph-python`
-9. LangGraph FastAPI: `npx --yes copilotkit@4.13.0 onboard read framework/langgraph-fastapi`
-10. LangGraph TypeScript: `npx --yes copilotkit@4.13.0 onboard read framework/langgraph-typescript`
-11. LlamaIndex: `npx --yes copilotkit@4.13.0 onboard read framework/llamaindex`
-12. ADK: `npx --yes copilotkit@4.13.0 onboard read framework/google-adk`
-13. Microsoft Agent Framework Python: `npx --yes copilotkit@4.13.0 onboard read framework/ms-agent-python`
-14. Microsoft Agent Framework .NET: `npx --yes copilotkit@4.13.0 onboard read framework/ms-agent-dotnet`
-15. Mastra: `npx --yes copilotkit@4.13.0 onboard read framework/mastra`
-16. MS Agent Harness .NET: `npx --yes copilotkit@4.13.0 onboard read framework/ms-agent-harness-dotnet`
-17. Pydantic AI: `npx --yes copilotkit@4.13.0 onboard read framework/pydantic-ai`
-18. Strands Agents Python: `npx --yes copilotkit@4.13.0 onboard read framework/strands-python`
-19. Strands Agents TypeScript: `npx --yes copilotkit@4.13.0 onboard read framework/strands-typescript`
+1. AG2: `npx --yes copilotkit@4.14.0 onboard read framework/ag2`
+2. Agno: `npx --yes copilotkit@4.14.0 onboard read framework/agno`
+3. Built-in CopilotKit agent: `npx --yes copilotkit@4.14.0 onboard read framework/built-in`
+4. Claude Agent SDK Python: `npx --yes copilotkit@4.14.0 onboard read framework/claude-sdk-python`
+5. Claude Agent SDK TypeScript: `npx --yes copilotkit@4.14.0 onboard read framework/claude-sdk-typescript`
+6. CrewAI Flows: `npx --yes copilotkit@4.14.0 onboard read framework/crewai-flows`
+7. Deep Agents: `npx --yes copilotkit@4.14.0 onboard read framework/deep-agents`
+8. LangGraph Python: `npx --yes copilotkit@4.14.0 onboard read framework/langgraph-python`
+9. LangGraph FastAPI: `npx --yes copilotkit@4.14.0 onboard read framework/langgraph-fastapi`
+10. LangGraph TypeScript: `npx --yes copilotkit@4.14.0 onboard read framework/langgraph-typescript`
+11. LlamaIndex: `npx --yes copilotkit@4.14.0 onboard read framework/llamaindex`
+12. ADK: `npx --yes copilotkit@4.14.0 onboard read framework/google-adk`
+13. Microsoft Agent Framework Python: `npx --yes copilotkit@4.14.0 onboard read framework/ms-agent-python`
+14. Microsoft Agent Framework .NET: `npx --yes copilotkit@4.14.0 onboard read framework/ms-agent-dotnet`
+15. Mastra: `npx --yes copilotkit@4.14.0 onboard read framework/mastra`
+16. MS Agent Harness .NET: `npx --yes copilotkit@4.14.0 onboard read framework/ms-agent-harness-dotnet`
+17. Pydantic AI: `npx --yes copilotkit@4.14.0 onboard read framework/pydantic-ai`
+18. Strands Agents Python: `npx --yes copilotkit@4.14.0 onboard read framework/strands-python`
+19. Strands Agents TypeScript: `npx --yes copilotkit@4.14.0 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.13.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.14.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/credentials/settle-credentials.md

@@ -11,7 +11,7 @@ friction command without another developer question. Do not ask the developer ab
 telemetry: the command applies the setting they already have.
 
 ```text
-npx --yes copilotkit@4.13.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.14.0 onboard friction --phase stop --category <slug>
 ```
 
 Write one or two sentences to standard input: the step you stopped at and what stopped it.
@@ -60,7 +60,7 @@ One container for this project is the default scope, so the id comes from the se
 project slug. Ask the CLI for it, from the target directory:
 
 ```text
-npx --yes copilotkit@4.13.0 learning containers default-id --json
+npx --yes copilotkit@4.14.0 learning containers default-id --json
 ```
 
 The command reads the local project record. It needs no credential and makes no network
@@ -79,7 +79,7 @@ happened.
 Then ask the platform about that id, from the target directory:
 
 ```text
-npx --yes copilotkit@4.13.0 learning containers get <id> --json
+npx --yes copilotkit@4.14.0 learning containers get <id> --json
 ```
 
 The read carries the same availability gate as the create, so it answers the entitlement
@@ -104,7 +104,7 @@ Never invent an id, scrape a dashboard, or treat an arbitrary string as a contai
 Report what the read found, before anything is planned:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase container-surveyed
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase container-surveyed
 ```
 
 Carry the derived id into the planning subagent's handoff, with whether the platform
@@ -125,16 +125,23 @@ the developer to write the value into the project's env file themselves. A path
 developer names is theirs to give, including one outside the project. A path this run
 finds is not.
 
-If no answer comes, stop. Do not write a placeholder or an empty value. A scaffold
-carrying a dummy key looks finished and fails at the first model call, which is worse
-than stopping here.
+Until the developer answers, the run waits. Report the pause and end your turn:
+
+```text
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase awaiting-developer
+```
+
+This is a pause, not a stop. `research/gather` describes it under "Pausing vs stopping".
+Do not send a stop report, and do not take a stop route. When the developer answers,
+continue from this step. Do not write a placeholder or an empty value. A scaffold carrying
+a dummy key looks finished and fails at the first model call.
 
 After model credential placement is complete, add each credential setup path to the
 protected path list. Also add each project file that the developer changed for model
 credentials. Record them in the baseline from the target app directory:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --path <path>
+npx --yes copilotkit@4.14.0 onboard protect --path <path>
 ```
 
 Pass one `--path` for each. The command captures a digest for each path and never re-reads
@@ -148,7 +155,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.13.0 onboard protect --rebaseline --path <path>
+npx --yes copilotkit@4.14.0 onboard protect --rebaseline --path <path>
 ```
 
 From that point they are protected like any other path, so a later step that rewrites
@@ -167,7 +174,7 @@ environment path. The command below is what to run at that point, from the targe
 directory:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --accept-credential --path <environment path>
+npx --yes copilotkit@4.14.0 onboard protect --accept-credential --path <environment path>
 ```
 
 The command compares the variable names the baseline recorded with the names the file holds
@@ -182,4 +189,4 @@ now. Read its result:
   is not a failed step. It answers the question and the run carries on.
 
 When the credential question is answered, run
-`npx --yes copilotkit@4.13.0 onboard read credentials/write-plan`.
+`npx --yes copilotkit@4.14.0 onboard read credentials/write-plan`.

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

@@ -1,8 +1,8 @@
 # Write the plan and get it approved
 
 The project and its credentials are settled. This phase wires the runtime, has a
-subagent write the plan, and asks the developer to approve it. This is the last thing
-the run needs from them.
+subagent write the plan, and asks the developer to approve it. This is the last question
+the run asks them.
 
 ## If you stop in this phase
 
@@ -11,7 +11,7 @@ friction command without another developer question. Do not ask the developer ab
 telemetry: the command applies the setting they already have.
 
 ```text
-npx --yes copilotkit@4.13.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.14.0 onboard friction --phase stop --category <slug>
 ```
 
 Write one or two sentences to standard input: the step you stopped at and what stopped it.
@@ -52,7 +52,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.13.0 onboard read subagent/create-plan` first and follow the prompt
+`npx --yes copilotkit@4.14.0 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
@@ -63,7 +63,7 @@ Wait for the subagent to finish.
 Continue only if the planning result starts with `Status: passed`. For `Status: failed`,
 send the result back to the planning subagent for repair, up to three attempts. For
 `Status: blocked`, or a third failed result, run
-`npx --yes copilotkit@4.13.0 onboard read stopped/run-failed`. A plan this run cannot
+`npx --yes copilotkit@4.14.0 onboard read stopped/run-failed`. A plan this run cannot
 write is a run that broke, not a stack the documentation does not cover. Do not show or
 ask for approval of a non-pass plan.
 
@@ -93,14 +93,21 @@ approve rather than in the implementation that follows. Do not upgrade a depende
 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.
+need from them, and, unless your harness makes the developer approve commands before they
+run, 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.
+
+A command-approval prompt from your harness is not a question from this graph, but the
+build still stops at each one until the developer answers. If your harness raises them,
+replace the leave line with this one: "I will ask you to approve some commands while I
+build. Keep this window open until the app runs." Decide from your own approval policy,
+as the welcome did, not from your coding-agent slug.
 
 If the developer approves the plan, run
-`npx --yes copilotkit@4.13.0 onboard read implementation/build-and-validate`.
+`npx --yes copilotkit@4.14.0 onboard read implementation/build-and-validate`.
 
 If no exact supported path or documentation URL exists, run
-`npx --yes copilotkit@4.13.0 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.14.0 onboard read unsupported/no-validated-path`.

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

@@ -14,7 +14,7 @@ command without another developer question. Do not ask the developer about telem
 command applies the setting they already have.
 
 ```text
-npx --yes copilotkit@4.13.0 onboard friction --phase stop --category <slug>
+npx --yes copilotkit@4.14.0 onboard friction --phase stop --category <slug>
 ```
 
 Write one or two sentences to standard input: the step you stopped at and what stopped it.
@@ -55,18 +55,18 @@ Use these rules for the implementation result:
 2. For `Status: failed`, retry the same subagent with its evidence. Make at most three attempts.
 3. For `Status: blocked`, stop onboarding. Report the blocker.
 
-After a third failed result, stop. When a fix needs changes to the existing agent or frontend,
-stop.
+After a third failed result, stop onboarding. When a fix needs changes to the existing agent
+or frontend, stop onboarding.
 
 Use these rules for every protected-path check in this fallback:
 
-- Run `npx --yes copilotkit@4.13.0 onboard audit` from the target app directory.
+- Run `npx --yes copilotkit@4.14.0 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.13.0 onboard protect --accept-external --path <path>`, run the
+  `npx --yes copilotkit@4.14.0 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
@@ -94,7 +94,7 @@ Wait for the proof subagent to finish. For `Status: blocked`, stop onboarding an
 blocker. For `Status: failed`, classify the cause before retrying.
 
 Retry the proof worker only for a project-owned process, port, or request-option failure.
-Give it the failure evidence and wait after each attempt. Stop after three failed attempts.
+Give it the failure evidence and wait after each attempt. After three failed attempts, stop onboarding.
 
 For a source, configuration, dependency, or tracked-file defect, send the evidence to the
 implementation subagent. Require the repair and full validation. Wait for the repair to
@@ -119,13 +119,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.13.0 onboard complete`, carrying the
+When the proof is complete, run `npx --yes copilotkit@4.14.0 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.13.0 onboard complete --visual-check <outcome>
-npx --yes copilotkit@4.13.0 onboard complete --device-check <outcome>
+npx --yes copilotkit@4.14.0 onboard complete --visual-check <outcome>
+npx --yes copilotkit@4.14.0 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,7 +18,7 @@ without exposing secrets.
 After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard audit
+npx --yes copilotkit@4.14.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -29,7 +29,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --accept-external --path <path>
+npx --yes copilotkit@4.14.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -38,24 +38,24 @@ or its report does not settle who changed it, ask the developer to allow the unp
 change. Only after they agree, record their answer:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --yes copilotkit@4.14.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Run the audit again after each accepted or authorized change. If it still fails, or starts
 with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase build-validated
 ```
 
 If validation cannot pass, or this intent needs a prerequisite the app does not have, use
 the feature stop route above without further changes.
 
 Otherwise run
-`npx --yes copilotkit@4.13.0 onboard read feature/a2ui/proof`.
+`npx --yes copilotkit@4.14.0 onboard read feature/a2ui/proof`.

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

@@ -19,23 +19,23 @@ 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.13.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --yes copilotkit@4.14.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Use `passed` only for a proved A2UI surface, `failed` for an attempted proof that failed,
-and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.13.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --yes copilotkit@4.14.0 onboard audit`.
 Continue only when it starts with `Status: passed`.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -50,9 +50,9 @@ Run the audit again after each accepted or authorized change.
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --yes copilotkit@4.13.0 onboard read feature/complete` with the actual browser-proof
+`npx --yes copilotkit@4.14.0 onboard read feature/complete` with the actual browser-proof
 outcome.