← KADAI English
KADAI · Konzeptübersicht · Stand 6. Oktober 2026

Ein Desktop, der aus einem Kernel kompiliert wird

KADAI dreht die Reihenfolge um: Nicht Rechner installieren und dann mühsam personalisieren, sondern eine kleine, verschlüsselte, portable Beschreibung der Person - der Kernel - wird auf jeder Maschine zu einem Desktop kompiliert. KDE Plasma ist dabei die Shell erster Klasse, Nextcloud die Speicherschicht, git das Gedächtnis.

compile(me.md, Umgebung) → Desktop

Drei Blöcke, drei Reifegrade (Stand Oktober 2026). KADAI besteht aus drei Teilen, die zusammengehören, aber verschieden weit sind. Der persönliche Kernel mit Identität, Register, Schlüsselbund und Tresor läuft auf drei Maschinen und ist weit. Das flussbasierte Interface, also die Schiene am Bildschirmrand mit Karten, Protokoll und Rückschau statt Fenstern und Chat, steht am Anfang und existiert auf der Labormaschine. Die Unterstützung durch Modelle, also der subsidiäre Router mit seiner urteilenden Instanz, steht ebenfalls am Anfang; sie hängt am Interface, weil dort das Urteil fällt. Abschnitt 1 bis 3 beschreiben den ersten Block, Abschnitt 4 den dritten, der zweite kommt in Abschnitt 4 und 6 vor und bekommt eine eigene Seite, sobald er mehr ist als ein Prototyp.

1 · Die Kernidee

me.md - der Kernel Markdown, stabile IDs, Provenienz je Eintrag, verschlüsselt identitywer ich bin factsmeine Welt (Geräte, Netz, Rolle) valueswofür ich stehe · wägt ab preferenceswie ich arbeiten will · weich ruleswas nie passieren darf · hart episodicwas gerade los ist · evtl. veraltet speichert Bedeutung, nie Konfiguration Umgebung Gerät · Netz · Ort · Zeit wird beim Start erkannt compile Reconciler Desktop (KDE Plasma) Activities als kompilierte Modi Panels, Widgets, Standard-Apps Dateien lazy aus der Cloud Ist-Zustand wird gelesen, nur die Differenz zum Soll wird angewandt episodisch zurück: was neu ist, mit Herkunft und Datum
Der Kernel enthält Aussagen über die Person, nie über die Shell: „vormittags fokussierte Arbeit" statt „Panel unten, Widget X". Ein Plasma-Backend übersetzt das in eine Activity ohne Benachrichtigungen; ein anderes Backend könnte dasselbe in einen Fokus-Modus übersetzen. Diese Trennung ist es, die den Kernel plattformunabhängig macht.

Was der Kernel minimal enthält (Stand 20.9.2026): das, was die Person gesagt hat - nicht, wer sie ist. Die Gründungsseite erzeugt heute einen validen Kernel aus fünf Aussagen (Name, Anrede, Ausführlichkeit, Cloud-Haltung, Anbieter) und erkannter Umgebung (Sprache, Zeitzone, Gerät); die ersten Modi, die Werte und die Regeln kommen als Vorgabe mit und sind später änderbar. Was das System beobachtet - Geräte, Konten, woran gerade gearbeitet wird - ist Daten, nicht Instruktion: Es kann neu erhoben werden und muss nicht in der Datei liegen; der Kernel verweist über me://-Ressourcen darauf. Der Kernel wird damit selbst kompiliert wie der Desktop: compile(Interview, Beobachtungen) → Kernel, dann compile(Kernel, Umgebung) → Desktop. Ein „kleiner Kernel" - Anrede, Modi, Regeln, Präferenzen - ist eine Instanz desselben Formats, kein anderes Design.

2 · Die Schichten - und was davon schon läuft

