## What
Adds **`@copilotkit/bot-whatsapp`** — a WhatsApp Business **Cloud API**
`PlatformAdapter` for the platform-agnostic `@copilotkit/bot` engine —
plus a runnable **`examples/whatsapp`** app and docs. This brings
WhatsApp to the bots ecosystem alongside the existing Slack support,
reusing the engine, the `@copilotkit/bot-ui` IR, and the pluggable
`ActionStore` untouched.
## How it works
- **Ingress:** the adapter owns its own HTTP server — GET verification
handshake (`hub.challenge`) + POST intake validated by
`X-Hub-Signature-256` HMAC (timing-safe), acked `200` immediately then
processed async.
- **No streaming:** WhatsApp messages are immutable, so the run renderer
**buffers** text and sends once on `TEXT_MESSAGE_END`
(`supportsStreaming: false`; `update()` posts fresh, `delete()` no-ops).
- **Interactive mapping:** text/section → text; ≤3 buttons →
reply-button message; `Select` or 4–10 actions → list message; >10 →
numbered-text fallback. A control's `value` round-trips by encoding it
into the reply id (`ck:…::<json>`), since WhatsApp replies carry no
value field; oversized encodings fail loud rather than corrupt silently.
- **Memory:** WhatsApp exposes no readable history, so a pluggable
**`HistoryStore`** (default `InMemoryHistoryStore`) holds it and replays
it into `agent.messages` each turn (fresh threadId per turn, mirroring
`bot-slack`). Swap in a durable backend to persist across restarts.
- **Commands:** leading-keyword matching (`commandPrefix`, default `/`);
the command text is injected via the engine's `runAgent({ prompt })`
path (not persisted at ingress).
- **Inbound media** → AG-UI multimodal content parts; **HITL** via
interactive replies.
## Example
`examples/whatsapp` mirrors `examples/slack`: a CopilotKit
`BuiltInAgent` over MCP (Linear + Notion), with `issue_list`, an
interactive `show_incident`, and a `confirm_write` HITL gate.
## Tests & verification
- 62 unit tests across the package (render mapping, markdown→WhatsApp,
signature verification incl. wrong-but-equal-length, interaction
decode/round-trip, buffered renderer, webhook listener/server, stores,
media, adapter).
- `build` ✅, package `check-types` ✅, `publint`/`attw` (ESM-only) ✅,
example `check-types` ✅. Full `nx run-many -t test
--projects=packages/**` passes.
- Two rounds of code review (APPROVE) — fixed slash-command history
double-append and silent value-truncation; minors (HMAC over raw bytes,
conversationKey invariant, offset-correct Blob, unused-dep pruning,
added tests).
## Docs
Package `README.md` + `ARCHITECTURE.md`, example setup guide (Meta app +
webhook + tunnel), and a `shell-docs` WhatsApp guide page (registered in
`meta.json` + early-access gate).
## Notes / out of scope (v1)
- No template-send path for messaging outside WhatsApp's 24-hour
customer-service window (documented limitation).
- Pre-existing, unrelated `@copilotkit/core` `phoenix-observable.ts`
typecheck error exists on the branch base (missing `@types/phoenix`) —
not introduced here.
## What
Completes the cvdiag flap-observability instrument so **d5/d6/e2e probe
runs are readable from `cvdiag_events`** — previously only the d4 driver
emitted probe-layer rows, leaving the d5/d6 path (where the dashboard
flaps live) a blind spot.
- Extract `CvdiagProbeSession` (+ event shapes, constants,
`turnCompleteReason`) from `d4-chat-roundtrip.ts` into shared
`cvdiag/probe-session.ts`; d4 re-imports (behavior-preserving).
- Wire `CvdiagProbeSession` into `d6-all-pills.ts::runFeature`: emit
`probe.start/navigate.complete/message.send/firstToken` + an
exactly-once guarded `probe.exit` carrying `terminal_outcome` +
`failure_classifier`, and close the probe↔backend `test_id` join
(X-Test-Id already injected).
- Thread `cvdiagPbWriter` through `orchestrator.ts` (fleet worker) +
`cli/runner.ts` (`--live`) so probe events persist to `cvdiag_events`.
## Why
The d5/d6 probe path emitted **zero `probe.exit` rows** (verified: 2
days of cvdiag retention = 100% `d4-`, zero d5), so a flapping d5 cell
(e.g. `dom-missing` reds) could not be diagnosed from staging data. This
closes that gap.
## Verification
- Local red-green on the real surface (`langgraph-typescript --d5`):
`probe.exit` rows **0 → 38** (terminal_outcome + failure_classifier
populated).
- Full harness suite: **3167/3167 passing**; tsc/oxlint/oxfmt/build
clean.
## Code review (2-round cr-loop, 7 agents/round, converged + Procedure 3
clean)
- **A1** — `messageSend` char-count ran unguarded in the probe path; a
non-string input could throw and red a green probe. Fixed: computation
moved inside the `if (cvdiag)` guard + non-string coerced. (red-green)
- **A2** — `parseFailureClassifier` used a stale hardcoded 4-member
allow-list omitting `selector-mismatch`; reconciled both membership
checks to the canonical `FAILURE_CLASSIFIER_SET` (derived from
`CVDIAG_FAILURE_CLASSIFIERS`). (red-green)
## Follow-ups (not in this PR)
- `--headed` CLI launcher lacks the `goto`-wrap that installs the SSE
interceptor, so cvdiag (newly wired into `--headed`) mislabels
`failure_classifier` there; the supported fleet/`--direct` path is
correct. (dev-path quality)
- d6 feature-concurrency: 4 concurrent features share `test_id`
`d6-<slug>-<runId>`; per-feature reads work via `demo=featureType`, but
the §5 sequence_num join + replay buffer would benefit from per-feature
keying.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Problem
A `shell-docs` promote (live run
[27990607860](https://github.com/CopilotKit/CopilotKit/actions/runs/27990607860))
failed even though docs itself was healthy. Requesting `docs` expands
the promote **dependency closure** to include the always-on Tier-1
verification set:
```
CLOSURE_PLAN: 0:pocketbase,1:dashboard,1:harness,2:docs
```
`harness` then tripped a **P6 env-divergence WARN-refusal**
(`only-in-staging BROWSER_POOL_*`, `only-in-prod NODE_ENV`) and the tier
barrier gated `docs` as **NOT-ATTEMPTED**. docs has no runtime
dependency on the control plane, so it should never have been coupled to
harness.
## Fix
Introduce a declarative **`standalone`** service class — a leaf that
**neither depends on anything nor gates on anything** — and flag `docs`:
- **`computePromoteClosure` (railway-envs.ts)** and the
**resolve-promote-targets jq mirror** skip the Tier-1 union when the
requested set is *entirely* standalone, so a standalone request promotes
**only itself** (a mixed / `all` request still forces Tier-1 for the
rest).
- Standalone closure members are emitted with an **`s:` plan marker**;
**promote-fleet.sh** promotes `s:` services **ungated** — always
attempted (never NOT-ATTEMPTED on an unrelated failure), and their own
failure fails the run **without** gating the tiers.
- The tier-gating model is unchanged for every non-standalone service.
Net effect: `service=shell-docs` now resolves to a closure of just
`docs` (no harness), and docs is never gated in an `all` run.
## Red → Green (real surfaces)
Against `origin/main` (pre-fix) the new tests fail with the exact bug;
after the fix they pass:
| suite | RED (origin/main) | GREEN (this PR) |
|---|---|---|
| `railway-envs.test.ts` (computePromoteClosure) | 4 fail — `docs`
closure pulls in `harness`/`dashboard`; `.standalone` undefined | 103
pass |
| `resolve-promote-targets.bats` | 4 fail —
`closure_csv=harness,dashboard,docs`;
`closure_plan=1:harness,1:dashboard,2:docs` | 17 pass |
| `promote-fleet.bats` | 3 fail — `CLOSURE_PLAN token 's:svc-docs' has
an unknown tier 's'` | 30 pass |
Other gates: `shellcheck --severity=warning` clean (both scripts);
`emit-railway-envs-json.ts --check` → up to date; `tsc -p
scripts/tsconfig.json` clean for the changed files.
## Note
Prod `docs` was unblocked out-of-band via a direct `bin/railway promote
docs` (single-service, no closure) while this lands; the #team-showcase
success notification was posted manually. This PR fixes the *workflow*
path so the manual route is no longer needed.
A `shell-docs` promote expanded its dependency closure to include the
always-on Tier-1 verification set (harness, dashboard, …); harness then
tripped a P6 env-divergence WARN-refusal and the tier barrier gated docs
as NOT-ATTEMPTED. docs has no runtime dependency on the control plane.
Introduce a declarative `standalone` service class: a leaf that neither
depends on anything nor gates on anything. computePromoteClosure (TS) and
the resolve-promote-targets jq both skip the Tier-1 union when the request
is entirely standalone, so a standalone request promotes ONLY itself; the
fleet runner promotes `s:`-marked services ungated (never NOT-ATTEMPTED on
an unrelated failure, never gating a tier). Flag `docs` standalone.
Red-green: railway-envs.test.ts (4), resolve-promote-targets.bats (5),
promote-fleet.bats (3) fail on origin/main (docs closure pulls harness;
`s:` is an unknown tier) and pass after the fix.
- open a per-feature CvdiagProbeSession for each d5/d6 pill probe
- emit exactly-once probe.exit and failure_classifier per session
- join probe-session output to its run via the X-Test-Id header
- thread cvdiagPbWriter through the orchestrator and CLI runner
Call-Site Enumeration: FAILURE_CLASSIFIER_SET is exported from
cvdiag/probe-session and consumed by d6-all-pills (classifier validation
against the canonical set). The export has no other call sites; any future
classifier addition must update the canonical set in probe-session and the
validation in d6-all-pills together.
Behavior-preserving extraction of the CvdiagProbeSession lifecycle from the
d4 chat-roundtrip driver into a shared cvdiag/probe-session module, so the
d5/d6 probe path can reuse the same session boundaries. d4-chat-roundtrip
now imports the extracted session instead of defining it inline.
## Summary
- Backports the generated/root Threads guide content into the shared
authored Threads snippet.
- Adds the CLI “Choose your starting point” path, manual path, thread
lock options, Enterprise Intelligence CTA, and corrected next-step links
to authored Threads docs.
- Standardizes authored integration Threads pages to explicitly import
the shared snippet with `components={props.components}` so authored
routes stay aligned.
## Authored routes covered
- AG2
- Agno
- AWS Strands
- Built-in Agent
- CrewAI Flows
- LangGraph
- LlamaIndex
- Mastra
- Microsoft Agent Framework
- PydanticAI
## Validation
- `npm run pretypecheck` in `showcase/shell-docs`
- `npm run lint` in `showcase/shell-docs` (passes with existing
warnings)
- `npm run test` in `showcase/shell-docs`
- `npm run typecheck` in `showcase/shell-docs`
- `npm run build` in `showcase/shell-docs` (passes with existing
Next/Turbopack warnings)
- `git diff --check`
- Manual MDX link sweep for changed docs links (`/premium/self-hosting`,
`/premium/threads-explained`, `/reference/hooks/useThreads`, and
`http://localhost:3000`)
## Formatter note
- `pnpm run check-format` currently fails on unrelated existing files
under `examples/showcases/arcade-tools/*`,
`examples/v2/react/demo/tsconfig.json`, `migrations.json`, and
`nx.json`.
- Scoped `oxfmt --check` does not treat the changed MDX files as target
files, so there is no formatter-owned MDX change to apply here.
## Summary
A full `service=all` promote ran **fully serially** and exceeded the
promote job's 20-minute `timeout-minutes`, getting cancelled mid-fleet
(silent partial promotion). This adds **within-tier parallel fan-out**
so `all` completes in budget.
## Changes
- **`promote-fleet.sh`** — within a tier, `promote_one` is backgrounded
up to `PROMOTE_FANOUT` (default 5) via a **bash-3.2-safe** PID-array
bounded launcher (plain `wait <pid>`, no `wait -n`/`declare -n`).
Per-service results go to temp files (`$WORK/<svc>.rc/.drift/.log`) and
`reap_tier` repatriates them into `succeeded[]`/`failed[]`/`drift[]`
(subshell-safe — backgrounded children can't mutate parent arrays).
**Tier boundaries are hard barriers** (all PIDs drained before the next
tier); cross-tier stays serial. A present-but-empty/non-numeric `.rc`
(crash/disk-full mid-write) is treated as a clean failure, not parsed as
garbage.
- **`showcase_promote.yml`** — wires `CLOSURE_PLAN` into the promote
step (was flat `SERVICES_CSV`) so the fan-out is tier-aware; bumps the
promote job `timeout-minutes` **20 → 35**.
- **`promote-fleet.bats`** — new fan-out tests with a **deterministic
rendezvous-barrier** concurrency proof (no wall-clock sleep race;
RED-on-serial preserved via timeout), tier-barrier boundary-inclusive
(`>=`), and the empty-`.rc`-as-failure case.
- `SC2317,SC2329` shellcheck disable for the trap-only `cleanup()`
(ubuntu-24.04 CI ships shellcheck 0.9.0).
## Test plan
- [x] bats **27/27** (file) / **108/108** (dir) green
- [x] shellcheck clean on local 0.11.0 **and** pinned CI 0.9.0
- [x] actionlint clean on the workflow
- [x] within-tier concurrency ≤ cap and reaches cap; tier barrier holds;
one failure doesn't abort its tier + run exits nonzero
Prod sitting behind staging is often intentional (changes are batched and
promoted deliberately), so a recurring drift alert is noise. Reshape the
reconcile workflow to manual-only:
- Remove the daily `schedule:` cron trigger — leave only `workflow_dispatch`.
- Remove the auto-Slack-on-stale step (and its SLACK_WEBHOOK env / stale_line
output derivation) — no unsolicited #oss-alerts post on mere staleness.
- A manual run surfaces the reconcile table to the GH step summary, keeps the
cheap `--json` capture as an uploaded artifact, and still exits nonzero on a
stale column so a manual run visibly flags drift.
- De-noise the gate script + bats comments that referenced the removed
scheduled/Slack behavior.
The on-demand CLI (`bin/railway reconcile-prod`), the gate wrapper, and the
Ruby + bats tests are unchanged.
Lever 1 of the promote-reliability hardening plan. The showcase deploy
model is staging=mutable :latest (continuously rebuilt), prod=immutable
@sha256: (advances only on explicit promote), so a prod column can
silently fall BEHIND a green staging — drift today is only noticed by
eyeballing a dead column. This adds proactive, automatic detection.
- bin/railway reconcile-prod: for every prod-eligible (probe.prod==true)
service, compares the prod SERVING digest (LintProd snapshot path) vs
the staging RUNNING digest (reuses PromoteCommand#staging_running_digest).
Classifies green/stale/gray, prints a table + summary, exits 1 iff any
stale. --json for machine output. Read-only: no promotes/mutations.
- scripts/reconcile-prod-gate.sh: wrapper mirroring lint-prod-gate.sh —
surfaces the table to the GH step summary, captures JSON for the Slack
builder, propagates the exit-code verdict.
- .github/workflows/showcase_reconcile.yml: daily cron + workflow_dispatch;
runs the gate; on stale services posts the stale-column list to
#oss-alerts (SLACK_WEBHOOK_OSS_ALERTS) via the fromJSON('"\n"') idiom.
- Tests: Ruby minitest (classification + exit-code, RED-anchored on a
drift-blind classifier) and a bats gate test. Wired the gate script
into the showcase_validate.yml shellcheck list.
Post-promote convergence verification is deferred to a fast-follow.
## Summary
- Rename the overview capability from "Cloud-hosted web app" to
"Cloud-hosted Intelligence features".
- Remove the redirecting multi-conversation tutorial link from thread
docs, shared thread snippets, and useThreads references.
## Validation
- npm run test (showcase/shell-docs)
- npm run lint (showcase/shell-docs; exits 0 with pre-existing warnings)
- npm run typecheck (showcase/shell-docs)
- npm run build (showcase/shell-docs)
- Manual link sweep for edited MDX confirmed no remaining
/tutorials/multi-conversation-chat links
The previous guide documented an older API (createTeamsAgentBot, a local "Teams
DevTools" bridge) that shipped through copilotkitnext. Rewrite it for the new
createBot + teams() PlatformAdapter, mirroring the Slack guide: M365 Agents
Playground quickstart, interactive Adaptive Cards, a human-approval gate,
splitting the bot from its agent over AG-UI, and Azure sideloading into real
Teams. Also refresh the frontend picker summary (Playground, not DevTools).
## What does this PR do?
Adds stable test IDs to the CopilotChat input area so automated tests
can reliably target the default chat UI.
Changes included:
- Adds `data-testid="copilot-chat-input"` to the chat textarea.
- Adds standard `data-testid` values to the send and stop button.
- Keeps the existing `data-test-id` values for backwards compatibility.
This is a small non-breaking testability improvement for the React UI
package.
## Related PRs and Issues
Related to #4215
## Checklist
- [x] I have read the Contribution Guide
- [x] If the PR changes or adds functionality, I have updated the
relevant documentation
- [x] Allow edits by maintainers is checked
## Hotfix — staging harness was crash-looping
PR #5616's on-demand-trigger code (`http/fleet-runs.ts`) imports
`control-plane.js` first, whose transitive load (`control-plane →
job-producer → run-view → control-plane`) evaluated `run-view.ts`'s
top-level `FLEET_FAMILIES` literal **before** `control-plane.ts`
finished assigning `FLEET_PRODUCER_SCHEDULE_ID` (+3 sibling schedule-id
constants) → `ReferenceError: Cannot access 'FLEET_PRODUCER_SCHEDULE_ID'
before initialization` → the harness never bound its port (staging
harness down; workers stuck on the stale digest).
The cycle was latent (prior load order happened to init the constants
first); the trigger change shifted load order and exposed it.
## Fix
New leaf module `fleet/control-plane/schedule-ids.ts` (zero imports)
holds the four `SCHEDULE_ID` constants. `control-plane.ts` re-exports
them (public surface unchanged); `run-view.ts` imports them from the
leaf instead of from `control-plane.js`. No eval-time edge into the
cycle → no TDZ.
## Verification (real boot — not just tsc; tsc passed while it crashed
at runtime)
- **RED** on main: `import('./dist/http/fleet-runs.js')` and
`import('./dist/orchestrator.js')` both threw the exact ReferenceError.
- **GREEN**: all four load orders (fleet-runs, orchestrator entrypoint,
control-plane, run-view) import clean; `FLEET_FAMILIES` builds with 4
entries.
- New regression guard `import-cycle-tdz.test.ts` (3 tests) asserts the
module graph imports without throwing.
- Fleet control-plane suite 347/347; broader fleet + fleet-runs +
orchestrator 814/814; `tsc --noEmit` clean (one pre-existing unrelated
`glob` env error, untouched).
## Note
CI's build-check compiles the harness image but never boots the fleet
control-plane, so this slipped through green. The new import test is a
boot-time regression guard.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What
Completes the cvdiag observability subsystem so a single flapping
showcase run is **fully attributable end-to-end** — and makes every
probe reproducible on demand. Four fixes, all proven against the real
surface (live PocketBase writer-role, real `next` build, driver vitest):
1. **Cross-layer `test_id` join (the keystone).** Both sides were using
different ids: the backend minted its own UUIDv7, and the probe
re-minted a random UUIDv7 when its forwarded `X-Test-Id`
(`d6-<slug>-<runId>`) wasn't a UUIDv7. Now both run the same
`sanitizeJoinTestId` over the forwarded id → probe.* and backend.* rows
for one run **share `test_id`** (the join key per `schema.ts`); each
side keeps its own `trace_id`/`span`.
2. **Probe failure classifier.** `probe.exit` now stamps `outcome=err` +
`failure_classifier` (`sse-missing`/`dom-missing`/`text-unstable`) from
`waitForTurnComplete`'s reason, instead of `outcome=ok` on every run —
so reds are labeled, not inferred.
3. **Backend boundaries.** (Confirmed already on main — full 11-boundary
set incl `request.ingress`/`sse.first_byte`/`llm.call.*`.)
4. **On-demand trigger for EVERY probe.** New `POST
/api/runs/:family/trigger` (OPS-token-gated, rate-limited) fires any
fleet/D6 probe via the existing job-producer enqueue; in-process probes
keep their route. No more waiting on the hourly cron to reproduce a
flap.
## Why
cvdiag was live and persisting, but couldn't yet say "backend stall vs
frontend race" for a single red because probe and backend rows couldn't
be joined, reds weren't labeled, and D6 wasn't on-demand reproducible.
These close those gaps.
## Verification
- harness `tsc --noEmit` clean · cvdiag + drivers vitest **665 passed /
31 files** (join + classifier + boundary + trigger together) · 4
fix-test files 151 passed
- codegen `--check` + `cvdiag-stage-ts --check` in-sync (schema.json + 4
staged copies regenerated, not hand-merged)
- real Docker `next build` of built-in-agent succeeded (backend boundary
+ writer code bundles)
- live-PB writer-role RED→GREEN for the join; driver RED→GREEN for the
classifier; enqueue-assertion RED→GREEN for the trigger
## Follow-ups (not in this PR)
- Python dual-process (:8123) backend→PB shipping gap (python
integrations emit zero backend rows despite the auth fix)
- liveness-probe 400 noise → `outcome=info` + plumb real `model_id`
- Java/.NET backend writer-role auth
- break the run-view⇄control-plane import cycle the trigger routes
around
🤖 Generated with [Claude Code](https://claude.com/claude-code)
schema.json regenerated from the merged canonical schema.ts (failure_classifier
probe.exit additions UNION backend request.ingress/sse.first_byte/llm.call.*
boundaries + test_id adoption). Per-integration staged schema.ts copies
re-derived via 'showcase cvdiag-stage-ts' so codegen --check and stage --check
are both in sync. No hand-merge of generated artifacts.
## Summary
- `upload-artifact`'s `!**/node_modules/**` filters are post-walk: the
action still descends into every `node_modules` and stats every file
(~6M with pnpm's `.pnpm/` symlink farm) before applying negations. That
enumeration is the actual bottleneck — `Upload workspace` runs 10+
minutes even with the filters added in #5044.
- Replace the filtered upload with: `rm -rf` the heavy dirs
(`node_modules`, `.nx`, `.turbo`, `.next`), `tar -czf /tmp/workspace.tgz
.`, upload that single file. Publish job `tar -xzf`'s it after download
and continues unchanged.
- Applied symmetrically to `prerelease.yml` and `publish-release.yml`.
## Measured impact
Verified on a dry-run dispatch of `release / pre` against this branch
([run
26531785850](https://github.com/CopilotKit/CopilotKit/actions/runs/26531785850)):
| Step | Before (run 26529550757) | After (this PR) |
| ------------------------------- | ------------------------ |
--------------- |
| Upload workspace | ~800s (cancelled) | **3s** |
| Pack workspace | — | 9s |
| Download workspace | — | 1s |
| Unpack workspace | — | 1s |
| **Total artifact round-trip** | **~800s** | **14s** |
- `Upload workspace` step alone: **~99.6% reduction (~267× faster)**.
- Full pack/upload/download/unpack pipeline vs the prior single upload:
**~98% reduction (~57× faster)**.
The 800s baseline is from a cancelled run, so both numbers are
conservative.
## Test plan
- [x] Dispatch `release / pre` against this branch with `dry_run=true`
- [x] Confirm `Upload workspace` completes in seconds instead of 10+ min
- [x] Confirm publish job `Unpack workspace` restores the tree and `pnpm
install` succeeds
- [x] Confirm dry-run publish step exits clean (no missing files from
the tarball round-trip)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## What
A new Cookbook recipe — **Build an agentic app on Angular + Google ADK**
— covering the non-obvious production gotchas when you wire an Angular
frontend to a Google ADK agent over AG-UI, with optional CopilotKit
Intelligence threads and memory. Written in the existing cookbook house
style (symptom → cause → fix callouts), and it links out to the Angular
and ADK quickstarts rather than re-teaching setup.
## Why
The Angular + ADK combination has a handful of correctness issues that
only surface in a real, multi-user, governed app, and they aren't
covered by the per-piece quickstarts:
- One agent, one store (a second composer must not create its own store)
- Scope the user via the **run body**, not an HTTP header (a header lags
by one in-session switch)
- Never reconfigure the runtime mid-submit (it recreates the agent store
and drops the message)
- Governance is server-side; the per-request allow-list rides the run
body
- Choose a capable model, and degrade gracefully when the Intelligence
platform is absent
The recipe is **model-flexible**: it frames ADK as running Gemini by
default but supporting any model ADK supports, consistent with the ADK
quickstart.
## Changes
- **New** `cookbook/angular-adk-agentic-app.mdx` — the recipe
- `cookbook/meta.json` — register in nav
- `cookbook/index.mdx` — add the index card (uses
`/logos/google-adk.svg`)
- `src/lib/sidebar-icon.tsx` — add `custom/google-adk` sidebar icon
entry
- `frontends/angular.mdx` — bidirectional cross-link into the recipe
- `src/lib/__tests__/docs-render.test.ts` — update the cookbook nav test
for the new page
## Test plan
Run from `showcase/shell-docs`:
- `npm run typecheck` — passes
- `npm run lint` — passes (only pre-existing warnings; none in changed
files)
- `npm run test` — the cookbook-nav test passes. Two
`public-assets.test.ts` cases fail **only locally** because git-LFS PNGs
are unmaterialized in a fresh worktree (the tests assert assets are not
LFS pointer stubs); they are unrelated to this change and pass in CI.
- `npm run build` — passes; all 211 static pages generate, including
`/cookbook` and `/cookbook/[...slug]`.
Verified in the browser at `localhost:3003`: recipe renders with correct
callout styling, code highlighting, populated TOC, sidebar entry, and
index card.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<img width="1026" height="586" alt="image"
src="https://github.com/user-attachments/assets/4c8d61ef-d74b-40fa-9e54-807750daed24"
/>
Two PR checks were red on the new integration:
- check-config-files: add strands-typescript/next.config.ts to the build-
config allowlist.
- Validate Showcase: update the new-integration guard pins that intentionally
trip when an integration is added — BORN_IN_SHOWCASE 6→7, calculator
_from-feature-parity count 18→19, catalog cross-join 874→920 / total_cells
855→900 / docs_only 19→20 (46 features × 20 integrations), and the aimock
substring-shadow ceiling 132→133 (+1 from the strands-typescript calculator
fixture).
Also drop the premature deploy wiring: strands-typescript is removed from
showcase_build.yml (matrix + path filter + ALL_SERVICES) because it has no
Railway service yet (deployed: false) and the railway-envs SSOT test requires
a real service entry. It re-enters the deploy pipeline when the Railway
service is provisioned (external setup per INTEGRATION-CHECKLIST).
Bring the TypeScript AWS Strands integration to parity with the Python
strands sibling now that the @ag-ui/aws-strands TS adapter is confirmed to
support the same feature surface (per its examples/server):
- Restore A2UI: the declarative-gen-ui + a2ui-fixed-schema demos, their
routes, qa, specs, the @copilotkit/a2ui-renderer dep, beautiful-chat's
A2UI catalog, and the manifest entries (generative_ui / features / demos /
a2ui_pattern). manifest now matches strands-python feature-for-feature.
- Header forwarding: attach `x-aimock-context: strands-typescript` as a
static defaultHeader on the OpenAI client (model-factory + sub-agent
client) — the TS analog of the Python integration's _header_forwarding
shim — so aimock matches this integration's fixtures.
- aimock fixtures: add d6/strands-typescript + d4/strands-typescript
(ported from the Python sibling, context retargeted).
- playwright.config: X-AIMock-Context → strands-typescript.
Note: the raw tests/e2e Playwright suite is flaky and not a CI merge gate
(demo e2e / `/eval` D5 are comment-triggered, not required) — it fails the
same specs for strands-python too. The auto-gates (build, validate-
constraints, oxlint/oxfmt, unit) are green.
A catalog on <CopilotKit a2ui={{ catalog }}> is now enough to use A2UI
end to end. Previously developers also had to set a2ui.injectA2UITool: true
on the runtime.
The provider forwards an a2uiCatalogAvailable signal per run whenever it has
a catalog (and renders surfaces locally). handle-run reads that signal and
hands it to configureAgentForRequest, which enables A2UIMiddleware and defaults
injectA2UITool to true. An explicit injectA2UITool value (including false) and
an explicit a2ui.enabled: false are always respected via ?? / short-circuit, so
this only fills the default and never overrides a deeper opt-out.
## What
Fixes a production defect in the cvdiag observability subsystem (#5591):
**backend emitters never persisted to PocketBase.** The `cvdiag_events`
createRule requires an authenticated `cvdiag_api_keys` record with
`role="writer"`, but:
- The **Python** writer sent a custom `X-Cvdiag-Writer-Key` header and
never authenticated → every CREATE 403'd and was silently dropped by the
never-throw daemon.
- The **TS** backends had a *type-only* PB-writer seam — the concrete
writer lived in `harness/` and was never bundled into the deployed
Next.js runtime → `pbWriter` undefined → flush was a no-op.
So backend boundaries (`request.ingress`, `llm.call.*`, `sse.*`,
`error.caught`) emitted to stdout but never reached the DB. (The
probe/harness side already persists — it auths as superuser.)
**Why #5591's CR didn't catch it:** the M2 persistence tests
authenticated as **superuser**, which the migration itself notes
bypasses *all* collection rules — so the real writer-role auth path was
never exercised.
## Fix
- **Python** (`cvdiag_pb_writer.py`): `auth-with-password` against
`cvdiag_api_keys` (identity `cvdiag-writer@keys.local`, password =
`CVDIAG_WRITER_KEY`) → cache Bearer token → `Authorization: Bearer` on
CREATE; re-auth on token expiry; auth failure degrades to no-op
(never-throw). Identity overridable via `CVDIAG_WRITER_IDENTITY`.
- **TS** (`harness/src/cvdiag/pb-writer-fetch.ts`, staged into the 4
integrations): a plain-`fetch` writer-role writer (no SDK, bundles
cleanly in Next), injected by `withCvdiagBackend` only when
`CVDIAG_PB_URL` is set.
The writer credential already exists — the migration seeds the `writer`
record — so no provisioning needed.
## Verification (against a LIVE PocketBase, authenticating as the writer
role — not superuser)
- Python: live-PB writer-role test — header-only → **0 rows**; after fix
→ **row persists**; wrong password → **0 rows, daemon alive**. `_shared`
pytest 16/16.
- TS: live-PB writer-role tests — 0 rows → rows persist; stale-token
re-auth lands; wrong-key/no-url no-op. harness cvdiag vitest 255/255.
Real Docker `next build` of built-in-agent succeeds (writer bundles).
- `cvdiag-stage-ts --check` in-sync.
## Follow-up (not in this PR)
Java/.NET backends have the same auth gap; they're not the flap-heavy
integrations and will be fixed before enabling their columns.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Replace the placeholder logo with the official Agent Development Kit mark
from google/adk-python (assets/agent-development-kit.png), committed as an
LFS PNG like the other recipe logos (Daytona, Arcade). Point the card and
sidebar at /logos/google-adk.png and revert the unused google-adk.svg back
to its original state.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
public/logos/google-adk.svg was a placeholder (a grey tile with the text
"Go"), like the other letter-stub SVGs in that directory. Replace it with
the real ADK glyph, reusing the vector paths from the `AdkIcon` component
(src/components/icons/framework-icons.tsx) on a light tile so it renders
on both light and dark surfaces. Only the new cookbook recipe references
this file, so no other page is affected. Monochrome for now; design can
recolor to official ADK colors at approval.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The ADK adapter (ag_ui_adk) builds session state from `dict(input.state)`
plus `input.context` (under `_ag_ui_context`); it does not mirror
`forwarded_props` into session state (it only reads it for the
`injectA2UITool` flag). So a user id sent via CopilotKit `properties`
(-> forwardedProps) never reaches `tool_context.state`, and the documented
scoping silently failed — the exact bug class the section warns about.
Carry the user id as agent context via `connectAgentContext` (or shared
agent state) instead, and read it from `tool_context.state["_ag_ui_context"]`
(or directly from state). Reconcile the contradictory forwardedProps/state
lines and fix the coding-agent prompt to match.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Tyler Slaton