mirror of
https://github.com/CopilotKit/CopilotKit.git
synced 2026-09-14 16:26:20 +08:00
codex/cloudplot-showcase-migration
15424 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Maxim
|
82c1c8e1fd |
feat(reskinnable-demo): add commerce's agent, a2ui trade brief and OGUI sandbox
The server half of the skin plus the two generated-surface paths. - `agent.ts` -- the server-safe `BuiltInAgent` factory. No "use client", no JSX, no React, so the server-only `agentRegistry` can import it. `id === skin id === agent id` is the only link between the skin and its agent. - `catalog/` -- the a2ui catalog and its renderers; `canvas-surface.tsx` and `report-data.tsx` render the server tool `render_trade_brief` full-region on the shared canvas; `build-brief-ops.ts` assembles the brief. - `design-skill.ts` and `sandbox-functions.ts` -- the OGUI brief and the functions exposed inside sandboxed iframes. Decisions: - THE PROMPT CARRIES A CLAUSE-TO-BEAT MAP. Most beats are enforced by prompt text, which makes an unlabelled prompt unreviewable: nobody can tell which clause is load-bearing for which beat, so nobody dares delete a line. The map is the fix. - THE SANDBOX REFUSES WHAT IT CANNOT SERVE. An empty snapshot returned on a failed read is indistinguishable from a genuinely empty ledger, and generated UI then renders a confident "no exceptions" screen. It now refuses instead. - Sandbox views SHARE THE APP'S SET PREDICATES rather than re-implementing them, so generated UI and the app agree on what "on hold" or "below floor" means. - The brief de-duplicates its a2ui selections; the same order appearing twice made the brief's counts wrong. - Beat 5's writes stay inside the view beat 3c built -- the agent may only write to rows the presenter's filters actually selected. Subsumes: ff8708651e 61a2404528 4067feadba e5efcac1a1 904ba72dcd Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
7050d655b3 |
feat(reskinnable-demo): add commerce's price sheet and beat 3d ingest
Beat 3d is "multimodal in, durable artifact out". For commerce the document is a vendor PRICE SHEET and the artifact is a filed restock plan. `data/price-sheet-pdf.ts` generates the PDF, `data/price-sheet-styles.ts` holds its typography, `/api/commerce/v1/price-sheet` serves it, `attach-price-sheet.ts` stages it onto the real composer so the pill's prompt rides with the attachment, and `/api/commerce/v1/plans` files the plan the ingest produces. Decisions: - COLUMNS ARE SET IN A MONOSPACED FACE. The sheet is a price table; proportional digits made the columns unreadable and, worse, made the demo's "read this document" claim look like a claim about a picture rather than about data. - The PDF's byte math assumes ASCII content. That was an unstated invariant holding up the whole layout; it is now pinned by a test rather than left to hold by luck. - EACH VENDOR IS QUOTED ONLY ITS OWN STYLES. The sheet leaked a second vendor's pricing into the first vendor's document -- correct-looking output, wrong data. - The cost narrative is DERIVED FROM the rows actually printed, so the prose under the table cannot describe a table that is not there. - The route fails LOUDLY. It no longer serves a zero-byte or partial PDF on an internal fault, and an empty `vendor` param is a refusal about the param rather than a 404 that reads as "no such vendor". - The beat-3d pill refuses to send its prompt when no price sheet is attached, and PROVES the attachment landed before claiming a send. Sending the prompt alone produced a confident answer about a document the agent never received. - A wrong restock plan is refused rather than filed. Subsumes: 6204113e8f 5bf498e850 ac0d1ff654 acec790481 cac652ff14 2d4ec6b76a 990c20b398 4dd3aff698 4c6690ea06 5e88b0640c Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
94f28eb4f3 |
feat(reskinnable-demo): add commerce's frontend tools, HITL and gen-UI cards
`tools.tsx` registers the skin's frontend tools, HITL interrupts, gen-UI cards and agent-context readables. Around it: `settle.ts` (the shared write-settlement narrator every card renders through), `refund.ts`, `teach-mode-directives.ts`, `order-queue-levers.ts`, `category-argument.ts` and `margin-summary.ts`. This is where beats 1, 3a, 3c, 8 and 9 are actually enforced on the client. Decisions: - HITL INTERRUPTS ARE ALWAYS SETTLED. Every path out of an interrupt resolves it, including the refusal and error paths -- an unsettled interrupt left the run wedged with a card that could never be dismissed. - A WRITE NEVER THROWS OUT OF ITS HANDLER. Failures come back as a refusal line the card renders, so a rejected write is visible instead of surfacing as an unhandled rejection in the console and a card stuck mid-render. - CARDS NEVER READ ARGS THAT HAVE NOT ARRIVED. Tool args stream; a card reading a half-streamed argument rendered a confidently wrong value. Cards now render a pending state until the argument they need is present. - The save-procedure card reports a DECLINE as a decline, not as a write. Claiming a write that never happened is the single worst thing a demo surface can do. - The recorded step count is reported FROM the recording rather than re-derived from the transcript, so the two cannot disagree. - Queue levers agree with the view: the lever chips describe the filters actually in force, not the ones the tool was asked for. - `category-argument.ts` refuses a category the model invented, so the margin ladder can never plot one that does not exist in the ledger. - `margin-summary.ts` caps its rows and SAYS what it left out. A silently truncated list is worse than a declared one, because the model cannot tell the difference. - The refund receipt's staleness wording was reconciled with the guarantee `settle` actually makes, and a blank record needle is refused instead of writing to row 0. Subsumes: 61d117bada 3eefc19766 f909cd2eee 5311f05d60 11779cd3f4 30d2413f4e dd370ef392 8814e78b20 f9cd20903a e3022a4228 b385b37764 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
bebc2d960d |
feat(reskinnable-demo): add commerce's REST API routes
`src/app/api/commerce/v1/*` -- one `ledger` snapshot read plus every write path the skin and its agent use: order patch, notes and notify; promotion approve and decline; return decision and refund; margin-waiver create and finalize. Together with the data layer they are what makes commerce REST-backed rather than in-memory, which is the point of shipping it beside the in-memory skins. Decisions: - A refund amount arriving as a string, `NaN` or a non-finite number is REFUSED at the boundary rather than coerced. `Number(body.amount)` turning `"12.oo"` into a refund is the failure this closes. - An UNREADABLE request body is told apart from a store fault: a malformed JSON body is the caller's error (4xx), a store failure is ours (5xx). Collapsing both into one status made a real backend fault look like a client typo. Subsumes: 3ed3b75581 f96c62870b Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
7be4079d74 |
feat(reskinnable-demo): add commerce's data layer and seeded ledger
The substrate under the commerce skin: `data/store.ts` (the in-process ledger the API routes mutate), `data/seed.ts` (the fixture the demo starts from), `data/types.ts`, `data/derive.ts` (every read-model the pages, tools, sandbox and a2ui brief share), `data/http.ts`, `data/find-record.ts`, `data/waiver-codes.ts`, `data/ledger-context.tsx` (the client-side `useCommerceLedger()` the skin uses in place of the contract's `useData`), and their tests. Decisions worth knowing, most of which are corrections to a first cut that looked right and was not: - ORDERS HAVE A REAL STATE MACHINE. Transitions are enumerated and illegal ones are refused at the store, not merely discouraged in the prompt. Beat-5 writes are validated against a CLOSED set for the same reason. - A MISSING MARGIN FLOOR IS `null`, NEVER `false`. A category can have no floor on file -- an unvalidated `/ledger` cast, a provider that mounts on a failed first fetch, a sandbox snapshot with no floors. In that state "is this below the floor?" has no answer, and `false` is the worst one available: it is indistinguishable from "checked, and it is fine" on the question the teachable gate is about. This is what `derive.FloorStatus` encodes. - THE UNLOCK MUST BE EARNED BY THE RIGHT PAPERWORK. A decoy waiver -- right shape, wrong subject -- no longer steals credit for another product's unlock, and a waiver filed AFTER the decision is refused rather than backdating it. The waiver must carry a real justification under a code from `waiver-codes.ts`. - PROTOTYPE KEYS. A record id named after something on `Object.prototype` no longer turns a failed write into a 200, and a blank needle is refused instead of resolving to row 0. - Promotion windows are compared DAY to DAY, not instant to day, so a promotion does not flip active state on a timezone boundary. - Refund rules: a refund on an UNDECIDED return is refused, and the refund guidance the UI shows agrees with the rule the store enforces (they disagreed). - Seed integrity: orders are numbered forward in time, `ret-2204` agrees with the order it returns, and there are enough exception orders that a `top=10` lever genuinely truncates -- otherwise beat 3c's top-N lever proves nothing on stage. - `ledger-context` refreshes are CANCELLABLE and honest: a caller can tell "done" apart from "done, but the screen is stale". Subsumes: a6d2104e2d bdf72fad7a c835259d20 b813f3cab0 55b5929b84 25c4f91b7e 2cf840a057 535cc82e96 b316977017 c1babd02bf 5855c9c6ab eb44916681 ed291d778f c3e9b27d46 6fb2f831d0 c2e0202a28 879c0c666a d0fddceb6e 1d71954555 b9a0516a6e Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
b115e58de4 |
feat(reskinnable-demo): add the commerce (Bellwether) skin
Adds a sixth skin to the reskinnable demo: `commerce` / "Bellwether", a storefront operations console for a DTC retail brand. It is REST-backed (over `/api/commerce/v1/*`) and demo-complete against all nine demo beats plus the presenter-reset requirement, which puts it alongside `banking` and `people` rather than the earlier wiring-only skins. Its teachable gate is approving a markdown that would trade BELOW the category margin floor (422 `BELOW_MARGIN_FLOOR`), unlocked by a margin waiver filed under a justifying code. This commit carries the bulk of the new skin: the four pages -- orders (index), catalog, promotions, returns -- and the components they are built from. The rest of the skin lands in the commits that follow, grouped by area of concern. SIGNATURE VISUAL -- the margin ladder. One rail per category, each anchored to that category's own margin floor, so "how far from the line I may not cross" is comparable across categories at a glance. The decisions inside it, all of which were wrong first: - Every floor line sits at ONE rail height, so the rails read as a set. The per-category floor is encoded by dot position, not by moving the line. - A dot that overflows its rail is never hidden. Hiding it lent the dot to the NEXT rail, silently misattributing a below-floor product to a compliant category. - Each below-floor label points at the dot it actually names. - An EMPTY ladder renders as "nothing plotted", not as an all-clear. Absence of data and absence of violations are different statements. - A category with NO margin floor on file renders as visibly UNCHECKED -- not green, not red, and not a bare figure in neutral ink, which reads as "checked, fine" on the exact question the ladder exists to answer. NAVIGATION -- orders is the reference for a four-lever view (beat 3c): status, exception class, sort and top-N all arrive from the query string and all four controls tint. The queue count is computed against the filters actually applied rather than the unfiltered set, and an unusable top-N lever is ignored instead of collapsing the view to a single row. WRITES -- the pages share one in-flight guard, extracted out of the orders page into `components/use-in-flight.ts`, so a control cannot fire twice or latch. The order queue guards per ROW, not per page, so one row's write does not freeze the others. Refusals returned by the write routes are surfaced on screen instead of being swallowed, and each page's on-screen readable describes the screen it is actually on rather than a generic skin summary. Note for reviewers: `1ad9711d98` created files across every area below; it is cited here once so each original SHA appears in exactly one body. Subsumes: 1ad9711d98 d52b4373ac 92159da17b 737e788fc3 441ce536de 6e8a02c029 6c7bd27cb6 4173278545 7a4c927da9 9a53d5712f 127190449d fefb43c16c 02638a398d c3a07fcd06 e793b652a6 094b4a6e4b 9663656e99 ed6969683e Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Sam Julien
|
6540848745 | chore: refresh agent artifacts for 1.67.1 | ||
|
Sam Julien
|
1853a24d00 | fix(skills): align public guidance with current APIs | ||
|
Sam Julien
|
73d1df29a2 | feat(release): add a generated public API manifest | ||
|
Sam Julien
|
00d800dc2b | fix(docs): enforce the production canonical host | ||
|
Tyler Slaton
|
bee39139bd |
chore: release monorepo v1.67.1 (#6449)
## Release monorepo v1.67.1 **Scope:** `monorepo` | **Bump:** `patch` --- ### How this release process works 1. **This PR was created automatically** by the "release / create-pr" workflow. It bumped the `monorepo` packages to `1.67.1` and generated AI-enhanced release notes. 2. **CI runs on this PR** — the full test suite (unit tests, lint, type checks, build) must pass before merging. This is the review gate. 3. **Review the release notes** in `release-notes.md` in this PR. If a Notion draft was created, you can edit the release notes there before merging. 4. **When this PR is merged**, the `release / publish` workflow automatically: - Builds all packages - Publishes the `monorepo` packages to npm at version `1.67.1` - Creates git tag `monorepo/v1.67.1` - Creates a GitHub Release with the final release notes ### Before merging - [ ] CI is green (tests, lint, types, build) - [ ] Version bumps look correct - [ ] Release notes are accurate (edit in Notion if a draft was created) --- > **Do not merge until CI is fully green.** The full test suite runs automatically on this PR.v1.67.1 |
||
|
Maxim
|
b4cfcf6f98 |
fix(react-core): stop the purity gate crashing opaquely on the declared Node floor
`assert-headless-purity.mjs` resolved its dist directory with
`import.meta.dirname`, which landed in Node 20.11 and is `undefined` below it.
The root package.json declares `engines: { "node": ">=18" }`, so a contributor
or runner on Node 18 hit this hard-fail CI gate as:
TypeError [ERR_INVALID_ARG_TYPE]: The "paths[0]" argument must be of type
string. Received undefined
at Object.resolve (node:path:1115:7)
at .../scripts/assert-headless-purity.mjs:71:19
— a stack trace into node internals, at module load, that names neither the
gate nor the real problem. Reproduced against a real Node 18.20.8.
Switch to `path.dirname(fileURLToPath(import.meta.url))`, which both sibling
scripts in this CI job already use (react-core's measure-copilotchat.mjs and
react-native's measure-headless.mjs), so all three read the same and none of
them carries a hidden runtime floor its own package does not declare.
Verified under real Node 18.20.8: the script now walks all four entries (650 /
646 / 649 / 645 modules) and exits 0, and still exits 1 with the full
`links the heavy render stack` report when a forbidden dep is injected into a
dist entry. The metafile-driven graph walk, the loud failure on unresolvable
edges and all 17 negative tests are untouched (`test:scripts`: 19 pass).
Skill-staleness check (reskinnable-demo CLAUDE.md rule): not applicable — this
touches packages/react-core, nothing under .claude/skills/reskin/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
4b25cf34b8 |
test(react-native): stop the entry guard racing its own module load
The #4893 entry-surface guard timed out nondeterministically at full test parallelism ("Test timed out in 5000ms" on `await import("../headless")`), which four independent agents each worked around with --testTimeout or --maxWorkers=2. A flaky hard gate is a gate people learn to ignore. Measured, not guessed. The import is a one-time module-graph load whose VARIANCE — not its mean — broke the default budget: ~0.7-1.1s for this file alone and ~0.9-1.8s inside the full 22-file suite (n=8 each), but 4568ms on the run straight after a cold `nx build`, i.e. 91% of the 5000ms budget spent on an otherwise idle machine. The cost is resolve/transform plus cold-page- cache I/O over the ~283 KB of workspace dist that vitest.config.mjs inlines via `server.deps.inline: [/@copilotkit/]` (core ~218 KB, react-core v2/headless ~55 KB, v2/context, shared); bare-Node `import()` of the equivalent prebuilt dist is 461ms, so evaluation is not the expensive part. Four separate tests each awaited that same import, so all four raced one cost against one budget — and when the first lost the race the other three inherited its in-flight import and timed out with it, which is why the observed signature was three simultaneous failures rather than one. They now share a single explicitly-budgeted `beforeAll`, so the cost lives in exactly one place and each test reports ~0ms. The hook is nested rather than top-level on purpose: its failure domain must cover only the tests that need the module, or an import failure would take down the fs-only graph tests too — the same blast-radius problem as blind spot #4, just relocated into a hook. No assertion is weakened: comment stripping, import()/require() extraction, the exact resolved-graph pin and the revived existence test are untouched, and the guard still fails on a real violation (injecting a lazy `import("@copilotkit/react-core/v2")` into src/streaming-fetch.ts trips 3 assertions; reverted). Verification: 5 consecutive full-suite runs at DEFAULT parallelism, no --maxWorkers or --testTimeout override, 271/271 passing in 3.97-5.87s wall each; plus 3 concurrent full suites (30 workers on 10 cores) all green, and one pass at load average 235. `check-types` clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
e7f3d7644d |
fix(react-core): make the #4893 purity gate scan the graph it claimed to scan
`scripts/assert-headless-purity.mjs` is a hard-fail CI gate, and it did not do what its header said. It read four built entry files and asked `code.includes(dep)`. That is weaker than the claim in both directions, and every item below was reproduced against a real build before this rewrite: 1. It never followed an edge out of those four files. Re-exporting one hook from the fat `@copilotkit/react-core/v2` entry — which links shiki, mermaid, cytoscape, katex and streamdown — left `dist/v2/headless.mjs` importing that entry by name, and the gate printed "clean" for all four files, exit 0. Same for a heavy dep reached through `@copilotkit/core`, which is external to this build: the entry says only `from "@copilotkit/core"` and there is nothing to grep. A split-out relative chunk escaped identically. 2. The header claimed the check "follows into node_modules". It followed nothing — not node_modules, not a relative sibling chunk. 3. `code.includes(dep)` is unanchored, so it matched comments and strings. Not hypothetical in either direction: the built artifact is comment-PRESERVING (233 lines of block comments survive in dist/v2/headless.mjs), and the five banned tokens sit in `src/v2/headless.ts`'s own banner. They are absent from dist only because that module is a re-export shell whose banner attaches to no retained code — moving the same sentence into a module that ships code hard-failed CI on all five tokens while linking none of them. The gate now drives esbuild with `metafile: true` over each built entry and matches on the RESOLVED graph, so it follows relative chunk edges and into node_modules for real, resolves `exports` maps, subpaths and pnpm symlinks, and cannot be fooled or tripped by a comment. Matching is anchored at the package name (`@shikijs/langs` and `cytoscape-fcose` count; `shikimori` does not) and also covers a forbidden dep left external, which resolves to no graph input at all. Unresolvable edges FAIL LOUDLY instead of reading as clean, as does a graph that does not contain its own entry. One edge shape survives a bundler: `import(name)` with a non-literal argument, which esbuild leaves alone without even warning. For that the gate reads text — the only place it does — over the graph's first-party files, using the `stripComments` helper ported from the sibling RN guard so a documented counter-example cannot trip it. Adds `scripts/__tests__/assert-headless-purity.test.mjs` (17 tests, wired into `test:scripts` next to measure-copilotchat's), because a hard-fail gate with no coverage of its own failure mode is how this shipped. Proven after the fix: both false negatives now exit 1, a clean build exits 0, and a banned token that appears only in a comment exits 0. esbuild is already this package's devDependency and already runs in the same CI job, so the gate needs no workflow change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
60d3ef1071 |
fix(react-native): externalize react-dom in the headless size measurement
The esbuild `external` list omitted `react-dom`, unlike react-core's measure-copilotchat.mjs, so a stray web-oriented edge could be absorbed into the figure the PR's bundle claim rests on. Checked empirically before changing anything: `react-dom` is NOT reachable from @copilotkit/react-native/headless today. A metafile run shows 0 of the 653 input modules are react-dom, and no module references it even pre-resolution. The reported figure is therefore UNCHANGED — 94941 B gzip (92.7 kB) before and after, byte for byte. The headline "92.8 kB -> 92.7 kB, flat" claim is unaffected and stays comparable with previously reported numbers. The guard is still worth having. Simulating a stray edge measures the inflation it prevents: +56.3 kB gzip via react-dom/client, +57.3 kB via react-dom/server (not the ~130 kB estimated in review — that is closer to the raw magnitude; react-dom-client.production.js is 536 kB raw). The subtler case is a bare `react-dom` edge at +1.4 kB, small enough to read as noise while still being a real regression. No subpath entries: esbuild prefix-matches package paths, so `react-dom` already covers react-dom/client and react-dom/server (verified on the pinned 0.27.3; esbuild CHANGELOG 0.5.14 and 0.14.13). Listing them would imply they were required. Hoisted the list to an exported HEADLESS_EXTERNAL with per-entry rationale, mirroring the sibling's DEFAULT_EXTERNAL, and made `external` an overridable option so the new test can A/B it rather than assert on a literal. Both new tests fail if react-dom is removed from the list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
4315adb1e7 |
test(react-native): make the tool-result assertions read the result
Two tests claimed to prove a tool RESULT reaches its renderer and neither
read it. "reports complete and passes the result through" rendered through a
registrar printing only status and args, so replacing the correlated tool
message's content with a constant left it green; its in-place-mutation twin
had the same hole. The integration test's only result assertion built its
tool message as `{ content: "ok" }` behind an `as never`, so it carried no
toolCallId — the id production correlates a result to a call by.
Both now render status, args AND result together, and a new negative case
gives a tool call a result belonging to a DIFFERENT call. That last one is
the only detector for a lookup that ignores the map key: every fixture in
the file matched on id, so an unkeyed "hand out any tool result we have"
lookup passed the whole suite unchanged.
Fixtures move to src/__mocks__/tool-fixtures.ts. toolMessage() takes
toolCallId as a required positional argument, so no fixture can omit the
correlation, and assistantToolCall() returns a typed AssistantMessage —
which retires the `as never`, an `as unknown as Message`, and three `any`s
in the touched files. A properly-typed ToolMessage typechecks at that call
site unchanged; the cast was convenience, not a type-system limit.
Test-only: CopilotChat.tsx is untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
d144757d8a |
test(react-native): guard the entry surface's export kinds against type-only stripping
`export type { X }` strips X's runtime binding. Five runtime values shipped from
`src/headless.ts` inside `export type` blocks — the `ToolCallStatus`,
`UseAgentUpdate`, `CopilotKitCoreErrorCode` and
`CopilotKitCoreRuntimeConnectionStatus` enums, and the `AbstractAgent` class —
while the reference docs told consumers to import and branch on them. Nothing in
the repo could see it: the package built, typechecked, linted and passed its
suite, because nothing here consumed its own entry the way a consumer does.
react-core's `headless-type-exports.test-d.ts` cannot cover this. Export kind is
a property of the re-exporting module, and that guard reads react-core's entry —
react-core's own `UseAgentUpdate` was already a correct value export while RN's
was wrong. The guard has to live on the RN side and read RN's own entries.
Adds `src/__tests__/headless-value-exports.test.ts`, in three layers:
- §1 asserts each of the five is a present runtime binding of the expected
`typeof`, with its enum members nameable, on BOTH `@copilotkit/react-native`
and `@copilotkit/react-native/headless`. A stripped export is an absent module
binding, so a runtime test is the direct instrument and cannot be faked by a
cast or an expect-error.
- §2 needs no symbol list: it parses both entry sources, and for every symbol
re-exported type-only it imports the module that symbol came from and fails if
that module has a runtime binding for it. A future contributor who adds a new
enum re-export inside an `export type { … }` block is caught without anyone
updating §1, and the failure names the symbol, the source module and the fix.
A floor on the parsed specifier count keeps a rotted parser from passing
vacuously.
- §3 type-checks the consumer-visible symptom (enum-member comparison on a
render-prop `status`, `extends AbstractAgent`, `instanceof`). The file lives
under `src/`, so `check-types` compiles it and a regression also fails there
with TS1362 naming the symbol. Its bodies are lazy on purpose: a module-scope
`extends` would crash collection and hide §1/§2's guided messages.
Proven by transiently restoring the defect three ways — the `AbstractAgent`
class, `ToolCallStatus` moved into an `export type` block, and `UseAgentUpdate`
via the inline `type ` prefix. Each produced 4 failing tests plus TS1362;
`src/headless.ts` is byte-identical to before.
RN suite 23 files / 276 tests (baseline 22 / 261, so +15 and no change
elsewhere); `nx run @copilotkit/react-native:check-types` clean; oxfmt and
oxlint clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
5a6bf1dc2b |
test(react-core): make the headless type guard actually detect type drift
`headless-type-exports.test-d.ts` asserted nothing. Its only check was a
value-position annotation (`const inProgress: RendererProps = { … }`), which is
an assignability check, so degrading `RendererProps` to `any` produced zero
`tsc` errors. And `status` was pinned through a force-cast
(`"inProgress" as RendererProps["status"] & "inProgress"`), which collapses to
whatever the left side already is and suppresses the comparison outright.
Verified against the live divergence the guard exists to catch: changing
`ReactToolCallRenderer["render"]`'s `status` from the `ToolCallStatus` enum
members to bare string literals produced six errors in unrelated files and
ZERO in the guard file. Those six are incidental to this package — React
Native, the consumer this contract protects, has no such incidental users, so
on that side the drift would have been entirely silent.
Rewritten on `expectTypeOf` (already the type-assertion idiom here, see
`hooks/__tests__/use-agent-types.test.tsx`), with every positive assertion as
`toEqualTypeOf` — exact type identity, no assignability, no `as` casts. The
expected props union is spelled out independently of the type under test so the
comparison is a real detector rather than a tautology. Now pinned: the exact
props union, an explicit `not.toBeAny()` tripwire, the arm keys (`args`, not
`parameters`), and `status` as the enum in both directions.
Also pins the known divergence between react-core's two same-named public
types — the canonical renderer props (`args`, `ToolCallStatus`) and public
`RenderToolProps` (`parameters`, string literals) — as a change-detector, so
converging them becomes a deliberate, visible edit instead of silent drift.
Proven by re-applying each degradation and confirming `tsc` fails: `any` (4
errors), the enum → literal drift (3), `status` → `string` (2), `args` →
`parameters` (2), and export removal (TS2305). All proof mutations reverted.
Coverage note: this guard canNOT catch the RN `export type`-on-a-value bug.
That failure is invisible to `tsc` by construction, and it lives in react-native's
entry, which no react-core assertion can reach. It needs a runtime guard in
that package — react-core's equivalent is the sibling runtime test
`headless-exports.test.ts`.
The file is read by `tsc` only (tsconfig includes `src/**/*`); vitest's
`include` globs do not match a `.test-d.ts` basename and the package sets no
`test.typecheck`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
63a1c94fbb |
fix(react-native): make the headless size measurement fail loudly, not print 0.0 kB
measure-headless.mjs prints the number the PR's bundle claim rests on, and it had three ways to report a broken run as a good one. All three reproduced: 1. No zero-output guard (the react-core sibling has one). A run whose bundle collapses to nothing measures ~20-35 B of gzip envelope, prints "0.0 kB" and exits 0 — reported into the CI job summary as a spectacular win. Note a zero-ONLY guard would not have caught the reproduction (35 B, not 0), so this adds a plausibility FLOOR of 8 kB alongside the zero check: ~11x below the real 92.7 kB, so legitimate size work can never trip it. 2. `logLevel: "silent"` discarded `result.warnings` and there was no try/catch, so esbuild resolution problems escaped as an unhandled rejection printing esbuild's internal frames and `errors: [Getter/Setter]` instead of the messages. Silent is kept (as in the sibling) so stdout stays the single figure line CI quotes; warnings are now formatted to stderr and errors are re-thrown with esbuild's own formatted diagnostics. 3. An unbuilt dist died on a raw "Could not resolve" stack. A preflight on dist/headless.mjs now names `npx nx run @copilotkit/react-native:build`, and the catch adds the same hint when the entry specifier is what failed. The measurement itself is untouched — same esbuild options, same synthetic entry, same six symbols, same external list — and still reports 92.7 kB, so comparability across PRs is preserved. A moved figure would have meant the measurement changed rather than its guards. Also adds the test hook RN lacked, mirroring react-core exactly: scripts/__tests__/measure-headless.test.mjs under `node --test`, wired as `test:scripts` and chained into `test`. Coverage targets the failure modes, not the happy path. Both packages' vitest `include` globs are scoped to `src/**`, so the .mjs test cannot collide with the jsdom setup — the reason the sibling runs under node --test in the first place. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
0ea71fc684 |
test(react-native): make the #4893 entry guard see what it claimed to see
The headless-entry import-graph guard was weaker than the PR claimed. Four
blind spots, each verified to let a real violation pass (or to flag a
non-violation), each now covered by a test:
1. Only `import … from "x"` was matched, so a lazy optional-peer
`require("@copilotkit/react-core/v2")` or `await import(…)` — which Metro
follows and bundles identically — defeated the guard entirely. Static,
bare side-effect, dynamic `import()` and `require()`/`require.resolve()`
are all extracted now, and a loader whose argument is not a string
literal is reported as unanalyzable rather than silently skipped.
2. Matching ran on raw text, so doc comments counted as imports. Not
hypothetical: the guard was harvesting EIGHT specifiers
(`@copilotkit/react-native`, `…/headless`, `…/polyfills` and its five
subpaths) that no source file imports — half the reported bare-specifier
set — purely from JSDoc examples. In the other direction, writing a
"don't do this: import from @copilotkit/react-core/v2" counter-example
in a doc comment failed the build. Comments are stripped first now, via
a single left-to-right pass that matches string/template literals with
the same alternation so a `//` inside a string stays a string.
3. `resolveLocal` returned null for an edge it could not resolve and the
caller dropped it, so an unresolvable specifier read as "clean" while
hiding the whole subgraph behind it. Proven: a real
`export … from "@copilotkit/react-core/v2"` reached through an ESM-style
`"./probe-heavy.js"` edge passed the old guard. Emitted-extension
specifiers now resolve, and anything still unresolvable FAILS LOUDLY
instead of vanishing. The resolved file set and bare-specifier set are
also asserted EXACTLY, so a new edge has to be looked at deliberately
rather than only being caught if someone thought to deny-list it.
4. The graph was walked in the `describe` body, so a missing entry file
threw at collection time and every test in the file — including the one
asserting the entry exists — never ran (`Tests no tests`). The walk is
lazy and memoized per entry now, and the existence assertion reports.
Every fix was proven by mutation in both directions: the violation passes
the old guard, fails the new one, and clean source still passes. Also drops
`localFiles`, which no test ever read.
Scope note: the ~5s `await import("../headless")` timeout flake in this
file is deliberately untouched — it is owned separately. Runs used
`--testTimeout=60000`.
RN suite 267 passed / 22 files (was 261; +6 new tests);
`nx run @copilotkit/react-native:check-types` clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
025b8d5979 |
test(react-native): make the useRenderTool suite detect its own forwardings
`useRenderTool` is a thin forwarder onto react-core's `useFrontendTool`, and its suite mocked exactly that hook. The double only modelled `name` and `render`, so deleting the `deps`, `handler` AND `agentId` forwarding from the hook each left the suite fully green — it could not detect a regression in any of the three things the hook exists to forward. Drop the four `vi.mock` blocks and drive a real `CopilotKitCoreReact` through the shared `TestCopilotKit` harness, the way the sibling `render-tool-call.integration.test.tsx` already does, then assert on core's own observable behaviour instead of a mock's call arguments: - handler — `core.runTool()`, i.e. core's real `executeToolHandler` path, so the handler is proven to RUN and its return value proven to become the tool result - agentId — the tool resolves for its agent and must NOT resolve as a global tool, and the renderer entry carries the agentId that keys it - deps — a render closure over a serialisable dep re-registers and the PAINTED text changes, observed through react-core's real `useRenderToolCall` Each mutation now fails exactly one test. Also pins the documented sharp edge that `useFrontendTool` compares deps with `JSON.stringify`, so a function dep collapses to a constant and can never re-register — a test asserting otherwise would assert a behaviour the code cannot deliver, and pinning it makes a change of comparator fail loudly. Test-only: `useRenderTool.ts` is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
63e7fa7fda |
fix(react-native): make the chat list's extraData contract true and explicit
CopilotChat's `extraData` memo carried a comment claiming it held "the exact
inputs renderItem reads", but it listed only { isRunning, renderToolCall,
toolMessages } while renderItem also read `listItems` — it answered "am I the
last row?" by index-reading the array's tail, and depended on `listItems` in
its own useCallback deps. The comment was false and the stated
row-memoisation contract was incomplete.
The defect is documentation and fragility, NOT observable behaviour. Verified
against the real react-native 0.85.2 sources in the pnpm store:
- FlatList is a PureComponent (Libraries/Lists/FlatList.js:307), and `data`
is one of the props it shallow-compares. `data={listItems}` is the same
reference, so any rebuild of `listItems` re-renders FlatList on its own.
- In the default non-strictMode path FlatList's render() uses `this._renderer`
rather than `this._memoizedRenderer` (FlatList.js:682), allocating a fresh
`renderProp` on every render, which is handed to every cell.
- VirtualizedList._pushCells passes that `renderItem` plus `item` to each
CellRenderer, which is itself a PureComponent
(VirtualizedListCellRenderer.js:63). `extraData` is NOT a cell prop.
- The `listItems` memo allocates fresh item objects on every rebuild, so each
cell's `item` prop also differs. Cells therefore invalidate through
`data`/`item` even under the narrowest path (strictMode with a memoizeOne
hit on renderItem and extraData).
So no stale last-row / stranded-loading-indicator state is reachable, and no
covering test is added: the behaviour is unchanged, and the package's test
FlatList is a mock that re-invokes renderItem for every row on every parent
render, so it cannot express cell memoisation in the first place.
Instead, make the contract honest. The tail id becomes a named `lastItemId`
memo; renderItem reads that scalar and deps on it rather than closing over
`listItems` and indexing it; `extraData` now lists exactly the four values
renderItem closes over, and the comment states why `listItems` is absent
(it is the `data` prop, which already invalidates cells). As a side benefit
renderItem's identity is now stable across `listItems` rebuilds that do not
move the tail.
Call-Site Enumeration (Procedure 2 step 8):
- `extraData` — grep over packages/react-native/src shows exactly two sites,
the memo itself and the `extraData={extraData}` prop on the list. No test
and no other module reads its keys. A caller-supplied `FlatListComponent`
(the documented BottomSheetFlatList case) receives it, but RN treats
extraData as an opaque re-render marker and never inspects its shape, so
adding `lastItemId` is not observable to any consumer.
- `renderItem` / `lastItemId` — local to CopilotChat; neither is exported.
- `isLoading` on AssistantMessage — value-identical by construction, since
`lastItemId` IS `listItems[listItems.length - 1]?.id`.
- No change to CopilotChatProps or to any entry-point export.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
7baed27370 |
fix(react-native): export the headless entry's runtime values as values
`src/headless.ts` re-exported five runtime values inside `export type { … }`
blocks. A type-only re-export strips the runtime binding, so the symbol is
unimportable and — for the enums — the field it types cannot be compared
against at all, because an enum-typed field rejects a bare string literal.
`RenderToolProps["status"]` is `ToolCallStatus`, so a consumer of this PR's own
render-prop contract had no working way to branch on `status`.
Determined empirically, not by reading: a throwaway probe imported all 32
re-exported symbols as values under the package's real tsconfig. The 27 that
are genuine types reported TS2693 ("only refers to a type"); five did not, and
those five are the ones moved. Declaration sites confirm each:
ToolCallStatus packages/core/src/types.ts:14 export enum
CopilotKitCoreErrorCode packages/core/src/core/core.ts:99 export enum
CopilotKitCoreRuntimeConnectionStatus packages/core/src/core/core.ts:320 export enum
UseAgentUpdate packages/react-core/src/v2/hooks/use-agent.tsx:13
export enum
AbstractAgent @ag-ui/client declare abstract class
Nothing else changed kind: Suggestion, FrontendTool, Message, ToolCall,
ToolMessage, AgentCapabilities, ResumeStatus, Interrupt, ResumeEntry, the
Interrupt*/RenderTool*/Thread*/CopilotChat* prop and config types,
ReactFrontendTool, ReactHumanInTheLoop, ReactToolCallRenderer and
CopilotKitContextValue are all genuine types and stay `export type`.
`src/index.ts` does `export * from "./headless"`, which republishes values and
types alike, so both published entry points are fixed. Verified in the built
output: all five appear without a `type` prefix in dist/headless.d.mts and
dist/index.d.mts, and as runtime bindings in headless.mjs, index.mjs and
index.cjs.
Negative control: with the pre-fix headless.ts the same probe produced ten
TS1362 errors ("cannot be used as a value because it was exported using
'export type'") across both entries; with the fix, zero.
This makes the already-merged docs on this branch true. The RN reference pages
write `import { ToolCallStatus } from "@copilotkit/react-native"` and
`status === ToolCallStatus.Executing` (useRenderTool.mdx:170, useFrontendTool.mdx:129,
useHumanInTheLoop.mdx:86) and `import { useAgent, UseAgentUpdate }` with
`updates: [UseAgentUpdate.OnMessagesChanged]` (useAgent.mdx:234). None of those
imports resolved before this commit.
AbstractAgent is a deliberate inclusion, not scope creep: it is a runtime class
and the AG-UI extension point consumers subclass, and @ag-ui/client is a
dependency of this package rather than a peer, so a consumer cannot reliably
import it from there directly. It carries no bundle cost — the headless entry
already imports @ag-ui/client transitively through
@copilotkit/react-core/v2/headless, and esbuild tree-shakes an unused
re-export, so scripts/measure-headless.mjs still reports 92.7 kB gzip.
Forced test change, in scope only because the fix causes it: the value
re-export makes headless.ts the first runtime importer of @copilotkit/core in
this package's graph, so `import "../index"` now evaluates real core, which
named-imports RUNTIME_MODE_SSE and friends from @copilotkit/shared.
headless-integration.test.tsx replaced that module wholesale with a two-key
factory, so the import threw. Fixed by spreading importOriginal() instead of
replacing — the form vitest's own error message prescribes — leaving
createLicenseContextValue the only stubbed member. No assertion, case or
coverage changed.
Call-Site Enumeration (Procedure 2 step 8) — `grep -rn` per symbol across
packages/ plus every importer of @copilotkit/react-native in the repo. Every
site holds, because type -> value is a widening: an `import type` of a value
export is still legal.
ToolCallStatus
packages/react-native/src/headless.ts:94 — the changed export. Holds.
No other site in packages/ or examples/ names it. Nothing imported it
before, which is the bug.
CopilotKitCoreRuntimeConnectionStatus
packages/react-native/src/headless.ts:95 — the changed export. Holds.
No other site.
CopilotKitCoreErrorCode
packages/react-native/src/headless.ts:96 — the changed export. Holds.
CopilotKitProvider.tsx:12,37 / CopilotChat.tsx:13,93 / CopilotPopup.tsx:26,223
— all `import type … from "@copilotkit/core"`, used only in a `code:` field
position. They import from core directly, not through this entry, and a
type position is unaffected by the re-export kind. Hold.
UseAgentUpdate
packages/react-native/src/headless.ts:65 — the changed export. Holds.
packages/react-core/src/v2/headless.ts:41 — already a value export there,
with a comment giving this exact reason; this commit makes RN agree with it
rather than diverge. Holds.
AbstractAgent
packages/react-native/src/headless.ts:107 — the changed export. Holds.
packages/react-native/src/__mocks__/test-copilotkit.tsx:22,41,42 — already
imports the class as a VALUE from @ag-ui/client and subclasses it, i.e. it
had to bypass this entry to do what the entry now permits. Unchanged and
still passing. Holds.
packages/react-core/src/v2/**, packages/channels-telegram/** — all import
from @ag-ui/client directly; none route through @copilotkit/react-native.
Hold.
Importers of @copilotkit/react-native outside the package
examples/v2/react-native/demo/{App.tsx,src/ChatScreen.tsx,index.js} — import
CopilotKitProvider, useAgent, useCopilotKit, useFrontendTool and the
polyfills entry. None of the five symbols appears anywhere in the demo, so
nothing to break; the demo is now able to import them. Holds.
Surface guards
src/__tests__/headless-entry-surface.test.ts — its `not.toHaveProperty`
denylist covers the chat/attachment exports and the two removed registry
symbols; none of the five is listed, and its bare-specifier bans
(@gorhom/bottom-sheet, expo-*, shiki/mermaid/katex/a2ui-renderer, non-headless
react-core entries) are unaffected by adding @copilotkit/core and
@ag-ui/client edges. Passes unchanged.
Verification: `pnpm nx run @copilotkit/react-native:check-types` succeeds
(tsc --noEmit, 0 errors). `npx vitest run --reporter=dot` — 22 files, 253
tests, all passing. `npx oxfmt --check` clean; `npx oxlint` 0 errors and 2
warnings, both pre-existing in the touched test file (no-shadow on a mocked
`React`, no-this-in-sfc).
Note on a pre-existing flake: headless-entry-surface.test.ts hits the 5000ms
default testTimeout on `await import("../headless")` when the machine is loaded.
Measured 6 serial runs each way on the same box — pre-fix headless.ts failed
4 of 6, post-fix 3 of 6, identical timeout signature — so it predates this
change and is load-induced, not caused by it. Every run above used
`--testTimeout=60000`; raising that default (or making those assertions
static) is worth a follow-up, and is not this commit's to make.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
tylerslaton
|
10d8f43829 | chore: release monorepo v1.67.1 | ||
|
Maxim
|
5c09f51967 |
fix(react-native): stop a tool result RN cannot type from reading as empty
`toolMessages` rebuilt every tool message with `content: typeof m.content === "string" ? m.content : ""`, so any non-string content became `""` — indistinguishable from a tool that genuinely returned nothing, with nothing logged. Renderers receive `result: string` and cannot tell the two apart. Static typing says the branch is unreachable: `ToolMessageSchema.content` is `z.string()`, the SSE transport zod-parses every TOOL_CALL_RESULT before it reaches `agent.messages`, and core stringifies non-string handler results itself (`JSON.stringify(result)`, run-handler.ts:831/1014) before inserting the tool message. So this is a defensive branch, not a live data-loss path — but core keeps the same hedge (`normalizeToolResultContent` accepts `unknown` and unwraps arrays of text parts), because unvalidated producers exist: restored thread history, a non-SSE transport, and app code casting on `addMessage`. Rather than delete the branch, make it loud and lossless: serialise non-string content the way core already represents non-string results, and warn in dev (`__DEV__` guard, matching src/CopilotChat.tsx and streaming-fetch.ts). null/undefined still render as `""` — nothing to lose — but now warn instead of passing silently. Never throws from the render path. Call-Site Enumeration (semantics of ToolMessage.content in RN's map): - Producer: the `toolMessages` memo, packages/react-native/src/components/CopilotChat.tsx. Module-local const; no other module imports it. - In-file consumers: the `extraData` memo (map identity only, never reads content) and `renderItem`, which passes `toolMessages.get(tc.id)` to `renderToolCall`. - react-core: `useRenderToolCall` (packages/react-core/src/v2/hooks/use-render-tool-call.tsx) forwards `toolMessage.content` as `result` (:53) and compares it in the memo comparator (:91-93). Both still receive a string. - Downstream: app renderers registered through RN's `useRenderTool` -> `useFrontendTool`, typed by `ReactToolCallRenderer` whose Complete branch declares `result: string`. That contract is unchanged. - Behaviour delta is confined to non-string content; the string path is byte-identical, and `""` stays `""` and stays silent. Tests: 6 cases in CopilotChatToolCalls.test.tsx cover verbatim strings, an empty result staying empty and silent, array/object serialisation with one warning, null warning, and non-serialisable content not throwing. RN suite 259/259, check-types clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
77ed31c437 |
fix(react-native): key the chat's message memos on content, not array identity
`CopilotChat` derived both `toolMessages` (toolCallId -> ToolMessage) and `listItems` from `useMemo(..., [messages])`, where `messages` is `agent.messages`. That dependency never changes on the path the memos exist to serve, so the headline fix of this PR was inert: - Core inserts tool results by MUTATING IN PLACE — `agent.messages.splice(insertAt, 0, toolMessage)` (packages/core/src/core/run-handler.ts:931, :1080). Nothing in production reassigns `.messages`; grepping for that assignment in packages/core/src hits test files only. - `AbstractAgent.addMessage` is a `this.messages.push(...)`, and AG-UI's apply pipeline reassigns the SAME array object for the whole run, so identity changes at most once per run and then never again. - `useAgent` re-renders with a bare `forceUpdate()` on `onMessagesChanged` (packages/react-core/src/v2/hooks/use-agent.tsx:385-397); it does not hand down a new array either. Net effect: both memos froze at whatever the first render of a run saw. Tool renderers kept receiving `result: undefined` with a status that never reached `complete`, and any assistant message or tool call appended mid-run never reached the flat list at all (`listItems` only ever recomputed when `isRunning` flipped). Both memos are now keyed on a lightweight content fingerprint — ids, roles, content length, `toolCallId`, and tool-call ids plus argument lengths — mirroring react-core's web `messagesMemoKey` (packages/react-core/src/v2/components/chat/CopilotChat.tsx:983). Length rather than value so large text and base64 attachment payloads are not re-serialized every render, and the fingerprint is recomputed per render so typing in the composer still does not rebuild the transcript. Why 253 tests were green over this: every RN chat suite drives messages by re-rendering `TestCopilotKit` with a NEW array, which DOES change identity, so those tests pass regardless of the dependency. The two added tests mutate in place through `agent.addMessage` instead — the same push core's paths bottom out in — and fail against the pre-fix source: AssertionError: expected 'inProgress:Rooftop' to be 'complete:Rooftop' TestingLibraryElementError: Unable to find an element by: [data-testid="places"] `TestCopilotKit` gains an optional `agentRef` prop to publish the stable agent so a test can reach that path. Call-Site Enumeration - `TestCopilotKitProps` (new OPTIONAL `agentRef`; no existing site needs a change): - packages/react-native/src/components/__tests__/CopilotChatToolCalls.test.tsx (10 uses) - packages/react-native/src/hooks/__tests__/render-tool-call.integration.test.tsx (3 uses) - no other `<TestCopilotKit` in packages/, examples/ or showcase/ - `messagesFingerprint`: new module-private helper, 1 definition + 1 call, both in packages/react-native/src/components/CopilotChat.tsx. Not exported. - No public RN export or `CopilotChatProps` field changed; `extraData` and `renderItem` keep their existing shapes and pick the corrected values up through their existing deps. Verification: @copilotkit/react-native 255/255 tests in 22 files; `tsc --noEmit` clean. Left untouched by design: the non-string tool-content coercion and `extraData` omitting `listItems`, both owned by other changes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Ben Taylor
|
800846d918 |
chore: remove unreferenced root assets (#6448)
Removes four files under `assets/` that nothing in the repo references. Together they are ~56 MB of git-LFS payload that every fresh clone pays for. | File | Size | Status | | --- | --- | --- | | `assets/demo.gif` | 17.4 MB | Last referenced by `README.md` until `446ad06afc` (2023-11-29) removed the `<img src="./assets/demo.gif">` tag | | `assets/animated-banner.gif` | 26.2 MB | No reference in the tree | | `assets/travel-planner-gif.gif` | 12.6 MB | No reference in the tree | | `assets/proejct-perplexity-clone.png` | 173 KB | No reference in the tree; filename also carries a `proejct` typo | `assets/license-badge.svg` is the only remaining asset referenced from the repo (`README.md:30`) and is untouched. Credit to @VZBYang, who identified `assets/demo.gif` in #4314. That PR carried 746 commits not in `main` (234 merges plus 512 commits whose subjects are absent from `main`), and with squash and rebase both disabled on this repo there is no way to land it without grafting all of them onto `main` for a file deletion — so the deletion is being taken directly here instead. ## Testing Every claim below was checked against this branch's base (`758e7dcb10`). **1. Each file is unreferenced.** Grepped the full tree for each basename and for the path-qualified form: ``` $ git grep -l animated-banner.gif -- . → 0 files $ git grep -l travel-planner-gif.gif -- . → 0 files $ git grep -l proejct-perplexity-clone.png -- . → 0 files $ git grep -n "assets/demo.gif" -- . → (no references to assets/demo.gif) ``` `demo.gif` returns 4 bare-basename matches, all of which are different files with their own relative paths, none resolving to `assets/`: ``` examples/integrations/agent-spec/README.md:5: examples/showcases/chatkit-studio/apps/playground/README.md:5: examples/showcases/chatkit-studio/apps/world/README.md:5: examples/showcases/multi-agent-canvas/README.md:63: ``` **2. Nothing builds or copies the root `assets/` dir.** Grepped `*.json`, `*.yml`, `*.yaml`, `*.ts`, `*.mjs` for `assets` path references — the only hits are per-package `assets` fields (Angular examples, `packages/angular/ng-package.json`, `packages/web-inspector/src/assets/`), none of which reach the root directory. **3. No CI check depends on them.** `.github/workflows/static_check-binaries.yml:94` explicitly allow-lists `assets/*` from the binary-size gate, so removing files there cannot trip it. **4. Sizes confirmed from the LFS pointers** at base: ``` demo.gif 17436012 bytes animated-banner.gif 26159308 bytes travel-planner-gif.gif 12567423 bytes proejct-perplexity-clone.png 173304 bytes ``` **5. `license-badge.svg` still resolves** — `README.md:30` is the sole reference into `assets/` and that file is not part of this change. ## Known limitation These are git-LFS objects, so deleting them from `HEAD` does not reclaim history — it cuts the LFS payload a fresh clone fetches, not the repo's stored size. Anyone who hand-built an absolute `raw.githubusercontent.com/.../main/assets/<file>` link will 404 afterward; the only reference the repo ever published was the relative `./assets/demo.gif` path in the README, dereferenced in 2023. |
||
|
Benjamin Taylor
|
f31f02d008 |
chore: remove unreferenced root assets
Four files under assets/ have no reference anywhere in the repo. Together
they are ~56 MB of git-LFS payload that every fresh clone pays for.
- assets/demo.gif (17.4 MB) — last referenced by README.md until
|
||
|
Maxim
|
8bafd4870c |
docs(react-native): narrow the render-prop drift guarantee to what holds
The header claimed deriving `RenderToolProps` from `ReactToolCallRenderer` made drift between RN and web impossible, and that `check-types` would catch any divergence. Both halves are false as written. react-core publicly exports its own `RenderToolProps<S>` (src/v2/hooks/use-render-tool.tsx:9-36) which is generic over a schema, carries arguments under `parameters` rather than `args`, and types `status` as the string literals "inProgress" / "executing" / "complete" rather than as `ToolCallStatus` members. RN's derived type differs from it in both the payload field name and the `status` type, today, on the same branch that made the claim. `check-types` cannot see that divergence: nothing relates the two types, and the one place they meet — react-core's bridge at use-render-tool.tsx:178-186 — spreads the enum-typed props into the literal-typed slot and compiles, because a string-enum member is assignable to its own literal type. Web's public `status` is a widening of the canonical contract, not a derivation from it. Rewritten to claim only the defensible guarantee: RN's props cannot drift from `ReactToolCallRenderer`, the contract renderers are actually invoked against. The residual divergence from web's public type is now stated explicitly, along with the fact that RN's entry point re-exports web's three `RenderTool*Props` arms so both shapes ship under similar names. The trailing paragraph now names the states as `ToolCallStatus` members, matching how the reference page describes them. Comment-only; no type declaration changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
61686bbb84 |
docs(react-native): type render-prop status as the ToolCallStatus enum
The status PropertyReference declared a string-literal union while the usage example below it compared against ToolCallStatus. The example was right: RN's RenderToolProps is derived from ReactToolCallRenderer["render"], whose arms are typed ToolCallStatus.InProgress/.Executing/.Complete, so a reader who followed the type= attribute and wrote status === "executing" got TS2322. Fixed both places that stated the type rather than the values: the PropertyReference, and the migration section, which described the NEW status as a literal union and so buried the actual breaking change (RN's old union really was "executing" | "complete", so existing string comparisons stop compiling). Added a diff showing that migration. Also aligned the value-naming prose and the useRenderToolCall example comment on enum members, and recorded in the RenderTool*Props comparison list that react-core's own props types do declare status as string literals -- that contrast is real, not an error on this page. Note: the example needs ToolCallStatus as a value, but react-native/headless.ts currently re-exports it under `export type`. That export fix is owned elsewhere. |
||
|
Maxim
|
499786d23d |
docs(react-native): correct useFrontendTool deps comparison
The `deps` array was documented as "similar to `useEffect`" in both the
PropertyReference and the Behavior list. It is not: `useEffect` compares
elements with `Object.is`, while this hook serialises the whole array with
`JSON.stringify` and compares the string
(packages/react-core/src/v2/hooks/use-frontend-tool.tsx:45).
That difference is load-bearing now that React Native's `useRenderTool`
registers through `useFrontendTool` and the documented remedy for its
capture-at-registration semantics is "declare changing values in deps".
Both sites now state the real comparator and link a new "Dependency
comparison" section that tabulates the measured consequences: functions,
`undefined` and symbols serialise to `null`; `Map`/`Set` and instances
whose state is in `#private` fields or prototype getters collapse to `{}`
(own enumerable fields do compare); key order is significant; circular
values and `BigInt` throw during render. The section closes with the two
patterns that work -- a derived primitive, or a latest-value ref.
The react-core/web copy of this page has the same defect and is deferred
to a follow-up.
|
||
|
Maxim
|
223bdfe576 |
docs(react-native): correct the render-hook claims the convergence invalidated
The React Native guide still described the pre-convergence world: it listed `useRenderToolCall` among the hooks React Native does not export, and told readers React Native keeps a render registry separate from react-core's. Both are now false. - `useRenderToolCall` IS exported (`src/headless.ts`), along with the `ReactToolCallRenderer` type. The remaining three web rendering hooks (`useDefaultRenderTool`, `useRenderCustomMessages`, `useRenderActivityMessage`) are still genuinely absent, and stay listed with the reason each one is held back. - Wildcard resolution now applies on React Native. `useRenderTool` registers through `useFrontendTool` into `CopilotKitCoreReact.renderToolCalls`, and `useRenderToolCall` falls back to a renderer named `"*"`. Noted the one remaining asymmetry: React Native's hook always registers a tool too, so a `"*"` entry still needs `parameters`, where web has a renderer-only overload. - The "two different registries" callout is rewritten. There is one registry, so a `render` passed to `useFrontendTool` does draw in the React Native chat; the reason to prefer `useRenderTool` is now its `ReactElement | null` return type, not registry separation. Left the same bullet's "requires `parameters`" claim alone — still true. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
e48a6c5b79 |
docs(react-native): state the render-prop migration in both directions
The migration note said only that `args` is partial while `status` is "inProgress", with no before side. Read as a migration instruction it implied the opposite of the real change: the old RN `RenderToolProps` declared `args: T` (never partial) and `status: "executing" | "complete"`, so the change ADDS an "inProgress" state in which `args` is `Partial<T>` rather than narrowing a partiality that already existed. Spell out old -> new for `status`, `args` and `result`, and name "inProgress" as a newly-introduced status value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
5541a0c5e1 |
docs(react-native): make the useRenderToolCall example pasteable
The "Rendering a tool call outside the chat" snippet called the hook at module top level, had a `return` at module scope (a syntax error), and referenced an undefined `toolCalls` binding, so it could not be pasted. Wrap it in a real component, source the tool calls from `useAgent()`'s message list, and correlate each call with its tool-result message the way the prebuilt RN chat does — without `toolMessage`, `status` stays "inProgress" and `result` is `undefined` forever. Hooks bypassed: this worktree has no node_modules, so the commitlint commit-msg hook cannot resolve its binary. Subject follows the convention. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
351a7d5711 |
docs(react-native): compare tool status against the ToolCallStatus enum
The useRenderTool page's Usage example compared `status` to the string
literal `"executing"`. `status` is typed as the `ToolCallStatus` enum
member union (`ReactToolCallRenderer["render"]` in react-core, which RN's
`RenderToolProps` derives from), so that comparison is TS2367 — the
snippet as printed does not compile.
Compare against `ToolCallStatus.Executing` and import the enum in the
snippet so the example is genuinely compilable.
Depends on `ToolCallStatus` being re-exported as a runtime VALUE from
packages/react-native/src/headless.ts (it currently sits inside an
`export type { … }` block, which strips the enum value). That export fix
is a separate change; both must land together for this snippet's import
to resolve.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
df11fa1dc5 |
docs(react-native): import the chat that renders tool calls in useRenderTool's example
The primary Usage example on the useRenderTool reference page never imported
CopilotChat, and the barrel specifier it implied resolves to the headless
component (packages/react-native/src/CopilotChat.tsx), which returns a bare
context provider around {children} and paints no message list. The page's
headline example therefore rendered nothing at all.
Import CopilotChat from @copilotkit/react-native/components -- the prebuilt UI
that calls useRenderToolCall and renders tool calls inline -- and state the
subpath requirement under the block so the distinction is not silent.
agentName is kept: it is the current, non-deprecated prop on the /components
chat (the deprecation and dev console.warn live on the headless component's
agentName), and it matches the prebuilt-UI usage on the CopilotChat page.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
8c7fb7aee1 |
docs(react-native): tell the truth about how useRenderTool compares deps
The deps guidance told readers that a render closure over changing values
is fixed by listing those values in deps. That remedy is inert for the
value types most likely to appear in a render closure.
react-core's useFrontendTool compares deps by serializing the whole array
(packages/react-core/src/v2/hooks/use-frontend-tool.tsx:45, via
JSON.stringify(extraDeps)), not by reference identity like useEffect. In
an array a function or symbol serializes to null, and a Map, a Set, or a
class instance holding state in private fields serializes to {} -- the
same string forever, so such a dep never re-registers the tool. A
circular dep additionally throws while the hook renders.
State the comparator's actual semantics, name the three consequences
(inert non-serializable deps, circular deps throwing, key order
counting), and document what does work: a primitive derived from the
changing value, or a ref the captured render dereferences at call time.
Docs-only. Core's comparator is deliberately unchanged -- it is shared by
every platform and is out of scope for this finding.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
63b6c4d0f4 |
docs(react-native): correct useRenderTool signature and render-prop semantics
The documented signature dropped the hook's generic constraint and default (`T extends Record<string, unknown> = Record<string, unknown>`) and rendered the required `options` argument as optional. The render-prop semantics were wrong in two ways verified against the types: `args` is not "fully parsed" on the executing/complete arms — every arm receives the same `partialJSONParse` of the raw argument string and the `parameters` schema is never applied before `render`, so widening `Partial<T>` to `T` is a type-level assertion only. And `result` is the tool result message's `content` correlated by `toolCallId`, not the handler's return value: the complete arm is selected because that message exists, handler returns arrive serialized (`undefined`/`null` -> `""`, else `JSON.stringify`), a thrown handler yields the string `Error: <message>`, a render-only tool completes with `""`, and on reload the value replays from stored history. Also document that the RN entry's re-exported `RenderToolInProgressProps` / `RenderToolExecutingProps` / `RenderToolCompleteProps` are NOT arms of RN's `RenderToolProps<T>`: they are schema-generic, `parameters`-shaped arms of react-core's own union for the web hook. They sit next to `RenderToolProps` on the public barrel, so the resemblance is a real trap worth naming. Commit hook note: the commit-msg commitlint hook cannot run in this worktree (no node_modules, `commitlint` binary unresolvable), so the message was validated by hand against commitlint.config.js — conventional type+scope, 77-char header under the 120 limit, blank-line-separated body and footer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
803ef2d7ab |
docs(react-native): correct the inverted pre-refactor history in render-tool-types
The header JSDoc on the new derived `RenderToolProps` claimed the deleted RN type had "args unconditionally partial". The opposite was true: the old `RenderToolContext.tsx` declared `args: T`, so RN promised the FULL argument object at every status — the drift this refactor fixes is that the canonical contract ADDS an `"inProgress"` state in which `args` narrows to `Partial<T>`. Stating the drift backwards in the very file that defines the contract misleads anyone reasoning about the migration, so the historical claims are now spelled out concretely and verified against the deleted type: - old `status` was `"executing" | "complete"` with no `"inProgress"` member - old type omitted `name` and `toolCallId` entirely - old `args` was unconditionally `T`, never `Partial<T>` Comment-only; no type declaration changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Maxim
|
2158a6f382 |
docs(bundle-size): correct the action pin, package inventory and guard coverage
The Tier 3 section shipped in this PR made claims the code contradicts:
- The action pin read v2.9.1; static_bundle_size.yml pins 2.10.0 (by SHA).
- assert-headless-purity.mjs asserts four targets — dist/v2/headless.{mjs,cjs}
AND dist/v2/context.{mjs,cjs} — not just the headless pair.
- The package inventory enumerated 9 packages while the workflow glob covers 10:
react-native was neither listed nor classified, and the "no size script" claim
was wrong for it (it ships size:headless).
- "Both directions of the #4893 regression" overclaimed. The purity script is a
substring scan of four emitted files with @copilotkit/core, @copilotkit/shared,
@ag-ui/*, rxjs, zod and uuid external, so it cannot see a heavy dep arriving
through an external edge; the RN test never resolves bare specifiers, so it
cannot enter node_modules. Both limits are now stated, along with the gap
neither guard covers.
- The heading said "two tiers" while three are documented.
Docs only — no change to the script or the workflow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Maxim
|
ec42161670 |
chore: drop the RN render-tool changeset, this repo has no Changesets
This repo migrated off Changesets. CLAUDE.md says never to create `.changeset/*` files, and `.github/workflows/static_check-binaries.yml` hard-fails the build on any added or modified path under `.changeset` (`git diff --name-only --diff-filter=AM origin/<base>...HEAD -- '.changeset'` must be empty). `.changeset/rn-render-tool-convergence.md` tripped that gate, so this branch could not go green. Releases here are conventional-commit driven; the change is described in commit subjects and footers instead. Where each piece of the deleted changeset now lives: - Package bumps (`@copilotkit/react-native` minor, `@copilotkit/react-core` minor) -> derived by the release tooling from commit subjects: `refactor(react-native)!` ( |
||
|
Tyler Slaton
|
758e7dcb10 |
chore: release channels v0.8.1 (#6446)
## Release channels v0.8.1 **Scope:** `channels` | **Bump:** `patch` --- ### How this release process works 1. **This PR was created automatically** by the "release / create-pr" workflow. It bumped the `channels` packages to `0.8.1` and generated AI-enhanced release notes. 2. **CI runs on this PR** — the full test suite (unit tests, lint, type checks, build) must pass before merging. This is the review gate. 3. **Review the release notes** in `release-notes.md` in this PR. If a Notion draft was created, you can edit the release notes there before merging. 4. **When this PR is merged**, the `release / publish` workflow automatically: - Builds all packages - Publishes the `channels` packages to npm at version `0.8.1` - Creates git tag `channels/v0.8.1` - Creates a GitHub Release with the final release notes ### Before merging - [ ] CI is green (tests, lint, types, build) - [ ] Version bumps look correct - [ ] Release notes are accurate (edit in Notion if a draft was created) --- > **Do not merge until CI is fully green.** The full test suite runs automatically on this PR.channels/v0.8.1 |
||
|
tylerslaton
|
a7378e70eb | chore: release channels v0.8.1 | ||
|
Austin Merrick
|
731f895db3 | test(docs): anchor managed onboarding sequence | ||
|
Austin Merrick
|
dc158885dc | docs: correct managed onboarding return order | ||
|
Austin Merrick
|
925fe39784 |
chore: release monorepo v1.67.0 (#6445)
## Release monorepo v1.67.0 **Scope:** `monorepo` | **Bump:** `minor` --- ### How this release process works 1. **This PR was created automatically** by the "release / create-pr" workflow. It bumped the `monorepo` packages to `1.67.0` and generated AI-enhanced release notes. 2. **CI runs on this PR** — the full test suite (unit tests, lint, type checks, build) must pass before merging. This is the review gate. 3. **Review the release notes** in `release-notes.md` in this PR. If a Notion draft was created, you can edit the release notes there before merging. 4. **When this PR is merged**, the `release / publish` workflow automatically: - Builds all packages - Publishes the `monorepo` packages to npm at version `1.67.0` - Creates git tag `monorepo/v1.67.0` - Creates a GitHub Release with the final release notes ### Before merging - [ ] CI is green (tests, lint, types, build) - [ ] Version bumps look correct - [ ] Release notes are accurate (edit in Notion if a draft was created) --- > **Do not merge until CI is fully green.** The full test suite runs automatically on this PR.v1.67.0 |
||
|
Austin Merrick
|
9cec8cd3e2 | docs: clarify automatic Free plan choice | ||
|
onsclom
|
48312f4d65 | chore: release monorepo v1.67.0 | ||
|
Austin Merrick
|
24766af5f8 | docs: clarify managed organization onboarding | ||
|
Tyler Slaton
|
11e07bd780 |
fix(channels): recover from error-only websocket failures (#6443)
## What changed - adds an internal 100 ms fallback when an established Realtime Gateway transport emits `error` without `close` - cancels the fallback on normal close, successful open, and intentional disconnect - cycles the existing Phoenix socket only when the close event never arrives, preserving Phoenix channel rejoin behavior - adds regression coverage for Node 22 error-only recovery and for avoiding a duplicate reconnect when error is followed by close ## Why Node 22 built-in WebSocket can report a failed HTTP upgrade, including a temporary HTTP 502, with an `error` event and no matching `close`. Phoenix schedules socket reconnects only from its close handler, so a managed Channels session could remain stuck in `reconnecting` until its process restarted. ## Impact Channels hosts recover automatically without new public options or host configuration. Initial-connect diagnosis, Phoenix backoff, connection states, and the reconnect give-up window are unchanged. ## Validation - Node 22 red regression: failed before the fix with 2 sockets instead of the expected recovered third socket - `pnpm nx run @copilotkit/channels-intelligence:test`: 22 files and 214 tests passed - `pnpm nx run @copilotkit/channels-intelligence:check-types`: passed - `pnpm nx run-many -t test,check-types,build --projects=@copilotkit/channels-intelligence`: passed - repository pre-commit tests, `publint`, and `attw` checks: passed The PR remains draft pending review. |