---
title: Eje agéntico de activeUIX — informe para revisión externa
type: process / informe
audience: evaluadores externos (IAs u humanos) SIN acceso al repositorio
status: snapshot 2026-07-21 — las decisiones firmadas son vinculantes; las propuestas no
purpose: someter el diseño a crítica externa — encontrar lo que se nos escapa
---

# Eje agéntico de activeUIX — informe para revisión externa

## 0 · Propósito y cómo evaluar este informe

Estamos diseñando la **dimensión agéntica** de un ecosistema de componentes UI:
que un agente LLM pueda **ser invocado desde y participar en** cualquier
componente del ecosistema (un editor de documentos, un calendario, un chat, un
formulario), con semántica, permisos, undo y accesibilidad de primera clase.

Este informe es **autocontenido**: no necesitas acceso al código. Contiene el
contexto del ecosistema (§1–§2), la tesis de diseño (§3), las decisiones ya
firmadas (§4), las propuestas en revisión (§5), los defectos que una
auto-crítica adversarial ya encontró y cómo se corrigieron (§6), las amenazas
abiertas (§7), el estado del estudio de referencias (§8) y las preguntas
concretas que te hacemos (§9). Un glosario mínimo cierra el documento (§10).

**Qué te pedimos**: no repitas lo que §6 ya encontró — búscanos lo que está
MÁS ALLÁ. Desafía las tesis (§3, §5), no solo los detalles. Si conoces un
patrón de la industria o un fallo de diseño que este documento no contempla,
eso es exactamente lo que buscamos.

---

## 1 · El ecosistema anfitrión (contexto mínimo suficiente)

**activeUIX** es un sistema de componentes Svelte 5 (headless-first, cero
dependencias externas de runtime) construido sobre un contrato declarativo y
cuatro capas con responsabilidades disjuntas:

- **morfo** — el ADN declarativo de cada componente: partes, atributos
  `data-*`, ARIA, teclado, y **eventos con semántica declarada**
  (familia/intent/verbo). No ejecuta nada. Es el único punto de articulación
  entre capas.
- **soma** — el comportamiento headless. Un runtime interpreta el morfo; el
  *provider* de cada componente aporta estado y handlers. Todo evento pasa por
  `runtime.trigger(evento)`, que secuencia: prewrite → emisión semántica →
  handler → derivación de atributos al DOM por efectos.
- **sema** — el motor perceptivo: un vocabulario canónico (8 familias de
  evento, 6 intents, verbos por familia) y canales de expresión (sonido,
  háptica) más un *stamp* visual transitorio (`data-event-*`) durante una
  ventana («hold»). No conoce el DOM más allá de un proyector inyectado.
- **eidos** — la capa visual: CSS que selecciona exclusivamente contra los
  atributos que el morfo promete. Theming completo (tokens, roles, 33 escalas
  de color, densidad, modo).

Reglas duras del ecosistema relevantes para este diseño:

1. **El estado es la única fuente de verdad; el DOM es derivación.**
2. **El DOM es el canal universal entre capas** (atributos declarados).
3. **Regla 2-de-3**: extender el contrato morfo solo se justifica si ≥2 capas
   lo consumen.
4. **Cero dependencia externa**: el framework implementa lo que necesita
   (tiene posicionamiento propio tipo floating-ui, motor de animación propio,
   i18n propio, validación de esquemas propia, bus de eventos propio…).
   Cuando adopta un protocolo abierto, lo reimplementa con paridad verificada.
5. **Guard mecánico**: cada sistema nace con su verificador automático
   (lint del contrato CSS, checks por tier, auditoría por componente).
6. **Nada destructivo corre por defecto sin registro explícito.**

