copilotkit 4.27.0 → 4.28.0

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

@@ -32,8 +32,8 @@ Wiring is not behavior. The CopilotKit SDK dependency, the middleware the agent
 in, the runtime mount, the AG-UI connection, and a frontend that renders what the agent
 already returns are wiring. Plan them as ordinary steps.
 
-Every item on the behavior list is a change the developer has to approve, so it is a risky
-change. Where a step needs one, plan it as its own item, name the file and the exact change, and state that it
+Every item on the behavior list is a change the developer has to approve, so it goes under
+`Changes that need your approval`. Where a step needs one, plan it as its own item, name the file and the exact change, and state that it
 changes how the agent answers everywhere, not only in CopilotKit. A system prompt the
 developer wrote is the agent's behavior rather than a setting this run tunes until a
 component renders. Where the plan cannot be written without such a change and you cannot
@@ -97,7 +97,7 @@ against a dead host, and the failure arrives as an empty-body 404 with no cause
 Ask the CLI for the dependency upgrade, from the target directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard upgrade-plan --json
+npx --prefer-offline --yes copilotkit@4.28.0 onboard upgrade-plan --json
 ```
 
 It reads the installed tree and the registry. Read `status`:
@@ -118,7 +118,7 @@ It reads the installed tree and the registry. Read `status`:
 
 The floor is 1.70.0 because the runtime resolves managed Intelligence entitlement
 authority from that version. Below it, the Intelligence features stay dark with no error.
-An exact pin is usually deliberate, so a move of one is a risky change the developer
+An exact pin is usually deliberate, so a move of one is a change the developer
 approves, not a repair the run invents halfway through. Where the developer needs a pin held, return
 `Status: blocked` and name `unsupported/no-validated-path` as the outcome.
 
@@ -185,33 +185,22 @@ 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 by
-`npx --prefer-offline --yes copilotkit@4.27.0 verify --round-trip`, which needs no browser. Do not plan a
+`npx --prefer-offline --yes copilotkit@4.28.0 verify --round-trip`, which needs no browser. Do not plan a
 step that opens the managed Intelligence dashboard.
 
 ## Name the files the run writes itself
 
 List these in the plan under `Files the run writes itself`, apart from the implementation
-steps. They are not steps, and they are not risky changes.
+steps. They are not steps, and they need no approval, except a file that is also under
+`Uncommitted files`: list that one under `Changes that need your approval` too.
 
 - Each `planChanges` entry from `onboard credentials`: the project key in the env file
   `environmentPath` names, the project record, and, where it lists `ignore-entries`, the
-  lines `project select` adds to `.gitignore` so that no credential env file can be
-  committed.
+  lines `project select` adds to `.gitignore` so that no credential env file and no
+  `.playwright-mcp/` browser snapshot can be committed.
 - `.copilotkit/proof/`, where the proof writes its evidence. It holds no source. The
   developer can delete it after the run.
 
-## Name the Skills install
-
-List the CopilotKit Skills install under `Skills install`, as its own line:
-`npx skills add CopilotKit/CopilotKit/skills -y`. It writes `.agents/skills/` and links it
-into `.claude/skills/`. End the line with "say **no Skills** to skip". Where
-`.agents/skills` already holds the CopilotKit skills, write `in place` instead, and plan no
-install.
-
-The Skills install is not a risky change. It adds agent-rule files only, holds no secret,
-changes nothing the app runs, and comes out with one delete. Do not list it under
-`Risky changes`.
-
 ## Scaffold an empty project
 
 This section applies when the starting state is `empty` and a step runs a scaffolder, such
@@ -243,7 +232,7 @@ the plan under `Uncommitted files`, one line each, with the path and one sentenc
 what the step changes there and why no other file will do. Keep the step in the plan.
 Adding a feature to an app the developer already built is the case this exists for: the
 option lives in a file they wrote, and on an app whose work was never committed that file
-has uncommitted changes. Each of those edits is a risky change, so the developer's answer
+has uncommitted changes. Each of those edits needs approval, so the developer's answer
 to the plan is their consent. The CLI records none.
 
 Installing or upgrading a package changes the manifest that lists it, such as `package.json`
@@ -288,15 +277,16 @@ Do not add compiler strictness the project did not have. Nothing later in the ru
 allowed to weaken type safety, so a stricter gate named here is one the run cannot get
 back out of.
 
-## Name the risky changes
+## Name the changes that need approval
 
 The run shows the plan to the developer and goes on to build it without waiting. It stops
-for an answer only when the plan makes a risky change. `onboard start` took a backup, so
-`onboard restore` undoes any other change the backup holds.
+for an answer only when the plan makes a change that needs approval. `onboard start` took a
+backup, so `onboard restore` undoes any other change the backup holds.
 
-List each risky change under `Risky changes`, one line each: the path or package, what the
-step does to it, and why the plan needs it. Write `none` when there is no risky change. A
-step makes a risky change when it:
+List each change that needs approval under `Changes that need your approval`, one line each: the path
+or package, what the step does to it, and why the plan needs it. Write `none` when there is
+none. List every other change under `What I will change`. A step makes a change that needs
+approval when it:
 
 - upgrades a dependency by a major version: a move whose `to` has a different major version
   than `from`, or a move of an exact pin
@@ -306,26 +296,34 @@ step makes a risky change when it:
 - changes a file that has uncommitted changes, from `Uncommitted files`
 - untracks a file or changes `.gitignore`, other than the lines under
   `Files the run writes itself`
-- writes to an env file the app already uses, other than the key line the developer
-  approved in the setup questions
+- writes to an env file the app already uses, other than the key line for the key file
+  the setup answers recorded
 - changes the existing agent's behavior, as `What the existing agent's behavior is`
   defines it
