REGISTRO DE DESARROLLO

Un camino que aún no está terminado

De v0.1 a v0.5.22: 156 días, 116 versiones. Esto no es una lista de funciones, sino los errores que cometimos, las reglas que ganamos y los huecos que aún no hemos llenado.

156 días: desde la primera versión
116: versiones
9: instantáneas de arquitectura
20+: comprobaciones de arquitectura

Instantánea de datos 2026-11-01 · cifras recogidas del repositorio de Liri por sync-facts y health:arch

Ir a la línea de tiempo

Origen

El 25 de mayo de 2026, Liri publicó la v0.1: 100 commits y un asistente de IA de terminal que funcionaba de verdad.

El problema era concreto: que el modelo estuviera de verdad en la terminal, leyera archivos, ejecutara comandos y editara código, en lugar de limitarse a conversar en un cuadro de texto web. Optamos por los modelos locales primero porque no queríamos enviar archivos privados al servidor de otro; optamos por la «seguridad integrada» porque recibe un ordenador real, no solo una API.

Durante los tres meses siguientes añadimos capacidades capa a capa: herramientas, 27 canales de mensajería, un cliente de escritorio, voz, una base de conocimiento. En agosto el repositorio ya tenía más de 4.000 archivos.

Fue también entonces cuando el problema se nombró en voz alta. La revisión de código del 18 de junio de 2026 encontró LocalHTTPService con 7.200 líneas y ChatManager con 3.263, con 150 archivos de prueba frente a 3.742 de código. Dos meses después llegó la primera puntuación de salud de la arquitectura: 10/40, nota D, con 105 archivos sobredimensionados y ninguno registrado.

La lección: que un proyecto pueda pasar a manos de otra persona no depende de cuántas funciones tenga, sino de las reglas que surgen después de chocar contra un muro.

Cinco puntos de inflexión

Ordenados por causa, no por calendario: algunos periodos se solapan.

2026-05-25 → 2026-08

Primero la capacidad, después los límites

Situación: La v0.1 tenía 100 commits; publicar importaba más que la estructura.
Decisión: Llenar primero la capacidad: herramientas, canales, escritorio, voz, conocimiento, uno a uno.
Coste: La primera auditoría fue fea: LocalHTTPService con 7.200 líneas, ChatManager con 3.263, una proporción de pruebas sobre código de alrededor del 4% y una primera puntuación de salud de 10/40 (D), con 105 archivos sobredimensionados sin registrar.
Resultado: Más de 4.000 archivos, 69 herramientas, 27 canales, 429 componentes de escritorio.

Evidencia CHANGELOG v0.1 Revisión de código, 18 jun 2026

↳ Cómo participar — ¿Quieres añadir una capacidad? Crea un módulo en app/src, no dentro del núcleo.

2026-08-09 → 2026-09-30

Aprender a medirnos

Situación: Todo el mundo notaba el problema; nadie sabía decir cuánto de grave era.
Decisión: Convertir la calidad de la arquitectura en una puntuación repetible con un registro y exigir que cada archivo sobredimensionado quedara registrado; renunciamos a la suposición de que la limpieza se sostiene solo con disciplina.
Coste: Registrar no es dividir: ChatManager pasó de 3.263 a 7.036 líneas (desde entonces se ha dividido hasta 2,570). La propia forma de puntuar seguía cambiando, así que sirve como chequeo de salud, no como KPI.
Resultado: Nueve instantáneas; los archivos sobredimensionados sin registrar bajaron de 105 a 0 (luego volvieron a 2); la lista pasó a ser un registro trazable.

Evidencia architecture-health-history.json architecture-health.ts

↳ Cómo participar — Reclama un archivo sobredimensionado para dividirlo (ver Formas de ayudar más abajo).

2026-10-08 → 10-09

Un borrado equivocado nos dio un proceso de borrado