Además de las capas, el ecosistema tiene **arts** (artefactos de runtime
inyectables): `bus` (eventos tipados), `orca` (orquestación declarativa de
acciones sobre eventos, con dependencias, transacciones y compensación LIFO),
`sium` (esquemas de validación, interop Standard Schema), `perm` (autorización
server-authoritative con guard `<Can/>`), `session`/`auth`, `http`,
`connection` (realtime websocket), `storage`, `prefs` (preferencias:
intención de usuario × entorno × valor efectivo), `motion`, `scene` (efectos
ambient WebGL), `adom` (DOM reactivo), `timer`, `logger`. Convención:
`Engine*` = núcleo puro sin estado reactivo; `Active*` = envoltorio reactivo.
Los arts NUNCA importan de las capas UIX; cuando necesitan algo del DOM u
otra capa, reciben un **puerto estructural** inyectado.

Sobre las capas hay **tiers**: *canon* (componentes con contrato completo, ~110),
*packs* (decoración hoja opt-in), *blocks* (composiciones de función de página).
Regla de admisión: todo lo que tenga superficie de contrato se construye en el
canon ANTES de que un tier lo componga.

Los **ejes ortogonales** existentes (sonido, idioma, tema, motion) siguen todos
el mismo patrón: un motor (art o capa) + un módulo por componente
(`sema/components/{x}.ts`, `langs/components/{x}.ts`…) + cableado en la raíz
de composición + vocabulario en el canon + guard mecánico. **El eje agéntico
debe instanciar este patrón, no inventar otro.**

---

## 2 · El fundamento semántico ya existente: la familia `delegate`

El vocabulario semántico del ecosistema proviene de un libro de diseño propio
(«Diseñando lo que ocurre»). Su 8ª familia, **`delegate`**, responde a la
pregunta perceptiva **«¿quién actúa ahora?»** y define el ciclo de vida
completo de una delegación:

```
delegate.offer      → el sistema ofrece encargarse de algo
delegate.plan       → el sistema propone un plan o curso de acción
delegate.authorize  → el usuario concede permiso o alcance
delegate.act        → el sistema actúa por el usuario
delegate.review     → el sistema espera revisión antes de aplicar
delegate.escalate   → el sistema pide intervención humana
delegate.return     → el control vuelve al usuario
```

Doctrina clave del libro (cap. 29): **no es una familia de IA** (macros,
reglas, workflows y aprobaciones también delegan); no tiene intent (tono
evaluativo) por defecto — el intent aparece en el RESULTADO que la acción
delegada produce; y los riesgos de diseño canónicos son: no distinguir
sugerencia/plan/autorización/ejecución, no explicitar alcance, no ofrecer
cancelación, no dejar claro cuándo vuelve el control.

La secuencia canónica del «sistema que propone y aplica cambios» (Apéndice C
del libro) es literal:

```
delegate.plan → signal.warn+risk → delegate.review → delegate.authorize
→ delegate.act → sustain.processing → commit.apply+affirm
```

Estado en el código: la familia está declarada (tipos, verbos, política de
intent, holds) pero **ningún componente la emite todavía** — es la única
familia sin materializar. Existen tres reservas previas firmadas: `Aura`
(componente canónico futuro: indicador visual de agente activo, materializa
`delegate`+`sustain`), «delegate-family ↔ agent chat» (sobre la familia de
componentes de chat ya construida), y «soporte agentivo» en `palabras` (el
editor de documentos por bloques — un agente rellena contenido).

---

## 3 · La tesis de diseño

> **No es un componente; es un eje.** Un componente-agente monolítico que
> conociera a cada componente invertiría la dirección de dependencias. El eje
> se descompone como los demás ejes ortogonales: un **motor** (art `$agent`) +
> un **contrato de participación por componente** (manifiesto de capacidades)
> + un **registro en runtime** + unas pocas **superficies UI** propias
> (indicador de presencia, tarjeta de revisión, panel copiloto).

La regla de oro (versión corregida tras la auto-crítica):

