copilotkit 4.25.1 → 4.26.0

package/onboarding/prompts/implementation/build-and-validate.md

@@ -13,7 +13,7 @@ acted on. Send one short report before you stop. The friction command follows th
 setting the developer already chose, so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.26.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -53,7 +53,7 @@ This prompt pauses for the developer in several places. Before you end your turn
 for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 The existing agent's behavior is never a departure to record and carry on from. It is four
@@ -70,7 +70,7 @@ declines, use the route-out rules below.
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 ## The developer's uncommitted files
@@ -92,12 +92,12 @@ or from an environment variable.
 If the CLI prints `## Stop: this run deleted or moved the developer's work` instead of a
 step, show the developer the list it printed, and run what they choose:
 the `onboard restore` command the tripwire stop prints, which names each deleted file, or
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard tripwire --continue`. Then read the step again. If
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard tripwire --continue`. Then read the step again. If
 you cannot ask, use the route-out rules below. Before you end your turn to wait for the
 developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 ## Implement the plan
@@ -111,7 +111,7 @@ Run this from the target app directory. The developer approved the id with the p
 is the first point at which it can be created:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 learning containers create --id <id> --name <name> --json
+npx --prefer-offline --yes copilotkit@4.26.0 learning containers create --id <id> --name <name> --json
 ```
 
 Pass the id the plan names. Take the name from the selected project's own display name, so
@@ -125,7 +125,7 @@ failure to repair and not a reason to pick a new id. Any other error code: repor
 stop onboarding, so no run wires a selector to an id the platform does not hold.
 
 Spawn one implementation subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read subagent/implement-and-validate` first and
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read subagent/implement-and-validate` first and
 follow the prompt it returns. Tell it to return at once, and say so, if that read is refused
 or fails, and not to wait for an approval. If it returns that way, stop that subagent. Run
 the same command yourself, then spawn a fresh subagent with the returned prompt and the same
@@ -160,7 +160,7 @@ Report it and take the failure ending.
 If the implementation result does not start with `Status: passed`, do not continue to proof.
 
 Then run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read proof/round-trip`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read proof/round-trip`.
 
 ## Repair rules
 
@@ -188,9 +188,9 @@ developer
 declined a file the plan does not name, or the run cannot ask them about it. A defect in a
 package this run installed is not a stack CopilotKit does not serve, and a command this run
 cannot get to pass is not one either. In those cases run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`.
 
 A plan with no path to follow takes the unsupported ending: the fix requires changing the
 developer's existing agent or frontend, or the documentation does not support the plan. In
 those cases run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/proof/complete.md

@@ -24,7 +24,7 @@ friction commands follow the telemetry setting the developer already chose, so t
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.26.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
 ```
 
 Put one or two sentences in `--message`. Pick one category from docs-missing, docs-wrong,
@@ -46,7 +46,7 @@ Pass the surface-check outcome the proof subagent returned, not the one you want
 web frontend, pass `--visual-check` and the URL the browser opened, unchanged:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard complete --visual-check <outcome> \
+npx --prefer-offline --yes copilotkit@4.26.0 onboard complete --visual-check <outcome> \
   --frontend-url <the url you opened>
 ```
 
@@ -74,7 +74,7 @@ this graph opens.
 nothing drove the frontend:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard complete --visual-check failed --blocked-by browser-control-unresponsive
+npx --prefer-offline --yes copilotkit@4.26.0 onboard complete --visual-check failed --blocked-by browser-control-unresponsive
 ```
 
 ## Write the handoff

package/onboarding/prompts/proof/oss-baseline.md

@@ -1,7 +1,7 @@
 # Prove the existing OSS baseline
 
 Do not prove the baseline yourself. Spawn one proof subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read subagent/prove-oss-baseline` first and follow
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read subagent/prove-oss-baseline` first and follow
 the prompt it returns. Tell it to return at once, and say so, if that read is refused or
 fails, and not to wait for an approval. If it returns that way, stop that subagent. Run the
 same command yourself, then spawn a fresh subagent with the returned prompt and the same
@@ -18,7 +18,7 @@ Wait for the subagent to finish.
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard proof --step oss-baseline --outcome <passed|failed|skipped> [--predicate <1-6>]
+npx --prefer-offline --yes copilotkit@4.26.0 onboard proof --step oss-baseline --outcome <passed|failed|skipped> [--predicate <1-6>]
 ```
 
 Report the gate whatever it returned. Use the list below. A proof that never ran is `skipped`, not failed. The command prints one line and sends