-- changes more than 10 files in all, the same limit the backup tripwire sets for deleted
-  files
+- changes more than 10 files in all. Count only the files the plan's own steps change. Do
+  not count a file the framework's own tooling writes by itself, such as the `AGENTS.md`
+  and `CLAUDE.md` that `next dev` writes, or a file under `Files the run writes itself`.
+  The limit is the same one the backup tripwire sets for deleted files
 - writes a file outside the project directory
 - changes the version of any CopilotKit dependency: an `@copilotkit/*` package or the
   `copilotkit` Python package, by any amount
 
-The plan is also risky when the backup does not hold every file: `backup.status` is
+A change the developer approved in the setup message needs no approval in the plan. The setup
+answers the main coding agent gives you show it: `envFile` is `approved` for the untrack or
+the `.gitignore` line that the env-file line named, and `alternative` for the key in the other
+env file. `uncommittedWrites: approved` allows the connection's writes to the env file and
+`.copilotkit/project.json`. Name each one under the notes instead.
+
+The plan also needs approval when the backup does not hold every file: `backup.status` is
 `partial` or `failed` in the `backup` result the main coding agent gives you. Name it as a
 line of its own. For `partial`, name each path in `backup.notHeld` with its `why`, which
 names the limit for a size skip, and the count in `backup.moreNotHeld` if any. For
 `failed`, name the cause in `backup.detail`, and that `onboard restore` puts nothing back.
-A step that changes one of those paths cannot be undone. `pending` is not risky: the CLI
+A step that changes one of those paths cannot be undone. `pending` needs no approval: the CLI
 takes the backup when the run moves to the chosen project, or at the next step, before any
 change. Say that in the plan.
 
-Do not leave a risky change out of the list to keep the run moving.
+Do not leave a change that needs approval out of the list to keep the run moving.
 
 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

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

@@ -32,7 +32,7 @@ listen on a port, and cannot connect to localhost. It does not always fail: a pa
 install can wait with no output until you stop it. So request escalation on the first run,
 not after a hang or an error, for these commands:
 
-- the dependency install and the Skills install,
+- the dependency install,
 - the commands that start the app and agent servers,
 - HTTP requests to those servers.
 
@@ -100,6 +100,13 @@ Wiring is not behavior. Add the CopilotKit SDK dependency, wrap the agent in the
 middleware, mount the runtime, connect AG-UI, and render what the agent already returns.
 Those are the parts this run adds.
 
+Every install in this step follows one rule for a version the registry does not serve
+yet. npm reports it as `ETARGET`, pnpm as `ERR_PNPM_NO_MATCHING_VERSION`, Yarn as
+`Couldn't find any versions` or `No candidates found`, and Bun as `No version matching`.
+A package published minutes earlier can name a dependency whose publish has not reached
+the registry. Wait 30 seconds and run the same install once more. If it fails again,
+report the first error.
+
 A run whose `environmentPath` ends in `.env.local` hosts the CopilotKit runtime in that
 Next.js app, never in a separate server: no other process reads the key from that file.
 