> El agente actúa a través de la **misma API pública** del provider que usaría
> el código de la aplicación — la ruta de llamada no se bifurca. Pero la
> **concreción semántica depende del actor**: los eventos del componente
> declaran capacidad `delegate` (mecanismo de eventos polimórficos ya
> sancionado en el contrato morfo, `allowedFamilies`) y el provider concreta
> `{family:'delegate', verb:'act'}` cuando la invocación llega con contexto de
> actor agente. Así sema suena, eidos pinta y la accesibilidad anuncia — con
> la respuesta correcta a «¿quién actúa?». Si una capacidad necesita una
> puerta que la API pública no tiene, esa puerta se promociona al componente;
> nunca se bifurca la cadena.

---

## 4 · Decisiones FIRMADAS (vinculantes)

### D-AG.1 — Nombre y hogar del motor

| Sub | Decisión | Rationale |
| --- | --- | --- |
| 1a | Arte **`agent`** (alias `$agent`), `EngineAgent` (núcleo puro) + `ActiveAgent` (reactivo, contrato estándar `ActiveEngine`) | Convención descriptiva de la mayoría de arts; los nombres propios se reservan a piezas de rol abstracto |
| 1b | **Factory feature-scoped a nivel app** (`defineActiveAgent(...)`, patrón de auth/session/perm: construcción explícita en la aplicación). Nada en la superficie UIX en v1; promoción futura a accessor `uix.agent` cuando exista consumidor canónico | El agente no es core; precedente firmado del motor de escenas (factory primero, promoción después); la raíz UIX standalone no puede construir sus dependencias |
| 1c | **Adaptadores de proveedor LLM en `$agent/adapters/*` fuera del barrel principal** (quien no los importa no los paga — precedente `$logger/adapters`). Un **transporte determinista scriptado** es ciudadano de primera clase (tests sin mocks, demos estáticas) | Resuelve la tensión zero-dependence ↔ proveedor: el motor solo conoce el puerto estructural `AgentTransport`; los formatos provider-shaped viven en adaptadores opcionales |

### D-AG.2 — Protocolo de transporte y eventos

| Sub | Decisión | Rationale |
| --- | --- | --- |
| 2a | **Protocolo de eventos PROPIO, espejo de la taxonomía AG-UI**: 5 categorías — ciclo de run · deltas de mensaje · tool-calls (args en streaming + resultado) · estado · custom. Nombres alineados con el canon semántico donde corresponda. AG-UI queda como *baseline de paridad* (mismo patrón que se usó con floating-ui) | El protocolo ES el contrato; el transporte es fontanería. Espejo propio da libertad de vocabulario manteniendo verificabilidad contra el estándar de facto |
| 2b | **El streaming lo posee cada adaptador** (fetch + ReadableStream/SSE parseado localmente). Los arts `http` y `connection` quedan intactos | El cliente HTTP del ecosistema no tiene streaming hoy; dárselo es una iniciativa colateral que no debe gatear este track |
| 2c | **Estado como snapshot-por-turno en v1**: los `reads` viajan como snapshot al abrir cada turno. La categoría snapshot/delta queda **reservada tipada** en el wire; los deltas (JSON Patch) llegan con la generalización sin romper el protocolo | Evita maquinaria de sincronización sin consumidor, sin pintarse en una esquina |

---

## 5 · Decisiones PROPUESTAS (en revisión — desafíalas)

### N1 · El sustantivo primario es el Run

Un **Run** = una delegación completa gobernada por el ciclo `delegate`
(principio, presupuesto, resultado, devolución de control). La
**Conversation** es una superficie que *encadena* runs — el chat es un
consumidor del agente, no su núcleo. Permite agentes sin chat (el caso
«rellena mi documento» es un run sin conversación).

```
Conversation (opcional)
 └── Run (la unidad primaria)
      ├── Turn (un intercambio con el modelo)
      │    └── CapabilityCall (un delegate.act sobre un componente)
      └── Context (snapshot de reads al abrir el turno)
```