@@ -40,7 +40,7 @@ Do not change project files before this proof ends. Starting existing developmen
 processes and their ignored runtime files is allowed.
 
 If the subagent proves the `both-oss` predicate, keep its evidence with the plan and run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read conversion/plan`. That project already works.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read conversion/plan`. That project already works.
 What it needs is the conversion, not a build.
 
 A failed baseline does not end the run, and this step does not repair it. Decide which
@@ -55,7 +55,7 @@ pass. This proof only reads.
 A failed baseline whose cause is in the project is the starting state of this project. So
 is an operational failure still there after the third attempt. Record the starting state
 `both-copilotkit-unproved` and run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read credentials/plan`. This prompt is served
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read credentials/plan`. This prompt is served
 whenever a project looks like an OSS integration, so a baseline that did not prove is an
 ordinary starting state rather than a failure. The build that follows fixes the
 integration, and `proof/round-trip` proves the result, with its own bounded repair cycle.
@@ -75,5 +75,5 @@ operational. Run the proof again, three times in total, then record the starting
 above and go on. Both causes lead to the same plan.
 
 If the proof cannot identify the running process safely, or it exposes a secret, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`. Neither means the
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`. Neither means the
 project is unsupported: each means this run did not establish what it needed to.

package/onboarding/prompts/proof/round-trip.md

@@ -1,7 +1,7 @@
 # Prove the user journey
 
 Do not do the proof work yourself. Spawn one proof subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read subagent/prove-round-trip` first and follow the
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read subagent/prove-round-trip` first and follow the
 prompt it returns. Tell it to return at once, and say so, if that read is refused or fails,
 and not to wait for an approval. If it returns that way, stop that subagent. Run the same
 command yourself, then spawn a fresh subagent with the returned prompt and the same handoff.
@@ -41,7 +41,7 @@ pass the time.
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.26.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Report the gate whatever it returned. A proof that never ran is `skipped`, not failed. A
@@ -53,7 +53,7 @@ the next one starts. Until then, `onboard proof-check` counts the next failure a
 If the CLI prints `## Stop: this run deleted or moved the developer's work` instead of a
 step, show the developer the list it printed, and run what they choose:
 the `onboard restore` command the tripwire stop prints, which names each deleted file, or
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard tripwire --continue`. Then read the step again. If
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard tripwire --continue`. Then read the step again. If
 you cannot ask, use the route-out rules below.
 
 Never repair, reset, or revert a file the developer changed outside this run. That holds for
@@ -66,11 +66,11 @@ This prompt pauses for the developer in several places. Before you end your turn
 for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 If the proof result starts with `Status: passed`, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read proof/complete`. A performed surface outcome with
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read proof/complete`. A performed surface outcome with
 the full round trip is core success even if a continued-development tool fails. A skipped
 surface outcome still enters `proof/complete`. The CLI records `skipped-cloned-starter` and
 `skipped-no-browser-tool` after a passed round trip as complete, and `skipped-no-device` as
@@ -97,7 +97,7 @@ credentials step found the model key missing, or the vendor refused it, and the
 started nothing. Do not send it to a repair worker. Run the `onboard credentials` command
 that its detail names, and act on its answer as `credentials/settle-credentials` says. Ask
 the developer its question, report the pause with
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-model-credential`, and
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-model-credential`, and
 end your turn. When the key settles, run the proof subagent again. If you have not recorded
 this attempt yet, record it first, with the outcome it ended with. This attempt does not
 count toward the three.
