copilotkit 4.9.60 → 4.10.1

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

@@ -4,6 +4,16 @@ Treat Learning as a managed Intelligence feature that assigns real threads to a
 Learning Container. Orchestrate with separate read-only, implementation, and proof
 subagents. Work only inside the target project and preserve its existing agent and chat.
 
+Before any subagent or project process runs, capture the developer's existing work:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+approved authorization before implementation.
+
 Before edits, inspect the runtime, agent id, provider/chat, server-side user identity,
 existing Intelligence configuration (presence only), existing thread routes, and the normal
 test/dev commands. Prove the current round trip and inspect `/info`. If the project does not
@@ -13,7 +23,7 @@ onboarding.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -23,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -47,10 +57,23 @@ Show a concise plan for managed runtime/thread prerequisites, a stable selected
 the documented `getLearningContainerId` selector, validation, and a visible assignment
 proof. Ask for approval separately.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/learning/implement`.
+Then run `npx --yes copilotkit@4.10.1 onboard read feature/learning/implement`.

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

@@ -11,18 +11,49 @@ intact unless the official guide and observed failure require a minimal document
 
 Run the project's focused validation commands. Start the app and confirm `/info` reports
 `openGenerativeUIEnabled`, while treating that only as capability evidence. Record changed paths and
-validation results without secrets. When implementation validation passes, report it:
+validation results without secrets.
+
+After validation and each repair, run:
+
+```text
+npx --yes copilotkit@4.10.1 onboard audit
+```
+
+Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+not a finding. Carry it into the final summary with its reason.
+
+If the audit fails, never repair, reset, or revert a protected path. Compare each named path
+with the implementation subagent's `Files changed` section. If that section does not name
+the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.1 onboard protect --accept-external --path <path>
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
-without further changes:
+For an env file where the developer placed a requested credential, use
+`onboard protect --accept-credential --path <path>` instead. If the subagent names the path,
+or its report does not settle who changed it, ask the developer to allow the unplanned
+change. Only after they agree, record their answer:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.1 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.10.1 onboard read feature/stop
+```
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.10.1 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.9.60 onboard read feature/open-generative-ui/proof`.
+`npx --yes copilotkit@4.10.1 onboard read feature/open-generative-ui/proof`.

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

@@ -13,15 +13,40 @@ the missing visual proof honestly.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
-Then run
-`npx --yes copilotkit@4.9.60 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
-with the outcome actually observed.
+After the final attempt, report the gate exactly once:
+
+```text
+npx --yes copilotkit@4.10.1 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.10.1 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
+with the proof subagent's `Files changed` section. If that section does not name the path,
+run `onboard protect --accept-external --path <path>`, or
+`onboard protect --accept-credential --path <path>` for an env file where the developer
+placed a requested credential. If the subagent names the path, or its report does not settle
+who changed it, ask the developer to allow it. Only after they agree, run
+`onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"`.
+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.10.1 onboard read feature/stop
+```
+
+When the audit passes, run
+`npx --yes copilotkit@4.10.1 onboard read feature/complete` with the outcome actually
+observed.

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

@@ -3,10 +3,20 @@
 Treat this as a focused OSS enhancement. Orchestrate the work with separate read-only,
 implementation, and proof subagents, all restricted to the target project directory.
 
+Before any subagent or project process runs, capture the developer's existing work:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+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.9.60 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`npx --yes copilotkit@4.10.1 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.
@@ -14,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.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -24,7 +34,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 Do not sign in, select an Intelligence project, create credentials, change the existing
@@ -38,10 +48,23 @@ Retry through a second retrieval method if needed. Setup is the documented
 Show a small plan covering that runtime option, the existing provider's renderer path,
 likely CSP/sandbox implications, tests, and a user-visible generated UI proof. Ask for approval separately.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/open-generative-ui/implement`.
+Then run `npx --yes copilotkit@4.10.1 onboard read feature/open-generative-ui/implement`.

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

@@ -17,22 +17,51 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused tests and
-`npx --yes copilotkit@4.9.60 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.10.1 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record changed paths and secret-safe validation
 evidence.
 