validiert (lauffähig, Stand Oktober 2026) Design, noch nicht gebaut
Shell - KDE Plasma 6 Activities, Panels, Widgets per DBus-Scripting gesteuert · Layout-Dump als Ist-Zustand plattform-spezifisch Modul-Laufzeit - MCP Fähigkeiten als MCP-Server, Manifest + Sandbox als Vertrauensgrenze; Kernel-Sektionen als me://-Ressourcen Vorschläge - Router und Stufen nach Ort Regeln sind bindend, was hinausgeht wird vorher gezeigt · kleinste ausreichende Stufe zuerst: ohne Modell → auf diesem Gerät → in deinem Netz → bei einem Anbieter Speicher-Tiering - git und Nextcloud git: Kernel, klein, versioniert (= Audit-Log) · Nextcloud: große Dateien, Auslagern/Zurückholen protokolliert und umkehrbar Kernel + Identität me.md verschlüsselt an alle eigenen Maschinen (age), Schlüssel im Sicherheitschip · Schlüsselbund und Tresor daneben · drei Maschinen live portabel läuft auf jedem Linux; Mac/Win als VM-Wirt
KADAIs eigene Erfindung ist klein: Kernel-Format, Identität, der Compile-Schritt, die Plasma-Anbindung. Die Mitte ist Integration bestehender Bausteine (MCP, Nextcloud, git), nicht Neubau. In der Vorschlags-Schicht ist der deterministische Boden bereits bewiesen: Sync, Entschlüsselung, Reconciler und Speicher laufen ohne jedes Modell - fällt jedes Modell aus, wird das System dümmer, nicht funktionsunfähig.

3 · Auf mein System kommen - überall

Die Kernszene: Eine beliebige Maschine wird durch eine Passphrase zu Jans System. Zwei Wege führen hin. Ein generisches Startabbild für eine leere Maschine, bewiesen am 16. August 2026 in einer frischen VM. Und ein Paket für ein laufendes Ubuntu: Adresse öffnen, herunterladen, ein Assistent führt bis in den Desktop, bewiesen am 2. Oktober 2026 auf einem alten Notebook. Beim nächsten Login „Willkommen, Jan" mit dem Datum des Kernel-Stands, und der Desktop wird bei jedem Login aus der Spezifikation im Repo hergestellt.

Kernel-Repo (git, privat) Kernel verschlüsselt · Register autorisierter Maschinen · Master-Identität (passphrase-geschützt) Startabbild oder Paket Abbild: Linux + Plasma, für leere Maschinen Paket: Assistent auf laufendem Ubuntu das Abbild für jeden, das Paket aus deinem Netz starten Erstboot-Zeremonie 1 · Maschine erzeugt ihre eigenen Schlüssel - im Sicherheitschip, wo sie einen hat 2 · Passphrase entsperrt die Master-Identität nur im Arbeitsspeicher 3 · Maschine trägt sich ins Register ein und gibt ihrem Sync-Schlüssel Schreibrecht der Wächter ist austauschbar: heute Passphrase, als Nächstes ein FIDO-Stick klonen Person: Passphrase im Kopf - das einzige, was reist, ohne Datei zu sein nativ · Linux + Plasma voller kompilierter Desktop virtualisiert · macOS, Windows das Seed als VM - legitime Form konversational · iOS, Android kein Desktop: der Assistent kennt den Kernel gleicher Kernel - Compile-Tiefe je nach Plattform
Es gibt keinen zentralen Identitätsanbieter. Identität ist Besitz (Repo-Zugang) plus Wissen (Passphrase) plus ein Register im eigenen Repo - wörtlich souverän. Ein verlorenes Gerät wird durch Streichen einer Zeile und Neuverschlüsselung widerrufen.

4 · Wo Vorschläge entstehen: eine Rolle, kein festes Modell

