copilotkit 4.23.1 → 4.24.0

package/onboarding/prompts/feature/learning/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.23.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard protect
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
 ```
 
 Then have one read-only subagent repeat the inspection for the findings above, and wait
@@ -72,11 +72,11 @@ 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>"
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/learning/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/learning/implement`.

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

@@ -4,10 +4,53 @@ Delegate proof to a fresh subagent. In the real authenticated app, create or use
 send a normal agent request, and confirm the resulting run reached the selected Learning
 Container. Confirm the thread remains associated with the expected user.
 
+## Check the local Learning model first
+
+If the app directory has `.copilotkit/local.json`, the app uses a local evaluation stack.
+A local stack runs Learning only with a model that the developer gave it. Before the proof,
+run this command from the app directory:
+
+```text
+npx --prefer-offline --yes copilotkit@4.24.0 local status --json
+```
+
+Read `learning.configuration`. If it is `configured`, continue with the proof. Any other
+value means that the stack has no Learning model.
+
+If the developer chose "configure later" in `deployment/choose-local`, and the run's plan
+records that choice, do not ask again. Continue with the proof, and report it as below.
+
+Otherwise, tell the developer that Learning cannot process this container's threads until
+it has a model. Ask them to run this command in their own terminal window, in the app
+directory:
+
+```text
+npx --prefer-offline --yes copilotkit@4.24.0 local setup
+```
+
+Do not give it as a `!` line, and do not run it yourself. Its guided model prompt needs a
+terminal, and a coding agent's shell has none. Without a terminal, the command stops and
+changes nothing. The prompt asks for the model and its key, and it saves them privately.
+On a running stack, it restarts only Learning. The container and its threads stay. Do not
+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
+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
+the app directory. `learning.verified` is always `false`. It does not mean that Learning
+failed.
+
+## Prove the container assignment
+
 One command decides it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.23.1 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --prefer-offline --yes copilotkit@4.24.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
@@ -40,7 +83,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.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.24.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
@@ -53,12 +96,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.23.1 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard audit`. Continue only when it starts with
+`npx --prefer-offline --yes copilotkit@4.24.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
@@ -73,9 +116,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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/complete` with the actual surface
+`npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/complete` with the actual surface
 outcome.

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

@@ -4,6 +4,23 @@ 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.
 
+## First, say which coding agent you are
+
+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>
+```
+
+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.
+
 ## Waits, stops, and subagents
 
 A run that starts here has not read these rules yet, so they come first. They cover this
@@ -20,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.23.1 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.24.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.
@@ -36,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.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.24.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 +83,7 @@ status:
   before the capture, the inspection, and any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/blocked-by-plan
 ```
 
 - `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -87,7 +104,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.23.1 onboard protect
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -101,20 +118,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.23.1 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/learning/plan
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard audit
+npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
 ```
 
 From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
@@ -35,7 +35,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.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.24.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 +47,7 @@ feature stop route below.
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.23.1 onboard audit
+npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -58,7 +58,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.23.1 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -71,11 +71,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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/open-generative-ui/proof`.
+`npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard protect
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
 ```
 
 Then have one read-only subagent repeat the inspection for the findings above, and wait
@@ -60,11 +60,11 @@ 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>"
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/open-generative-ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/open-generative-ui/implement`.

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

@@ -21,7 +21,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.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.24.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 +34,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.23.1 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard audit`.
+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 `Status: passed`.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -53,9 +53,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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/complete` with the outcome actually
+`npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/complete` with the outcome actually
 observed.

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

@@ -3,6 +3,23 @@
 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.
 
+## First, say which coding agent you are
+
+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>
+```
+
+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.
+
 ## Waits, stops, and subagents
 
 A run that starts here has not read these rules yet, so they come first. They cover this
@@ -19,13 +36,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.23.1 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.24.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.
@@ -35,7 +52,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.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.24.0 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 +66,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.23.1 onboard protect
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -59,26 +76,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.23.1 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/open-generative-ui/plan
+npx --prefer-offline --yes copilotkit@4.24.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

@@ -17,14 +17,14 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused tests and
-`npx --prefer-offline --yes copilotkit@4.23.1 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard audit
+npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
 ```
 
 From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
@@ -43,7 +43,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.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.24.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 +55,7 @@ feature stop route below.
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.23.1 onboard audit
+npx --prefer-offline --yes copilotkit@4.24.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -66,7 +66,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.23.1 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -79,11 +79,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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/realtime-sync/proof`.
+`npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard protect
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
 ```
 
 Then have one read-only subagent repeat the inspection for the findings above, and wait
@@ -65,11 +65,11 @@ 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>"
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/realtime-sync/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/realtime-sync/implement`.

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

@@ -23,7 +23,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.23.1 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.24.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 +36,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.23.1 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard audit`.
+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 `Status: passed`.
 
 If the audit fails, never repair, reset, or revert a protected path. Compare each named path
@@ -55,8 +55,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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.23.1 onboard read feature/complete` with the actual outcome.
+`npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/complete` with the actual outcome.

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

@@ -4,6 +4,23 @@ 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.
 
+## First, say which coding agent you are
+
+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>
+```
+
+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.
+
 ## Waits, stops, and subagents
 
 A run that starts here has not read these rules yet, so they come first. They cover this
@@ -20,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.23.1 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.24.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.
@@ -36,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.23.1 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.24.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.
@@ -50,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.23.1 onboard protect
+npx --prefer-offline --yes copilotkit@4.24.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -65,20 +82,20 @@ 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.23.1 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.24.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.23.1 onboard read feature/realtime-sync/plan
+npx --prefer-offline --yes copilotkit@4.24.0 onboard read feature/realtime-sync/plan
 ```
 
 That prompt holds the plan, the developer's approval, and the paths the plan changes.