### N2 · La máquina de estados del run = los verbos delegate, literal

```
                    ┌─────────── escalated ──────────┐
                    ▼                                │
offered → planned → reviewing → authorized → acting ─┤
   │         │    (opcional por  (siempre,    │      ▼
   │         │     política)     aunque auto) ▼   returned  ← control SIEMPRE vuelve
   └─────────┴──── cancelled ─────────────────────────┘
```

- `review` es opcional por política (N5); `authorize` existe siempre, aunque
  sea automático — la transición queda registrada aunque no haya UI.
- `returned` es el único cierre sano («todo proceso abierto necesita salida»);
  `escalated` no es terminal — espera humana que desemboca en continuar o
  cancelar.
- **Interrupción del usuario = `return` inmediato, nunca un error.**
- Cada transición emite su semántica (N6): el estado del run es observable
  perceptualmente, no solo un enum.

### N3 · El tool-loop

Vive en `EngineAgent`, en cliente, v1 (consecuencia de D-AG.1c/2b). Acts
**secuenciales** (el paralelismo complica undo y narración perceptiva sin
consumidor que lo pida). Fallos tipados → verbos: recuperable→reintento
acotado · alcance-insuficiente→`escalate` · abortado→`return`.
**Presupuestos de primera clase**: máx. acts por run, máx. turns, timeout,
`AbortSignal` inyectado en cada capacidad; agotamiento → `escalate`
automático, jamás silencio. (Verificado: los guards de re-entrada del
orquestador del ecosistema NO alcanzan un loop que se origina fuera del bus —
el presupuesto debe ser del motor.)

### N4 · Elicitación (el agente pregunta a mitad de run)

El agente suspende, hace una pregunta **tipada** (esquema sium de la respuesta
esperada) y reanuda con la respuesta. Modelada dentro de `escalated`, con dos
salidas: respuesta → continúa · silencio/cancelar → `returned`. En v1 entra
como categoría reservada del protocolo; se materializa con la superficie de
conversación. Sinergia propia del ecosistema: el generador de formularios por
esquema puede auto-renderizar la pregunta.

### N5 · Autonomía: la política del agente

| Nivel | Ciclo efectivo |
| --- | --- |
| `suggest` | offered → planned → *(fin: solo propone)* |
| `review` | … → reviewing → authorized → acting (default recomendado) |
| `auto` | … → authorized(auto) → acting — **solo capacidades reversibles** |

Resolución estilo prefs: la app fija el techo, el usuario ajusta por debajo,
la capacidad puede exigir MÁS control (nunca menos). Deny-overrides.
**Irreversible ⇒ review siempre, no negociable.**

### N6 · Semántica del run (quién emite qué)

- El **motor no emite nada** (es un art; no conoce el DOM). Expone el run como
  estado reactivo observable.
- Las **superficies del agente** (Aura, review-card, conversación) declaran en
  SUS contratos morfo los eventos del ciclo (`delegate-offer/plan/review/
  authorize/escalate/return`); `sustain-processing` pertenece a Aura con
  persistencia ligada al estado del run.
- Los **componentes actuados** concretan `{family:'delegate', verb:'act'}` en
  sus eventos existentes vía eventos polimórficos, cuando la invocación llega
  con **contexto de actor** (`actor:'agent'` + id de run en cada
  CapabilityCall — contrato del motor).

### N7 · Identidad del agente

Multi-instancia por construcción (la factory lo da gratis), **singleton por
convención en v1**. Cada instancia lleva `identity` (nombre + descripción, que
el modelo necesita como system-context). Ningún «registro de agentes» hasta
que exista el segundo.

### N8 · Memoria

v1: `ActiveAgent` posee conversación/runs **en memoria** (snapshot()).
Un refresh mata el run en curso → `returned` con huella (los acts aplicados
persisten en el componente; no hay corrupción porque los acts son
transaccionales del lado del componente). Persistencia (historial entre
sesiones, audit-trail) = adapter de storage opcional, **diferida con hueco
declarado**. Restricción conocida: el orquestador del ecosistema prohíbe ser
store — el audit-trail necesita vehículo propio o no existe.

