JOURNAL DE DÉVELOPPEMENT

Une route encore en construction

De v0.1 à v0.5.22 — 156 jours, 116 versions. Ce n’est pas une liste de fonctionnalités ; ce sont nos erreurs, les règles qu’elles nous ont coûtées et les blancs qu’il reste à remplir.

156 jours: depuis la première version
116: versions
9: instantanés d’architecture
20+: vérifications d’architecture

Instantané de données 2026-11-01 · chiffres collectés sur le dépôt Liri par sync-facts et health:arch

Aller à la chronologie

Origine

Le 25 mai 2026, Liri a livré v0.1 : 100 commits et un assistant IA de terminal qui fonctionnait vraiment.

Le problème était concret — faire tenir le modèle dans le terminal, lire des fichiers, exécuter des commandes et modifier du code, au lieu de discuter dans un champ de saisie web. Les modèles locaux d’abord, parce que des fichiers privés ne devraient pas avoir à quitter la machine ; la sécurité intégrée, parce que l’assistant reçoit un vrai ordinateur, pas seulement une API.

Les trois mois suivants ont ajouté les capacités couche par couche : outils, 27 canaux de messagerie, client de bureau, voix, base de connaissances. En août, le dépôt comptait plus de 4 000 fichiers.

C’est aussi là que le problème a été nommé. La revue de code du 18 juin 2026 a trouvé LocalHTTPService à 7 200 lignes et ChatManager à 3 263, avec 150 fichiers de test pour 3 742 fichiers source. Deux mois plus tard, le premier score de santé de l’architecture est tombé : 10/40, note D, avec 105 fichiers hors limite, aucun enregistré.

La leçon : la capacité d’un projet à être repris par quelqu’un d’autre ne se décide pas au nombre de fonctionnalités, mais aux règles qu’il fait pousser après avoir heurté un mur.

Cinq tournants

Classés par causalité, pas par ordre chronologique — certaines périodes se chevauchent.

2026-05-25 → 2026-08

D’abord les capacités, les frontières ensuite

Situation: v0.1 n’avait que 100 commits ; livrer primait sur la structure.
Décision: Remplir d’abord les capacités : outils, canaux, bureau, voix, connaissances, un par un.
Coût: Le premier audit a été brutal : LocalHTTPService à 7 200 lignes, ChatManager à 3 263, un ratio tests/source d’environ 4 %, et un premier score de santé de 10/40 (D) avec 105 fichiers hors limite non enregistrés.
Résultat: Plus de 4 000 fichiers, 69 outils, 27 canaux, 429 composants de bureau.

Preuve CHANGELOG v0.1 Revue de code du 18 juin 2026

↳ Comment participer — Pour ajouter une capacité : créez un module sous app/src, pas dans le noyau.

2026-08-09 → 2026-09-30

Apprendre à se mesurer

Situation: Tout le monde sentait le problème ; personne ne pouvait dire à quel point il était grave.
Décision: Transformer la qualité de l’architecture en score reproductible avec un registre, et exiger l’enregistrement de chaque fichier hors limite — en abandonnant l’hypothèse que la propreté tient à la seule discipline.
Coût: Enregistrer n’est pas découper : ChatManager est passé de 3 263 à 7 036 lignes (depuis découpé à 2,570). La notation elle-même a changé, c’est donc un bilan de santé, pas un KPI.
Résultat: Neuf instantanés ; les fichiers hors limite non enregistrés sont passés de 105 à 0 (puis 2) ; la liste est devenue un registre traçable.

Preuve architecture-health-history.json architecture-health.ts

↳ Comment participer — Réclamez le découpage d’un fichier hors limite (voir Comment participer ci-dessous).

2026-10-08 → 10-09

Une suppression ratée a acheté un processus de suppression

