Generative UI via KVG (Koder Vector Graphics)

draft

RFC aiRFC001 — Generative UI via KVG

Summary

Explora se KVG (Koder Vector Graphics — formato declarativo já existente em engines/sdk/koder_kit/lib/src/kvg/) pode ser o substrato Koder-nativo para *enerative UI*— pattern emergente onde IA emite especificações de widgets dinâmicos renderizados em runtime (e.g., Gemini Intelligence 2026, Google research generative UI 2024).

Motivation

Padrões competitivos:

  • *oogle Gemini Intelligence (2026)*anunciou "AIgenerated widgets" criados por linguagem natural, com LiquidGlass-like rendering.
  • *esearch.google generative UI*(2024 blog) demonstrou LLMs emitindo HTML+CSS+JS dinâmico para responder a prompts variados.
  • *ercel v0*(de-facto comercial) gera React from prompts.

Risco competitivo: se Koder não tem caminho próprio para generative UI, produtos AI Koder ficam atrás em UX.

Por que *ÃO*HTML+CSS+JS:

  • LLMs emitindo HTML têm taxa de erro alta (markup malformado, XSS risks, runtime crashes).
  • Sandbox enforcement complexo.
  • Não composes bem com koder_kit widgets nativos.

Por que KVG pode ser a resposta:

  • *eclarativo*— parseable + validável antes de render.
  • *á existente*— koder_kit/lib/src/kvg/ é cross-surface (Flutter, Web).
  • *estritivo por design*— não permite eval, network, file IO — sandbox trivial.
  • *omposes com Koder design system*— usa tokens, color roles, type roles existentes.
  • *ais fácil pra LLM*— schema declarativo menor que React/HTML.

Hypothesis

H1: LLMs (Claude Opus 4.7, GPT5, Gemini Pro) podem emitir KVG oneshot com taxa de sucesso ≥80% para prompts comuns ("show me a chart of X", "render a card for Y", "generate a diagram of Z").

H2: KVG output é validável antes de render, capturando ~95% de errors estruturais sem rodar render.

H3: Composição com tokens Koder (color-roles, typography) é zeroshot — LLM já entende surface, primary, `bodymedium` se documentado.

Experiments (proposed)

Phase 1: schema documentation

  • Document KVG schema (estendido se necessário) em meta/docs/stack/specs/kvg/generative-extensions.kmd.
  • Cobrir: shapes, layouts, charts, common widget compositions (card, list, table).
  • Decisão go/no-go: schema fits em <3k tokens? Sim → continua. Não → reconsider.

Phase 2: pilot prompts

10 prompts canônicos:

  1. "Render a card with title 'Hello' and body 'World'"
  2. "Show a bar chart of [1, 5, 3, 8, 2]"
  3. "Generate a flowchart of OAuth flow"
  4. "Create a button with primary color saying 'Submit'"
  5. "Render a 2-column layout with image left, text right"
  6. ...

Testar em 3 modelos (Opus, GPT-5, Gemini Pro). Métrica: % de outputs que renderizam corretamente sem editing.

Phase 3: integration test in Kortex

If Phase 2 ≥80% success: integrar em Kortex artifact panel (cross-link #110):

  • User pede widget → AI emite KVG → artifact panel renders.
  • Edit affordance: user modifies KVG; AI sees diff next message.
  • Cost transparency via cost-display.kmd (#112).

Phase 4: safety bounds

Even with declarative KVG:

  • *o network calls*from rendered widgets (no <image src="url"> fetching arbitrary).
  • *o eval-like*— KVG não tem <script> semantics.
  • *esource limits*— max nodes per widget (e.g., 10k), max nested depth (32).
  • *anitization*— text content sanitized; URLs whitelisted.
  • *udit log*— every generated widget logged for forensics.

Open questions

  1. Should KVG schema be extended for AI-generative use cases (charts, forms, dynamic data)? Or keep current minimal scope and accept KVG não cobre todo widget?
  2. Does the AI need access to current theme tokens to emit consistent designs? (Probably yes — include in prompt.)
  3. How is interaction handled? KVG hoje é mostly static; do we add on_click actions emitted by AI that bind to Koder actions?
  4. Versioning compatibility: KVG v1 vs v2 if extended for generative — backward-compat?
  5. Latency budget: generative widget = full prompt round-trip. Acceptable for "show me X" but not for inline UI suggestions. Differentiate use cases.

Decision (Gate 1 — go/no-go for Phase 2)

*ODO*— owner decision after reading this RFC.

Suggested gate criteria:

  • Document KVG schema in Phase 1 (~1 day work).
  • If schema fits + LLM tested can emit reasonable output for 3 trial prompts: proceed Phase 2.
  • If schema doesn't fit or LLM struggles: pivot — close RFC; revisit when KVG matures or alternative tech emerges (e.g., Mermaid for diagrams, Vega-Lite for charts).

Alternatives considered

Alternative Pros Cons
HTML+CSS sandboxed Universal Sandbox complex; XSS risk; LLM error-prone
React via Vercel v0 approach Mature NonKodernative; bundle bloat; doesn't fit Flutter
Mermaid (charts/diagrams only) Already common LLM target Limited to diagrams
Vega-Lite (charts) Excellent for charts Limited to data viz
Custom DSL for generative Tailored Yet another schema to learn
*VG (this RFC)* *lready in stack; declarative; sandbox-trivial* *nproven for generative; may need extension*
  • Ticket umbrella: #120 em meta/docs/stack/backlog/pending/120-ai-generative-ui.md
  • Backing spec (future, dependent on this RFC): meta/docs/stack/specs/ai-ui/generative-ui.kmd
  • KVG SDK: engines/sdk/koder_kit/lib/src/kvg/
  • Refs: Gemini Intelligence 2026, Google research Generative UI 2024, Vercel v0

Source: ../home/koder/dev/koder/meta/docs/stack/rfcs/ai-RFC-001-generative-ui-via-kvg.kmd