copilotkit 4.9.4 → 4.9.17

package/onboarding/prompts/proof/round-trip.md

@@ -1,10 +1,13 @@
 # Prove the user journey
 
-Do not do the proof work yourself. Spawn one proof subagent.
-
-Give the subagent the full text of the proof brief at the end of this prompt, the selected
-framework, frontend, model, approved plan, selected documentation URLs, and validation
-evidence. Give it the documentation policy recorded during framework selection.
+Do not do the proof work yourself. Spawn one proof subagent. Tell it to run
+`npx --yes copilotkit@4.9.17 onboard read subagent/prove-round-trip` first and follow the
+prompt it returns. If that read fails because the subagent cannot use the shell, stop that
+subagent. Run the same command yourself, then spawn a fresh subagent with the returned prompt
+and the same handoff. Give it the selected framework, frontend, model, approved plan, selected
+documentation URLs, and validation evidence. Give it the documentation policy recorded during
+framework selection or conversion planning. On a conversion, also give it the frozen
+criterion. Give it the protected path list.
 
 Give it the browser or device control you recorded in the preflight as well. The subagent
 drives the surface and cannot see your environment, so without that finding it spends the
@@ -16,10 +19,20 @@ https://docs.copilotkit.ai/build-with-agents.md
 
 Wait for the subagent to finish.
 
-If the subagent proves the complete round trip, run
-`npx --yes copilotkit@4.9.4 onboard read proof/complete`. The round trip proves core success
-even if a continued-development tool fails. Keep the Skills and MCP results separate from
-the proof result.
+For every protected-path audit in this prompt, run
+`npx --yes copilotkit@4.9.17 onboard audit` from the target app directory. If its result
+starts with `Status: blocked`, report the printed reason and use the route-out rules below.
+A blocked audit proved nothing changed and is not a preservation failure. If a
+protected-path audit reports a changed path, use the route-out rules below. Never repair,
+reset, or revert a protected path.
+
+If the proof result starts with `Status: passed`, run the protected-path audit. Continue to
+`proof/complete` only if that audit passes. After the audit passes, run
+`npx --yes copilotkit@4.9.17 onboard read proof/complete`. A performed surface outcome with
+the full round trip is core success even if a continued-development tool fails. A skipped
+surface outcome still enters `proof/complete` so the CLI records the blocked result. Do not
+describe a skipped surface as proved. Keep the Skills and MCP results separate from the proof
+result.
 
 If the round trip proves and something after it blocks this run anyway -- the managed
 Intelligence dashboard, the debugging surface, or a capability the approved plan already
@@ -30,266 +43,73 @@ not for a journey that worked and then hit a wall: routing a proved run there te
 developer that a framework and frontend that just worked are unsupported, and hands them a
 stop report instead of the application they now have.
 