@@ -126,10 +133,10 @@ new one. After wiring, run the recorded baseline checks and report any regressio
 
 Where the plan names a CopilotKit dependency upgrade, apply its moves before you wire
 Intelligence: declare each exact version in its app's manifest, then install with the
-project's package manager. Then check the installed tree:
+project's package manager, under the install rule above. Then check the installed tree:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard upgrade-plan --check --json
+npx --prefer-offline --yes copilotkit@4.28.0 onboard upgrade-plan --check --json
 ```
 
 `single` means every direct dependency resolved to one version. `duplicates` names each
@@ -144,7 +151,7 @@ If the check finds duplicates or the baseline regresses, put the manifests and l
 back, leave Intelligence unwired, and report what failed:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard upgrade-plan --revert --json
+npx --prefer-offline --yes copilotkit@4.28.0 onboard upgrade-plan --revert --json
 ```
 
 Then end your turn. Never add an `overrides`, `resolutions`, or `pnpm.overrides` block to
@@ -180,7 +187,7 @@ Where the plan names a Learning Container id, check that the container exists fi
 this from the target app directory, before you write any selector:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 learning containers get <id> --json
+npx --prefer-offline --yes copilotkit@4.28.0 learning containers get <id> --json
 ```
 
 `"status": "success"` means the container exists. An `error.code` of
@@ -202,36 +209,6 @@ constructor for it, and never write an id the plan does not name: a selector poi
 id the platform does not hold answers `LEARNING_CONTAINER_NOT_FOUND` on every thread create.
 Where the plan names no container, write no selector.
 
-## Install the CopilotKit Skills
-
-The plan names the Skills install on its own line, and the build does not wait for an
-answer on it. Install them in a whole-plan implementation. Skip it only when the developer
-said no, which the main coding agent passes in the handoff. A repair handoff never installs
-them.
-
-Where `.agents/skills` already holds the CopilotKit skills, do not install them again.
-Report that they are in place.
-
-Where the developer said no, do not install them, and do not call that a change from the
-plan. Report in the Validation section that the developer declined them.
-
-Install them at the same time as the project's dependencies, not after validation: start both installs together. Where this run installs no dependencies,
-install them before you run the validation list. Tell the developer what the skills
-install writes into this project before you run it: a `.agents/skills` directory holding
-one folder per CopilotKit skill, linked into `.claude/skills`. Both sit in the working tree,
-so the install shows up in `git status` and can land in a commit. You cannot know whether
-this project keeps those directories in version control, so name them before you write them
-rather than after.
-
-Then run `npx skills add CopilotKit/CopilotKit/skills -y` in the target app directory.
-
-The plan names both directories under `Skills install`, so they are not departures. Name
-them under Files changed. Do not register an MCP server: the Skills read the CopilotKit
-documentation without one.
-
-Check whether the install succeeded, and record the command result in the Validation
-section. A failed install does not change your status. Report it and continue.
-
 ## Report the result
 
 Report the runtime constructor you wrote. Name whether it passes `intelligence` or

package/onboarding/prompts/subagent/inspect-repository.md

@@ -8,7 +8,7 @@ Your handoff holds the JSON of this command, which the main coding agent ran fro
 target project directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard inspect --json
+npx --prefer-offline --yes copilotkit@4.28.0 onboard inspect --json
 ```
 
 Read that JSON. Do not run the command again. If the handoff holds no inspection JSON, run

package/onboarding/prompts/subagent/prove-oss-baseline.md

@@ -35,7 +35,7 @@ Prove the live runtime in this order:
 4. Confirm from project files that the runtime constructor passes a `runner` option rather
    than an `intelligence` option. A package, import, project file, or key is not use proof.
 5. Run