-When implementation validation passes, report it:
+After validation and each repair, run:
+
+```text
+npx --yes copilotkit@4.10.1 onboard audit
+```
+
+Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+not a finding. Carry it into the final summary with its reason.
+
+If the audit fails, never repair, reset, or revert a protected path. Compare each named path
+with the implementation subagent's `Files changed` section. If that section does not name
+the path, accept the developer's external change:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --accept-external --path <path>
+```
+
+For an env file where the developer placed a requested credential, use
+`onboard protect --accept-credential --path <path>` instead. If the subagent names the path,
+or its report does not settle who changed it, ask the developer to allow the unplanned
+change. Only after they agree, record their answer:
+
+```text
+npx --yes copilotkit@4.10.1 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.9.60 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
-without further changes:
+When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.1 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.9.60 onboard read feature/realtime-sync/proof`.
+`npx --yes copilotkit@4.10.1 onboard read feature/realtime-sync/proof`.

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

@@ -14,15 +14,39 @@ 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.9.60 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
-Run
-`npx --yes copilotkit@4.9.60 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
-with the actual outcome.
+After the final attempt, report the gate exactly once:
+
+```text
+npx --yes copilotkit@4.10.1 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.10.1 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
+with the proof subagent's `Files changed` section. If that section does not name the path,
+run `onboard protect --accept-external --path <path>`, or
+`onboard protect --accept-credential --path <path>` for an env file where the developer
+placed a requested credential. If the subagent names the path, or its report does not settle
+who changed it, ask the developer to allow it. Only after they agree, run
+`onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"`.
+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.10.1 onboard read feature/stop
+```
+
+When the audit passes, run
+`npx --yes copilotkit@4.10.1 onboard read feature/complete` with the actual outcome.

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

@@ -4,6 +4,16 @@ Treat realtime sync as the Intelligence thread-realtime plane, not as a generic
 exercise. Act as the orchestrator and delegate read-only inspection, implementation, and
 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.10.1 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+approved authorization before implementation.
+
 Before edits, inspect the current runtime, provider/chat, agent id, authenticated stable user
 identity, thread routes, existing Intelligence configuration (presence only), current websocket
 configuration, and normal test/dev commands. Prove the current frontend-to-runtime-to-agent
@@ -13,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.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -23,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -41,10 +51,23 @@ from explicit developer-owned values; never derive one from the other. The clien
 `/api` itself, so an `apiUrl` that already ends in `/api` produces `/api/api/...`. Hosted setup may not
 need a `wsUrl`. Ask for approval separately.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/realtime-sync/implement`.
+Then run `npx --yes copilotkit@4.10.1 onboard read feature/realtime-sync/implement`.

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

@@ -2,7 +2,7 @@
 
 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.9.60 login --json` and follow its single streaming session. Then
+`npx --yes copilotkit@4.10.1 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
@@ -20,22 +20,51 @@ 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.9.60 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.10.1 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures before continuing. Record changed paths and secret-safe
 validation evidence.
 
