R&D_01 · MAIN PROJECT

Kern OS

Eine local-first Steuerungsebene für autonome Software-Agenten.

Kern OS ist die Umgebung, mit der ich Software mit KI-Agenten baue, auch Teile dieser Seite. Du gibst ihr ein Ziel, etwa ein Feature ergänzen oder einen Bug beheben, und sie führt ein Coding-Modell durch die Arbeit wie ein Teil über ein Fließband: Jeder Schritt wird geplant, jede Änderung getestet, bevor sie bleibt, und der ganze Lauf wird aufgezeichnet, sodass du genau siehst, was passiert ist.

Ich habe sie gebaut, weil Agenten im Chatfenster bei allem Echten auseinanderfallen. Nach einer Stunde kannst du nicht sagen, was sich wirklich geändert hat, ob die Tests tatsächlich liefen oder wie du dasselbe Ergebnis nochmal bekommst. Bessere Prompts lösen das nicht; die richtige Maschinerie um das Modell herum schon.

Also läuft jede Aufgabe durch dieselben fünf Stufen, schreibt an jeder Beweise und muss die Verifikation bestehen, bevor eine einzige Zeile den Main-Branch erreicht. Jeder Lauf lässt sich später aus seinen Aufzeichnungen nachspielen. Alles läuft auf meinen eigenen Maschinen: Die Modelle dürfen remote sein, aber Zustand und Kontrolle bleiben hier.

Jede Mission durchläuft dieselben fünf Stufen, in dieser Reihenfolge. Ein Hintergrunddienst besitzt die Schleife und merkt sich alles; die Apps darüber schauen nur zu und geben Befehle.

267 Kernel-Module

33 Daemon-Subsysteme

340+ Integrationstests

4 Operator-Oberflächen

ARCHITEKTUR

Drei Schichten

Die Basis ist ein Kernel aus 267 Modulen. Jedes ist ein reines Funktionspaket: Zustand rein, normalisiertes unveränderliches JSON raus, keine Seiteneffekte. Diese Eigenschaft erlaubt es, dass Kommandozeile, Terminal-UI, Desktop-App und Testsuite eine einzige Implementierung der Geschäftslogik teilen statt vier auseinanderlaufender Kopien.

Auf dem Kernel läuft ein Node.js-Daemon mit 33 Subsystemen. Ihm gehören Missionszustand, die Autonomie-Schleifen, Beweissicherung, Verifikation und Promotion. Wenn ich ein Fenster schließe, läuft die Mission weiter; die Oberflächen halten keinen eigenen Zustand, alles Maßgebliche sitzt im Daemon und auf der Platte.

Die oberste Schicht sind vier austauschbare Operator-Oberflächen: ein CLI, eine Terminal-Workbench, eine React-Desktop-App in Tauri und ein experimentelles Rust-Frontend in Leptos. Alle vier rendern den Missionszustand durch dieselben geteilten Formatierungsmodule; ein Plan sieht im Terminal aus wie in der GUI.

ARENA

Mehrere Kandidaten, verifizierte Auswahl

Schwere Aufgaben gelingen selten beim ersten Versuch, also setzt Kern OS nicht auf einen. Es kann dieselbe Aufgabe an mehrere Agenten zugleich geben, jeder in seiner eigenen privaten Kopie des Codes (einem Git-Worktree), sodass sie nie kollidieren. Jeder kommt mit einer fertigen Änderung zurück und einem Protokoll, wie er dahin kam.

Dann werden die Kandidaten bewertet: lief es sauber, ist die Spur intakt, wie groß ist die Änderung, bestehen die statischen Checks. Der beste geht in Review und, falls nötig, Reparaturrunden, und er muss immer noch Kritik-, Sicherheits- und Benchmark-Checks bestehen, bevor er gemergt werden darf.

Gespeichert werden die Bewertungen und Fingerabdrücke, nicht der volle Code oder die Transkripte, damit ein Ergebnis reproduzierbar bleibt, ohne dass die Aufzeichnungen mit der Zeit aufquellen.

POLICY

Harte Grenzen für jede Änderung

Agenten committen mit Vorliebe, was sie nicht sollten: Build-Ausgaben, heruntergeladene Bibliotheken, riesige generierte Dateien. Ein gemeinsames Regelwerk kennt über achtzig Arten solcher Wegwerf-Pfade und prüft jede Änderung gegen harte Grenzen, höchstens achtzig Dateien und ein Megabyte Code, bevor sie zählen darf.

Es greift an jeder Stelle, an der eine Änderung eintreten kann: Kandidatenprüfung, Merges, Benchmark-Berichte. Der Sinn ist, den Müll-Commit-Fehler per Regel unmöglich zu machen, statt zu hoffen, dass ein Review ihn fängt.

GEDÄCHTNIS

Kontinuität zwischen Sitzungen

Wenn eine Sitzung endet, sollte das Wissen nicht mit ihr sterben. Kern OS führt ein strukturiertes Gedächtnis aus Fakten, Entscheidungen und Lektionen, mit Verknüpfungen, die festhalten, welches Wissen welches ersetzt hat, sodass es nicht nur weiß, was es gelernt hat, sondern auch, was es nicht mehr glaubt.

Eine neue Sitzung liest dieses Gedächtnis, statt alte Chat-Logs erneut zu lesen. Sie bleibt im Projekt scharf, ohne die ganze Geschichte hinter sich herzuschleppen.

BENCHMARKS

Offengelegte Messung

Die Benchmark-Pipeline fährt Terminal-Bench, SWE-Bench und eigene Suiten unter einem Offenlegungsvertrag: Jedes Ergebnis hält fest, welche Konfiguration es erzeugt hat, ein einzelnes Modell oder die volle Kern-OS-Schleife. Einreichungen speichern nur kompakte Metadaten.

Das ist wichtig, weil Agenten-Zahlen ständig falsch berichtet werden. Ein Aufbau, der wiederholt, repariert und verifiziert, schlägt jedes nackte Modell, und die Offenlegung verhindert, dass die beiden Zahlen durcheinandergeraten, auch bei mir selbst.

SKILLS

Kontrollierte Selbstverbesserung

Sobald sich eine Vorgehensweise über genug Missionen bewährt, kann Kern OS sie als wiederverwendbaren Skill speichern. Aber ein Skill muss sich eine Bilanz verdienen und bewusst eingeschaltet werden, bevor eine Mission ihn nutzen darf, und das kompilierte Ergebnis bleibt einsehbar.

Ein System seine eigenen Fähigkeiten umschreiben zu lassen ist der einfachste Weg, leisen, bleibenden Schaden anzurichten. Deshalb hat dieser Pfad mehr Schranken als alles andere im Code.

PRAXIS

Ingenieursdisziplin

Das Projekt trägt über 340 Integrationstests auf dem nativen Node-Testrunner. Ein Release-Gate verkettet Typecheck, Build, Lint, Security-Scan und die volle Suite. Missionen pflegen dauerhafte Vertragsdateien für Architektur, Plan, Fortschritt, Verifikation und Risiko. Eine vollständige Beispielanwendung, Ende zu Ende im System gebaut, dient als permanente Regressionsfläche.

Dieselbe Infrastruktur trägt meine kommerzielle Arbeit: Der Modell-Dispatch, die Verifikationsdisziplin und die Pipeline-Orchestrierung in Kern OS stammen direkt aus der Produktion finaler Bilder und Filme mit KI-Pipelines unter Produktionsterminen.