Under the pinned-prod contract, prod is intentionally digest-pinned behind
:latest. image-drift now renders such prod services green (pinnedExpected)
instead of red; a genuinely missing digest stays red. Staging unchanged.
Prod services are now born pinned to a resolved @sha256 digest (mirroring
the Ruby promote CLI's GHCR resolver) instead of the mutable :latest tag,
fail-loud on resolve failure, and goLive asserts the prod source.image is
digest-pinned. Adds DI-testable assertProdDigestPinned + coverage.
## Summary
Fix-forward for the RED `Showcase: Validate` on `main` introduced by
#5569 (MS Agent Harness (.NET) full column).
`showcase/scripts/__tests__/calculator-fixture-routing.test.ts`
hard-pins the count of discovered `_from-feature-parity.json`
integration fixtures. #5569 legitimately added the 19th integration
(`ms-agent-harness-dotnet`) and its calculator fixtures are already
mirrored in
`showcase/aimock/d6/ms-agent-harness-dotnet/_from-feature-parity.json`.
The test's own failure message prescribes the fix: bump the pin.
## Changes
- Bump the discovered-integration pin from 18 → 19 (test name +
`toHaveLength`).
- Update the explanatory comment counts (16/18 → 17/19) to match the new
integration set. The two pill-less integrations (built-in-agent,
claude-sdk-python) are unchanged; `ms-agent-harness-dotnet` carries the
full calculator pill, so it joins the 17 with a real pill.
No source/behavior change — pin reflects reality (the harness fixture
file exists and passes all per-integration routing/ordering assertions).
## Red → Green proof
RED (original pin=18, glob discovers 19):
```
FAIL __tests__/calculator-fixture-routing.test.ts > beautiful-chat calculator fixture routing > discovers all 18 integration _from-feature-parity.json files
AssertionError: integration count changed — new integration added? mirror its calculator fixtures from langgraph-python and update this pin: expected [ 'ag2', 'agno', …(17) ] to have a length of 18 but got 19
- 18
+ 19
Test Files 1 failed (1)
Tests 1 failed | 57 skipped (58)
```
GREEN (after pin=19, full file):
```
Test Files 1 passed (1)
Tests 58 passed (58)
```
(58 = 19 integrations × 3 per-integration tests + the discovery/pin
test.)
## Summary
Adds the full **MS Agent Harness (.NET)** showcase column
(`ms-agent-harness-dotnet`) — a 1:1 port of the green framework sibling
`ms-agent-dotnet`, rebuilt on the `AsHarnessAgent` construction surface
(Microsoft.Agents.AI 1.6.1).
- **326 files** (+30k): 243 frontend demo files + shared components/API
routes, 24 backend agent `.cs` on the `AsHarnessAgent` pattern, 38 D6 +
1 D4 aimock fixtures (cribbed from the framework, `match.context`
re-keyed), manifest/csproj registration.
- The column was already registered (slug-map, compose, dashboard,
smoke) on main; this lands the implementation.
## .NET adaptations (the novel surface)
- **Microsoft.Agents.AI 1.6.1 API migration** —
`AgentThread`→`AgentSession`,
`AgentRunResponse(Update)`→`AgentResponse(Update)`,
`RunAsync`→`RunCoreAsync` across the ported agents.
- **aimock-header** aligned to the `IHttpContextAccessor` design so
`x-aimock-context` propagates across the AG-UI SSE-pump boundary
(matches the framework).
- **JsonElement-capable `TypeInfoResolver`** threaded to the
shared-state agents (fixes a startup crash).
- **`crypto.randomUUID` secure-context fallback** in the headless demos
(the container serves over plain HTTP at a non-localhost host; symmetric
with the existing `multimodal` helper).
## LOCAL==STAGING parity fix
- `control-plane-run.ts` now threads each scope's
`not_supported_features` into the synthesized local roster, so the D6
driver reclassifies architecturally/upstream-blocked features as
`skipped-incapable` locally exactly as staging does. **Benefits every
column** (the local control-plane previously dropped NSF). +3 unit tests
(RED→GREEN).
## LGP / framework parity
- Frontend demos, fixtures (`response.content` untouched — only
`match.context` re-keyed), and backend behavior are 1:1 with the
framework sibling. The `hitl` demo was reverted to byte-identical
framework parity.
## D6 status
- Per-demo D6 GREEN verified locally (control-plane): `headless-simple`,
`headless-complete`, `gen-ui-agent`, `shared-state-read`, `multimodal`.
- 3 features inherited as `not_supported`/skipped-incapable
(architecturally/upstream-blocked, same as the framework):
`shared-state-streaming`, `gen-ui-interrupt`, `interrupt-headless`.
- `declarative-gen-ui` verified structurally parity-clean
(byte-identical to the green framework). **CI runs the authoritative
full-column D6.**
## Review
- 7-agent cr-loop converged (0 mandatory findings; Procedure 3 promotion
audit 0-promote). All review findings were either framework-inherited
(fixing breaks 1:1 parity) or pre-existing `control-plane-run.ts`
poll-hardening (tracked as a follow-up — not introduced here).
## Test plan
- [ ] CI: Showcase: Validate green
- [ ] CI: full-column D6 (`ms-agent-harness-dotnet`) green
(authoritative)
- [ ] CI: .NET image build green
Approach (A) reorder: decode -> html-strip -> headTailCap -> scrub(head)+scrub(tail).
The prior order scrubbed the FULL decoded body before the cap, so a body >32KB hit
scrubSecrets' bounded-prefix path: it truncated to a ...[unscanned:N] prefix BEFORE
headTailCap, which (1) lost the real tail, (2) never scanned the real tail for secrets,
and (3) zeroed elided_count. Reordering scrubs each retained <=16KB segment AFTER the
cap: input is bounded per-segment (linear regex x bounded length = ReDoS-impossible, no
scan-budget truncation), the captured head AND tail are the REAL ends of the body, and
elided_count comes from headTailCap on the FULL body. The unrelated 2KB metadata-hot-path
scan guard (SCRUB_MAX_SCAN_LEN) is untouched; the now-unneeded RAW_BYTE_SCAN_MAX export
is removed.
The emit-hardening redesign added a 2KB SCRUB_MAX_SCAN_LEN guard inside
scrubSecrets, correct for the DEFAULT-tier metadata hot path (legit values
<=512B). But raw-byte-capture.ts also calls scrubSecrets on the DECODED wire
body, which is legitimately large (<=16KB head + <=16KB tail = up to 32KB).
The 2KB guard truncated the body to ~2KB before headTailCap ran, so for an
>32KB body elided_count became 0 and the head+tail elision never triggered.
Approach: parameterize the scan cap (chosen over the reorder-and-scrub-segments
alternative because it is a minimal, local change that preserves the documented
decode->scrub->html-strip->headtail pipeline order and keeps the metadata
default behavior byte-identical for all existing callers).
- scrub.ts: scrubSecrets gains an optional maxScanLen param defaulting to the
exported SCRUB_MAX_SCAN_LEN (2KB). Metadata/validateMetadata callers are
unchanged; the ReDoS guard on the hot path is untouched.
- raw-byte-capture.ts: passes RAW_BYTE_SCAN_MAX (head+tail cap = 32KB) so the
full retained sample is scanned (no secret in the kept head/tail escapes) and
headTailCap sees the un-truncated body. The three scrub regexes are linear at
any bounded length, so the larger bound stays ReDoS-safe.
- scrub.test.ts: asserts the default param still applies the 2KB guard AND an
explicit larger cap does not truncate, proving both contexts.
The redesigned scrub regexes are linear, but the previous hard <50ms bound
flaked under JIT warm-up and shared-runner load (observed 77ms on a loaded
machine). Add a timeScrub helper that discards a warm-up call before timing
and assert against a 500ms ReDoS ceiling — wide enough to be jitter-immune,
still ~3x under the legacy ~1.4s catastrophic-backtracking blowup it guards
against.
## What
1. Add `suppressHydrationWarning` to `<body>` across **all 14
integration demo templates**
(`examples/integrations/*/src/app/layout.tsx`).
2. Fix a pre-existing **double-escaped Windows path** bug in the parity
manifest's `packageJsonOverrides`.
## Why (hydration)
**Mike Ryan hit a hydration error on first load of a fresh
`langgraph-python` init — caused by his Grammarly browser extension.**
Grammarly (and similar extensions) inject attributes onto `<body>`
*before* React hydrates:
```
data-new-gr-c-s-check-loaded="9.98.0"
data-gr-ext-installed=""
```
Those attributes are in the client DOM but absent from the server HTML,
so Next.js reports:
> A tree hydrated but some attributes of the server rendered HTML didn't
match the client properties.
It's a **false positive** — the app works, and end users (without dev
extensions) never see it — but it's a red console error on the first
load of our flagship eval/showcase templates, which is a poor first
impression.
## Fix (hydration)
`suppressHydrationWarning` on `<body>` is the React/Next.js-recommended
escape hatch for this. It is **scoped and one level deep**: it only
relaxes the check for `<body>`'s *own* attributes/text — **everything
rendered inside `<body>` (the whole app) is still fully
hydration-checked** — and `<body>`'s only attribute here is a static
`className`, so none of our own markup is masked. An inline comment
documents this so a future maintainer who adds dynamic `<body>`
attributes knows the check is relaxed.
`agent-spec` already had `suppressHydrationWarning` on `<html>`; the
Grammarly attributes land on `<body>`, so it needed the body-level
relaxation too (the `<html>` one is a level up and doesn't cover
`<body>`'s attributes).
## Commits
1. `b1fa482a7` — north-star (`langgraph-python`) + parity instances
(`langgraph-js`, `langgraph-fastapi`, `strands-python`) via `pnpm
parity:sync`.
2. `9f9c415d9` — the non-parity templates (not tracked by
`_parity/manifest.json`): `adk`, `agno`, `crewai-crews`, `crewai-flows`,
`llamaindex`, `mastra`, `ms-agent-framework-dotnet`,
`ms-agent-framework-python`, `pydantic-ai`, `agent-spec`. *(The repo's
`oxfmt` pre-commit hook also collapsed some multiline `<CopilotKit …>`
JSX in these files — standard auto-format on touched files; the only
semantic change is the suppression.)*
3. `7d60e49de` — parity manifest path-escaping fix (see below).
## The manifest bug (commit 3)
While syncing I found the `langgraph-js` and `strands-python`
`packageJsonOverrides` double-escaped the Windows `.bat` fallback,
producing `scripts\\run-agent.bat` (two backslashes) instead of
`scripts\run-agent.bat`:
- `langgraph-js/package.json` had already been synced with the broken
value.
- `strands-python/package.json` was still correct — and `parity:sync`
would have **corrupted** it on the next run (which is what surfaced
this).
Fixed the three overrides and re-ran `parity:sync`, which corrects
`langgraph-js/package.json` and leaves `strands-python`'s correct value
intact.
## Test plan
- [x] `pnpm parity:verify` → 0 errors
- [x] lefthook pre-commit green on all 3 commits (lint + `packages/**`
tests + commitlint)
- [x] All 14 templates confirmed to have body-level
`suppressHydrationWarning`
- [ ] Reviewer with Grammarly installed: run/`init` a template and
confirm no hydration error on first load
The langgraph-js and strands-python packageJsonOverrides in
_parity/manifest.json double-escaped the Windows .bat fallback, so the
synced value became `scripts\\run-agent.bat` (two backslashes) instead of
the intended `scripts\run-agent.bat`. langgraph-js's package.json had
already been synced with the broken value; strands-python's was still
correct (and parity:sync would have corrupted it on the next run).
Fix the three overrides and re-run parity:sync, which corrects
langgraph-js/package.json and leaves strands-python's correct value intact.
Extend the same `<body suppressHydrationWarning>` fix to the integration
templates that are not tracked by examples/integrations/_parity/manifest.json,
so they don't surface a Grammarly-style hydration mismatch on first load:
adk, agno, crewai-crews, crewai-flows, llamaindex, mastra,
ms-agent-framework-dotnet, ms-agent-framework-python, pydantic-ai, agent-spec.
agent-spec already had suppressHydrationWarning on <html>; the Grammarly
attributes land on <body>, so it needs the body-level relaxation too (the
<html> one is one level up and does not cover <body>'s attributes).
## Summary
Two focused, pre-existing fixes in the `generative-ui-playground`
example. These were surfaced as out-of-subject bucket-(d) findings
during the `@copilotkitnext` → `/v2` migration CR (#5562) and split out
into this follow-up.
### 1. Invalid model id in the opengenui route
`src/app/api/copilotkit-opengenui/[[...slug]]/route.ts:16` set `const
MODEL = "openai/gpt-5.2"` — a nonexistent model id, so every chat turn
errored. Changed to `"openai/gpt-4o"`, the verified-real id used by the
sibling `showcase/shell/src/app/api/copilotkit/[[...slug]]/route.ts`.
### 2. Missing `serverExternalPackages` in next.config.ts
`next.config.ts` lacked `serverExternalPackages`, but the example's API
routes import `@copilotkit/runtime/v2` (a server-only package). Added
`serverExternalPackages: ["@copilotkit/runtime"]` (base package name
covers the `/v2` subpath), mirroring `showcase/shell/next.config.ts`.
## Red → Green evidence
**Model id**
- RED: `route.ts:16` was `const MODEL = "openai/gpt-5.2";`; sibling
`showcase/shell` route uses `model: "openai/gpt-4o"`.
- GREEN: `route.ts:16` is now `const MODEL = "openai/gpt-4o";`.
**serverExternalPackages**
- RED: `grep -n serverExternalPackages next.config.ts` -> no match (exit
1).
- GREEN: `grep -n serverExternalPackages next.config.ts` -> `9:
serverExternalPackages: ["@copilotkit/runtime"],`.
## Build outcome
`next build` is **blocked by SEPARATE pre-existing module-resolution
failures unrelated to these fixes** and NOT addressed here:
- `copilotkit` and `copilotkit-a2ui` routes import
`createCopilotEndpoint` from the bare v1 `@copilotkit/runtime`, which
does not export it.
- The `copilotkit-opengenui` route (and its client-component chain)
imports from `@copilotkitnext/runtime`, which is not a declared
dependency of this package and fails with `Module not found: Can't
resolve '@copilotkitnext/runtime'`.
Because the build fails at module resolution for these pre-existing
imports before compiling the changed lines, a clean end-to-end build
cannot be obtained. Both edits are statically correct: the model id
matches the verified-real sibling, and `serverExternalPackages` mirrors
the working `showcase/shell` config. Fixing the pre-existing
`createCopilotEndpoint` / `@copilotkitnext/runtime` import errors is
explicitly out of scope for this follow-up.
The opengenui route used the nonexistent model id "openai/gpt-5.2", causing
every chat turn to error. Switch to "openai/gpt-4o", the verified-real id used
by the sibling showcase/shell copilotkit route.
The example's API routes import @copilotkit/runtime/v2 (a server-only package),
but next.config.ts lacked serverExternalPackages, so Next.js attempted to bundle
it. Add serverExternalPackages: ["@copilotkit/runtime"] (base package name covers
the /v2 subpath), mirroring showcase/shell/next.config.ts.
## Summary
Migrates all `@copilotkitnext/*` usages onto the v2 entrypoints of the
existing `@copilotkit/*` packages and removes the `@copilotkitnext`
dependency surface from `showcase/shell` and the
`generative-ui-playground` example.
- `@copilotkitnext/react` → `@copilotkit/react-core/v2`
- `@copilotkitnext/agent` & `@copilotkitnext/runtime` →
`@copilotkit/runtime/v2`
- `globals.css` styles import → `@copilotkit/react-core/v2/styles.css`
- `showcase/shell` deps `@copilotkit/{react-core,runtime}` pinned
`latest` → `^1.60.2` (lockfile regenerated → coherent 1.61.0 set)
- dropped `@copilotkitnext/runtime` from `serverExternalPackages`
Result: zero `@copilotkitnext` references in touched source; `next
build` of `showcase/shell` passes (27/27 routes), all `/v2` imports +
styles resolve.
## CR
Reviewed via 7-agent cr-loop, 3 rounds to convergence + Procedure 3
bucket-(c) promotion audit (PROMOTE_TO_A: 0). The R1 mandatory fix was a
missed `.css` migration target (globals.css); the dep-pin hardening
fixed a stale-prerelease lockfile mismatch.
## Follow-up (separate PR)
Pre-existing, out-of-subject issues in the generative-ui-playground
example (tracked separately): invalid model id `openai/gpt-5.2`, and its
own missing `serverExternalPackages`.
Browser extensions such as Grammarly inject attributes onto <body>
(data-gr-ext-installed, data-new-gr-c-s-check-loaded) before React
hydrates, which surfaces as a hydration mismatch error on first load of
the generated Next.js app.
Add suppressHydrationWarning to <body> in the langgraph-python north-star
and propagate to the parity instances (langgraph-js, langgraph-fastapi,
strands-python) via parity:sync. This only relaxes the check for <body>'s
own attributes (one level deep); everything rendered inside <body> is
still fully hydration-checked, and <body>'s className is static so none of
our own markup is masked.
## Summary
- run the plugin metadata sync after release prep updates package
versions
- ensure release PR creation commits include aligned plugin metadata
## Root cause
The release PR action commits generated version bumps, which triggers
the pre-commit plugin sync check. The workflow updated package versions
before committing but did not update plugin metadata first.
## Validation
- bash scripts/release/verify-release-scope-dropdowns.sh
- pre-commit hook
Note: actionlint was not installed locally.
CR-round hardening that builds on the bug #1/#2 fixes: the P2 in-flight race
guard now reads the running digest from meta.imageDigest (the dead guard
never REFUSEd before) and is skipped on the --digest override path. Refresh
the snapshot ivar-lint allowlist line numbers after the surrounding CR line
drift.
Bug #2: promote used serviceInstanceRedeploy, which replays the EXISTING
deployment and never pulls the newly-pinned digest, so prod could keep
serving stale. Switch to serviceInstanceDeployV2 to spawn a NEW deployment
that pulls the pinned digest, then verify_serving_digest! fail-loud asserts
the new deployment reaches SUCCESS and its meta.imageDigest == the pinned
digest. Update the promote mock-GraphQL fixtures across the spec suite to
return serviceInstanceDeployV2 + meta.imageDigest accordingly.
Bug #1: resolved_prod_image re-resolved :latest at promote time, so prod
could be pinned to a digest different from what staging is actually serving.
Now resolve via staging_running_digest (latestDeployment meta.imageDigest)
and REFUSE when unavailable. Add detect_staging_drift +
emit_staging_drift_warnings to surface (non-fatally) when :latest has moved
past staging's running digest; aggregate markers across the fleet in
promote-fleet.sh (printf join) and plumb the drift_line through
showcase_promote.yml (both Slack payloads + fallback log + GITHUB_OUTPUT
single-line guard). Skip drift detection on the --digest override path.
Adds a **Vue** section to the reference docs at `/reference/vue`,
alongside the existing React, React Native, and Core references. Until
now there was no Vue reference, so users and agents had no way to
discover the API.
It mirrors the React v2 reference but documents the real
`@copilotkit/vue/v2` API, with Vue idioms throughout (composables return
refs, slots instead of render props, kebab-case props, Vue SFC
examples).
### What's included
- The Vue index page (install, styling, provider setup)
- 14 composables (useAgent, useFrontendTool, useHumanInTheLoop,
useThreads, and the rest)
- 9 components (CopilotKitProvider, CopilotChat, CopilotPopup,
CopilotSidebar, and the chat sub-components)
- Vue registered in the SDK picker and the reference landing page
### Screenshots
Landing page (SDK picker set to Vue, full sidebar):
A composable page (useAgent):
A component page (CopilotKitProvider):
### How it was verified
- All 24 pages render (HTTP 200) on the local docs server
- Content shows up in `llms.txt` and `llms-full.txt`
- Each page was written from the Vue source, not copied from React, and
spot-checked for accuracy
Guide content and new demos are out of scope.
## Summary
- Update locked Threads drawer copy in integration examples to use `npx
copilotkit@latest license`
- Keep the command consistent across the example variants that render
the licensed feature panel
## Validation
- Pre-commit hooks ran lint/check package hooks successfully
- Verified integration examples no longer render the stale `copilotkit
license` command
Jordan Ritter