-If the round trip fails, decide which kind of failure it is before you route. A failure
-caused by a file this run created or changed is a defect in the new work. Send it back to
-the proof subagent to fix and prove again, at most three attempts.
+If the round trip fails, decide which kind of failure it is before you route. The proof
+subagent can repair only project-owned processes, ports, and request options. A failure caused
+by a source, configuration, dependency, or tracked-file change is a defect in the new work.
+
+Retry the proof subagent only for a project-owned process, port, or request-option failure.
+Give it the failure evidence and the failed attempt's pinned Step 1 record. Wait for the
+proof subagent after each operational repair.
+If the result passes, use the passed-result route above. Retry a failed result at most three
+times. Use the route-out rules below for a blocked or third failed result.
+
+Enter the code-repair branch only for a source, configuration, dependency, or tracked-file
+defect.
+
+If the starter shortcut created the selected path, spawn one repair subagent. Give it the
+failed step, proof evidence, generated path list, selected framework, frontend, model, exact
+target app directory, documentation, and policy.
+Require it to change only files that the starter command generated. Do not read or return
+secret values. Require its result to start with `Status: passed`, `Status: failed`, or
+`Status: blocked`, followed by Files changed, Validation, and Blockers. Otherwise, send the
+defect to the implementation subagent that validated the planned implementation path. Give it
+the approved plan and proof evidence. Treat the worker that gets the defect as the repair worker.
+Give the repair worker the protected path list. Do not let a generated or repaired path
+overlap a protected path.
+
+Require the full validation list to pass again. Wait for the repair worker to finish.
+Continue only if its result starts with `Status: passed`. If the repair worker returns
+`Status: failed`, retry the repair with its evidence. Run the protected-path audit after the
+repair passes. Send the full validation list to the validator for the selected path. Use the
+implementation worker for a planned implementation path. Use the repair worker for a starter
+path. Wait for the validator to finish. If its result starts with `Status: passed`, continue.
+If the validator returns `Status: failed`, return its evidence to the repair
+worker. Repeat repair and validation at most three times. If either worker returns
+`Status: blocked`, use the route-out rules below.
+
+Run the protected-path audit again after validation passes. Continue only if its result
+starts with `Status: passed`.
+
+Restart each project-owned process changed by the repair. Then spawn a fresh proof subagent
+with the full original proof handoff, failed proof evidence, and new validation evidence.
+This handoff includes the plan, documentation, policy, current process IDs, ports,
+surface-control state, the continued-tools guide, and the failed attempt's pinned Step 1
+record. Carry that record so the second attempt sends the request the first one failed on.
+A fresh subagent given the plan alone writes its own request where the plan named none, and
+its grounding check then speaks about a question the failed attempt never asked.
+Wait for the fresh proof subagent to finish.
+If the fresh proof result starts with `Status: passed`, run the protected-path audit and use
+the passed-result route above. If it starts with `Status: failed`, begin the next bounded
+repair cycle. Use the route-out rules below for `Status: blocked`. Stop after three repair
+and proof cycles.
 
 Route out only when the failure is not yours to fix, when the same proof still fails after
 three attempts, or when no evidence of the round trip can be produced. In those cases run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`. All three are
+`npx --yes copilotkit@4.9.17 onboard read unsupported/no-validated-path`. All three are
 about the round trip itself. A round trip that proved is not one of them, whatever failed
 after it.
 
-## Proof subagent brief
-
-Everything below the rule is the subagent's prompt. Give it verbatim.
-
----
-
-# Prove the complete round trip
-
-Use the proof steps and documentation URLs from the approved plan. Follow the documentation
-policy the main coding agent gives you before you start.
-
-Run the steps below in the order they appear. They are the proof. Do not design a
-different sequence of your own, and do not drop a step because an earlier one looked
-convincing. Step 6 has a web form and a React Native form: run the one that matches this
-journey's frontend, and run only that one.
-
-Record the result of every step as you go. A step with nothing recorded did not happen.
-Write each captured file to `.copilotkit/proof/` inside the project and name the path in
-the record. That directory holds regenerable evidence rather than application code. Where
-a browser or device tool writes to a location of its own, keep that location and record
-it instead.
-
-Gather what you need in as few commands as possible. Combine independent reads into one
-command rather than running them one at a time. Split a command only when its result decides
-what you run next.
-
-## Step 1 -- Read what the proof needs
-
-Read all of this from the approved plan in one pass, before you start anything:
-
-- the exact request to send through the frontend, in the words the plan gave it,
-- the user-visible result that request has to produce,
-- the expected agent id,
-- where the project's own data lives, and which entities the answer has to name,
-- the start command for the agent and for the frontend, from the plan where it named
-  one and from the project's own scripts otherwise,
-- the runtime URL.
-
-Where the plan named no request, write one that produces the outcome the plan named, and
-record the request you wrote. Every later step uses these words unchanged, so that the
-browser, the device, and the grounding check all speak about one request.
-
-## Step 2 -- Start the agent and the frontend
+If you stop here without taking that route -- a repair cycle you cannot finish, a limit in
+your own harness, a run that has run out -- send one short report before you stop.
+Run the feedback command without another developer question. The CLI telemetry gate decides
+whether the report is sent.
 
-Read the port the developer's agent already serves from this project's own configuration.
-Do not assume a default, and do not start a second copy of an agent this project is
-already running. Before you bind any new server, check that the port is free and pick
-another one if it is not. Record every port you used.
-
-The table names what each frontend's own scaffolder writes, for recognizing a port in a
-started process's output. The project's configuration wins over the table.
-
-| Frontend     | Dev server the scaffolder writes |
-| ------------ | -------------------------------- |
-| Next.js      | `next dev`, port 3000            |
-| React SPA    | Vite, port 5173                  |
-| Vue 3        | Vite, port 5173                  |
-| Angular      | `ng serve`, port 4200            |
-| React Native | Metro, port 8081                 |
-
-Where this project's runtime runs as a process of its own, the frontend documentation
-puts it on port 8200. Use the runtime URL from step 1 rather than that number.
-
-Start each server in the background with the project's own script. Then wait for it to
-answer rather than for a fixed number of seconds:
-
-```bash
-ready=
-for _ in $(seq 90); do
-  curl -fs -o /dev/null "<url>" && ready=1 && break
-  sleep 1
-done
-[ "$ready" = 1 ] && echo "up" || echo "no answer from <url> after 90 seconds"
+```text
+npx --yes copilotkit@4.9.17 onboard feedback
 ```
 