### D-AG.3 (abierta) · El contrato de capacidades — la bisagra motor↔componentes

| Sub | Recomendación (no firmada) | Alternativas |
| --- | --- | --- |
| 3a | Contrato **estructural en el arte**: `AgentCapability`/`AgentRead` (ids string, args Standard-Schema, handler opaco — patrón puerto). Los manifiestos del lado UIX lo satisfacen tipando contra la API del provider | Registro entero del lado UIX con el arte ciego · manifiesto dentro del morfo (descartado: viola 2-de-3) |
| 3b | **Emisor sium→JSON Schema** + `description` obligatoria por read/act/arg | Backend consume la forma propietaria del validador · JSON Schema a mano (drift) |
| 3c | Registro **por instancia con id estable** + predicado reactivo `available` por act + evento capabilities-changed entre turnos | Estático por montaje · mono-instancia v1 (colapsa con dos editores) |
| 3d | **Resultado tipado (sium)** + clases de fallo mapeadas a verbos (retry/escalate/return) | Texto libre · ok/fail binario |

### Cola restante (aún sin proponer en detalle)

Superficies propias (Aura · review-card con su socio obligatorio
`signal.warn+risk` · panel copiloto como block · slot de actividad de tool en
el chat) · doctrina de amenazas (§7) · secuencia de fases del track ·
**delegado al track del editor**: los 4 ejes de su integración (formato que
emite el agente · one-shot vs streaming · por dónde entra · alcance de
escritura) y la provenance en su modelo de documento.

---

## 6 · Lo que la auto-crítica adversarial ya encontró (no lo repitas — supéralo)

Sometimos la propuesta v1 a un panel adversarial (7 lentes, 43 agentes, cada
hallazgo verificado contra el repositorio intentando refutarlo): 34
confirmados (6 críticos), 4 refutados. **Las correcciones ya están integradas
en §3–§5.** Resumen de lo confirmado, por tema:

**Críticos (corregidos en el diseño actual)**
1. La emisión `delegate` no tenía dueño (la «regla de oro» original era
   contradictoria) → resuelto con eventos polimórficos + contexto de actor (N6).
2. El registro de providers al montar invertía la dirección de dependencias
   (canon → eje opcional) → manifiestos como datos estáticos + binding de
   instancia sin conocimiento provider→agente (D-AG.3a/3c).
3. La provenance «persistente» como atributo DOM no puede persistir (el DOM es
   derivación) → provenance = campo del modelo de contenido; el atributo es
   pintura derivada. (Delegado al track del editor.)
4. Usar el orquestador como ejecutor violaba su invariante («los artefactos no
   consumen orca; solo la app registra acciones») → ruta por defecto: llamada
   directa a la API del provider; orquestación reservada a cadenas
   multi-componente registradas por la app.
5. Sin política de concurrencia usuario↔agente (el streaming roba el caret y
   destruye el redo del editor) → política pendiente de detallar en el track
   del editor; primitivas del motor: pausa/abort/return (N3).
6. La secuencia construía el framework genérico antes que el piloto y
   pre-firmaba decisiones ajenas → v1 mínimo, generalización al 2º consumidor.