-   `npx --prefer-offline --yes copilotkit@4.27.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
+   `npx --prefer-offline --yes copilotkit@4.28.0 verify --expect-runtime oss --round-trip --agent <expected-agent-id> --json`,
    with the runtime URL or auth header options that this project needs. Add
    `--runtime-url <url>` when the report names a runtime URL the dev server does not
    serve. Require exit zero

package/onboarding/prompts/subagent/prove-round-trip.md

@@ -30,7 +30,7 @@ the steps name: no SDK calls, AG-UI requests, or thread reads of your own to con
 journey's frontend, and run only that one.
 
 A run that cloned a starter is the one exception. When the main coding agent tells you
-that this run cloned a starter, run Step 1 and the proof checks, then go to Step 10. Skip Steps 5a through 9, open no browser
+that this run cloned a starter, run Step 1 and the proof checks, then go to Step 9. Skip Steps 5a through 8, open no browser
 or device, and report `skipped-cloned-starter` as the surface-check outcome.
 
 Where this is a second attempt after a repair, run every step from the proof checks through
@@ -76,7 +76,7 @@ about the failure it was spawned to clear.
 Run this from the target app directory:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard proof-check --json
+npx --prefer-offline --yes copilotkit@4.28.0 onboard proof-check --json
 ```
 
 It starts each app's `dev` script unless a server from that app already listens, and
@@ -132,7 +132,7 @@ Otherwise sort `firstFailure`, and run the command again after each repair:
   asking. Read the port from the log, not from the plan, and record it:
 
   ```text
-  npx --prefer-offline --yes copilotkit@4.27.0 onboard runtime-url --url <runtime-url>
+  npx --prefer-offline --yes copilotkit@4.28.0 onboard runtime-url --url <runtime-url>
   ```
 
   `<runtime-url>` is the project's runtime URL, or the plan's, with its port replaced by the
@@ -177,6 +177,13 @@ Otherwise sort `firstFailure`, and run the command again after each repair:
 
   Where the handoff carries a thread id from the developer, skip the numbered steps above
   and do not open the app for them. Run the checks with `--thread <id>` at once.
+- `round-trip:page_context_reaches_agent` with a detail that says the starter does not pass
+  page context yet: it is marked `advisory`, and the checks pass. This framework's starter
+  and its AG-UI adapter keep the page's context off the model's prompt. That is a known gap,
+  not a fault of this run. Do not repair the adapter. Still run Step 5a where it applies. If
+  its context comparison fails, record that under the same warning rather than as a failed
+  step. Return the warning with the proof result. The rules below are for every other
+  page-context result.
 - `round-trip:page_context_reaches_agent` at `fail`: the agent answered the plain request
   and recorded nothing for the request that carried context. Return it with its evidence as
   a failed proof step. At `undetermined` and marked `advisory`, the agent answered without
@@ -212,10 +219,11 @@ for the same reason. Skip both steps and send no run. Record that they sent no r
 reason, and prove the page's data and the component in the browser instead, at Steps 6
 and 7.
 
-`verify --round-trip` asks a question that needs no context. Where the frontend's files
-call a context hook, it also sends one token as context and reports
-`page_context_reaches_agent`, whose `pass` proves that the agent's model sees context at
-all. An agent scoped to its own task answers without the token, so that check is often
+`verify --round-trip` asks a question that needs no context. It then sends one token as
+context and reports `page_context_reaches_agent`, also where the frontend's files call no
+context hook, because the CopilotKit frontend sends context entries of its own. Without a
+context hook, a `pass` proves only that a run with context answers. Where the files call a
+context hook, a `pass` proves that the agent's model sees context at all. An agent scoped to its own task answers without the token, so that check is often
 `undetermined`, and this step is then the only proof of the path. A `pass` does not prove
 that the page's own entries arrive in the shape the agent reads. Nothing else before the
 browser reads that path, so a page whose data the agent never sees answers fluently over a
@@ -228,9 +236,15 @@ the agent sees the request the browser sends rather than a thinner one. Read the
 files the main coding agent named in the handoff, and search the project only for a file it
 did not name. Do not search the dependencies for the shape of an entry: the page's own call
 shows it. Send the same run
-body twice, to `<runtime>/agent/<agent id>/run`: once carrying the context entries the page
+body twice: once carrying the context entries the page
 publishes, and once carrying the same entries with one value changed. Use the step 1
-request both times. Record the streamed events from each, and name both capture paths.
+request both times. Write each body to a JSON file in `.copilotkit/proof/`, and send it with
+`npx --prefer-offline --yes copilotkit@4.28.0 verify --send-run <file> --agent <agent id> --json`.
+The command sends the body to `<runtime>/agent/<agent id>/run` and reads the events the run
+streams. It writes them to `<file name>.events.jsonl` beside the body, and prints that path
+with the answer text and the tool calls. Do not send a run with `curl` and read its events
+with a client of your own. A managed runtime streams the events over the gateway, behind a
+join token that expires 30 seconds after the run starts. Name both capture paths.
 
 For the changed run, pick one record the step 1 request matches. Add a marker to a text
 field that the answer repeats and that the step 1 request does not quote, such as its title
