copilotkit 4.16.0 → 4.17.0

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

@@ -17,14 +17,45 @@ 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.16.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.17.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.17.0 onboard audit
+```
+
+From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
+no such block means that nothing is authorized. Read only that block now, and decide the
+findings of a failed audit after implementation, with the audit rules below. If this audit
+starts with `Status: blocked`, the CLI cannot supply the list. Report the printed reason and
+take the feature stop route below.
+
+Give the implementation subagent the protected path list and the authorized list. Tell it
+this rule: it can change a path on the authorized list. When the work needs any other
+protected path, it must not edit it. It returns a result that starts with `Status: blocked`
+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:
+
+```text
+npx --prefer-offline --yes copilotkit@4.17.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
+new list from its `Authorized to modify:` block, and spawn a fresh implementation subagent
+with the same handoff and that list. A subagent that already returned cannot pick up consent
+recorded after it was spawned. If you cannot ask, or the developer declines, take the
+feature stop route below.
+
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.17.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -35,33 +66,30 @@ 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.16.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.17.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
 `onboard protect --accept-credential --path <path>` instead. If the subagent names the path,
-or its report does not settle who changed it, ask the developer to allow the unplanned
-change. Only after they agree, record their answer:
-
-```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
-```
+or its report does not settle who changed it, the change is this run's own, made without
+consent. Do not ask the developer to allow it: the CLI refuses consent for a path that
+already changed. Route out, and name the path and the change the audit reports.
 
-Run the audit again after each accepted or authorized change. If it still fails, or starts
+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.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase build-validated
 ```
 
 If validation cannot pass, or this intent needs a prerequisite the app does not have, use
 the feature stop route above without further changes.
 
 Otherwise run
-`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/realtime-sync/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/realtime-sync/proof`.

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

@@ -4,33 +4,54 @@ Delegate proof to a fresh subagent. Open the same authenticated project/thread i
 browser contexts. From context A, create or mutate a thread and send a message. Require
 context B to receive the thread/message change without a manual reload. Then exercise a
 second mutation in the reverse direction where the product supports it. Keep the managed
-round-trip verification green.
+round-trip verification result that implementation recorded: passed, or UNKNOWN for an
+auth-gated app.
 
 Record both visible states, actions, timing, app URL, process IDs, and safe stop commands.
 A successful WebSocket connection, a server event, or a refreshed second tab is not proof.
 Repair changed-file defects and repeat. If the environment cannot drive two contexts, report
 the missing proof rather than claiming realtime works.
 
+Give the proof subagent the protected path list and the authorized list. Take that list from
+the latest audit, and copy the paths under `Authorized to modify:`. Tell it this rule: a fix
+can change a path on the authorized list. When a fix needs any other protected path, it must
+not edit it. It returns a result that starts with `Status: blocked` 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 fix needs it, 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.17.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
+new list from its `Authorized to modify:` block, and spawn a fresh proof subagent with the
+same handoff and that list. A subagent that already returned cannot pick up consent recorded
+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:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.17.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.16.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.17.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.16.0 onboard audit`.
+and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.17.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
@@ -38,15 +59,15 @@ with the proof subagent's `Files changed` section. If that section does not name
 run `onboard protect --accept-external --path <path>`, or
 `onboard protect --accept-credential --path <path>` for an env file where the developer
 placed a requested credential. If the subagent names the path, or its report does not settle
-who changed it, ask the developer to allow it. Only after they agree, run
-`onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"`.
-Run the audit again after each accepted or authorized change.
+who changed it, the change is this run's own, made without consent. Do not ask the developer
+to allow it: the CLI refuses consent for a path that already changed. Route out, and name
+the path and the change the audit reports. Run the audit again after each accepted change.
 
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/complete` with the actual outcome.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/complete` with the actual outcome.

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

@@ -7,7 +7,7 @@ two-context proof to subagents within the target project.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.17.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -17,13 +17,12 @@ approved authorization before implementation.
 Before edits, inspect the current runtime, provider/chat, agent id, authenticated stable user
 identity, thread routes, existing Intelligence configuration (presence only), current websocket
 configuration, and normal test/dev commands. Prove the current frontend-to-runtime-to-agent
-round trip and inspect `/info`. If this is not an existing CopilotKit app, leave files
-unchanged and direct the developer to generic onboarding first.
+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.16.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -33,11 +32,11 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
-https://docs.copilotkit.ai/intelligence/connect-your-runtime.md
+https://docs.copilotkit.ai/intelligence/quickstart.md
 https://docs.copilotkit.ai/auth.md
 https://docs.copilotkit.ai/intelligence/threads-explained.md
 https://docs.copilotkit.ai/reference/hooks/useThreads.md
