copilotkit 4.9.60 → 4.10.0

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

@@ -4,6 +4,16 @@ Treat this as an additive OSS feature integration, not a new-app scaffold. Act a
 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.
 
+Before any subagent or project process runs, capture the developer's existing work:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+approved authorization before implementation.
+
 Before changing files, send a short welcome that says you will inspect the existing app,
 show an A2UI plan, implement only after approval, and prove a rendered surface in the real
 UI. Then spawn one read-only subagent to locate the current CopilotKit runtime, provider,
@@ -12,7 +22,7 @@ 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 --yes copilotkit@4.9.60 verify --expect-runtime oss --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.10.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.
@@ -20,7 +30,7 @@ an existing OSS app, and direct the developer to generic `copilotkit onboard sta
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -30,7 +40,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.0 onboard read feature/stop
 ```
 
 Do not run `login`, select an Intelligence project, add an Intelligence client, mint a
@@ -46,10 +56,23 @@ Show a concise plan that names the existing runtime/provider files, the smallest
 catalog or runtime wiring required, the test command, and a browser proof request that
 renders a compact visible surface. Ask for plan approval as its own question.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/a2ui/implement`.
+Then run `npx --yes copilotkit@4.10.0 onboard read feature/a2ui/implement`.

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

@@ -11,18 +11,48 @@ available context and retain a safe empty state. Do not add Intelligence, creden
 standalone mock UI.
 
 Run focused type/test checks and start the app. Record the changed files and validation.
-When implementation validation passes, report it:
+
+After validation and each repair, run:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.0 onboard audit
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
-without further changes:
+Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+not a finding. Carry it into the final summary with its reason.
+
+If the audit fails, never repair, reset, or revert a protected path. Compare each named path
+with the implementation subagent's `Files changed` section. If that section does not name
+the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.10.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+```
+
+Run the audit again after each accepted or authorized change. If it still fails, or starts
+with `Status: blocked`, route out and stop:
+
+```text
+npx --yes copilotkit@4.10.0 onboard read feature/stop
+```
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.9.60 onboard read feature/chat-suggestions/proof`.
+`npx --yes copilotkit@4.10.0 onboard read feature/chat-suggestions/proof`.

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

@@ -12,15 +12,40 @@ project-owned services running.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
-Run
-`npx --yes copilotkit@4.9.60 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
-with the real browser-proof outcome.
+After the final attempt, report the gate exactly once:
+
+```text
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.10.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
+with the proof subagent's `Files changed` section. If that section does not name the path,
+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.
+
+If the audit still fails, or starts with `Status: blocked`, route out and stop:
+
+```text
+npx --yes copilotkit@4.10.0 onboard read feature/stop
+```
+
+When the audit passes, run
+`npx --yes copilotkit@4.10.0 onboard read feature/complete` with the real browser-proof
+outcome.

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

@@ -3,9 +3,19 @@
 Treat this as an additive OSS chat-surface feature. Delegate repository inspection,
 implementation, and proof to separate subagents and keep all work inside the target project.
 
+Before any subagent or project process runs, capture the developer's existing work:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+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 --yes copilotkit@4.9.60 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`/info`, `npx --yes copilotkit@4.10.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.
@@ -13,7 +23,7 @@ onboarding first.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -23,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.0 onboard read feature/stop
 ```
 
 Do not run login, provision Intelligence, request a credential, replace the agent, or alter
@@ -37,10 +47,23 @@ first-message experience, or offer dynamic suggestions when the developer needs
 context-dependent follow-ups. Show an approved-plan-sized diff, a focused test, and a proof
 that a visible suggestion submits the intended message.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/chat-suggestions/implement`.
+Then run `npx --yes copilotkit@4.10.0 onboard read feature/chat-suggestions/implement`.

package/onboarding/prompts/feature/complete.md

@@ -0,0 +1,11 @@
+# Complete the feature run
+
+Use the outcome the proof step observed. Run:
+
+```text
+npx --yes copilotkit@4.10.0 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>
+```
+
+Use `performed` only when browser control drove the real user-visible surface. Use
+`skipped-no-browser-tool` only when no browser tool was available. Use `failed` when the
+browser proof ran but did not prove the feature.

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

