copilotkit 4.16.0 → 4.18.0

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

@@ -1,13 +1,57 @@
 # Add A2UI to the existing CopilotKit app
 
 Treat this as an additive OSS feature integration, not a new-app scaffold. Act as the
-orchestrator and delegate inspection, implementation, and proof to focused subagents.
-Work only inside the target project. Do not show internal prompt names to the developer.
+orchestrator and delegate inspection, implementation, and proof to focused subagents. Work
+only inside the target project. Prompt names are this graph's own bookkeeping. Say what the
+run is doing in the developer's words instead.
+
+## Waits, stops, and subagents
+
+A run that starts here has not read these rules yet, so they come first. They cover this
+prompt and every later one.
+
+Spawning a subagent returns almost at once. That return is the dispatch succeeding, not the
+work finishing: the result reaches you as a notification, or with the dispatch itself where
+your harness works that way. Do the work that does not depend on the result, then end your
+turn and wait for the result. That wait is a pause. Do not sleep or poll.
+
+A subagent that returns no usable result failed in your harness, not in this graph. Every
+assignment here is work you can do yourself, slower, so run that assignment yourself and
+carry on. Keep a read-only assignment read-only. If no subagent works at all, report it
+once:
+
+```text
+npx --prefer-offline --yes copilotkit@4.18.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
+```
+
+A turn that ends while the run waits is a pause, not a stop, even when your harness ends it.
+When the answer or the result arrives, continue from the step that paused.
+
+If you stop this run, send one short report before you stop. The friction command follows
+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>"
+```
+
+`--message` takes one or two sentences: the step you stopped at and what stopped it.
+Pick the category that fits from docs-missing, docs-wrong, docs-sequential, cli-gap,
+sdk-gap, environment, port-collision, credential, validation-loop, and other. Leave
+--cost-seconds off. Send no secrets, source code, logs, or command output. A refused report
+is not a failed step: reword it and send it again, or stop without a report. A stop that
+routes to `feature/stop` sends no report here: that prompt first asks the developer about
+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.16.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.18.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. No
@@ -22,15 +66,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.16.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.18.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.16.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -40,7 +82,7 @@ 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.18.0 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -64,7 +106,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.18.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 +116,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.18.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/a2ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.18.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.16.0 login --json`: the same single streaming
+yourself with `npx --prefer-offline --yes copilotkit@4.18.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.18.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.18.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.18.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.16.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.18.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.18.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.16.0 onboard checkpoint --phase build-validated
+npx --prefer-offline --yes copilotkit@4.18.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.16.0 onboard read feature/channels/proof`.
+`npx --prefer-offline --yes copilotkit@4.18.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.18.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.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.16.0 onboard checkpoint --phase repair-attempted --attempt 1
+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.16.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.18.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.16.0 onboard audit`.
+failed, and `skipped` when the proof did not run. Then run `npx --prefer-offline --yes copilotkit@4.18.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.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.18.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.16.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.18.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,21 +3,66 @@
 First, report your coding agent identity using the same command as generic onboarding:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard identify --coding-agent <coding-agent-slug>
+npx --prefer-offline --yes copilotkit@4.18.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.
 Orchestrate with separate read-only, implementation, and proof subagents, each
 restricted to the target project.
 
+## Waits, stops, and subagents
+
+A run that starts here has not read these rules yet, so they come first. They cover this
+prompt and every later one.
+
+Spawning a subagent returns almost at once. That return is the dispatch succeeding, not the
+work finishing: the result reaches you as a notification, or with the dispatch itself where
+your harness works that way. Do the work that does not depend on the result, then end your
+turn and wait for the result. That wait is a pause. Do not sleep or poll.
+
+A subagent that returns no usable result failed in your harness, not in this graph. Every
+assignment here is work you can do yourself, slower, so run that assignment yourself and
+carry on. Keep a read-only assignment read-only. If no subagent works at all, report it
+once:
+
+```text
+npx --prefer-offline --yes copilotkit@4.18.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
+```
+
+A turn that ends while the run waits is a pause, not a stop, even when your harness ends it.
+When the answer or the result arrives, continue from the step that paused.
+
+If you stop this run, send one short report before you stop. The friction command follows
+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>"
+```
+
+`--message` takes one or two sentences: the step you stopped at and what stopped it.
+Pick the category that fits from docs-missing, docs-wrong, docs-sequential, cli-gap,
+sdk-gap, environment, port-collision, credential, validation-loop, and other. Leave
+--cost-seconds off. Send no secrets, source code, logs, or command output. A refused report
+is not a failed step: reword it and send it again, or stop without a report. A stop that
+routes to `feature/stop` sends no report here: that prompt first asks the developer about
+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.16.0 onboard protect
+npx --prefer-offline --yes copilotkit@4.18.0 onboard protect
 ```
 
 Keep the exact protected path list it prints and give that list to every subagent. Do not
@@ -47,7 +92,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.16.0 onboard checkpoint --phase research-returned
+npx --prefer-offline --yes copilotkit@4.18.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -64,7 +109,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.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/stop
 ```
 
 Do not run login, select Intelligence, or create a credential until the developer
@@ -94,7 +139,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.18.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 +149,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.18.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/channels/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.18.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.18.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.18.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.18.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.16.0 onboard protect --accept-external --path <path>
+npx --prefer-offline --yes copilotkit@4.18.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.18.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.18.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/chat-suggestions/proof`.
+`npx --prefer-offline --yes copilotkit@4.18.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.18.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.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.16.0 onboard checkpoint --phase repair-attempted --attempt 1
+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.16.0 onboard proof --step round-trip --outcome <passed|failed|skipped>
+npx --prefer-offline --yes copilotkit@4.18.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.16.0 onboard audit`.
+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 `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.16.0 onboard read feature/stop
+npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/stop
 ```
 
 When the audit passes, run
-`npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/complete` with the real browser-proof
+`npx --prefer-offline --yes copilotkit@4.18.0 onboard read feature/complete` with the real browser-proof
 outcome.