copilotkit 4.18.0 → 4.20.0

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.18.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.20.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 +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.18.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.20.0 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.18.0 learning containers get <id> --json
+npx --prefer-offline --yes copilotkit@4.20.0 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.18.0 learning containers list --json
+npx --prefer-offline --yes copilotkit@4.20.0 learning containers list --json
 ```
 
 One call returns at most 500 containers. When `nextCursor` in the result is not null, read
@@ -79,15 +79,6 @@ the next page with `--cursor <nextCursor>` and keep going until it is null. A pr
 container sits on the second page looks empty to a single call, and the run then adds a
 second container for work the first one already covers.
 
-Report what the read found before asking anyone anything:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase container-surveyed
-```
-
-Everything after this waits on a person, so a run that stops past this point stopped on a
-decision rather than on a read.
-
 Reuse an existing container when one covers the workflow this run is instrumenting, and ask
 the developer which one when more than one could. Otherwise create one.
 
@@ -103,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.18.0 learning containers default-id --json
+npx --prefer-offline --yes copilotkit@4.20.0 learning containers default-id --json
 ```
 
 It derives the project-scoped id from the selected project's slug, reads the local project
@@ -117,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.18.0 learning containers create --id <id> --name <name> --json
+npx --prefer-offline --yes copilotkit@4.20.0 learning containers create --id <id> --name <name> --json
 ```
 
 An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
@@ -129,16 +120,6 @@ the cheap one to keep: a selector wired to an id the platform does not hold retu
 breaks on the next message. If the id does not resolve, take the feature stop route below. Do not write a placeholder
 or a guessed id.
 
-Then report that the container is settled, before any edit:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase container-settled
-```
-
-Everything above happens between two prompts, so a run that stopped on a developer who could
-not choose, on a taken id, or on an id that never resolved would otherwise report the plan
-and then nothing at all.
-
 Add only the documented managed runtime/thread prerequisites and the selected
 `getLearningContainerId` on the `CopilotKitIntelligence` instance. Return the same stable
 1-64 character id for the same thread every time: a thread cannot move after its first
@@ -153,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.18.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.20.0 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.18.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.20.0 onboard audit
 ```
 
 From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
@@ -178,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.18.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.20.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
@@ -190,7 +171,7 @@ feature stop route below.
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.20.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -201,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.18.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.20.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -215,17 +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.18.0 onboard read feature/stop
-```
-
-When implementation validation passes, report it:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard read feature/learning/proof`.
+`npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/learning/proof`.

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.18.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --prefer-offline --yes copilotkit@4.20.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 +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.18.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.20.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
@@ -49,27 +49,16 @@ same handoff and that list. A subagent that already returned cannot pick up cons
 after it was spawned. If you cannot ask, or the developer declines, take the feature stop
 route below.
 
-Report each attempt at the proof as it ends, counting from one:
+Report the outcome of each attempt as it ends, before any repair. The command counts the
+attempts and the repairs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase journey-attempted --attempt 1
-```
-
-Report each repair cycle the same way, counting from one:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase repair-attempted --attempt 1
-```
-
-After the final attempt, report the gate exactly once:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard audit`. Continue only when it starts with
+`npx --prefer-offline --yes copilotkit@4.20.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
@@ -84,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.18.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/complete` with the actual surface
+`npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/complete` with the actual surface
 outcome.

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

@@ -20,13 +20,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.18.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.20.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 +36,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.18.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.20.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 +66,7 @@ status:
   before the capture, the inspection, and any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/blocked-by-plan
 ```
 
 - `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -87,7 +87,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.18.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.20.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -101,17 +101,14 @@ 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.18.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.20.0 onboard checkpoint --phase research-returned
 ```
 
-A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
-failed step.
-
 If the inspection did not prove the baseline this intent extends, stop here without
 changing files:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -143,17 +140,11 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.20.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 report the plan this run is about to implement:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase plan-written
-```
-
-Then run `npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/learning/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/learning/implement`.

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.18.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.20.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -71,17 +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.18.0 onboard read feature/stop
-```
-
-When implementation validation passes, report it:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard read feature/open-generative-ui/proof`.
+`npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/open-generative-ui/proof`.

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.18.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.20.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
@@ -30,26 +30,15 @@ same handoff and that list. A subagent that already returned cannot pick up cons
 after it was spawned. If you cannot ask, or the developer declines, take the feature stop
 route below.
 
-Report each attempt at the proof as it ends, counting from one:
+Report the outcome of each attempt as it ends, before any repair. The command counts the
+attempts and the repairs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase journey-attempted --attempt 1
-```
-
-Report each repair cycle the same way, counting from one:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase repair-attempted --attempt 1
-```
-
-After the final attempt, report the gate exactly once:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.20.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
@@ -64,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.18.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/complete` with the outcome actually
+`npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/complete` with the outcome actually
 observed.

package/onboarding/prompts/feature/open-generative-ui/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.18.0 onboard checkpoint --phase delegation-unavailable
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.20.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 +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.18.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.20.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 +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.18.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.20.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -59,23 +59,20 @@ 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.18.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.20.0 onboard checkpoint --phase research-returned
 ```
 
-A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
-failed step.
-
 If the inspection did not prove the baseline this intent extends, stop here without
 changing files:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/stop
 ```
 
 Do not sign in, select an Intelligence project, create credentials, change the existing
@@ -97,17 +94,11 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.20.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 report the plan this run is about to implement:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase plan-written
-```
-
-Then run `npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/open-generative-ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/open-generative-ui/implement`.

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

@@ -17,14 +17,14 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused tests and
-`npx --prefer-offline --yes copilotkit@4.18.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.20.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
@@ -79,17 +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.18.0 onboard read feature/stop
-```
-
-When implementation validation passes, report it:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard read feature/realtime-sync/proof`.
+`npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/realtime-sync/proof`.

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.18.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+npx --prefer-offline --yes copilotkit@4.20.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
@@ -32,26 +32,15 @@ same handoff and that list. A subagent that already returned cannot pick up cons
 after it was spawned. If you cannot ask, or the developer declines, take the feature stop
 route below.
 
-Report each attempt at the proof as it ends, counting from one:
+Report the outcome of each attempt as it ends, before any repair. The command counts the
+attempts and the repairs:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase journey-attempted --attempt 1
-```
-
-Report each repair cycle the same way, counting from one:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase repair-attempted --attempt 1
-```
-
-After the final attempt, report the gate exactly once:
-
-```text
-npx --prefer-offline --yes copilotkit@4.18.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.20.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.18.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.20.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
@@ -66,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.18.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/complete` with the actual outcome.
+`npx --prefer-offline --yes copilotkit@4.20.0 onboard read feature/complete` with the actual outcome.