mirror of
https://github.com/CopilotKit/CopilotKit.git
synced 2026-09-14 16:26:20 +08:00
Ben Taylor
fa6041fc7b
## Problem
A developer on the Learning pane clicks **Copy setup prompt** and gets a
prompt for **Threads**.
Three sites hard-coded the Threads tile as the feature target on a pane
whose own `serviceId` is `memory`:
- `handleLearningSetupCopy` called
`getHomeFeaturePromptTarget("threads")`.
- the locked Learning overview passed `setupPrompt: { serviceId:
"threads" }`.
- `cpk-learning-view`'s `.setupPrompt` was built from `"threads"`.
The mislabelling reached the reader, not just the internals: the
button's `aria-label` and its live-region announcement both read
"Threads setup prompt copied" under the heading "Turn every interaction
into reusable context." After #7004 moved these buttons onto the CLI
intent routes, the copied text read `--intent add-rich-threads` —
equally wrong, on the same three lines.
#7004 left them alone on purpose, because the target looked like a
product decision rather than a naming slip.
## Why it is a bug and not a flow
Threads-first was the defensible reading: Learning needs threads, so
send the developer to set up Threads first. Three checks say that
premise is false.
1. **Learning works with no thread routes at all.** A runtime mounted
`mode: "single-route"` serves no `threads/*` route, and Learning still
binds Containers — the binding happens server-side while a run starts,
in the Intelligence run handler, independent of the mount. Intelligence
PR #1198 proves a full round trip and Container assignment on exactly
that shape.
2. **The Inspector does not gate it.** `learningOn` reads the `memory`
tile and `threadsOn` reads `threads`, independently. Nothing conditions
one on the other.
3. **The route does not require them.** `feature/learning/start.md`
lists existing thread routes among the things it *inspects*; its only
hard stop is a project with no CopilotKit app.
So the target was the bug. The intent table in `onboarding-prompt.ts`
already maps `memory` to `add-learning`, and its comment already says
why — the tile is the Learning tile, enabled by a configured Learning
Container, "which is exactly what `feature/learning` sets up". These
three call sites were the leftover.
Pointing at `add-learning` is also the more robust answer: that route
inspects its own prerequisites and refuses cleanly through
`feature/stop` when one is missing, instead of this pane hard-coding a
guess at which prerequisite matters.
## Evidence
RED first. Two existing tests pinned the wrong behavior by asserting the
Learning preview's button is the `"threads"` one; inverted to
`"memory"`, they failed with `expected null not to be null` — the
Learning button did not exist. They now also assert what actually
reaches the clipboard (`--intent add-learning`) and that the accessible
label says Learning rather than Threads.
```
@copilotkit/web-inspector test 697 passed (38 files)
@copilotkit/web-inspector check-types clean
oxfmt --check on both changed files clean
```
## What is deliberately unchanged
- `renderThreadsView` keeps its own `serviceId: "threads"`. It is the
Threads pane.
- The Home Threads tile keeps its target, and its test still reaches it
through `clickHud("threads")`.
- `inspector-metadata.spec.ts`'s Threads-tab assertion is untouched for
the same reason.
Only the Learning pane borrowed the Threads target, and only that
borrowing is removed.
Closes OSS-1151.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Updated the Learning setup prompt to target the correct Learning
feature.
* Copied setup instructions now provide Learning-specific configuration.
* Updated the setup prompt button’s accessibility label to identify
Learning correctly.
* Learning onboarding no longer requires the Threads feature.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->