@@ -10,7 +10,7 @@ After the project is selected, settle the container from the terminal.
 When the plan or the repository already names an id, ask about that one id and nothing else:
 
 ```text
-npx --yes copilotkit@4.9.60 learning containers get <id> --json
+npx --yes copilotkit@4.10.0 learning containers get <id> --json
 ```
 
 One call answers it, and no list is needed.
@@ -18,7 +18,7 @@ One call answers it, and no list is needed.
 When no id is in hand, survey what the project holds:
 
 ```text
-npx --yes copilotkit@4.9.60 learning containers list --json
+npx --yes copilotkit@4.10.0 learning containers list --json
 ```
 
 One call returns at most 500 containers. When `nextCursor` in the result is not null, read
@@ -29,7 +29,7 @@ second container for work the first one already covers.
 Report what the read found before asking anyone anything:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase container-surveyed
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase container-surveyed
 ```
 
 Everything after this waits on a person, so a run that stops past this point stopped on a
@@ -50,7 +50,7 @@ user, so the callback can return a different id per tier or per customer.
 Use a descriptive lowercase hyphenated id of 1-64 characters:
 
 ```text
-npx --yes copilotkit@4.9.60 learning containers create --id <id> --name <name> --json
+npx --yes copilotkit@4.10.0 learning containers create --id <id> --name <name> --json
 ```
 
 An id already in use answers `LEARNING_CONTAINER_ALREADY_EXISTS`. That is a container to
@@ -65,7 +65,7 @@ or a guessed id.
 Then report that the container is settled, before any edit:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase container-settled
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase container-settled
 ```
 
 Everything above happens between two prompts, so a run that stopped on a developer who could
@@ -86,21 +86,50 @@ 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 --yes copilotkit@4.9.60 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
+`npx --yes copilotkit@4.10.0 verify --expect-runtime intelligence --round-trip --agent <agent-id> --json`.
 Repair changed-file failures and record secret-safe evidence.
 
-When implementation validation passes, report it:
+After validation and each repair, run:
+
+```text
+npx --yes copilotkit@4.10.0 onboard audit
+```
+
+Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+not a finding. Carry it into the final summary with its reason.
+
+If the audit fails, never repair, reset, or revert a protected path. Compare each named path
+with the implementation subagent's `Files changed` section. If that section does not name
+the path, accept the developer's external change:
+
+```text
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.10.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
+```
+
+Run the audit again after each accepted or authorized change. If it still fails, or starts
+with `Status: blocked`, route out and stop:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.0 onboard read feature/stop
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
-without further changes:
+When implementation validation passes, report it:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.9.60 onboard read feature/learning/proof`.
+`npx --yes copilotkit@4.10.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 --yes copilotkit@4.9.60 verify --expect-runtime intelligence --round-trip --agent <agent-id> --expect-learning-container <id> --json
+npx --yes copilotkit@4.10.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
@@ -31,15 +31,41 @@ takes its container before its first agent run. So the container starts empty on
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
-Run
-`npx --yes copilotkit@4.9.60 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
-with the actual surface outcome.
+After the final attempt, report the gate exactly once:
+
+```text
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.10.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
+with the proof subagent's `Files changed` section. If that section does not name the path,
+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.
+
+If the audit still fails, or starts with `Status: blocked`, route out and stop:
+
+```text
+npx --yes copilotkit@4.10.0 onboard read feature/stop
+```
+
+When the audit passes, run
+`npx --yes copilotkit@4.10.0 onboard read feature/complete` with the actual surface
+outcome.

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

@@ -4,6 +4,16 @@ Treat Learning as a managed Intelligence feature that assigns real threads to a
 Learning Container. Orchestrate with separate read-only, implementation, and proof
 subagents. Work only inside the target project and preserve its existing agent and chat.
 
+Before any subagent or project process runs, capture the developer's existing work:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+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
@@ -13,7 +23,7 @@ onboarding.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -23,7 +33,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.0 onboard read feature/stop
 ```
 
 Fetch the current official guides before planning:
@@ -47,10 +57,23 @@ Show a concise plan for managed runtime/thread prerequisites, a stable selected
 the documented `getLearningContainerId` selector, validation, and a visible assignment
 proof. Ask for approval separately.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/learning/implement`.
+Then run `npx --yes copilotkit@4.10.0 onboard read feature/learning/implement`.

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