@@ -124,7 +124,7 @@ fault, so this is not a route-out. Ask the developer to send one message in the
 thread, and to give you that thread's id. Give them the app URL and the request words from
 the result. Tell them where the id is: in the browser's network tools, the request the page
 sends to the runtime URL carries `threadId` in its body. Report the pause with
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer` and end your
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer` and end your
 turn. When the developer gives the id, start a new proof subagent with
 the full original proof handoff, the pinned Step 1 record, and the thread id. Tell it to run
 the proof checks with `--thread <id>`. This attempt does not count toward the three. Use the
@@ -173,7 +173,7 @@ files the developer allowed, and the developer's answer on the Skills install.
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 Restart each project-owned process changed by the repair. Then spawn a fresh proof subagent
@@ -191,7 +191,7 @@ takes the developer path above instead.
 
 Route out only when the failure is not yours to fix, when the same proof still fails after
 three attempts, or when no evidence of the round trip can be produced. In those cases run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`. The stack is supported:
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`. The stack is supported:
 this run did not finish, which is a different ending and a different report. All three are
 about the round trip itself. A round trip that proved is not one of them, whatever failed
 after it.
@@ -202,7 +202,7 @@ friction command follows the telemetry setting the developer already chose, so i
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.26.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.

package/onboarding/prompts/research/gather.md

@@ -14,10 +14,10 @@ own bookkeeping. Say what the run is doing in the developer's words instead.
 
 Every later command must run from the directory this run is bound to. Elsewhere, the
 command cannot find its run and refuses. Do not report that refusal as a stop. Run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard start --run <onboarding_run_id>` where you are
+`npx --prefer-offline --yes copilotkit@4.26.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 --prefer-offline --yes copilotkit@4.25.1 onboard start` in the
+If you no longer hold the id, run `npx --prefer-offline --yes copilotkit@4.26.0 onboard start` in the
 directory this run started in, with no `--run` and no `--intent`. It reprints the id
 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.
@@ -82,7 +82,7 @@ When that thing arrives, continue. A pause waits for one of two things:
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 When the answer or the result arrives, continue from the step that paused. Do not read an
@@ -102,7 +102,7 @@ Both research subagents failing means this harness has no working subagent at al
 is worth recording once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase delegation-unavailable
 ```
 
 Then say once, in your own words, that this environment has no working subagents. Say that
@@ -118,8 +118,8 @@ Prepare two research assignments. Before you spawn either subagent, run these tw
 read-only commands yourself, from the target project directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard read subagent/inspect-repository
-npx --prefer-offline --yes copilotkit@4.25.1 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.26.0 onboard read subagent/inspect-repository
+npx --prefer-offline --yes copilotkit@4.26.0 onboard inspect --json
 ```
 
 Give each research subagent the prompt that the first command returns, the whole JSON that
@@ -140,8 +140,8 @@ Start both research subagents in parallel:
 The research is under way. Continue to the surface-control preflight while it runs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard read research/preflight
+npx --prefer-offline --yes copilotkit@4.26.0 onboard read research/preflight
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`.

package/onboarding/prompts/research/merge.md

@@ -51,11 +51,11 @@ waits on the developer, end your turn and wait for it: that is a pause.
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 When both research results are merged and sign-in is done, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read research/route`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read research/route`.
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`.

package/onboarding/prompts/research/preflight.md

@@ -32,8 +32,8 @@ Where the device probe found no booted device, that is the whole finding.
 Then merge the research:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard read research/merge
+npx --prefer-offline --yes copilotkit@4.26.0 onboard read research/merge
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`.

package/onboarding/prompts/research/route.md

@@ -21,7 +21,7 @@ On any one of them, run this before you read the three findings below, and witho
 the purpose question:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard read feature/channels/start
