copilotkit 4.27.0 → 4.28.0

package/onboarding/prompts/frontend/react-spa.md

@@ -6,7 +6,7 @@ This step asks the developer nothing. If the run must wait for the developer any
 the pause first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 React SPA has no starter. For a target directory that holds no project, build the new
@@ -26,7 +26,7 @@ that import when Vite leaves the package external.
 - https://docs.copilotkit.ai/react-spa.md
 
 If the page supports the selection, record React SPA and this URL. Then run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read credentials/finalize-plan`.
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/frontend/vue.md

@@ -6,7 +6,7 @@ This step asks the developer nothing. If the run must wait for the developer any
 the pause first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 Vue 3 has no starter. For a target directory that holds no project, build the new
@@ -26,7 +26,7 @@ page above. Vue has its own `useComponent`, which is not the React package. Take
 that reference page rather than from a Vue generative-UI guide, which is not published.
 
 If the pages support the selection, record Vue 3 and these URLs. Then run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read credentials/finalize-plan`.
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read credentials/finalize-plan`.
 
 If the documentation does not support the selection, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read unsupported/no-validated-path`.

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.27.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.28.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -31,7 +31,7 @@ name in the plan prompt, `credentials/write-plan`.
 
 ## Departing from the approved plan
 
-The developer saw a written plan and answered any risky change in it. The approved plan is
+The developer saw a written plan and answered any change in it that needs approval. The approved plan is
 that plan, with their answer. They were told that no question comes after it unless a step
 cannot be built as written. Such a step is therefore a change to the only thing they agreed
 to.
@@ -57,7 +57,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.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 The existing agent's behavior is never a departure to record and carry on from. It is four
@@ -74,14 +74,14 @@ 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.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 ## The developer's uncommitted files
 
 `onboard start` backed up the developer's work, so nothing is recorded before an edit. The
 approved plan lists the files that had uncommitted changes under `Uncommitted files`. Each
-one is a risky change, so the developer's answer to the plan is their agreement to those
+one needs approval, so the developer's answer to the plan is their agreement to those
 edits. Any other such file is a file
 the plan does not name: ask the developer, as above.
 
@@ -97,12 +97,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.27.0 onboard tripwire --continue`. Then read the step again. If
+`npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 ## Implement the plan
@@ -116,7 +116,7 @@ Run this from the target app directory. The developer saw the id in the plan, so
 the first point at which it can be created:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 learning containers create --id <id> --name <name> --json
+npx --prefer-offline --yes copilotkit@4.28.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
@@ -129,8 +129,11 @@ credentials step found it or another run made it. That is a container to reuse,
 failure to repair and not a reason to pick a new id. Any other error code: report it and
 stop onboarding, so no run wires a selector to an id the platform does not hold.
 
+When you start a subagent in the background, tell the developer in one sentence what it
+does. Then send nothing more until it returns.
+
 Spawn one implementation subagent. Tell it to run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read subagent/implement-and-validate` first and
+`npx --prefer-offline --yes copilotkit@4.28.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
@@ -138,8 +141,7 @@ handoff. Give it the plan, selected framework, frontend, model, exact target app
 selected documentation URLs, and the
 documentation policy recorded during framework selection or conversion planning. On a
 conversion, also give it the frozen criterion. Give it the paths that had uncommitted
-changes when the run started. Give it the developer's answer on the Skills install, so that it skips a
-declined install. Require it to implement every step in plan order
+changes when the run started. Require it to implement every step in plan order
 and run the full validation list. Wait for it.
 
 One subagent implements the whole plan. Do not divide the work across concurrent subagents,
@@ -165,7 +167,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.27.0 onboard read proof/round-trip`.
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read proof/round-trip`.
 
 ## Repair rules
 
@@ -193,9 +195,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.27.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard read unsupported/no-validated-path`.
+`npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard complete --visual-check <outcome> \
+npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard complete --visual-check failed --blocked-by browser-control-unresponsive
+npx --prefer-offline --yes copilotkit@4.28.0 onboard complete --visual-check failed --blocked-by browser-control-unresponsive
 ```
 
 ## Write the handoff
@@ -98,10 +98,9 @@ only you can say:
 - What the project now does, and the first thing to try in it.
 - What changed since the developer approved the plan: every path, version, or step the run
   departed from, and why. Where nothing departed, say so in one line. A file the approved
-  plan named under `Files the run writes itself` or `Skills install` is not a departure, and
-  neither is a Skills install the developer declined.
-- Where this run installed the CopilotKit Skills, the Skills files the install added:
-  `.agents/skills/` and its links in `.claude/skills/`. Say that deleting both removes them.
+  plan named under `Files the run writes itself` is not a departure.
+- A page-context warning the proof recorded: name the framework, and say that the page's data
+  does not reach its model yet.
 - Every change to the existing agent's behavior: its instructions, its tools, its model or
   provider, or its memory. Name each one and its file, and say the developer approved it.
   Where none changed, write `none`.

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

@@ -1,12 +1,15 @@
 # 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.27.0 onboard read subagent/prove-oss-baseline` first and follow