**Mayores (agrupados)**: APIs programáticas del editor semánticamente mudas
(no emiten eventos — hay que promocionarlas); el «pack sema por familia» no
existe como concepto (el carácter es por-evento/por-componente); `perm` es
error de categoría para capacidades cliente-locales (split: consentimiento
local × perm solo para scopes de servidor); compensación del orquestador ≠
undo de usuario (la reversión la da la historia nativa del componente); un
run debe ser UN paso de undo (falta puerta transaccional pública en el
editor); sin presupuestos anti-runaway (→ N3); vocabulario de scopes
indefinido y sin guard que audite la veracidad del manifiesto; falta la fila
de degradación («con agente ausente, todo funciona al 100%»); `reads` sin
doctrina de consentimiento (contenido del usuario viaja al LLM); sin
transporte determinista (→ D-AG.1c); coste del streaming sin medir; a11y sin
resolver (anuncios de acciones del agente; el indicador visual no puede
desaparecer bajo reduced-motion); exposición prematura en la raíz UIX (→
D-AG.1b); backend server-authoritative contradecía una decisión previa («el
transporte es de la app») → transporte app-land (D-AG.1c/2b); ningún guard
mecánico en el plan (pendiente de la secuencia).

**Refutados** (el diseño original resistió): la lectura de la regla 2-de-3
para el atributo de provenance; la ruta de acceso del indicador Aura a su
motor de efectos (ya estaba firmada); el orden de fases de Aura; la
preocupación por targets DOM en la emisión.

---

## 7 · Amenazas identificadas y AÚN SIN RESOLVER (aquí queremos tu mejor crítica)

1. **Inyección de prompt**: los `reads` inyectan al modelo contenido no
   autorado por el usuario (documentos importados, mensajes de otros
   participantes, texto pegado) y la salida del modelo se convierte en `acts`.
   No hay modelo de amenaza: ¿etiquetado de origen del contexto? ¿gating de
   acts cuando el contexto contiene material no confiable? ¿qué hacen bien
   otros?
2. **TOCTOU**: nada liga el plan revisado al estado sobre el que `act`
   ejecuta. Entre review y act el documento puede cambiar (el propio usuario,
   otro run). ¿Fingerprint/versión del estado en la autorización? ¿re-review
   automático si el estado derivó?
3. **Persistencia y recuperación del run**: recarga a mitad de stream, runs
   huérfanos, audit-trail sin vehículo de almacenamiento decidido.
4. **Identidad de instancia y ensamblaje de contexto a escala**: con decenas
   de componentes montados (el caso formulario), ¿qué reads entran en el
   prompt, con qué presupuesto de tokens, y cómo direcciona el modelo la
   instancia concreta?
5. **La costura con el proveedor LLM**: resuelta estructuralmente (adaptadores
   fuera del barrel), pero sin diseñar los adaptadores concretos ni la
   estrategia de paridad entre proveedores (formatos de tool-call divergen).

---

## 8 · Referencias externas

Dos pasadas de investigación web sobre fuentes primarias. **Nota de método**:
la segunda pasada extrajo 25 claims citados de documentación oficial, pero su
fase de verificación adversarial falló por límite de infraestructura — los
marcamos «(sin verificar)»; todos citan fuente primaria.

### 8.1 · Convergencias de la primera pasada (moldearon las decisiones §4–§5)

- **Taxonomía de eventos de protocolo** (AG-UI como formalización más limpia)
  → D-AG.2a. · **Frontend tool calling** como contrato más load-bearing
  (CopilotKit `useCopilotAction`, Vercel AI SDK tools, MCP tools) → D-AG.3.
- **Registro de contexto legible** (CopilotKit `useCopilotReadable`) → los
  `reads`. · **HITL en dos formas** (aprobación previa + interrupción tipada
  a mitad de run — LangGraph interrupts, MCP elicitation) → N4.
- **Generative UI** (actividad de tools en el transcript) — hueco reconocido
  en nuestra superficie de chat. · **Proyección model-facing**
  (descripciones + JSON Schema) → D-AG.3b.

### 8.2 · Hallazgos de la pasada profunda (sin verificar; fuente primaria citada)