@@ -243,7 +257,8 @@ nothing to copy invents records. That failure belongs to the probe, not to the i
 
 Read each answer against the context it carried. The run carrying the page's context has to
 name the project's own records and no others. The run carrying the changed entry has to
-carry the marker, character for character, and name no record its context did not hold. A
+carry the marker's 8 hex characters anywhere in it, in any case and with any punctuation
+around them, and name no record its context did not hold. The model can reword the rest. A
 model that the context never reaches cannot produce the marker. A model that invents a
 different record on every call cannot produce it either, so two answers that only differ
 prove nothing. An answer without the marker means the page's data is not reaching the model.
@@ -270,8 +285,8 @@ Read the registrations this project's frontend declares, by name. Step 5a alread
 step 1 request with those declarations, so read the tool calls out of the events Step 5a
 captured for the run carrying the page's unchanged context. Do not send that request again.
 Where Step 5a sent no run because the proof checks needed `--thread`, send no run here
-either. Where Step 5a sent no run, because this journey shares no page data, send the step 1 request
-to `<runtime>/agent/<agent id>/run`, carrying those declarations, and read the tool calls out
+either. Where Step 5a sent no run, because this journey shares no page data, send the step 1 request,
+carrying those declarations, with `verify --send-run` the way Step 5a does, and read the tool calls out
 of that run's own events. Where the Step 5a run carried none of those declarations, send
 that run once more with them, and read that run instead. Never report a wiring gap from a run
 that carried no declarations: the agent has no component to call in it. The agent has to call one of the names the frontend registered. An
@@ -302,7 +317,7 @@ For a recorded `both-oss` starting state, this step has no component to render.
 same request the baseline recorded, require the same kind of user-visible result the
 baseline produced, and require that the thread for that request is listed in the drawer.
 Where this journey's frontend framework ships no threads drawer -- React Native --, prove
-that thread with `npx --prefer-offline --yes copilotkit@4.27.0 verify --round-trip`, which reads the
+that thread with `npx --prefer-offline --yes copilotkit@4.28.0 verify --round-trip`, which reads the
 answer back off the thread and needs no browser. Where the proof checks needed `--thread`,
 prove the thread for this request with `verify --thread <id>` instead. Record which of the
 two you proved.
@@ -332,7 +347,7 @@ limit can be ten minutes. You cannot interrupt a call while it runs, so the limi
 what you do after one. If a browser call took longer than 60 seconds to return, the browser
 control is unresponsive. Do not call the browser again in this attempt. A second call to a
 hung tool waits as long as the first one did. Run
-`npx --prefer-offline --yes copilotkit@4.27.0 verify --frontend-url <the frontendUrl the proof checks resolved> --json` once,
+`npx --prefer-offline --yes copilotkit@4.28.0 verify --frontend-url <the frontendUrl the proof checks resolved> --json` once,
 and record the `frontend_assets_served` result. Report the outcome `failed` with the cause
 `browser-control-unresponsive`. The application is not at fault on this evidence: every
 step before the browser proved the runtime without one, and no repair to the project can
@@ -342,7 +357,7 @@ reach the tool.
    the page to finish loading. Do not retype the host, and do not substitute a URL a tool
    offers you by default. Where the page loads but its styling is missing or the chat
    control is dead, run
-   `npx --prefer-offline --yes copilotkit@4.27.0 verify --frontend-url <the url you opened> --json`
+   `npx --prefer-offline --yes copilotkit@4.28.0 verify --frontend-url <the url you opened> --json`
    before you diagnose anything else. A dev server can serve its page and refuse every
    static chunk behind it, and on screen that is indistinguishable from a broken
    integration. The `frontend_assets_served` check tells the two apart.
@@ -356,7 +371,10 @@ reach the tool.
    turn is finished when the streamed text stops growing and the generative UI component
    has rendered. For a recorded `both-oss` starting state, this step has no component, and
    the turn is finished when the streamed text stops growing.
-6. Take one screenshot of the finished turn and record where you wrote it.
+6. Take one screenshot of the finished turn, and record its path. Where the browser tool
+   takes a path, save it in `.copilotkit/proof/`. A tool that writes into its own output
+   folder, such as `.playwright-mcp/`, can keep it there. Never save it among the project's
+   own files.
 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