+`npx --prefer-offline --yes copilotkit@4.28.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
 handoff. Give it the repository findings and exact CLI package spec.
 
+When you start a subagent in the background, tell the developer in one sentence what it
+does. Then send nothing more until it returns.
+
 Give it the browser or device control you recorded in the preflight as well. The subagent
 proves the runtime from a shell and needs no browser for that. The control is for the one
 predicate that drives the existing frontend. Where the preflight recorded `unavailable`, say
@@ -18,7 +21,7 @@ Wait for the subagent to finish.
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard proof --step oss-baseline --outcome <passed|failed|skipped> [--predicate <1-6>]
+npx --prefer-offline --yes copilotkit@4.28.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 +43,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.27.0 onboard read conversion/plan`. That project already works.
+`npx --prefer-offline --yes copilotkit@4.28.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 +58,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.27.0 onboard read credentials/plan`. This prompt is served
+`npx --prefer-offline --yes copilotkit@4.28.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 +78,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.27.0 onboard read stopped/run-failed`. Neither means the
+`npx --prefer-offline --yes copilotkit@4.28.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,15 +1,17 @@
 # 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.27.0 onboard read subagent/prove-round-trip` first and follow the
+`npx --prefer-offline --yes copilotkit@4.28.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.
 Give it the selected framework, frontend, model, approved plan, selected documentation URLs,
 and validation evidence. Give it the documentation policy recorded during framework
 selection or conversion planning. On a conversion, also give it the frozen criterion. Give
-it the paths that had uncommitted changes when the run started. Give it the developer's answer on the Skills install and the
-Skills result the implementation returned.
+it the paths that had uncommitted changes when the run started.
+
+When you start a subagent in the background, tell the developer in one sentence what it
+does. Then send nothing more until it returns. This holds for a repair subagent too.
 
 Give it the frontend files that publish the page context and register the tools, by path,
 from the Files changed sections the implementation returned. The subagent sends what those
@@ -32,16 +34,13 @@ device control, and have it report `skipped-cloned-starter` rather than a missin
 capability: nothing was unavailable, the run declined to spend it. That outcome completes
 the run.
 
-Give the subagent this guide for continued-development tools:
-https://docs.copilotkit.ai/build-with-agents.md
-
 Wait for the subagent to finish. Its result arrives as a notification. Do not sleep to
 pass the time.
 
 Record what that proof returned before you route on it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.28.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 +52,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.27.0 onboard tripwire --continue`. Then read the step again. If
+`npx --prefer-offline --yes copilotkit@4.28.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,16 +65,15 @@ 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.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 If the proof result starts with `Status: passed`, run
-`npx --prefer-offline --yes copilotkit@4.27.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
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read proof/complete`. 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
 blocked. Do not describe a
-skipped surface as proved. Keep the Skills result separate from the proof result.
+skipped surface as proved.
 
 A passed result can carry the surface-check outcome `failed` with the cause
 `browser-control-unresponsive`. It means that the browser tool stopped answering, not that
@@ -97,7 +95,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.27.0 onboard checkpoint --phase awaiting-model-credential`, and
+`npx --prefer-offline --yes copilotkit@4.28.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 +122,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.27.0 onboard checkpoint --phase awaiting-developer` and end your
+`npx --prefer-offline --yes copilotkit@4.28.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
@@ -167,19 +165,19 @@ that returns blocked because the repair needs a file the plan does not name. Han
 way `implementation/build-and-validate` does: pause and ask the developer, add the file to
 the handoff if they allow it, and use the route-out rules below if they decline. Then spawn a
 fresh repair worker with this repair handoff, not the whole-plan implementation handoff: the
-plan, the proof evidence, the paths that had uncommitted changes when the run started, the
-files the developer allowed, and the developer's answer on the Skills install.
+plan, the proof evidence, the paths that had uncommitted changes when the run started, and
+the files the developer allowed.
 
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 Restart each project-owned process changed by the repair. Then spawn a fresh proof subagent
 with the full original proof handoff, failed proof evidence, and new validation evidence.
 This handoff includes the plan, documentation, policy, current process IDs, ports,
-surface-control state, the continued-tools guide, and the failed attempt's pinned Step 1
+surface-control state, and the failed attempt's pinned Step 1
 record. Carry that record so the second attempt sends the request the first one failed on.
 A fresh subagent given the plan alone writes its own request where the plan named none, and
 its grounding check then speaks about a question the failed attempt never asked.
@@ -191,7 +189,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.27.0 onboard read stopped/run-failed`. The stack is supported:
+`npx --prefer-offline --yes copilotkit@4.28.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 +200,7 @@ friction command follows the telemetry setting the developer already chose, so i
 separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.28.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

@@ -3,7 +3,8 @@
 The developer can still be signing in. Keep reading the login process as
 `authenticate/start` says while this phase runs. This phase inspects the project and proves
 what this environment can drive. Do not change application code here, and do not ask the
-developer a setup question yet: every read-only investigation finishes first.
+developer a setup question yet, except the setup message below: every other read-only
+investigation finishes first.
 
 ## Rules for the whole run
 
@@ -14,10 +15,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.27.0 onboard start --run <onboarding_run_id>` where you are
+`npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard start` in the
+If you no longer hold the id, run `npx --prefer-offline --yes copilotkit@4.28.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 +83,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.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.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 +103,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.27.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase delegation-unavailable
 ```
 
 Then say once, in your own words, that this environment has no working subagents. Say that
