Un substrato simbólico
para agentes que compongan

Qué es. Una app full-stack con runes (reactividad compilada) servida serverless. 13 páginas de producto (welcome, onboarding, office, briefing, library, activity, outputs, squads, hire, squad-proposal, discover, deep-dive, share — aparte quedan la demo pública, el callback de OAuth y las legales) cada una con su +page.server.ts que carga datos reales del motor — y degrada a contenido de ejemplo etiquetado si el motor no responde.

Para qué sirve. Es la cara del producto: todo lo que el founder ve y toca. Stateless a propósito: no guarda nada, así Vercel puede crear y destruir instancias sin que se pierda estado.

Qué es. Una escena voxel renderizada en el browser: 16 agentes en 3 zonas de squad, 12 escritorios, layout calculado por una función pura (testeada con vitest, sin tocar WebGL).

Para qué sirve. Convierte "tenés agentes trabajando" en algo que se ve. El recap de la oficina ("N shipped · M await review") viene de un endpoint del motor que agrega trazas reales de las últimas 24h.

Qué es. El chat con cada agente. Un parser SSE propio (~60 líneas, puro, testeado) pinta cada fragmento de la respuesta en una burbuja transitoria; al abrir el drawer con sesión vacía, hidrata el hilo persistido en el motor.

Para qué sirve. Conversar con un agente sin proceso esperando: la "continuidad" del agente vive en su memoria (briefing + trabajos + hilo), que el motor arma en el instante del mensaje. Si el stream se corta antes del primer fragmento, degrada al camino clásico con un único retry.

Qué es. La UI de "pedile a Nova": un textarea en lenguaje natural y un modal que muestra el desenlace — match con un SuperSkill existente, plan nuevo compuesto (con costo estimado y pasos en humano), o un "no puedo" honesto. Desde ahí el plan se guarda con nombre propio.

Para qué sirve. El usuario nunca navega un catálogo técnico: pide. Y lo que Nova compone puede promoverse a SuperSkill relanzable desde la library.

Qué es. Un backend-as-a-service que aporta auth.users con perfil JSONB passthrough, más dos tablas propias: user_access (gate booleano de beta privada, fail-closed) y magic_links (tokens CSPRNG de un solo uso, 15 min, consumo atómico con UPDATE … WHERE consumed_at IS NULL).

Para qué sirve. Toda la identidad, separada del substrato por diseño. El estado de la app del usuario (squad, onboarding, SuperSkills instalados) vive en profile.app_state — el perfil ES la base de datos del consumer.

Qué es. El hook de SvelteKit que corre en CADA request del server: lee la cookie httpOnly, renueva el access token con el refresh si expiró (~15 min), y consulta user_access con la service key.

Para qué sirve. Fail-closed de verdad: error leyendo el gate = no autorizado. El bypass para tests E2E existe pero está doblemente gateado (dev && CI) — en build de producción esa rama es código muerto.

Qué es. Login, OAuth de Google y magic links se intercambian en el server (client_type=server), nunca en el browser. Razón: el SDK de browser hace el intercambio PKCE en su constructor y jamás expone el refresh token — sin él, las sesiones morían a los 15 minutos.

Para qué sirve. Sesiones de 30 días con renovación silenciosa, y tokens que viven solo en cookie httpOnly/secure.

Qué es. El único endpoint que escribe app_state: hace read-merge-write del estado completo, re-sanitiza campos con pick explícito (el junk no persiste) y rechaza bodies >64KB. Del lado cliente, una write-queue serializa los POSTs (dos escrituras en vuelo se pisarían) con update optimista y revert compare-and-swap.

Para qué sirve. Multi-dispositivo sin servidor de estado: creás un squad en un browser, lo ves en otro. localStorage queda como cache write-through, con precedencia perfil > cache > derivación.

