The OSS-136 sales-analyst rework migrated the D6 fixtures but left the
demo page pills on the pre-OSS-136 KPI set in 8 integrations. Port the
4 canonical sales-analyst pills from the langgraph-python reference so
the pills match what the fixtures answer.
Fixes#6791.
## What
Brings the just-released A2UI support and the latest Microsoft Agent
Framework
(Python) into the showcase, and moves the MAF A2UI demos onto the native
subagent / auto-inject technique so they match the langgraph-python
reference
instead of the pre-1.2.0 hand-rolled path.
- **Bump MAF to 1.2.0.** `agent-framework-ag-ui[a2ui]==1.2.0`,
`agent-framework-openai==1.14.0`, `agent-framework-core==1.15.0`,
`ag-ui-a2ui-toolkit==0.0.4`. 1.2.0 is A2UI's first release; the `[a2ui]`
extra
pulls the toolkit.
- **New `a2ui-recovery` demo** (the one A2UI demo the integration lacked
vs
langgraph-python). Backend-owned via the adapter's native `enable_a2ui`
(`injectA2UITool: false`), which runs the shared toolkit's
validate/retry
recovery loop in-process. Heal pill recovers a malformed first render;
exhaust
pill hits the attempt cap and surfaces the `a2ui_recovery_exhausted`
fallback.
Adds the agent, route, page, chat, suggestions, a D6 fixture, and an e2e
spec.
- **Migrate `declarative-gen-ui` to native A2UI auto-injection.**
Removed the
hand-rolled `generate_a2ui` (a raw secondary OpenAI call to
`_design_a2ui_surface`); the agent now binds no A2UI tool and the route
sets
`injectA2UITool: true`, so the adapter's `plan_a2ui_injection`
auto-injects the
native `generate_a2ui` sub-agent. Reworked the D6 fixture to the native
`render_a2ui` shape.
- **Migrate `beautiful-chat` to native A2UI auto-injection.** Same
change for the
flagship composite: removed its hand-rolled `generate_a2ui`, flipped the
route
to `injectA2UITool: true`. The adapter now auto-injects the native
sub-agent
alongside the agent's own tools (todos, query, flights).
- **`a2ui-fixed-schema` unchanged** — it is the fixed-schema pattern
(client
authored schema, agent streams data via a backend `display` tool,
`injectA2UITool: false`), which langgraph-python does identically. Not
hand-rolled generation.
- **Docs.** Enriched the MAF A2UI docs page into real "how to A2UI"
content
(dynamic / fixed / recovery) and connected the A2UI demos via
`docs-links`.
## Why native (not the dojo's example agents)
The showcase mirrors langgraph-python's frontend-catalog + auto-inject
pattern,
not the AG-UI dojo's `a2ui_config` example agents. Before 1.2.0 the MAF
adapter
had no native A2UI, so the showcase hand-rolled `generate_a2ui`. 1.2.0
ships the
native path, so these demos now use it and match langgraph 1:1.
## Validation
- `validate-pins` clean (FAIL count + hash unchanged), `validate-parity`
PASS,
`generate-registry` clean.
- **D6 (full frontend, aimock replay), all green:**
- `a2ui-recovery` — heal paints the recovered surface; exhaust shows the
hard-failure UI.
- `declarative-gen-ui` — all 4 dashboard pills paint on the auto-inject
path
(confirms the runtime forwards `injectA2UITool: true` and
`plan_a2ui_injection` fires).
- `beautiful-chat` — regression across all 5 features (pie/bar chart,
schedule-meeting, search-flights, toggle-theme): wrapping the multi-tool
agent in the A2UI planner loop does not break its non-A2UI tools.
- **AG-UI protocol layer** (published 1.2.0 wheel + aimock): recovery
(heal/exhaust), declarative, and beautiful-chat all stream real
`a2ui_operations` / `a2ui_recovery_exhausted`, RUN_FINISHED, no
RUN_ERROR.
- **Remove the last hand-rolled A2UI (default agent).** The
general-purpose
default agent (`agent.py`, catch-all `/` endpoint) also carried a
hand-rolled
`generate_a2ui`; removed it (the default agent no longer offers A2UI,
matching
langgraph's default agent). Stripped the stale `_design_a2ui_surface`
fixture
residue and refreshed the e2e-spec comments that described the old
mechanism.
After this PR the MAF-python integration has **zero hand-rolled A2UI
anywhere
except the fixed-schema demo** (which is the intended fixed-schema
pattern,
identical to langgraph). The shared `tools/generate_a2ui.py` module is
intentionally left intact — it is symlinked by other integrations (ag2,
agno, …)
that have not migrated; MAF-python simply no longer imports it.
## Pre-existing, out of scope
Full D6 for ms-agent-python is 37/40. The 3 red cells — `multimodal`,
`voice`,
`hitl-approve-deny` — are **not** touched by this PR: their agents are
byte-identical to main and never used `generate_a2ui`. `multimodal` is
the known
shared-CopilotKit frontend bug (`runStartCount=0`, the run never
starts);
`voice`/`hitl-approve-deny` complete the run but their text does not
settle inside
the probe's tight budget. All A2UI and default-agent cells pass.
`generative-ui/tool-based` is now the terminal page every onboarding run fetches
(OSS-1034), and its "How it works in code" section is a bundled
`frontend-tools-setup` concept. Only 5 of 19 frameworks shipped one, so for the
rest the section rendered nothing and absence encoded two different facts: this
framework needs no agent-side wiring, or it needs some and nobody wrote it down.
Four frameworks whose own gen-ui-tool-based demo agent settles the question get
a snippet. pydantic-ai, llamaindex and ms-agent-python declare no tools at all --
the AG-UI request forwards them and their demo agents say so in as many words --
so their snippet states that, and then states the half that is easy to miss: a
model with no instruction about the tool answers in prose and the component never
renders. CrewAI is the opposite case. A Flow owns its own model call, so it has
to read `state.copilotkit.actions` and pass them itself, wrap the call in
`copilotkit_stream`, and drive `tool_choice`.
A compile failure in a bundled snippet no longer returns null. It shared that
return with "nobody bundled this", so a rendering defect shipped looking exactly
like a deliberate omission, traceable only through a console.error nobody reads
in production. Absence stays quiet; a broken snippet throws.
The nine frameworks still undetermined are named in a list a test reads, so a new
framework cannot join the gap silently and closing one means deleting a name.
Refs OSS-1036
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review caught a real bug: the endpoint only applies `a2ui_config` while wrapping a
RAW agent. The recovery factory returned an already-wrapped `AgentFrameworkAgent`,
so its `a2ui_config` was dropped and recovery silently ran on toolkit defaults
instead of the configured `maxAttempts: 3`.
- recovery_agent.py: `create_agent` now returns a raw `Agent`; the /a2ui_recovery
endpoint wraps it and applies `A2UI_RECOVERY_CONFIG` (verified: the wrapper carries
the config). D6 green with the config actually applied.
- Refresh the remaining old-path descriptions to the auto-inject + a2ui_config wording:
manifest.yaml, the demo page.tsx header, the e2e spec contract, and the fixture _note.
Address review: switch the a2ui-recovery demo from an explicit enable_a2ui() wrap
to MAF's auto-injection path, matching the other MAF A2UI demos and MAF's upstream
recovery example.
- recovery_agent.py: now a plain Agent (no enable_a2ui, no tool). The recovery cap
+ catalog live in A2UI_RECOVERY_CONFIG.
- agent_server.py: the /a2ui_recovery endpoint passes a2ui_config=A2UI_RECOVERY_CONFIG
({"recovery": {"maxAttempts": 3}, "default_catalog_id": "declarative-gen-ui-catalog"}).
- route.ts: injectA2UITool false -> true (auto-inject, same as declarative-gen-ui).
- docs: dynamic-schema "backend recovery policy" section now shows the a2ui_config
path instead of enable_a2ui.
Verified: the agent constructs as a plain Agent; plan_a2ui_injection fires from the
forwarded injectA2UITool flag and reads recovery{maxAttempts:3} + catalog from
a2ui_config, producing the same A2UIAgent recovery engine (no separate subagent
client / attempt callback / flag-independent injection needed, so enable_a2ui was
not required).
The MAF A2UI docs were a single page rendering the shared A2UI stub, which
matched neither of the two prod shapes. Restructure to shape #2 — the a2ui
submenu — mirroring the langgraph / strands / deepagents tree 1:1:
generative-ui/a2ui/
index.mdx (Overview)
fixed-schema.mdx
dynamic-schema.mdx
styling.mdx
advanced.mdx
meta.json
Content is ported page-by-page from the reference tree (deepagents, authored
mode) with MAF-accurate code — `agent-framework-ag-ui` auto-injection
(`injectA2UITool`), the real `a2ui_dynamic` / `a2ui_fixed` agents, and the
`enable_a2ui` backend-owned recovery note. styling/advanced are the
framework-agnostic frontend pages. docs-links now point the demos at the
matching sub-pages (dynamic-schema / fixed-schema).
The general-purpose default agent (agent.py, catch-all `/` endpoint) still
carried a hand-rolled `generate_a2ui` (raw secondary OpenAI call to
`_design_a2ui_surface`). Removed it: the default agent no longer offers A2UI at
all, matching the langgraph-python default agent. The main route enables no A2UI
middleware, so this was latent/dead A2UI anyway.
- agent.py: drop the hand-rolled generate_a2ui tool + its import.
- render-a2ui.json: strip the stale `_design_a2ui_surface` fixture entries (the
native `render_a2ui` + generate_a2ui entries remain).
- e2e specs: refresh the declarative-gen-ui + beautiful-chat comments that
described the old `_design_a2ui_surface` mechanism to the native auto-inject path.
The shared `tools/generate_a2ui.py` module is intentionally kept: it is symlinked
by other integrations (ag2, agno, ...) that still hand-roll A2UI; MAF-python
simply no longer imports it. After this, the MAF-python integration has ZERO
hand-rolled A2UI anywhere except the fixed-schema demo (which is the intended
fixed-schema pattern, identical to langgraph). Full D6: all A2UI + default-agent
cells green.
Remove the flagship demo's hand-rolled `generate_a2ui` (raw secondary OpenAI
call to `_design_a2ui_surface`) and flip its route to `injectA2UITool: true`, so
the agent-framework-ag-ui adapter auto-injects the native `generate_a2ui`
sub-agent alongside the agent's own tools (manage_todos, query_data,
search_flights). Matches the langgraph-python reference.
Regression: D6 green across all 5 beautiful-chat features (pie/bar chart,
schedule-meeting, search-flights, toggle-theme) — wrapping the multi-tool agent
in the A2UI planner loop does not break its non-A2UI tools; search_flights still
emits its fixed-schema a2ui_operations. The native dynamic A2UI path
(generate_a2ui -> render_a2ui -> a2ui_operations) is verified against aimock on
the published 1.2.0 wheel. fixed-schema remains backend-owned, matching langgraph.
Replace the pre-1.2.0 hand-rolled `generate_a2ui` (a raw secondary OpenAI call
to `_design_a2ui_surface`) with the native auto-inject path, matching the
langgraph-python reference:
- a2ui_dynamic.py binds NO A2UI tool; the route sets `injectA2UITool: true`, so
the agent-framework-ag-ui adapter's `plan_a2ui_injection` auto-injects the
native `generate_a2ui` sub-agent (progressive `render_a2ui` streaming + the
shared toolkit recovery loop) in-process.
- Reworked the D6 fixture from the `_design_a2ui_surface` shape to the native
`render_a2ui` shape (inner keyed on the full pill prompt; outer emit + narration).
D6 green: all 4 declarative pills pass through the real frontend + browser on the
auto-inject path (verified `plan_a2ui_injection` fires and the runtime forwards
the flag). fixed-schema stays backend-owned (`injectA2UITool: false`), matching
langgraph; that is the fixed-schema pattern, not hand-rolled generation.
Bring the just-released A2UI support and latest Microsoft Agent Framework
(Python) into the showcase, following the langgraph-python A2UI pattern.
- Bump agent-framework-ag-ui[a2ui]/openai/core to 1.2.0/1.14.0/1.15.0. 1.2.0
is A2UI's first release; the [a2ui] extra pulls ag-ui-a2ui-toolkit.
- Add the a2ui-recovery demo, mirroring langgraph-python's recovery demo:
backend-owned A2UI via the adapter's native enable_a2ui (injectA2UITool=false),
which runs the shared toolkit validate/retry recovery loop in-process. The
heal pill recovers a malformed first render into a valid surface; the exhaust
pill hits the attempt cap and surfaces the a2ui_recovery_exhausted fallback.
Reuses the declarative-gen-ui catalog. Adds the agent, route, page, chat,
suggestions, a D6 aimock fixture (framework-unique prompts), and an e2e spec.
- Enrich the MAF A2UI docs page with how-to content covering the three A2UI
flavors (dynamic, fixed, recovery) and connect the three A2UI demos through
docs-links.
Validation: validate-pins clean (count/hash unchanged), validate-parity PASS,
generate-registry clean. The recovery loop is verified at the AG-UI protocol
layer against aimock on the published 1.2.0 wheel (heal streams a2ui_operations
after an invalid-then-valid render; exhaust returns a2ui_recovery_exhausted
after 3 attempts; RUN_FINISHED, no RUN_ERROR).
Moves all 239 showcase integration routes off
`copilotRuntimeNextJSAppRouterEndpoint`, the deprecated v1 Next.js adapter, so
the v1 entrypoint has no remaining code-level users under
`showcase/integrations/`.
const copilotHandler = createCopilotRuntimeHandler({
runtime,
basePath: "/api/copilotkit-x",
mode: "single-route",
});
...
return await copilotHandler(req);
## Why single-route, and why this handler
**Single-route** because these demos' frontends are
`<CopilotKit runtimeUrl="/api/copilotkit-x">` with no transport prop, and every
released provider pins the single-route transport. Single-route mode is
therefore a drop-in for the v1 adapter: no frontend change, no path change, no
`GET` export, and nothing here probes `/info`. Migrating to multi-route instead
would have required editing every demo page in lockstep for no functional gain.
**`createCopilotRuntimeHandler`** rather than `createCopilotEndpointSingleRoute`
because that helper is itself deprecated in favour of the `mode` option (see the
deprecated-aliases table in `docs/backend/runtime-endpoints.mdx`), and because
the fetch handler needs no `hono` dependency and composes directly with the
wrappers these routes already have.
The statement is rewritten in place, inside whatever wrapper it already sat in,
so `withForwardedHeaders`, the try/catch envelopes, `wrapStreamingResponse` and
`withCvdiagBackend` are all untouched. 75 of these routes construct the runtime
inline in the call; rewriting in place preserves that per-request construction
exactly as v1 did. No `runner` is added — it is optional, and none of these
routes passed one before.
13 `copilotkit-auth/[[...slug]]` routes already use the v2 fetch handler and are
left alone; they only mention the v1 name in explanatory comments.
## Collateral
- `mastra`'s main route declared a module-level
`const serviceAdapter = new ExperimentalEmptyAdapter()` plus a startup log
about the adapter choice. V2 has no service adapters, so both are gone and the
comment now explains that there is nothing to configure.
- The three `mastra` vitest suites mocked `@copilotkit/runtime` and the v1
`{ handleRequest }` return shape; they now mock `@copilotkit/runtime/v2` and
`createCopilotRuntimeHandler`, which returns the handler directly.
- 27 `@ts-expect-error` directives guarded the **v1** `CopilotRuntime` agents
type ("wraps Record in MaybePromise<NonEmptyRecord<...>>"). Under `/v2` that
hole is gone, which makes the directive unused — a hard error. They are
demoted to `@ts-ignore`, which compiles whether or not the mismatch survives
in a given integration, because 19 of these apps cannot be built locally to
prove it either way. Removing all ~220 now-stale suppressions is left as
follow-up once CI has built every integration green.
## Verified
`mastra` is the one integration installed and exercised locally (19 routes, the
`withCvdiagBackend` main route, and the only vitest suites that touch routes).
Measured against `origin/main` in the same tree:
tsc --noEmit baseline: errors in 10 files
after: errors in 9 files
new errors introduced: NONE
fixed: src/app/api/copilotkit-mcp-apps/route.ts, whose
@ts-expect-error was ALREADY unused on main
vitest run baseline: 2 files failed, 13 tests failed, 21 passed
after: 2 files failed, 13 tests failed, 21 passed
→ test-neutral; those 13 failures are pre-existing on main
Structural audit over all 239 routes: none still imports the v1 root, uses the
v1 adapter, references `ExperimentalEmptyAdapter` or `handleRequest` in code, or
is missing `createCopilotRuntimeHandler` / `basePath` / `mode: "single-route"`.
The shape itself was proved end-to-end before the rollout, in a real running
app with an untouched provider (aimock as the model backend):
`POST /api/copilotkit` -> 200 twice, chat turn rendered.
## Two pre-existing problems found on the way
- `npm ci` fails in `showcase/integrations/mastra`: `Missing:
@types/http-errors@2.0.5 from lock file`. Its Dockerfile uses
`npm ci --legacy-peer-deps`, which does succeed, so the image still builds —
but a plain `npm ci` does not. Untouched here; no manifest or lockfile is in
this diff.
- `mastra`'s vitest suite is red on `main` (13 failures, mostly
`extractXHeaders` dereferencing `req.headers` on a `{}` fake request).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
multimodal was wrongly quarantined based on a local-only failure: the
sample.png/sample.pdf demo assets are Git LFS pointers, and without
git-lfs on PATH the attachment send fails before the run starts
(runStartCount=0). langgraph-python multimodal fails locally for the
exact same reason, yet declares the feature supported.
Verified the MAF agent actually works: with the real assets in place
the D6 cell is green (2 turns, assertions passed). Both production
deploys serve the real 10KB PNG (LFS pulled), so multimodal is green
in prod for MAF just like langgraph. not_supported_features now matches
langgraph exactly: [gen-ui-interrupt, interrupt-headless].
- Remove multimodal from features (already in not_supported_features);
the duplicate made generate-registry reject the manifest, blocking D6
from starting.
- Pin agent-framework-{ag-ui,openai,core} to exact published latest
(1.0.1 / 1.12.0 / 1.13.0) so validate-pins classifies them as exact
framework deps; drop unused langchain-openai/langchain-core.
- Ratchet validate-pins baseline down 31 -> 27 (the 4 non-exact framework
fails are now exact); ms-agent-python's only remaining FAIL is the
shared-frontend openai ^5.9.0, identical to every other integration.
- frontend-tools-async: drop the stray broad 'project planning' fixture entry that
substring-shadowed 'Find my notes about project planning' -> run-loop. Green.
- gen-ui-open + gen-ui-open-advanced: remove 6 gen-ui-open-owned strays from
gen-ui-tool-based.json ('3D axis visualization', 'Inline expression evaluator',
'render an open gen-ui element', 'continue the advanced gen-ui flow') that
collided (same context, different responses) with gen-ui-open.json. Green;
gen-ui-tool-based unaffected.
- multimodal: quarantine. On main + latest deps the browser gets 200 from the
runtime but never starts a run (runStartCount=0) — a shared multimodal
frontend/runtime issue (identical frontend to langgraph; agent works via direct
POST; my #5985 fix doesn't change it). Genuine gap, needs shared-layer work.
Full D6 now 36/36 green on official latest (ag-ui 1.0.1, core 1.13.0, openai 1.12.0).
- shared-state-streaming: replace main's stale 'counter' fixture (drifted from
langgraph canonical) with the write_document document demo (6-entry poem/email/
quantum + chunkSize) + SharedStateStreamingFrameworkAgent seed subclass; frontend
already matches langgraph. Un-quarantine + add to features. Green (3/3 turns).
- tool-rendering-reasoning-chain: un-quarantine + add to features. Green on core
1.13.0 / openai 1.12.0 (latest) via aimock encrypted_content (CopilotKit/aimock#342,
which fixes the Responses reasoning multi-tool regression) + the store:False agent.
CI-green depends on aimock#342 releasing.
- Drop reasoning-default-render / agentic-chat-reasoning from not_supported (no D6
probe featureType — not real cells).
Port the #5985 fix onto main: ported langgraph's full 18-entry custom-catchall
fixture (main's 4-entry set left SF/flights/d20/chain pills leaking to the
default-catchall fixture) + _ToolRenderingFrameworkAgent dropping the divergent
end-of-run MESSAGES_SNAPSHOT so the narration (not the tool card) is the terminal
bubble. Verified green via per-cell --direct. First cell of the #5985->main
re-integration.
Demo assets under showcase/integrations/*/public/{demo-files,demo-audio}/
were stored two different ways. Ten integrations committed them as LFS
pointers (the root .gitattributes convention); eight carved themselves out
with a per-integration .gitattributes that re-declared the same paths
`-filter -diff -merge`, committing raw binaries instead.
Those carve-outs were added when the image build did not fetch LFS, so a
pointer stub shipped into the image and the multimodal sample-attachment
magic-bytes guard rejected it. That premise no longer holds: the deploy
build's Checkout step hardcodes `lfs: true` (7bde1eef3a), so every
integration image now gets real binaries regardless of storage form. The
overrides are dead weight that only buys divergence.
Delete all eight override files and renormalize the 21 affected assets
through the LFS clean filter. Each override contained nothing but demo-asset
exemptions, so each is removed in full; the root .gitattributes is untouched.
Storage form changes, content does not. Every asset's sha256 already equals
the LFS OID the pointer-mode integrations reference, so each renormalized
blob is bit-for-bit the pointer blob already committed on main -- no new LFS
objects are introduced and no pointer can dangle:
sample.png 10083 B oid 01aa5681de99461247543e9215c1e4da3242e26b2bee11593fcdbe209672d973
sample.pdf 2486 B oid 3da2afae36a1a81fd2c02f15e54bfc38b6c22e41655c31a5b54ff1e0e3daab41
sample.wav 87078 B oid bd4aa7b049f1c3e324dfd15af4068d7f8fbf2eae1dd044df270dddc5f38a5c57
All three OIDs return download actions from the LFS batch API and were
downloaded and confirmed to hash to their OID.
The multimodal PDF turn dropped the user's question out of the final
outbound user message, so the model was handed a document dump with no
question attached. Against aimock's strict mode that surfaced as
`503 no_fixture_match` on turn 2 (turn 1, the image, passed); against a
real LLM it would have silently answered the wrong thing.
Root cause is a serialisation mismatch, not a fixture gap.
`agent_framework_openai._chat_completion_client._prepare_message_for_openai`
emits ONE OpenAI message per `Content` — it builds a fresh `args` dict on
every iteration of its content loop. `_PdfFlattenChatMiddleware` appended
the flattened `[Attached document]` text as a SECOND text `Content` beside
the prompt, so one logical user turn serialised to two consecutive user
messages: prompt-only, then document-only. Anything reading "the current
user turn" off the tail of the list saw only the document.
Merge the flattened document INTO the message's existing prompt text
content instead, so the turn stays a single text content and serialises to
a single user message reading `"<prompt>\n[Attached document]\n<body>"`.
langgraph-python's equivalent agent is green precisely because LangChain
keeps multiple text parts inside one message rather than splitting them.
The merge copies the prompt `Content` rather than mutating it: the
middleware restores the original `contents` list after the model call, and
that restore only undoes the list swap — an in-place mutation would leak
the raw PDF body into the AG-UI MESSAGES_SNAPSHOT and render it in the
user's chat bubble.
Also dedupe identical flattened blocks. The page's `LegacyConverterShim`
appends a legacy `binary` mirror alongside every modern attachment part, so
the same PDF arrives twice and its body was being sent to the model twice.
No fixture change: the existing `userMessage` match key is correct and is
what the corrected request shape satisfies.
The D6 e2e-full probe for ms-agent-python:gen-ui-declarative failed at turn 1
with reason=surface-missing. Two root causes, both fixed:
1. Stale aimock fixture. The fixture still carried the old D5 pill prompts
(KPI/pie/bar/status) plus a lone outer generate_a2ui entry for the current
sales-dashboard prompt with no matching inner _design_a2ui_surface or
narration. The backend looped generate_a2ui to its invocation limit and
RUN_FINISHED was blocked while the tool call stayed active. Re-authored to
the current 4 VantageThreads sales prompts mirroring the llamaindex green
north-star for this backend shape: the outer generate_a2ui returns a
`context` steering phrase (the ms-agent-framework session does not surface
the latest user message to the secondary LLM), the inner
_design_a2ui_surface fixture matches that phrase (not the full prompt), and
hasToolResult discriminates outer vs narration. This also avoids the stale
render-a2ui "KPI dashboard" catch-all collision that was rendering the wrong
surface.
2. Renderer/catalog drift. ms-agent-python's declarative-gen-ui renderers.tsx
and definitions.ts lagged the green peers — missing the DataTable and
InfoRow components (declarative-data-table / declarative-info-row testids)
that turns 2 and 4 assert, plus Metric trendValue and the Row/Column/Text
gap overrides. Brought both files to parity with the langgraph-python /
google-adk green cluster.
Red-green proof on the real control-plane surface (SHOWCASE_ISO_SLOT=11,
--d6 --isolate):
- RED: d6:ms-agent-python/gen-ui-declarative = red (exit 1, turn 1 surface-missing)
- GREEN: d6:ms-agent-python/gen-ui-declarative = green (exit 0, 1 passed)
Visually verified all 4 turns via Playwright (header-injected to replicate the
harness x-aimock-context): turn 1 renders 4 KPI metrics + region pie + monthly
bar; turn 2 the rep-quota DataTable + attainment bar; turn 3 three at-risk
StatusBadges + KPI metrics; turn 4 seven InfoRow account facts + product-line
pie.
Restore the 12 Python integration tools/ dirs to symlinks into
shared/python/tools. They had eroded to real, drifting copies via an
accidental stage_shared() leak (commit 534cd1efa7) — the structural root
cause of showcase divergence bugs. Symlinking re-establishes the single
source of truth; content is identical to shared (only render_a2ui naming
and the shared roll_dice/sanitize additions are adopted).
Add showcase/AGENTS.md documenting the 4 iron rules and the single-source
symlink mechanism, plus a validate-shared-symlinks CI guard (shrink-only
baseline) that fails on any NEW erosion.
Gates per-request POST + 2xx Response-status + GET health-probe logs behind SHOWCASE_ROUTE_DEBUG across 19 integrations to stay under Railway's 500-logs/sec cap, while logging non-2xx responses unconditionally so production errors stay visible.
The auth demo capped at D4 across integrations because the post-sign-out
rejection banner never rendered. The post-sign-out `agent_run_failed` is
delivered only on the agent-scoped `<CopilotChat onError>` channel — never the
provider-level `<CopilotKit onError>` the demos listened on — so the D5/D6 auth
probe's rejection-surface assertion failed and the cell was capped at D4.
Fix (applied to all 19 integrations whose auth demo reproduced the bug): wire a
stable `handleAuthError` onto the agent-scoped `<CopilotChat onError>` (keeping
the provider handler), key the error surface off auth-error STATE alone with a
clear-on-auth effect (removing the `&& !isAuthenticated` cross-slice race), and
harden the rejection-banner message fallback against nullish error events.
Scope: 19 of 20 integrations. built-in-agent already passes (renders via its
ChatErrorBoundary); claude-sdk-python adapted to its legacy/error-boundary shape.
Bump the canonical CopilotKit pin across all showcase integrations + shell
to 1.61.2 (canonical-pins.json, every package.json + package-lock.json),
which carries CopilotKit#5611: passing a catalog to the provider
(`<CopilotKit a2ui={{ catalog }}>`) now auto-enables A2UI and defaults tool
injection on, so the runtime no longer needs an explicit `a2ui` config.
Demonstrate the feature on the A2UI dynamic (declarative-gen-ui) demos by
removing the now-redundant runtime `a2ui` block (`injectA2UITool: true` +
`defaultCatalogId`) from:
- langgraph-python, langgraph-fastapi, langgraph-typescript
- strands, strands-typescript
- google-adk
The forwarded catalog supplies its own catalogId (sdk-js A2UI middleware
auto-derives `defaultCatalogId` from it), so the previous "Catalog not found"
fallback no longer applies.
Verified: validate-pins drift ratchet unchanged (38 / same hash);
langgraph-python D6 `gen-ui-declarative` green end-to-end (no Catalog-not-found).
Bump every @copilotkit/* dependency across the showcase integrations and
the shell from 1.60.2 (and stray "latest" override pins) to an exact
1.61.1 pin, and move the canonical pin source of truth to match.
Regenerate each standalone npm package-lock.json with the same
--legacy-peer-deps flag the Dockerfiles use for "npm ci".
- showcase/integrations/*/package.json + package-lock.json
- showcase/integrations/langgraph-typescript/src/agent/*
- showcase/shell/package.json + package-lock.json
- showcase/scripts/showcase-canonical-pins.json: canonical 1.60.2 to 1.61.1
aimock stays on its own version line (1.26.1). The Python copilotkit SDK
was already 0.1.94 across every requirements.txt, so no change there.
validate-pins ratchet is unchanged (FAIL=38, identical hash);
validate-parity, validate-fixture-tool-surface, and the showcase/scripts
vitest suite (2102 tests) all pass.
Aligns dependency versions across all 19 showcase integrations to current
released minor versions for the 1.60.2 release cycle.
Package families:
- @copilotkit/{a2ui-renderer, react-core, react-ui, runtime, shared, sdk-js, voice}
1.59.4 -> 1.60.2 (18 integrations already staged; ms-agent-harness-dotnet
catches up from 1.57.2)
- @ag-ui/{client, core, encoder} 0.0.55 -> 0.0.57
- @ag-ui/mastra 0.2.1-beta.2 -> 0.2.4 (stable on 0.x; 1.0.x major held back)
Includes the previously-missed ms-agent-harness-dotnet integration in the
@copilotkit/* bump, plus the @copilotkit/web-inspector override pin.
Lockfile-only reconciliation via npm install --package-lock-only
--legacy-peer-deps (cmdk@0.2.1 pre-existing react^18 peer-dep is unaffected).
The injected render_a2ui tool guide instructs models to omit catalogId
("the catalog id is set by the host"), and backend-owned generate_a2ui
tools see real models omit or late-stream it. Without defaultCatalogId
the a2ui middleware falls back to the spec basic catalog, which no
showcase page registers — surfaces fail with "Catalog not found:
https://a2ui.org/specification/v0_9/basic_catalog.json" (reported on
beautiful-chat / langgraph-python).
Pin each route to the catalog its page registers: beautiful-chat ->
copilotkit://app-dashboard-catalog, declarative-gen-ui ->
declarative-gen-ui-catalog. Routes with no a2ui block never attach the
middleware and are left untouched.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Annotates 14 integration manifests with d6_not_supported_features entries
and aligns d6_supported_features with what each backend actually implements,
so the D6 fleet probe only enumerates demos that the backend can serve.
deepshekhardas