@@ -446,42 +464,7 @@ it, rather than reading the compatibility field as a pass.
 
 For every other starting state, record Step 8 as not applicable.
 
-The application edit ban ends only after Step 8 passes or is recorded as not applicable.
-Step 9 can write only the tool files named by its guide or by this step.
-
-## 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.
-
-The implementation subagent installs the Skills unless the developer declined them. Check that
-it did. Look for the `.agents/skills` directory and the `.claude/skills` links in this
-project, and read the Skills result the implementation reported. Do not install them again.
-
-Where the developer declined them, do not install them, and do not call that a change from
-the plan. Report the command for them to run later instead:
-`npx skills add CopilotKit/CopilotKit/skills -y`.
-
-Where the developer did not decline them and they are missing, install them as a recovery step.
-Tell the developer what the skills install writes into this project before you run it: a
-`.agents/skills` directory holding one folder per CopilotKit skill, linked into
-`.claude/skills`. Both sit in the working tree, so the install shows up in `git status`
-and can land in a commit. You cannot know whether this project keeps those directories in
-version control, so name them before you write them rather than after. Then run
-`npx skills add CopilotKit/CopilotKit/skills -y` to install the
-project-scoped CopilotKit Skills.
-<!-- sandboxed-harness -->
-It needs the network, so in a sandbox request escalation for it on its first run.
-<!-- /sandboxed-harness -->
-Record that the proof ran the install because the implementation did not.
-
-Do not register an MCP server: the Skills read the CopilotKit documentation without one.
-
-Check whether the install succeeded and record what you found. Record the command result.
-Report the Skills result separately from the proof result. A tool error does not change the
-proof result: this journey proved or it did not, whatever the install did.
-
-## Step 10 -- Return the result
+## Step 9 -- Return the result
 
 Start with `Status: passed`, `Status: failed`, or `Status: blocked`.
 Use `Status: passed` when the proof attempt completed with `performed`,

package/onboarding/prompts/unsupported/no-validated-path.md

@@ -36,17 +36,17 @@ Before you show the best-effort plan, require this complete packet:
 Before you end your turn to wait for the developer, report the pause:
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard checkpoint --phase awaiting-developer
+npx --prefer-offline --yes copilotkit@4.28.0 onboard checkpoint --phase awaiting-developer
 ```
 
 After the developer approves the best-effort plan, run
-`npx --prefer-offline --yes copilotkit@4.27.0 onboard read fallback/best-effort`.
+`npx --prefer-offline --yes copilotkit@4.28.0 onboard read fallback/best-effort`.
 
 Send one short report. The friction command follows the telemetry setting the developer
 already chose, so it needs no separate question.
 
 ```text
-npx --prefer-offline --yes copilotkit@4.27.0 onboard friction --phase stop --category <slug> --message "<sentences>"
+npx --prefer-offline --yes copilotkit@4.28.0 onboard friction --phase stop --category <slug> --message "<sentences>"
 ```
 
 `--message` takes one or two sentences: the step you stopped at and what stopped it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "copilotkit",
-  "version": "4.27.0",
+  "version": "4.28.0",
   "type": "module",
   "engines": {
     "node": ">=20.9.0"

package/release/release-tool.js

@@ -14984,7 +14984,7 @@ init_define_CLI_LOCAL_EVALUATION_SUPPORT();
 
 // apps/cli/src/config.ts
 function getTemplateRef() {
-  return true ? "3cddb360660503325b24564820c78a2ad7ee1843" : "main";
+  return true ? "c616389550105d5a96d74501f77c6921aa79ecee" : "main";
 }
 
 // apps/cli/src/services/agentcore-config.ts
@@ -15182,6 +15182,13 @@ var TELEMETRY_ERROR_CODES = {
    * tell "the caller guessed a slug" from a malformed request.
    */
   PROJECT_NOT_FOUND: "PROJECT_NOT_FOUND",
+  /**
+   * `init --create` named a project the active organization already has.
+   * Distinct from {@link TELEMETRY_ERROR_CODES.PROJECT_NOT_FOUND}, which it was
+   * tagged as, so the dashboard counted a taken name as a missing project
+   * (PE-784).
+   */
+  PROJECT_NAME_TAKEN: "PROJECT_NAME_TAKEN",
   /**
    * `project select` persisted the record and the key-provisioning call did
    * not succeed. Buckets as `network` because that is what it almost always