copilotkit 4.9.50 → 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.50 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.50 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.50 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.50 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 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.50 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.50 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

@@ -5,10 +5,72 @@ valid existing Intelligence selection. If it is absent, use the documented strea
 `login --json` session, let the developer select or create the Intelligence project, and
 require the secret-safe project/key provisioning summary before wiring the runtime.
 
-After the project is selected, ask the developer to create or select a stable Learning
-Container in the selected project's dashboard and provide its non-secret id. This is a real
-human gate: stop if they cannot provide it. Do not write a placeholder, a guessed id, or a
-new unsupported CLI command.
+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.10.0 learning containers get <id> --json
+```
+
+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.10.0 learning containers list --json
+```
+
+One call returns at most 500 containers. When `nextCursor` in the result is not null, read
+the next page with `--cursor <nextCursor>` and keep going until it is null. A project whose
+container sits on the second page looks empty to a single call, and the run then adds a
+second container for work the first one already covers.
+
+Report what the read found before asking anyone anything:
+
+```text
+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
+decision rather than on a read.
+
+Reuse an existing container when one covers the workflow this run is instrumenting, and ask
+the developer which one when more than one could. Otherwise create one.
+
+Default to one container for this project, and name it after the project. Learning needs
+evidence to work with: the first automatic run wants threads from 15 distinct conversations
+in one container, so splitting a new project across several leaves every one of them below
+the line. One container per end user is the same trap and a harder one, because a project
+holds at most 500 and each user's own container then needs 15 conversations from that one
+person. Route per user only when the developer asks for it, and do it in their selector
+rather than in more containers: `getLearningContainerId` receives the resolved application
+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.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
+read with `get` and reuse, not a failure to repair and not a reason to pick a new id.
+
+Confirm the id resolves before any file changes, whichever way it was settled. That check is
+the cheap one to keep: a selector wired to an id the platform does not hold returns
+`LEARNING_CONTAINER_NOT_FOUND` on every thread create and every run lock, so a working chat
+breaks on the next message. Stop here if the id does not resolve. Do not write a placeholder
+or a guessed id.
+
+Then report that the container is settled, before any edit:
+
+```text
+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
+not choose, on a taken id, or on an id that never resolved would otherwise report the plan
+and then nothing at all.
 
 Add only the documented managed runtime/thread prerequisites and the selected
 `getLearningContainerId` on the `CopilotKitIntelligence` instance. Return the same stable
@@ -24,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.50 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.9.50 onboard checkpoint --phase build-validated
+npx --yes copilotkit@4.10.0 onboard protect --authorize --unplanned --path <path> --reason "<what the developer said>"
 ```
 
-If validation cannot pass, or this intent needs a prerequisite the app does not have, stop
-without further changes:
+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.50 onboard read feature/stop
+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.50 onboard read feature/learning/proof`.
+`npx --yes copilotkit@4.10.0 onboard read feature/learning/proof`.

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

@@ -1,27 +1,71 @@
 # Prove a real run is assigned to the selected Learning Container
 
 Delegate proof to a fresh subagent. In the real authenticated app, create or use a thread,
-send a normal agent request, and confirm the resulting run is assigned to the selected
-Learning Container through the documented Intelligence/Inspector evidence. Confirm the
-thread remains associated with the expected user and that the managed round-trip check still
-passes.
+send a normal agent request, and confirm the resulting run reached the selected Learning
+Container. Confirm the thread remains associated with the expected user.
+
+One command decides it:
+
+```text
+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
+passes only when that thread carries the container this run selected.
+
+Two other signals look like proof and are not. `features.self_learning` is a plan
+entitlement and is already true before any wiring. The `/info` response reports Learning
+from the presence of a callback, not from a single assigned thread. Never report either one
+as evidence.
 
 Do not claim that Insights or Skills are already available: those depend on completed runs
 and later learning processing. Record only the assignment visible now, the request, app URL,
 process IDs, and safe stop commands. Repair changed-file defects and repeat.
 
+Tell the developer what happens next, because a correct run looks like a broken one
+otherwise. Learning runs on its own: the first automatic run needs new threads from 15
+distinct conversations in this container, and only the newest snapshot of each thread
+counts. Threads that already ran before this change are never pulled in, because a thread
+takes its container before its first agent run. So the container starts empty on purpose.
+
 Report each attempt at the proof as it ends, counting from one:
 
 ```text
-npx --yes copilotkit@4.9.50 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.50 onboard checkpoint --phase repair-attempted --attempt 1
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase repair-attempted --attempt 1
+```
+
+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
 ```
 
-Run
-`npx --yes copilotkit@4.9.50 onboard complete --visual-check <performed|skipped-no-browser-tool|failed>`
-with the actual surface outcome.
+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.50 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,16 +33,20 @@ If the inspection did not prove the baseline this intent extends, stop here with
 changing files:
 
 ```text
-npx --yes copilotkit@4.9.50 onboard read feature/stop
+npx --yes copilotkit@4.10.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/threads.md
-Use a second retrieval method if needed. The CLI has no supported command to create or list
-Learning Containers. Do not invent an id, scrape a dashboard, or treat an arbitrary string
-as one.
+Use a second retrieval method if needed.
+
+The CLI owns the container. `copilotkit learning containers list --json` reads the ones this
+project already has, and `copilotkit learning containers create --id <id> --name <name>
+--json` makes one. So there is no dashboard step and no reason to guess: never invent an id,
+scrape a dashboard, or treat an arbitrary string as a container.
 
 Read the "Assign Threads to Learning Containers" section of that page. The container is
 chosen by `getLearningContainerId` on the `CopilotKitIntelligence` instance, which the
@@ -43,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.50 onboard checkpoint --phase plan-written
+npx --yes copilotkit@4.10.0 onboard checkpoint --phase plan-written
 ```
 
-Then run `npx --yes copilotkit@4.9.50 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.50 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.50 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.50 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.50 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.50 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.50 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.