@@ -59,7 +58,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.17.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
@@ -69,7 +68,7 @@ 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.16.0 onboard checkpoint --phase plan-written
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/realtime-sync/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/realtime-sync/implement`.

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

@@ -2,7 +2,7 @@
 
 Delegate implementation to one subagent with the approved plan and fetched official guides.
 If repository evidence does not prove an existing valid Intelligence selection, run
-`npx --prefer-offline --yes copilotkit@4.16.0 login --json` and follow its single streaming session. Then
+`npx --prefer-offline --yes copilotkit@4.17.0 login --json` and follow its single streaming session. Then
 list projects, show the developer the current/recent choices, and select or create one only
 after they choose. Require the secret-safe selection summary to confirm the project file,
 environment file, and key provisioning; never display a key. If existing configuration is
@@ -20,14 +20,45 @@ non-zero on an app that is working. Pass what `identifyUser` reads with a repeat
 It is not a defect to repair.
 
 Run focused type/test commands, then start the app and run
-`npx --prefer-offline --yes copilotkit@4.16.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --prefer-offline --yes copilotkit@4.17.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures before continuing. 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.17.0 onboard audit
+```
+
+From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
+no such block means that nothing is authorized. Read only that block now, and decide the
+findings of a failed audit after implementation, with the audit rules below. If this audit
+starts with `Status: blocked`, the CLI cannot supply the list. Report the printed reason and
+take the feature stop route below.
+
+Give the implementation subagent the protected path list and the authorized list. Tell it
+this rule: it can change a path on the authorized list. When the work needs any other
+protected path, it must not edit it. It returns a result that starts with `Status: blocked`
+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:
+
+```text
+npx --prefer-offline --yes copilotkit@4.17.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
+new list from its `Authorized to modify:` block, and spawn a fresh implementation subagent
+with the same handoff and that list. A subagent that already returned cannot pick up consent
+recorded after it was spawned. If you cannot ask, or the developer declines, take the
+feature stop route below.
+
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.17.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -38,33 +69,30 @@ 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.16.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.17.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
 `onboard protect --accept-credential --path <path>` instead. If the subagent names the path,
-or its report does not settle who changed it, ask the developer to allow the unplanned
-change. Only after they agree, record their answer:
-
-```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
-```
+or its report does not settle who changed it, the change is this run's own, made without
+consent. Do not ask the developer to allow it: the CLI refuses consent for a path that
+already changed. Route out, and name the path and the change the audit reports.
 
-Run the audit again after each accepted or authorized change. If it still fails, or starts
+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.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase build-validated
 ```
 
 If validation cannot pass, or this intent needs a prerequisite the app does not have, use
 the feature stop route above without further changes.
 
 Otherwise run
-`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/rich-threads/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/rich-threads/proof`.

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

@@ -3,34 +3,55 @@
 Delegate proof to a fresh subagent. In the real authenticated frontend, create a conversation,
 send a distinct message, confirm the response, reload or reopen the same thread, and require
 the prior history to remain visible for that same stable user. Confirm the runtime exposes
-the required thread routes and the Intelligence verification remains successful.
+the required thread routes and the Intelligence verification keeps the result that
+implementation recorded: passed, or UNKNOWN for an auth-gated app.
 
 Record the interaction, visible persisted history, app URL, process IDs, and safe stop
 commands. Do not count a thread id in a log, a successful API call, or an in-memory history
 as proof. Repair defects caused by changed files and repeat. Keep project-owned servers
 running.
 
+Give the proof subagent the protected path list and the authorized list. Take that list from
+the latest audit, and copy the paths under `Authorized to modify:`. Tell it this rule: a fix
+can change a path on the authorized list. When a fix needs any other protected path, it must
+not edit it. It returns a result that starts with `Status: blocked` 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 fix needs it, 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.17.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
+new list from its `Authorized to modify:` block, and spawn a fresh proof subagent with the
+same handoff and that list. A subagent that already returned cannot pick up consent recorded
+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:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase journey-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.17.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.16.0 onboard checkpoint --phase repair-attempted --attempt 1
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
 After the final attempt, report the gate exactly once:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.17.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
 ```
 
 Use `passed` only for proved persistence and reopen, `failed` for an attempted proof that
 failed, and `skipped` when the proof could not run. Then run
-`npx --prefer-offline --yes copilotkit@4.16.0 onboard audit`. Continue only when it starts with
+`npx --prefer-offline --yes copilotkit@4.17.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
@@ -38,16 +59,16 @@ with the proof subagent's `Files changed` section. If that section does not name
 run `onboard protect --accept-external --path <path>`, or
 `onboard protect --accept-credential --path <path>` for an env file where the developer
 placed a requested credential. If the subagent names the path, or its report does not settle
-who changed it, ask the developer to allow it. Only after they agree, run
-`onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"`.
-Run the audit again after each accepted or authorized change.
+who changed it, the change is this run's own, made without consent. Do not ask the developer
+to allow it: the CLI refuses consent for a path that already changed. Route out, and name
+the path and the change the audit reports. Run the audit again after each accepted change.
 
 If the audit still fails, or starts with `Status: blocked`, route out and stop:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/complete` with the actual browser
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/complete` with the actual browser
 outcome.

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