-Read the loop's own last line rather than assuming it ended because the server answered.
-A server that never answered has written the reason to its own output, and reading that
-output is faster than starting it again.
-
-Leave the agent and frontend servers running after proof. Record each process ID and a
-safe command that stops that process. Record the frontend URL and the commands that start
-both servers again.
-
-## Step 3 -- Identify the process that answered
-
-Before you trust the agent, confirm that the process answering is the one in this
-repository. `verify` reports which agents the runtime declares and has nothing to compare
-them against, and `--round-trip` proves an agent answers under the declared id without
-proving which deployment did, so this comparison is yours. A health endpoint that returns
-success proves only that something listens on
-that port. An agent from earlier work often still holds it, and a stale process answers
-as though it were the new one. Ask the running agent which graph or agent id it serves
-and compare that with the id declared in this project.
-
-If they do not match, find out whose process it is before you signal anything.
-`lsof -ti :<port> -sTCP:LISTEN` gives the process id, and `lsof -a -p <pid> -d cwd` gives
-the directory it runs in. Stop it only when that directory is inside this project, and
-stop its children before the parent so nothing survives by reparenting. A holder outside
-this project belongs to other work: leave it running, report it, and bind to another port.
-Never stop a process because its command line matches a name. One `pkill` pattern reaches
-every project on the machine and takes down work that has nothing to do with this run.
-Never continue against a process you cannot identify, and never report a round trip proven
-by one.
-
-Address a local agent by host name rather than by an IP literal. Some local agents bind
-IPv6 only, so an IPv4 literal fails against the correct port.
-
-## Step 4 -- Check the wiring
-
-With both running, check the wiring in one command before you open a browser:
-`npx --yes copilotkit@4.9.4 verify --json`. Add `--runtime-url` when the runtime is not at
-`http://localhost:3000/api/copilotkit`. Read the individual checks rather than the summary
-alone: a check reported `undetermined` did not run, and that is not a pass. Fix anything
-that is not a pass before the browser, because a browser failure stacked on broken wiring
-costs a round of debugging to reach an answer this command already gave.
-
-Treat `intelligence_consumed` as the check that matters most here. A journey that finishes
-with the Intelligence credential never read looks complete and proves nothing about the
-paid surface. `api_key_authenticates` passing beside it says the key is real and the
-runtime never used it.
-
-`intelligence_thread_routes` fails when the runtime reports a license but serves no
-thread routes, which means saved Threads cannot load in a browser. The usual cause is a
-handler mounted `mode: "single-route"`: remove that option so the handler serves its full
-route set, and mount it at a catch-all route. If instead that check is `undetermined`
-because the runtime reports no thread-endpoint state, the runtime predates the field.
-Record that and move on -- there is nothing to repair.
-
-## Step 5 -- Prove that the agent runs
-
-Run `npx --yes copilotkit@4.9.4 verify --round-trip --json`. It sends one request through
-the runtime and reads the answer back from the thread, so it separates an agent that is
-configured from an agent that works. Use `--agent <id>` when the runtime declares more
-than one. If it reports `user-not-identified`, this project's `identifyUser` reads a
-session the CLI does not carry: pass what it reads with `--header "Name: value"` and run
-it again, because an auth-gated app refusing an unauthenticated caller is that app
-working. Do not continue until this passes, and never report a round trip proven without
-it.
-
-## Step 6 -- Drive the surface
-
-Now send one real request through the running frontend, on this journey's own surface.
-Make sure that the request passes through CopilotKit and reaches the selected agent, and
-that the frontend receives working generative UI from the agent. This is the step that
-covers realtime delivery, the frontend provider being wired to this runtime, and a
-generative UI component actually rendering, and no command-line check reaches any of them.
-It is not optional polish: a run that skips it has proven the agent and not the journey,
-and the graph ends such a run as blocked rather than complete.
-
-Use the surface control the main coding agent recorded for your environment. It either had
-one already or registered one before this step, so that finding is the answer and there is
-nothing here for you to go looking for. Do not add a browser driver or a device tool to this
-project: a devDependency and a browser download land in the diff and tax a repository that
-never asked for one, which is a different thing from the server registered against the
-coding agent. If nothing in your environment can drive the surface this journey needs, skip
-this step rather than installing one, and report the skip outcome named below.
-
-Never report a result you did not see, on either surface.
-
-### Step 6a -- Web frontends: React SPA, Next.js, Angular, Vue 3
-
-The surface is a browser, and it also covers browser-origin CORS and CSP, which a CLI
-request never exercises. Drive it with the browser control step 6 named.
-
-1. Open the frontend URL from step 2 and wait for the page to finish loading.
-2. Take one page snapshot. Record whether the CopilotKit surface is on the page. A page
-   that renders without it is a wiring failure rather than a proof to retry.
-3. Read the browser console before you type anything, and record every error already
-   there. An error at this point belongs to page load rather than to the request.
-4. Enter the step 1 request into the CopilotKit input, in the words step 1 recorded, and
-   submit it.
-5. Wait for the assistant turn to finish rather than for a fixed number of seconds. The
-   turn is finished when the streamed text stops growing and the generative UI component
-   has rendered.
-6. Take one screenshot of the finished turn and record where you wrote it.
-7. Read the browser console a second time, and record every error that step 3 did not
-   already list. Those belong to the request.
-8. Read the network requests. Record every request the page made to the runtime endpoint
-   and the status each returned. An answer on the page with no successful request to this
-   runtime behind it came from something else, and that is a failed proof rather than a
-   passing one.
-9. Record one line for the finished turn: the time, the page URL, the element you read
-   the answer from, and what that element showed.
-
-Report exactly one of `performed`, `skipped-no-browser-tool`, or `failed` for a web
-frontend.
-
-### Step 6b -- React Native
-
-The surface is a device or emulator, and a browser cannot stand in for it.
-
-1. List the booted devices in one command: `adb devices -l`. With no booted device this
-   step is `skipped-no-device`. Do not substitute a browser.
-2. Build and install the app on the booted device with the project's own script, which
-   an Expo or React Native CLI project names in `package.json`.
-3. Clear the log buffer before the request: `adb logcat -c`.
-4. Open the CopilotKit surface in the running app and enter the step 1 request, in the
-   words step 1 recorded.
-5. Wait for the assistant turn to finish rather than for a fixed number of seconds.
-6. Capture the terminal state with
-   `adb exec-out screencap -p > .copilotkit/proof/surface.png`, and record that path.
-7. Read the log for the request with `adb logcat -d -t 500`. A redbox is a runtime failure
-   the terminal state never shows.
-8. Record one line for the finished turn: the time, the platform, the device id, the
-   screen you were on, and what that screen showed.
-
-An Android emulator reaches a runtime on the host machine at `10.0.2.2` rather than at
-`localhost`. A request that fails against the runtime with nothing in the runtime's own
-log is that, rather than a broken runtime.
-
-Report exactly one of `performed`, `skipped-no-device`, or `failed` for React Native.
-
-## Step 7 -- Check the answer against the project's data
-
-Where the answer is meant to be about data the project holds, check it against that data.
-Read the entities the project holds -- the ids, names, or records the answer claims to
-describe -- and confirm the answer names those and no others. Record the entities you
-compared. Where the outcome of this journey references no project data, record that
-instead, and do not invent a comparison to pass this step.
-
-An answer that renders correctly over entities the project does not hold looks the same as
-a correct one in a browser, in a screenshot, and in a video, so this comparison is the only
-stage that separates them. An answer that names an entity the project does not hold is a
-failed proof, not a passing one. Find which of these it is before you change anything: the
-project's data never reaches the agent, the agent receives it and its instructions ignore
-it, the page loads its data after the context was registered, or the run wired a different
-source than the page renders. Fix that cause, then prove again.
-
-## Step 8 -- Compare with the recorded OSS baseline
-
-Run this step only for a recorded `both-oss` starting state. Compare the final round trip
-with the recorded OSS baseline. The same frontend request must still reach the same agent
-and produce the same kind of user-visible result. The runtime must now report
-`licenseStatus`, and the authenticated Intelligence checks must pass. Record both before
-and after evidence.
-
-## Step 9 -- Set up the continued-development tools
-
-Fetch the continued-development guide from the main coding agent with the proof
-documentation. Try the continued-development tools after the application passes proof.
-Use it to install the project-scoped CopilotKit Skills.
-Use it to configure the CopilotKit documentation MCP server for the current coding agent.
-
-Do not validate whether the Skills or MCP server installed correctly. Record the command
-result for each attempt. Report each tool result separately. A tool error does not change
-the proof result.
-
-## Step 10 -- Return the result
-
-Return the proof or the exact failed step to the main coding agent, together with the
-input, the visible result, the relevant process status, the evidence locations, the
-surface-check outcome, and which surface that outcome speaks for. Do not return secret
-values. Stop after you return the result.
+Write at most four lines to standard input: the step you stopped at and what stopped it.
+Send no secrets, source code, logs, or command output. The command refuses a report that
+carries any of those, prints the reason, and exits zero. A refused report is not a failed
+step. Report friction only from a run that finished, never from a stop. A run that dies in
+this phase is the one this graph most needs to hear about and the one it hears from least.

