copilotkit 4.22.0 → 4.23.1

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

@@ -3,7 +3,7 @@
 First, report your coding agent identity using the same command as generic onboarding:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard identify --coding-agent <coding-agent-slug> --model <model-id> --model-family <model-family>
+npx --prefer-offline --yes copilotkit@4.23.1 onboard identify --coding-agent <coding-agent-slug> --model <model-id> --model-family <model-family>
 ```
 
 Use your own product's slug, such as `codex` or `claude-code`. For `--model`, copy the
@@ -34,13 +34,13 @@ carry on. Keep a read-only assignment read-only. If no subagent works at all, re
 once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase delegation-unavailable
 ```
 
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase awaiting-developer
 ```
 
 A turn that ends while the run waits is a pause, not a stop, even when your harness ends it.
@@ -50,7 +50,7 @@ If you stop this run, send one short report before you stop. The friction comman
 the telemetry setting the developer already chose, so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -64,7 +64,7 @@ one scoped fix, and sends the report itself when no fix is approved.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. Do not
@@ -74,9 +74,9 @@ authorization first.
 Before changing files, send a short welcome. Say you will inspect the project, show a
 Channel plan, implement only after approval, and prove a real mention reply.
 
-Ask Slack or Teams as its own question only when the copied prompt did not already
-name one. If it named Slack, use Slack. If it named Teams or Microsoft Teams, use
-Teams. Do not ask again.
+Ask Slack or Teams as its own question only when neither the copied prompt nor the
+developer already named one. If either named Slack, use Slack. If either named Teams or
+Microsoft Teams, use Teams. Do not ask again.
 
 For an empty folder, the OpenTag starter brings its own agent. An agent framework this
 run recorded earlier does not apply here. Say that plainly and do not ask for a framework
@@ -94,7 +94,7 @@ This one does not.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase research-returned
 ```
 
 If the folder is empty, check Node 22, `uv`, and Python before cloning. Python 3.12 or
@@ -108,41 +108,14 @@ and its install command in the message the developer sees: `nvm install 22` for
 for Python. Offer a custom headless build as a later path. Then route out:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/stop
 ```
 
-Do not run login, select Intelligence, or create a credential until the developer
-approves the plan. Fetch the connect guide for the chosen provider before planning:
-https://docs.copilotkit.ai/slack/connect.md for Slack,
-https://docs.copilotkit.ai/teams/connect.md for Teams.
-Retry it a second way if needed.
-
-For an empty folder, OpenTag runs its own agent on `OPENAI_API_KEY`. State that before the
-plan. Check the target `.env` and the environment for that name. Report presence only, and
-never read, print, or store the value. If it is absent, ask the developer to place it as
-part of the plan approval, not at backend start. Say that the key is never displayed and
-goes only into the project `.env`. Asking for a key the developer already owns is not
-creating a credential.
-
-Show a small plan. For an empty folder, clone OpenTag and do not rewrite it. For an
-existing agent or app, keep that code and wire a managed Channel. Slack or Teams is
-only `channels add <name> --adapter slack|teams`, with the project's directory or package
-name as `<name>`. On Teams, skip Slack-only tools and the Slack e2e harness. Name focused
-tests and a real mention proof on the chosen provider. Ask for approval separately.
-
-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. Authorization covers
-changing a protected path, not removing it, so the plan must not delete, move, or rename
-one.
-
-After approval, record each approved path before implementation:
+When the tools this run needs are present, read the next prompt now, in this turn:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/channels/plan
 ```
 
-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 run `npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/channels/implement`.
+That prompt holds the plan, the developer's approval, and the paths the plan changes.
+Do not write the plan or change project files in this prompt.

package/onboarding/prompts/feature/chat-suggestions/implement.md

@@ -15,7 +15,7 @@ Run focused type/test checks and start the app. Record the changed files and val
 Before you spawn the implementation subagent, take the authorized list from the CLI:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.23.1 onboard audit
 ```
 
 From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
@@ -34,7 +34,7 @@ still go on the record. Name the file and why the work needs it, then end your t
 for the developer's answer. If they allow it, record their answer before any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Continue only when the result starts with `Status: passed`. Run the audit again, take the
@@ -46,7 +46,7 @@ feature stop route below.
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.23.1 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -57,7 +57,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -70,11 +70,11 @@ Run the audit again after each accepted change. If it still fails, or starts
 with `Status: blocked`, route out and stop:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/stop
 ```
 
 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 --prefer-offline --yes copilotkit@4.22.0 onboard read feature/chat-suggestions/proof`.
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/chat-suggestions/proof`.

