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