Situación: El código había acumulado una capa de «superficies muertas» que parecían no usarse. La limpieza de la v0.4.69 trató el subsistema de sandbox y aislamiento como código muerto: 170 archivos tocados, +9.340 / −10.174 líneas.
Decisión: Al día siguiente, la v0.4.71 lo revirtió todo: 24 archivos restaurados (IsolationManager, EnhancedSandboxManager, PTYSandbox, SSHSandbox, docker/** y más, además de 5 suites de pruebas) y 21 archivos vivos devueltos a su estado anterior.
Coste: Borrar ahora lleva más tiempo: primero se escribe la evidencia. Aun así sale más barato que una reversión.
Resultado: La v0.4.72 convirtió el borrado en un proceso, code-deletion.md (CD01–CD07): reunir evidencia, desenganchar los puntos de entrada y luego borrar. «Parece que nadie lo usa» dejó de ser un motivo.

Evidencia CHANGELOG v0.4.69 / v0.4.71 / v0.4.72

↳ Cómo participar — Revisa un «candidato a código muerto» según CD01–CD07.

2026-10-10 → 10-22

Convertir las reglas en puertas

Situación: Las reglas vivían en documentos y dependían de la disciplina; los documentos y el código empezaron a divergir.
Decisión: Cada regla se convirtió en un bloqueo de CI en lugar de una recomendación: cinco puertas más doc-gate y un job obligatorio sandbox-negative; 413 claves de línea base de valores codificados; un vocabulario de estados de 34 valores con 1.795 pares de línea base; puertas de superficie de arranque, módulos críticos y superficie del núcleo.
Coste: Unos segundos por commit, y hay que regenerar las líneas base con cada cambio de vocabulario: precisamente para que las definiciones ya no puedan divergir en silencio.
Resultado: Violaciones de lint:arch en 0; las pruebas pasaron de 3.029 a 7.488.

Evidencia AGENTS.md: lista de puertas Flujo de trabajo de CI

↳ Cómo participar — Ejecuta las puertas locales (bun run ci) antes de subir cambios y arregla lo que se ponga en rojo.

2026-10-05 → 10-28

Encoger el núcleo: de 5.336 líneas a un paquete propio

Situación: El core era a la vez la implementación de entrada y el patio común de todas las capacidades: cualquiera podía añadirle cosas.
Decisión: Tres pasos: encoger (CoreAPIImpl de 5.336 a 2.521 líneas), extraer (@openliri/kernel como paquete propio; core de 146 a 113 archivos con las puertas de núcleo K01–K08) y después desalojar (37 módulos que incumplían la regla de «cero E/S / cero dependencias hacia arriba» bajaron a app/src, con más de 470 imports actualizados y cinco familias de líneas base regeneradas).
Coste: Una migración grande y la regeneración completa de las líneas base; desde el 18 de octubre el trabajo llega por lotes y la densidad de commits baja a propósito.
Resultado: El núcleo ahora expone una interfaz fina; las contribuciones externas tienen por fin un límite claro.

Evidencia CHANGELOG v0.5.22

↳ Cómo participar — Las nuevas capacidades viven fuera del límite del núcleo y empiezan en app/src.

Arquitectura: por capas, como un sistema operativo

La arquitectura no se inventó desde cero. El núcleo fino, los límites entre subsistemas, la dirección única de las dependencias, las puertas y la observabilidad vienen de décadas de práctica en sistemas operativos; las guías de patrones de diseño e ingeniería publicadas para agentes en los últimos dos años coinciden en las mismas preguntas: capas, límites, estado, gobernanza y evaluación. Nos limitamos con lo primero y nos auditamos con lo segundo.

Concepto de sistema operativo → dónde está Liri

Concepto	En Liri	Estado
Núcleo	@openliri/kernel como paquete propio con una interfaz pública fina, protegido por K01–K08	Implementado
Subsistemas	Herramientas / canales / memoria / enrutamiento / sandbox / tareas / voz / escritorio, cada uno con sus puntos de entrada y límites	Convergiendo
Drivers	Adaptadores de proveedor, adaptadores de canal y 6 backends de sandbox (Landlock / Docker / SSH / PTY / macOS / Windows)	Implementado
Procesos y planificación	Ejecución de sesiones, PDCA, Swarm, Cron	Implementado
Modelo de permisos	Cinco capas de defensa más cuatro etapas de aprobación (requested → presented → decided → recorded)	Pendiente de auditoría
Observabilidad y auditoría	Registro de eventos, libro de costes, registro de evidencias	Implementado
Mantenedores	Aún no establecidos: no hay responsables por subsistema ni una vía de traspaso	Sin cubrir

Con qué nos comparamos

Nos comparamos punto por punto con los patrones de diseño de agentes y las guías de ingeniería públicas: los 21 patrones tienen implementación real, pero 3 de los interruptores clave están desactivados por defecto, así que solo decimos «implementado», nunca «activo por defecto». El ciclo de ingeniería se audita igual: arquitectura, compilación, ejecución, gobernanza y optimización.

Tres huecos

Mantenedores por subsistema

Sin responsables no hay vía de traspaso. Es la pieza más parecida a un sistema operativo y la que nos falta.

Contratos de subsistema

El diseño de contratos existe, pero no está verificado si el registro / LoopProfile llegó a implementarse: la promesa de estabilidad de las interfaces aún no está fijada.

Puerta de cobertura

Alrededor del 4% en el momento de la revisión; la CI ejecuta más de 20 comprobaciones de arquitectura, pero aún no hay umbral de cobertura.

Para ser honestos: la salud de la arquitectura sigue en D (10/40); de 142 archivos sobredimensionados, 141 siguen sin registrar, y el mayor sigue en chat (ChatManager se ha dividido de 7.036 a 2,570 líneas). El núcleo existe, los límites están convergiendo y los mantenedores aún no existen: eso es lo que significa «no está terminado».

Desplegar las 8 capas funcionales actuales

Arquitectura de un vistazo

8 capas funcionales del punto de entrada a la retroalimentación; en ingeniería las imponen 6 puertas de dependencia (entry > ui > app > service > infra > core)

Capa de entrada multimodal

Entra en Liri desde cualquier superficie

Terminal REPL

Una interfaz de terminal construida con React + Ink, con el sistema de compañero Buddy integrado

Cliente de escritorio Tauri

429 componentes TSX en 32 páginas de funciones (Tauri 2.11 + React 19)

MCP / pasarela de canales

Servidor MCP y 27 canales de mensajería (WeChat, DingTalk, Feishu, Telegram y más)

CLI / API HTTP

Tres ejecutables — Liri / liri-memory / liri-ink — más una API HTTP

Capa de seguridad primero

Cada entrada pasa por un filtro de seguridad

Análisis AST en Rust en tiempo de compilación

La capa FFI analiza el AST de Bash con 37 reglas de comandos peligrosos

Análisis semántico en TypeScript

Los comandos compuestos de solo lectura se evalúan segmento a segmento, con motivos de rechazo atribuibles

Motor de reglas Guardrail

14 patrones de inyección + 10 reglas específicas de shell

Clasificador AutoMode

Puntúa el riesgo de la tarea automáticamente y decide entre permitir, preguntar y denegar

Capa de enrutamiento inteligente

Elección de modelo según el tipo de tarea y su dificultad

19 tipos de tarea detectados

codificación, redacción, análisis, herramientas, traducción, búsqueda, ideación, charla informal y más

4 niveles

simple / medium / complex / reasoning

Pipeline de decisión en 5 etapas

interruptor → vía rápida → persistencia de sesión → juicio del LLM → resolución del nivel

FallbackChain

Conmutación por error ordenada cuando el proveedor principal no está disponible, junto con RetryPolicy

Capa de inyección del segundo cerebro

Base de conocimiento + memoria + eventos de sesión: tres fuentes de contexto recuperables

Base de conocimiento

Markdown en disco más indexación semántica, con recuperación híbrida por palabra clave / vector / RRF

Sistema de memoria

Memoria por capas con una tabla vectorial en SQLite y recuperación ponderada por relevancia

Eventos de sesión

events.jsonl de solo añadir: reproducible y auditable

DreamEngine

Consolida el conocimiento cuando está inactivo: recoger → analizar → generar → escribir → indexar

Bucle de decisión TAOR

Think → Act → Observe → Reason

Think

4 estrategias de agente: general / codificación / exploración / planificación

Act

69 herramientas integradas, registradas dinámicamente según la variante de compilación

Observe

Evaluación de resultados, ventanas de contexto por capas y compactación automática

Reason

Gestión del presupuesto de tokens + reanudación desde puntos de control + corte de circuito por ronda

Capa de sandbox de ejecución

Los comandos se ejecutan aislados y degradan con honestidad cuando no hay aislamiento disponible

Linux Landlock

Restricciones de acceso al sistema de archivos a nivel de núcleo

macOS / Windows

Sandbox del sistema con Low IL / objetos Job como alternativa

Contenedor Docker

Aislamiento completo en contenedor con límites de recursos y políticas de red

SSH / PTY

Entornos remotos de ejecución limpios y rutas de pseudo-terminal controladas

Capa de tareas de larga duración

De una sola conversación a trabajo de varios días

Pipeline PDCA

Un bucle Plan-Do-Check-Act que avanza según artefactos reales

Swarm multiagente

AgentSwarm con orquestación tipo consejo y descubrimiento dinámico en el registro

Programación Cron

expresiones once / interval / cron, husos horarios incluidos

Persistencia de tareas

Instantáneas de sesión, recuperación desde puntos de interrupción y cuentas atrás visibles mientras espera

Capa de retroalimentación y evolución

Cada interacción deja evidencia verificable

Inducción de patrones de fallo

Los patrones de fallo se generalizan de vuelta a los prompts y las habilidades, cerrando el bucle de mejora

Libro de costes

Facturado según la tabla de precios de la base de datos, registrando el nombre real del modelo que devuelve el proveedor

Puertas de evaluación

Conjuntos de referencia integrados, puntuación de fiabilidad pass^k y medición de seguridad por pares

Repetición de eventos

El contexto de cada llamada al modelo puede reconstruirse a posteriori

Filosofía de la arquitectura

🛡️

Seguridad integrada

La seguridad no es un complemento: es el ADN de cada capa

🏠

Local-first

Los datos se quedan en local, funciona sin conexión y la privacidad está protegida por defecto

🧠

Enrutamiento inteligente

19 clases de tarea asignadas al nivel de modelo adecuado

🧬

Segundo cerebro

Base de conocimiento, memoria y registros de eventos: tres capas de contexto recuperables

🔄

Bucle verificable

Las lecciones de los fallos vuelven al sistema y las puertas bloquean las regresiones

🔌

Multimodal unificado

Terminal, escritorio, IM y API comparten un mismo motor

Ver el estado completo

Línea de tiempo

Una entrada por mes: solo cambios de arquitectura y gobernanza, sin commits rutinarios.

2026-05-25 v0.1: 100 commits, el asistente de terminal funciona
2026-06-18 Primera revisión de código: un monolito de 7.200 líneas, proporción de pruebas sobre código de ~4%
2026-08-09 Primera puntuación de salud: 10/40 (D), 105 archivos sobredimensionados sin registrar
2026-10-09 El sandbox se borra por una limpieza → reversión completa; al día siguiente, proceso de borrado CD01–CD07
2026-10-20 Llega la puerta del vocabulario de estados: 34 valores, 1.795 pares de línea base
2026-10-28 Se consolida el desalojo del núcleo; herramientas visibles por defecto limitadas a 12 y 1.397 tokens
2026-10-28 Se publican el sitio de documentación bilingüe y esta página

Las actualizaciones mensuales se irán añadiendo aquí.

Formas de ayudar

Esta página no es un informe de cierre, es una invitación. Tres huecos y faltan manos para todos.

Lista de auditoría de seguridad

Reglas de comandos peligrosos: 37 reglas — dónde están y cómo se disparan; construye un caso y comprueba si cae en la regla esperada
Reglas de inyección de prompts: 14 reglas — alimenta un documento malicioso y comprueba si se bloquea
Reglas de shell: 10 entradas de lista blanca / negra — prueba vías de elusión (tuberías, subshells, codificación)
Degradación del sandbox: en qué condiciones degrada cada uno de los 6 backends y si falla en cerrado
Etapas de aprobación: requested → presented → decided → recorded — busca etapas que falten o estén desordenadas
Superficie de privilegios: ¿puede una llamada a herramienta saltarse el clasificador de permisos y escribir o ejecutar directamente?

Puntos de entrada: app/src/security, app/src/sandbox, app/src/permission.

Si encuentras detalles de una vulnerabilidad, repórtalos de forma privada según SECURITY.md; no abras un issue público. Los issues públicos son solo para el proceso y el alcance de la auditoría.

Reclama o pregunta en Issues Abrir la vía de autoevaluación de seguridad

¿Prefieres financiarlo? Consulta la página de patrocinio