package/onboarding/prompts/starter/clone.md

@@ -36,7 +36,7 @@ instruction in this prompt.
 
 If the developer did not name an Intelligence project, list the available projects:
 
-`npx --yes copilotkit@4.9.4 project list --json`
+`npx --yes copilotkit@4.9.17 project list --json`
 
 Ask the developer to select a project or give a name for a new project. If the developer
 already gave this answer, do not ask again. Do not read a secret value. Do not show or
@@ -46,7 +46,7 @@ Run the command from the parent directory. Do not inspect another entry in the p
 directory. Replace each placeholder with the recorded value. Do not run a placeholder as
 a shell argument.
 
-`npx --yes copilotkit@4.9.4 init --name <project-name> --framework <framework-id> --channel none --no-banner --project <slug-or-id> --install`
+`npx --yes copilotkit@4.9.17 init --name <project-name> --framework <framework-id> --channel none --no-banner --project <slug-or-id> --install`
 
 If the developer wants a new project, use `--create <name>` instead of
 `--project <slug-or-id>`. If the developer asked to skip the dependency install, use
@@ -60,8 +60,8 @@ account. The command does not need terminal input.
 If the command succeeds, do not rebuild the starter by hand. Inspect only the generated
 paths inside the target directory. Record the files, install result, project connection,
 and validation commands. Then run
