Authoritative wire shape for the Action.Submit button + the Message activity Teams
delivers on click (activity.value carries { ckActionId, value }, text empty; not
Action.Execute). Round-trip contract test locks emit↔decode.
finish() now performs the final send outside the error-swallowing throttle path
and rejects on transport failure, so a consumer never marks a turn delivered when
the last post/update didn't land. Mid-stream edits stay tolerant (log + retry).
## Release channels-whatsapp v0.0.2
**Scope:** `channels-whatsapp` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels-whatsapp` packages to `0.0.2`
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-whatsapp` packages to npm at version `0.0.2`
- Creates git tag `channels-whatsapp/v0.0.2`
- 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 channels-telegram v0.0.4
**Scope:** `channels-telegram` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels-telegram` packages to `0.0.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 `channels-telegram` packages to npm at version `0.0.4`
- Creates git tag `channels-telegram/v0.0.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 channels-intelligence v0.1.1
**Scope:** `channels-intelligence` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels-intelligence` packages to `0.1.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-intelligence` packages to npm at version
`0.1.1`
- Creates git tag `channels-intelligence/v0.1.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 channels-teams v0.1.2
**Scope:** `channels-teams` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels-teams` packages to `0.1.2`
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-teams` packages to npm at version `0.1.2`
- Creates git tag `channels-teams/v0.1.2`
- 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 channels-slack v0.1.2
**Scope:** `channels-slack` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels-slack` packages to `0.1.2`
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-slack` packages to npm at version `0.1.2`
- Creates git tag `channels-slack/v0.1.2`
- 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 channels-discord v0.0.3
**Scope:** `channels-discord` | **Bump:** `patch`
---
### How this release process works
1. **This PR was created automatically** by the "release / create-pr"
workflow.
It bumped the `channels-discord` packages to `0.0.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 `channels-discord` packages to npm at version `0.0.3`
- Creates git tag `channels-discord/v0.0.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.
## Problem
`@copilotkit/channels-intelligence` still used the retired Bot
HTTP/realtime contract and exposed Phoenix implementation details. The
managed Slack entrypoint used the same legacy API.
## Why
Intelligence now exposes a clean-break Channels contract. The SDK must
use it consistently, while keeping the Phoenix-backed transport private
behind a product-neutral Realtime Gateway API. Compatibility aliases
would hide integration mismatches.
## Fix
- Migrated HTTP paths, payloads, config, and KV state to Channel
terminology.
- Added the Realtime Gateway abstraction and Channel realtime wire
contract.
- Renamed remaining APIs/types, updated the managed Slack example, and
added forbidden-term coverage.
- Preserved framework and vendor `Bot` terminology only where it remains
semantically correct.
## Summary
Adds production onboarding for the Inspector Threads empty state:
- Moves the Threads `Talk to an Engineer` CTA into the main inspector
tab nav when Threads is active.
- Replaces the enabled-empty `No threads yet` state with example thread
rows and a deselected overview.
- Lets users select an example thread to preview the real thread-details
UI with Timeline, Raw AG-UI Events, and State data.
- Adds a dismissible/reopenable example tour that persists dismissal in
local storage.
- Hides examples once real threads are present.
- Adds the `Learn how Threads work` and `Explore self-hosted
Intelligence` CTAs.
- Adds a deferred autoplay video preview to the enabled-empty deselected
overview.
## Telemetry
New/updated Threads events in this PR:
- `oss.inspector.threads_tab_clicked` — fires when the rendered Threads
nav tab is clicked.
- `oss.inspector.threads_locked_viewed` — fires once per inspector
instance for the locked state.
- `oss.inspector.threads_empty_enabled_viewed` — fires once per
inspector instance when Threads are enabled with zero real threads.
- `oss.inspector.threads_enabled_viewed` — fires once per inspector
instance when real threads are present.
- `oss.inspector.threads_intelligence_signup_clicked` — fires from
locked-state Intelligence signup CTAs.
- `oss.inspector.threads_talk_to_engineer_clicked` /
`oss.inspector.talk_to_engineer_clicked` — fire from Threads-specific
and shared Talk to an Engineer CTAs.
- `oss.inspector.threads_example_viewed` — fires once per example thread
shown in the empty state.
- `oss.inspector.threads_example_selected` — fires once per example
thread selection.
- `oss.inspector.threads_example_tour_started` — fires when the tour
auto-starts for the first selected example.
- `oss.inspector.threads_example_tour_step_viewed` — fires once per
example thread/tour step.
- `oss.inspector.threads_example_tour_dismissed` — fires when the user
skips the tour.
- `oss.inspector.threads_example_tour_completed` — fires when the user
finishes the tour.
- `oss.inspector.threads_example_tour_reopened` — fires when the user
clicks `Show tour` after dismissal.
Telemetry properties are limited to product metadata and funnel context:
package/version, inspector distinct IDs,
intelligence/thread-service/license/runtime status, runtime URL type,
CTA surface/type, telemetry-disabled status, thread count, example
thread ID, tour step/tab, and dismiss method. We do **not** send message
content, AG-UI event payloads, agent state, prompts, completions, or
thread bodies.
No telemetry was added for passive video loading; it is a visual
affordance rather than a user intent signal.
## Outbound Attribution
Threads onboarding CTAs now include existing `ref` attribution plus
these UTM parameters:
- `utm_source=copilotkit_inspector`
- `utm_medium=in_product`
- `utm_campaign=threads_onboarding`
Affected links are limited to Threads onboarding surfaces:
- Threads tab-nav `Talk to an Engineer`
- Threads locked-state `Sign up for Intelligence`
(`https://dashboard.operations.copilotkit.ai/sign-in`)
- Empty Threads overview `Learn how Threads work`
- Empty Threads overview `Explore self-hosted Intelligence`
The UTM params are opt-in for these Threads onboarding CTAs and do not
apply to generic announcement/banner links or locked Memories CTAs. The
inspector spec includes a regression test to keep locked Memories CTAs
free of the Threads campaign params.
## Video Asset + Performance
- The overview video uses the CDN-hosted asset at
`https://cdn.copilotkit.ai/corp-site/videos/copilotkit-generative-ui-agentic-frontend-demo.webm`
instead of committing a binary to `@copilotkit/web-inspector`.
- Verified the URL serves `200`, `Content-Type: video/webm`,
`Content-Length: 6765736`, and a CloudFront cache hit.
- `@copilotkit/web-inspector` currently only inlines CSS and SVG assets
in its package build, while larger docs/showcase media commonly lives on
hosted/CDN-style URLs.
- The video `src` is not rendered on the initial overview paint. It is
deferred until `requestIdleCallback` or a short timeout fallback, uses
`preload="metadata"`, fades in after `loadeddata`, and does not load for
`prefers-reduced-motion: reduce`.
## Validation
- `NX_TUI=false npx -y pnpm@10.33.4 nx run
@copilotkit/web-inspector:test -- web-inspector.spec.ts`
- `NX_TUI=false npx -y pnpm@10.33.4 nx run
@copilotkit/web-inspector:check-types`
<img width="1662" height="1382" alt="CleanShot 2026-07-10 at 12 01
03@2x"
src="https://github.com/user-attachments/assets/e2031570-f602-40dc-a54c-e9c7690fc0ba"
/>
<img width="1680" height="1388" alt="CleanShot 2026-07-10 at 12 01
12@2x"
src="https://github.com/user-attachments/assets/2c8db42f-3ab0-47e2-a235-ea54e8dd292b"
/>
## Problem
A managed bot with **both** a Slack and a Teams adapter attached only
ever received its **Slack** deliveries. Teams deliveries stayed `queued`
forever — never claimed, never sent.
## Root cause
`channels-intelligence`'s runtime claim loop (`http-transports.ts` →
`claimOnce()`) posted a per-provider filter to
`/api/bots/listener/claim`:
```ts
{
runtimeInstanceId: this.cfg.runtimeInstanceId,
adapters: [this.cfg.adapter], // defaults to "slack"
}
```
app-api filters claimable deliveries by that list (`$adapters IS NULL OR
bie.provider = ANY($adapters)`), so a runtime declaring only `"slack"`
is never handed the same bot's Teams deliveries.
But the managed runtime is **provider-agnostic**: it emits abstract
render frames and Intelligence renders each reply per the delivery's own
reply target. There is no reason for the runtime to constrain claims by
provider — one `intelligenceAdapter()` should serve every channel its
bot has attached.
## Fix
Drop the `adapters` field from the claim body. `adapters` is already
optional on the app-api side (absent → `NULL` → no provider filter → all
providers), so this needs no coordinated backend change.
`this.cfg.adapter` is still used for the heartbeat's declared bots and
for egress, both unaffected.
## Testing
Verified end-to-end locally against a managed Teams bot: inbound Bot
Framework JWT → claim → agent run → render → Bot Connector egress all
`succeed` with this change. Slack continues to work unchanged.
Follow-up to the provider-agnostic claim change on this branch. Now that the
runtime claims deliveries for every provider its bot has attached, Teams
deliveries flow through the same bridge — and their reply target is a distinct
shape (serviceUrl/conversationId/tenantId, no teamId/channel/threadTs). Deriving
conversationKey from Slack-only fields collapsed every Teams conversation onto
one degenerate key, and conversationKey keys the agent/session
(getOrCreate -> makeAgent), so distinct Teams conversations would share
state/memory.
Make replyTarget a discriminated union (slack|teams) and derive conversationKey
per provider: teams:{tenantId}:{conversationId}, matching Intelligence app-api's
thread_key (OSS-441 slice 2, Intelligence #511) so client and server agree on
conversation identity. Unknown adapters fail loud (the claim loop's existing
catch nacks, not wedges).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The managed runtime's claimOnce() declared `adapters: [this.cfg.adapter]`
(defaulting to "slack"), which Intelligence used to filter claimable
deliveries by provider. A runtime serving a bot with both Slack and Teams
adapters would therefore never receive the bot's Teams deliveries — they
stayed queued forever while Slack worked.
The managed runtime is provider-agnostic: it emits abstract render frames
and Intelligence renders per the delivery's own reply target. So the claim
must not filter by provider. Drop the adapter filter from the claim body;
one config-free `intelligenceAdapter()` now serves every channel its bot
has attached.
Verified end-to-end locally against managed Teams: inbound JWT -> claim ->
agent -> render -> Bot Connector egress all succeed with this change.
The realtime primitives (startManagedBots, connectPhoenixHostedBotChannel,
PhoenixRealtimeTransport) existed but nothing composed them into a launcher, so
the managed path defaulted to HTTP and Phoenix was never actually used.
- startManagedBotsOnChannel(bots, { channel, scope, runtimeInstanceId }) — wraps
an already-connected channel in a PhoenixRealtimeTransport (delivery source +
render sink) and starts the bots via startManagedBots. Split out so the
behavior is unit-testable against a fake channel.
- startManagedBotsOverPhoenix(bots, config) — thin glue: connect the gateway
bot-IO channel, delegate, disconnect on stop().
- phoenixEgress: fail-loud EgressSink (Phoenix routes all egress through the
render sink).
- examples/slack/app/managed.ts — a REAL consumer of the launcher: the same
Slack bot as index.ts (agent/tools/context/commands/handlers identical) run in
managed mode over Phoenix instead of the native slack() adapter. No native
index.ts changes.
Tests drive a real createBot through the full managed path over a fake channel:
delivered turn → render frame → completion INTENT (never self-ack); throwing
handler → fail intent. Live-stack E2E + manual validation are the OSS-406 proof;
scale-out (Teams, etc.) is OSS-459.
Bumps react-syntax-highlighter from ^15.6.1 to ^16.1.1. The v16 line
pulls refractor 5 and prismjs ^1.30.0, keeping react-ui's syntax
highlighting dependency chain current for downstream consumers.
The public API used by CodeBlock (the Prism/Light exports) is unchanged,
and highlighting renders the same across common languages.
Closes#2823.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
SDK-emit half of OSS-446 (lease-token fencing for hosted-bot render/complete).
The fail path already sends the lease token; render-accept and the completion
intent did not, so app-api fell back to instance-id + expiry there.
- HTTP: HttpRenderEventSink.push now includes leaseToken (new leaseTokenFor()
bridge on HttpDeliverySource, mirroring scopeFor). (ack already sent it.)
- Phoenix: push (render-accept) and complete_requested now carry leaseToken
from DeliveryState (fail already did).
Optional/forward-compatible: app-api + gateway already accept and fence on the
token when present (verified render/complete validators + fencing SQL), falling
back to the old check when absent — so this deploys safely ahead of the app-api
flip-to-required (OSS-446 half B), which waits on #511 settling managed-bots
service.ts.
github-actions[bot]