-When implementation validation passes, report it:
+After validation and each repair, run:
+
+```text
+npx --yes copilotkit@4.10.1 onboard audit
+```
+
+Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+not a finding. Carry it into the final summary with its reason.
+
+If the audit fails, never repair, reset, or revert a protected path. Compare each named path
+with the implementation subagent's `Files changed` section. If that section does not name
+the path, accept the developer's external change:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --accept-external --path <path>
+```
+
+For an env file where the developer placed a requested credential, use
+`onboard protect --accept-credential --path <path>` instead. If the subagent names the path,
+or its report does not settle who changed it, ask the developer to allow the unplanned
+change. Only after they agree, record their answer:
+
+```text
+npx --yes copilotkit@4.10.1 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.9.60 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
-without further changes:
+When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.1 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.9.60 onboard read feature/rich-threads/proof`.
+`npx --yes copilotkit@4.10.1 onboard read feature/rich-threads/proof`.

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

@@ -13,15 +13,41 @@ running.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
-Then run
-`npx --yes copilotkit@4.9.60 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
-with the actual browser outcome.
+After the final attempt, report the gate exactly once:
+
+```text
+npx --yes copilotkit@4.10.1 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.10.1 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
+with the proof subagent's `Files changed` section. If that section does not name the path,
+run `onboard protect --accept-external --path <path>`, or
+`onboard protect --accept-credential --path <path>` for an env file where the developer
+placed a requested credential. If the subagent names the path, or its report does not settle
+who changed it, ask the developer to allow it. Only after they agree, run
+`onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"`.
+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.10.1 onboard read feature/stop
+```
+
+When the audit passes, run
+`npx --yes copilotkit@4.10.1 onboard read feature/complete` with the actual browser
+outcome.

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

@@ -4,6 +4,16 @@ Treat Rich Threads as a managed Intelligence feature layered onto the existing a
 reason to replace its agent or chat. Act as the orchestrator and delegate inspection,
 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.10.1 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+approved authorization before implementation.
+
 Before edits, have a read-only subagent locate the runtime route, CopilotKit provider/chat,
 agent id, current thread UI or headless API, authentication boundary, stable server-side user
 identity source, current project configuration (presence only), and test/dev commands. Prove
@@ -13,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.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -23,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.1 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -43,10 +53,23 @@ The plan must name the documented Intelligence runtime wiring, server-side `iden
 catch-all thread routes, the selected UI (drawer or existing headless UI), preserved behavior,
 tests, and a reload/reopen proof. Ask for approval separately.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.1 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.1 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/rich-threads/implement`.
+Then run `npx --yes copilotkit@4.10.1 onboard read feature/rich-threads/implement`.

package/onboarding/prompts/feature/stop.md

@@ -8,13 +8,19 @@ extends, a documentation page that would not load, a prerequisite the app does n
 validation that would not pass, or a proof that could not be driven. Do not say the feature
 works when this run could not prove it.
 
-If the app has no proven CopilotKit baseline, say so plainly and point the developer at
-generic onboarding, which builds the app this intent needs. Give it a run id of its own:
+For `add-channels`, Slack or Teams is the UI; a CopilotKit web app is not required.
+Do not send this intent to generic onboarding because the project has no web app.
+Name the missing Channel prerequisite or failed mention proof and the next step needed
+to resolve it. Keep the existing agent and runtime, and report friction below.
+
+For other intents, if the app has no proven CopilotKit baseline, say so plainly and point
+the developer at generic onboarding, which builds the app this intent needs. Give it a run
+id of its own:
 a `start` with no `--run` reprints the id this stopped run already holds, and one id
 covering both reads as one run that did two different things.
 
 ```text
-npx --yes copilotkit@4.9.60 onboard start --run <new-12-character-id>
+npx --yes copilotkit@4.10.1 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
@@ -25,17 +31,20 @@ 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.
 
-Send one short report. Run the feedback command without another developer question. The
+Send one short report. Run the friction command without another developer question. The
 CLI telemetry gate decides whether the report is sent.
 
 ```text
-npx --yes copilotkit@4.9.60 onboard feedback
+npx --yes copilotkit@4.10.1 onboard friction --phase stop --category <slug>
 ```
 
-Write the feedback message to the command's standard input, in at most four lines. Send no
+Write one or two sentences to standard input: the step you stopped at and what stopped it.
+Pick the category that fits from docs-missing, docs-wrong, docs-sequential, cli-gap,
+sdk-gap, environment, port-collision, credential, validation-loop, and other. Leave
+--cost-seconds off. A run that stopped cannot separate one papercut's cost from the cost
+of the whole run, so the estimate is optional on a stop report and only there. Send no
 secrets, source code, logs, or command output. The command refuses a report that carries
 any of those, prints the reason, and exits zero. A refused report is not a failed step.
 Reword it and send it again, or stop without a report. The command prints what it sent.
-This is the channel for a stop. Report friction only from a run that finished, never from
-here. If the CLI says the report was not sent, state what it said and
+This is the channel for a stop. If the CLI says the report was not sent, state what it said and
 stop without another question.