copilotkit 4.16.0 → 4.17.0

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

@@ -6,7 +6,7 @@ implementation, and proof to separate subagents and keep all work inside the tar
 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
@@ -15,15 +15,13 @@ approved authorization before implementation.
 
 Before edits, identify the current CopilotKit provider, chat component, message lifecycle,
 agent id, package version, and test/dev commands. Prove the existing OSS round trip with
-`/info`, `npx --prefer-offline --yes copilotkit@4.16.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
-and one real frontend request when browser control is available. If there is no proven
-existing CopilotKit chat, leave files unchanged and direct the developer to generic
-onboarding first.
+`/info`, `npx --prefer-offline --yes copilotkit@4.17.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+and one real frontend request when browser control is available.
 
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.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,7 +31,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.17.0 onboard read feature/stop
 ```
 
 Do not run login, provision Intelligence, request a credential, replace the agent, or alter
@@ -55,7 +53,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
@@ -65,7 +63,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/chat-suggestions/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/chat-suggestions/implement`.

package/onboarding/prompts/feature/complete.md

@@ -3,7 +3,7 @@
 Use the outcome the proof step observed. Run:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard complete --visual-check <performed|skipped-no-browser-tool|channels-proof-passed|failed>
+npx --prefer-offline --yes copilotkit@4.17.0 onboard complete --visual-check <performed|skipped-no-browser-tool|channels-proof-passed|failed>
 ```
 
 Use `channels-proof-passed` for a Slack or Teams run that recorded a passed round-trip proof
@@ -20,7 +20,7 @@ Before `onboard complete`, send the friction this run mentioned to the developer
 report each, at most four, costliest first:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.17.0 onboard friction --category <slug> --cost-seconds <seconds> --message "<sentences>"
 ```
 
 Put one or two sentences in `--message`, with no secrets, source, or logs. Pick the

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

@@ -7,16 +7,17 @@ require the secret-safe project/key provisioning summary before wiring the runti
 
 ## If you stop in this phase
 
-Four rules below end this run without completing it: an entitlement the platform will not
-resolve, a container id that never resolves, an audit that stays blocked, and validation
-that cannot pass. Each one stops onboarding for a developer who has already approved a
+Five rules below end this run without completing it: an entitlement the platform will not
+resolve, a container id that never resolves, an audit that still fails or is blocked or
+cannot be cleared, validation that cannot pass, and an intent that needs a prerequisite the
+app does not have. Each one stops onboarding for a developer who has already approved a
 plan. Name the exact command, id, and error code that stopped you: a report that names only
 the step cannot be acted on. Send one short report before you stop. Run the friction
 command without another developer question. Do not 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.
@@ -29,7 +30,9 @@ those, prints the reason, and exits zero. A refused report is not a failed step.
 report, then stop.
 
 A refusal by the platform is the one exception. It reaches `feature/blocked-by-plan`, which
-reports the ending by itself and says to file nothing further.
+reports the ending by itself and says to file nothing further. A stop that routes to
+`feature/stop` also sends no report here: that prompt first asks the developer about one
+scoped fix, and sends the report itself when no fix is approved.
 
 After the project is selected, settle the container from the terminal.
 
@@ -41,7 +44,7 @@ settled refusal rather than a missing baseline, so stop here, before any file ch
 take its own ending:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/blocked-by-plan
 ```
 
 `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -55,7 +58,7 @@ then, so the read below is where its refusal surfaces.
 When the plan or the repository already names an id, ask about that one id and nothing else:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 learning containers get <id> --json
+npx --prefer-offline --yes copilotkit@4.17.0 learning containers get <id> --json
 ```
 
 One call answers it, and no list is needed.
@@ -63,7 +66,7 @@ One call answers it, and no list is needed.
 When no id is in hand, survey what the project holds:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 learning containers list --json
+npx --prefer-offline --yes copilotkit@4.17.0 learning containers list --json
 ```
 
 One call returns at most 500 containers. When `nextCursor` in the result is not null, read
@@ -74,7 +77,7 @@ second container for work the first one already covers.
 Report what the read found before asking anyone anything:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase container-surveyed
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase container-surveyed
 ```
 
 Everything after this waits on a person, so a run that stops past this point stopped on a
@@ -95,7 +98,7 @@ user, so the callback can return a different id per tier or per customer.
 Ask the CLI for the id rather than spelling one yourself:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 learning containers default-id --json
+npx --prefer-offline --yes copilotkit@4.17.0 learning containers default-id --json
 ```
 
 It derives the project-scoped id from the selected project's slug, reads the local project
@@ -109,7 +112,7 @@ run that spells the id differently gives one project two containers, each below
 above on its own. One command is what keeps the two spellings identical.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 learning containers create --id <id> --name <name> --json
+npx --prefer-offline --yes copilotkit@4.17.0 learning containers create --id <id> --name <name> --json
 ```
 
 An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
@@ -124,7 +127,7 @@ or a guessed id.
 Then report that the container is settled, before any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard checkpoint --phase container-settled
+npx --prefer-offline --yes copilotkit@4.17.0 onboard checkpoint --phase container-settled
 ```
 
 Everything above happens between two prompts, so a run that stopped on a developer who could
