copilotkit 4.24.0 → 4.25.0

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

@@ -2,7 +2,8 @@
 
 Delegate proof to a fresh subagent. In the real authenticated app, create or use a thread,
 send a normal agent request, and confirm the resulting run reached the selected Learning
-Container. Confirm the thread remains associated with the expected user.
+Container. Confirm the thread remains associated with the expected user. Where the proof
+uses `--thread` (below), that command cannot show the user, so read the user from the app.
 
 ## Check the local Learning model first
 
@@ -11,7 +12,7 @@ A local stack runs Learning only with a model that the developer gave it. Before
 run this command from the app directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 local status --json
+npx --prefer-offline --yes copilotkit@4.25.0 local status --json
 ```
 
 Read `learning.configuration`. If it is `configured`, continue with the proof. Any other
@@ -25,7 +26,7 @@ it has a model. Ask them to run this command in their own terminal window, in th
 directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 local setup
+npx --prefer-offline --yes copilotkit@4.25.0 local setup
 ```
 
 Do not give it as a `!` line, and do not run it yourself. Its guided model prompt needs a
@@ -35,13 +36,13 @@ On a running stack, it restarts only Learning. The container and its threads sta
 ask the developer to write a model file, and do not read or print the model key.
 
 Say that the run continues when they reply or resume this session. Report the pause with
-`npx --prefer-offline --yes copilotkit@4.24.0 onboard checkpoint --phase awaiting-model-credential`, end your
+`npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-model-credential`, end your
 turn, and wait. When the developer replies, run `local status --json` again.
 When it reports `configured`, continue with the proof.
 
 If the developer declines, continue with the proof, because the container assignment can
 still be proved. In the closing report, write "Learning configuration incomplete". Name the
-command that adds the model later: `npx --prefer-offline --yes copilotkit@4.24.0 local setup`, run from
+command that adds the model later: `npx --prefer-offline --yes copilotkit@4.25.0 local setup`, run from
 the app directory. `learning.verified` is always `false`. It does not mean that Learning
 failed.
 
@@ -50,12 +51,28 @@ failed.
 One command decides it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --prefer-offline --yes copilotkit@4.25.0 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
 passes only when that thread carries the container this run selected.
 
+That command starts its own run on a new thread. An app that runs only threads it created,
+or whose `identifyUser` reads a session, refuses that run, and the container check never
+runs. Do not change the app to accept it. Send one request on a new thread in the app, as
+a signed-in user, read that request's `threadId` from the request body the page sent to
+the runtime, and prove the same thread. Where the page needs a sign-in, do not create an
+account and do not enter credentials. Where you cannot send the request yourself, ask the
+developer to send one message on a new thread and give you its thread id. Report the pause
+with `npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-developer`, then
+end your turn and wait. When the developer gives the id, prove that thread:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 verify --expect-runtime intelligence --thread <thread-id> --expect-learning-container <id> --json
+```
+
+It reads that thread from the platform with the project key and starts no run.
+
 Two other signals look like proof and are not. `features.self_learning` is a plan
 entitlement and is already true before any wiring. The `/info` response reports Learning
 from the presence of a callback, not from a single assigned thread. Never report either one
@@ -79,11 +96,18 @@ not edit it. It returns a result that starts with `Status: blocked` and names th
 Blockers.
 
 That result is a question for the developer. The file has not changed yet, so consent can
-still go on the record. Name the file and why the fix needs it, then end your turn and wait
-for the developer's answer. If they allow it, record their answer before any edit:
+still go on the record. Name the file and why the fix needs it.
+Before you end your turn to wait for the developer, report the pause:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-developer
+```
+
+Then end your turn and wait for the developer's answer. If they allow it, record their
+answer before any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.25.0 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
@@ -96,12 +120,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.24.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.25.0 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.24.0 onboard audit`. Continue only when it starts with
+`npx --prefer-offline --yes copilotkit@4.25.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
@@ -116,9 +140,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.24.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/complete` with the actual surface
+`npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/complete` with the actual surface
 outcome.

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

@@ -9,17 +9,18 @@ subagents. Work only inside the target project and preserve its existing agent a
 Run this before anything else in this prompt:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard identify --coding-agent <coding-agent-slug> --model <model-id> --model-family <model-family>
+npx --prefer-offline --yes copilotkit@4.25.0 onboard identify --coding-agent <coding-agent-slug> --model <model-id> --model-family <model-family>
 ```
 
 Report your product slug, such as `codex` or `claude-code`. The command needs no sign-in,
 browser, or project. If this run already ran `onboard identify`, skip this step.
 