+npx --prefer-offline --yes copilotkit@4.26.0 onboard read feature/channels/start
 ```
 
 Name the provider to that node so it does not ask again. A `/slack` page names Slack. A
@@ -82,7 +82,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 --prefer-offline --yes copilotkit@4.25.1 onboard read proof/oss-baseline`.
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read proof/oss-baseline`.
 
 Route there before any other question to the developer. The questions after this prompt
 select a framework and a frontend that the findings already name, so a developer who
@@ -91,10 +91,10 @@ application is what that node protects. Whether it works is what the proof decid
 these three findings.
 
 For every other combination of the three, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read setup/questions`. That node asks every
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read setup/questions`. That node asks every
 remaining setup question in one message, including what the project is for when nothing
 proves it.
 
 If authentication or inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.25.1 onboard read stopped/run-failed`. Neither says anything
+`npx --prefer-offline --yes copilotkit@4.26.0 onboard read stopped/run-failed`. Neither says anything
 about whether this project's stack is supported, which is not yet known at this point.

package/onboarding/prompts/setup/questions.md

@@ -1,8 +1,7 @@
 # Ask the setup questions together
 
 The route is chosen. This node asks, in one message, every setup choice that the findings
-and the developer's request do not settle. The developer answers once, and the run then
-goes on without them until the plan is ready for approval. Do not change application code
+and the developer's request do not settle. Do not change application code
 in this phase. Do not read, show, store, or request a secret value.
 
 ## Settle what the findings already answer
@@ -37,8 +36,8 @@ about a missing toolchain before they choose, and not after.
 Ask every choice that is still open at this point in one message, one numbered line per
 choice, so that one reply can accept every recommendation. Put the recommendation first,
 give its evidence in one sentence, and keep the alternatives short. Do not ask a yes-or-no
-question first. Leave out a line whose answer is settled. Do not ask about the plan in
-this message: a later step asks for its approval.
+question first. Leave out a line whose answer is settled. Do not ask about the plan
+here.
 
 **Line 1: what the project is for.**
 
@@ -94,8 +93,7 @@ the framework's CopilotKit pages:
 
 "Project-defined" is not a missing default. It means that framework's own route settles
 the vendor with the developer: it keeps the one the repository already uses, and asks a
-single question when the repository shows none. Do not read it as a framework this release
-cannot onboard.
+single question when the repository shows none.
 
 "The agent's own" means that the route keeps the vendor the existing agent already uses.
 Ask no vendor question for it.
@@ -103,25 +101,34 @@ Ask no vendor question for it.
 Do not offer a framework that is not listed above. Do not port an existing agent to another
 framework.
 
-**Line 3: the model provider.**
+**Line 3: the model and its key.**
 
-The run asks for a model key later. A developer with no key from the vendor the run picked
-cannot answer that question, so settle the vendor in this message.
+Settle the vendor and where its key is here: without a key from that vendor, the developer
+cannot answer the later key question.
 
 For a new agent, ask this line, even if the framework needed no question. Skip it for an
 existing agent, and when the default vendor is "Project-defined" or "The agent's own":
-those routes settle the vendor themselves. Ask which model provider the developer has an
-API key for. Offer the documented vendors of the recommended framework, then another
-provider, then no preference. Never ask for the key itself.
+those routes settle the vendor themselves. Recommend the row's default vendor and, in the
+same sentence, ask where its key is: a file, or that they will add it later. When the row
+documents more than one vendor, name the others. Offer no vendor the row does not name. For
+example, for the built-in agent: "Model: OpenAI, with the key in a file outside this folder,
+or 'later'. Anthropic and Google work too." Never ask for the key itself.
+
+With no file named, record that they will add it later. A path the developer names is
+theirs to give, including one outside the project. Recommend the project's env file when it
+exists, git ignores and does not track it, and it already holds the key. Otherwise recommend
+a file outside the project, or "later". Never recommend an env file in the project while an
+`env-file-exposed` line is open, or when git tracks it or does not ignore it. For an empty
+target, a new key file goes outside the target directory, because `init` refuses a target
+that holds a `.env` file. Tell the developer only where the file goes, not that reason.
 
 **Line 4: the frontend.**
 
 If the project has no frontend, ask this line. The valid choices are React SPA,