-`npx --yes copilotkit@4.9.4 onboard read proof/round-trip`.
+`npx --yes copilotkit@4.9.17 onboard read proof/round-trip`.
 
 If the command fails, report its exact error and do not claim that the starter is ready.
 Then run
-`npx --yes copilotkit@4.9.4 onboard read unsupported/no-validated-path`.
+`npx --yes copilotkit@4.9.17 onboard read unsupported/no-validated-path`.

package/onboarding/prompts/subagent/create-plan.md

@@ -73,6 +73,50 @@ Create one plan for implementation, validation, and proof. Name each file or are
 change. Name the commands that can validate the result.
 Name the commands or user path that prove a real generative-UI round trip.
 
+The terminal is one component rendered through this frontend's own registration -- the
+`useComponent` hook, or Angular's `registerComponent` -- over entities the project holds.
+Plan that component: name it, name the fields it shows, and name which of the project's own
+records fill them. Do not plan a declarative A2UI card unless the developer asks for one:
+the terminal needs no renderer package and nothing added to the agent, because the tool is
+declared by the frontend and forwarded over AG-UI.
+
+A prose answer is not the terminal. The structure is what the grounding comparison reads: a
+component with named fields can be checked field by field against the records the project
+holds, and that comparison is the only thing separating a correct answer from a confident
+invented one.
+
+For a recorded `both-oss` starting state, plan no generative-UI component. The terminal is
+the baseline request still working over the same frontend, the runtime now constructed
+with `intelligence`, and the thread that request creates listed in this frontend's threads
+drawer. A `both-oss` project already has its user-visible result. The conversion preserves
+that result rather than replacing it with a new one, and a generative-UI component added
+here is work the developer did not ask for.
+
+Plan the threads drawer itself: add it from the selected drawer page, where this frontend
+does not already render one. Where this journey's frontend framework ships no threads
+drawer -- React Native --, plan that the thread is proved in the managed Intelligence
+dashboard instead.
+
+## Order the plan into steps
+
+Create one ordered list of implementation steps. For each step, name the outcome, the exact
+files or directories it changes, its validation commands, and the steps it depends on.
+
+One implementation subagent runs every step in that order. Do not split the steps across
+concurrent subagents, and do not plan a separate step to reconcile a split.
+
+Use the protected path list you were given. It is the baseline the CLI captured, not a
+list to re-derive: a path you leave out of it is not protected, and a path you add to it
+is not in the baseline the audit reads. Do not name a protected path as a path a step
+changes. Do not name a path that overlaps a protected path. The paths overlap when they are
+equal or either path is an ancestor directory on a path-segment boundary. `apps/a` overlaps
+`apps/a/src`, but not `apps/ab`. `app.ts` does not overlap `app.tsx`. If the plan needs
+one, return `Status: blocked` before approval.
+Return the protected path list as part of the plan.
+
+Keep final validation and proof outside the implementation steps. The developer approves
+one plan.
+
 Keep a production build out of the validation commands. A type check plus the real round
 trip is the proof, and the round trip runs in development mode. Name the production build
 as a follow-up for the developer instead. Never raise a bundle budget or relax a lint rule