@@ -11,18 +11,49 @@ intact unless the official guide and observed failure require a minimal document
 
 Run the project's focused validation commands. Start the app and confirm `/info` reports
 `openGenerativeUIEnabled`, while treating that only as capability evidence. Record changed paths and
-validation results without secrets. When implementation validation passes, report it:
+validation results without secrets.
+
+After validation and each repair, run:
+
+```text
+npx --yes copilotkit@4.10.0 onboard audit
+```
+
+Continue only when it starts with `Status: passed`. A path under `Authorized to change:` is
+not a finding. Carry it into the final summary with its reason.
+
+If the audit fails, never repair, reset, or revert a protected path. Compare each named path
+with the implementation subagent's `Files changed` section. If that section does not name
+the path, accept the developer's external change:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.0 onboard protect --accept-external --path <path>
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
-without further changes:
+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 --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
+Run the audit again after each accepted or authorized change. If it still fails, or starts
+with `Status: blocked`, route out and stop:
+
+```text
+npx --yes copilotkit@4.10.0 onboard read feature/stop
+```
+
+When implementation validation passes, report it:
+
+```text
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.9.60 onboard read feature/open-generative-ui/proof`.
+`npx --yes copilotkit@4.10.0 onboard read feature/open-generative-ui/proof`.

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

@@ -13,15 +13,40 @@ the missing visual proof honestly.
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase journey-attempted --attempt 1
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase journey-attempted --attempt 1
 ```
 
 Report each repair cycle the same way, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase repair-attempted --attempt 1
 ```
 
-Then run
-`npx --yes copilotkit@4.9.60 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
-with the outcome actually observed.
+After the final attempt, report the gate exactly once:
+
+```text
+npx --yes copilotkit@4.10.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 --yes copilotkit@4.10.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
+with the proof subagent's `Files changed` section. If that section does not name the path,
+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.
+
+If the audit still fails, or starts with `Status: blocked`, route out and stop:
+
+```text
+npx --yes copilotkit@4.10.0 onboard read feature/stop
+```
+
+When the audit passes, run
+`npx --yes copilotkit@4.10.0 onboard read feature/complete` with the outcome actually
+observed.

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

@@ -3,10 +3,20 @@
 Treat this as a focused OSS enhancement. Orchestrate the work with separate read-only,
 implementation, and proof subagents, all restricted to the target project directory.
 
+Before any subagent or project process runs, capture the developer's existing work:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect
+```
+
+Keep the exact protected path list it prints and give that list to every subagent. No
+subagent may write a protected path or an overlapping path unless this run records the
+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 --yes copilotkit@4.9.60 verify --expect-runtime oss --round-trip --agent <agent-id> --json`,
+`npx --yes copilotkit@4.10.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.
@@ -14,7 +24,7 @@ generic onboarding path first.
 Wait for the inspection subagent to finish. Then report that the inspection came back:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase research-returned
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase research-returned
 ```
 
 A refused checkpoint prints its reason and leaves onboarding unaffected. It is not a
@@ -24,7 +34,7 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard read feature/stop
+npx --yes copilotkit@4.10.0 onboard read feature/stop
 ```
 
 Do not sign in, select an Intelligence project, create credentials, change the existing
@@ -38,10 +48,23 @@ Retry through a second retrieval method if needed. Setup is the documented
 Show a small plan covering that runtime option, the existing provider's renderer path,
 likely CSP/sandbox implications, tests, and a user-visible generated UI proof. Ask for approval separately.
 
-After approval, report the plan this run is about to implement:
+The plan must list every protected path it needs to change under `Authorization requested`,
+with one sentence explaining why. Write `None` when it needs none.
+
+After approval, record each approved path before implementation:
+
+```text
+npx --yes copilotkit@4.10.0 onboard protect --authorize --path <path> --reason "<the plan's sentence>"
+```
+
+If an approved path changed after capture and no implementation step has run, add
+`--with-prior-change`. Continue only when every result starts with `Status: passed`. Do not
+authorize a path the approved plan did not list.
+
+Then report the plan this run is about to implement:
 
 ```text
-npx --yes copilotkit@4.9.60 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.60 onboard read feature/open-generative-ui/implement`.
+Then run `npx --yes copilotkit@4.10.0 onboard read feature/open-generative-ui/implement`.