@@ -112,14 +113,14 @@ For the rest of this run, do not spawn a subagent where a prompt tells you to. R
 `subagent/` brief yourself and follow it.
 
 Before you ask the developer any setup question, finish every read-only investigation and
-preflight check in this section.
+preflight check in this section. The setup message below is the one exception.
 
 Prepare two research assignments. Before you spawn either subagent, run these two
 read-only commands yourself, from the target project directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard read subagent/inspect-repository
-npx --prefer-offline --yes copilotkit@4.27.0 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.28.0 onboard read subagent/inspect-repository
+npx --prefer-offline --yes copilotkit@4.28.0 onboard inspect --json
 ```
 
 Give each research subagent the prompt that the first command returns, the whole JSON that
@@ -137,11 +138,38 @@ Start both research subagents in parallel:
 2. Spawn a second research subagent. Assign it the environment evidence packet.
 3. Start both research subagents. Then continue.
 
+## Show the setup message while the research runs
+
+For some folders the setup message needs nothing that the research finds. Then the
+developer reads it while the research runs. That is the case when the developer's request
+names no Channel (as `research/route` lists), and the `onboard inspect` JSON shows one of:
+
+- `appDiscovery.reason` is `no-project`: the folder holds no project.
+- A frontend and no agent: `detection.frontend` has a `match`, and
+  `detection.agentFramework` has an empty `matched` and an empty `unmatched`.
+
+Once `login --json` has emitted `type: completed`, read the setup questions now:
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read setup/questions`. Record the frontend from
+`detection` first.
+Show the message. Before you end your turn to wait for the developer, report the pause:
+
+```text
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
+```
+
+Then continue below: the preflight and the merge do not wait for the reply. When the
+developer replies, record the reply as that prompt says. If `research/route` sends you back
+to the setup questions before the developer replied, do not show the message again: the
+pause above still holds.
+
+In any other folder, such as one with an agent, the research can change the message. Keep
+the research first.
+
 The research is under way. Continue to the surface-control preflight while it runs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard read research/preflight
+npx --prefer-offline --yes copilotkit@4.28.0 onboard read research/preflight
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 When both research results are merged and sign-in is done, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read research/route`.
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read research/route`.
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard read research/merge
+npx --prefer-offline --yes copilotkit@4.28.0 onboard read research/merge
 ```
 
 If inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read stopped/run-failed`.
+`npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard read feature/channels/start
+npx --prefer-offline --yes copilotkit@4.28.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.27.0 onboard read proof/oss-baseline`.
+`npx --prefer-offline --yes copilotkit@4.28.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,16 @@ 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.27.0 onboard read setup/questions`. That node asks every
+`npx --prefer-offline --yes copilotkit@4.28.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.
 
+On a blank folder the setup message can go out before the research ends. If the setup
+message is already out and the developer has not replied, record what the findings settle
+with `onboard setup-answers`, then end your turn and send the developer nothing. Report
+the pause with `onboard checkpoint --phase awaiting-developer` first. Do not remind them,
+and do not restate the setup. Their reply continues the run.
+
 If authentication or inspection stops onboarding, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read stopped/run-failed`. Neither says anything
+`npx --prefer-offline --yes copilotkit@4.28.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.