0 · ohne Modell Skripte: Sync, Reconciler, Speicher System bleibt betriebsfähig - garantiert 1 · auf diesem Gerät kleines Modell, offline der Normalfall: nichts verlässt das Gerät 2 · in deinem Netz mittleres Modell auf eigenem Rechner verlässt deine Infrastruktur nicht 3 · bei einem Anbieter stärkstes Modell, fremde Cloud je Aktion, mit Vorschau und einem Ja → eine Stufe höher nur, wenn die vorige messbar nicht ausreicht, und nur so weit, wie die Regeln es erlauben · nach rechts: fähiger, weniger privat
Subsidiarität: Der Router beginnt bei der kleinsten Stufe, die für diese Aufgabe bisher ausgereicht hat, und steigt erst auf, wenn das Ergebnis messbar nicht genügt. Was der Mensch annimmt oder verwirft, bestimmt die Startstufe des nächsten Mals. Vor jedem Schritt zu einem Anbieter zeigt er, was die Maschine verlassen würde, und wartet auf ein Ja, das für eine Aktion gilt, nicht für die Sitzung. Prototyp im Labor seit September 2026: 0,8-Milliarden-Modell auf dem Gerät, 2-Milliarden-Modell im Netz, Anbieter hinter Zustimmung; Konzept in kadai-subsidiarity.md.

Die urteilende Instanz (seit 4. Oktober 2026). Niemand weiß vorher, welche Stufe eine Aufgabe braucht; wer das vorab beurteilen soll, rät. Die Instanz misst nachher und merkt sich das, in vier Teilen. Einordnung: die Aufgabenart plus messbare Merkmale der Eingabe ohne Modell, Länge, Sprache, ob Wissen von außen gefragt ist; die Statistik läuft je Art und Längenklasse. Decke: die niedrigste aus Modellregister, Datenklasse der Eingabe (Kontonummern, Gesundheit, Geld, fremde Kontaktdaten, Inhalt des eigenen Kernels), Limit-Blöcken in den Regeln des Kernels und den Pins der Person; der Grund steht auf der Karte. Prüfung: formale Prüfer je Art, dann der Mensch; „Besser" auf der Karte zählt als Urteil gegen die gezeigte Stufe. Rückschau: in der Schiene, je Aufgabenart, wo sich die Stufe eingependelt hat, mit Sekunden und Energieschätzung, und dort die Pins „nie darunter", „nie darüber". Das ist die Buchhaltung mit Messlatte, kein Orakel.

5 · Was das für KDE bedeutet

Was Plasma 6 heute schon kann - validiert

  • evaluateScript über DBus funktioniert von außerhalb der Sitzung, lesend und schreibend (Wallpaper, Widgets, Panels) - auch unter Wayland
  • dumpCurrentLayoutJS() liefert den kompletten Desktop-Zustand als ausführbares Skript - ein eingebauter Serialisierungs-Roundtrip
  • Activities sind vollständig skriptbar (anlegen, benennen, wechseln, je eigene Desktop-Konfiguration) - der „kompilierte Modus" existiert bereits als Container
  • Befund: loadSerializedLayout ist additiv, nicht idempotent - daher lebt der Abgleich in KADAI (Diff-and-Apply), nicht im Layout-Load

Was KADAI sich von Plasma wünschen würde

  • eine deklarative Reconcile-API: „hier ist der Soll-Zustand, gleiche an" - statt imperativer Skripte
  • eine kernel-bewusste Widget-Basisklasse, die me://-Ressourcen unter Regelkontrolle liest
  • ein Activity-Metadaten-Schema (Zweck, Kernel-Ausschnitt, Module, Geräte), damit Activities portabel werden
  • Capabilities je Widget: ein Widget darf Präferenzen lesen, aber nicht Identität - und nicht ohne Freigabe ins Netz

Die Wünsche sind bewusst klein gehalten: Alles Wesentliche wurde mit dem heutigen Plasma bewiesen. Die Punkte rechts würden KADAI von einem Aufsatz zu einem Bürger der Plattform machen - und sie sind genau die Fragen, die sich jeder stellt, der Plasma als Zielshell für automatisierte, personalisierte Arbeitsplätze denkt.

6 · Stand der Dinge - ehrlich