**AG-UI** (docs.ag-ui.com — CopilotKit es su autor; afirma adopción de
Google/LangChain/AWS/Microsoft/Mastra/PydanticAI → candidato a estándar de
facto):
- **17 tipos de evento en 5 categorías**: 5 de ciclo de run
  (RUN_STARTED/FINISHED/ERROR, STEP_STARTED/FINISHED), 3 de texto
  (TEXT_MESSAGE_START/CONTENT/END), 4 de tool-calls
  (TOOL_CALL_START/ARGS/END/RESULT), 3 de estado (STATE_SNAPSHOT,
  STATE_DELTA, MESSAGES_SNAPSHOT), 2 especiales (RAW, CUSTOM). → Nuestro
  baseline de paridad para D-AG.2a ya tiene lista concreta.
- Patrón triple **start/content/end** para todo streaming; los args de tool
  llegan como deltas de JSON parcial (permite pintar la actividad mientras el
  modelo aún genera).
- Estado: **snapshot + delta JSON Patch (RFC 6902)**, aplicación secuencial, y
  **resincronización por re-snapshot** (no por replay de eventos) — valida
  nuestra D-AG.2c (snapshot primero, delta reservado).
- **Tools frontend se declaran por-run** (`RunAgentInput.tools`, campo
  reservado a tools del cliente) y el resultado vuelve como **mensaje
  `role:'tool'`** en el historial — el roundtrip se cierra por la vía de
  mensajes, no por canal aparte. → Informa el mapeo wire de D-AG.3d.
- **DESAFÍA N2/N4**: AG-UI modela el HITL como *caso particular de frontend
  tool calling* (una «confirmation tool» que el frontend renderiza y cuya
  decisión vuelve como resultado) — **no tiene primitiva de protocolo para
  aprobaciones**; los interrupts se reanudan iniciando un run nuevo con un
  array `resume`. Nosotros elevamos review/authorize/escalate a estados
  observables del run porque nuestra semántica (`delegate`) lo exige. Es una
  divergencia deliberada — pregunta 3/12 al evaluador.

**CopilotKit** (docs.copilotkit.ai):
- `useCopilotReadable`: pares **descripción-natural + valor**, composición
  **jerárquica** (parentId refleja el árbol de componentes), **gating
  por-readable** (`available: enabled|disabled`), serialización custom
  (`convert`) y `categories`. → Valida D-AG.3b/3c; la jerarquía padre-hijo de
  contexto es una idea que NO teníamos (candidata para el ensamblaje de
  contexto de §7.4).
- Plataformas: React/Next GA, Angular/Vue/React-Native, **Svelte ausente** —
  evidencia directa del hueco de oportunidad.

**MCP Apps (SEP-1865, estatus Final)** (modelcontextprotocol.io):
- UI embebida como **recursos `ui://` predeclarados** referenciados por tools;
  comunicación iframe↔host **reutilizando JSON-RPC de MCP** (rechazado el
  «objeto API global» inyectado); **sandboxing obligatorio** + mensajería
  auditable; y **el HOST controla la autorización** de tool-calls iniciadas
  desde la UI (no el servidor ni la UI). → Alinea con N5 («la app fija el
  techo») y aporta doctrina de seguridad para superficies embebidas.

### 8.3 · Huecos que nadie cubre bien (oportunidades)

**Semántica perceptiva de la delegación** (familia `delegate` +
sonido/motion/hold — nadie tiene un equivalente), **undo transaccional de un
run**, **accesibilidad de acciones de agente** (anuncios de «quién actúa»,
reduced-motion del indicador), **provenance de contenido** como doctrina, y
**ecosistema Svelte-nativo** (vacío confirmado en la referencia principal).

*(Pendiente: re-verificación adversarial de los claims 8.2 y fichas de
Vercel AI SDK/AI Elements, assistant-ui, OpenAI Apps SDK/ChatKit, LangGraph,
generative-UI y kits headless — la pasada profunda cubrió a fondo
AG-UI/CopilotKit/MCP Apps antes del fallo de infraestructura.)*

---

## 9 · Preguntas concretas al evaluador