-- `--model`: copy the model id exactly as your instructions write it. If they name no
-  exact model id, leave out `--model` rather than guess.
-- `--model-family`: your model's family, such as `claude-opus` or `gpt-5`. Give it even
-  without `--model`, and leave out `--model-family` if you do not know it.
-- Never give your product slug as a model or a family.
+- `--model`: copy the model id exactly as your instructions write it. Without an exact
+  model id, leave out `--model` rather than guess.
+- `--model-family`: give it even without `--model`. Closest of: `claude-opus`,
+  `claude-sonnet`, `claude-haiku`, `gpt-5`, `gemini`, `grok`, `glm`, `minimax`, `mimo`,
+  `deepseek`, `qwen`, `kimi`, else the model's series. Leave it out if you do not know it.
+- Never give your product slug as a model, or as an unlisted family.
 
 ## Waits, stops, and subagents
 
@@ -37,13 +38,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.24.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.25.0 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.24.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.25.0 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.
@@ -53,7 +54,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.24.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.25.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -83,7 +84,7 @@ status:
   before the capture, the inspection, and any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/blocked-by-plan
 ```
 
 - `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -104,7 +105,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 --prefer-offline --yes copilotkit@4.24.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.25.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -118,20 +119,20 @@ test/dev commands. Prove the current round trip and inspect `/info`.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.25.0 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.24.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/stop
 ```
 
 When the inspection proved what this intent needs, read the next prompt now, in this turn:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/learning/plan
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/learning/plan
 ```
 
 That prompt holds the plan, the developer's approval, and the paths the plan changes.

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

@@ -16,7 +16,7 @@ validation results without secrets.
 Before you spawn the implementation subagent, take the authorized list from the CLI:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.25.0 onboard audit
 ```
 
 From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
@@ -31,11 +31,18 @@ protected path, it must not edit it. It returns a result that starts with `Statu
 and names the file under Blockers.
 
 That result is a question for the developer. The file has not changed yet, so consent can
-still go on the record. Name the file and why the work needs it, then end your turn and wait
-for the developer's answer. If they allow it, record their answer before any edit:
+still go on the record. Name the file and why the work needs it.
+Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-developer
+```
+
+Then end your turn and wait for the developer's answer. If they allow it, record their
+answer before any edit:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 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
@@ -47,7 +54,7 @@ feature stop route below.
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.25.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -58,7 +65,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.24.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.25.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -71,11 +78,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.24.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.25.0 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.24.0 onboard read feature/open-generative-ui/proof`.
+`npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/open-generative-ui/proof`.

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

@@ -12,7 +12,7 @@ The approval is a wait for the developer. Before you end your turn to wait, repo
 pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.25.0 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.
@@ -33,7 +33,7 @@ you plan. Run `onboard protect` again from the target app directory: on the same
 prints the baseline the run already holds.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.25.0 onboard protect
 ```
 
 Then have one read-only subagent repeat the inspection for the findings above, and wait
@@ -52,19 +52,27 @@ 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 as its own question.
 
+Before you end your turn to wait for the developer, report the pause:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-plan-approval
+```
+
 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.
+with one sentence explaining why. Write `None` when it needs none. A step that installs or
+upgrades a package changes its manifest, so list a protected manifest such as `package.json`
+or `pyproject.toml`. Its consent covers its lockfile, beside it or at the workspace root.
+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.24.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.25.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
 `--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.24.0 onboard read feature/open-generative-ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/open-generative-ui/implement`.

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

@@ -17,11 +17,18 @@ not edit it. It returns a result that starts with `Status: blocked` and names th
 Blockers.
 
 That result is a question for the developer. The file has not changed yet, so consent can
-still go on the record. Name the file and why the fix needs it, then end your turn and wait
-for the developer's answer. If they allow it, record their answer before any edit:
+still go on the record. Name the file and why the fix needs it.
+Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-developer
+```
+
+Then end your turn and wait for the developer's answer. If they allow it, record their
+answer before any edit:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 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
@@ -34,11 +41,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.24.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.25.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 --prefer-offline --yes copilotkit@4.24.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.25.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
@@ -53,9 +60,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.24.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/complete` with the outcome actually
+`npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/complete` with the outcome actually
 observed.

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

@@ -8,17 +8,18 @@ implementation, and proof subagents, all restricted to the target project direct
 Run this before anything else in this prompt:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard identify --coding-agent <coding-agent-slug> --model <model-id> --model-family <model-family>
