ENTWICKLUNGSPROTOKOLL

Ein Weg, der noch nicht zu Ende ist

Von v0.1 bis v0.5.22 — 156 Tage, 116 Releases. Das ist keine Funktionsliste; es sind die Fehler, die gemacht wurden, die daraus gewonnenen Regeln und die Lücken, die noch offen sind.

156 Tage: seit dem ersten Release
116: Releases
9: Architektur-Snapshots
20+: Architekturprüfungen

Daten-Snapshot 2026-11-01 · Zahlen von sync-facts und health:arch aus dem Liri-Repository gesammelt

Zur Zeitleiste springen

Ursprung

Am 25. Mai 2026 war das erste Release v0.1 — 100 Commits und ein Terminal-KI-Assistent, der tatsächlich lief.

Das Problem war konkret: Das Modell sollte im Terminal sitzen, Dateien lesen, Befehle ausführen und Code ändern, statt in einem Web-Eingabefeld zu chatten. Lokale Modelle zuerst, weil private Dateien nicht auf fremden Servern landen sollen; Sicherheit von Anfang an, weil das System einen echten Rechner erhält und nicht nur eine API.

In den folgenden drei Monaten kamen die Fähigkeiten Schicht für Schicht dazu: Werkzeuge, 27 Messaging-Kanäle, ein Desktop-Client, Sprache, eine Wissensbasis. Im August lagen über 4.000 Dateien im Repository.

Da wurde das Problem zum ersten Mal benannt. Die Code-Durchsicht vom 18. Juni 2026 ergab LocalHTTPService mit 7.200 Zeilen und ChatManager mit 3.263, bei 150 Testdateien gegenüber 3.742 Quelldateien. Zwei Monate später kam der erste Architektur-Gesundheitswert: 10/40, Note D, mit 105 überdimensionierten Dateien, keine davon registriert.

Die Lehre: Ob ein Projekt übernehmbar ist, entscheidet nicht die Zahl der Funktionen, sondern die Regeln, die es nach dem Aufprall hervorbringt.

Fünf Wendepunkte

Nach Ursache sortiert, nicht nach Kalender — Zeiträume überschneiden sich.

2026-05-25 → 2026-08

Erst Fähigkeiten, Grenzen später

Ausgangslage: v0.1 hatte 100 Commits; Ausliefern schlug Struktur.
Entscheidung: Zuerst die Fähigkeiten füllen: Werkzeuge, Kanäle, Desktop, Sprache, Wissen — eins nach dem anderen.
Preis: Das erste Audit fiel unschön aus: LocalHTTPService mit 7.200 Zeilen, ChatManager mit 3.263, ein Test-zu-Quellcode-Verhältnis von rund 4 % und ein erster Gesundheitswert von 10/40 (D) mit 105 nicht registrierten überdimensionierten Dateien.
Ergebnis: Über 4.000 Dateien, 69 Werkzeuge, 27 Kanäle, 429 Desktop-Komponenten.

Belege CHANGELOG v0.1 Code-Durchsicht, 18. Juni 2026

↳ Einstieg — Neue Fähigkeiten? Modul unter app/src starten, nicht im Kernel.

2026-08-09 → 2026-09-30

Sich selbst messen lernen

Ausgangslage: Alle spürten das Problem, niemand konnte sagen, wie groß es ist.
Entscheidung: Architekturqualität in einen wiederholbaren Wert mit Register überführen und jede überdimensionierte Datei registrieren — die Annahme, Sauberkeit halte sich durch Disziplin, wurde aufgegeben.
Preis: Registrieren ist nicht Aufteilen: ChatManager wuchs von 3.263 auf 7.036 Zeilen (inzwischen auf 2,570 heruntergeteilt). Auch die Bewertung änderte sich weiter, daher ist sie ein Gesundheitscheck, kein KPI.
Ergebnis: Neun Snapshots; nicht registrierte überdimensionierte Dateien von 105 auf 0 (später zurück auf 2); die Liste wurde ein nachvollziehbares Register.