package/onboarding/prompts/feature/chat-suggestions/plan.md

@@ -0,0 +1,71 @@
+# Plan chat suggestions with the developer
+
+The inspection in `feature/chat-suggestions/start` came back and proved what this intent
+needs. This prompt turns it into a plan, asks the developer to approve it, and records the
+protected paths the plan changes. Do not change project files in this prompt.
+
+## Waits and stops
+
+The rules in `feature/chat-suggestions/start` still hold here.
+
+The approval is a wait for the developer. Before you end your turn to wait, report the
+pause:
+
+```text
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase awaiting-developer
+```
+
+A turn that ends while the run waits is a pause, not a stop, even when your harness ends it.
+When the answer arrives, continue from the step that paused. If the developer asks for a
+change, show the changed plan and ask again.
+
+## What this prompt takes from the start
+
+Keep these from `feature/chat-suggestions/start`, and give them to every subagent:
+
+- the protected path list that `onboard protect` printed, and
+- the paths and findings the inspection returned: the CopilotKit provider, chat component,
+  message lifecycle, agent id, package version, test and dev commands, and the OSS round
+  trip that `verify` proved.
+
+If you do not hold them, as after `onboard resume` in a new session, get them back before
+you plan. Run `onboard protect` again from the target app directory: on the same run it
+prints the baseline the run already holds.
+
+```text
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect
+```
+
+Then have one read-only subagent repeat the inspection for the findings above, and wait
+for it. It changes no files.
+
+## Plan the change
+
+Do not run login, provision Intelligence, request a credential, replace the agent, or alter
+the existing runtime/persistence. Fetch the official hook guide before planning:
+https://docs.copilotkit.ai/reference/hooks/useConfigureSuggestions.md
+Use a second retrieval method if the first fails.
+
+Determine static versus dynamic suggestions from the repository. If the repository does
+not answer it, ask one short question only: recommend static suggestions for a predictable
+first-message experience, or offer dynamic suggestions when the developer needs
+context-dependent follow-ups. Show an approved-plan-sized diff, a focused test, and a
+proof that a visible suggestion submits the intended message. Ask for approval as its own
+question.
+
+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. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --prefer-offline --yes copilotkit@4.23.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 run `npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/chat-suggestions/implement`.

package/onboarding/prompts/feature/chat-suggestions/proof.md

@@ -20,7 +20,7 @@ still go on the record. Name the file and why the fix needs it, then end your tu
 for the developer's answer. If they allow it, record their answer before any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Continue only when the result starts with `Status: passed`. Run the audit again, take the
@@ -33,11 +33,11 @@ Report the outcome of each attempt as it ends, before any repair. The command co
 attempts and the repairs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.23.1 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Use `passed` only for a proved sent suggestion, `failed` for an attempted proof that failed,
-and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.22.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.23.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
@@ -52,9 +52,9 @@ the path and the change the audit reports. Run the audit again after each accept
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/complete` with the real browser-proof
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/complete` with the real browser-proof
 outcome.

package/onboarding/prompts/feature/chat-suggestions/start.md

@@ -19,13 +19,13 @@ carry on. Keep a read-only assignment read-only. If no subagent works at all, re
 once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase delegation-unavailable
 ```
 
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase awaiting-developer
 ```
 
 A turn that ends while the run waits is a pause, not a stop, even when your harness ends it.
@@ -35,7 +35,7 @@ If you stop this run, send one short report before you stop. The friction comman
 the telemetry setting the developer already chose, so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -49,7 +49,7 @@ one scoped fix, and sends the report itself when no fix is approved.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -58,46 +58,27 @@ approved authorization before implementation.
 
 Before edits, identify the current CopilotKit provider, chat component, message lifecycle,
 agent id, package version, and test/dev commands. Prove the existing OSS round trip with
