Two independent docs-frontend improvements in `showcase/shell-docs`.
Rebased onto current `main` (the branch was 158 commits behind).
## 1. `<Tabs persist>` now actually persists
101 tab groups in the content tree are authored as `<Tabs groupId="..."
persist>`. The wrapper accepted both props and ignored them — the
comment in `docs-tabs.tsx` said so outright:
> `groupId` and `persist` are accepted and currently ignored
So every page reopened on its own default. A reader working through the
LangGraph guide in TypeScript had to reselect TypeScript on each page.
Fumadocs holds tab selection in local component state and exposes no
persistence hook, so the wrapper takes over the controlled
`value`/`onValueChange` pair and mirrors the pick into `localStorage`
under `shell-docs.tab.<groupId>`.
**Selection precedence**, strongest first:
| # | Source | Where it comes from |
|---|--------|---------------------|
| 1 | `urlDefault` | The framework-route override the page shell derives
from the URL (`TAB_DEFAULTS_BY_SLUG`) |
| 2 | Stored pick | `localStorage`, same `groupId` |
| 3 | `default=` | The author's value in the MDX |
| 4 | First item | Fallback |
The page shell passes its URL-derived value as a **separate `urlDefault`
prop** rather than overwriting `default`. This matters: 45 of the 101
`persist` groups also carry an author `default=`. Collapsing the two
sources into one prop ranks the author's default above storage, which
would leave the stored pick unreachable on almost half of the pages the
feature exists for. `language_langgraph_agent` appears both ways (30
sites with `default="Python"`, 8 without), so the same group would have
behaved inconsistently within one guide.
Two details worth noting for review:
- The stored value is read in an **effect**, not in the initial state,
so server and client render identical markup and hydration stays clean.
- Every `localStorage` read and write is wrapped in `try`/`catch`.
Private mode and quota errors leave the tabs fully working, just without
persistence.
## 2. API-key hints under `.env` snippets
The LangGraph quickstart tells the reader to put `OPENAI_API_KEY` in
`.env` and leaves them to go find the key page. `<ApiKeyHint
provider="openai" />` renders a muted one-line link under the snippet.
The component maps a provider id to a label and URL — `openai`,
`anthropic`, `google`, `langsmith`, `copilotkit`. An unknown id renders
nothing, so a typo degrades to today's behaviour instead of throwing. It
is navigational only: it neither reads nor writes a key. Both `.env`
steps on the LangGraph quickstart use it.
## Removed from this branch
The earlier revision led the LangGraph quickstart with a `<InlineDemo
demo="agentic-chat" />` block under a "See it working" heading. That is
gone, along with the `inline-demo.test.tsx` file that covered it —
`InlineDemo` is pre-existing `main` code this PR no longer touches.
Two tests in `docs-page-view-toc.test.tsx` were also dropped rather than
kept. They were named for this PR's components but did not exercise
them: `docs-page-view-toc.test.tsx` asserts on `DocsPage` props, and the
page body is never rendered. Verified by mutation — deleting
`ApiKeyHint` from the MDX registry left the test titled `renders the
LangGraph quickstart (InlineDemo + ApiKeyHint) without errors`
**passing**. Real coverage lives in `api-key-hint.test.tsx` instead.
## Testing
No CI job runs the `showcase/shell-docs` vitest suite.
`test_unit-showcase.yml` covers only `harness` and `shell-dashboard`;
`showcase_validate.yml` runs vitest only in `showcase/scripts`.
Everything below was therefore run locally.
**Full suite, branch vs. pristine `origin/main` in the same
environment** — `main` carries 6 pre-existing failures here, so the
failure *set* is the comparison, not zero:
```
base (origin/main) 843 tests, 6 failed
branch (this PR) 858 tests, 6 failed
NEW failures: none
```
The 6 are identical on both sides: `brand-nav` layout cap, 3 ×
`angular-docs-content`, `llm-text` mastra, `ms-agent-python-stable-api`.
**Mutation checks** — every new test was verified to fail when the
mechanism it claims to cover is broken:
| Mutation | Result |
|----------|--------|
| `canPersist = false` (persistence off) | ✅ `persists a groupId pick
and reapplies it on a fresh mount` fails |
| Author `default` outranks storage (the pre-fix precedence) | ✅ `ranks
a stored pick above the author's MDX default` fails |
| `urlDefault` demoted below author `default` | ✅ `ranks a urlDefault
above the author's MDX default` fails |
| `ApiKeyHint` removed from the MDX registry | ✅ `is registered as an
MDX component` fails |
| `href={meta.url}` → `href={undefined}` | ✅ 5 of 7 `ApiKeyHint` tests
fail |
**End-to-end render** — `ApiKeyHint` was rendered through the real
`MDXRemote` pipeline (same `remarkGfm` options, nested in
`<Steps>/<Step>` as the quickstart uses it) to confirm the `provider`
prop survives compilation and the anchor reaches the HTML:
```
✓ ApiKeyHint through the real MDX pipeline > survives compilation with its provider prop
expect(html).toContain("https://platform.openai.com/api-keys")
```
**Typecheck and lint** (`showcase/shell-docs`):
```
$ npx tsc --noEmit → exit 0
$ npx oxlint . → Found 28 warnings and 0 errors
$ npx oxfmt --check <touched files> → All matched files use the correct format
```
The 28 lint warnings are pre-existing. The only two in a file this PR
touches (`mdx-registry.tsx`) are `iframe-missing-sandbox` on
pre-existing `InlineDemo` iframes, untouched here.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added inline API key guidance below relevant documentation code
blocks, with links to provider credential pages.
* Added tab selection persistence across documentation pages, with
support for URL and author-defined defaults.
* Added API key guidance to the LangGraph quickstart.
* **Tests**
* Added coverage for tab persistence, selection precedence, invalid
values, disabled persistence, and API key hint behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
A self-review of the previous commit found three gaps.
- Nothing tested that the page wires the fixes up. A new test walks the
rendered `DocsPageView` tree, asserts `blockJS` is off in the page's
own MDXRemote options, and renders the registered `CTACards` override
to confirm it prefixes card hrefs with the framework being read.
Removing either the option or the override fails it.
- The compile test asserted `grid-cols-1`, which the two-column class
also contains, so the `columns` half of that test proved nothing. It
now asserts the absence of the `sm:` variant.
- The per-page test guarded the extracted href count but not the title
count, so a regex that matched no titles would have passed silently.
Also correct the component comment: four content files author the
block, but the pydantic-ai one is shadowed by a sibling leaf file and
renders nowhere.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The component fix alone was inert on the real page. next-mdx-remote 6
defaults `blockJS` to true, which runs a remark plugin that deletes
every JSX attribute whose value is an expression. On the docs route
`<CTACards columns={2} cards={[...]} />` reached the component with no
props at all, so it still rendered an empty grid. The unit tests passed
because they call the component directly and skip the MDX pipeline.
- Turn `blockJS` off for the docs route. Every source there is
first-party content from `src/content`. `blockDangerousJS` keeps its
default. The other MDXRemote call sites keep the default too, because
`ag-ui/introduction.mdx` authors inline `onMouseEnter` handlers that
the stripping currently keeps out of a server component.
- Resolve each card href against the framework being read. The cards
render through the registry `Card`, so they never reached the
href-resolving `Card` override, and a reader on
`/ms-agent-python/human-in-the-loop` was redirected to the .NET page.
Content now authors the hrefs root-relative.
- Stack the grid to one column below the `sm` breakpoint. An inline
`grid-template-columns` cannot be overridden by a class, so the two
cards stayed 157px wide side by side on a 390px viewport.
- Pass each description through the `Card` `description` prop, the same
as every other card grid in the docs.
- Match `iconKey` against own properties only.
- Add a test that compiles the four authored blocks through the MDX
pipeline, which is the check the earlier tests were missing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`CTACards` accepted only `children`, but every call site in content
authors `<CTACards columns={n} cards={[...]} />` self-closing. Both
props were dropped, so the grid rendered empty and the pages lost
their links with no error anywhere.
Four human-in-the-loop landing pages are affected: crewai-flows,
mastra, pydantic-ai, and microsoft-agent-framework.
The component now renders each entry through the shared `Card`, honors
`columns` in the grid template, and falls back to wrapping `children`
so legacy `<CTACards>...</CTACards>` authoring keeps working — the same
prop-or-children contract `EcosystemTable` uses in this file.
`iconKey` values on these cards are lucide names, not the framework
keys in `customIcons`, so they get their own lookup. An unregistered
key renders the card without an icon rather than throwing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The LangGraph quickstart tells the reader to put `OPENAI_API_KEY` in
`.env` and leaves them to find the key page themselves. `<ApiKeyHint
provider="openai" />` renders a muted one-line link under the snippet.
The component maps a provider id to a label and a URL, covering openai,
anthropic, google, langsmith and copilotkit. An unknown id renders
nothing, so a typo degrades to the current behaviour instead of
throwing. It is navigational only: it neither reads nor writes a key.
Both `.env` steps on the LangGraph quickstart use it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## The problem
Every Channels page that tells a reader what to install named a pair
that is four minors stale:
```sh
npm install --save-exact @copilotkit/channels@0.6.1 @copilotkit/runtime@1.65.0
```
That pin is not merely old, it is load-bearing in the wrong direction.
`@copilotkit/channels@0.6.1`
does not export `defineChannelComponent`. Compiling an agent-rendered
component against the version
our own quickstart installs fails outright:
```
error TS2724: '"@copilotkit/channels"' has no exported member named
'defineChannelComponent'. Did you mean 'ChannelComponent'?
```
The export listing confirms where the boundary sits.
`@copilotkit/channels-core@0.6.1` ships
`defineChannelCommand` and `defineChannelTool` and nothing else in that
family; `defineChannelComponent`
first appears in the 0.6.2 canary line and first ships stable in 0.7.0.
So the two halves of our own documentation disagree. The Channels setup
guide gates success on "at
least one `defineChannelComponent` must render," while the reference
page and both provider
quickstarts hand the reader a version in which that success criterion
cannot be satisfied. A builder
following the docs faithfully reaches a compile error, and the error
blames their code rather than
our pin. The bad trade they make next is guessing — dropping
`--save-exact`, reaching for `@latest`,
or abandoning agent-rendered components entirely, each of which discards
the tested-pair guarantee
the pin existed to provide.
The timing is what makes this worth a same-day fix rather than a queued
one. The "Agents, Everywhere"
global hackathon runs Saturday 12 September 2026 across 51 cities with
CopilotKit as a global
sponsor, and these are precisely the pages participants will open first.
## The approach
Every pinned pair in the Channels docs moves to
`@copilotkit/channels@0.9.2` +
`@copilotkit/runtime@1.70.2`, the current published pair as of
2026-09-08. Five install lines across
the reference index, the direct-adapters reference, the
deploy-and-operate how-to, and the Slack and
Teams quickstarts.
**The pin is what changes, not the prose.** Where a page's guidance
implies agent-rendered components
are available, that guidance was already correct — it was the version
underneath it that was wrong.
Nothing about the described behaviour is edited.
**The direct-adapters availability note moves too.** It read "their
direct adapters already ship in
`@copilotkit/channels@0.6.1`," an availability claim rather than a
first-shipped-in claim, sitting
directly above an install block that now names 0.9.2. Leaving it would
make the page contradict
itself within fifteen lines.
**The SDK reference index gains the tested-pair framing it was
missing.** The quickstarts and the
deploy-and-operate page already explain that the two packages ship as a
tested pair and must be
upgraded together; the reference index pinned exact versions while
explaining nothing, which is how a
pin decays into a number nobody knows they may not touch.
**One file outside the docs content changes, and the cost is worth
naming.**
`src/lib/__tests__/channels-docs.test.ts` asserts the quickstarts
contain the exact tested install
string, so it hard-codes the pair. Updating the docs without it produces
a red PR. Only the two
version constants move; no assertion is added, removed, or loosened.
## What is not covered
- **No recording.** The change is text in six files with no runtime
surface to demonstrate. The
durable evidence is the export listing above, which is reproducible from
the registry rather than
from this branch.
-
`showcase/shell-docs/src/content/reference/channels/functions/createChannel.mdx:114`
still reads
"Channels 0.6.1 warns when enumerable fields are dropped." This is a
behaviour-provenance note, not
an install pin, and rewriting the number would change a factual claim
about when the behaviour
changed. It needs a maintainer to say whether it means "as of 0.6.1" or
"in 0.6.1."
- `skills/setup-slack-channel/SKILL.md:81` and
`skills/setup-slack-channel/references/troubleshooting.md:8`
reference `@copilotkit/channels@0.6.0` and `@copilotkit/runtime@1.65.0`
— an even older pin, and one
the guard test explicitly calls "the broken Channels 0.6.0 release."
Same class of bug, outside docs
content, left for a separate decision.
- The three `doctest.json` files pin `@copilotkit/runtime@1.68.3`, also
stale, also a different
purpose.
- `CopilotKit/channels-sdk` carries the same stale install line in
`.agents/skills/build-channels-agent/SKILL.md`. Different repository.
- The docs do not document `defineChannelComponent` anywhere, despite
the setup guide gating success
on it. That gap is not addressed here.
- The guard test could ratchet against 0.6.1 and 1.65.0 the way it
already ratchets against 0.5.0,
0.6.0, and 1.64.2, which would stop this recurring. Deliberately not
added, to keep the diff to the
bug.
## Verification
Registry state re-checked at edit time: `npm view @copilotkit/channels
version` → `0.9.2`,
`npm view @copilotkit/runtime version` → `1.70.2`.
Export boundary confirmed by unpacking the published tarballs:
`channels-core@0.6.1` has no
`defineChannelComponent`; `0.6.2-canary.1785779327`, `0.7.0`, `0.7.1`,
and `0.9.2` all have it.
All 10 assertions in the `channels-docs` guard test's install and
Node-version blocks were replayed
against the edited files for both provider quickstart slugs — 20 checks,
all passing. The `--save-exact`
negative lookaheads still hold: the docs contain no unpinned
`@copilotkit/channels` or
`@copilotkit/runtime` install, no `@latest` or `@next` tag, and none of
the previously blocked 0.5.0,
0.6.0, or 1.64.2 versions.
`grep` across `showcase/shell-docs/src` returns no remaining
`channels@0.6.1` or `runtime@1.65.0`.
No new test files. No source, config, or lockfile changes.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated channel, Slack, Teams, and direct adapter setup guides with
the latest pinned SDK versions.
* Updated the channel reference documentation to reflect the current
package versions.
* **Tests**
* Updated documentation checks to validate the newer SDK versions in
provider quickstarts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The Channels pages pinned @copilotkit/channels@0.6.1 with
@copilotkit/runtime@1.65.0, four minors behind the current release.
Anyone following them installs a Channels version that predates
defineChannelComponent, which landed in 0.7.0, so agent-rendered
components cannot compile.
Update every pinned pair in the Channels docs to
@copilotkit/channels@0.9.2 + @copilotkit/runtime@1.70.2, refresh the
direct-adapters availability note that named 0.6.1, and add the
tested-pair framing to the SDK reference index, which pinned versions
without explaining that the two ship and upgrade together.
Also updates the pinned constants in the shell-docs guard test, which
asserts the quickstarts contain the exact tested install string.
`generative-ui/tool-based` is the terminal page every onboarding run fetches,
and its `## How it works in code` section renders a per-framework snippet.
Nine frameworks shipped no snippet, so the section rendered nothing and the
silence meant both "no agent-side wiring is needed" and "wiring is needed and
nobody wrote it down".
Each verdict was read out of the pinned adapter rather than the docs:
- ag2: `run_stream` builds `client_tools` from `incoming.tools`.
- mastra: the adapter reduces `input.tools` into `clientTools`.
- strands, strands-typescript: a proxy tool per forwarded tool is registered
in the agent's tool registry, and a native tool of the same name wins.
- agno: its AG-UI interface never reads `RunAgentInput.tools`, so a component
needs an `external_execution=True` stub and a `db` for the paused run.
- deepagents: `CopilotKitMiddleware` merges `copilotkit.actions` into
`request.tools`, so the middleware is load-bearing.
- built-in-agent: config mode forwards for you, a factory does not. It is also
the root framework, so this is the unscoped default page.
The two .NET columns rest on their own demo agents, which render charts with
an empty tool list. No .NET SDK was available to read the NuGet hosting
package.
REQUIREMENT_NOT_ESTABLISHED is now empty. The shape test pins each snippet,
and setup-concept.test.ts no longer depends on ag2 being an open gap.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Announce recommendation selection without invalid active descendants, omit
missing controlled elements, and cover empty-result and result-slot behavior.
Report snippet expansion failures and reject partially staged content roots
before either search index is overwritten.
Validation: 829 tests pass; three Angular/Mastra content failures already
reported in PR #6887 remain. Typecheck and lint pass (existing lint warnings).
Browser-verified local search, keyboard selection, and recommendation navigation.
## Summary
- carry Intelligence thread, memory, and annotation requests through the
single Runtime endpoint
- advertise the bridge through an optional Runtime info capability
- reuse the existing REST route matcher, handlers, method checks, hooks,
and memory gate
- route Core memory and React annotation calls through the negotiated
Runtime fetch
- make single-route the documented Intelligence quickstart while keeping
multi-route supported
## Compatibility
- Multi-route behavior does not change.
- A new client uses the bridge only when a single-route Runtime
advertises it.
- An old client ignores the new optional capability.
- A new client keeps the old behavior with a Runtime that does not
advertise the capability.
## Validation
- `pnpm nx run-many -t check-types,build
--projects=@copilotkit/shared,@copilotkit/core,@copilotkit/runtime,@copilotkit/react-core`
- package pre-commit gate: tests, `publint`, and `attw` passed for all
affected packages
- Runtime focused suite: 102 tests passed
- Core focused suite: 108 tests passed
- React focused suite: 53 tests passed
- React full suite: 1,591 Vitest tests and 47 script tests passed
- Angular and React memory tests: 18 tests passed
- docs type-check and production build passed
- changed docs contract tests: 33 tests passed
## Local baseline notes
The full docs test command also reads Git LFS images and generated
cross-framework fixtures. It has six unrelated failures in this
checkout: three image-pointer checks, two Angular content checks, and
one Mastra content check. The changed docs tests pass, and the docs
production build passes.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added single-route support for thread, memory, and annotation
operations.
- Runtime capability discovery now advertises single-route resource
support.
- Resource requests preserve paths, query parameters, headers, methods,
and request bodies.
- Memory and annotation operations consistently use the configured
runtime transport.
- **Documentation**
- Updated setup guides for single-route configuration, capability
negotiation, and compatibility.
- Added guidance for single-route LangGraph deployments.
- **Tests**
- Added coverage for transport behavior, validation, resource
operations, and error handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Pin Intelligence in the header and sidebar, add an Explore docs mega menu, and collapse top-level sidebar sections so people do not have to scroll past a long list to reach Intelligence.
Two legacy docs URLs have been dead ends for six months. Neither has
anything to do with the recent `premium/` → `intelligence/` rename —
they are older, and the rename only moved where they fail.
## `/premium/inspector` — 404
`cc8c945893` ("refactor(docs): optimize structure, content and
navigability", 2026-02-23) renamed `(root)/premium/inspector.mdx` to
`(root)/inspector.mdx` as an `R100` rename — identical content. The page
still exists and `/inspector` serves it. Only the old URL was left
behind, and it has 404'd ever since. It shows up in
`analytics_postgres_contacts.hs_analytics_source_data_1` as a HubSpot
first-touch page, so it had real traffic.
## `/direct-to-llm/guides/premium/*` — wrong page, 200
All four pages under that path (overview, headless-ui, observability,
inspector) were deleted in the same commit. The `R16`
`/direct-to-llm/:path*` wildcard strips the prefix and the remainder
falls through to the docs home, so the reader gets a 200 and the wrong
page. That is why it went unnoticed longer than a 404 would have —
nothing looks broken. `/direct-to-llm/guides/premium/headless-ui` is
also in the HubSpot first-touch data.
`cc8c945893` had no redirect config to update: `seo-redirects.ts` did
not exist yet. The gap is that nobody back-filled these when it was
built.
## What this adds
33 exact entries:
- `INTEL-inspector-root`: `/premium/inspector` → `/inspector`
- `INTEL-inspector×<fw>`: `/<fw>/premium/inspector` →
`/<canonical-fw>/inspector`, expanded over `PREMIUM_URL_FRAMEWORKS`
exactly as the observability entries are
- `INTEL-d2l-guides-*`: the four `/direct-to-llm/guides/premium/*`
pages, each to its current equivalent (the retired observability page
goes to the overview, matching `INTEL-observability-*`)
Both hosts get them, plus the harness copy. `P7` renames `/premium/*` to
a docs-host `/intelligence/*` on the way across, so without the shell
entry the legacy shell URL would 301 into a docs-host 404 — the same
reasoning the `INTEL-observability-root` comment already spells out. The
harness driver is the declared intentional copy of the shell list and
moves with it.
## Why exact entries
Middleware builds `exactMap` from every source without `:path*` and
checks it before the wildcard list. `INTEL-rename-wild` would otherwise
rewrite `/premium/inspector` to a nonexistent `/intelligence/inspector`.
Same mechanism that makes the observability entries work today.
## Verification
- All 24 distinct destinations probed against staging: 22 return 200.
`/langroid/inspector` and `/spring-ai/inspector` 404 — those two
framework surfaces are not served at all, their bare roots and
quickstarts 404 too, and the existing observability entries carry the
same property. No reachable URL changes behavior.
- Catalogue check over all 463 exact sources: no duplicate source, no
self-loop, no wildcard among the new entries.
- `showcase-harness`: 177 test files, 3728 tests pass.
`showcase-scripts`: 78 files, 2543 tests pass. shell-docs lint and
typecheck clean; its redirect suite goes from 10 to 13 tests.
- Decommission fixtures regenerated through the CLI with
`--events-json`, not through the core module, so the byte-for-byte
cross-check between CLI and core keeps its meaning. The diff is 390 →
395 defined, 377 → 382 zero-hit, plus the five new ids.
## Not verifiable in production yet
`docs.copilotkit.ai` has not been promoted since #6818 merged, so
production has no `/intelligence/*` tree and serves `/premium/*`
directly. Everything above was measured on staging, where the rename and
its redirects are live. Reviewing these URLs against production will
show the old behavior until `shell-docs` is promoted.
## Left alone
- `/integrations/direct-to-llm/guides/premium/headless-ui` also 404s,
but there is no `/integrations/direct-to-llm/:path*` rule at all, so
that is a wider gap about the `/integrations/*` prefix rather than this
one.
- `docs/superpowers/plans/2026-08-03-ent-1173-…md` still names the old
content path. It is a record of a finished plan and describes what was
true then.
Adds a five-minute quickstart for connecting an existing CopilotKit app
to Intelligence. Developers can use a coding-agent prompt or follow
framework-specific manual steps. The guide ends with a saved-thread
check in Inspector.
Linear:
[OSS-1076](https://linear.app/copilotkit/issue/OSS-1076/add-a-quickstart-for-intelligence)
## What changed
- Added the Intelligence quickstart to the docs navigation and overview.
- Added setup examples for React, Vue, Angular, and React Native.
- Added Inspector checks for browser apps and a hosted-project check for
React Native.
- Updated the coding-agent prompt with route, identity, and
authorization requirements.
- Updated Next.js and TanStack Start adapters to forward thread mutation
methods.
## Testing
Commands run:
- `npm exec -- vitest run
src/lib/__tests__/intelligence-quickstart-docs.test.ts
src/lib/__tests__/docs-render.test.ts
src/lib/__tests__/rich-threads-setup-docs.test.ts
src/components/__tests__/rich-threads-setup-prompt.test.tsx`: 39 tests
passed.
- `npm run typecheck`: passed.
- `npm run lint`: passed with existing warnings in unrelated files.
- `npm run build`: passed.
- The pre-commit package, binary, environment-name, lint, and commit
checks passed.
The full shell-docs test run still has unrelated Windows failures in
asset, generated Angular content, and LLM text tests.
Manual test:
1. Start shell-docs and open `/intelligence/quickstart`.
2. Select React, Vue, Angular, and React Native in the frontend
selector.
3. Check that each frontend shows its matching provider example.
4. Check that browser frontends use Inspector to find the new thread.
5. Check that React Native uses the hosted Intelligence project instead.
The new contract test checks the route, navigation, framework examples,
agent prompt, and Inspector completion path.
## Risk / rollback
Risk is low because this PR changes documentation and examples only.
Revert the commit to remove the quickstart and restore the prior adapter
examples.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added an Intelligence quickstart guide covering project setup,
authentication, thread authorization, runtime integration, frontend
configuration, and connection verification.
- Added the quickstart to Intelligence documentation navigation and
linked to it from the overview page.
- Expanded setup guidance with browser and React Native steps for
creating threads and sending messages.
- **Documentation**
- Updated Next.js and TanStack Start examples to forward all Runtime
methods, including `PATCH` and `DELETE`.
- Clarified authentication and thread ownership requirements for Runtime
routes and operations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The "Copy agent prompt" button already told the CLI's onboarding graph
which agent framework the reader had selected. The docs carry a second
selector — Frontend — whose choice the prompt dropped, so the graph still
had to ask which frontend to configure.
Add a frontend sentence built exactly like the framework one and placed
between it and the page sentence, which is the order the graph works in:
it settles the agent framework first, then the frontend. Each sentence
leads with its own subject and can be empty independently, so all four
combinations read correctly.
The docs frontend is resolved from the URL, never from a stored
preference — choosing a frontend navigates to another URL, so the URL is
what asserts the selection. This is the rule the selector itself applies
(`urlFrontend ?? "react"`), and the same standard the framework sentence
already holds to. Resolution happens server-side and reaches the button
as a prop, so it cannot drift from the page being rendered.
Why `react` maps to the graph's `nextjs`: every frontend prompt under
`apps/cli/onboarding-prompts/frontend/` names the docs page it belongs
to, and `nextjs.md` is the only one whose documentation link is the
UNPREFIXED https://docs.copilotkit.ai/quickstart.md — the docs' default
`react` frontend, served at the root. Every other prompt points at its
own prefixed page (`/vue.md`, `/angular.md`, `/react-spa.md`,
`/react-native.md`). Same frontend, spelled differently on each side.
Slack and Teams stay deliberately unmapped. They are chat channels, not
application frontends; the graph has no node for either, so naming one
would promise a path the CLI cannot walk. The analytics `frontend`
property follows the same rule as `agent_framework`: the graph slug, and
the key omitted entirely when there is no equivalent.
A guard test over the docs frontend registry reads `FRONTEND_OPTIONS` —
the same list the app itself renders — so adding a frontend forces a
mapping decision instead of silently producing no sentence.
copilotkit-qa-bot[bot]