## 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.
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.
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 446ad06afc
(2023-11-29) removed the <img src="./assets/demo.gif"> tag.
- assets/animated-banner.gif (26.2 MB) — no reference in tree history.
- assets/travel-planner-gif.gif (12.6 MB) — no reference in tree history.
- assets/proejct-perplexity-clone.png (173 KB) — no reference in tree
history; the filename also carries a "proejct" typo.
Verified unreferenced by grepping the full tree for each basename and for
the path-qualified form. The only remaining reference into assets/ is
README.md:30 -> assets/license-badge.svg, which is untouched.
Credit to @VZBYang, who identified assets/demo.gif in #4314.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## 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.
## 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.
## 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.
## Summary
- `CopilotChat` fingerprints messages for `useMemo` with `contentKey =
0` for any non-string / non-array content.
- `ACTIVITY_SNAPSHOT` updates often keep the same `messageId` and only
replace object `content` (progress / generative UI). That left activity
renderers stuck on the first frame until some other list change forced a
refresh.
- Include `JSON.stringify(m.content)` for object content in the
fingerprint. Multimodal attachments remain on the array-length branch,
so this does not reintroduce base64 serialization for user uploads.
- Add a regression test that replaces the same activity `messageId` and
asserts the UI updates.
## Test plan
- [x] `nx run @copilotkit/react-core:test` (or the package's activity
e2e suite)
- [x] Manual: stream repeated `ACTIVITY_SNAPSHOT` with the same
`messageId` + `replace: true` and confirm custom activity renderers
update each frame
Made with [Cursor](https://cursor.com)
Small docs clarification for the Channels SDK.
- **Channels overview** (`/channels`): adds a short note under the
architecture diagram that you can build your own channel runner on the
open-source SDK, with no CopilotKit Intelligence dependency — a
supported path where the team owns state, persistence, concurrency,
locking, retries, and race-condition handling. Intelligence remains the
managed runner; analytics, learning, and governance come in addition.
- **Self-hosting section**: Enterprise Intelligence can be fully
self-hosted today; onboarding guides are still to come, and we're happy
to help in the meantime.
- **Package READMEs** (`channels`, `channels-core`, and the five
adapters): removes the "there is no standalone / DIY runner" phrasing,
which contradicted the above, in favor of the same managed-vs-custom
framing.
Intentionally does **not** add any implementation guidance for custom
runners (no state-store interface details, no persistence examples).
Follow-up (not in this PR): swap in the updated architecture diagram
assets (light + dark) that show the "Build Your Own Channel Runner" box
alongside Enterprise Intelligence.
Refs
[FAC-155](https://linear.app/copilotkit/issue/FAC-155/channels-docs-lack-a-clear-supported-path-without-intelligence)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
New export from Figma: two runner paths (managed Intelligence runner or
build your own), durable-data emphasis, Any Agent framework list, and
channel platforms with the +4 more row. Used for both themes until a
dark export exists.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Drop the defensive parentheticals around Intelligence pricing; say
"available on a free plan" and move on.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Note in the Channels overview and package READMEs that building your own
channel runner on the open-source SDK primitives is a supported path with
no CopilotKit Intelligence dependency; teams choosing it own their state,
persistence, concurrency, locking, retries, and race-condition handling.
Intelligence remains the managed runner, with analytics, learning, and
governance in addition.
Also updates the production self-hosting note: Enterprise Intelligence can
be fully self-hosted today, onboarding guides are still to come.
Refs FAC-155
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
## What does this PR do?
Adds the CopilotKit consumer side of ENT-1173 across Shared, Runtime,
Core, Web Inspector, and the existing Shell Docs pages.
- Defines and parses optional trusted Inspector metadata for identity,
plan, license, action, usage, and expiry. Runtime proxies it through a
private, failure-isolated route, and Core refreshes it without changing
connection state.
- Groups Inspector navigation into Threads, Agents, and Learning.
Threads renders finite, unlimited, unknown, overage, and expiring usage
states plus matching trusted plan or license actions.
- Keeps explicit `threadEndpoints` as the only authority for Thread
requests. Locked or absent capability states make no list, subscription,
detail, message, event, or state calls.
- Keeps the zero-thread video, three example Threads, detail tabs, and
guided tour in empty and locked states. General Intelligence remains the
default onboarding path; only trusted `team_self_hosted` metadata uses
self-hosted onboarding.
- Gives an active license with missing Runtime routes a short **Finish
setting up Rich Threads** state. Users can copy a safe coding-agent
prompt or open the public Runtime setup guide. The same copy control
appears in that guide, and raw Markdown/LLM views include the full
prompt.
- Keeps finite usage green below 90%, orange from 90% to the limit, and
red at or above the limit. At 90%, a trusted plan action changes from
**Manage Your Plan** to a purple **Upgrade Your Plan** without changing
its trusted URL, action kind, or telemetry contract.
- Adds a deterministic 33-state loopback lab for CopilotKit developers.
It has no production route or export, is absent from public docs and
package metadata, and is excluded from the npm tarball.
`Expiring Soon` is display-only; this PR does not enable the thread
culler. Managed Enterprise receives no manage-plan action, and Team
Self-Hosted receives no hosted plan action. Optional metadata and the
additive expiry field remain compatible across mixed producer, Runtime,
Core, and Inspector versions.
A small Channels test-only change updates fetch mocks for current
TypeScript types. It changes no Slack or Teams docs or runtime behavior.
## Related PRs and issues
- Refs
[ENT-1173](https://linear.app/copilotkit/issue/ENT-1173/ship-plg-ready-inspector-navigation-metadata-and-locked-threads)
- Producer:
[CopilotKit/Intelligence#696](https://github.com/CopilotKit/Intelligence/pull/696)
## Validation
- `@copilotkit/web-inspector`: 20 files and 372 tests passed; typecheck
and production build passed.
- Shell Docs: 57 files and 383 tests passed; lint, typecheck, and
production build passed. The build generated all 222 static pages.
- Browser checks cover the copy-prompt flow, unchanged white **Manage
Your Plan**, purple **Upgrade Your Plan**, orange 4,500/5,000 usage, and
red 5,000/5,000 usage.
- Independent review found no Critical or Important issues.
- The broader Runtime, React Native, Channels, package-quality,
compatibility, and Node-version checks from the prior pushed head remain
green.
## Checklist
- [x] I have read the [Contribution
Guide](https://github.com/copilotkit/copilotkit/blob/master/CONTRIBUTING.md)
- [x] I updated the relevant documentation
- [ ] "Allow edits by maintainers" is checked
## The bug
`agentIdFromUrl` in `src/app/api/copilotkit/[[...slug]]/route.ts` only
read the target agent from the URL **path** (`/agent/:agentId/run`).
Thread routes carry it in the **query string** instead
(`/threads?agentId=<id>`), so every thread-list request looked
agentId-less and fell through to `defaultSkinId`'s `identifyUser` —
banking's.
That split identity for every non-default skin:
| path | resolves via | result |
| --- | --- | --- |
| `POST /agent/people/run` | `people`'s resolver ✅ | thread created
under `rowan-demo-user` |
| `GET /threads?agentId=people` | **banking's** resolver ❌ | asks for
`northwind-demo-user`, gets `[]` |
## Why it was hard to see
Nothing errors. The thread rail just reads *"No conversations yet"*
forever and reopening a conversation after a reload is impossible —
which reads to a viewer as "this product doesn't persist threads", the
exact opposite of what the demo exists to prove. **Banking was immune
only because it IS `defaultSkinId`.**
## The fix
Fall back to `?agentId=` from the query string when the path carries no
`/agent/<id>` segment.
## Verification
Against a local Intelligence stack, thread counts from `GET
/api/copilotkit/threads?agentId=<id>`:
| skin | before | after |
| --- | --- | --- |
| people | 0 | 11 |
| airline | 0 | 1 |
| logistics | 0 | 3 |
| banking | 7 | 7 (unchanged) |
Confirmed the backend held those threads all along — they were being
listed under the wrong end-user id.
Skins with no `identifyUser` (airline) still fall through to
`genericIdentity()` via the existing `if (!resolve)` guard, so this
widens correct resolution without adding a failure mode.
`pnpm build`, `pnpm lint`, `pnpm test:unit` (335/335) green.
## Skill-staleness check
Per the app's standing rule: **checked, no skill impact.** This is
shell-internal identity plumbing; `.claude/skills/reskin/` documents the
`identifyUser` contract, which is unchanged — a skin still contributes
the same resolver in the same place.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Rowan is a People Operations command center and the second skin built against
the full nine-beat bar in `.claude/skills/reskin/demo-beats.md` (banking was the
first). Pages: Roster (index), Compensation, Requests, Onboarding.
REST-backed like banking and logistics: `/api/people/v1/*` serves one `ledger`
snapshot read plus the write paths, a generated `offer-letter` PDF, and a
presenter-gated `dev/reset`. Components read the ledger through the skin's own
`usePeopleLedger()` context, so `useData` is omitted. That context is mounted in
`RuntimeProviders` rather than `Providers`, which lets the single fetch also feed
`useRuntimeProperties`.
The signature element is the band ladder: one rail per level, each normalized to
its OWN band, so "halfway up L3" and "halfway up L7" line up at the same height
and become comparable. Anyone outside their band is drawn outside the rail, in
the negative colour, always labelled.
Beats, all walked in a browser against a live Intelligence stack:
1 face showCompBands renders the ladder + a two-sentence answer
2 rich thread gen-UI replays intact on reopen after a hard reload
3a drive the app setBaseSalary — the figure is typed into a chat card and
goes straight to REST; it appears nowhere in the transcript
3b sees screen route readable + per-page on-screen readables on all four
pages; Roster and Requests give different, correct answers
3c levers HITL confirm naming the levers, then
?status=pending&sort=aging_desc&top=10 with the Status, Sort
and Show controls visibly tinted, "TOP 10 OF 11"
3d multimodal an offer-letter PDF rides the pill, and the filed packet
survives deleting the thread and reloading
4 memory seeded preference recalled AND named in the component's
`note` slot
5 stored skill one vague sentence fires three visible writes in order, no
confirmations, amid four distractor tools
6 teach a skill 422 OUT_OF_BAND (symptom only) -> decline -> record the
demonstration -> save -> apply unaided to a DIFFERENT person
in a fresh thread
Notes for reviewers:
- The beat-6 gate is deliberately discriminating. Decoy exception codes file and
finalize successfully and still do not lift it, and an unknown code is refused
without enumerating the catalogue — so "the agent filed an exception" is not
the same as "the agent cleared the gate". Two out-of-band comp requests are
seeded so the case taught on stage and the unaided replay are different people.
- Seed dates are relative offsets materialized at store init, not absolute ISO
strings, so request aging and the generated offer letter stay coherent years
from now and a Reset genuinely re-freshens the queue.
- Memories are seeded and saved at `user` scope, not `project`. Verified against
the running stack: a project-scoped row is returned for EVERY user id in the
instance, so with several skins sharing one backend it is not a per-skin
boundary. For the same reason this skin's `forgetAllMemories` skips
project-scoped rows rather than deleting data it does not own, and `dev/reset`
reports the skipped count.
- `temperature` is not set. gpt-5.4 rejects it and the value is discarded, so
carrying it alongside a comment claiming determinism would be misleading.
- Beat 2 additionally requires the thread-list identity fix sent separately; the
skin merges and runs fine without it, it just cannot demo thread reopen.
Docs updated for the fifth skin per the app's standing skill-staleness rule:
CLAUDE.md (skin list, substrate split, beat matrix), README.md,
docs/teach-mode/README.md (teach-mode is now per-skin, not banking-only), and
`.claude/skills/reskin/{SKILL,demo-beats,templates}.md` — including six
"only banking does this" claims that are no longer true.
Verified: pnpm build, pnpm lint, pnpm test:unit (335/335) on this base.
Co-Authored-By: Claude <noreply@anthropic.com>
`agentIdFromUrl` only read the target agent from the URL PATH
(`/agent/:agentId/run`). Thread routes carry it in the QUERY STRING instead
(`/threads?agentId=<id>`), so every thread-list request looked agentId-less and
fell through to `defaultSkinId`'s `identifyUser` — banking's.
The result was a split identity for every non-default skin: runs created threads
under the skin's own end-user id (the run path resolves correctly), while the
list asked for banking's id and got an empty array back. The thread rail read
"No conversations yet" forever and reopening a conversation after a reload was
impossible.
Nothing errored, which is what made it hard to see — and it reads to a viewer as
"this product doesn't persist threads", the opposite of what the demo exists to
show. Banking was immune only because it IS `defaultSkinId`.
Verified against a local Intelligence stack; thread counts returned by
`GET /api/copilotkit/threads?agentId=<id>` before → after:
people 0 → 11
airline 0 → 1
logistics 0 → 3
banking 7 → 7 (unchanged; it was already resolving correctly)
Skins with no `identifyUser` (airline) still fall through to `genericIdentity()`
via the existing guard, so this widens correct resolution without introducing a
new failure mode.
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes#261 (open since March 2024). Supersedes #4622 — @ashish4143
diagnosed the same wrappers and is credited as co-author on the commit.
## The bug
`CopilotSidebar` wraps consumer content in two divs:
- `.copilotKitSidebarContentWrapper` (`Sidebar.tsx`) — only sets
`overflow`, `margin-right`, `transition`
- `.copilotKitModalChildrenWrapper` (`Modal.tsx`) — **has no CSS rule
anywhere in the repo**
Both are auto-height blocks, so a child's `height: 100%` has no definite
containing block to resolve against and collapses to content height.
## The fix
An opt-in `fullHeightChildren` prop on `CopilotSidebar` that adds a
modifier class to the content wrapper. Two deliberate choices, both from
the review on #4622:
- **Opt-in, not default.** The content wrapper wraps the *entire*
consumer app. Making it a fixed-height flex column for everyone would
reflow apps that never asked for it.
- **A viewport unit, not `height: 100%`.** `100%` only resolves if every
ancestor (`html`/`body`/`#root`) also declares a height — react-ui
neither sets that nor can guarantee it, so `100%` would silently no-op
in a stock Next.js app. `min-height: 0` on the children wrapper clears
the flex-item `min-height: auto` floor so tall content scrolls inside
the child rather than stretching the wrapper past the viewport.
```tsx
<CopilotSidebar fullHeightChildren>
<div style={{ height: "100%" }}>...</div>
</CopilotSidebar>
```
## Testing
**Unit** — `packages/react-ui/src/css/sidebar-full-height.test.ts` (4
tests), in the repo's existing CSS-contract style. Guards both halves:
the escape hatch's rules, and that the default wrapper stays
auto-height. Also asserts the height is *not* `100%`, since that's the
regression that would make the whole feature a silent no-op.
```
✓ src/css/sidebar-full-height.test.ts (4 tests)
Test Files 9 passed (9) Tests 58 passed (58) # full react-ui suite
```
`npx tsc --noEmit` → exit 0. `oxlint` on changed files → 0 warnings, 0
errors.
**Live in Chrome** — the acceptance criterion from the #4622 review: a
stock app where **nothing** declares a height on `html`/`body`/`#root`,
loading the real built `dist/index.css` (not the source CSS), standards
mode, 762px viewport. DOM per `Sidebar.tsx:92` + `Modal.tsx:143`.
| case | child `height:100%` measures |
|---|---|
| default (no opt-in) | **17px** — collapsed, i.e. behavior unchanged
for existing consumers |
| `fullHeightChildren` | **762px** — exactly the viewport |
| `fullHeightChildren`, content 3000px tall | **762px**, scrolls inside
the child (`min-height: 0` holds) |
Also confirmed on the opt-in path: `.copilotKitSidebar` stays `position:
fixed`, and the expanded push-aside `margin-right` is still `448px`
(28rem), so the sidebar's own layout is untouched.
**Docs** — `CopilotSidebar.mdx` is auto-generated from `Sidebar.tsx`;
regenerated via `scripts/docs/gen.ts` and committed only the new
`fullHeightChildren` entry (the generator also surfaces unrelated
pre-existing drift in other reference pages, left out of this PR).
## Not covered
The issue mentions a "works in Safari, not Chrome" symptom. I verified
in Chromium only — the mechanism above is spec behavior rather than a
Chrome quirk, but I haven't measured WebKit.
Fixes#5961 (OSS-609).
## The bug
Both LangGraph auth pages told self-hosted readers to wrap their graph
in `CopilotKitRemoteEndpoint`. That path is retired and fails two ways
against the stack the reporter used (`copilotkit==0.1.94`,
`ag-ui-langgraph==0.0.4x`, Python 3.12):
```
import LangGraphAgent -> ImportError: cannot import name 'LangGraphAgent' from 'copilotkit'
execute_agent -> AgentExecutionException: Agent 'sample_agent' failed to execute:
'LangGraphAGUIAgent' object has no attribute 'execute'
```
(Reproduced locally against the `langgraph-fastapi` example's venv —
output above is verbatim.)
## The fix
`showcase/shell-docs/src/content/docs/auth.mdx` (Self-hosted tab of the
`auth_pattern: langgraph` section) and
`showcase/shell-docs/src/content/docs/integrations/langgraph/auth.mdx`
now document the supported pattern: **serve the AG-UI endpoint
yourself**, validate in a FastAPI dependency (401 before the graph
runs), and bake the resolved user into a **per-request**
`LangGraphAGUIAgent(config={"configurable": {"auth_user": user}})` so
nodes read an already-verified identity off `RunnableConfig` — no raw
token in the graph, no shared agent carrying another request's identity.
The gate-only variant (`FastAPI(dependencies=[Depends(current_user)])` +
`add_langgraph_fastapi_endpoint`) is documented for readers who only
want unauthenticated traffic rejected.
Two adjacent bugs on the same pages, fixed here because they break the
same walkthrough:
- **The frontend channel was wrong.** The pages said to pass
`properties={{ authorization: userToken }}` and claimed it "is forwarded
as a Bearer token". Nothing in `packages/` converts properties into
headers — `properties` reach the agent as AG-UI `forwardedProps` (run
payload data). The v2 runtime *does* forward the inbound `authorization`
header (and custom `x-*`) onto the agent call, so `headers={{
Authorization: ... }}` is the channel that actually works, for both
Platform and self-hosted.
- **The Platform user key was wrong.**
`config["configuration"]["langgraph_auth_user"]` →
`config["configurable"]["langgraph_auth_user"]` (matches
`langgraph/pregel/main.py` and `langgraph_api/worker.py`).
## Testing
**1. Doc snippets extracted verbatim from the MDX and executed** (a
script pulls the `main.py` + node code blocks out of each page, stubs
only `validate_your_token`, and drives them with `TestClient`; run under
the `examples/integrations/langgraph-fastapi` venv — `copilotkit
0.1.94`, `ag-ui-langgraph 0.0.41`, Python 3.12):
```
# docs/auth.mdx
PASS no header -> 401 {"detail":"Missing bearer token"}
PASS bad token -> 401 {"detail":"Invalid token"}
PASS valid token -> 200
PASS no RUN_ERROR
PASS node read user_123 off RunnableConfig
PASS node read role 'member'
PASS run completed
MESSAGES_SNAPSHOT: [{"id": "None", "role": "assistant", "content": "hello user_123"}]
ALL DOC-SNIPPET CHECKS PASSED
# docs/integrations/langgraph/auth.mdx — same script, same 7 checks
ALL DOC-SNIPPET CHECKS PASSED
```
**2. Gate-only variant**
(`FastAPI(dependencies=[Depends(current_user)])` + stock
`add_langgraph_fastapi_endpoint`):
```
no token -> 401 {"detail":"Missing bearer token"}
valid token -> 200 True True
PASS gate-only pattern (401 without token, run proceeds with token; identity NOT injected)
```
The trailing `True True` is `RUN_FINISHED` present **and** the node
seeing `nobody` — i.e. the gate works but no identity lands on the
config, exactly as the docs now say.
**3. Header forwarding actually reaches a LangGraph deployment** — the
claim behind the new `headers` guidance. Pointed a real
`@ag-ui/langgraph` `LangGraphAgent` at a local stub server, set
`agent.headers` the way `configureAgentForRequest` does, and recorded
what arrived:
```
[ { "url": "/assistants/search", "auth": "Bearer end-user-token", "apiKey": "server-side-key" } ]
PASS: authorization forwarded to the deployment
```
Both the end-user token and the server-side key arrive, which is why the
"server-configured headers win on collision" note is accurate.
Runtime-side breadth is already covered by
`packages/runtime/src/v2/runtime/__tests__/agent-utils-header-forwarding.test.ts`
("authorization header IS forwarded").
**4. Docs render checks** — both pages compile as MDX (`@mdx-js/mdx`
`compile()`), and every `python` block on both pages parses
(`ast.parse`), including the ones I didn't touch.
## Follow-up
**The DIY endpoint is deliberate but temporary.**
`add_langgraph_fastapi_endpoint` exposes no per-request seam (no
`dependencies` passthrough, no config/agent factory), and `endpoint.py`
is byte-identical in 0.0.41 and 0.0.42 — so owning the route is
currently the only way to get a verified identity onto
`config["configurable"]`. Adding that seam upstream in
`ag-ui-protocol/ag-ui` is tracked as **OSS-760**; when it lands, both
pages collapse back to the helper form and the DIY route stays only as
an escape hatch.
The broader "document request-scoped auth for
`add_langgraph_fastapi_endpoint`" ask in #3177 is now substantively
answered by these pages; leaving that issue open pending a maintainer's
call on whether it wants an SDK-level hook rather than the DIY endpoint.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Summary
`shared-state-read-write` pills showed **no chat responses** on staging.
### Cause
#6227 wired deterministic replies for the suggestion pills, but those
updates were emitted as:
```csharp
new AgentRunResponseUpdate { Contents = [new TextContent(...)] }
```
without `Role = ChatRole.Assistant`. AG-UI's .NET adapter only turns
assistant-role text into `TEXT_MESSAGE_*` events, so the frontend
dropped every pill reply. Notes snapshots could still land; chat looked
dead.
### Fix
- Set `Role = ChatRole.Assistant` on deterministic text updates
- Prefer `message.Text` when resolving the latest user message
- Broaden pill matching for greet / weekend / remember-something copy
## Test plan
- [x] `dotnet build` ms-agent-dotnet agent
- [ ] Staging after deploy: Greet / Remember something / Plan a weekend
all show assistant text; Remember something updates the notes panel
## Summary
`declarative-gen-ui` on staging painted surfaces but charts showed **No
data available** and tables were empty.
### Cause
With `injectA2UITool: false`, the secondary design LLM does **not**
receive frontend App Context (`useSalesAnalystContext` /
sales-context.ts). It only got a thin design prompt, so it omitted or
emptied `PieChart`/`BarChart` `data` arrays and `DataTable` rows.
### Fix
- Embed the Vantage Threads Q2 dataset + composition rules into
`DeclarativeGenUiDesignSystemPrompt`
- Add concrete non-empty PieChart / BarChart / DataTable examples
- Coerce string chart values to numbers
- Tighten outer agent: one short sentence, no prose dashboards
## Test plan
- [x] GenerateA2ui unit tests 12/12
- [ ] Staging after deploy: all four declarative-gen-ui pills show
populated charts/tables from the Q2 dataset
`LOCK_SKIN=<skin id>` turns the four-skin demo shell into a
**single-tenant product deploy**. Unset — the default — behaviour is
byte-identical to before.
```
LOCK_SKIN=logistics # the skin is SERVED AT /, and the /logistics prefix
# leaves the URL space: /, /lanes, /inventory
# /logistics itself -> 404, as do banking|airline|keel
# switcher -> static badge; tab reads "Meridian"
LOCK_SKIN= # unset: all four reachable under /<id>, switcher present
LOCK_SKIN=bankng # throws at boot, naming the typo and listing valid ids
```
The point is what the deploy *admits to being*. The selector card used
to announce "this is a reskinnable demo with four tenants" — and so did
every URL. A locked deploy says "this is Meridian": in the routing, the
chrome, the page metadata, **and the address bar**.
## Design notes for review
- **Served at `/`, not redirected to `/logistics`.** A redirect still
puts the substrate's tenant id in front of a customer, on the front door
and on every link after it. `src/proxy.ts` REWRITES the prefix-free
space onto the `/[skin]` route tree instead, so the segment never
appears.
- **`proxy.ts`, not a `next.config` rewrite.** `rewrites()` is
serialised into `routes-manifest.json` at BUILD time, which would bake
the lock into the artifact. Proxy files (Next 16's rename of
`middleware.ts`) always run on the Node.js server, so `LOCK_SKIN` stays
a per-request read and ONE BUILD SERVES BOTH HOSTS.
- **The SSE stream is safe by construction.** The matcher excludes `api`
at a segment boundary, so `/api/copilotkit` never enters the proxy.
`proxy.test.ts` asserts it directly, plus a live-server check in the
locked e2e.
- **Links are the other half of the contract.** `useSkinHref`
(`src/shell/skin-path.ts`) makes every in-skin href prefix-free under a
lock. The rewrite alone is useless: a hardcoded `` `/${skin.id}/cards`
`` still RESOLVES, it just puts the prefix back in the address bar on
the first nav click.
- **`useSkinHref` drops the prefix for the LOCKED skin, not for any
lock** (`locked === skinId`). Otherwise `useSkinHref("airline")` under
`LOCK_SKIN=banking` would silently ignore the id it was handed and
return a banking URL.
- **`params` is untouched, which is why this is a rewrite.** The rewrite
target keeps the `[skin]` segment, so keel's `useParams<{ skin, rest }>`
pages needed no change. Collapsing `[skin]/[[...rest]]` into a root
catch-all — the obvious alternative — would have broken them.
- **`useSkinSegments` replaces three copies of
`pathname.split("/").slice(2)`.** It strips a LEADING skin id rather
than slicing a fixed offset, so it is correct whether or not the
pathname carries the prefix, and does not depend on resolving whether
`usePathname()` reports the browser URL or the matched route under a
rewrite.
- **The URL contract is enforced by an ESLint AST rule**, not by
scanning source as text. See "What the review changed" below — this
replaced a regex scanner that drifted out of true three rounds running.
- **Non-`NEXT_PUBLIC_` env**, read server-side and threaded to client
chrome through a small context, so one build serves every deployment
shape. **`force-dynamic` on both env-reading entry points** — reading
`process.env` is not a dynamic API, so `/` would otherwise be
prerendered with the build-time skin baked in. **SSR metadata** via
`generateMetadata`, because a client effect cannot brand what crawlers
and unfurlers read.
- **A disabled dropdown was rejected** for the locked state — it implies
a choice that doesn't exist. The switcher's own
`router.push(\`/${skin.id}\`)` deliberately KEEPS the prefix: it renders
only when unlocked, and switching skins is the one case where the
segment is meaningful.
## What the review changed
A 5-round review loop (7+ unbiased agents per round, ~60 agent-reviews
total) found and fixed the following. Round 1 found four production
defects; rounds 2–5 found **zero** — every later finding was in the
review's own scaffolding or in docs the fix cycles themselves wrote.
**Production defects (all round 1):**
| Defect | Impact |
|---|---|
| `` `${base}/charges` `` and `` `${base}${page}` `` in
`banking/tools.tsx` | `skinHref()` returns `/` under a lock, so these
emitted `//charges` — a **protocol-relative URL that navigates
off-site** to `https://charges/`. Both were `router.push` calls,
invisible to any rendered-href check. Now routed through a pure,
unit-tested `nav-target.ts`. |
| Proxy matcher excluded `_next/static` + `_next/image`, not `_next` |
`/_next/webpack-hmr` and the error-overlay endpoint WERE rewritten under
a lock, breaking HMR and the overlay in `next dev` — which
`next.config.mjs:22` states is how this demo is presented. |
| `api`/`_next` matched by prefix, not segment | A future `/apiary` or
`/api-keys` route would silently skip the rewrite and 404 only on locked
deploys. |
| The locked e2e's headline guard passed vacuously |
`expect(hrefs).toEqual([])` succeeds when zero links render. Now has a
positive precondition plus a `//` assertion. |
**Scaffolding and docs, rounds 2–5:** the drift guard was rewritten from
a regex text-scanner to an ESLint AST rule after it produced a mandatory
finding three rounds running (it caught 1 of 5 spellings, missed the bug
that actually shipped, over-claimed its coverage, and was evadable via a
`$` in a variable name); the AST rule was then narrowed twice, first to
navigation contexts and then to navigation *objects*, after it
false-positived on dates (`` `${m}/${d}` ``), `String.replace`,
`Object.assign` and `Array.push`. Docs fixes: a false "defence in depth"
claim on `/`, the README's skin count, keel's brand name, and the reskin
skill's file list.
**Deliberately not fixed here** — 13 real findings that fail all three
subject-scope tests, routed to follow-up PRs under four subject handles:
Intelligence dev-env credential/org consistency (`.env.example` key
contradicts `docker-compose.yml`, silently emptying memory scope), HITL
replay-safety across banking and keel (including an approval card that
offers a non-approver no escape, hanging the interrupt), reskin template
correctness (a stray space in the `theme.css` selector yields invalid
CSS), and assorted pre-existing nits. Full list in the review ledger.
## Deliberately out of scope
- **Does not pin dark/light** — separate axis (theme toggle + per-skin
`--nw-dark-capable`).
- **Does not hide the inspector.** Locked-`banking`-with-inspector is
the intended FDE configuration.
- **Not a security boundary.** All four agents stay registered
server-side, so another skin's agent endpoint remains reachable under a
lock. `.env.example` says so explicitly.
## Verification
`pnpm lint` clean · `pnpm test:unit` 54 files / 335 tests · `pnpm build`
clean (the type-check gate) · zero static routes, `ƒ Proxy (Middleware)`
registered · locked e2e 12/12.
**One build artifact, served three ways, driven in a REAL BROWSER.** Raw
SSR HTML cannot substitute: the skin tree is entirely client-rendered,
so the server response contains no nav links at all. The hrefs — the
thing most likely to be wrong — only exist after hydration.
| Same build served… | `<title>` | `/` renders | nav hrefs | other
routes |
|---|---|---|---|---|
| `LOCK_SKIN=banking` | `Northwind Finance` | cards view **at `/`** |
`/`, `/dashboard`, `/charges`, `/team` | `/banking`, `/airline`, `/nope`
→ 404 page |
| `LOCK_SKIN=keel` | `Keel` | Desk **at `/`** | zero `/keel`-prefixed
hrefs in the DOM | `/knowledge/phi-access-policy` → doc reader, all 6
sections |
| unlocked | `CopilotKit Reskinnable Demo` | 307 → `/banking` |
`/banking`, `/banking/dashboard`, … | all four 200; switcher present |
Clicking a nav entry under a lock keeps the URL prefix-free with
`aria-current` on the correct entry. `GET /api/copilotkit/info` returns
200 under both locks and `public/sample-invoice-q2.pdf` still serves.
Airline and logistics were browser-verified locked as well.
**The e2e suite now has two projects**, because the lock is a boot-time
server env and the two deploy shapes are therefore two processes:
`unlocked` (port 3000) runs 17 tests, `locked` (port 3100,
`LOCK_SKIN=banking`, its own `.next-locked` dist dir) runs 12. Target
one with `--project=locked`.
## Known, pre-existing
**An unknown path under a lock renders the 404 PAGE but returns HTTP
200.** Not caused by the rewrite — on the unlocked build `/banking/nope`
is already 200, because `notFound()` raised from a client PAGE component
cannot change a status Next has already committed, whereas `notFound()`
from a layout can. The lock only changes which of those two paths an
unknown URL takes.
**The lint rule is sound, not complete** — deliberately, and documented
in the config. A URL assembled into a variable before `router.push(u)`,
or built with string concatenation, is not caught. Completeness would
require flagging shapes indistinguishable from legitimate code, and a
guard that misfires gets disabled.
**`next-env.d.ts` churns on e2e runs.** Next rewrites it to reference
whichever dist dir booted last, so a full run leaves it pointing at
`.next-locked`. Discard that hunk before committing; any build restores
it. Documented at the env block in `playwright.config.ts`.
`e2e/memory-learning.spec.ts` fails in this environment and reproduces
identically at base `77d99f6` — it exercises license-gated durable
memory and needs the Docker Intelligence stack. Not this branch.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[reviewdog/action-actionlint](https://redirect.github.com/reviewdog/action-actionlint)
| action | patch | `v1.73.0` → `v1.73.1` |
---
### Release Notes
<details>
<summary>reviewdog/action-actionlint
(reviewdog/action-actionlint)</summary>
###
[`v1.73.1`](https://redirect.github.com/reviewdog/action-actionlint/compare/v1.73.0...v1.73.1)
[Compare
Source](https://redirect.github.com/reviewdog/action-actionlint/compare/v1.73.0...v1.73.1)
</details>
---
### Configuration
📅 **Schedule**: (in timezone America/Los_Angeles)
- Branch creation
- "before 9am every weekday"
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/CopilotKit/CopilotKit).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xMi4wIiwidXBkYXRlZEluVmVyIjoiNDQuMTIuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->
The reskin skill is the only instruction a new skin's author reads, and it goes
stale SILENTLY: nothing type-checks it, no test imports it, and a skin built from
a stale template still compiles, lints and renders. There is no mechanism that
notices — only a person who thought to look.
This adds one standing question to every change to existing code: does it make
anything in `.claude/skills/reskin/` wrong, incomplete or misleading? Answered in
the PR body or commit message; "checked, no skill impact" is a fine answer. The
unanswered question is the failure, not a considered no.
Grounded in three real misses from the LOCK_SKIN root-serving change in this same
PR, all caught late and none by tooling:
- templates.md handed every new skin the two patterns that change had just removed
(a hardcoded `/${skin.id}/…` href, a fixed `pathname.split("/").slice(2)`). Both
fail silently under a lock — the page renders, the URL is just wrong.
- SKILL.md's verification steps pointed at `pnpm test:unit` and a drift test the
same PR deleted. Caught by a reviewer, not by a gate.
- The skill's authoring half was updated and its verification half was not; the gap
survived until it was asked about directly.
Includes a trigger table (contract change, required/forbidden call, a gate a skin
must pass, registration/routing/boundary, beat mechanism, brand or id, deleted or
renamed referenced file) so it is a lookup rather than a judgement call, and a
~2-minute grep check.
Skill-staleness check for THIS change: no impact. It is a process rule for people
editing the app, not guidance for people authoring a skin; no contract, gate,
command or path the skill references is altered.
Co-Authored-By: Claude <noreply@anthropic.com>
## Release monorepo v1.66.4
**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.66.4`
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.66.4`
- Creates git tag `monorepo/v1.66.4`
- 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.
## Release monorepo v1.66.3
**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.66.3`
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.66.3`
- Creates git tag `monorepo/v1.66.3`
- 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.
Mechanical documentation repairs for the Pydantic AI integration, found
while auditing its docs. **No content rewrites** — every change here is
a dead link, a wrong command, or a duplicate file, and each was verified
against the tree.
## Changes
| Fix | Evidence |
|---|---|
| Delete `shell-docs/.../pydantic-ai/quickstart/` (`pydantic-ai.mdx` +
`meta.json`) | `seo-redirects.ts` rule **F6** already routes
`/pydantic-ai/quickstart/pydantic-ai` → `/pydantic-ai/quickstart`; adk
has the identical **F7** rule and no such directory. pydantic-ai was the
**only** framework of 17 still carrying a `quickstart/` subdir alongside
the canonical `quickstart.mdx`. |
| `human-in-the-loop/agent.mdx` — quickstart link | Pointed at the
redirected legacy path; now points at `/pydantic-ai/quickstart`
directly. |
| `human-in-the-loop/agent.mdx` — starter link |
`examples/coagents-starter-pydantic-ai` does not exist. Now
`examples/integrations/pydantic-ai`. |
| `docs-links.json` — `subagents.shell_docs_path` | Was
`/multi-agent/subagents`; there is no `multi-agent/` directory. Real
page is `/multi-agent-flows`, which the entry's own `og_docs_url`
already pointed at. |
| `headless-simple/chat.tsx` — console tag | Said
`[langgraph-python:headless-simple]` inside the pydantic-ai package.
This sits inside an `@region` block, so it is pulled into the docs as a
snippet. |
| `pydantic-ai-todos/README.md` — troubleshooting command | `uv run
src/main.py`; that file does not exist in this tree (entrypoint is
`agent/main.py`, which `scripts/run-agent.sh` gets right). |
| `pydantic-ai-todos/README.md` — Python floor | Said 3.12+;
`agent/pyproject.toml` declares `requires-python = ">=3.13"`. A 3.12
user hits a `uv sync` resolver error. |
| `canvas/pydantic-ai/README.md` — prerequisites | Said Python 3.8+, but
`agent/agent.py:100` uses a PEP 604 union (`str \| None`), which
requires 3.10+ at runtime. Aligned to the sibling tree pinning the same
`pydantic-ai-slim==2.22.0`. Node floor aligned to the two sibling
READMEs. |
## Deliberately not included
- **The `human-in-the-loop.mdx` / `human-in-the-loop/index.mdx` route
collision.** Both resolve to `/pydantic-ai/human-in-the-loop`, and
pydantic-ai is the only framework with both. Resolving it means choosing
which page survives — the flat file has the correct `pydantic-ai` demo
embed, the directory matches the house structure. That is a content
decision, tracked in OSS-777 along with the related `meta.json` nav
omission.
- **11 other integrations carry the same
`[langgraph-python:headless-simple]` console tag.** Left for the fleet
sweep rather than fixed piecemeal here.
- Two candidate findings were **dropped after verification**:
`/pydantic-ai/generative-ui` is not a dead link (no framework has a
`generative-ui/index.mdx` — it is the house pattern), and `uv run
main.py` in `docs/setup/channels-agent-setup.mdx` is correct (the
quickstart genuinely produces a `main.py` in a uv project).
## Related
- OSS-777 — the remaining pydantic-ai documentation drift (PARITY_NOTES
rewrite, `qa/*.md` sweep, per-demo READMEs teaching LangGraph APIs)
- #6379 — carries the v2-specific doc corrections
- #6381 — the D6 probe failures with the same root cause
## Verification
Static: `docs-links.json` re-parsed and its new target confirmed to
exist; deleted paths confirmed unreferenced except by the F6 redirect
that supersedes them; every replacement path confirmed present on disk.
No Docker in the audit environment, so the docs site was not built —
worth a preview check on the nav after the `quickstart/` deletion.
Mechanical repairs found while auditing the pydantic-ai docs. Each was
verified against the tree; nothing here is a content rewrite.
- Delete `quickstart/pydantic-ai.mdx` + its `meta.json`. `seo-redirects.ts`
already routes `/pydantic-ai/quickstart/pydantic-ai` ->
`/pydantic-ai/quickstart` (rule F6), and adk got the same treatment (F7).
pydantic-ai was the only framework still carrying a `quickstart/`
subdirectory alongside the canonical `quickstart.mdx`.
- `human-in-the-loop/agent.mdx`: link to the canonical quickstart directly
instead of the redirected legacy path, and point the starter link at
`examples/integrations/pydantic-ai` — `examples/coagents-starter-pydantic-ai`
does not exist.
- `docs-links.json`: `subagents.shell_docs_path` was `/multi-agent/subagents`,
which has no page. The real page is `/multi-agent-flows`, which the
entry's own `og_docs_url` already pointed at.
- `headless-simple/chat.tsx`: the console tag said `langgraph-python` inside
the pydantic-ai package. This sits in an `@region` block, so it is pulled
into docs as a snippet. 11 other integrations carry the same copy-paste;
they are left for the fleet sweep.
- `examples/showcases/pydantic-ai-todos/README.md`: `uv run src/main.py` ->
`uv run main.py` (there is no `src/main.py` in that tree), and the stated
Python floor now matches `agent/pyproject.toml` (`>=3.13`).
- `examples/canvas/pydantic-ai/README.md`: Python 3.8+ was unrunnable —
`agent/agent.py` uses PEP 604 unions. Aligned to the sibling tree that
pins the same `pydantic-ai-slim==2.22.0`.
Tyler Slaton