Qué es. TLS con certificado origin de Cloudflare y un solo site de nginx que proxya 443 → 127.0.0.1:4000 exponiendo únicamente /health, /api/workspaces/*, /api/approvals y /api/intents. El endpoint de Inngest no existe para internet. Para el SSE del chat: proxy_buffering off y read timeout de 120s.

Para qué sirve. Que el motor tenga exactamente la superficie que la app necesita y ni un path más. El puerto 4000 está cerrado al público por firewall; solo loopback y el bridge de Docker llegan.

Qué es. Un token bearer server-to-server comparado en tiempo constante (anti timing-attack), y un rate limiter de ventana deslizante en memoria: chat 10/min, compose 4/min, intents 10/min — montado después del bearer (un 401 no consume cupo), respondiendo 429 con Retry-After.

Para qué sirve. El LLM es el recurso caro; los límites protegen la sesión de un loop accidental o un script ansioso. El browser jamás ve este token: solo la app server-side lo usa.

Qué es. Una sola app HTTP con 10 archivos de ruta: POST /api/intents, POST /api/approvals, y bajo /api/workspaces/:id/ — outputs, activity, brief (GET/PUT), manifest, chat (+history), compose (+launch/discard), superskills (+launch). Corre como unidad systemd con restart on-failure y logs a archivo.

Para qué sirve. Es el único punto de entrada al substrato. Detalle con cicatriz: idleTimeout: 120 en el export del server — el default de Bun (10s) mataba el SSE cuando el modelo razonaba más de 10s en silencio. Lo cazó el manual vivo, no un test unitario.

Qué es. Setenta y tres refs tipadas y versionadas repartidas en 33 dominios (trace.query, claim.recall_decisions, text.compose_brief, video.compose…); son 70 ids, porque tres conviven en dos versiones vivas. El dominio más grande es research, con 17. Todas tienen handler de runtime salvo dos — human_gate.approve y human_task — que no lo tienen a propósito: las ejecuta el propio executor suspendiendo el workflow.

Para qué sirve. La operation es la unidad con contrato (inputs tipados → outputs + costo) y la costura donde se pondría en cuarentena cualquier dependencia volátil — un framework de agentes cabe adentro de una operation; la inversa no.

Qué es. Un Intent declarado se compila a un Plan: DAG topo-sorteado de steps donde cada step referencia una operation del catálogo. Los planes que compone Nova pasan una validación server-side de 4 capas (cada operación existe en el catálogo, el grafo no tiene ciclos — Kahn —, tope de 10 steps, y la aprobación final la agrega el sistema); todo lanzamiento — de fábrica, compuesto o guardado — re-valida contra el catálogo y exige estructuralmente el gate humano terminal. Los evaluators emiten verdicts por paso.

Para qué sirve. Que "el modelo decidió" nunca sea la explicación de una ejecución: lo que corre es un artefacto tipado que el servidor validó, con costo estimado calculado server-side (el modelo no puede mentirlo).

Qué es. Una sola consulta al modelo decide: MATCH (el pedido corresponde a un SuperSkill existente — validado server-side contra la lista real, el modelo no puede inventar ids), COMPOSE (arma un plan nuevo usando SOLO operations del catálogo), o CANNOT (lo dice honesto y el pedido queda registrado como demanda).

Para qué sirve. Es el único lugar del sistema donde el LLM "diseña" — y por eso es el más vigilado: lo que propone entra por su validación de 4 capas y por el mismo gate estructural que todo lo demás. Cada pedido queda en plan_drafts como telemetría: los "no pude" priorizan qué construir.

Qué es. Un plan compuesto que gustó se promueve con nombre propio al catálogo del workspace: se re-valida contra el catálogo ANTES del insert, y un unique parcial en DB hace imposible el doble-promote (gana exactamente uno, el otro recibe 409). El lanzamiento usa un helper compartido con los planes de fábrica: assertHumanGatePresent verifica estructuralmente ≥1 gate humano terminal con fallback 'fail'.

Para qué sirve. Que lo que el usuario crea pidiendo tenga las mismas garantías que lo que construyó el equipo. El formulario de relanzado se deriva mecánicamente de las variables que el propio plan declara.

Qué es. Un adapter propio con dos backends: Claude Code headless por CLI (sesión de suscripción Max — costo marginal $0) y la API oficial como fallback. Para streaming parsea NDJSON línea a línea y emite SOLO text_delta — el razonamiento interno del modelo jamás llega al usuario; la línea result final gana sobre lo acumulado.

Para qué sirve. Separar arquitectura de etapa: la beta corre a costo cero, y como cada paso registra su costo notional en dólares, la economía unitaria del switch a API se conoce HOY ($0.013–0.022 por digest). Prender la API es configuración, no re-arquitectura.

Qué es. El runtime durable self-hosted para eventos, crons y reintentos operativos. handle-intent-declared selecciona v2 y arranca una corrida sobre el grafo compilado; worker-orquestacion da cuerda al worker que consume work_items; los barridos recuperan leases y gates vencidos; materialize-manifest conserva su cron. execute-plan permanece únicamente como executor v1 en deprecación y canario anti-zombie.

Para qué sirve. Inngest hace durable la entrega y el housekeeping, pero ya no es la autoridad sobre el avance del DAG. Esa verdad vive en Postgres: runs + run_events, plegados por el reducer, y la cola transaccional que procesa el worker v2. Un deploy puede interrumpir un tick; no puede borrar lo que la corrida ya decidió.

Qué es. Una instancia dedicada (Docker, :5433) con 77 tablas lógicas y 32 particiones mensuales. Las dos de mayor volumen — traces y step_executions — particionadas por mes. Los embeddings (3072d, text-embedding-3-large) son una columna en claims y artifacts con índice StreamingDiskANN — HNSW topa en 2000 dimensiones, por eso pgvectorscale.

Para qué sirve. Memoria semántica y hechos tipados en el MISMO store: un JOIN entre similitud vectorial y claims estructurados, sin dual-write contra un vector DB externo. La consistencia es gratis porque hay una sola base.

Qué es. La cadena intents → plans (steps, edges) → traces → step_executions → artifacts / claims, más lineage_edges con una vista recursiva (profundidad máx 12, guard de ciclos). Regla dura: todo claim y artifact DEBE tener provenance {trace_id, step_id}.

Para qué sirve. Auditoría nativa: de cualquier afirmación del sistema se puede responder "¿de dónde salió esto?" caminando el grafo — qué trace la emitió, qué step, qué humano la confirmó.

Qué es. Un snapshot navegable por workspace (squad, intents activos, artifacts recientes, decisiones, índice de navegación) materializado cada noche y on-demand por evento. Desde la migración 0006, la columna manifest JSONB es la fuente de verdad.

Para qué sirve. Que un agente arranque sabiendo dónde está parado sin listar media base: lee UN registro. Es cache derivado — se puede reconstruir entero desde el grafo.

Qué es. Stack self-hosted de 6 servicios (web, worker, ClickHouse, MinIO, Redis, Postgres propio) que traza cada llamada LLM con latencia, tokens y costo, correlacionada por trace_id del substrato. Con cicatriz propia: ClickHouse capado a 2 CPUs después de un runaway que clavó 7.7 cores durante 19 horas.

Para qué sirve. Responder "¿qué hizo exactamente el modelo en este paso y cuánto costó?" con un click. El único Redis del sistema vive adentro de este stack — no está en el camino de la app.

Qué es. Dos crons: backup nightly (03:00 UTC, pg_dump gzip a ~/backups/substrate/, retención 30 días, push opcional a R2) y standup digest diario (07:30 UTC, declara un Intent real vía la API pública con bearer — con preflight que verifica la salud del CLI antes de disparar).

Para qué sirve. El backup es la respuesta al dominio de falla catastrófico (RPO ≤24h). El digest es el latido del producto: el sistema se usa a sí mismo todos los días. Los dumps crecen con el sistema: 680K en mayo, 1.8M hoy.

Qué es. Tres anillos: 13.333 tests unit y de integración (4.102 de la app, 9.058 del motor contra Postgres real, 173 del spec), 443 E2E/visuales con Playwright repartidos en 81 archivos (journeys completos + regresión de screenshots), y el anillo exterior — un manual de 34 pasos que un navegador real re-ejecuta contra producción antes de cada demo, con usuario efímero y limpieza quirúrgica del workspace.

Para qué sirve. El anillo exterior caza lo que los internos no ven: el bug del idleTimeout (SSE muerto a los 10s de silencio) pasó todos los tests unitarios y E2E — lo encontró el manual. Si un paso se rompe en producción, su sello deja de decir VERIFICADO.

Qué hacía. execute-plan recorría el Plan, escribía steps y traces, reintentaba operaciones y suspendía el workflow en los gates con step.waitForEvent.

Por qué sale. Su estado efectivo estaba repartido entre el historial de Inngest y las proyecciones del substrato. Reanudar, reconstruir o cambiar el motor exigía entender una ejecución viva, no plegar un log estable.

Qué hace. Compila templates a grafos inmutables, registra cada transición como evento y mueve trabajo mediante una cola con leases. El reducer no hace I/O: declara. aplicar-evento persiste. El worker ejecuta.

Qué conserva Inngest. Entrada durable de eventos, crons, retries operativos y el tick que da cuerda al worker. Inngest sigue en el sistema; dejó de ser el lugar donde se esconde la máquina de estados de una corrida.

Ya no existe un waitForEvent sosteniendo el Plan. El efecto ACTIVAR_GATE crea transaccionalmente un registro en artifact_approval_flows: el entregable aparece para revisión, la persona aprueba y, cuando el protocolo lo requiere, elige una opción; el executor acusa recibo y recién entonces el flow completa.

consumirHandoffV2 aplica la decisión a la corrida y encadena los sucesores. El orden de locks es una invariante, no una recomendación: runs → artifact_approval_flows → work_items. Evita que aprobación, timeout y worker cierren el mismo gate en órdenes incompatibles.

Cada flow congela deadline_at, política de fallback y required_role. El cron barrido-gates-vencidos reclama solamente el estado que observó mediante CAS: state = fase AND deadline_at <= now(). Una aprobación que ganó la carrera no puede ser pisada por el timeout.

El gate no es la única barrera. Un evaluator configurado como bloqueante emite un veredicto hard-stop: si falla, el downstream no se despacha. La corrida no convierte una mala salida en trabajo posterior solamente porque el worker siga vivo.

“Volver a v1” sonaba reversible, pero no lo era. v1 no podía reanudar una corrida v2, no se ejercitaba con tráfico real y ejecutaba el template, no el grafo compilado que v2 había autorizado. Cambiar la bandera no recuperaba una corrida: creaba otra interpretación del trabajo.

Con dos motores, apagar el worker v2 podía parecer una precaución. Con v2 como único motor es un footgun: acepta corridas, deja work_items en ready y nada avanza. Por eso el default ahora es on; apagarlo exige una decisión explícita y observable.