-`/info`, `npx --prefer-offline --yes copilotkit@4.22.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --prefer-offline --yes copilotkit@4.23.1 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
 and one real frontend request when browser control is available.
 
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase research-returned
 ```
 
 If the inspection did not prove the baseline this intent extends, stop here without
 changing files:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/stop
 ```
 
-Do not run login, provision Intelligence, request a credential, replace the agent, or alter
-the existing runtime/persistence. Fetch the official hook guide before planning:
-https://docs.copilotkit.ai/reference/hooks/useConfigureSuggestions.md
-Use a second retrieval method if the first fails.
-
-Determine static versus dynamic suggestions from the repository. If the repository does not
-answer it, ask one short question only: recommend static suggestions for a predictable
-first-message experience, or offer dynamic suggestions when the developer needs
-context-dependent follow-ups. Show an approved-plan-sized diff, a focused test, and a proof
-that a visible suggestion submits the intended message.
-
-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. Authorization covers
-changing a protected path, not removing it, so the plan must not delete, move, or rename
-one.
-
-After approval, record each approved path before implementation:
+When the inspection proved what this intent needs, read the next prompt now, in this turn:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/chat-suggestions/plan
 ```
 
-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 run `npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/chat-suggestions/implement`.
+That prompt holds the plan, the developer's approval, and the paths the plan changes.
+Do not write the plan or change project files in this prompt.

package/onboarding/prompts/feature/complete.md

@@ -3,7 +3,7 @@
 Use the outcome the proof step observed. Run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard complete --visual-check <performed|skipped-no-browser-tool|channels-proof-passed|failed>
+npx --prefer-offline --yes copilotkit@4.23.1 onboard complete --visual-check <performed|skipped-no-browser-tool|channels-proof-passed|failed>
 ```
 
 Use `channels-proof-passed` for a Slack or Teams run that recorded a passed round-trip proof
@@ -22,7 +22,7 @@ Before `onboard complete`, send the friction this run mentioned to the developer
 report each, at most four, costliest first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
 ```
 
 Put one or two sentences in `--message`, with no secrets, source, or logs. Pick the

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

@@ -17,7 +17,7 @@ follows the telemetry setting the developer already chose, so it needs no separa
 question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -49,7 +49,7 @@ settled refusal rather than a missing baseline, so stop here, before any file ch
 take its own ending:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/blocked-by-plan
 ```
 
 `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -63,7 +63,7 @@ then, so the read below is where its refusal surfaces.
 When the plan or the repository already names an id, ask about that one id and nothing else:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 learning containers get <id> --json
+npx --prefer-offline --yes copilotkit@4.23.1 learning containers get <id> --json
 ```
 
 One call answers it, and no list is needed.
@@ -71,7 +71,7 @@ One call answers it, and no list is needed.
 When no id is in hand, survey what the project holds:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 learning containers list --json
+npx --prefer-offline --yes copilotkit@4.23.1 learning containers list --json
 ```
 
 One call returns at most 500 containers. When `nextCursor` in the result is not null, read
@@ -94,7 +94,7 @@ user, so the callback can return a different id per tier or per customer.
 Ask the CLI for the id rather than spelling one yourself:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 learning containers default-id --json
+npx --prefer-offline --yes copilotkit@4.23.1 learning containers default-id --json
 ```
 
 It derives the project-scoped id from the selected project's slug, reads the local project
@@ -108,7 +108,7 @@ run that spells the id differently gives one project two containers, each below
 above on its own. One command is what keeps the two spellings identical.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 learning containers create --id <id> --name <name> --json
+npx --prefer-offline --yes copilotkit@4.23.1 learning containers create --id <id> --name <name> --json
 ```
 
 An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
@@ -134,13 +134,13 @@ 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 --prefer-offline --yes copilotkit@4.22.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.23.1 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record secret-safe evidence.
 
 Before you spawn the implementation subagent, take the authorized list from the CLI:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.23.1 onboard audit
 ```
 
 From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
@@ -159,7 +159,7 @@ still go on the record. Name the file and why the work needs it, then end your t
 for the developer's answer. If they allow it, record their answer before any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Continue only when the result starts with `Status: passed`. Run the audit again, take the
@@ -171,7 +171,7 @@ feature stop route below.
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.23.1 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -182,7 +182,7 @@ with the implementation subagent's `Files changed` section. If that section does
 the path, accept the developer's external change:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -196,11 +196,11 @@ with `Status: blocked`, route out and stop. Route out the same way when
 `--accept-credential` refuses because it names a lost variable:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/stop
 ```
 
 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 --prefer-offline --yes copilotkit@4.22.0 onboard read feature/learning/proof`.
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/learning/proof`.

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

