AI Canvas — A2UI Engine

• *rea:*Intelligence
• *ath:*services/ai/canvas
• *ind:*A2UI engine — agenttoUI workspace; serializable widget protocol that Koder clients render natively
• *tatus:*v0.0.1 — sector bootstrapping (20260509); RFC accepted 20260429

Role in the stack

canvas is the engine that turns LLMemitted "I'd like a calculator here" intent into a *yped, throwaway, taskshaped widget*that the user manipulates inline. LLM agents can produce text and call tools, but they cannot create adhoc UIs — and the Koder Stack today has Kode (chat) without a rendering surface for agentpainted widgets. canvas defines the A2UI protocol, validates messages against the v1 grammar, holds widget state across messages on kdb-next, and exposes the API consumed by every Koder client renderer.

It is the Koder analog of OpenClaw's "Canvas" feature — built on a typed protocol (no free-form HTML/JS) so widgets are safe to emit and deterministic to render across surfaces.

Boundary vs neighbors

• *air product:*products/horizontal/kanvas/ is the flagship Flutter app exposing Canvas as a workspace; same agent backend as Kode, optimised for "agent-painted UI" flows. Engine+product split per project memory engine_product_pattern.
• *enderer SDK:*lives inside engines/sdk/koder_kit/ (per RFC001 of koder_kit + reusefirst policy) so Kode, Kanvas, Pass, and any future Koder Flutter app render A2UI uniformly without per-app duplication.
• *rimary producer:*services/ai/kode recognises A2UI blocks in agent responses and forwards to the renderer.
• *osting:*infra/net/jet serves canvas.koder.dev (engine API) and kanvas.koder.dev (product landing).
• *tate store:*infra/data/kdb-next partitioned by (tenant_id, user_id).

Features (v1 target)

• A2UI v1 protocol — JSON envelope, fixed widget catalog (Column, Row, Text, TextInput, Slider, Button, Chart{line,bar,pie}, Table, ListTile, …), action targets restricted to agent and client:open_url with allowlist
• Schema validator rejecting any widget outside the grammar — no free-form HTML, no JS, no untyped style strings
• Sessions API keyed by (tenant_id, user_id, agent_id) with kdb-next backing
• Synchronous render endpoint + WebSocket streaming for live mid-session updates
• koder_kit Dart renderer with golden tests per widget and theme/i18n awareness
• Versioning policy: version: 1 fixed; v2 adds-only; engine accepts both during migration windows

Primary couplings

RFC and bootstrap

• RFC: canvas-RFC-001-a2ui.md — *ccepted*20260429
• Cleanup ticket: services/ai/backlog/done/141-canvas-decide-future.md (decided to bootstrap; sector active)
• Spec (normative): a2ui-v1.kmd + a2ui-v1.schema.json — *hipped*20260510 via #001 (25 widgets, closed action grammar, 10 valid + 11 invalid conformance fixtures)
• Backend skeleton: canvasd + OpenAPI openapi.yaml — shipped 20260510 via #002 (validator wired to spec fixtures, sessions API, JWKSValidator + devtoken middleware, inmemory store, per-tenant render rate limit)
• Implementation tickets:
  • done/: 001 (A2UI v1 schema + companion + fixtures), 002 (canvasd skeleton + validator + sessions API), 006 (kdbnext sessions+renders adapter — code complete, gated behind `tags kdb until upstream cache #007` resolves the SDK init-panic)
  • pending/: 003 (Flutter renderer in koder_kit), 004 (WS streaming), 005 (Kanvas flagship integration)
  • All 003–005 MUST round-trip the conformance fixtures.

Selfhostedfirst analysis (5 gates)