REGISTRO DI SVILUPPO

Una strada non ancora conclusa

Da v0.1 a v0.5.22 — 156 giorni, 116 segmenti di versione. Non è un elenco di funzioni: sono gli errori fatti, le regole guadagnate e i vuoti ancora da colmare.

156 giorni: dal primo rilascio
116: segmenti di versione
9: istantanee dell'architettura
20+: controlli architetturali

Istantanea dei dati 2026-11-01 · numeri raccolti dal repository Liri da sync-facts e health:arch

Salta alla cronologia

Origine

Il 25 maggio 2026 Liri ha rilasciato la v0.1: 100 commit e un assistente IA da terminale che riusciva davvero a funzionare.

Il problema era concreto: far sedere il modello nel terminale, leggere file, eseguire comandi e modificare codice, invece di chattare in una casella di testo sul web. Modelli locali prima di tutto, perché i file privati non dovrebbero lasciare la macchina; sicurezza integrata, perché all'assistente viene consegnato un computer reale, non solo un'API.

Nei tre mesi successivi le capacità sono cresciute strato dopo strato: strumenti, 27 canali di messaggistica, un client desktop, voce, una base di conoscenza. Ad agosto il repository conteneva più di 4.000 file.

È anche il momento in cui il problema è stato nominato. La revisione del codice del 18 giugno 2026 ha trovato LocalHTTPService a 7.200 righe e ChatManager a 3.263, con 150 file di test contro 3.742 file sorgente. Due mesi dopo è arrivato il primo punteggio di salute dell'architettura: 10/40, grado D, con 105 file fuori limite, nessuno registrato.

La lezione: se un progetto può essere rilevato da altri non dipende da quante funzioni ha, ma dalle regole che sviluppa dopo aver sbattuto contro un muro.

Cinque punti di svolta

Ordinati per causalità, non per calendario: alcuni periodi si sovrappongono.

2026-05-25 → 2026-08

Prima le capacità, i confini dopo

Situazione: La v0.1 aveva 100 commit: funzionare contava più della struttura.
Decisione: Riempire prima le capacità: strumenti, canali, desktop, voce, conoscenza, uno alla volta.
Costo: Il primo audit è stato brutto: LocalHTTPService a 7.200 righe, ChatManager a 3.263, un rapporto test/sorgenti intorno al 4% e un primo punteggio di salute di 10/40 (D) con 105 file fuori limite non registrati.
Risultato: Oltre 4.000 file, 69 strumenti, 27 canali, 429 componenti desktop.

Prove CHANGELOG v0.1 Revisione del codice, 18 giu 2026

↳ Come partecipare — Per aggiungere capacità: creare un modulo sotto app/src, non dentro il nucleo.

2026-08-09 → 2026-09-30

Imparare a misurarsi

Situazione: Tutti percepivano il problema, nessuno sapeva dire quanto fosse grave.
Decisione: Trasformare la qualità dell'architettura in un punteggio ripetibile con un registro e rendere obbligatoria la registrazione di ogni file fuori limite — rinunciando all'ipotesi che la pulizia sopravviva alla sola disciplina.
Costo: Registrare non significa dividere: ChatManager è passato da 3.263 a 7.036 righe (ora ridotto a 2,570 righe). Anche il criterio di punteggio è cambiato più volte, quindi vale come controllo di salute, non come KPI.
Risultato: Nove istantanee; i file fuori limite non registrati sono scesi da 105 a 0 (poi tornati a 2); l'elenco è diventato un registro tracciabile.

Prove architecture-health-history.json architecture-health.ts

↳ Come partecipare — Prendere in carico la divisione di un file fuori limite (vedi Come partecipare più sotto).

2026-10-08 → 10-09

Un errore di cancellazione ha prodotto un processo di rimozione