Bewiesen, lauffähig

  • Seed → Zeremonie → verschlüsselter Kernel → begrüßter, reconcilter Desktop (16. und 29.8.2026)
  • Beitritt auf laufendem Ubuntu: Paket laden, Assistent, Passphrase, Desktop (2.10.2026, altes Notebook, erster echter Lauf)
  • Drei Maschinen gleichzeitig: Änderungen werden je Eintrag zusammengeführt, was nicht entscheidbar ist, wird Vorschlag statt Überschreibung (seit 26.9.2026)
  • Schlüssel im Sicherheitschip: Secure Enclave auf dem Mac, TPM in der VM; getrennter Sync-Schlüssel ohne Präsenzpflicht; Dateischlüssel nur, wo kein Chip ist, und dann gesagt
  • Schlüsselbund und Tresor als KeePass-Dateien neben dem Kernel: Systemzugänge für die Geräte, eigene Passwörter nur für die Person (2./3.10.2026)
  • Kernel-Sync: lokale Sicherung alle zehn Minuten, Push bei An- und Abmeldung und stündlich; git-Historie als Audit-Log; Repository auf eigenem Server (Forgejo)
  • Reconciler (idempotent) und Speicher-Tier gegen Nextcloud (auslagern, zurückholen, pinnen, protokolliert)
  • Deklarativer Desktop: Spezifikation im Repo, jede Maschine kompiliert sich beim Login selbst; die Spezifikation kennt heute Activities, Farbe und Panel-Elemente, mehr nicht
  • Subsidiärer Router mit zwei Modellen und einem Anbieter hinter Zustimmung, KRunner als Eingang, Schiene am rechten Rand (Labormaschine, September 2026)
  • Urteilende Instanz im Router: Merkmale der Eingabe, Decke aus Datenklasse, Kernelregel und Pins, „Besser" als Urteil, Rückschau mit Pins in der Schiene (4. und 5.10.2026, Labormaschine)
  • Anbieter-Zugang im Schlüsselbund statt in einer Datei je Maschine: alle drei Maschinen erreichen dieselbe oberste Stufe (5.10.2026)
  • Kernel und Code auf eigenem Server (Forgejo), alle drei Maschinen dorthin umgezogen (2. bis 5.10.2026)

Design, noch offen

  • Modul-Laufzeit über MCP mit Manifest und Sandbox
  • Modell und Schiene auf jeder Maschine, nicht nur im Labor; automatische episodische Einträge am Sitzungsende, jederzeit löschbar
  • Die Personenidentität auf Hardware: ein FIDO-Stick statt der Passphrase, danach das Telefon; Festplattenverschlüsselung im Seed
  • Ableitung der Desktop-Spezifikation direkt aus dem Kernel (heute noch handgeschrieben und sehr knapp)
  • Windows-Formate über eine Build-Pipeline; iOS-Client für die konversationale Stufe; der Tresor auf dem Telefon
  • Beobachtungsdaten als eigene synchronisierte Schicht: heute Anhängelogs je Maschine, nicht abgeglichen; abgeleiteter Zustand wird je Maschine neu berechnet
  • Beobachtungsdaten außerhalb des Kernels, in einem eigenen Speicher, auf den me:// zeigt - die Datei enthält nur noch Instruktionen
  • Ein kleiner lokaler Prüfer, der inhaltlich beurteilt, ob die Aufgabe getroffen wurde; heute prüfen nur Form und Mensch
  • Ein Eingang für jede Distribution: ein Startskript, das Debian, openSUSE, Fedora oder Arch erkennt und das Passende nachzieht; heute ein Paket für Ubuntu
  • Die Klasse „Skript" mit einem Agenten-Motor in der Sandbox, der Workflow-Skripte für Activities schreibt und testet
KADAI ist ein Projekt von Jan Mühlig. Die Architektur ist dokumentiert in kadai-architecture.md (Schichten, Entscheidungen, offene Fragen), das Seed-Handbuch in kadai-seed.md; der Kernel-Prototyp me.example.md zeigt das Format. Kernel, Schlüsselbund und Skripte liegen in einem privaten git-Repository auf eigenem Server (Forgejo), die Startabbilder auf Nextcloud.