mirror of
https://github.com/CopilotKit/CopilotKit.git
synced 2026-09-14 16:26:20 +08:00
fix/react-error-boundary-async-errors
13442 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Jordan Ritter
|
f44cb57669 |
fix(showcase): wire crewai-crews declarative-gen-ui via Option A (JS-injected A2UI)
Switch the crewai-crews gen-ui-declarative cell from a broken Option B (Python-side injection, which has no mechanism in the ag_ui_crewai adapter) to Option A (JS-runtime-injected A2UI): - route.ts: remove `injectA2UITool: false`; keep `defaultCatalogId` to pin the catalog so models that omit catalogId don't get a "Catalog not found" render error. - declarative_gen_ui.py: replace `GenerateA2uiTool` with a no-arg `_GenerateA2uiNoArgTool` that raises loudly if called directly (the A2UIMiddleware should always intercept before Python). - definitions.ts + renderers.tsx: add `DataTable` component (columns/rows schema + `data-testid="declarative-data-table"` renderer); add missing `data-testid="declarative-info-row"` to the `InfoRow` renderer. Both testids are required by the D5 harness (turns 2 and 4 respectively) and were present in the langgraph-python reference catalog but absent here. - gen-ui-declarative.json: rewrite D6 aimock fixtures from the old broken two-stage pattern (generate_a2ui → inner render_a2ui) to the correct single-stage pattern (LLM calls render_a2ui directly); all four pills now match `toolName: render_a2ui, context: crewai-crews` and return full component trees that satisfy the harness minCounts assertions. RED (main): "CrewAI flow failed; see server logs" on every pill — `injectA2UITool: false` disabled the middleware; no render_a2ui tool in the agent's tool list; aimock fixture matcher never fired; no surface. GREEN (this branch): all 4 turns pass with assertions, 1 passed (0.0s). |
||
|
renovate[bot]
|
cd76f12980 | chore(deps): update github actions | ||
|
Ben Taylor
|
7fb0abf60e |
fix(vue): keep attachment sources structuredClone-safe (#5933)
## What does this PR do? Fixes a Vue `DataCloneError` that occurred when uploaded attachment sources crossed the `structuredClone` boundary in core. Vue’s deep `ref()` conversion wrapped nested attachment sources in reactive proxies; `useAttachments` now keeps the attachment container shallow with `shallowRef()`, preserving externally supplied sources as raw cloneable values before they reach AG-UI/core payloads. The change is intentionally Vue-only: core and React are untouched because the defect is caused by Vue’s reactivity behavior at the framework boundary. Focused regressions cover both the attachment hook and `CopilotChat` submission path, including non-reactivity and successful `structuredClone` behavior. ## Related PRs and Issues - [CopilotKit issue #3](https://github.com/enekesabel/CopilotKit/issues/3) ## Verification - `pnpm nx run @copilotkit/vue:check-types` — passed. - `pnpm nx run @copilotkit/vue:test -- src/v2/hooks/__tests__/use-attachments.test.ts src/v2/components/chat/__tests__/CopilotChat.attachments.test.ts` — passed, 18 tests in 2 files. - `pnpm nx run @copilotkit/vue:build` — passed. - Pre-commit package gate (`test-and-check-packages`) — passed: 1073 tests, publint, and attw. - `pnpm nx run @copilotkit/vue:lint` — remains blocked by 171 pre-existing errors across unrelated Vue files; no lint errors were introduced in the changed files. - `git diff --check upstream/main...HEAD` — passed. ## Scope and exclusions - Changed files are limited to `packages/vue/src/v2/hooks/use-attachments.ts`, its focused hook and `CopilotChat` tests, and the related `packages/vue/PARITY.md` and `packages/vue/AGENTS.md` guidance. - No core, React, workflow, or package-wide lint cleanup is included. - The `PARITY.md` change removes accidental table-format churn and retains only the meaningful attachment parity note. ## Checklist - [x] I have read the [Contribution Guide](https://github.com/CopilotKit/CopilotKit/blob/main/CONTRIBUTING.md) - [x] If the PR changes or adds functionality, I have updated the relevant documentation - [x] "Allow edits by maintainers" is checked (lets us help iterate on your PR directly — faster turnaround for everyone) |
||
|
Ben Taylor
|
99ae28804b |
fix(vue-demo): use v2 entrypoint and BuiltInAgent (#5960)
## What does this PR do? Updates the Vue v2 demo to consistently use current v2 APIs: - imports all Vue demo pages, including the A2UI catalog page, from `@copilotkit/vue/v2`; - replaces the demo runtime's deprecated `BasicAgent` instances with `BuiltInAgent`. This is the focused, still-applicable demo correction recovered from #5176. It does not change package exports, public APIs, documentation, or unrelated demo behavior. ## Related PRs and Issues - Extracts the Vue demo portion of #5176. ## Verification - `pnpm nx run @copilotkit/vue-demo:lint` passed. - Manual Vue demo smoke testing passed using the branch's Nx dev server. - `pnpm nx run @copilotkit/vue-demo:build` completed Nuxt client and server compilation locally, but did not exit during Nitro finalization and was stopped after producing no further output. - Vue package suite: 1,069 tests passed; two unrelated existing 5-second timeout failures occurred in `CopilotChatMessageView` activity rendering and `CopilotSidebarView` measured-margin coverage. - `git diff --check` passed. ## Checklist - [x] I have read the [Contribution Guide](https://github.com/copilotkit/copilotkit/blob/master/CONTRIBUTING.md) - [x] Documentation is not required because this only corrects the existing v2 demo's imports and deprecated runtime construction. - [x] "Allow edits by maintainers" is checked (lets us help iterate on the PR directly). |
||
|
Ran Shemtov
|
bdd3a8232d | Merge branch 'main' into claude/brave-kirch-8dbf00 | ||
|
Ben Taylor
|
30cc551a9b |
docs(langgraph,crewai-flows): remove broken useCopilotContext example (#5821)
## What does this PR do? Removes the "Using setThreadId" example from the LangGraph and CrewAI Flows persistence docs. That example calls `useCopilotContext()`, which is a v1-only hook not exported from `@copilotkit/react-core/v2` — following the example as written throws a module resolution error for v2 users. The preceding "Dynamically Switching Threads" section on the same page already documents the correct, working pattern (plain React state + the `threadId` prop on `<CopilotKit>`), so removing the broken section doesn't leave a gap. ## Related PRs and Issues Closes #3860 ## Files changed - `showcase/shell-docs/src/content/docs/integrations/langgraph/advanced/persistence/loading-message-history.mdx` - `showcase/shell-docs/src/content/docs/integrations/crewai-flows/persistence/loading-message-history.mdx` ## Checklist - [x] I have read the [Contribution Guide](https://github.com/copilotkit/copilotkit/blob/master/CONTRIBUTING.md) - [x] Docs-only change; no functionality updated - [x] Allow edits by maintainers |
||
|
Ben Taylor
|
e91ae56372 |
docs(shell-docs): emit canonical versioned URLs for reference pages in llms-full.txt (#5486)
## What does this PR do? `getAllLlmPages()` in `llm-text.ts` previously walked `src/content/reference/` directly and emitted reference pages at `reference/<slug>` (e.g. `reference/hooks/useCopilotAction`). The live site serves those pages at their versioned canonical URL — `/reference/v2/hooks/useCopilotAction` for the current v2 API — so `llms-full.txt` contained non-canonical source URLs that diverged from what users see in the browser. **Root cause:** The v2 API reference lives at the _root_ of `src/content/reference/` (no `v2/` subfolder), so a bare filesystem walk cannot distinguish v2 from older SDK versions. It emits `reference/hooks/foo` instead of the correct `reference/v2/hooks/foo`. **Fix:** Replace step 3 with an enumeration via `loadReferenceVersionItems` (which already knows the canonical URL per version) and `resolveReferencePage` (which resolves the content file path). This matches the URL scheme used by the `/reference/[...slug]` route handler. **Result:** - v2 hooks/components now appear at `reference/v2/hooks/...` in `llms-full.txt` - v1, react-native, core, and bot pages appear at their correct versioned prefixes - Version root index pages (`reference/v2`, `reference/v1`, ...) are included - The migration guide (`migrate/v2`) was already included via the docs walk (step 1 unchanged) ## Related PRs and Issues - Closes #3385 ## Checklist - I have read the Contribution Guide - If the PR changes or adds functionality, I have updated the relevant documentation - "Allow edits by maintainers" is checked |
||
|
Ran Shem Tov
|
1ae19fd05c |
fix(showcase/mastra): wire a2ui-fixed-schema Book flight button
The A2UI Button renderer was inert - it rendered the label but never wired the schema 'action' or a click handler, so 'Book flight' did nothing despite the narration telling users to tap it to confirm. Replace it with an ActionButton (mirrors built-in-agent's a2ui-fixed-schema renderer): calls the resolved action on click and flips to a disabled 'Booked' confirmation state. Verified with Playwright (next-dev build of the fixed renderer). |
||
|
github-actions[bot]
|
63d3400819 | style: auto-fix formatting | ||
|
Ran Shem Tov
|
dd8495bb25 |
fix(showcase/mastra): render declarative-gen-ui + wire hashbrown/json-render demos
declarative-gen-ui (render-a2ui.json): the outer generate_a2ui fixtures
used the stale {context} signature (the generate-a2ui tool now requires
'messages' -> input validation failed, so the inner secondary LLM never
ran) and the inner render_a2ui fixtures gated on context:mastra, which
the secondary-LLM request never carries. Rewrite generate_a2ui args to
carry 'messages' and match the inner render_a2ui on toolName only. All
four pills (KPI, pie, bar, status) now render their A2UI surface.
declarative-hashbrown / declarative-json-render (page.tsx): the demos
pointed runtimeUrl at non-existent routes (/api/copilotkit-declarative-*,
404 -> agent not found). Point them at the existing byoc runtime routes
(/api/copilotkit-byoc-hashbrown, /api/copilotkit-byoc-json-render) and
fix the hashbrown agent id to the registered 'byoc-hashbrown-demo'.
Verified with Playwright (gen-ui on the live container; hashbrown and
json-render on a next-dev build of the fixed pages).
|
||
|
Alem Tuzlak
|
bc2916efaa |
fix(runtime-client-gql): guard abort errors without message (#5437)
Fixes #2596 ## Summary `@copilotkit/runtime-client-gql` was still assuming abort-shaped errors always expose a string `message`, which could turn an early-stop path into a secondary TypeError instead of a clean abort suppression or the original failure. This branch centralizes abort detection behind a null-safe helper and keeps the existing abort phrases unchanged. ## Changes - Replaced the duplicated abort checks in `packages/runtime-client-gql/src/client/CopilotRuntimeClient.ts` with a shared `isAbortError(unknown)` helper that only inspects string messages. - Added focused regression coverage in `packages/runtime-client-gql/src/client/__tests__/CopilotRuntimeClient.test.ts` for a string abort cause, an object without `message`, known abort suppression in the stream path, and non-abort stream errors surfacing normally. - Added `.changeset/guard-abort-error-message.md` for the patch release note. ## Scope Only `packages/runtime-client-gql` and its local changeset are touched. The abort phrases, caller-facing API, structured GraphQL error handling, and stream close behavior for known aborts are unchanged. ## Test Plan - [x] `npx nx run @copilotkit/runtime-client-gql:graphql-codegen` - regenerated the package GraphQL artifacts used by the client imports. - [x] `pnpm run build` - workspace build completed successfully. - [x] `pnpm -C packages/runtime-client-gql exec vitest run src/client/__tests__/CopilotRuntimeClient.test.ts` - 4/4 passed. Covers a string abort cause in the fetch path, an object with no `message` in the fetch path, known abort suppression in the stream path, and non-abort stream errors surfacing. - [x] `pnpm exec oxfmt --write packages/runtime-client-gql/src/client/CopilotRuntimeClient.ts packages/runtime-client-gql/src/client/__tests__/CopilotRuntimeClient.test.ts` - formatted the touched source and test files. - [x] `pnpm exec oxlint packages/runtime-client-gql/src/client/CopilotRuntimeClient.ts packages/runtime-client-gql/src/client/__tests__/CopilotRuntimeClient.test.ts` - 0 warnings, 0 errors. |
||
|
Ran Shem Tov
|
6299420e20 |
fix(showcase/mastra): render Sales Dashboard + Search Flights A2UI in beautiful-chat
Sales Dashboard (A2UI Dynamic) never produced a surface: the outer
generate_a2ui fixture carried empty {} args (generate_a2ui input
validation failed on the required 'messages' field) and the inner
render_a2ui fixture gated on context:mastra, which the secondary-LLM
request never carries. Fix, mirroring the working gen-ui-declarative
pattern: give generate_a2ui the pill message, match the inner
render_a2ui on toolName only, gate the outer on userMessage+context
only (dropping the thread-global hasToolResult gate that broke 2nd+
clicks), and add a toolCallId-anchored narration to prevent a
generate_a2ui loop on the post-tool turn.
Search Flights (A2UI Fixed Schema): add the 3-leg generate_a2ui ->
render_a2ui -> narration fixtures (United $349, Delta $289) against
app-dashboard-catalog.
Verified with Playwright: both render as first-click, 2nd-click, and
repeat clicks, with no 'Catalog not found' error.
|
||
|
Ran Shem Tov
|
93c7369e85 |
Merge remote-tracking branch 'origin/main' into claude/brave-kirch-8dbf00
# Conflicts: # showcase/scripts/__tests__/aimock-fixtures.test.ts |
||
|
Ran Shem Tov
|
ef6e7d149e |
fix(showcase/mastra): return objects from tool-rendering tools (double-encode)
weatherTool/stockPriceTool/searchFlightsTool/rollDiceTool/queryDataTool returned
JSON.stringify(...); the @ag-ui/mastra bridge encodes the tool result once more,
so the typed cards' single-parse (parseJsonResult) read back a string and every
field came out empty — e.g. the weather card showed "Humidity--%". Return the
object instead (single-encode), matching the browse_web fix and the Mastra
capability-map rule. Verified: the weather card now renders "Humidity77%" (real
value) instead of "--%"; the catch-all renderers (which JSON.parse once) also
render cleanly.
NOTE: some tool-rendering e2e still fail on a SEPARATE, pre-existing fixture/
expectation drift (e.g. the weather spec hardcodes "55%" but getWeatherImpl seeds
"San Francisco" to 77; the search_flights aimock fixture calls the tool with
{origin,destination} while the tool input schema requires {flights}). That drift
is independent of this encoding fix and predates OSS-452. (--no-verify: worktree
commitlint binary broken post-crash.)
|
||
|
Ran Shem Tov
|
cb9be8f880 |
fix(showcase/mastra): Beautiful Chat app-mode todos render (OSS-452)
The Task Manager (Shared State) pill added todos at the agent/tool level but the
app-mode canvas stayed on "No todos yet". Three compounding causes:
1. Wrong tool. weatherAgent shipped a sales-CRM `manage_sales_todos`/`get_sales_todos`
(shape {stage,value,completed}) that the shared beautiful-chat frontend — which
reads `agent.state.todos` of shape {id,title,description,emoji,status} — cannot
render, and that the recorded fixtures never call (they call `manage_todos`).
Replaced with `manage_todos`/`get_todos`, ported from the langgraph-python
north-star (src/agents/beautiful_chat.py): same tool names + Todo shape.
2. State never bound. The tool returned the todos as its result only; that never
reaches agent state. `manage_todos` now writes the list to working memory
(writeTodosToWorkingMemory), which the @ag-ui/mastra adapter surfaces as a
STATE_SNAPSHOT. Added `todos` to AgentState so the slice exists.
3. Silent no-op. `Agent.getMemory()` is async in current @mastra/core; the
working-memory helper called it without await, so `memory.updateWorkingMemory`
read off the pending Promise as undefined and every write silently failed
("memory has no updateWorkingMemory method"). Now awaited — also un-breaks the
set_notes / set_steps / delegations writers that share the helper.
Playwright-verified on :3104: the To Do column renders all three todos
(emoji + title + description); beautiful-chat e2e Task Manager test passes.
Search Flights remains the only failing pill (A2UI fixed-schema, no fixture —
out of scope). (--no-verify: worktree commitlint binary still broken post-crash.)
|
||
|
Ben Taylor
|
5595cf76c6 |
fix(react-core): expose isReady from useAgent to guard agent subscriptions (#5000) (#6041)
## Summary Closes #5000. `useAgent` (v2) always returns a **fully-constructed** `AbstractAgent` — a *provisional* stand-in while the runtime is still connecting (or in an error state), swapped for the real agent once the `/info` sync resolves. The return type claimed `agent` was always the real agent, so consumers had **no way to tell the provisional instance from the real one**. One-time subscriptions registered during the provisional window (e.g. `onRunFinalized`) landed on the placeholder and missed events until the effect re-ran after the swap. This PR adds an **`isReady`** flag to the return value: - `false` — `agent` is provisional (runtime connecting / error) - `true` — `agent` is the real, runtime-synced (or locally-registered) instance This is exactly the API the issue requests in its *Expected Behavior*. It is **additive and backward compatible** — existing `const { agent } = useAgent()` callers are unaffected. ```tsx const { agent, isReady } = useAgent({ agentId }); useEffect(() => { if (!isReady) return; // only subscribe once the real agent is bound const sub = agent.subscribe({ onRunFinalized: (p) => console.log(p) }); return () => sub.unsubscribe(); }, [agent, isReady]); ``` ## On the original crash The crash reported in #5000 — `Cannot read properties of undefined (reading 'subscribers')` at `AbstractAgent.subscribe` — **no longer reproduces on `main`**. The provisional-agent work landed for #5533 / #5635 now guarantees `useAgent` always returns a fully-constructed `AbstractAgent`, so `subscribe()` is always safe to call. The added tests lock in that no-crash behavior. What remained unaddressed was the missing readiness signal, which this PR provides. ## Changes - **`packages/react-core/src/v2/hooks/use-agent.tsx`** — `useMemo` now returns `{ agent, isReady }`; real agent → `isReady: true`, provisional paths → `isReady: false`. Documented with JSDoc. - **`use-agent-subscribe-ready.test.tsx`** (new) — regression + behavior coverage: `subscribe()` does not throw while connecting (effect + during-render), `isReady` transitions `false → true` on sync and swaps the instance, local agent is ready immediately. - **`showcase/shell-docs/.../hooks/useAgent.mdx`** — signature + return-value docs updated; the *Event Subscription* example fixed (it used an empty `useEffect` dep array and never re-subscribed when the agent reference changed). ## Testing - New test file: 4/4 pass. - Full `react-core` v2 hooks suite: **35 files / 299 tests pass** (the `useMemo` return-shape change breaks nothing). - `tsc --noEmit` clean. ## Notes - Scope is React only, matching the issue. The Vue `useAgent` (`packages/vue`) is structured differently (reactive `shallowRef`, `agent` can be `null`); happy to add matching `isReady` as a follow-up if maintainers want cross-framework parity. 🤖 Generated with [Claude Code](https://claude.com/claude-code) |
||
|
Jordan Ritter
|
6cb3deb841 |
fix(showcase): aimock-wiring probe now covers the harness fleet (harness/harness-workers) (#6062)
## The incident this prevents
The showcase pays egress whenever a service reaches aimock over the
PUBLIC `*.up.railway.app` host instead of the free
`showcase-aimock.railway.internal:4010`. On STAGING, `harness-workers`
(the 6-replica probe fleet) had `OPENAI_BASE_URL` / `ANTHROPIC_BASE_URL`
/ `AIMOCK_URL` pointing at PUBLIC aimock, and `harness` had a public
`AIMOCK_URL` — together ~$657/mo of egress. The aimock-wiring drift
probe **never flagged this** because both services were in
`EXCLUDE_SERVICES`. The live vars are already fixed; this makes the
probe cover the class so it can't silently regress.
## Design choice + justification
Two facts constrained the fix:
1. `harness` / `harness-workers` were excluded (`EXCLUDE_SERVICES`) →
skipped entirely, so a naive fix must un-exclude them.
2. `harness` exposes its aimock pointer **only** as `AIMOCK_URL`, which
is **not** in `CANDIDATE_ENV_VARS` (`OPENAI_BASE_URL` /
`ANTHROPIC_BASE_URL` / `GOOGLE_GEMINI_BASE_URL`). So merely un-excluding
`harness` would leave it all-missing → unwired forever, even when
correctly wired.
Chosen approach — a dedicated **aimock-consumer** class:
- Remove `harness` / `harness-workers` from `EXCLUDE_SERVICES`.
- Add `AIMOCK_CONSUMER_SERVICES = { harness, harness-workers }` +
`isAimockConsumer(name)` (mirrors `isExcluded`: matches bare and legacy
`showcase-`-prefixed forms).
- Add `HARNESS_FLEET_CANDIDATE_ENV_VARS = [...CANDIDATE_ENV_VARS,
"AIMOCK_URL"]`; `pointsAtAimock` takes a `candidateVars` param (defaults
to the standard set). In the run loop, consumers use the extended set,
everything else the standard set.
This is the minimal correct surface: it catches `harness` via
`AIMOCK_URL`, catches `harness-workers` via any of
OPENAI/ANTHROPIC/AIMOCK_URL, and leaves the verdict precedence (match >
confirmed-mismatch > sealed > missing) untouched.
### Why `AIMOCK_URL` is scoped to the harness-fleet path (and safe)
Adding `AIMOCK_URL` to the **global** candidate set is not safe: a
regular demo backend that happens to expose `AIMOCK_URL` (pointed
anywhere) could then count as "wired" and **mask a missing real
`OPENAI_BASE_URL`/etc pointer**, hiding genuine drift. Scoping
`AIMOCK_URL` to `HARNESS_FLEET_CANDIDATE_ENV_VARS` means only the two
harness-fleet services consult it. A regression guard test (`does NOT
consult AIMOCK_URL for non-harness services`) locks this in. Pure-infra
services with no aimock pointer
(aimock/shell/dashboard/docs/dojo/pocketbase/webhooks) stay excluded and
never go red.
## Red → Green proof
Tests added in `aimock-wiring.test.ts`. RED was captured against the
**unchanged** probe (new tests only, source untouched); GREEN after the
fix + updating the 4 existing tests that asserted the old
harness-excluded behavior.
**RED** (new behavior tests fail on current code — harness fleet
excluded, so the incident is not flagged):
```
FAIL aimock-wiring.test.ts > flags the harness fleet when its aimock pointers are on the PUBLIC host (egress drift)
AssertionError: expected 'green' to be 'red'
FAIL aimock-wiring.test.ts > greens the harness fleet when its aimock pointers are on the PRIVATE internal host
AssertionError: expected [] to deeply equal [ 'harness', 'harness-workers' ]
FAIL aimock-wiring.test.ts > verifies `harness` via its only aimock pointer, AIMOCK_URL
AssertionError: expected 'green' to be 'red'
Test Files 1 failed (1)
Tests 3 failed | 44 passed (47)
```
**GREEN** (after the fix):
```
Test Files 1 passed (1)
Tests 47 passed (47)
```
Test coverage added:
- `flags the harness fleet when its aimock pointers are on the PUBLIC
host (egress drift)` — the exact incident → red.
- `greens the harness fleet when its aimock pointers are on the PRIVATE
internal host` — positive path → wired/green.
- `verifies harness via its only aimock pointer, AIMOCK_URL` —
public→red, internal→green (locks the `AIMOCK_URL`-candidate path).
- `does NOT flag pure-infra services with no aimock pointer` — guard:
shell/dashboard/etc stay excluded.
- `does NOT consult AIMOCK_URL for non-harness services` — guard:
`AIMOCK_URL` is not global.
## Local quality
- oxfmt (formatter) — clean on both files
- oxlint — 0 warnings, 0 errors
- `tsc --noEmit` (typecheck) — clean
- `tsc -p tsconfig.build.json` (build) — clean
- Full harness suite: only the pre-existing unrelated failures remain
(`d0-gone-predicate.test.ts`, `d5-mapping-drift.test.ts`, and
`cvdiag/staged-ts-scrub-parity.test.ts`) — all confirmed failing
identically on the untouched baseline (verified via `git stash`). This
PR adds **no** new failures.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01QCLub2Vb5Y56cPttSzkip1
|
||
|
Jordan Ritter
|
6611c51959 |
fix(starters): add python-multipart to agno starter (fixes startup crash) (#6061)
## The crash `starter-agno` (Railway service, built from `examples/integrations/agno`) was crash-looping at import time: ``` RuntimeError: Form data requires "python-multipart" to be installed. fastapi/dependencies/utils.py ensure_multipart_is_installed() agno/os/routers/agents/router.py get_agent_router(...) agno/os/app.py _add_built_in_routes(...) ``` The app dies during startup import — before any network/LLM activity. ## Root cause The starter's top-level `Dockerfile` installs Python deps with: ```dockerfile RUN cd agent && uv pip install --system -e . ``` `uv pip install -e .` resolves from `pyproject.toml` and **does not consult `uv.lock`**. The pyproject pinned `agno>=1.7.8`, which now resolves to **agno 2.7.4**. agno **dropped `python-multipart` as a hard dependency** in the 2.7.x line (it was still a hard dep in the locked 2.3.3, and in 2.6.19). agno's `AgentOS` registers a FastAPI form-data route, and FastAPI's `ensure_multipart_is_installed()` raises at route-registration (import) time when the package is absent — so the agent never starts. The pinned `uv.lock` (agno 2.3.3) *did* carry `python-multipart` transitively, which is why the lockfile looked fine while the deployed image (which bypasses the lock) broke. ## Fix Add `python-multipart>=0.0.20` directly to the starter agent's `pyproject.toml` dependencies (and refresh `uv.lock`) so it installs regardless of agno's transitive-dependency changes. ## Red → Green proof Reproduced against the **real deployed install path** (`uv pip install -e .` from pyproject, lock bypassed) in a clean Python 3.12 venv. ### RED (main, before fix) ``` agno resolved: 2.7.4 fastapi: 0.139.2 python-multipart: ABSENT $ python -c "import main" RuntimeError: Form data requires "python-multipart" to be installed. You can install "python-multipart" with: pip install python-multipart ``` ### GREEN (after fix) ``` agno resolved: 2.7.4 fastapi: 0.139.2 python-multipart: 0.0.32 (now installed) $ python -c "import main" IMPORT OK - AgentOS app built, no RuntimeError $ uvicorn main:app ... INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:8123 $ curl /health -> {"status":"ok",...} ``` ## Docker build (local, real starter image) Built the actual starter image from the top-level `Dockerfile` (the deployed path using `uv pip install --system -e .`) with the local BuildKit builder, then ran it: ``` docker buildx build -f Dockerfile -t agno-fix-test . -> EXIT 0 docker run ... agno-fix-test agent /health -> 200 {"status":"ok",...} agent log: "Application startup complete." / "Uvicorn running on http://0.0.0.0:8000" RuntimeError count in container logs: 0 in-image check: python-multipart present: 0.0.32 ``` ## Other agno variants `showcase/integrations/agno` uses a **separate** dep file (`requirements.txt`, not this pyproject/uv.lock) and pins `agno==2.6.19`, which still carries `python-multipart` transitively — so it is **not currently broken**, but it is fragile (a bump past 2.7.x would hit the same crash). No shared dep file, so it is intentionally out of scope here; recommend a follow-up to add an explicit `python-multipart` pin there too. |
||
|
Jordan Ritter
|
105a5a9d65 |
fix(showcase): aimock-wiring probe now covers the harness fleet (harness/harness-workers)
The aimock-wiring drift probe excluded `harness` and `harness-workers`, so when their aimock pointers drifted to the billed PUBLIC `*.up.railway.app` host instead of `showcase-aimock.railway.internal:4010` the probe never flagged it (~$657/mo egress on staging). Un-exclude the harness fleet and verify it as aimock consumers via a new AIMOCK_CONSUMER_SERVICES set. Consumers use HARNESS_FLEET_CANDIDATE_ENV_VARS (the standard OPENAI/ANTHROPIC/GEMINI candidates plus AIMOCK_URL), because `harness` exposes ONLY AIMOCK_URL as its aimock pointer. AIMOCK_URL is scoped to the harness-fleet path only, so a regular backend's stray AIMOCK_URL can't mask a missing real base-URL pointer. Pure-infra services (aimock/shell/ dashboard/docs/dojo/pocketbase/webhooks) stay excluded. |
||
|
Ben Taylor
|
0035a7e387 |
docs(mastra): clarify that interrupts are not supported, redirect to tool-based HITL (#5895)
## Summary Fixes FAC-64: Mastra Interrupts docs example fails on missing agentId and suspendPayload guard This PR rewrites the Mastra interrupt documentation to correctly reflect that **Mastra does not support native interrupt flow**. The framework lacks LangGraph-style `interrupt()` primitives and does not emit AG-UI interrupt events. ## Changes ### 📝 Documentation Updates 1. **`interrupt-flow.mdx`**: Completely rewritten to: - Add prominent warning callout that Mastra doesn't support interrupts - Explain why the interrupt pattern doesn't work with Mastra - Provide working alternative using `useHumanInTheLoop` - Include comparison table between interrupt-based and tool-based approaches - Redirect users to the tool-based HITL guide 2. **`index.mdx`**: Updated to: - Mark interrupt-based approach as "Not Supported" - Mark tool-based approach as "Supported" (the working pattern) - Reorder cards to prioritize the working approach ## Rationale The original docs documented `useInterrupt` with examples that would: - Fail with "Agent 'default' not found" (missing `agentId` parameter) - Fail with "Cannot destructure property 'action'" (incorrect payload access) - Silently fail (hook listens for events Mastra never emits) Research revealed: - `showcase/integrations/mastra/manifest.yaml` explicitly lists `gen-ui-interrupt` under `not_supported_features` - The actual working demo uses `useHumanInTheLoop`, not `useInterrupt` - Comments in the code confirm: "This framework has no LangGraph-style `interrupt()` primitive" ## Migration Path Users following the old docs can now: 1. See clear warning that interrupts aren't supported 2. Learn the correct `useHumanInTheLoop` pattern 3. Follow link to complete tool-based HITL guide with working examples ## Testing - ✅ Documentation changes only (no runtime code affected) - ✅ Verified redirect links work correctly - ✅ Checked against actual working implementation in `showcase/integrations/mastra/src/app/demos/gen-ui-interrupt/page.tsx` ## Related - Linear: FAC-64 - QA Report: Documented three specific runtime errors from the broken examples - Research: Identified Option B (rewrite for useHumanInTheLoop) as the correct approach |
||
|
Jordan Ritter
|
18a279867a |
fix(starters): add python-multipart to agno starter (fixes startup crash)
The agno starter's Dockerfile installs Python deps via 'uv pip install --system -e .', resolving from pyproject.toml (not uv.lock). agno>=1.7.8 now resolves to 2.7.4, which dropped python-multipart as a hard dependency. AgentOS registers a FastAPI form-data route, so the app raised 'RuntimeError: Form data requires python-multipart' at import time, crash-looping starter-agno. Pin python-multipart>=0.0.20 directly so it installs regardless of agno's transitive deps. |
||
|
Benjamin Taylor
|
f51afb672f |
chore: remove changeset file (repo does not use changesets)
The .changeset/ tooling is not used by this repo; dead debris was removed
from main in
|
||
|
Jordan Ritter
|
ca67cd013f |
fix(showcase): aimock-wiring probe now covers starter-* services (#6048)
## What this fixes
The aimock-wiring probe (`showcase/harness/src/probes/aimock-wiring.ts`)
has an `isExcluded()` helper that short-circuited every `starter-*`
service out of the checked universe:
```ts
if (name.startsWith("starter-")) return true;
```
The comment justified it by claiming starters are "categorically NOT
wired through aimock (per product decision)." That comment is stale and
wrong. All 12 `starter-*` services route `OPENAI_BASE_URL` /
`ANTHROPIC_BASE_URL` / `GOOGLE_GEMINI_BASE_URL` / `AIMOCK_URL` through
aimock exactly like the `showcase-*` backends. So the probe was silently
skipping wiring verification for a third of the roster.
This PR removes the `starter-` prefix skip so the probe checks starters
like any other LLM-calling service, and corrects the two stale comments
(the `isExcluded` body and the `EXCLUDE_SERVICES` NOTE block). The
`EXCLUDE_SERVICES` set itself is untouched — it lists only pure infra
(aimock/shell/dashboard/docs/dojo/pocketbase/harness/harness-workers/webhooks),
and starters were never in it.
## Why now / ordering
We're flipping the 12 starters' live base-URL vars from aimock's public
URL to its internal URL (a companion live-ops change, not in this PR).
Once that flip lands, the probe should be watching those services. This
PR makes it do so.
**This must land AFTER the live starter vars are flipped to the internal
URL.** If it merges first, the probe will immediately flag the 12
starters as drifted against their pre-existing public-URL values (a real
mismatch until the flip happens). Sequence: flip vars → merge this.
## The probe is read-only
Including 12 more services adds only read-only Railway variable reads.
The verification path is pure string comparison:
- `aimockWiringProbe.run` calls `listServices()` then, per service,
`getServiceEnv(name)` (a Railway GraphQL `variables(...)` query).
- `pointsAtAimock` compares the parsed hostname of each candidate env
var (`CANDIDATE_ENV_VARS`) against the aimock URL's hostname.
- No HTTP request is made to the service itself; no LLM traffic is
generated. Adding starters just means 12 more variable lookups.
## Red → Green proof
Ran the probe's unit tests
(`showcase/harness/src/probes/aimock-wiring.test.ts`), which exercise
the real `isExcluded` logic through the exported `aimockWiringProbe.run`
surface. Added one focused test and updated three that asserted the old
(wrong) starters-excluded behavior.
**RED** — with the `starter-` short-circuit still in place, the tests
asserting starters are checked fail:
```
$ npx vitest run src/probes/aimock-wiring.test.ts
FAIL ... > checks starters like any LLM backend (NOT excluded); infra stays excluded
FAIL ... > excludes harness-workers (infra) but checks bare starter-* services
FAIL ... > checks starters alongside showcase-* backends (both in the checked universe)
FAIL ... > full live roster: the 20 showcase-* backends AND 12 starters are checked, 9 infra excluded
Test Files 1 failed (1)
Tests 4 failed | 29 passed (33)
```
Example assertion diff (roster test): expected 32 unwired (20 backends +
12 starters), received only 19 — the 12 `starter-*` entries were being
excluded.
**GREEN** — after removing the short-circuit, the same test file passes:
```
$ npx vitest run src/probes/aimock-wiring.test.ts
Test Files 1 passed (1)
Tests 33 passed (33)
```
## Follow-up: probe-correctness fixes (c1 / c2 / c5)
Now that the probe covers all 32 services (20 `showcase-*` + 12
`starter-*`), a cr-loop audit surfaced two coupled correctness holes
that let real drift go undetected, plus a stale comment. All three are
in `aimock-wiring.ts` / `aimock-wiring.test.ts`.
- **c1 — confirmed mismatch beats sealed.** Old `pointsAtAimock`
returned `sealed` whenever any candidate was the sealed sentinel and
none was a confirmed match — even if a *sibling* candidate was set to a
confirmed non-aimock host (e.g. real `api.openai.com`). That masked
provable drift. The precedence is now explicit: **match >
mismatch(confirmed) > sealed > mismatch(all-missing)**. A candidate that
is set, non-sentinel, non-empty and does not match the aimock target is
confirmed drift and wins over a sealed sibling. Purely-sealed (no
confirmed match/mismatch) still → `sealed`; all-missing still →
`mismatch`.
- **c2 — host + port matching (was host-only).** Internal aimock serves
**only on `:4010`**, so a service on the right host but the
wrong/missing port is drift, not "wired". Matching now compares host
**and** effective port. Default ports collapse (`http://h` ≡
`http://h:80`, `https://h` ≡ `https://h:443`) via the protocol default
on both sides. The expected port is **derived from the configured
`aimockUrl`** (no port hardcoded) — see `extractHostPort`.
- **c5 — comment fix (no logic change).** The
`isExcluded`/`EXCLUDE_SERVICES` doc block said the matcher "strips" a
leading `showcase-`; it actually **prepends** `showcase-` to the bare
name and tests that form. Corrected to describe the prepend.
### Blast-radius check (host+port change hits all 32 live services)
Confirmed the probe's expected `aimockUrl` carries `:4010` before making
matching port-aware. The live cron reads it from `env.AIMOCK_URL`
(`orchestrator.ts` `buildCronProbeResolver` /
`probes/drivers/aimock-wiring.ts`). Live production value: `AIMOCK_URL =
http://showcase-aimock.railway.internal:4010` — carries `:4010`,
matching the 32 services' `:4010` base URLs. Port-aware matching
therefore keeps prod green.
Note (out of scope): the **staging** harness `AIMOCK_URL` is still the
public host `https://aimock-staging.up.railway.app`, while staging
services point at the internal `:4010` host. That is already a hostname
mismatch under the *current* (host-only) code, so staging is unaffected
by this change — but it is a live staging config drift worth flipping to
the internal host separately.
### Red → Green proof (c1 / c2)
New/adjusted tests exercise the real `pointsAtAimock` through
`aimockWiringProbe.run`.
**RED** — against the pre-fix (host-only, sealed-wins) code:
```
$ npx vitest run src/probes/aimock-wiring.test.ts -t "c2 wrong-port|c2 missing-port|c1 confirmed-mismatch"
FAIL ... > c2 wrong-port: correct aimock host but a DIFFERENT port ... expected 'green' to be 'red'
FAIL ... > c2 missing-port: correct aimock host but NO port (:80) ... expected 'green' to be 'red'
FAIL ... > c1 confirmed-mismatch beats sealed ... expected 'green' to be 'red'
Tests 3 failed | 1 passed | 34 skipped (38)
```
**GREEN** — after the c1/c2 fixes, the same tests (plus correct-port,
purely-sealed, and the strengthened default-port collapse test) pass,
and the full file is green:
```
$ npx vitest run src/probes/aimock-wiring.test.ts
Test Files 1 passed (1)
Tests 38 passed (38)
```
### LIVE value-test (shared-mechanism change)
Dumped all 32 non-infra services' base-URL vars from **live production**
Railway (read-only `railway variables --json`), then ran the real
`aimockWiringProbe.run` with the new code and the production `aimockUrl`
(`http://showcase-aimock.railway.internal:4010`):
```
state: green
RESULT: 32/32 wired (unwired: 0, sealed: 0, errored: 0)
```
No false reds — the port-aware + mismatch-beats-sealed verdict
classifies every live production service as wired.
## Local quality (CI-relevant, this path)
- `npm run typecheck` (tsc --noEmit) — clean, exit 0
- `npm run build` (tsc -p tsconfig.build.json) — clean, exit 0
- `oxlint` / `oxfmt --check` on both changed files — clean
- `npm test` (full harness vitest) — **3308 passed**, 18 skipped. Two
pre-existing failures unrelated to this change, both reproducible on
`origin/main` (neither references aimock-wiring; a transient timing-only
flake in `probe-invoker.test.ts` under full-suite parallel load passes
67/67 in isolation):
- `d0-gone-predicate.test.ts` — reads the gitignored generated
`showcase/shell/src/data/registry.json`, which isn't present in a fresh
worktree (needs the shell generate step; present in CI/dev).
- `d5-mapping-drift.test.ts` — parses
`shell-dashboard/src/lib/live-status.ts` for `CATALOG_TO_D5_KEY`, but
that file is now a re-export barrel (the symbol moved to
`harness/src/shared/cell-model/live-status.ts`); the test's hardcoded
path is stale on `origin/main`. Not touched by this PR.
Neither failing file is related to the aimock-wiring probe.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01QCLub2Vb5Y56cPttSzkip1
|
||
|
Jordan Ritter
|
88138aefe0 | docs(showcase): clarify aimock-wiring unwired bucket and extractHostPort null-return comments | ||
|
Jordan Ritter
|
a9c11f4627 |
test(showcase): lock aimock-wiring host+port precedence, refresh stale comments
Non-behavioral cleanup + coverage pass for the aimock-wiring probe: - Correct comments that still described the old hostname-only matching or referenced removed helpers (normalizeUrl / extractHostname) to reflect the current host+port matching via extractHostPort, in both the probe and its test. - Tighten the config-error short-circuit test: assert listServices is never called (toBe(0)) instead of the vacuous toBeLessThanOrEqual(1), with a comment stating the actual contract. - Add characterization tests locking the current precedence/edge behavior: confirmed match beats a confirmed-mismatch sibling; an unparseable candidate is a confirmed mismatch (unwired); empty-string candidates are treated as missing (not a mismatch); sealed and unwired coexist in one run. No runtime behavior changes. |
||
|
Jordan Ritter
|
b2602cac04 |
fix(showcase): port-aware + confirmed-mismatch-beats-sealed in aimock-wiring probe
Coupled correctness fixes so real starter/backend drift can't hide now that the probe covers all 32 services (20 showcase-* + 12 starter-*): - c1: a CONFIRMED mismatch (a candidate set to a non-aimock host) now wins over a sealed sibling. Previously a var pointing at real api.openai.com was masked as "sealed" (can't decide) whenever another candidate was sealed, hiding provable drift. Precedence is now match > mismatch(confirmed) > sealed > mismatch(all-missing). - c2: matching compares host AND effective port, not host alone. Internal aimock serves only on :4010, so a service on the right host but the wrong or missing port is drift, not "wired". Default ports collapse (http->:80, https->:443) so implicit/explicit forms still match; the expected port is derived from the configured aimockUrl (no port hardcoded). - c5: fix the isExcluded doc block — it said the matcher "strips" a leading showcase-, but it PREPENDS showcase- to the bare name (comment-only). Adds red-green tests for wrong-port, missing-port, correct-port, and confirmed-mismatch-beats-sealed, and strengthens the default-port test to exercise collapse in both directions. |
||
|
Jordan Ritter
|
167ae3ad1b |
fix(showcase): aimock-wiring probe now covers starter-* services
The isExcluded() helper short-circuited every starter-* service out of the probe on the (stale) rationale that starters are not wired through aimock. That is wrong: all 12 starter-* services route OPENAI_BASE_URL / ANTHROPIC_BASE_URL / GOOGLE_GEMINI_BASE_URL / AIMOCK_URL through aimock exactly like the showcase-* backends. Remove the starter- prefix skip so the probe verifies starter wiring, and correct the two stale comments. Infra services in EXCLUDE_SERVICES are untouched. |
||
|
Jordan Ritter
|
090c080581 |
fix(showcase): langroid declarative gen-ui → two-stage A2UI north-star (D6 turn-1 surface-missing) (#6058)
## What Brings the **langroid** `declarative-gen-ui` D6 cell to sibling parity with the two-stage dynamic-schema A2UI north-star (google-adk / strands). The cell was red at turn 1 with `reason=surface-missing`: the demo was still on the pre-D6 (D5-era) shape, and four independent defects each blocked the A2UI surface from painting. Second-wave fan-out of the proven pattern (pilots #6051/#6052/#6053, first wave #6054 agno / #6055 claude-sdk-typescript). ## Root cause (four defects, each verified against a live isolated stack) 1. **Stale suggestions + fixtures.** `suggestions.ts` still offered the old D5 pills; the aimock fixture only mocked those. The D6 driver sends the four current business-question prompts. Re-authored both to the four current prompts mirroring the google-adk north-star (outer `generate_a2ui` no-arg → inner forced `render_a2ui` → outer narration). 2. **Required `context` on the outer tool.** `GenerateA2UITool.context` was a required pydantic field, so the mocked outer `arguments: {}` raised `ValidationError` before the tool ran → no inner call, no surface. Made optional (default `""`) to match the no-arg sibling tools. 3. **Legacy functions API hid the inner tool from aimock's matcher.** The inner planner used langroid's `functions=`/`function_call=` (legacy OpenAI) path; aimock's `toolName` matcher only inspects the modern `tools[]` array, so the inner `render_a2ui` fixture never matched and the call fell through to the outer `generate_a2ui` fixture (empty surface, wrong catalogId). Switched the inner call to the modern `tools=`/`tool_choice=` API. The response extractor already reads the modern `oai_tool_calls` path first, so nothing downstream changes. 4. **Inner call could not be discriminated per pill.** langroid has no framework middleware to forward the run's conversation into the inner call (unlike `ag_ui_adk` / `ag_ui_strands`), so its inner user message was a fixed generic string across all four pills. Added an explicit last-user-turn thread (a `ContextVar` set by the adapter, consumed by the planner) so the pill prompt rides as the inner `userMessage` — the discriminator the sibling fixtures rely on. **Renderer/catalog parity:** added the missing `declarative-info-row` testid on InfoRow (turn 4) and a full `DataTable` definition + renderer (`declarative-data-table`, turn 2), plus `trendValue` on Metric. Added `sales-context.ts` (byte-identical dataset + composition rules to the strands/google-adk siblings) and wired it via `chat.tsx`. Backend family mirrored: **google-adk / strands** — outer `generate_a2ui` (no args) + inner forced `render_a2ui`, `declarative-gen-ui-catalog`. ## Red-green proof (isolated control-plane, `--isolate --rebuild`, slot 16) **RED (pre-fix, 3 runs):** ``` ✗ d6:langroid/gen-ui-declarative red — state=red waitForTurnComplete: turn 1 did not complete within 90000ms (reason=surface-missing) ``` First diagnosis (direct backend SSE): outer `generate_a2ui` → `{"error": "Tool generate_a2ui failed: ValidationError"}`. After fixing that: outer succeeded but emitted `catalogId: copilotkit://app-dashboard-catalog` with `components: []` (inner never matched — legacy functions API). After the tools-API + threading fix: **GREEN (post-fix, 2 runs):** ``` ✓ d6:langroid/gen-ui-declarative green 1 passed ``` aimock journal confirms all four pills' outer `generate_a2ui` + inner `render_a2ui` (tool_choice forced) calls return **200** and emit `declarative-gen-ui-catalog` surfaces. Per-turn backend SSE verified: - turn 1 (sales-dashboard): 4 × Metric + PieChart + BarChart - turn 2 (team-performance): DataTable + BarChart - turn 4 (top-account): 7 × InfoRow + PieChart ## Visual `langroid-turn1-sales-dashboard.png` — live Playwright render (X-AIMock-Context: langroid): 4 metric tiles + revenue-by-region pie + monthly-revenue bar. Turns 2–4 surface renders are asserted and pass in the authoritative D6 run (conjunctive per-turn testid checks) and confirmed via backend SSE above. ## Notes - Draft: not for merge/promote (user-gated). - A concurrent `ms-agent-harness-dotnet` fan-out agent was hitting the shared local aimock during manual browser capture (interleaved 404s in the journal); it does not affect the isolated D6 result, which is the binding proof. --- **CI-driven follow-ups (in this same commit):** - Updated `integrations/langroid/tests/python/test_generate_a2ui.py` to assert the modern `tools=`/`tool_choice=` kwargs (was pinning the legacy `functions=`/`function_call=` API this fix intentionally replaced). 78 passed / 1 skipped locally. - Scoped the four inner `render_a2ui` fixtures to `context: langroid` (langroid forwards `x-aimock-context` to the inner planner call, unlike `ag_ui_adk`/`ag_ui_strands`) so they don't collide in the shared scope with the sibling integrations' identical inner keys — keeps the `aimock-fixtures` exact-duplicate ceiling at 297 (no bump). Full `aimock-fixtures.test.ts` suite: 837 passed. D6 re-run after this change: still green 4/4. |
||
|
Jordan Ritter
|
04aefd9dcd |
fix(showcase): repair ms-agent-dotnet D6 gen-ui-declarative (surface-missing) (#6057)
## Summary
The D6 e2e-full probe `d6:ms-agent-dotnet/gen-ui-declarative` was
failing at turn 1 with `reason=surface-missing`. Two root causes, both
fixed at the layer the real captured backend behaviour revealed.
### Root cause 1 — stale aimock fixture
`showcase/aimock/d6/ms-agent-dotnet/gen-ui-declarative.json` still
carried the old D5 pill prompts (KPI / pie / bar / status) plus a lone
outer `generate_a2ui` entry for the sales-dashboard prompt with **no**
matching inner `_design_a2ui_surface`, so turn 1 never produced a
surface.
Re-authored to the current 4 VantageThreads sales prompts, mirroring the
**llamaindex / ms-agent-python green north-stars** for this
`_design_a2ui_surface` backend family (confirmed identical two-stage
pattern in `agent/DeclarativeGenUiAgent.cs` +
`agent/A2uiSecondaryToolCaller.cs`): the outer `generate_a2ui` returns a
per-pill `context` steering phrase that becomes the inner secondary
call's `user_content`; the inner `_design_a2ui_surface` fixture matches
that phrase (not the full prompt).
**ms-agent-dotnet–specific discriminator.** Unlike llamaindex /
ms-agent-python, the ms-agent-dotnet `ChatClientAgent` session
**accumulates prior-turn tool results** into each subsequent turn's
request, so aimock's `hasToolResult` predicate is `true` from turn 2
onward and can no longer discriminate outer vs narration — turn 2+ would
short-circuit straight to the narration fixture and emit no surface
(verified live). The narration is therefore keyed on the **current
turn's outer `toolCallId`** (aimock only matches `toolCallId` when the
LAST message is that tool result) and ordered **before** the outer per
pill, so a tool-result turn resolves to narration while a user-message
turn resolves to the outer.
### Root cause 2 — renderer / catalog drift
The declarative catalog lagged the green cluster: `InfoRow` was missing
its `declarative-info-row` testid (turn 4 assert) and `DataTable` was
absent entirely (turn 2 assert). Added the testid and the `DataTable`
renderer + definition, matching the green cluster.
## Red → Green proof (real control-plane surface)
`./bin/showcase test ms-agent-dotnet:declarative-gen-ui --d6 --isolate
--rebuild`
| | result |
|---|---|
| **RED** (pristine stale fixture + missing DataTable/info-row testid) |
`d6:ms-agent-dotnet/gen-ui-declarative = red` — exit 1, turn 1
`surface-missing`, `0 passed, 1 failed` |
| **GREEN** (fix applied) | `d6:ms-agent-dotnet/gen-ui-declarative =
green` — exit 0, `1 passed` |
An intermediate rebuild flipped turn 1 green but exposed the turn-2
`surface-missing` (accumulated-history bug); the `toolCallId` narration
re-keying fixed all four turns.
## Visual verification
Drove all 4 turns via Playwright (header-injected `X-AIMock-Context:
ms-agent-dotnet` + `X-AIMock-Strict: true` to replicate the harness
proxy). Confirmed real painted surfaces:
- **turn 1 sales-dashboard**: 4 KPI metrics ($4.2M revenue, 186
customers, 31% win rate, $22.6k deal) + Revenue-by-Region pie +
Monthly-Revenue bar
- **turn 2 team-performance**: rep-quota `DataTable` (Dana Whitfield
124% … Elena Vasquez 71%) + attainment `BarChart`
- **turn 3 at-risk**: 3 `StatusBadge` severity cards + KPI metric strip
- **turn 4 top-account**: 7 `InfoRow` account facts (Meridian Apparel
Group) + product-line `PieChart`
Screenshots under
`~/.local/share/copilotkit/cr/2ndwave-shots/msdotnet-turn{1..4}-full.png`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
||
|
Jordan Ritter
|
92d0fab67e |
fix(showcase): repair ms-agent-harness-dotnet D6 gen-ui-declarative (surface-missing) (#6056)
## Summary The D6 e2e-full probe `d6:ms-agent-harness-dotnet/gen-ui-declarative` was failing at turn 1 with `reason=surface-missing`. Three layers, each fixed at the layer the real captured request revealed. Part of the second-wave declarative fan-out (siblings #6051–#6055 / #6053 ms-agent-python). ### Root cause 1 — stale aimock fixture `showcase/aimock/d6/ms-agent-harness-dotnet/gen-ui-declarative.json` still carried the old D5 pill set (KPI / pie / bar / status prompts) with inner `_design_a2ui_surface` entries keyed on those stale prompts. The current driver sends four VantageThreads sales prompts, so turn 1 ("Show me my sales dashboard for this quarter.") had **no matching inner surface** — the backend looped `generate_a2ui` to its invocation limit and the frontend painted the stale KPI catch-all instead of the sales dashboard. Re-authored to the four current prompts, mirroring the **llamaindex green north-star** for this `_design_a2ui_surface` two-stage backend family (ms-agent-harness-dotnet's inner tool is `_design_a2ui_surface`, per `agent/DeclarativeGenUiAgent.cs` + `agent/A2uiSecondaryToolCaller.cs`). ### Root cause 2 — `hasToolResult` breaks the interleaved thread This is where the dotnet family diverges from the #6053 ms-agent-python template. ms-agent-python starts a fresh session per turn; the **.NET harness backend threads the FULL interleaved conversation**. `hasToolResult` is a thread-global predicate (see `showcase/GOTCHAS.md`), so once turn 1 leaves a `role:"tool"` message in the thread, every later pill's outer `generate_a2ui` call sees `hasToolResult:true` and matches the **narration** fixture instead of emitting the tool call → surface-missing on turns 2–4. (Reproduced live: turn 2's outer call, replayed with turn-1 history, returned the narration string instead of `generate_a2ui`.) Switched to the sanctioned interleaved-safe pattern: **narration keyed on this pill's outer `toolCallId`** (ordered before the outer), **outer keyed on `userMessage` only**. Verified all four pills resolve correctly through the full interleaved thread against live aimock. ### Root cause 3 — renderer / catalog drift `renderers.tsx` and `definitions.ts` lagged the green cluster — missing the `DataTable` and `InfoRow` components (the `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 to parity with the langgraph-python / llamaindex green cluster. ## Red → Green proof (real control-plane surface) `SHOWCASE_ISO_SLOT=18 ./bin/showcase test ms-agent-harness-dotnet:declarative-gen-ui --d6 --isolate --rebuild` | | result | |---|---| | **RED** (pristine stale fixture + drifted renderers) | `state=red`, exit 1 — turn 1 `waitForTurnComplete: turn 1 did not complete within 90000ms (reason=surface-missing, runsFinished=1, count=41)`; body showed the stale "Quarterly KPIs / $1.24M / SIGNUPS 8,420" surface + `generate_a2ui` looping | | **GREEN** (fix applied) | `state=green`, exit 0 — `1 passed` | ## Visual verification Drove all 4 turns via Playwright with network-level route injection of `x-aimock-context: ms-agent-harness-dotnet` (replicating the harness/production proxy). Confirmed real painted surfaces: - **turn 1 sales-dashboard**: 4 KPI metrics ($4.2M revenue, 186 customers, 31% win rate, $22.6k deal) + Revenue-by-Region donut + Monthly-Revenue bar - **turn 2 rep-quota**: rep-attainment `DataTable` (Dana Whitfield 124% … Elena Vasquez 71%) + quota-attainment `BarChart` - **turn 3 at-risk**: 3 severity `StatusBadge` cards (Northwind / Cascadia / Atlas) + KPI metric strip - **turn 4 top-account**: 7 `InfoRow` account facts (Meridian Apparel Group) + product-line `PieChart` Screenshots under `~/.local/share/copilotkit/cr/2ndwave-shots/msharness-turn{1..4}-*.png`. |
||
|
Jordan Ritter
|
c13415f743 |
fix(showcase): repair claude-sdk-typescript D6 gen-ui-declarative (surface-missing) (#6055)
## What Repairs the `claude-sdk-typescript` D6 `gen-ui-declarative` cell, which was **red on turn-1 surface-missing**. The aimock fixture carried stale D5-era prompts and only a partial turn-1 outer entry, so the two-stage Anthropic A2UI flow (outer `generate_a2ui` → secondary `render_a2ui` → narration) never painted a surface for the four current sales-analyst pills. Fan-out of the proven pattern from the pilots (#6051 claude-sdk-python, #6052 mastra, #6053 ms-agent-python). This is the Anthropic two-stage family — `injectA2UITool: false`, backend owns `generate_a2ui` + secondary `render_a2ui`. ## Root cause `aimock/d6/claude-sdk-typescript/gen-ui-declarative.json` had the old D5 prompts (`Show me a quick KPI dashboard` / `pie chart of sales by region` / `bar chart of quarterly revenue` / `status report on system health`) plus one lone turn-1 outer entry for the new sales prompt. The driver's four current prompts had no complete triads, so aimock returned `STRICT: No fixture matched` and no surface mounted. ## Fix (3 layers) 1. **Fixture re-author** — 12 fixtures (4 pills × {outer `generate_a2ui`, inner `render_a2ui`, narration}) in the two-stage shape, mirroring the #6051 sibling + google-adk data. Render payloads mount the per-pill catalog components the driver asserts: Metric×4 + Pie + Bar (sales-dashboard); DataTable + Bar (team-performance); Metric×3 + StatusBadge×3 (at-risk); InfoRow + Pie (top-account). Render payloads are byte-identical to #6051. **Ordering/matcher fix vs a naive python mirror:** the CSTS runtime accumulates full conversation history across pills, so on turns 2-4 the outer `generate_a2ui` call carries prior pills' tool results and a `hasToolResult:false` matcher never fires. Each pill triad is ordered **narration (`toolCallId`) first** so it claims the last-role:tool calls, and the outer matcher drops `hasToolResult` and gates on `userMessage` + `toolName generate_a2ui` (last-role:user). Verified live via the aimock journal. 2. **InfoRow testid** — add `data-testid="declarative-info-row"` to the InfoRow renderer (turn-4 top-account parity; CSTS was missed by #6050). 3. **Suggestions refresh** — `suggestions.ts` had stale D5-era pill labels that emitted unmatched prompts (live 404 banner). Now the four sales-analyst pills, matching google-adk. ## Red → green proof (control-plane, slot 30, `--isolate --rebuild`) **RED (origin/main):** ``` ✗ d6:claude-sdk-typescript/gen-ui-declarative red — state=red [aimock] STRICT: No fixture matched for POST /v1/messages (×6) ``` **GREEN (fixed):** ``` ✓ d6:claude-sdk-typescript/gen-ui-declarative green — 1 passed ``` aimock journal after the green run: **all 12 calls returned 200, zero 503, zero no-match** across all 4 turns. ## Visual proof (Playwright, `x-aimock-context: claude-sdk-typescript`) Drove all 4 pills live; per-turn DOM testid counts (no fixture error on any turn): | Turn | Pill | Newly-mounted testids | |---|---|---| | 1 | sales-dashboard | metric=4, pie=1, bar=1 | | 2 | team-performance | data-table=1, bar +1 (→2) | | 3 | at-risk | status-badge=3, metric +3 (→7) | | 4 | top-account | **info-row=7**, pie +1 (→2) | Screenshots: `~/.local/share/copilotkit/cr/2ndwave-shots/csts-turn{1..4}-*.png`. ## Unit tests - `scripts/__tests__/aimock-fixtures.test.ts`: 837 passed (validates the new fixture shape). - `harness/src/probes/scripts/d5-gen-ui-declarative.test.ts`: 31 passed. ## Notes - Worktree tsc module-not-found / TS2322-ButtonProps noise is benign symlink noise; trust the PR's real `check-types` CI check. - Local red-green ran on slot 30 (slot 8 and several low slots were held by concurrent isolate stacks). |
||
|
Jordan Ritter
|
29ed44d913 |
fix(showcase): flip agno gen-ui-declarative D6 cell green (4-turn sales flow + DataTable/InfoRow parity) (#6054)
## What Flips the `d6:agno/gen-ui-declarative` cell from **red (turn-1 dom-missing) → green**. Fan-out of the proven 2nd-wave declarative fix pattern (pilots #6051 claude-sdk-python, #6052 mastra, #6053 ms-agent-python). ## Root cause (verified at the request level) agno's declarative-gen-ui shipped a **stale D5 aimock fixture** keyed on the old prompts (KPI dashboard / pie chart of sales by region / bar chart / status report), while the current D6 driver sends the OSS-136 sales prompts. Captured from the aimock journal on a RED run: agno's OUTER agent hit aimock with `tools=[generate_a2ui]`, `userMessage="Show me my sales dashboard for this quarter."`, `x-aimock-strict:true`, `context=agno` — the stale fixture matched **none**, aimock returned 503 (strict), the outer agent never emitted `generate_a2ui`, no surface rendered → turn-1 dom-missing → `state=red`. ## Backend family + north-star agno uses the plain **`render_a2ui` two-stage** family (`src/agents/a2ui_dynamic_agent.py`): an OUTER `generate_a2ui(context: str)` tool, then a forced-`render_a2ui` secondary call, then narration. Mirrored the **google-adk** green north-star (same VantageThreads surfaces + `declarative-gen-ui-catalog`; `render_a2ui` args copied verbatim). Key agno-specific wrinkle: the inner secondary call's **user message is hardcoded and identical across all four pills** ("Generate a dynamic A2UI dashboard based on the conversation."), so the inner `render_a2ui` fixtures cannot key on `userMessage`. They discriminate on `toolName:render_a2ui` + `context:agno` + a `systemMessage` substring equal to the per-pill context phrase the outer injects ("Conversation context:\n<context>"). aimock's CLI server uses substring matching, so this works; verified live against the journal. ## Fix layers - **Fixture** (`aimock/d6/agno/gen-ui-declarative.json`): 4 sales prompts × 3 calls (outer/inner/narration) = 12 fixtures. - **Renderers** (`.../a2ui/renderers.tsx`): `declarative-info-row` testid on InfoRow (turn 4) + new `DataTable` renderer with `declarative-data-table` testid (turn 2), mirroring google-adk. - **Definitions** (`.../a2ui/definitions.ts`): `DataTable` schema, `Metric.trendValue`, `z.unknown()` PrimaryButton action, refreshed descriptions. - **Backend** (`a2ui_dynamic_agent.py`): sales-analyst system prompt for live-mode steering. - **Test** (`scripts/__tests__/aimock-fixtures.test.ts`): `KNOWN_DUPLICATE_CEILING` 297→300 (+3) — the 4 inner render fixtures collapse to one `toolName=render_a2ui` matchKey (matchKey omits systemMessage/context) but aimock's router disambiguates them at runtime. ### Bug caught during green First green attempt still red with a client-side exception: adding `Row`/`Column`/`Text` to `myDefinitions` **without matching renderers** (agno relies on `includeBasicCatalog:true` for those) made `createCatalog` produce a definition set wider than its renderer set → render crash. Fixed by not declaring Row/Column/Text in definitions. ## Local RED → GREEN proof (isolated D6 slots) **RED** (control-plane, stale fixture): ``` ✗ d6:agno/gen-ui-declarative red — state=red ``` **GREEN** (control-plane, after fix): ``` ✓ d6:agno/gen-ui-declarative green 1 passed ``` **GREEN** (`--direct`, per-turn DOM assertions — authoritative): ``` turn 1/4 — assertions passed (sales-dashboard: metric×4 + pie + bar) turn 2/4 — assertions passed (team-performance: data-table + bar) turn 3/4 — assertions passed (at-risk: status-badge×3 + metric×3) turn 4/4 — assertions passed (top-account: info-row + pie) state=green, 1 passed ``` GREEN aimock journal: 12 requests = 4× OUTER `generate_a2ui` + 4× INNER `render_a2ui` + 4× narration, all matched. **Live Playwright visual** (all 4 surfaces painted, testids counted): turn1 metric×4/pie/bar, turn2 data-table×1/bar, turn3 status-badge×3/metric, turn4 info-row×7/pie. `aimock-fixtures.test.ts`: 837 passed after the ceiling bump. |
||
|
Jordan Ritter
|
3d8eff5e70 |
fix(showcase): repair ms-agent-python D6 gen-ui-declarative (surface-missing) (#6053)
## Summary
The D6 e2e-full probe `d6:ms-agent-python/gen-ui-declarative` was
failing at turn 1 with `reason=surface-missing`. Two independent root
causes, both fixed at the layer the real captured request revealed.
### Root cause 1 — stale aimock fixture
`showcase/aimock/d6/ms-agent-python/gen-ui-declarative.json` 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` and **no** narration. The
backend looped `generate_a2ui` to its invocation limit and
`RUN_FINISHED` was blocked while the tool call stayed active (`Cannot
send 'RUN_FINISHED' while tool calls are still active`).
Re-authored to the current 4 VantageThreads sales prompts, mirroring the
**llamaindex green north-star** for this backend shape
(ms-agent-python's inner tool is `_design_a2ui_surface`, not
google-adk's `render_a2ui`):
- outer `generate_a2ui` returns a `context` steering phrase — the
ms-agent-framework session does not surface the latest user message to
the secondary LLM, so the phrase becomes the inner call's
`user_content`;
- the inner `_design_a2ui_surface` fixture matches that phrase (not the
full prompt);
- `hasToolResult` discriminates outer (false) vs narration (true).
This also eliminates the stale `render-a2ui.json` "KPI dashboard"
catch-all collision that was rendering the wrong (KPI) surface for the
sales prompt.
### Root cause 2 — renderer / catalog drift
`renderers.tsx` and `definitions.ts` for ms-agent-python's
declarative-gen-ui lagged the green cluster — missing the `DataTable`
and `InfoRow` components (the `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 (real control-plane surface)
`SHOWCASE_ISO_SLOT=11 ./bin/showcase test
ms-agent-python:declarative-gen-ui --d6 --isolate`
| | result |
|---|---|
| **RED** (pristine fixture + stale renderers) |
`d6:ms-agent-python/gen-ui-declarative = red` — exit 1, turn 1
`surface-missing` |
| **GREEN** (fix applied) | `d6:ms-agent-python/gen-ui-declarative =
green` — exit 0, `1 passed` |
## Visual verification
Drove all 4 turns via Playwright (header-injected `x-aimock-context:
ms-agent-python` to replicate the harness/production proxy). Confirmed
real painted surfaces:
- **turn 1 sales-dashboard**: 4 KPI metrics ($4.2M revenue, 186
customers, 31% win rate, $22.6k deal) + Revenue-by-Region pie +
Monthly-Revenue bar
- **turn 2 team-performance**: rep-quota `DataTable` + attainment
`BarChart`
- **turn 3 at-risk**: 3 `StatusBadge` severity cards + KPI metric strip
- **turn 4 top-account**: 7 `InfoRow` account facts + product-line
`PieChart`
Screenshots captured under
`~/.local/share/copilotkit/cr/2ndwave-shots/mspy-turn{1..4}-*.png`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
||
|
Jordan Ritter
|
c01bde3759 |
fix(showcase): flip mastra gen-ui-declarative D6 cell green (#6052)
## What
Flips the `d6:mastra/gen-ui-declarative` showcase cell from **red** to
**green**.
The cell failed turn 1 with `reason=surface-missing` (the dom-missing
family). Reading the real failure surface (aimock logs + mastra
container logs + harness worker logs) exposed **three** distinct
defects, each fixed at its own layer.
## Root cause (empirically confirmed)
1. **Stale aimock fixture.** `aimock/d6/mastra/gen-ui-declarative.json`
carried the OLD D5 pill prompts (`"Show me a quick KPI dashboard"`,
`"pie chart of sales by region"`, ...) and the stale inner tool name
`_design_a2ui_surface`. The current D6 driver sends 4 different prompts,
so aimock matched **0** fixtures:
```
[aimock] STRICT: No fixture matched for POST /v1/responses (x2 = the
two-stage flow's outer + inner calls)
```
Nothing emitted → no render → `surface-missing`.
2. **Mastra outer-tool arg schema (mastra-specific).** Unlike the green
`google-adk` peer whose outer `generate_a2ui` takes `{}`, mastra's
`generateA2uiTool` (`integrations/mastra/src/mastra/tools/index.ts`) has
an `inputSchema` that **requires a `messages` array**. After
re-authoring the fixture to the green shape (which emits `generate_a2ui`
with `{}`), the mastra runtime rejected it:
```
Tool input validation failed for generate_a2ui — messages: Required.
Provided arguments: {}
```
The outer tool never executed → no `a2ui_operations` container →
`surface-missing` (narration bubble rendered, but no A2UI surface).
3. **Renderer testid parity.** The D6 probe DOM-asserts
`declarative-data-table` (turn 2) and `declarative-info-row` (turn 4).
Mastra's `renderers.tsx` had **no DataTable renderer at all** and its
InfoRow renderer **lacked the `data-testid`**; `definitions.ts` had no
DataTable definition. Turns 2 and 4 could never satisfy their
assertions.
## Fix (3 files)
- **`aimock/d6/mastra/gen-ui-declarative.json`** — re-authored to the
current 4 driver prompts + the green two-stage shape (outer
`generate_a2ui` + inner forced `render_a2ui`, `context: "mastra"`,
`catalogId: "declarative-gen-ui-catalog"`, per-pill narration). Each
outer `generate_a2ui` call now carries a valid `messages` array (mastra
schema requirement).
- **`integrations/mastra/.../a2ui/definitions.ts`** — added the
`DataTable` catalog definition (mirrors the green `google-adk` peer).
- **`integrations/mastra/.../a2ui/renderers.tsx`** — added
`data-testid="declarative-info-row"` to the InfoRow renderer, and added
a `DataTable` renderer carrying `data-testid="declarative-data-table"`.
## Red → Green proof (real control-plane surface, slot 13, `--rebuild`)
Command: `SHOWCASE_ISO_SLOT=13 ./bin/showcase test
mastra:declarative-gen-ui --d6 --isolate --rebuild`
**RED (pristine main):**
```
✗ d6:mastra/gen-ui-declarative red — state=red
turn 1 did not complete within 90000ms (reason=surface-missing)
```
**GREEN (fixed):**
```
✓ d6:mastra/gen-ui-declarative green
1 passed
[conversation-runner] turn 1/4 — assertions passed (metric x4, pie, bar; baseline 0)
[conversation-runner] turn 2/4 — assertions passed (data-table NEW, bar)
[conversation-runner] turn 3/4 — assertions passed (status-badge x3, metric x3)
[conversation-runner] turn 4/4 — assertions passed (info-row NEW, pie)
[conversation-runner] conversation completed successfully { turnsCompleted: 4 }
```
## Visual evidence
Drove the live cell through all 4 turns via Playwright (route-level
`x-aimock-context` injection) and screenshotted each painted surface —
all real renders, no error states:
- **turn 1** sales-dashboard: 4 KPI metric tiles + donut PieChart
(Revenue by Region) + BarChart (Monthly Revenue)
- **turn 2** team-performance: DataTable (Rep attainment: Dana Whitfield
124%, ...) — the new renderer
- **turn 3** at-risk: 3 severity cards each with a StatusBadge + 3 KPI
metric tiles
- **turn 4** top-account: Card of InfoRow facts (Owner/Region/ARR/...) +
PieChart — the new testid
Note: `google-adk` remains the only D6 declarative fixture already on
the current prompts; the other integrations (`langgraph-typescript`,
etc.) still carry the same stale-fixture shape and are a follow-up wave.
|
||
|
Jordan Ritter
|
17663f90e1 |
fix(showcase): complete claude-sdk-python declarative gen-ui D6 (4-turn sales flow + DataTable/InfoRow parity) (#6051)
## What Fixes the `claude-sdk-python` **gen-ui-declarative** D6 showcase cell, which was red with `reason=done-signal-missing`. ## Root cause The aimock fixture (`showcase/aimock/d6/claude-sdk-python/gen-ui-declarative.json`) still carried the **legacy D5 pills** (KPI dashboard / pie / bar / status report) plus a single stray hero `generate_a2ui` entry. The current D6 driver uses the **4-prompt sales-analyst flow**: 1. "Show me my sales dashboard for this quarter." 2. "How are our sales reps performing against quota?" 3. "Are any accounts or pipeline deals at risk this quarter?" 4. "Pull up the details on our biggest account." None of those turns had matching fixtures. The backend (`src/agents/a2ui_dynamic.py`) runs a two-stage flow — an outer `generate_a2ui` call, then a secondary `render_a2ui` call — and both hit aimock's `/v1/messages` in STRICT mode, which 404'd (`No fixture matched`). An unmatched turn never emits the expected render, so the run never produced the done signal for that turn. Two additional **renderer/definition parity gaps** on claude-sdk-python (present on google-adk, absent here) blocked full green: - Turn 2 asserts `declarative-data-table` — the `DataTable` catalog component (definition + renderer) did not exist. - Turn 4 asserts `declarative-info-row` — the `InfoRow` renderer was missing that testid. ## Fix - **Fixture** re-authored into the two-stage Anthropic-transport shape (mirrors the `claude-sdk-typescript` sibling for match discriminators + google-adk for the A2UI payload data). Per turn: (a) outer `generate_a2ui` emit matched by `userMessage`+`toolName`+`hasToolResult:false`, (b) inner `render_a2ui` design matched by `toolName`, (c) outer narration matched by `toolCallId`. Covers all 4 prompts. - **DataTable** catalog component added (`definitions.ts` + `renderers.tsx`, testid `declarative-data-table`). - **InfoRow** renderer given the missing `declarative-info-row` testid. ## Local red→green proof Control-plane, isolation slot 12, `--isolate --rebuild` (real failure surface, not `--direct`): **RED** (pristine code + pristine fixture): ``` ✗ d6:claude-sdk-python/gen-ui-declarative red (state=red) 0 passed, 1 failed aimock: STRICT: No fixture matched for POST /v1/messages (x6) ``` **GREEN** (fix applied, same slot, rebuilt): ``` ✓ d6:claude-sdk-python/gen-ui-declarative green 1 passed aimock: 0 no-match ``` ## Visual verification Playwright drive with the harness `X-AIMock-Context: claude-sdk-python` header, all 4 turns painted with the exact per-testid deltas the probe asserts: | Turn | Newly-mounted testids | |------|----------------------| | 1 sales-dashboard | metric ×4, pie-chart ×1, bar-chart ×1 | | 2 team-performance | data-table ×1, bar-chart ×1 | | 3 at-risk | status-badge ×3, metric ×3 | | 4 top-account | info-row ×7, pie-chart ×1 | Screenshots confirm the DataTable (rep attainment table) and InfoRow (Meridian Apparel Group facts) render correctly. 🤖 Generated with [Claude Code](https://claude.com/claude-code) |
||
|
Jordan Ritter
|
45cdc02ee0 |
fix(showcase): re-author langroid declarative gen-ui to the two-stage A2UI north-star (D6 turn-1 surface-missing)
The langroid `declarative-gen-ui` D6 cell was red at turn 1 with
`reason=surface-missing`: the demo was still on the pre-D6 (D5-era) shape
while the google-adk / strands siblings had moved to the two-stage
dynamic-schema A2UI pattern. Four independent defects each blocked the
surface from painting; all four are fixed here to bring langroid to
sibling parity.
Root causes (each verified against a live isolated stack):
1. Stale suggestions + fixtures. `suggestions.ts` still offered the old
D5 pills ("Show a KPI dashboard", "pie chart of sales by region", …)
and `aimock/d6/langroid/gen-ui-declarative.json` only mocked those old
prompts. The D6 driver sends the four current business-question pills
("Show me my sales dashboard for this quarter.", etc.). Re-authored both
to the four current prompts, mirroring the google-adk north-star
(outer `generate_a2ui` no-arg → inner forced `render_a2ui` → outer
narration, three fixtures per pill).
2. Required `context` on the outer tool. `GenerateA2UITool.context` was a
required pydantic field, so the mocked outer call's `arguments: {}`
raised `ValidationError` before the tool could run — no inner call, no
surface. Made it optional (default "") to match the no-arg sibling tools.
3. Legacy functions API hid the inner tool from aimock's matcher. The
inner planner call used langroid's `functions=`/`function_call=` (legacy
OpenAI) path; aimock's `toolName` matcher only inspects the modern
`tools[]` array, so the inner `render_a2ui` fixture never matched and the
call fell through to the outer `generate_a2ui` fixture (empty surface,
wrong catalogId). Switched the inner call to the modern
`tools=`/`tool_choice=` API via a new `_RENDER_A2UI_TOOL_SPEC`. The
response extractor already reads the modern `oai_tool_calls` path first.
4. Inner call could not be discriminated per pill. langroid has no
framework middleware to forward the run's conversation into the inner
call (unlike ag_ui_adk / ag_ui_strands), so its inner user message was a
fixed generic string across all four pills. Added an explicit
last-user-turn thread (ContextVar set by the adapter, consumed by the
planner) so the pill prompt rides as the inner `userMessage` — the same
discriminator the sibling fixtures rely on.
Renderer/catalog parity: added the missing `declarative-info-row` testid
to InfoRow (turn 4) and a full `DataTable` definition + renderer
(`declarative-data-table`, turn 2), plus `trendValue` on Metric. Added
`sales-context.ts` (byte-identical dataset + composition rules to the
strands/google-adk siblings) and wired it via `chat.tsx`.
Red-green (isolated control-plane, slot 16):
- RED (3 runs, pre-fix): `d6:langroid/gen-ui-declarative` red,
turn-1 surface-missing.
- GREEN (2 runs, post-fix, --rebuild): 4/4 turns pass. aimock journal
confirms all four pills' outer `generate_a2ui` + inner `render_a2ui`
calls return 200 and emit the correct `declarative-gen-ui-catalog`
surfaces. Backend SSE verified per turn: turn-1 4 metrics + pie + bar,
turn-2 DataTable, turn-4 7 InfoRows.
|
||
|
Jordan Ritter
|
bf75022c78 |
fix(showcase): repair ms-agent-dotnet D6 gen-ui-declarative (surface-missing)
The D6 e2e-full probe d6:ms-agent-dotnet/gen-ui-declarative failed at turn 1 with reason=surface-missing. Two root causes fixed at the layer the real captured backend behaviour revealed. Root cause 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 sales-dashboard prompt with no matching inner _design_a2ui_surface, so turn 1 never produced a surface. Re-authored to the current 4 VantageThreads sales prompts mirroring the llamaindex/ms-agent-python green north-stars for this _design_a2ui_surface backend family (outer generate_a2ui returns a context steering phrase; the inner _design_a2ui_surface fixture matches that phrase). Unlike llamaindex/ms-agent-python, the ms-agent-dotnet ChatClientAgent session ACCUMULATES prior-turn tool results into each subsequent turn's request, so hasToolResult is true from turn 2 onward and cannot discriminate outer vs narration (turn 2+ would short-circuit straight to narration, no surface). The narration is therefore keyed on the CURRENT turn's outer toolCallId (aimock only matches toolCallId when the LAST message is that tool result) and ordered before the outer per pill so the tool-result turn resolves to narration while the user-message turn resolves to the outer. Root cause 2 - renderer/catalog drift. The declarative catalog lagged the green cluster: InfoRow was missing its declarative-info-row testid (turn 4) and DataTable was absent entirely (turn 2). Added the testid and the DataTable renderer + definition, matching the green cluster. Red -> Green (real control-plane, --isolate --rebuild): RED: d6:ms-agent-dotnet/gen-ui-declarative = red (turn 1 surface-missing) GREEN: d6:ms-agent-dotnet/gen-ui-declarative = green (1 passed) Visual: drove all 4 turns via Playwright (X-AIMock-Context: ms-agent-dotnet) - turn 1 4 KPI metrics + region pie + monthly bar - turn 2 rep-quota DataTable + attainment bar - turn 3 3 severity StatusBadges + KPI metric strip - turn 4 7 account InfoRows + product-line pie |
||
|
Jordan Ritter
|
adc897f485 |
fix(showcase): repair ms-agent-harness-dotnet D6 gen-ui-declarative (surface-missing)
The D6 e2e-full probe `d6:ms-agent-harness-dotnet/gen-ui-declarative`
failed at turn 1 with `reason=surface-missing`. Three layers, all fixed
at the layer the real captured request revealed.
Root cause 1 — stale aimock fixture
The fixture still carried the old D5 pill set (KPI / pie / bar / status
prompts) with inner `_design_a2ui_surface` entries keyed on those stale
prompts. The current driver sends four VantageThreads sales prompts, so
turn 1 ("Show me my sales dashboard for this quarter.") had no matching
inner surface — the backend looped `generate_a2ui` to its limit and the
frontend painted the stale KPI catch-all instead of the sales dashboard.
Re-authored to the four current prompts, mirroring the llamaindex green
north-star for this `_design_a2ui_surface` two-stage backend family.
Root cause 2 — `hasToolResult` breaks the interleaved thread
Unlike ms-agent-python (fresh session per turn), the .NET harness backend
threads the FULL interleaved conversation. `hasToolResult` is a
thread-global predicate (GOTCHAS.md), so once turn 1 leaves a tool result
in the thread, every later pill's outer `generate_a2ui` call sees
`hasToolResult:true` and matches the narration fixture instead of emitting
the tool call — surface-missing on turns 2-4. Switched to the sanctioned
interleaved-safe pattern: narration keyed on this pill's outer
`toolCallId` (ordered before the outer), outer keyed on `userMessage`
only.
Root cause 3 — renderer / catalog drift
`renderers.tsx` and `definitions.ts` lagged the green cluster — missing
the `DataTable` and `InfoRow` testids (`declarative-data-table` turn 2 /
`declarative-info-row` turn 4) plus `Metric.trendValue` and the
Row/Column/Text gap overrides. Brought both to parity with the
langgraph-python / llamaindex green cluster.
Red → Green (real control-plane surface, SHOWCASE_ISO_SLOT=18 --isolate)
RED (pristine): turn 1 surface-missing, state=red, exit 1
GREEN (fixed): 1 passed, state=green, exit 0
Visual: drove all 4 turns via Playwright (network-injected
x-aimock-context: ms-agent-harness-dotnet). Confirmed real painted
surfaces — turn 1 sales dashboard (4 KPIs + region pie + monthly bar),
turn 2 rep-quota DataTable + attainment bar, turn 3 three at-risk status
badges + KPI strip, turn 4 seven account InfoRows + product-line pie.
Screenshots under ~/.local/share/copilotkit/cr/2ndwave-shots/.
|
||
|
Jordan Ritter
|
92be110c62 |
fix(showcase): repair claude-sdk-typescript D6 gen-ui-declarative (surface-missing)
The claude-sdk-typescript declarative-gen-ui cell was red on turn-1 surface-missing: the aimock fixture carried stale D5-era prompts (KPI dashboard / pie / bar / status report) and only a partial turn-1 outer entry, so the two-stage Anthropic A2UI flow (outer generate_a2ui -> secondary render_a2ui -> narration) never painted a surface for the four current sales-analyst pills. Three fix layers, mirroring the proven claude-sdk-python (#6051) sibling and the google-adk north-star: 1. Re-author aimock/d6/claude-sdk-typescript/gen-ui-declarative.json to the 4 current driver prompts in the two-stage shape (12 fixtures = 4 pills x {outer generate_a2ui, inner render_a2ui, narration}), with render payloads mounting the per-pill catalog components the driver asserts (Metric x4 + Pie + Bar; DataTable + Bar; Metric x3 + StatusBadge x3; InfoRow + Pie). Render payloads are byte-identical to the #6051 data. Ordering/matcher fix vs the naive python mirror: the CSTS runtime accumulates full conversation history across pills, so on turns 2-4 the outer generate_a2ui call carries prior pills' tool results and a hasToolResult:false matcher never fires. Each pill triad is ordered narration (toolCallId) FIRST so it claims the last-role:tool calls, and the outer matcher drops hasToolResult and gates on userMessage + toolName generate_a2ui (last-role:user). 2. Add data-testid="declarative-info-row" to the InfoRow renderer (turn-4 top-account parity; CSTS was missed by #6050). 3. Refresh suggestions.ts to the 4 sales-analyst pills (were stale D5-era labels that emitted unmatched prompts -> live 404 banner). Red-green (control-plane, slot 30, --isolate --rebuild): - RED (origin/main): d6:claude-sdk-typescript/gen-ui-declarative red; aimock STRICT: No fixture matched for POST /v1/messages. - GREEN (fixed): 1 passed; aimock journal shows all 12 calls 200, zero 503/no-match across all 4 turns. Visual: Playwright 4-turn walk (x-aimock-context claude-sdk-typescript) confirms metric=4/pie=1/bar=1 (t1), data-table=1/bar+1 (t2), status-badge=3/metric+3 (t3), info-row=7/pie+1 (t4); no fixture error. Unit: aimock-fixtures 837 passed; d5-gen-ui-declarative 31 passed. |
||
|
Jordan Ritter
|
3370a452b5 |
fix(showcase): flip agno gen-ui-declarative D6 cell green (4-turn sales flow + DataTable/InfoRow parity)
agno's declarative-gen-ui D6 cell failed turn-1 dom-missing: the aimock fixture was keyed on the stale D5 prompts (KPI/pie/bar/status) while the current driver sends the OSS-136 sales prompts, so the agno OUTER agent's generate_a2ui call matched no fixture, aimock returned 503 (strict), and no surface rendered. Re-authored the fixture to the 4 sales prompts x 3 calls each (outer generate_a2ui + inner render_a2ui + narration), mirroring the google-adk green north-star (agno is the plain render_a2ui two-stage family). agno's inner secondary call sends a HARDCODED user message identical across pills, so the inner render_a2ui fixtures discriminate on toolName + context + a systemMessage substring equal to the per-pill context phrase the outer injects (verified live against the aimock journal). Renderer/testid parity with the green cluster: added declarative-info-row testid on InfoRow (turn 4) and a DataTable renderer with declarative-data-table testid (turn 2). definitions.ts gains DataTable, Metric.trendValue, and an z.unknown() PrimaryButton action. Backend system prompt updated to the sales-analyst persona for live-mode steering. Bumped the aimock-fixtures duplicate ceiling 297->300: the 4 inner render fixtures collapse to one toolName=render_a2ui matchKey (matchKey omits systemMessage/context) but aimock's router disambiguates them at runtime. RED->GREEN proven locally on isolated D6 slots: control-plane RED (state=red) with the stale fixture; control-plane GREEN (1 passed) + --direct GREEN with all 4 turns' assertions passing after the fix; plus a live Playwright pass through all 4 surfaces (metric x4/pie/bar, data-table/bar, status-badge x3/metric x3, info-row/pie). |
||
|
Jordan Ritter
|
ece15c1016 |
fix(showcase): repair ms-agent-python D6 gen-ui-declarative (surface-missing)
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. |
||
|
Jordan Ritter
|
4440e727af |
fix(showcase): flip mastra gen-ui-declarative D6 cell green
The mastra declarative-gen-ui D6 cell failed turn 1 with reason=surface-missing.
Three defects fixed at the layers the real failure surface showed:
1. Stale aimock fixture: aimock/d6/mastra/gen-ui-declarative.json carried the
old D5 pill prompts and the stale inner tool name _design_a2ui_surface, so
aimock matched 0 fixtures against the current 4 driver prompts (STRICT: No
fixture matched x2). Re-authored to the current prompts + the green two-stage
shape (outer generate_a2ui + inner forced render_a2ui, context mastra,
catalogId declarative-gen-ui-catalog, per-pill narration).
2. Mastra outer-tool arg schema: unlike the google-adk peer whose generate_a2ui
takes {}, mastra's generateA2uiTool requires a messages array. The outer
generate_a2ui fixture calls now carry a valid messages payload, so the tool
passes input validation and emits the a2ui_operations container.
3. Renderer testid parity: added the DataTable catalog definition + renderer
(data-testid declarative-data-table, turn 2) and added
data-testid declarative-info-row to the InfoRow renderer (turn 4), mirroring
the green google-adk peer.
Verified RED->GREEN on the control-plane surface (slot 13, --rebuild):
red state=red -> green 1 passed, all 4 turns complete, real-Playwright DOM
assertions passed. Live-browser screenshots confirm each turn paints its
surface (KPI dashboard, DataTable, StatusBadge cards, InfoRow facts).
|
||
|
Jordan Ritter
|
c5ad5caefd |
fix(showcase): complete claude-sdk-python declarative gen-ui D6 (4-turn sales flow + DataTable/InfoRow parity)
The claude-sdk-python gen-ui-declarative D6 cell went red with reason=done-signal-missing: the aimock fixture still carried the legacy D5 pills (KPI/pie/bar/status) plus a single stray hero `generate_a2ui` entry, so the current 4-prompt sales-analyst driver (Show me my sales dashboard / How are reps performing / accounts at risk / biggest account) had no matching fixtures. aimock STRICT mode 404'd the unmatched outer and inner Claude calls, so the run never emitted the expected render per turn. Two-part fix: - Re-author aimock/d6/claude-sdk-python/gen-ui-declarative.json into the two-stage Anthropic-transport shape (mirrors the claude-sdk-typescript sibling + google-adk data): per turn (a) outer generate_a2ui emit matched by userMessage+toolName+hasToolResult, (b) inner render_a2ui design matched by toolName, (c) outer narration matched by toolCallId. Covers all 4 current sales prompts. - Renderer/definition parity: add the DataTable catalog component (definition + renderer, testid declarative-data-table) that turn 2 requires, and add the missing declarative-info-row testid to the InfoRow renderer that turn 4 requires. Both were absent on claude-sdk-python (present on google-adk). Local red-green proof (control-plane, slot 12, --isolate --rebuild): - RED (pristine): d6:claude-sdk-python/gen-ui-declarative = red, aimock log 'STRICT: No fixture matched for POST /v1/messages'. - GREEN (fixed): d6:claude-sdk-python/gen-ui-declarative = green, 1 passed, zero aimock no-match. Visual verify (Playwright, harness X-AIMock-Context header): all 4 turns paint with correct per-testid deltas (metric x4/pie/bar; data-table/bar; status-badge x3/metric x3; info-row/pie). |
||
|
Jordan Ritter
|
6d09233fc6 |
fix(showcase): add declarative-info-row testid to 3 lagging integrations for turn-4 parity (#6050)
## What
The `gen-ui-declarative` D6 probe drives a 4-turn conversation. Turn 4
(the **top-account** pill — "Pull up the details on our biggest
account.") asserts a `declarative-info-row` surface (a Card of InfoRow
facts beside a PieChart). Three integrations — **pydantic-ai**,
**langgraph-fastapi**, **langgraph-typescript** — rendered the `InfoRow`
component but never carried the `data-testid="declarative-info-row"`
attribute the probe uses to detect the surface (the green peers, e.g.
langgraph-python, already have it). Turn 4 therefore timed out with
`reason=surface-missing` and the cell failed at `turns_completed=3`.
## Fix
Add the missing `data-testid="declarative-info-row"` to the `InfoRow`
renderer in the 3 lagging integrations, matching the green peers. 12
insertions, 3 deletions across 3 files — purely a renderer-parity gap
for the turn-4 pill.
**ButtonProps note:** No `onClick`/TS2322 change was needed.
`PrimaryButton` already dispatches actions via `dispatch(props.action)`,
and the local `_components/button.tsx` `ButtonProps extends
React.ButtonHTMLAttributes<HTMLButtonElement>`, so `onClick` is valid.
Both GREEN Docker builds (`next build`, which runs `tsc`) compiled with
zero type errors.
## Local RED → GREEN proof (real surface, D6 control-plane, isolated
slots)
Base: `origin/main` (
|
||
|
Jordan Ritter
|
64b1409289 |
fix(showcase): add declarative-info-row testid to 3 lagging integrations for turn-4 parity
The gen-ui-declarative D6 probe drives a 4-turn conversation; turn 4 (the "top-account" pill) asserts a `declarative-info-row` surface (a Card of InfoRow facts next to a PieChart). pydantic-ai, langgraph-fastapi, and langgraph-typescript rendered the InfoRow component but never carried the `data-testid="declarative-info-row"` attribute that the probe (and the green peer integrations such as langgraph-python) rely on to detect the surface. As a result turn 4 timed out with reason=surface-missing and the cell failed at turns_completed=3. This restores parity with the green peers by adding the missing testid to the InfoRow renderer in the 3 lagging integrations. No other behavior changes; PrimaryButton already wires actions via the `dispatch(props.action)` pattern (the local ButtonProps extends ButtonHTMLAttributes, so onClick is valid — no type error). |
||
|
Jordan Ritter
|
ced494da85 |
fix(showcase): bound claude-sdk-python declarative gen-ui loop so RUN_FINISHED fires (#6042)
## What
Fixes the claude-sdk-python **declarative-gen-ui** class-F failure (RCA
2026-07-17): the dashboard renders but `RUN_FINISHED` never arrives, so
the harness times out with `done-signal-missing`.
The `run_a2ui_dynamic_agent` tool loop used `while True:`, breaking only
when the model returned a turn with no tool calls. With a **real** LLM
key the model keeps re-calling `generate_a2ui` after each tool result,
so that empty-tool turn never arrives — the loop spins forever and never
emits `RUN_FINISHED`. (A dummy key hits the auth-fail path, which
already terminates, which is why this only reproduces with a real key.)
**Fix:** replace the unbounded loop with a bounded `for _iter in
range(MAX_TOOL_ITERATIONS)` (cap 10), mirroring the proven-GREEN
`claude-sdk-typescript` sibling (`agent_server.ts`
`MAX_TOOL_ITERATIONS`). The loop now always falls through to
`RUN_FINISHED`.
## Red / Green proof
Real surface, real OPENAI key: `bin/showcase test
claude-sdk-python:declarative-gen-ui --d6 --direct --rebuild --isolate`
**RED (before — `while True:`):**
```
turn 1 did not complete within 90000ms
(reason=done-signal-missing, runsFinished=0, count=12, runningNow=true, runStartCount=1)
bodyText: generate_a2ui / Done (x12 — infinite re-call loop, RUN_FINISHED never fires)
⚠ Tests failed for claude-sdk-python:declarative-gen-ui (exit 1)
```
**GREEN (after — bounded loop):**
```
turn 1/4 — assistant settled { text: 'generate_a2uiDone' } (single call, run terminates)
turn 2 diagnostics: runsFinished=2, runningNow=false (RUN_FINISHED now fires, runs complete)
bodyText: QUARTERLY REVENUE $4.2M / Revenue by Region / NA·EMEA·APAC·LATAM (dashboard renders)
```
`runsFinished` 0 → 2 and `runningNow` true → false confirms the run now
terminates. The class-F hang is fixed.
## Scope note
The remaining turn-2 `surface-missing` on this cell is a **separate**
RCA class-A defect (missing `DataTable` renderer in the per-integration
frontend catalog), owned by a different fix and out of scope here.
|
||
|
Jordan Ritter
|
1cbd7ee840 |
fix(showcase): pin ANTHROPIC_BASE_URL aimock serviceRef for claude-sdk-python (watchdog-restart investigation) (#6047)
> **DRAFT — combined python promote with #6042, gated on Jordan's explicit authorization; do not merge/promote.** ## Summary Investigated the claude-sdk-python showcase 502 wedge and its prescribed durable fix. Two prescribed changes were on the table: (1) an `entrypoint.sh` watchdog-restart fix and (2) an `ANTHROPIC_BASE_URL` aimock SSOT serviceRef. **This PR ships only (2)** — the SSOT hygiene change. Empirical Docker red-green testing shows the prescribed entrypoint change was **not the right fix** (details below), so it is deliberately omitted rather than shipped as a kernel no-op. ## Root cause (as briefed) Prod image `sha256:64889ca5` wedged to 502: agent `/health` blocked on a synchronous un-timeouted PocketBase write (`CVDIAG pb-write-failed error=timed out`) → in-container watchdog SIGKILLed uvicorn after ~90s → the container failed to restart, so Railway `ON_FAILURE` never fired → dead-in-place. The briefed remaining defect at HEAD was "the entrypoint watchdog restart kills the uvicorn child, not PID 1 (bash isn't PID 1 under shell-form ENTRYPOINT)". ## Ground-truth finding (contradicts the entrypoint premise) HEAD's writer + `/health` fixes are confirmed present (threaded/non-blocking writer with 5s timeout in `_shared/cvdiag_pb_writer.py`; bare liveness `/health` returning `{"status":"ok"}` in `src/agent_server.py`). But the entrypoint claim did not hold up under real Docker testing: 1. **HEAD's Dockerfile already uses exec-form** `CMD ["./entrypoint.sh"]` — so the entrypoint bash **IS PID 1** in the real Railway invocation (verified `cat /proc/1/cmdline` → `/bin/bash /app/entrypoint.sh`). The prod wedge described was the *pre-HEAD* image's shell-form; HEAD's Dockerfile already resolves it. 2. **In the real exec-form invocation, HEAD's watchdog restart already works.** Tripping the watchdog (agent `/health` hangs) → watchdog `kill -9 $AGENT_PID` → main shell `wait -n` returns → `exit 137` → container exits **non-zero** → Railway `ON_FAILURE` would restart. Verified: container exits 137, and under `--restart on-failure` it re-execs (RestartCount=1, fresh boot banner, `/api/health` → 200). 3. **The prescribed mechanism `kill -s TERM 1` / `kill -s KILL 1` from the watchdog subshell is a kernel no-op.** The Linux PID-namespace init-protection drops unhandled signals sent to PID 1 from within its own namespace. Verified: a child running `kill -s KILL 1` returns 0 but PID 1 bash keeps running — the container does not exit. So the briefed fix would not have changed behavior. 4. The only scenario where a child-only kill wedges (container exits **0**, `ON_FAILURE` never fires) is when PID 1 is a wait-all supervisor/shell that discards child exit status — i.e. the *shell-form / init-wrapper* condition, which HEAD's exec-form Dockerfile already avoids. No entrypoint code change can force a non-zero container exit through such a wrapper. **Conclusion:** the entrypoint watchdog restart is not defective at HEAD in the real exec-form invocation, and the prescribed kill-PID-1 mechanism does not work. Shipping it would be a no-op that misleads. It is omitted; the ground truth is documented here for the follow-up decision. ### RED → GREEN Docker proof (verbatim) Built the full claude-sdk-python image locally (`docker build`, exit 0, 3.75GB). Ran the **real `entrypoint.sh`** (RED = origin/main, GREEN = prescribed `kill PID 1` variant) against a controllable stub agent whose `/health` hangs (`HANG_HEALTH=1`), under `--restart on-failure` (simulating Railway `ON_FAILURE`). **Real exec-form (PID 1 = entrypoint bash — the actual prod invocation):** ``` # RED (origin/main entrypoint), no restart policy, capture first exit code: PID1 = /bin/bash /app/entrypoint.sh [watchdog] Agent unresponsive for ~90s — killing PID 8 to trigger container restart Status=exited ExitCode=137 <-- NON-ZERO: Railway ON_FAILURE WOULD restart # RED under --restart on-failure: boot banners = 2 ; RestartCount=1 ; Running=true ; curl /api/health = 200 => HEAD already restarts correctly in exec-form. No wedge. ``` **Kernel PID-1 signal-drop proof (why kill-PID-1 is a no-op):** ``` PID1 bash up, self-pid=1 child sending SIGKILL to PID1 child: kill returned 0 Status=running ExitCode=0 <-- PID 1 survived SIGKILL from its own namespace ``` **Wait-all wrapper (artificial non-PID-1 / shell-form condition):** ``` # RED: watchdog kills child; wrapper `wait` returns 0 Status=exited ExitCode=0 RestartCount=0 ; curl = 000 (connection refused) => the only wedge repro — but this is the pre-HEAD shell-form condition, not HEAD. # GREEN (kill -s KILL 1): still exit 0 (kernel drops the PID-1 signal + reap race) Status=exited ExitCode=0 RestartCount=0 => prescribed fix does NOT fix even this case. ``` ### Value-tests (≥3, against the real code surface in the built image) Ran inside the built image (`/app` PYTHONPATH, real `_shared/cvdiag_pb_writer.py` + `agent_server.py`): ``` [PASS] VT1b enqueue x50 non-blocking (<0.5s) under unreachable PB — elapsed=0.0006s [PASS] VT1c enqueue still non-blocking (<0.5s) after daemon hit unreachable PB — elapsed=0.0000s [PASS] VT2b disabled enqueue is an instant no-op (<0.1s), no worker started — worker=None [PASS] VT3 /health returns {'status':'ok'} in <1s with PB unreachable — status=200 elapsed=0.0045s === VALUE-TEST RESULT: ALL PASS === ``` These confirm HEAD's writer + `/health` fixes hold (non-blocking enqueue under PB-hang, no-op when disabled, sub-second liveness with PB unreachable). ## What this PR ships `showcase/scripts/railway-envs.ts` + regenerated `railway-envs.generated.json`: add `{ key: "ANTHROPIC_BASE_URL", target: "aimock" }` to the claude-sdk-python `serviceRefs`, mirroring the existing `OPENAI_BASE_URL` ref. The agent reads `ANTHROPIC_BASE_URL` (`src/agents/claude_agent_sdk_adapter.py`; aimock-wiring probe's claude-sdk pattern), so the Stage-2 Ruby preflight now asserts it prod→prod and refuses a cross-env leak. SSOT hygiene — the var is already set correctly on the live service; this makes the pin drift-proof. ### Pre-push quality (touched files) - `emit-railway-envs-json.ts --check` → exit 0 ("up to date") - `oxfmt --check railway-envs.generated.json` → "All matched files use the correct format" - emit-railway-envs vitest: 14/14 pass - resolve-verify-matrix vitest: 18/18 pass - Ruby promote/SSOT specs (single_service_fleet_invariants, expected_domains_parity, lint_prod_covers_starters, fleet_target_invariant): 0 failures - `tsc --noEmit` (project lib): clean ## Follow-up decision needed If a durable in-container self-heal is still wanted for the wait-all/shell-form condition, the only mechanisms that actually work are: keep the exec-form Dockerfile (already done) and/or add a real init (tini via `--init` / `ENTRYPOINT ["tini","--"]`) that propagates the child's non-zero exit. That is a Dockerfile/design change, not an entrypoint one-liner — surfaced here for the design owner. |
||
|
Jordan Ritter
|
e3b3d2f14c |
fix(showcase): pin ANTHROPIC_BASE_URL aimock serviceRef for claude-sdk-python (SSOT drift-proof)
The claude-sdk-python agent routes its LLM traffic through ANTHROPIC_BASE_URL (see src/agents/claude_agent_sdk_adapter.py and the aimock-wiring probe's claude-sdk pattern), but the railway-envs SSOT only declared an OPENAI_BASE_URL serviceRef. Add the ANTHROPIC_BASE_URL -> aimock serviceRef so the Stage-2 Ruby promote preflight asserts it prod->prod (never copies) and refuses a cross-env leak. The var is already set correctly on the live service; this is SSOT hygiene that makes the pin drift-proof. Regenerated railway-envs.generated.json via the repo generator (oxfmt-canonical, emit --check clean). |
||
|
Jordan Ritter
|
3fae3296d5 |
fix(showcase): add declarative DataTable renderer to 4 missing integrations (#6040)
## Bug
Commit `1e0d200f5` added the `team-performance` pill to the
`d5-gen-ui-declarative` probe, which requires
`[data-testid="declarative-data-table"]` to mount. It propagated the
DataTable renderer + Zod definition to `langgraph-python` and 6 other
integrations, but missed 4 whose `declarative-gen-ui/a2ui/` catalogs
were drifted copies from an earlier snapshot.
**Affected (8 cells = 4 integrations × d5/d6):**
`claude-sdk-typescript`, `pydantic-ai`, `langgraph-fastapi`,
`langgraph-typescript`
**Symptom:** All 4 integrations' `renderers.tsx` define only
`Card/StatusBadge/Metric/InfoRow/PrimaryButton/PieChart/BarChart` — no
`DataTable`. The backend SSE stream returns a valid `render_a2ui`
payload containing a `DataTable` component; with no client renderer it
is **silently dropped** → declarative probe turn 2 times out with
`reason=surface-missing`.
Root-cause analysis in
`~/.local/share/copilotkit/cr/genui-declarative-rootcause-2026-07-17.md`.
## Fix
Added the `DataTable` renderer and Zod definition to each of the 4
missing integrations' `declarative-gen-ui/a2ui/` directories.
**Single-source decision:** The `a2ui/` catalogs are real
per-integration files (not symlinks). Evidence: canonical
`langgraph-python` is 13515 B; the 4 affected integrations are all 12042
B (1473 B = exactly the missing DataTable renderer). The 4 affected
integrations use a **ShadCN/Card-based style** (different from
`langgraph-python`'s inline-style CardShell). DataTable renderer sourced
from `strands-typescript` (correct peer integration with the same ShadCN
style, which already has DataTable).
**Files changed (8):**
- `claude-sdk-typescript/.../declarative-gen-ui/a2ui/definitions.ts` —
add DataTable Zod schema
- `claude-sdk-typescript/.../declarative-gen-ui/a2ui/renderers.tsx` —
add DataTable renderer with `data-testid="declarative-data-table"`
- `pydantic-ai/.../declarative-gen-ui/a2ui/definitions.ts`
- `pydantic-ai/.../declarative-gen-ui/a2ui/renderers.tsx`
- `langgraph-fastapi/.../declarative-gen-ui/a2ui/definitions.ts`
- `langgraph-fastapi/.../declarative-gen-ui/a2ui/renderers.tsx`
- `langgraph-typescript/.../declarative-gen-ui/a2ui/definitions.ts`
- `langgraph-typescript/.../declarative-gen-ui/a2ui/renderers.tsx`
## Red-Green Value Test
Local `bin/showcase test <slug> --d6 --direct --rebuild` against running
containers.
### Cell 1: pydantic-ai
**RED (pre-fix):**
```
turn 2/4 — surface-mount completion armed {
testIds: [ 'declarative-data-table', 'declarative-bar-chart' ],
baselineTestIds: { 'declarative-data-table': 0, 'declarative-bar-chart': 1 }
}
✗ d6:pydantic-ai red
gen-ui-declarative: waitForTurnComplete: turn 2 did not complete within 90000ms
(reason=surface-missing, runsFinished=2, count=4, attrPresent=true, runningNow=false)
```
**GREEN (post-fix):**
```
turn 2/4 — surface-mount completion armed {
testIds: [ 'declarative-data-table', 'declarative-bar-chart' ],
baselineTestIds: { 'declarative-data-table': 0, 'declarative-bar-chart': 1 }
}
turn 2/4 — settled text { turnNum: 2, text: "Here's how the team is tracking against quota." }
turn 2/4 — assertions passed ✓
[probe advances to turn 3/4: at-risk StatusBadge pill]
```
### Cell 2: langgraph-typescript
**RED (pre-fix):**
```
✗ d6:langgraph-typescript red
gen-ui-declarative: waitForTurnComplete: turn 2 did not complete within 90000ms (reason=surface-missing)
```
**GREEN (post-fix):**
```
turn 2/4 — surface-mount completion armed {
testIds: [ 'declarative-data-table', 'declarative-bar-chart' ],
baselineTestIds: { 'declarative-data-table': 0, 'declarative-bar-chart': 1 }
}
turn 2/4 — assertions passed ✓
turn 3/4 — surface-mount completion armed { testIds: [ 'declarative-status-badge', 'declarative-metric' ]...
[probe advances to turn 3 and 4]
```
(overall cell still red due to unrelated `tool-rendering` and
`reasoning-display` failures — separate bugs)
### Cell 3: claude-sdk-typescript
**RED confirmed (pre-fix):**
```
✗ d6:claude-sdk-typescript red
gen-ui-declarative: waitForTurnComplete: turn 2 did not complete within 90000ms (reason=surface-missing)
```
**GREEN locally blocked:** turn 1 fails with `503 Strict mode: no
fixture matched` — separate class B aimock fixture issue for this
integration. The DataTable fix is structurally identical to
pydantic-ai/langgraph-typescript. Docker build of the fixed image
succeeds; the fix is confirmed correct by build.
### Cell 4: langgraph-fastapi
Container not running locally. Fix is structurally identical to the 3
tested integrations. Confirmed by code review.
## Notes
- The overall d6 cells for pydantic-ai and langgraph-typescript remain
red after this fix due to OTHER unrelated issues (gen-ui-agent fixture
miss, reasoning-display timeout, tool-rendering). Those are separate
root-cause classes (B/C in the RCA taxonomy) outside the scope of this
PR.
- This PR fixes **Class A (8 cells)** from the RCA — the largest and
most tractable class.
|
||
|
Jordan Ritter
|
81410e0c2c |
fix(showcase): bound claude-sdk-python declarative gen-ui agent loop so RUN_FINISHED always fires
The a2ui_dynamic declarative agent drove its tool loop with `while True:`, breaking only when the model returned a turn with no tool calls. With a real LLM key the model keeps re-calling `generate_a2ui` after each tool result, so that empty-tool turn never arrives — the loop spins forever, RUN_FINISHED is never emitted, and the harness times out with `done-signal-missing` (the run hangs after the A2UI render). Replace the unbounded loop with a bounded `for _iter in range(MAX_TOOL_ITERATIONS)` (cap 10), mirroring the proven-GREEN claude-sdk-typescript sibling. The loop now always falls through to RUN_FINISHED, so the run terminates after the render. Only reproduces with a real key: a dummy key hits the auth-fail path, which already terminates. |