30 KiB

Raw Blame History Unescape Escape

title	type	audience	status	purpose
Eje agéntico de activeUIX — informe para revisión externa	process / informe	evaluadores externos (IAs u humanos) SIN acceso al repositorio	snapshot 2026-07-21 — las decisiones firmadas son vinculantes; las propuestas no	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:

El estado es la única fuente de verdad; el DOM es derivación.
El DOM es el canal universal entre capas (atributos declarados).
Regla 2-de-3: extender el contrato morfo solo se justifica si ≥2 capas lo consumen.
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.
Guard mecánico: cada sistema nace con su verificador automático (lint del contrato CSS, checks por tier, auditoría por componente).
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)

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).
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).
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.)
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.
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).
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)

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?
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ó?
Persistencia y recuperación del run: recarga a mitad de stream, runs huérfanos, audit-trail sin vehículo de almacenamiento decidido.
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?
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

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)?
N1: ¿Run como sustantivo primario — conoces casos reales donde este modelo rompa y Conversation-primero sea estructuralmente necesario?
N2: ¿La máquina estados=verbos es completa? ¿Faltan estados (paused, resuming, degraded, partial-failure)? ¿Es correcto que escalated no sea terminal?
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)?
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?
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?
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?)?
Amenazas §7: para inyección de prompt y TOCTOU en agentes-en-UI, ¿qué patrones concretos de mitigación existen ya en la industria?
Identidad de instancia (§7.4): ¿cómo resuelven otros el direccionado de N instancias del mismo tipo de componente y el presupuesto de contexto?
Referencias: ¿qué framework/protocolo/paper relevante NO está en §8?
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»?
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

30 KiB Raw Blame History Unescape Escape