copilotkit 4.13.0 → 4.14.0

package/onboarding/prompts/feature/learning/start.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.
@@ -38,7 +38,7 @@ status:
   before the capture, the inspection, and any edit:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/blocked-by-plan
+npx --yes copilotkit@4.14.0 onboard read feature/blocked-by-plan
 ```
 
 - `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -59,7 +59,7 @@ again: it has no answer, so it carries the question forward rather than ending o
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect
+npx --yes copilotkit@4.14.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -75,7 +75,7 @@ onboarding.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -85,7 +85,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -117,7 +117,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.14.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -127,7 +127,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.13.0 onboard read feature/learning/implement`.
+Then run `npx --yes copilotkit@4.14.0 onboard read feature/learning/implement`.

package/onboarding/prompts/feature/open-generative-ui/implement.md

@@ -16,7 +16,7 @@ validation results without 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
@@ -27,7 +27,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
@@ -36,24 +36,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/open-generative-ui/proof`.
+`npx --yes copilotkit@4.14.0 onboard read feature/open-generative-ui/proof`.

package/onboarding/prompts/feature/open-generative-ui/proof.md

@@ -13,23 +13,23 @@ the missing visual proof honestly.
 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 generated UI, `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
@@ -44,9 +44,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 outcome actually
+`npx --yes copilotkit@4.14.0 onboard read feature/complete` with the outcome actually
 observed.

package/onboarding/prompts/feature/open-generative-ui/start.md

@@ -6,7 +6,7 @@ implementation, and proof subagents, all restricted to the target project direct
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect
+npx --yes copilotkit@4.14.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -16,7 +16,7 @@ approved authorization before implementation.
 Before edits, have a research subagent identify the current CopilotKit runtime route,
 provider/chat component, agent id, package versions, existing middleware, sandbox/CSP
 constraints, and normal test/dev commands. Prove the existing app first with `/info`,
-`npx --yes copilotkit@4.13.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`npx --yes copilotkit@4.14.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
 and a real frontend request when browser control is available. If the app is not an existing
 OSS CopilotKit app with a proven round trip, change nothing and direct the developer to the
 generic onboarding path first.
@@ -24,7 +24,7 @@ generic onboarding path first.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -34,7 +34,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 Do not sign in, select an Intelligence project, create credentials, change the existing
@@ -56,7 +56,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.14.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -66,7 +66,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.13.0 onboard read feature/open-generative-ui/implement`.
+Then run `npx --yes copilotkit@4.14.0 onboard read feature/open-generative-ui/implement`.

package/onboarding/prompts/feature/realtime-sync/implement.md

@@ -17,14 +17,14 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused tests and
-`npx --yes copilotkit@4.13.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.14.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record changed paths and secret-safe validation
 evidence.
 
 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
@@ -35,7 +35,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
@@ -44,24 +44,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/realtime-sync/proof`.
+`npx --yes copilotkit@4.14.0 onboard read feature/realtime-sync/proof`.

package/onboarding/prompts/feature/realtime-sync/proof.md

@@ -14,23 +14,23 @@ the missing proof rather than claiming realtime works.
 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 proved two-client sync, `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
@@ -45,8 +45,8 @@ 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 outcome.
+`npx --yes copilotkit@4.14.0 onboard read feature/complete` with the actual outcome.

package/onboarding/prompts/feature/realtime-sync/start.md

@@ -7,7 +7,7 @@ two-context proof to subagents within the target project.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect
+npx --yes copilotkit@4.14.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -23,7 +23,7 @@ unchanged and direct the developer to generic onboarding first.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -33,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -59,7 +59,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.14.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -69,7 +69,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.13.0 onboard read feature/realtime-sync/implement`.
+Then run `npx --yes copilotkit@4.14.0 onboard read feature/realtime-sync/implement`.

package/onboarding/prompts/feature/rich-threads/implement.md

@@ -2,15 +2,15 @@
 
 Delegate implementation to one subagent with the approved plan and fetched official guides.
 If repository evidence does not prove an existing valid Intelligence selection, run
-`npx --yes copilotkit@4.13.0 login --json` and follow its single streaming session. Then
+`npx --yes copilotkit@4.14.0 login --json` and follow its single streaming session. Then
 list projects, show the developer the current/recent choices, and select or create one only
 after they choose. Require the secret-safe selection summary to confirm the project file,
 environment file, and key provisioning; never display a key. If existing configuration is
 valid, reuse it rather than minting another project or key.
 
 Add only documented Intelligence runtime wiring, server-side `identifyUser`, and catch-all
-thread routes. Use the existing authenticated user source; if no stable source exists, stop
-and explain that it is a prerequisite. Preserve the agent, existing persistence, and chat
+thread routes. Use the existing authenticated user source; if no stable source exists, explain
+that it is a prerequisite and take the feature stop route below. Preserve the agent, existing persistence, and chat
 surface. Add the documented drawer only if the approved plan selected it.
 
 An Intelligence runtime requires `identifyUser`, and it usually reads a signed-in session