Situazione: Nel codice si era accumulato uno strato di «superfici morte» apparentemente non usate. La pulizia della v0.4.69 ha trattato il sottosistema sandbox e isolamento come codice morto: 170 file toccati, +9.340 / −10.174 righe.
Decisione: Il giorno dopo la v0.4.71 ha ripristinato tutto: 24 file recuperati (IsolationManager, EnhancedSandboxManager, PTYSandbox, SSHSandbox, docker/** e altri, più 5 suite di test) e 21 file attivi riportati allo stato precedente.
Costo: Ora cancellare richiede più tempo: prima si raccolgono le prove. Resta comunque più economico di un rollback.
Risultato: La v0.4.72 ha trasformato la cancellazione in un processo, code-deletion.md (CD01–CD07): raccogliere le prove, staccare i punti di ingresso, poi eliminare. «Sembra che nessuno lo usi» non è più un motivo.

Prove CHANGELOG v0.4.69 / v0.4.71 / v0.4.72

↳ Come partecipare — Verificare un «candidato al codice morto» seguendo CD01–CD07.

2026-10-10 → 10-22

Trasformare le regole in cancelli

Situazione: Le regole vivevano nei documenti e si basavano sulla disciplina; documenti e codice hanno iniziato a divergere.
Decisione: Ogni regola è diventata un blocco della CI invece di un consiglio: cinque cancelli più doc-gate e un job obbligatorio sandbox-negative; 413 chiavi di riferimento per l'hardcoding; vocabolario di stato con 34 valori e 1.795 coppie di riferimento; cancelli su superficie di avvio, moduli critici e superficie del nucleo.
Costo: Qualche secondo in più per commit e basi di riferimento da rigenerare a ogni modifica del vocabolario — il punto è proprio che le definizioni non possono più cambiare in silenzio.
Risultato: Violazioni di lint:arch a 0; test da 3.029 a 7.488.

Prove AGENTS.md, elenco dei cancelli Workflow CI

↳ Come partecipare — Eseguire i cancelli locali (bun run ci) prima del push e correggere ciò che diventa rosso.

2026-10-05 → 10-28

Ridurre il nucleo: da 5.336 righe a un pacchetto autonomo

Situazione: Il core era sia l'implementazione di ingresso sia il cortile comune di tutte le capacità: chiunque poteva aggiungere qualcosa.
Decisione: Tre passi: ridurre (CoreAPIImpl da 5.336 a 2.521 righe), estrarre (@openliri/kernel come pacchetto autonomo; core da 146 a 113 file con i cancelli del nucleo K01–K08), poi espellere (37 moduli che non rispettavano la regola «zero I/O / zero dipendenze verso l'alto» spostati in app/src, oltre 470 import aggiornati, cinque famiglie di basi di riferimento rigenerate).
Costo: Una migrazione ampia e la rigenerazione completa delle basi di riferimento; dal 18 ottobre il lavoro procede a lotti e la densità dei commit è deliberatamente più bassa.
Risultato: Il nucleo ora espone un'interfaccia sottile; i contributi esterni hanno finalmente un confine.

Prove CHANGELOG v0.5.22

↳ Come partecipare — Le nuove capacità vivono fuori dal confine del nucleo e partono da app/src.

Architettura: a livelli come un sistema operativo

L'architettura non è stata reinventata. Nucleo sottile, confini tra sottosistemi, direzione unica delle dipendenze, cancelli e osservabilità vengono da decenni di pratica sui sistemi operativi; i pattern di progettazione e le guide ingegneristiche pubblicate per gli agenti negli ultimi due anni convergono sulle stesse domande: livelli, confini, stato, governo, valutazione. Ci imponiamo il primo modello e ci verifichiamo con il secondo.

Concetto di sistema operativo → stato in Liri

Concetto	In Liri	Stato
Nucleo	@openliri/kernel come pacchetto autonomo con un'interfaccia pubblica sottile, protetto da K01–K08	Rilasciato
Sottosistemi	Strumenti / canali / memoria / instradamento / sandbox / attività / voce / desktop, ciascuno con ingressi e confini propri	In convergenza
Driver	Adattatori dei fornitori, adattatori dei canali e 6 backend sandbox (Landlock / Docker / SSH / PTY / macOS / Windows)	Rilasciato
Processi e pianificazione	Esecuzione di sessione, PDCA, Swarm, Cron	Rilasciato
Modello dei permessi	Cinque livelli di difesa più quattro fasi di approvazione (requested → presented → decided → recorded)	In attesa di audit
Osservabilità e audit	Log degli eventi, registro dei costi, registro delle prove	Rilasciato
Manutentori (MAINTAINERS)	Non ancora istituiti: mancano owner dei sottosistemi e un percorso di passaggio di consegne	Mancante

Con cosa ci siamo confrontati

Abbiamo confrontato voce per voce i pattern di progettazione e le guide ingegneristiche pubblicati per gli agenti: tutti e 21 i pattern hanno un'implementazione reale, ma 3 interruttori chiave sono disattivati per impostazione predefinita — per questo diciamo solo «implementato», mai «attivo per default». Il ciclo ingegneristico è verificato allo stesso modo: architettura, build, esecuzione, governo, ottimizzazione.

Tre vuoti

Manutentori dei sottosistemi

Senza owner non c'è un percorso di passaggio di consegne. È la parte più simile a un sistema operativo e quella che manca.

Contratti dei sottosistemi

La bozza di progetto dei contratti esiste, ma non è verificato se registro / LoopProfile siano stati realizzati: la promessa di stabilità delle interfacce non è ancora fissata.

Cancello di copertura

Circa il 4% al momento della revisione; la CI esegue oltre 20 controlli architetturali, ma non esiste ancora una soglia di copertura.

Va detto: la salute dell'architettura è ancora D (10/40); dei 142 file fuori limite, 141 sono ancora non registrati, e il più grande resta nel modulo chat (ChatManager è stato ridotto da 7.036 a 2,570 righe). Il nucleo c'è, i confini stanno convergendo, i manutentori non ci sono ancora: è questo che significa «non ancora concluso».

Espandere gli attuali 8 livelli funzionali

Architettura d'insieme

8 livelli funzionali dall'ingresso al feedback; sul piano ingegneristico 6 cancelli di dipendenza (entry > ui > app > service > infra > core)

Livello di ingresso multimodale

Entrare in Liri da qualsiasi superficie

Terminale REPL

Interfaccia terminale costruita con React + Ink, con il sistema di compagni Buddy integrato

Client desktop Tauri

429 componenti TSX su 32 pagine funzionali (Tauri 2.11 + React 19)

Gateway MCP / canali

MCP Server più 27 canali di messaggistica (WeChat, DingTalk, Feishu, Telegram e altri)

CLI / API HTTP

Tre eseguibili — Liri / liri-memory / liri-ink — più un'API HTTP

Primo livello di sicurezza

Ogni input passa da un filtro di sicurezza

Analisi AST Rust in fase di compilazione

Il livello FFI analizza l'AST Bash applicando 37 regole sui comandi pericolosi

Analisi semantica TypeScript

I comandi composti di sola lettura vengono valutati segmento per segmento, con motivi di rifiuto attribuibili

Motore di regole Guardrail

14 pattern di iniezione + 10 regole specifiche per la shell

Classificatore AutoMode

Valuta automaticamente il rischio del compito e decide tra consentire, chiedere e negare

Livello di instradamento intelligente

Scelta del modello in base al tipo di compito e alla difficoltà

19 tipi di compito rilevati

codice, scrittura, analisi, strumenti, traduzione, ricerca, ideazione, conversazione e altri

4 livelli

simple / medium / complex / reasoning

Pipeline decisionale a 5 stadi

interruttore → percorso rapido → persistenza di sessione → giudizio LLM → risoluzione del livello

FallbackChain

Failover ordinato quando il fornitore principale non è disponibile, con RetryPolicy

Livello di iniezione del secondo cervello

Base di conoscenza + memoria + eventi di sessione: tre fonti di contesto interrogabili

Base di conoscenza

Markdown su disco più indicizzazione semantica, con recupero ibrido keyword / vettoriale / RRF

Sistema di memoria

Memoria a livelli con tabella vettoriale SQLite e richiamo ponderato per rilevanza

Eventi di sessione

events.jsonl in sola aggiunta — riproducibili e verificabili

DreamEngine

Consolida la conoscenza quando è inattivo: raccolta → analisi → generazione → scrittura → indicizzazione

Ciclo decisionale TAOR

Think → Act → Observe → Reason

Think

4 strategie di agente: generale / codice / esplorazione / pianificazione

Act

69 strumenti integrati, registrati dinamicamente per variante di build

Observe

Valutazione dei risultati più finestre di contesto a livelli e compattazione automatica

Reason

Gestione del budget di token + ripresa da checkpoint + interruzione per singolo giro

Livello di esecuzione in sandbox

I comandi girano in isolamento e degradano onestamente quando l'isolamento non è disponibile

Linux Landlock

Restrizioni di accesso al filesystem a livello di kernel

macOS / Windows

Sandbox di sistema con Low IL / oggetti Job come fallback

Container Docker

Isolamento completo del container con limiti di risorse e policy di rete

SSH / PTY

Ambienti di esecuzione remoti puliti e percorsi pseudo-terminale controllati

Livello dei compiti di lunga durata

Da una singola conversazione a un lavoro di più giorni

Pipeline PDCA

Un ciclo Plan-Do-Check-Act che avanza in base ai prodotti reali

Swarm multi-agente

AgentSwarm con orchestrazione in stile consiglio e scoperta dinamica nel registro

Pianificazione Cron

Espressioni once / interval / cron, fusi orari inclusi

Persistenza dei compiti

Istantanee di sessione, ripresa da punto di interruzione e conto alla rovescia visibile in attesa

Livello di feedback ed evoluzione

Ogni interazione lascia prove verificabili

Induzione dei pattern di fallimento

I pattern di fallimento vengono generalizzati e reinseriti in prompt e competenze, chiudendo il ciclo di miglioramento

Registro dei costi

Addebitato sulla tabella prezzi del database, registrando il nome reale del modello restituito dal fornitore

Cancelli di valutazione

Suite di riferimento integrate, punteggio di affidabilità pass^k e misurazione di sicurezza appaiata

Riproduzione degli eventi

Il contesto di ogni chiamata al modello può essere ricostruito a posteriori

Filosofia dell'architettura

🛡️

Sicurezza integrata

La sicurezza non è un plugin: è il DNA di ogni livello

🏠

Prima in locale

Dati in locale, funzionamento offline, privacy protetta per impostazione predefinita

🧠

Instradamento intelligente

19 classi di compito associate al livello di modello adatto

🧬

Secondo cervello

Base di conoscenza, memoria e log degli eventi: tre livelli di contesto interrogabili

🔄

Ciclo verificabile

Gli insegnamenti dei fallimenti rientrano, i cancelli bloccano le regressioni

🔌

Multimodale unificato

Terminale, desktop, IM e API condividono un unico motore

Vedere lo stato completo

Cronologia

Una voce al mese, solo cambiamenti di architettura e governo; i commit ordinari non sono inclusi.

2026-05-25 v0.1: 100 commit, l'assistente da terminale funziona
2026-06-18 Prima revisione del codice: un monolite da 7.200 righe, rapporto test/sorgenti intorno al 4%
2026-08-09 Primo punteggio di salute dell'architettura: 10/40 (D), 105 file fuori limite non registrati
2026-10-09 Sandbox cancellata per errore → rollback completo; il giorno dopo nasce il processo CD01–CD07
2026-10-20 Entra in funzione il cancello del vocabolario di stato: 34 valori, 1.795 coppie di riferimento
2026-10-28 Si conclude l'espulsione dal nucleo; gli strumenti visibili al modello scendono a 12 / 1.397 token
2026-10-28 Vanno online il sito di documentazione bilingue e questa pagina

Le voci mensili successive saranno aggiunte qui.

Come partecipare

Questa pagina non è un rapporto di chiusura, è un invito. Tre lacune, tutte con bisogno di mani.

Checklist di audit della sicurezza

Regole sui comandi pericolosi: dove vivono le 37 regole e come si attivano — costruire un caso e verificare che scatti quella prevista
Regole di prompt injection: 14 regole — fornire un documento malevolo e vedere se viene bloccato
Regole Shell: 10 voci tra elenco consentiti e vietati — provare i percorsi di bypass (pipe, subshell, codifica)
Degrado della sandbox: in quali condizioni degrada ciascuno dei 6 backend e se, dopo il degrado, resta fail-closed
Fasi di approvazione: requested → presented → decided → recorded — cercare fasi mancanti o fuori ordine
Superficie dei privilegi: una chiamata a uno strumento può aggirare il classificatore dei permessi e scrivere o eseguire direttamente?

Punti di ingresso: app/src/security, app/src/sandbox, app/src/permission.

I dettagli delle vulnerabilità vanno segnalati in privato secondo SECURITY.md, non in una issue pubblica; le issue pubbliche servono solo a discutere processo e copertura dell'audit.

Prendere in carico o chiedere nelle Issues Aprire il percorso di autoverifica della sicurezza

Preferisci sostenere con un contributo economico? Vedere la pagina sponsor