@@ -0,0 +1,82 @@
+# Plan Learning with the developer
+
+The inspection in `feature/learning/start` came back and proved what this intent needs.
+This prompt turns it into a plan, asks the developer to approve it, and records the
+protected paths the plan changes. Do not change project files in this prompt.
+
+## Waits and stops
+
+The rules in `feature/learning/start` still hold here.
+
+The approval is a wait for the developer. Before you end your turn to wait, report the
+pause:
+
+```text
+npx --prefer-offline --yes copilotkit@4.23.1 onboard checkpoint --phase awaiting-developer
+```
+
+A turn that ends while the run waits is a pause, not a stop, even when your harness ends it.
+When the answer arrives, continue from the step that paused. If the developer asks for a
+change, show the changed plan and ask again.
+
+## What this prompt takes from the start
+
+Keep these from `feature/learning/start`, and give them to every subagent:
+
+- the protected path list that `onboard protect` printed,
+- the paths and findings the inspection returned: the runtime, agent id, provider and
+  chat, server-side user identity, existing Intelligence configuration (presence only),
+  existing thread routes, test and dev commands, and the round trip, and
+- the answer `copilotkit learning containers list --json` gave.
+
+If you do not hold them, as after `onboard resume` in a new session, get them back before
+you plan. Run `onboard protect` again from the target app directory: on the same run it
+prints the baseline the run already holds.
+
+```text
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect
+```
+
+Then have one read-only subagent repeat the inspection for the findings above, and wait
+for it. It changes no files. If the Learning answer is lost, leave it.
+`feature/learning/implement` asks the same question again before any file changes.
+
+## Plan the change
+
+Fetch the current official guides before planning:
+https://docs.copilotkit.ai/learning.md
+https://docs.copilotkit.ai/backend/copilot-runtime.md
+https://docs.copilotkit.ai/intelligence/quickstart.md
+https://docs.copilotkit.ai/threads.md
+Use a second retrieval method if needed.
+
+The CLI owns the container. `copilotkit learning containers list --json` reads the ones this
+project already has, and `copilotkit learning containers create --id <id> --name <name>
+--json` makes one. So there is no dashboard step and no reason to guess: never invent an id,
+scrape a dashboard, or treat an arbitrary string as a container.
+
+Read the "Assign Threads to Learning Containers" section of that page. The container is
+chosen by `getLearningContainerId` on the `CopilotKitIntelligence` instance, which the
+same page documents. It receives the resolved application user and the run input, and it
+serves web and Channel runs through one API.
+
+Show a concise plan for managed runtime/thread prerequisites, a stable selected container,
+the documented `getLearningContainerId` selector, validation, and a visible assignment
+proof. Ask for approval as its own question.
+
+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. Authorization covers
+changing a protected path, not removing it, so the plan must not delete, move, or rename
+one.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --prefer-offline --yes copilotkit@4.23.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 run `npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/learning/implement`.

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

@@ -7,7 +7,7 @@ Container. Confirm the thread remains associated with the expected user.
 One command decides it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --prefer-offline --yes copilotkit@4.23.1 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
 ```
 
 It reads the thread back from the platform, so it answers for any runtime mount, and it
@@ -40,7 +40,7 @@ still go on the record. Name the file and why the fix needs it, then end your tu
 for the developer's answer. If they allow it, record their answer before any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
 Continue only when the result starts with `Status: passed`. Run the audit again, take the
@@ -53,12 +53,12 @@ Report the outcome of each attempt as it ends, before any repair. The command co
 attempts and the repairs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.23.1 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Use `passed` only for a proved Container assignment, `failed` for an attempted proof that
 failed, and `skipped` when the proof could not run. Then run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard audit`. Continue only when it starts with
+`npx --prefer-offline --yes copilotkit@4.23.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
@@ -73,9 +73,9 @@ the path and the change the audit reports. Run the audit again after each accept
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.22.0 onboard read feature/complete` with the actual surface
+`npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/complete` with the actual surface
 outcome.