Belege architecture-health-history.json architecture-health.ts

↳ Einstieg — Eine überdimensionierte Datei zum Aufteilen übernehmen (siehe „Möglichkeiten zu helfen“ unten).

2026-10-08 → 10-09

Ein falsches Löschen brachte einen Löschprozess

Ausgangslage: In der Codebasis hatte sich eine Schicht scheinbar ungenutzter „toter Oberflächen“ angesammelt. Die Bereinigung in v0.4.69 behandelte Sandbox und Isolations-Subsystem als toten Code: 170 Dateien berührt, +9.340 / −10.174 Zeilen.
Entscheidung: Am nächsten Tag rollte v0.4.71 alles zurück — 24 Dateien wiederhergestellt (IsolationManager, EnhancedSandboxManager, PTYSandbox, SSHSandbox, docker/** und weitere, dazu 5 Test-Suiten) und 21 aktive Dateien passend zurückgesetzt.
Preis: Löschen dauert jetzt länger: erst Belege schreiben. Dennoch günstiger als ein Rollback.
Ergebnis: v0.4.72 machte das Löschen zu einem Prozess, code-deletion.md (CD01–CD07): Belege sammeln, Einstiegspunkte lösen, dann löschen. „Scheint niemand zu nutzen“ ist kein Grund mehr.

Belege CHANGELOG v0.4.69 / v0.4.71 / v0.4.72

↳ Einstieg — Einen „Dead-Code-Kandidaten“ gegen CD01–CD07 prüfen.

2026-10-10 → 10-22

Regeln zu Gates machen

Ausgangslage: Regeln standen in Dokumenten und verließen sich auf Disziplin; Dokumente und Code begannen auseinanderzudriften.
Entscheidung: Jede Regel wurde zum CI-Blocker statt zum Ratschlag: fünf Gates plus doc-gate und ein verpflichtender sandbox-negative-Job; 413 Baseline-Schlüssel für Hardcoding; ein Zustandsvokabular mit 34 Werten und 1.795 Baseline-Paaren; Gates für Startfläche, kritische Module und Kernel-Fläche.
Preis: Ein paar Sekunden pro Commit, und Baselines müssen bei jeder Vokabularänderung neu erzeugt werden — genau das ist der Punkt: Definitionen können nicht mehr still auseinanderlaufen.
Ergebnis: lint:arch-Verstöße bei 0; Tests wuchsen von 3.029 auf 7.488.

Belege AGENTS.md Gate-Liste CI-Workflow

↳ Einstieg — Vor dem Push die lokalen Gates laufen lassen (bun run ci) — beheben, was rot wird.

2026-10-05 → 10-28

Kernel verkleinern: von 5.336 Zeilen zum eigenen Paket

Ausgangslage: Der core war sowohl Einstiegsimplementierung als auch gemeinsamer Hinterhof — jeder konnte etwas hinzufügen.
Entscheidung: Drei Schritte: verkleinern (CoreAPIImpl 5.336 → 2.521 Zeilen), herauslösen (@openliri/kernel als eigenes Paket; core von 146 auf 113 Dateien mit Kernel-Gates K01–K08), dann auslagern (37 Module, die die Regel „null I/O / keine Abhängigkeit nach oben“ verletzten, nach app/src verschoben, über 470 Importe angepasst, fünf Baseline-Familien neu erzeugt).
Preis: Eine große Migration und vollständige Baseline-Neuerzeugung; seit dem 18.10. landen Änderungen in Batches, die Commit-Dichte ist bewusst niedriger.
Ergebnis: Der Kernel zeigt nur noch eine schlanke Schnittstelle; externe Beiträge haben endlich eine Grenze.

Belege CHANGELOG v0.5.22

↳ Einstieg — Neue Fähigkeiten leben außerhalb der Kernel-Grenze und starten in app/src.

Architektur: geschichtet wie ein Betriebssystem

Die Architektur wurde nicht neu erfunden. Schlanker Kernel, Subsystem-Grenzen, einseitige Abhängigkeitsrichtung, Gates und Observability stammen aus Jahrzehnten Betriebssystempraxis; die in den letzten zwei Jahren veröffentlichten Designmuster und Engineering-Leitfäden für Agenten laufen auf dieselben Fragen hinaus — Schichtung, Grenzen, Zustand, Governance, Evaluation. Wir beschränken uns auf die erste Weise und prüfen uns an der zweiten.

Betriebssystem-Konzept → Stand von Liri

Konzept	In Liri	Status
Kernel	@openliri/kernel als eigenes Paket mit schlanker öffentlicher Schnittstelle, abgesichert durch K01–K08	Umgesetzt
Subsysteme	Werkzeuge / Kanäle / Gedächtnis / Routing / Sandbox / Aufgaben / Sprache / Desktop — je mit eigenen Einstiegspunkten und Grenzen	Konvergiert
Treiber	Anbieter-Adapter, Kanaladapter und 6 Sandbox-Backends (Landlock / Docker / SSH / PTY / macOS / Windows)	Umgesetzt
Prozesse & Scheduling	Sitzungsausführung, PDCA, Swarm, Cron	Umgesetzt
Berechtigungsmodell	Fünf Verteidigungsebenen plus vier Genehmigungsstufen (requested → presented → decided → recorded)	Externes Audit ausstehend
Observability & Audit	Ereignisprotokoll, Kostenbuch, Belegregister	Umgesetzt
Maintainer	Noch nicht etabliert: keine Subsystem-Owner und kein Übergabepfad	Fehlt

Woran wir uns gemessen haben

Wir haben uns Punkt für Punkt an öffentlich verfügbaren Agent-Designmustern und Engineering-Leitfäden gemessen: alle 21 Muster haben echte Implementierungen, aber 3 der entscheidenden Schalter sind standardmäßig aus — deshalb heißt es nur „implementiert“, nie „standardmäßig aktiv“. Die Engineering-Schleife wird genauso geprüft: Architektur, Build, Betrieb, Governance, Optimierung.

Drei Lücken

Subsystem-Maintainer

Ohne Owner gibt es keinen Übergabepfad. Das ist das betriebssystemnächste Stück — und das, das fehlt.

Subsystem-Verträge

Der Vertragsentwurf existiert, ob Register / LoopProfile umgesetzt sind, ist nicht verifiziert — die Zusage stabiler Schnittstellen ist noch nicht festgeschrieben.

Coverage-Gate

Zum Zeitpunkt der Durchsicht etwa 4 %; die CI hat über 20 Architekturprüfungen, aber noch keine Coverage-Schwelle.

Ehrlich gesagt: Die Architektur-Gesundheit liegt weiter bei D (10/40); von 142 überdimensionierten Dateien sind 141 noch nicht registriert; die größte liegt weiter im Chat-Bereich (ChatManager wurde von 7.036 auf 2,570 Zeilen aufgeteilt). Der Kernel existiert, die Grenzen konvergieren, ein Maintainer-Modell gibt es noch nicht — das heißt „noch nicht zu Ende“.

Die aktuellen 8 Funktionsebenen ausklappen

Architektur im Überblick

8 Funktionsebenen vom Einstiegspunkt bis zur Rückmeldung; technisch erzwungen durch 6 Abhängigkeits-Gates (entry > ui > app > service > infra > core)

Multimodale Eingangsebene

Von jeder Oberfläche aus in Liri einsteigen

REPL-Terminal

Terminal-UI mit React + Ink, inklusive Buddy-Begleitsystem

Tauri-Desktop-Client

429 TSX-Komponenten auf 32 Funktionsseiten (Tauri 2.11 + React 19)

MCP / Kanal-Gateway

MCP-Server plus 27 Messaging-Kanäle (WeChat, DingTalk, Feishu, Telegram und weitere)

CLI / HTTP API

Drei ausführbare Einstiegspunkte — Liri / liri-memory / liri-ink — plus HTTP API

Ebene Sicherheit zuerst

Jede Eingabe durchläuft einen Sicherheitsfilter

Rust-AST-Analyse zur Compile-Zeit

Die FFI-Schicht parst den Bash-AST gegen 37 Regeln für gefährliche Befehle

TypeScript-Semantikanalyse

Zusammengesetzte Nur-Lese-Befehle werden segmentweise bewertet, Ablehnungsgründe sind zuordenbar

Guardrail-Regelengine

14 Injektionsmuster + 10 Shell-spezifische Regeln

AutoMode-Klassifikator

Bewertet das Aufgabenrisiko automatisch und entscheidet zwischen erlauben, nachfragen und ablehnen

Ebene Smartes Routing

Modellwahl nach Aufgabentyp und Schwierigkeit

19 erkannte Aufgabentypen

Coding, Schreiben, Analyse, Werkzeuge, Übersetzung, Suche, Ideenfindung, Small Talk und weitere

4 Stufen

simple / medium / complex / reasoning

Entscheidungspipeline mit 5 Stufen

Schalter → Schnellpfad → Sitzungsbindung → LLM-Bewertung → Stufenauflösung

FallbackChain

Geordneter Wechsel, wenn der primäre Anbieter nicht verfügbar ist, zusammen mit RetryPolicy

Ebene Injektion des zweiten Gehirns

Wissensbasis + Gedächtnis + Sitzungsereignisse: drei abrufbare Kontextquellen

Wissensbasis

Markdown auf der Platte plus semantischer Index, mit Hybrid-Suche aus Stichwort, Vektor und RRF

Gedächtnissystem

Gestuftes Gedächtnis mit SQLite-Vektortabelle und relevanzgewichteter Erinnerung

Sitzungsereignisse

Nur anhängendes events.jsonl — wiederholbar und auditierbar

DreamEngine

Konsolidiert Wissen im Leerlauf: sammeln → analysieren → erzeugen → schreiben → indexieren

TAOR-Entscheidungsschleife

Think → Act → Observe → Reason

Think

4 Agent-Strategien: allgemein / Coding / Exploration / Planung

Act

69 integrierte Werkzeuge, je Build-Variante dynamisch registriert

Observe

Ergebnisbewertung plus geschichtete Kontextfenster und automatische Kompaktierung

Reason

Token-Budget-Verwaltung + Wiederaufnahme ab Checkpoint + Circuit Breaker pro Runde

Ebene Ausführungs-Sandbox

Befehle laufen isoliert und degradieren ehrlich, wenn keine Isolation verfügbar ist

Linux Landlock

Kernel-seitige Beschränkung des Dateisystemzugriffs

macOS / Windows

System-Sandboxes mit Low IL / Job-Objekten als Rückfallebene

Docker-Container

Vollständige Container-Isolation mit Ressourcenlimits und Netzwerkrichtlinien

SSH / PTY

Saubere entfernte Ausführungsumgebungen und kontrollierte Pseudo-Terminal-Pfade

Ebene langlaufende Aufgaben

Von einem einzelnen Gespräch zu mehrträgiger Arbeit

PDCA-Pipeline

Plan-Do-Check-Act-Schleife, die Fortschritt an tatsächlichen Artefakten misst

Swarm mit mehreren Agenten

AgentSwarm mit ratsähnlicher Orchestrierung und dynamischer Registry-Erkennung

Cron-Zeitpläne

once / interval / Cron-Ausdrücke, Zeitzonen inklusive

Aufgabenpersistenz

Sitzungs-Snapshots, Wiederaufnahme ab Breakpoint und sichtbarer Countdown beim Warten

Ebene Rückmeldung und Evolution

Jede Interaktion hinterlässt überprüfbare Belege

Induktion von Fehlermustern

Fehlermuster werden verallgemeinert und in Prompts und Skills zurückgeschrieben, was den Verbesserungskreislauf schließt

Kostenbuch

Abrechnung über die Preistabelle der Datenbank, mit dem vom Anbieter gemeldeten Modellnamen

Evaluations-Gates

Integrierte Basissuiten, pass^k-Zuverlässigkeitswerte und paarweise Sicherheitsmessung

Ereignis-Wiedergabe

Der Kontext jedes Modellaufrufs lässt sich im Nachhinein rekonstruieren

Architekturphilosophie

🛡️

Sicherheit von Anfang an

Sicherheit ist kein Plugin, sondern die DNA jeder Ebene

🏠

Lokal zuerst

Daten bleiben lokal, offline nutzbar, Datenschutz standardmäßig

🧠

Smartes Routing

19 Aufgabenklassen werden der passenden Modellstufe zugeordnet

🧬

Zweites Gehirn

Wissensbasis, Gedächtnis und Ereignisprotokolle: drei abrufbare Kontextebenen

🔄

Überprüfbarer Kreislauf

Lehren aus Fehlern fließen zurück, Gates blockieren Regressionen

🔌

Einheitlich multimodal

Terminal, Desktop, IM und API teilen eine Engine

Vollständigen Status ansehen

Zeitleiste

Ein Eintrag pro Monat — nur Architektur und Governance, keine Routine-Commits.

2026-05-25 v0.1: 100 Commits, der Terminal-Assistent läuft
2026-06-18 Erste Code-Durchsicht: eine Datei mit 7.200 Zeilen, Test-zu-Quellcode-Verhältnis rund 4 %
2026-08-09 Erster Gesundheitswert: 10/40 (D), 105 überdimensionierte Dateien nicht registriert
2026-10-09 Sandbox durch eine Bereinigung gelöscht → vollständiger Rollback; Löschprozess CD01–CD07 am nächsten Tag
2026-10-20 Zustandsvokabular-Gate geht live: 34 Werte, 1.795 Baseline-Paare
2026-10-28 Kernel-Auslagerung abgeschlossen; sichtbare Werkzeuge auf 12 / 1.397 Token begrenzt
2026-10-28 Zweisprachige Dokumentationsseite und diese Seite gehen live

Monatliche Einträge werden hier ergänzt.

Möglichkeiten zu helfen

Diese Seite ist kein Abschlussbericht, sondern eine Einladung. Drei Lücken, für alle werden Hände gebraucht.

Checkliste für das Sicherheitsaudit

Regeln für gefährliche Befehle: 37 Regeln — wo sie liegen, wie sie auslösen; einen Fall bauen und prüfen, ob die erwartete Regel greift
Prompt-Injection-Regeln: 14 Regeln — ein bösartiges Dokument einspeisen und prüfen, ob es gestoppt wird
Shell-Regeln: 10 Allow-/Deny-Einträge — Umgehungspfade testen (Pipes, Subshells, Kodierung)
Sandbox-Degradierung: wann jedes der 6 Backends degradiert und ob es dann fail-closed ist
Genehmigungsstufen: requested → presented → decided → recorded — fehlende oder falsch geordnete Stufen suchen
Rechtefläche: Kann ein Werkzeugaufruf den Berechtigungsklassifikator umgehen und direkt schreiben oder ausführen?

Einstiegspunkte: app/src/security, app/src/sandbox, app/src/permission.

Details zu Schwachstellen bitte vertraulich über SECURITY.md melden — kein öffentliches Issue. Öffentliche Issues dienen nur Auditprozess und Abdeckung.

In Issues übernehmen oder fragen Den Sicherheits-Check öffnen

Lieber finanziell unterstützen? Zur Sponsorenseite