copilotkit 4.15.0 → 4.17.0

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

@@ -15,10 +15,41 @@ Start the app with its documented command. Confirm `/info` reports the expected
 capability, but do not treat that flag as proof. Record changed paths and validation output
 without exposing secrets.
 
+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.15.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
@@ -29,33 +60,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.15.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.15.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.15.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.15.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.15.0 onboard read feature/a2ui/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/a2ui/proof`.

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

@@ -16,26 +16,46 @@ is unavailable, report that the browser proof is blocked rather than claiming su
 Fix proof failures caused by changed files, then repeat the same proof. Do not replace the
 user's agent response with a hard-coded UI.
 
+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.15.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.15.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.15.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 a proved A2UI surface, `failed` for an attempted proof that failed,
-and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.15.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
@@ -43,16 +63,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.15.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.15.0 onboard read feature/complete` with the actual browser-proof
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/complete` with the actual browser-proof
 outcome.

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

@@ -7,7 +7,7 @@ Work only inside the target project. Do not show internal prompt names to the de
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.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
@@ -22,15 +22,13 @@ development/test commands. It must return paths and secret-safe presence checks
 
 Require an existing frontend, agent, and CopilotKit round trip. Start only project-owned
 processes when needed, inspect `/info`, and run
-`npx --prefer-offline --yes copilotkit@4.15.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
-Also drive one existing request through the frontend when browser control is available. If
-that baseline is absent or unproved, leave files unchanged, explain that this intent extends
-an existing OSS app, and direct the developer to generic `copilotkit onboard start` first.
+`npx --prefer-offline --yes copilotkit@4.17.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
+Also drive one existing request through the frontend 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.15.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
@@ -40,7 +38,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -64,7 +62,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.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
@@ -74,7 +72,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.15.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.15.0 onboard read feature/a2ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/a2ui/implement`.

package/onboarding/prompts/feature/blocked-by-plan.md

@@ -20,13 +20,13 @@ Tell the developer, in two or three sentences:
 3. The one action that can change it: check the organization's plan and billing state at
    https://cloud.copilotkit.ai, or reply to support with the organization name.
 
+If this run changed files before it stopped, list every path it changed and say whether it
+reverted them. A refusal that arrives after the first edit still owes the developer that
+list.
+
 Then stop. Report nothing else and ask no follow-up question.
 
 Do not run `onboard complete`. This run did not complete.
 
 Do not file a friction report for this ending. Reading this prompt already reports it, and a
 free-text report of a refusal the platform already named adds nothing.
-
-If this run changed files before it stopped, list every path it changed and say whether it
-reverted them. A refusal that arrives after the first edit still owes the developer that
-list.

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

@@ -19,7 +19,7 @@ On Teams, skip Slack-only tools and the Slack e2e harness. Do not add a CopilotK
 web app to make this run look complete. Do not replace the existing agent.
 
 If repository evidence does not prove an existing valid Intelligence selection, sign in
-yourself with `npx --prefer-offline --yes copilotkit@4.15.0 login --json`: the same single streaming
+yourself with `npx --prefer-offline --yes copilotkit@4.17.0 login --json`: the same single streaming
 session generic onboarding uses. Read its JSON Lines while the process runs. Open the
 first `authentication_url` exactly once with the operating system's default browser
 opener, `open` on macOS, `xdg-open` on Linux, `Start-Process` in Windows PowerShell. Your
@@ -75,10 +75,41 @@ writes it, the starters this graph clones are built on it, and its own tooltip
 names no replacement. Write what the framework node names. Do not rewrite a cloned
 starter to satisfy this rule, and do not report the page that shows it.
 
+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.15.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
@@ -89,23 +120,20 @@ 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.15.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.15.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.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 ## Values this run writes, and the one credential the developer supplies
@@ -141,11 +169,11 @@ variable while every recorded one keeps its value, and run the audit again.
 When implementation validation passes, report it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.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 run 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.15.0 onboard read feature/channels/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/channels/proof`.

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

@@ -20,26 +20,46 @@ defects and repeat.
 If a gate cannot run, do not complete this run. Name the gate. Use the feature stop
 route after the audit rules below.
 
+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.15.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.15.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.15.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 a proved mention reply, `failed` for an attempted proof that
-failed, and `skipped` when the proof did not run. Then run `npx --prefer-offline --yes copilotkit@4.15.0 onboard audit`.
+failed, and `skipped` when the proof did 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
@@ -47,19 +67,18 @@ 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.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
-When the audit passes and the mention proof passed, record it first with
-`onboard proof --step round-trip --outcome passed` as above. Then run
-`npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/complete` and complete with
+When the audit passes and the round trip you reported above was `passed`, run
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/complete` and complete with
 `--visual-check channels-proof-passed`. The recorded mention and reply are this run's
 proof, so no web app check is missing. Use `--visual-check performed` only when a
 browser drove Slack or Teams web and proved the mention reply. Do not use

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

@@ -3,11 +3,13 @@
 First, report your coding agent identity using the same command as generic onboarding:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard identify --coding-agent <coding-agent-slug>
+npx --prefer-offline --yes copilotkit@4.17.0 onboard identify --coding-agent <coding-agent-slug> --model <model-id>
 ```
 
-Use your own product's slug, such as `codex` or `claude-code`. This also covers entry
-commands that omit `--coding-agent`. It needs no login, browser, or project setup.
+Use your own product's slug, such as `codex` or `claude-code`. For `--model`, give the
+exact model id your instructions name. If they name none, leave out `--model` rather than
+guess. This also covers entry commands that omit `--coding-agent`. It needs no login,
+browser, or project setup.
 
 Treat Slack or Teams as the UI for this run. A CopilotKit web app is not required.
 Empty folders, agent-only folders, and existing CopilotKit apps are all valid starts.
@@ -17,7 +19,7 @@ restricted to the target project.
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.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. Do not
@@ -47,7 +49,7 @@ This one does not.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.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
@@ -64,7 +66,7 @@ and its install command in the message the developer sees: `nvm install 22` for
 for Python. Offer a custom headless build as a later path. Then route out:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/stop
 ```
 
 Do not run login, select Intelligence, or create a credential until the developer
@@ -94,7 +96,7 @@ one.
 After approval, record each approved path before implementation:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.15.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
@@ -104,7 +106,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.15.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.15.0 onboard read feature/channels/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/channels/implement`.

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

@@ -12,10 +12,41 @@ standalone mock UI.
 
 Run focused type/test checks and start the app. Record the changed files and validation.
 
+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.15.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
@@ -26,33 +57,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.15.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.15.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.15.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.15.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.15.0 onboard read feature/chat-suggestions/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/chat-suggestions/proof`.

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

@@ -9,26 +9,46 @@ Do not count a static DOM assertion, a hook return value, or a locally rendered
 proof. If the changed files caused a failure, repair it and repeat the interaction. Keep
 project-owned services 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.15.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.15.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.15.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 a proved sent suggestion, `failed` for an attempted proof that failed,
-and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.15.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
@@ -36,16 +56,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.15.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.15.0 onboard read feature/complete` with the real browser-proof
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/complete` with the real browser-proof
 outcome.