Situation: Le code avait accumulé une couche de « surfaces mortes » apparemment inutilisées. Le nettoyage de v0.4.69 a traité le sous-système de bac à sable et d’isolation comme du code mort : 170 fichiers touchés, +9 340 / −10 174 lignes.
Décision: Le lendemain, v0.4.71 a tout annulé : 24 fichiers restaurés (IsolationManager, EnhancedSandboxManager, PTYSandbox, SSHSandbox, docker/** et d’autres, plus 5 suites de tests) et 21 fichiers vivants remis en cohérence.
Coût: Supprimer prend désormais plus de temps : il faut d’abord écrire les preuves. Cela reste moins cher qu’un retour arrière.
Résultat: v0.4.72 a transformé la suppression en processus, code-deletion.md (CD01–CD07) : réunir les preuves, détacher les points d’entrée, puis supprimer. « Personne ne semble l’utiliser » n’est plus une raison.

Preuve CHANGELOG v0.4.69 / v0.4.71 / v0.4.72

↳ Comment participer — Examinez un « candidat au code mort » au regard de CD01–CD07.

2026-10-10 → 10-22

Transformer les règles en garde-fous

Situation: Les règles vivaient dans des documents et reposaient sur la discipline ; les documents et le code ont commencé à diverger.
Décision: Chaque règle est devenue un blocage CI plutôt qu’un conseil : cinq garde-fous plus doc-gate et un job sandbox-negative obligatoire ; 413 clés de référence pour les valeurs codées en dur ; un vocabulaire d’états de 34 valeurs avec 1 795 paires de référence ; des garde-fous sur la surface de démarrage, les modules critiques et la surface du noyau.
Coût: Quelques secondes par commit, et les références doivent être régénérées à chaque changement de vocabulaire — c’est précisément le but : les définitions ne peuvent plus dériver en silence.
Résultat: Zéro violation lint:arch ; les tests sont passés de 3 029 à 7 488.

Preuve Liste des garde-fous dans AGENTS.md Workflow CI

↳ Comment participer — Lancez les garde-fous locaux (bun run ci) avant de pousser — corrigez ce qui passe au rouge.

2026-10-05 → 10-28

Réduire le noyau : de 5 336 lignes à un paquet autonome

Situation: Le core était à la fois l’implémentation d’entrée et l’arrière-cour commune — n’importe qui pouvait y ajouter du code.
Décision: Trois étapes : réduire (CoreAPIImpl de 5 336 à 2 521 lignes), extraire (@openliri/kernel devient un paquet autonome ; core passe de 146 à 113 fichiers avec les garde-fous de noyau K01–K08), puis évincer (37 modules ne respectant pas la règle « zéro I/O / zéro dépendance vers le haut » descendus dans app/src, plus de 470 imports mis à jour, cinq familles de références régénérées).
Coût: Une grosse migration et une régénération complète des références ; depuis le 18 octobre, le travail arrive par lots et la densité de commits est volontairement plus basse.
Résultat: Le noyau n’expose plus qu’une interface mince ; les contributions externes ont enfin une frontière.

Preuve CHANGELOG v0.5.22

↳ Comment participer — Les nouvelles capacités vivent hors de la frontière du noyau et démarrent dans app/src.

Architecture : structurée comme un système d’exploitation

L’architecture n’a pas été réinventée. Un noyau mince, des frontières entre sous-systèmes, une direction de dépendance à sens unique, des garde-fous et de l’observabilité viennent de décennies de pratique des systèmes d’exploitation ; les patrons de conception et guides d’ingénierie publiés pour les agents ces deux dernières années convergent vers les mêmes questions — couches, frontières, état, gouvernance, évaluation. Nous nous contraignons de la première façon et nous nous auditons avec la seconde.

Concept de système d’exploitation → état de Liri

Concept	Dans Liri	Statut
Noyau	@openliri/kernel en paquet autonome avec une interface publique mince, protégé par K01–K08	Déployé
Sous-systèmes	Outils / canaux / mémoire / routage / bac à sable / tâches / voix / bureau — chacun avec ses points d’entrée et ses frontières	En convergence
Pilotes	Adaptateurs de fournisseurs, adaptateurs de canaux et 6 backends de bac à sable (Landlock / Docker / SSH / PTY / macOS / Windows)	Déployé
Processus et ordonnancement	Exécution de session, PDCA, Swarm, Cron	Déployé
Modèle de permissions	Cinq couches de défense et quatre étapes d’approbation (requested → presented → decided → recorded)	Audit externe en attente
Observabilité et audit	Journal d’événements, registre des coûts, registre des preuves	Déployé
Mainteneurs (MAINTAINERS)	Pas encore établi : aucun propriétaire de sous-système ni chemin de reprise	Manquant

Ce à quoi nous nous sommes comparés

Nous nous sommes comparés point par point aux patrons de conception d’agents et aux guides d’ingénierie publics : les 21 patrons ont une implémentation réelle, mais 3 des interrupteurs clés sont désactivés par défaut — nous disons donc seulement « implémenté », jamais « actif par défaut ». La boucle d’ingénierie est auditée de la même façon : architecture, build, exécution, gouvernance, optimisation.

Trois blancs

Mainteneurs de sous-systèmes

Sans propriétaires, pas de chemin de reprise. C’est la pièce la plus proche d’un système d’exploitation, et celle qui nous manque.

Contrats de sous-systèmes

La conception des contrats existe, mais la mise en œuvre du registre / LoopProfile n’est pas vérifiée — la stabilité des interfaces n’est pas encore figée.

Garde-fou de couverture

Environ 4 % lors de la revue ; la CI exécute plus de 20 vérifications d’architecture, mais il n’y a pas encore de seuil de couverture.

Pour être honnête : la santé de l’architecture reste D (10/40) ; sur 142 fichiers hors limite, 141 ne sont toujours pas enregistrés ; le plus gros reste dans le module chat (ChatManager est passé de 7 036 à 2,570 lignes). Le noyau existe, les frontières convergent, les mainteneurs n’existent pas encore — c’est ce que signifie « pas encore terminé ».

Développer les 8 couches fonctionnelles actuelles

Architecture en un coup d’œil

8 couches fonctionnelles, de l’entrée à la rétroaction ; contraintes en ingénierie par 6 garde-fous de dépendance (entry > ui > app > service > infra > core)

Couche d’entrée multimodale

Entrez dans Liri depuis n’importe quelle surface

REPL terminal

Une interface terminal construite avec React + Ink, avec le système de compagnon Buddy intégré

Client de bureau Tauri

429 composants TSX répartis sur 32 pages fonctionnelles (Tauri 2.11 + React 19)

MCP / passerelle de canaux

MCP Server et 27 canaux de messagerie (WeChat, DingTalk, Feishu, Telegram, etc.)

CLI / HTTP API

Trois exécutables — Liri / liri-memory / liri-ink — et une API HTTP

Couche sécurité

Chaque entrée passe par un filtre de sécurité

Analyse AST Rust à la compilation

La couche FFI analyse l’AST Bash selon 37 règles de commandes dangereuses

Analyse sémantique TypeScript

Les commandes composites en lecture seule sont jugées segment par segment, avec un motif de refus attribuable

Moteur de règles Guardrail

14 motifs d’injection + 10 règles spécifiques au shell

Classificateur AutoMode

Évalue automatiquement le risque d’une tâche et décide entre autoriser, demander et refuser

Couche de routage intelligent

Choix du modèle selon le type et la difficulté de la tâche

19 types de tâches détectés

codage, rédaction, analyse, outils, traduction, recherche, idéation, conversation et plus

4 niveaux

simple / medium / complex / reasoning

Pipeline de décision en 5 étapes

interrupteur → voie rapide → ancrage de session → jugement LLM → résolution du niveau

FallbackChain

Bascule ordonnée quand le fournisseur principal est indisponible, avec RetryPolicy

Couche d’injection du second cerveau

Base de connaissances + mémoire + événements de session : trois sources de contexte interrogeables

Base de connaissances

Markdown sur disque et index sémantique, avec recherche hybride par mots-clés / vecteurs / RRF

Système de mémoire

Mémoire à plusieurs niveaux avec table vectorielle SQLite et rappel pondéré par pertinence

Événements de session

events.jsonl en ajout seul — rejouable et auditable

DreamEngine

Consolide les connaissances au repos : collecter → analyser → générer → écrire → indexer

Boucle de décision TAOR

Think → Act → Observe → Reason

Think

4 stratégies d’agent : général / codage / exploration / planification

Act

69 outils intégrés, enregistrés dynamiquement selon la variante de build

Observe

Évaluation des résultats, fenêtres de contexte stratifiées et compaction automatique

Reason

Gestion du budget de tokens + reprise sur point de contrôle + coupure par tour

Couche de bac à sable d’exécution

Les commandes s’exécutent isolées et se dégradent honnêtement quand aucun isolement n’est disponible

Linux Landlock

Restrictions d’accès au système de fichiers au niveau du noyau

macOS / Windows

Bacs à sable système avec Low IL / objet Job en repli

Conteneur Docker

Isolation complète en conteneur avec limites de ressources et politiques réseau

SSH / PTY

Environnements d’exécution distants propres et chemins de pseudo-terminal contrôlés

Couche des tâches de longue durée

D’une conversation unique à un travail de plusieurs jours

Pipeline PDCA

Une boucle Plan-Do-Check-Act qui avance selon l’existence réelle des artefacts

Swarm multi-agents

AgentSwarm avec orchestration type conseil et découverte dynamique du registre

Planification Cron

once / interval / expressions cron, fuseaux horaires compris

Persistance des tâches

Instantanés de session, reprise sur point de rupture et compte à rebours visible pendant l’attente

Couche de rétroaction et d’évolution

Chaque interaction laisse une preuve vérifiable

Induction des motifs d’échec

Les motifs d’échec sont généralisés puis réinjectés dans les prompts et les compétences, fermant la boucle d’amélioration

Registre des coûts

Facturé selon la grille tarifaire de la base, en enregistrant le nom réel du modèle renvoyé par le fournisseur

Garde-fous d’évaluation

Suites de référence intégrées, score de fiabilité pass^k et mesure de sécurité par paires

Rejeu d’événements

Le contexte de chaque appel de modèle peut être reconstruit après coup

Philosophie d’architecture

🛡️

Sécurité intégrée

La sécurité n’est pas un greffon — c’est l’ADN de chaque couche

🏠

Local d’abord

Données stockées localement, usage hors ligne, confidentialité protégée par défaut

🧠

Routage intelligent

19 classes de tâches associées au bon niveau de modèle

🧬

Second cerveau

Base de connaissances, mémoire et journaux d’événements : trois couches de contexte interrogeables

🔄

Boucle vérifiable

Les leçons des échecs sont réinjectées et les garde-fous bloquent les régressions

🔌

Multimodal unifié

Terminal, bureau, messagerie et API partagent un seul moteur

Voir l’état complet

Chronologie

Une entrée par mois — uniquement les changements d’architecture et de gouvernance, pas les commits ordinaires.

2026-05-25 v0.1 : 100 commits, l’assistant terminal fonctionne
2026-06-18 Première revue de code : un monolithe de 7 200 lignes, ratio tests/source d’environ 4 %
2026-08-09 Premier score de santé : 10/40 (D), 105 fichiers hors limite non enregistrés
2026-10-09 Bac à sable supprimé par un nettoyage → retour arrière complet ; processus de suppression CD01–CD07 le lendemain
2026-10-20 Garde-fou du vocabulaire d’états livré : 34 valeurs, 1 795 paires de référence
2026-10-28 L’éviction du noyau aboutit ; les outils visibles par le modèle sont plafonnés à 12 / 1 397 tokens
2026-10-28 Site de documentation bilingue et cette page en ligne

Les mises à jour mensuelles seront ajoutées ici.

Comment participer

Cette page n’est pas un bilan, c’est une invitation. Trois chantiers, et il manque des mains partout.

Liste de contrôle d’audit de sécurité

Règles de commandes dangereuses : 37 règles — où elles vivent, comment elles se déclenchent ; construisez un cas et vérifiez qu’il tombe sur la règle attendue
Règles d’injection de prompt : 14 règles — fournissez un document malveillant et voyez s’il est bloqué
Règles Shell : 10 entrées d’autorisation / refus — testez les chemins de contournement (pipes, sous-shells, encodage)
Dégradation du bac à sable : quand chacun des 6 backends se dégrade, et s’il échoue en mode fermé (fail-closed)
Étapes d’approbation : requested → presented → decided → recorded — cherchez les étapes manquantes ou hors ordre
Surface de privilèges : un appel d’outil peut-il contourner le classificateur de permissions et écrire ou exécuter directement ?

Points d’entrée : app/src/security, app/src/sandbox, app/src/permission.

Signalez les détails d’une vulnérabilité en privé via SECURITY.md — n’ouvrez pas d’issue publique. Les issues publiques ne servent qu’au processus d’audit et à sa couverture.

Réclamer ou poser une question dans les Issues Ouvrir le parcours d’auto-évaluation sécurité

Vous préférez financer ? Voir la page de sponsoring