+npx --prefer-offline --yes copilotkit@4.25.0 onboard identify --coding-agent <coding-agent-slug> --model <model-id> --model-family <model-family>
 ```
 
 Report your product slug, such as `codex` or `claude-code`. The command needs no sign-in,
 browser, or project. If this run already ran `onboard identify`, skip this step.
 
-- `--model`: copy the model id exactly as your instructions write it. If they name no
-  exact model id, leave out `--model` rather than guess.
-- `--model-family`: your model's family, such as `claude-opus` or `gpt-5`. Give it even
-  without `--model`, and leave out `--model-family` if you do not know it.
-- Never give your product slug as a model or a family.
+- `--model`: copy the model id exactly as your instructions write it. Without an exact
+  model id, leave out `--model` rather than guess.
+- `--model-family`: give it even without `--model`. Closest of: `claude-opus`,
+  `claude-sonnet`, `claude-haiku`, `gpt-5`, `gemini`, `grok`, `glm`, `minimax`, `mimo`,
+  `deepseek`, `qwen`, `kimi`, else the model's series. Leave it out if you do not know it.
+- Never give your product slug as a model, or as an unlisted family.
 
 ## Waits, stops, and subagents
 
@@ -36,13 +37,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.24.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.25.0 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.24.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.25.0 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.
@@ -52,7 +53,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.24.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.25.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -66,7 +67,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.24.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.25.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -76,26 +77,26 @@ 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 --prefer-offline --yes copilotkit@4.24.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`npx --prefer-offline --yes copilotkit@4.25.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
 and a 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.24.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.25.0 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.24.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/stop
 ```
 
 When the inspection proved what this intent needs, read the next prompt now, in this turn:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/open-generative-ui/plan
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/open-generative-ui/plan
 ```
 
 That prompt holds the plan, the developer's approval, and the paths the plan changes.

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

@@ -12,19 +12,20 @@ or rewrite either endpoint. For hosted setup, do not add a speculative URL.
 
 An Intelligence runtime requires `identifyUser`, and it usually reads a signed-in session
 that a CLI request does not carry. That makes the round trip UNKNOWN and the command exit
-non-zero on an app that is working. Pass what `identifyUser` reads with a repeatable
-`--header "Name: value"`, or record UNKNOWN as the expected result for an auth-gated app.
-It is not a defect to repair.
+non-zero on an app that is working. It is not a defect to repair. The proof step proves
+such an app on a thread the app created, with `--thread <id>`, which needs no session. Pass
+`--header "Name: value"` only when the developer offers what `identifyUser` reads, or
+record UNKNOWN as the expected result here.
 
 Run focused tests and
-`npx --prefer-offline --yes copilotkit@4.24.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.25.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record changed paths and secret-safe validation
 evidence.
 
 Before you spawn the implementation subagent, take the authorized list from the CLI:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.25.0 onboard audit
 ```
 
 From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
@@ -39,11 +40,18 @@ protected path, it must not edit it. It returns a result that starts with `Statu
 and names the file under Blockers.
 
 That result is a question for the developer. The file has not changed yet, so consent can
-still go on the record. Name the file and why the work needs it, then end your turn and wait
-for the developer's answer. If they allow it, record their answer before any edit:
+still go on the record. Name the file and why the work needs it.
+Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-developer
+```
+
+Then end your turn and wait for the developer's answer. If they allow it, record their
+answer before any edit:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 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
@@ -55,7 +63,7 @@ feature stop route below.
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.25.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -66,7 +74,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.24.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.25.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -79,11 +87,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.24.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.25.0 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.24.0 onboard read feature/realtime-sync/proof`.
+`npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/realtime-sync/proof`.

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

@@ -12,7 +12,7 @@ The approval is a wait for the developer. Before you end your turn to wait, repo
 pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.25.0 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.
@@ -34,7 +34,7 @@ you plan. Run `onboard protect` again from the target app directory: on the same
 prints the baseline the run already holds.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.25.0 onboard protect
 ```
 
 Then have one read-only subagent repeat the inspection for the findings above, and wait
@@ -57,19 +57,27 @@ 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 as its own question.
 
+Before you end your turn to wait for the developer, report the pause:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-plan-approval
+```
+
 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.
+with one sentence explaining why. Write `None` when it needs none. A step that installs or
+upgrades a package changes its manifest, so list a protected manifest such as `package.json`
+or `pyproject.toml`. Its consent covers its lockfile, beside it or at the workspace root.
+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.24.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.25.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
 `--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.24.0 onboard read feature/realtime-sync/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/realtime-sync/implement`.

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

@@ -19,11 +19,18 @@ not edit it. It returns a result that starts with `Status: blocked` and names th
 Blockers.
 
 That result is a question for the developer. The file has not changed yet, so consent can
-still go on the record. Name the file and why the fix needs it, then end your turn and wait
-for the developer's answer. If they allow it, record their answer before any edit:
+still go on the record. Name the file and why the fix needs it.
+Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.24.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.25.0 onboard checkpoint --phase awaiting-developer
+```
+
+Then end your turn and wait for the developer's answer. If they allow it, record their
+answer before any edit:
+
+```text
+npx --prefer-offline --yes copilotkit@4.25.0 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
@@ -36,11 +43,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.24.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.25.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 --prefer-offline --yes copilotkit@4.24.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.25.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
@@ -55,8 +62,8 @@ 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.24.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/complete` with the actual outcome.
+`npx --prefer-offline --yes copilotkit@4.25.0 onboard read feature/complete` with the actual outcome.