@@ -7,7 +7,7 @@ implementation, and proof to separate subagents within the target project.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.17.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -17,13 +17,12 @@ approved authorization before implementation.
 Before edits, have a read-only subagent locate the runtime route, CopilotKit provider/chat,
 agent id, current thread UI or headless API, authentication boundary, stable server-side user
 identity source, current project configuration (presence only), and test/dev commands. Prove
-the current frontend-to-runtime-to-agent round trip and inspect `/info`. If the project lacks
-an existing CopilotKit app, leave it unchanged and direct the developer to generic onboarding.
+the current frontend-to-runtime-to-agent 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.16.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -33,13 +32,13 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
 https://docs.copilotkit.ai/threads.md
 https://docs.copilotkit.ai/threads-lifecycle.md
-https://docs.copilotkit.ai/intelligence/connect-your-runtime.md
+https://docs.copilotkit.ai/intelligence/quickstart.md
 https://docs.copilotkit.ai/auth.md
 https://docs.copilotkit.ai/prebuilt-components/copilot-threads-drawer.md
 Retry unavailable pages a second way. Do not infer an identity from a browser display name or
@@ -61,7 +60,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+npx --prefer-offline --yes copilotkit@4.17.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
@@ -71,7 +70,7 @@ 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.16.0 onboard checkpoint --phase plan-written
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/rich-threads/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/rich-threads/implement`.

package/onboarding/prompts/feature/stop.md

@@ -20,7 +20,7 @@ a `start` with no `--run` reprints the id this stopped run already holds, and on
 covering both reads as one run that did two different things.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard start --run <new-12-character-id>
+npx --prefer-offline --yes copilotkit@4.17.0 onboard start --run <new-12-character-id>
 ```
 
 Do not read a generic onboarding node from this run. A feature run and a generic run are
@@ -48,7 +48,7 @@ put to them, stop here and send the report below.
 If they approve it, make that one fix and nothing else. Then come back into this run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard resume --message "<approval>"
+npx --prefer-offline --yes copilotkit@4.17.0 onboard resume --message "<approval>"
 ```
 
 Put the developer's approval in `--message`, in one or two sentences: the fix they
@@ -69,7 +69,7 @@ Send one short report. Run the friction command without another developer questi
 ask the developer about telemetry: the command applies the setting they already have.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.17.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.

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

@@ -11,10 +11,41 @@ type/test command and start the app. Confirm `/info` reports
 `audioFileTranscriptionEnabled`, but treat it as capability evidence rather than completed
 voice proof. Record changed paths and validation results.
 
+Before you spawn the implementation subagent, take the authorized list from the CLI:
+
+```text
+npx --prefer-offline --yes copilotkit@4.17.0 onboard audit
+```
+
+From its result, copy the paths under `Authorized to modify:`. A passed or failed audit with
+no such block means that nothing is authorized. Read only that block now, and decide the
+findings of a failed audit after implementation, with the audit rules below. If this audit
+starts with `Status: blocked`, the CLI cannot supply the list. Report the printed reason and
+take the feature stop route below.
+
+Give the implementation subagent the protected path list and the authorized list. Tell it
+this rule: it can change a path on the authorized list. When the work needs any other
+protected path, it must not edit it. It returns a result that starts with `Status: blocked`
+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:
+
+```text
+npx --prefer-offline --yes copilotkit@4.17.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
+new list from its `Authorized to modify:` block, and spawn a fresh implementation subagent
+with the same handoff and that list. A subagent that already returned cannot pick up consent
+recorded after it was spawned. If you cannot ask, or the developer declines, take the
+feature stop route below.
+
 After validation and each repair, run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard audit
+npx --prefer-offline --yes copilotkit@4.17.0 onboard audit
 ```
 
 Continue only when it starts with `Status: passed`. A path under `Authorized to modify:` is
@@ -25,33 +56,30 @@ 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.16.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.17.0 onboard protect --accept-external --path <path>
 ```
 
 For an env file where the developer placed a requested credential, use
 `onboard protect --accept-credential --path <path>` instead. If the subagent names the path,
-or its report does not settle who changed it, ask the developer to allow the unplanned
-change. Only after they agree, record their answer:
-
-```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
-```
+or its report does not settle who changed it, the change is this run's own, made without
+consent. Do not ask the developer to allow it: the CLI refuses consent for a path that
+already changed. Route out, and name the path and the change the audit reports.
 
-Run the audit again after each accepted or authorized change. If it still fails, or starts
+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.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase build-validated
 ```
 
 If validation cannot pass, or this intent needs a prerequisite the app does not have, use
 the feature stop route above without further changes.
 
 Otherwise run
-`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/voice/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/voice/proof`.