@@ -20,14 +20,14 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused type/test commands, then start the app and run
-`npx --yes copilotkit@4.13.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.14.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures before continuing. Record changed paths and secret-safe
 validation evidence.
 
 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
@@ -38,7 +38,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
@@ -47,24 +47,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/rich-threads/proof`.
+`npx --yes copilotkit@4.14.0 onboard read feature/rich-threads/proof`.

package/onboarding/prompts/feature/rich-threads/proof.md

@@ -13,24 +13,24 @@ running.
 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 proved persistence and reopen, `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`. Continue only when it starts with
+`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
@@ -45,9 +45,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
+`npx --yes copilotkit@4.14.0 onboard read feature/complete` with the actual browser
 outcome.

package/onboarding/prompts/feature/rich-threads/start.md

@@ -7,7 +7,7 @@ implementation, and proof to separate subagents within the target project.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect
+npx --yes copilotkit@4.14.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -23,7 +23,7 @@ an existing CopilotKit app, leave it unchanged and direct the developer to gener
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -33,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard read feature/stop
+npx --yes copilotkit@4.14.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -61,7 +61,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --yes copilotkit@4.14.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
 ```
 
 If an approved path changed after capture and no implementation step has run, add
@@ -71,7 +71,7 @@ authorize a path the approved plan did not list.
 Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.13.0 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.14.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.13.0 onboard read feature/rich-threads/implement`.
+Then run `npx --yes copilotkit@4.14.0 onboard read feature/rich-threads/implement`.

package/onboarding/prompts/feature/stop.md

@@ -20,7 +20,7 @@ a `start` with no `--run` reprints the id this stopped run already holds, and on
 covering both reads as one run that did two different things.
 
 ```text
-npx --yes copilotkit@4.13.0 onboard start --run <new-12-character-id>
+npx --yes copilotkit@4.14.0 onboard start --run <new-12-character-id>
 ```
 
 Do not read a generic onboarding node from this run. A feature run and a generic run are
@@ -31,11 +31,45 @@ Do not run `onboard complete`. This run did not complete.
 If this run changed files before it stopped, list every path it changed and say whether it
 reverted them. A report that says only that the run stopped cannot be acted on.
 
+## If one scoped fix can finish this run
+
+This applies when the app already has what this intent extends and one step of this run
+broke: a validation that would not pass, a proof that could not be driven, or a Channel
+prerequisite the developer can supply. It does not apply to an app with no proven
+CopilotKit baseline; that app goes to generic onboarding as described above.
+
+Do not decide this yourself. This run refused to widen its own scope, and that refusal
+stands. The developer is the one who can widen it.
+
+Name the one fix you propose, and say which file, setting, or process it touches. Ask the
+developer whether they approve that one fix. If they decline, or the question cannot be
+put to them, stop here and send the report below.
+
+If they approve it, make that one fix and nothing else. Then come back into this run:
+
+```text
+npx --yes copilotkit@4.14.0 onboard resume
+```
+
+Write the developer's approval to standard input, in one or two sentences: the fix they
+approved and what it touches. Send no secrets, source code, logs, or command output. The
+command refuses an approval that carries any of those, prints the reason, exits zero, and
+serves nothing. Reword it and send it again.
+
+The command prints the run id, the step it puts you back on, and that step's prompt.
+Follow that prompt. This is the same run, so do not run `onboard start` again, and keep
+the run id you already have.
+
+If the command refuses for any other reason, it says so and serves nothing. Report what it
+said and stop.
+
+## If no fix is approved
+
 Send one short report. Run the friction command without another developer question. Do not
 ask the developer about 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.

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

@@ -4,7 +4,7 @@ Delegate implementation to one subagent with the approved plan and fetched voice
 Wire the documented `TranscriptionService` into the existing v2 catch-all runtime and retain
 the current provider/chat surface. Use the already configured credential variable by name
 only; never read, print, synthesize, or add a secret. If no supported credential is present,
-stop with that specific setup requirement.
+name that specific setup requirement and take the feature stop route below.
 
 Do not add Intelligence, replace the agent, or make a fake microphone button. Run the focused
 type/test command and start the app. Confirm `/info` reports
@@ -14,7 +14,7 @@ voice proof. Record changed paths and validation results.
 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
@@ -25,7 +25,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
@@ -34,24 +34,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/voice/proof`.
+`npx --yes copilotkit@4.14.0 onboard read feature/voice/proof`.

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

@@ -13,23 +13,23 @@ path, agent response, app URL, and process IDs. Fix changed-file defects and rep
 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 proved voice input, `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`.
+`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
@@ -44,9 +44,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 surface
+`npx --yes copilotkit@4.14.0 onboard read feature/complete` with the actual surface
 outcome.