@@ -145,13 +148,44 @@ 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 secret-safe 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
@@ -162,33 +196,31 @@ 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
-with `Status: blocked`, route out and stop:
+Run the audit again after each accepted change. If it still fails, or starts
+with `Status: blocked`, route out and stop. Route out the same way when
+`--accept-credential` refuses because it names a lost variable:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.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/learning/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/learning/proof`.

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

@@ -7,7 +7,7 @@ Container. Confirm the thread remains associated with the expected user.
 One command decides it:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --prefer-offline --yes copilotkit@4.17.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
 ```
 
 It reads the thread back from the platform, so it answers for any runtime mount, and it
@@ -29,27 +29,47 @@ counts. Existing threads can join this container if they never belonged to anoth
 Their surviving earlier history then becomes eligible for collection and counts toward the
 same threshold. Existing threads do not join automatically just because a container exists.
 
+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 a proved Container assignment, `failed` for an attempted proof that
 failed, and `skipped` when the proof could not run. Then run
-`npx --prefer-offline --yes copilotkit@4.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
@@ -57,16 +77,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 surface
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/complete` with the actual surface
 outcome.

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

@@ -11,7 +11,7 @@ friction command without another developer question. Do not ask the developer ab
 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.
@@ -22,6 +22,11 @@ the whole run, so the estimate is optional on a stop report and only there. Send
 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 refusal by the platform is the one exception. It reaches `feature/blocked-by-plan`, which
+reports the ending by itself and says to file nothing further. A stop that routes to
+`feature/stop` also sends no report here: that prompt first asks the developer about one
+scoped fix, and sends the report itself when no fix is approved.
+
 Ask the platform whether this organization may use Learning before doing any work. The
 read carries the same availability gate as the create, so it answers the entitlement
 question in one call and writes nothing:
@@ -38,7 +43,7 @@ status:
   before the capture, the inspection, and any edit:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.16.0 onboard read feature/blocked-by-plan
+npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/blocked-by-plan
 ```
 
 - `LEARNING_AVAILABILITY_UNAVAILABLE` means the platform did not resolve the answer. It is
@@ -59,7 +64,7 @@ again: it has no answer, so it carries the question forward rather than ending o
 Before any subagent or project process runs, capture the developer's existing work:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.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
@@ -68,14 +73,12 @@ approved authorization before implementation.
 
 Before edits, inspect the runtime, agent id, provider/chat, server-side user identity,
 existing Intelligence configuration (presence only), existing thread routes, and the normal
-test/dev commands. Prove the current round trip and inspect `/info`. If the project does not
-already have a CopilotKit app, leave it unchanged and direct the developer to generic
-onboarding.
+test/dev commands. Prove the current round trip and inspect `/info`.
 
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.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
@@ -85,13 +88,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/learning.md
 https://docs.copilotkit.ai/backend/copilot-runtime.md
-https://docs.copilotkit.ai/intelligence/connect-your-runtime.md
+https://docs.copilotkit.ai/intelligence/quickstart.md
 https://docs.copilotkit.ai/threads.md
 Use a second retrieval method if needed.
 
@@ -117,7 +120,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
@@ -127,7 +130,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/learning/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/learning/implement`.

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

@@ -1,7 +1,7 @@
 # Implement Open Generative UI with the existing chat surface
 
 Delegate implementation to one subagent with the approved plan and the fetched official
-guide. Add only the documented Open Generative UI runtime middleware and any documented
+guide. Enable only the documented `openGenerativeUI` runtime option and any documented
 provider wiring the current package versions require. Preserve the existing agent, runtime
 route, persistence, chat surface, and model setup.
 
@@ -13,10 +13,41 @@ Run the project's focused validation commands. Start the app and confirm `/info`
 `openGenerativeUIEnabled`, while treating that only as capability evidence. Record changed paths and
 validation results without 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.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
@@ -27,33 +58,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/open-generative-ui/proof`.
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/open-generative-ui/proof`.

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

@@ -10,26 +10,46 @@ project-owned services running. Repair a failure caused by changed files and pro
 do not replace the output with a hard-coded component. If browser control is absent, report
 the missing visual proof honestly.
 
+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 a proved generated UI, `failed` for an attempted proof that failed,
-and `skipped` when the proof could not run. Then run `npx --prefer-offline --yes copilotkit@4.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
@@ -37,16 +57,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 outcome actually
+`npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/complete` with the outcome actually
 observed.

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

@@ -6,7 +6,7 @@ implementation, and proof subagents, all restricted to the target project direct
 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
@@ -16,15 +16,13 @@ approved authorization before implementation.
 Before edits, have a research subagent identify the current CopilotKit runtime route,
 provider/chat component, agent id, package versions, existing middleware, sandbox/CSP
 constraints, and normal test/dev commands. Prove the existing app first with `/info`,
-`npx --prefer-offline --yes copilotkit@4.16.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
-and a real frontend request when browser control is available. If the app is not an existing
-OSS CopilotKit app with a proven round trip, change nothing and direct the developer to the
-generic onboarding path first.
+`npx --prefer-offline --yes copilotkit@4.17.0 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+and a real frontend request when browser control is available.
 
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.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
@@ -34,7 +32,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.17.0 onboard read feature/stop
 ```
 
 Do not sign in, select an Intelligence project, create credentials, change the existing
@@ -56,7 +54,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
@@ -66,7 +64,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/open-generative-ui/implement`.
+Then run `npx --prefer-offline --yes copilotkit@4.17.0 onboard read feature/open-generative-ui/implement`.