@@ -88,5 +132,6 @@ Gather what you need in as few commands as possible. Combine independent reads i
 command rather than running them one at a time. Split a command only when its result decides
 what you run next.
 
+Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
 Return the plan, the URLs that you read, and each documentation gap. Stop after you return
 the findings to the main coding agent.

package/onboarding/prompts/subagent/implement-and-validate.md

@@ -1,59 +1,85 @@
 # Implement and validate the approved plan
 
+Implement every step of the approved plan in plan order, and run the full validation list.
+Do not repeat the full repository inspection.
+
+Do not change a protected path.
+Do not change a path that overlaps a protected path. Paths overlap when they are equal or
+either path is an ancestor directory on a path-segment boundary. `apps/a` overlaps
+`apps/a/src`, but not `apps/ab`. `app.ts` does not overlap `app.tsx`.
+
+Change only the files and directories the approved plan names as changeable. If the work
+requires a file the plan does not name, stop and return the blocker. Do not run a
+repository-wide formatter.
+
+Before validation, read the protected path list. Inspect the current changed and untracked
+paths. Keep protected paths out of the run path set. Compare every changed path with the
+paths the plan named. Here, a changed path means one in the run path set. If a changed path
+is outside them, return `Status: blocked` before validation. Run the approved validation
+commands one at a time. Fix validation and proof defects only in the paths the plan named.
+
 Use only the approved plan and the selected documentation URLs. Follow the documentation
 policy the main coding agent gives you before you change the project.
 
 Add only the props, options, and imports that appear in the fetched documentation. A
 remembered API from an earlier CopilotKit version will fail type checking against this
-release, so do not decorate a documented example with anything it does not show.
+release. Do not add details that the fetched documentation omits.
+
+The documentation supplies the wiring. The project supplies the application. Use that
+wiring in the project's domain. Do not copy an example's agent name, tools, or data.
 
-The documentation supplies the wiring. The project supplies the application. That rule
-governs props, options, and imports, and it stops there. A documentation example names a
-domain of its own to make itself readable. Build what the plan names, in the project's
-own domain, from the wiring the page shows. Do not carry the page's example domain into
-the project: not its agent name, not its tools, not its data.
+Preserve each existing agent and frontend. Add only missing parts and the CopilotKit
+connection. Do not read, show, store, or return secrets. Do not read a file outside the
+project directory: not for a credential, and not for an API question the fetched
+documentation answers. Ask the main coding agent for a missing credential.
 
-Preserve each agent or frontend that already exists. Add only the missing parts and the
-CopilotKit connection. Do not read, show, store, or return secret values. Do not read a
-file outside the project directory: not for a credential, and not for an API question the
-fetched documentation answers. A missing credential is the main coding agent's to ask
-for.
+An existing `README.md` is the developer's, not this run's. Leave it exactly as you found
+it: not the title, not a section, not a line. Where this run has documentation to write,
+write it to a new file and name that file when you report the result. On an empty project
+the README is the whole of the brief -- the only place the developer said what they
+wanted, and the thing they read this run's result against -- so the rule binds hardest
+where the file looks emptiest.
 
 For a recorded `both-oss` baseline, preserve the existing agent, frontend, CopilotKit