-Next.js, Angular, Vue 3, React Native, Slack, and Microsoft Teams. They are valid in every
-starting state.
+Next.js, Angular, Vue 3, React Native, Slack, and Microsoft Teams.
 
 Where there is no existing frontend, include Slack and Microsoft Teams in the frontend
-question. They are chat UIs, not CopilotKit web apps. Then recommend the one the developer
+question. Then recommend the one the developer
 names, and say what each choice implies for where the CopilotKit runtime lives: Next.js
 hosts it in a route handler, Angular in its SSR server, and Vue 3, React SPA and React
 Native reach a runtime that runs as its own process. Slack and Microsoft Teams use a
@@ -129,7 +136,7 @@ long-running Channel host, not a CopilotKit web app.
 
 **Line 5: the project.** Leave out the project line on the local route: local evaluation
 creates its own project. For an existing app, first
-run `npx --prefer-offline --yes copilotkit@4.25.1 onboard credentials --json` from the target app directory.
+run `npx --prefer-offline --yes copilotkit@4.26.0 onboard credentials --json` from the target app directory.
 It only reads: it creates no project and writes no file. Read `status`:
 
 - `ready`: the app already has a project. Leave the line out.
@@ -137,7 +144,8 @@ It only reads: it creates no project and writes no file. Read `status`:
   the developer already has. If there is no `suggestedName`, ask for a name. Do not list
   the organization's projects.
 - `needs-developer` with `env-file-exposed`: git tracks the env file the key goes into, or
-  does not ignore it. Add `question.ask` as its own line, in those words. When
+  does not ignore it. Add `question.ask` as its own line, word for word: never shorten it or
+  drop what it says about teammates. When
   `question.untrack` is absent, recommend approving it: without it, the run writes no key. A
   reply that accepts every recommendation approves it. When `question.untrack` is present,
   git tracks the file. If `question.alternative` is present, recommend it: the key goes into
@@ -145,24 +153,18 @@ It only reads: it creates no project and writes no file. Read `status`:
   recommendation takes it. Without `question.alternative`, recommend nothing for this line.
   Untracking removes the file for everyone who pulls the next commit, so only an answer to
   this line approves it. A reply that accepts every recommendation never approves the
-  untrack. Then offer a new project for this app, or a project the developer already has.
+  untrack. Never suggest a reply that approves it. Then offer a new project for this app, or
+  a project the developer already has.
 - `stopped`: the command already filed the stop report. Tell the developer
   `stopReason.detail` in one sentence, then stop onboarding.
 
 For an empty target, offer a new project named after the target directory, or a project the
 developer already has.
 
-**Line 6: where the model key lives.** For a new agent, ask this line beside the provider
-line. Ask where the developer keeps the key for that provider: the file that holds it, or
-that they will add it later. With no file named, record that they will add it later. Never
-ask for the key itself. A path the developer names is
-theirs to give, including one outside the project. For an empty target, a new key file
-goes outside the target directory: `init` refuses a target that holds a `.env` file.
-
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 If no line is open, ask nothing and continue.
@@ -190,12 +192,12 @@ developer three things in one message:
 2. That the coding agent's shell reads PATH when it starts, so it cannot see the new
    toolchain until the developer restarts the coding agent.
 3. That the run resumes after the restart with
-   `npx --prefer-offline --yes copilotkit@4.25.1 onboard start --run <onboarding_run_id>`.
+   `npx --prefer-offline --yes copilotkit@4.26.0 onboard start --run <onboarding_run_id>`.
 
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.25.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.26.0 onboard checkpoint --phase awaiting-developer
 ```
 
 Then end your turn and wait for the developer. That restart is a step here, not an error.
@@ -208,4 +210,4 @@ which is the row's default vendor. An existing agent's vendor: `existing`. Give
 every later node and subagent. They answer the framework, provider, and frontend questions
 for the rest of the run. The project and key answers answer those questions too.
 
-Then run `npx --prefer-offline --yes copilotkit@4.25.1 onboard read credentials/plan`.
+Then run `npx --prefer-offline --yes copilotkit@4.26.0 onboard read credentials/plan`.