1. **La tesis** (§3): ¿«eje con motor propio» es el modelo correcto, o hay uno
   superior (p. ej. protocolo puro sin motor, agente 100% backend con la UI
   como terminal tonto, o UI generada dinámicamente sin manifiestos)?
2. **N1**: ¿Run como sustantivo primario — conoces casos reales donde este
   modelo rompa y Conversation-primero sea estructuralmente necesario?
3. **N2**: ¿La máquina estados=verbos es completa? ¿Faltan estados (paused,
   resuming, degraded, partial-failure)? ¿Es correcto que `escalated` no sea
   terminal?
4. **N3**: ¿Loop en cliente v1 — qué riesgos reales (seguridad, consistencia,
   coste) vs loop en servidor? ¿Qué presupuesto falta (rate, coste en tokens,
   sandboxing de args)?
5. **N5**: ¿El modelo de autonomía de 3 niveles con deny-overrides tiene
   agujeros conocidos? ¿Cómo manejan otros la escalada de privilegios
   mid-conversation?
6. **N6**: ¿La concreción semántica por actor (mismo evento, familia
   polimórfica) tiene agujeros — p. ej. acts que disparan cascadas de eventos
   secundarios, o composiciones donde el actor se pierde?
7. **D-AG.2c**: ¿Snapshot-por-turno es suficiente en la práctica, o los deltas
   de estado son imprescindibles antes de lo que creemos (¿casos límite de
   staleness?)?
8. **Amenazas §7**: para inyección de prompt y TOCTOU en agentes-en-UI, ¿qué
   patrones concretos de mitigación existen ya en la industria?
9. **Identidad de instancia** (§7.4): ¿cómo resuelven otros el direccionado de
   N instancias del mismo tipo de componente y el presupuesto de contexto?
10. **Referencias**: ¿qué framework/protocolo/paper relevante NO está en §8?
11. **A11y**: ¿qué exige (o exigirá) WCAG/ARIA para acciones autónomas de
    agente en la UI? ¿Hay precedente de anuncios de «quién actúa»?
12. **Lo que no preguntamos**: ¿qué pregunta deberíamos estar haciendo y no
    está en esta lista?

---

## 10 · Glosario mínimo

| Término | Significado |
| --- | --- |
| morfo / soma / sema / eidos | Las 4 capas: contrato declarativo / comportamiento headless / semántica perceptiva / visual |
| provider | La clase soma que da vida a un componente (estado + handlers) |
| `runtime.trigger(e)` | La única vía de disparo de eventos declarados: prewrite → emisión semántica → handler → derivación DOM |
| familia / intent / verbo | Clasificación semántica canónica de todo evento (8 familias · 6 intents · verbos por familia) |
| `delegate` | La familia del reparto de acción («¿quién actúa ahora?») — §2 |
| eventos polimórficos (`allowedFamilies`) | Mecanismo morfo por el que un evento declara varias familias posibles y el provider concreta cuál en runtime |
| hold / stamp | Ventana perceptiva en la que sema estampa `data-event-*` en el DOM y eidos reacciona |
| arts | Artefactos de runtime inyectables (bus, orca, sium, perm, http, storage, prefs…) |
| orca | Orquestador declarativo: acciones sobre eventos del bus, con transacciones y compensación — solo la APP registra acciones |
| sium | Motor de esquemas/validación propio (interop Standard Schema) |
| prefs | Preferencias: intención de usuario × entorno × valor efectivo |
| tier canon / packs / blocks | Componentes con contrato / decoración opt-in / composiciones de página |
| Aura | Componente canónico reservado: indicador visual de agente activo (materializa delegate+sustain) |
| palabras | El editor de documentos por bloques del ecosistema (primer consumidor del eje) |
| manifiesto agéntico | El contrato de participación de un componente: `reads` (estado legible) + `acts` (capacidades tipadas) |
| Run / Turn / CapabilityCall | Unidad de delegación / intercambio con el modelo / invocación de una capacidad |