-integration, user-visible request, and runtime behavior. Do not replace the existing
-persistence. Change only the approved project selection, the approved CopilotKit
-dependency upgrade, and the Intelligence runtime wiring.
-Run the recorded baseline checks again after the Intelligence wiring and report any
-regression.
-
-Apply the planned CopilotKit dependency upgrade before you wire Intelligence, as its own
-step, and record each version it changed. Then re-run the recorded baseline checks. A
-regression at this point can only be the upgrade, which is why it is checked here rather
-than after the wiring.
-
-If the baseline regresses, restore the manifest and lockfile to their recorded state,
-leave Intelligence unwired, and report the regression with the failing check. A
-half-upgraded project with no working chat is worse than the one this run was given, and
-finishing the wiring on top of a broken baseline hides which change broke it.
-
-Report each `@copilotkit/*` version before and after the upgrade. Where the plan named no
-dependency change, say that the installed versions already met the floor.
-
-When the documentation creates the frontend with the framework's own scaffolder,
+integration, user-visible request, runtime behavior, and persistence. Do not replace the
+existing persistence. Change only the approved project selection, CopilotKit dependency
+upgrade, Intelligence runtime wiring, and the approved threads drawer: the drawer belongs
+in that list because the approved plan already named it, not because this step invents a
+new one. After wiring, run the recorded baseline checks and report any regression.
+
+Where the plan names a CopilotKit dependency upgrade:
+
+1. Apply the planned CopilotKit dependency upgrade before you wire Intelligence.
+2. Report each `@copilotkit/*` version before and after the upgrade.
+3. Then re-run the recorded baseline checks.
+
+If the baseline regresses, restore the manifest and lockfile to their recorded state, leave
+Intelligence unwired, and report the regression with the failing check. Stop. Where the plan
+names no dependency change, report that the installed versions met the floor.
+
+When the documentation uses the framework's scaffolder,
 run that scaffolder rather than hand-authoring what it emits.
-Do not re-declare a compiler option it set. Every real project of that framework
-inherits those defaults, so a hand-written replacement measures a configuration no
-developer has. Where the plan needs configuration the scaffolder did not write,
-extend the scaffolder's file and set only what you add.
+Do not re-declare a compiler option it set.
+If the plan needs more configuration, extend the scaffolder's file and set only what you add.
+
+Where the plan names data the project already holds, share that data with the agent through
+the documented context API. Tell the agent to refuse to answer about entities the shared
+context does not carry and to name what is missing.
+
+An empty context set is a condition to state rather than an input to work around. Keep
+these two cases apart in the instructions you write. The context set holds no records:
+the answer says the page sent none. The context set holds records and none of them match
+the request: the answer says the request names something the page does not hold, and
+names what the page did send. An agent that runs the two together reads an empty page as
+a page to fill in.
 
-Where the plan names data the project already holds, share that data with the agent
-through the context API the selected documentation names for this frontend. Then write the agent's instructions to
-refuse to answer about entities the shared context does not carry, and to name what is
-missing instead. An agent with no context and no refusal invents plausible entities, and
-no part of the run errors.
+Where a tool renders one of those records, take every field of the record from the
+context set. A field the model is allowed to fill is a field it fills, so an optional
+field on that tool's schema turns an empty context set into a well-formed record the
+project does not hold, and the rendered result looks the same either way.
 
-Run the validation commands from the approved plan. Record the changed files, command
-results, and each error. Do not claim that the real user journey works in this phase.
+Run the full validation list. Record changed files, command results, and errors. Do not
+claim that the real user journey works in this phase.
 
 Report the runtime constructor you wrote. Name whether it passes `intelligence` or
 `runner`. A runtime built with `runner` is the SSE runtime and never reads the credential,
@@ -63,5 +89,5 @@ Gather what you need in as few commands as possible. Combine independent reads i
 command rather than running them one at a time. Split a command only when its result decides
 what you run next.
 
-Return the implementation result and validation evidence to the main coding agent. Stop
-after you return the result.
+Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
+Return exactly four sections: Status, Files changed, Validation, and Blockers. Stop.