KAUT — Wissensaktualisierung unter Vertrauen

Macht Alt-Codebasen KI-nativ. KAUT ist selbstwartende, KI-erste Dokumentation für Ihr Projekt — eine Wissensebene, die undokumentierten, kontextschwachen Code für KI-Agenten lesbar macht. Kein Gedächtnis für Gespräche — eine Wissensbasis über das System selbst: was es tut, wie es strukturiert ist und warum. Es verwandelt das, was Agenten während der Arbeit lernen, in lebendige Dokumentation — so startet keine Sitzung bei null.

Null-Abhängigkeiten Node.js (≥ 20, entwickelt auf 24), Apache-2.0. Entwickelt und getestet auf macOS und Linux (CI läuft auf Linux, Node 20 und 24); Windows wird nicht unterstützt.

Ein vollständiges, eigenständiges Produkt. Ein git clone ist die gesamte Installation; richten Sie Ihre Umgebung auf den gebündelten MCP-Server aus (oder rufen Sie die CLI aus jedem Skill/Prompt auf) und es funktioniert — kein Orchestrator, kein Framework, keine Dienste, keine Konten, nichts anderes zu bereitstellen. Es komponiert mit dem Schwester-Framework TAUT (TAUT steuert Agenten, KAUT ist das, was sie wissen) — aber diese Integration ist optional, keine Abhängigkeit.

Status: v0.8.1 — die vollständige Schleife ist live. Lesen: lookup (Antwort mit einem Aufruf) mit Frische-Urteilen (merge-base-verankert, schreit nie „frisch", wenn unsicher), Vertrauensstufen und das altitude-Abdeckungsband; Manipulationsschutz hält alles zurück, was außerhalb der Pipeline bearbeitet wurde. Multi-Repo: Workspace-Registry, Mitglieder-Stores, ein System-Store, der an einem Launcher-Repo verankert ist. Schreiben: das mehrschichtige Schreib-Gate (Agenten-Stufen-Updates landen direkt; Eigentümer-gesperrte Ebenen und neue Dokumente werden als Entwürfe für die asynchrone Überprüfung eingereiht). Wartung: refresh (Neuableitungs-Delta-Bündel), touched (Änderungsstellen-Sensor), digest/note (Nutzungs- und Ergebnis-Telemetrie). Interoperabilität: Stores erfüllen die OKF-v0.2-Konformitätsstufe und kaut okf export erzeugt idiomatische OKF-Bündel. Jede MCP-fähige Umgebung schließt sich über den gebündelten MCP-Server an. Was im Detail live ist: docs/HANDBOOK.md §16.

Das Problem, das es löst

Jede neue KI-Sitzung beginnt mit Amnesie: Der Agent erkundet Ihr Projekt erneut, stellt dieselben Fragen wieder und — am schlimmsten — macht weiterhin die teuerste Art von Fehler: Code, der kompiliert und Tests besteht, aber leise eine Geschäftsregel bricht, von der er keine Möglichkeit hatte zu wissen.

Das „Warum" eines Projekts ist normalerweise nirgendwo geschrieben. KAUT gibt ihm einen Ort zum Leben — und hält es am Leben.

Das trifft am härtesten auf Alt-Code zu: Jahre undokumentierter Entscheidungen, keine ursprünglichen Autoren in der Nähe, Geschäftsregeln nur als Nebeneffekte sichtbar. Genau dort schneiden KI-Codierungswerkzeuge heute am schlechtesten ab — und genau für diese Codebasis ist KAUT gebaut. KAUT ist der erste Schritt eines größeren Ziels: Alt-Codebasen KI-nativ zu machen — so strukturiert, dass Agenten sicher und kostengünstig daran arbeiten können.

Related MCP server: 50 First Tapes MCP Server

Was KAUT ist — und was nicht

Drei vertraute Kategorien sehen aus der Ferne ähnlich aus. KAUT ist keine von ihnen — und die Unterschiede sind genau dort, wo der Wert liegt.

Kein weiteres Gedächtnissystem. Gedächtnis beantwortet „worüber haben wir gesprochen, was bevorzugt dieser Benutzer?" — persönlich, episodisch, nicht verifizierbar. KAUT beantwortet „wie funktioniert dieses Projekt, und warum?" — Dokumentation: nach Domäne organisiert, quellgebunden, frischheitsgeprüft, vertrauensgekennzeichnet, und lesbar für jeden Agenten und für Menschen. Persönliche Notizen gelangen nie in KAUT; Projektwissen bleibt nie im Gedächtnis eines einzelnen Agenten gefangen. Diese Grenze ist in den Schreibpfad eingebaut.

Kein RAG. Retrieval-Augmented Generation indexiert, welcher Text auch immer existiert, und serviert die bestpassenden Chunks — ohne zu wissen, ob sie noch wahr sind. KAUT speichert die gegenteilige Auswahl: nur Wissen, das teuer neu abzuleiten und nicht billig im Code sichtbar ist (der Speicher-Lackmustest), destilliert in kurze Dokumente, die ein Modell vollständig liest — keine Einbettungen, kein Ranking, keine Chunk-Suppe. Und jedes Dokument trägt ein maschinell geprüftes Frische-Urteil: verankert am Commit, von dem es abgeleitet wurde, bei jedem Lesen gegen den verfolgten Hauptzweig diffed, in Richtung stale tendierend, wenn git es nicht anders beweisen kann. Führen Sie RAG über Ihren Code aus, wenn Sie möchten — KAUT ist für das, was der Code nicht sagt: das Warum, die querliegenden Invarianten, das Stammeswissen.

Kein LLM-Wiki. Automatisch generierte Dokumentation ist plausibler Text, bei der Geburt unverifiziert und beim ersten Commit verlassen. Ein KAUT-Dokument kann nicht ohne typisierte Quellbindungen und einen Anker-Commit existieren — und kann nicht still falsch bleiben, weil die Quellen bei jedem Lesen diffed werden. Der Schreibpfad ist die andere Hälfte: mechanische Ebenen regenerieren automatisch, Agenten dürfen betriebliche Fakten landen, die sie in der Sitzung verifiziert haben, aber Urteils-Wissen (Entscheidungen, Domänensemantik, Verträge) gelangt nur durch ein menschlich genehmigtes Tor — Updates warten als Entwürfe, die Sie in Stapeln überprüfen. Ein Wiki verfällt standardmäßig; KAUTs Standard ist zu gestehen.

Und es ist kein proprietäres Silo. KAUT ist eine Implementierung des anbieterneutralen Open Knowledge Format (OKF) v0.2 — Stores sind typisierte Markdown-Konzeptdokumente, die OKFs Konformitätsstufe direkt erfüllen, und kaut okf export projiziert jeden Store in ein vollständig idiomatisches OKF-v0.2-Bündel (einschließlich Herkunfts-, Vertrauens- und Lebenszyklus-Familien), lesbar für jeden OKF-Konsumenten. KAUTs Frische-/Vertrauensmechanik sitzt obenauf als OKF-geschützte Erweiterungsschlüssel: Das Format zeichnet Wissen auf — die Engine hält es wahr. Die normative Zuordnung steht in SCHEMA.md.

Prinzipien

1. Quellgebunden, commit-verankert. Jede Tatsache benennt die Dateien, aus denen sie stammt, und den Commit, an dem sie abgeleitet wurde. Keine Quelle, kein Dokument — der Vertrag wird an der Tür validiert.

2. In Richtung stale tendieren. Frische ist eine reine git-Berechnung (merge-base gegen den verfolgten Hauptzweig). Wenn git nicht beweisen kann, dass ein Dokument aktuell ist, sagt das Urteil das. KAUT schreit nie „frisch", wenn unsicher — ein falsches „stale" kostet eine erneute Prüfung; ein falsches „frisch" liefert einen Bug aus.

3. Wissen informiert; es autorisiert nie. Ein gesundes Urteil ist die Erlaubnis, die Neuableitung zu überspringen, nicht die Erlaubnis zu handeln. Urteile leiten Vertrauen: gesund + präzise = unverändert nutzbar; stale / gebrochen / grobe Höhe = zuerst im Code bestätigen.

4. Servieren Sie nichts, wofür Sie nicht bürgen können. Der Store wird von KI-Agenten gelesen, also ist eine Bearbeitung außerhalb der Pipeline ein Injektionskanal, keine Bequemlichkeit. Alles, was nicht byte-identisch mit dem letzten Pipeline-Commit ist, wird vollständig zurückgehalten (tampered), bis es wiederhergestellt oder ordnungsgemäß gelandet ist.

5. Menschen besitzen Urteile; Agenten besitzen Mechanik. Das mehrschichtige Schreib-Gate: Karten regenerieren frei, verifizierte betriebliche Fakten landen auf Agenten-Ebene, und Entscheidungs-/Domänen-/Vertragswissen wartet in einer Entwurfswarteschlange auf die Ein-Tasten-Überprüfung des Eigentümers.

6. Reparieren Sie dort, wo es am billigsten ist. Frische-Verfall wird strukturell bekämpft, nicht heroisch: die Änderungsstelle (touched benennt die Dokumente, die eine Codeänderung schuldet), die Lesestelle (ein stale-Urteil kommt mit einem refresh-Delta-Bündel — genau was sich geändert hat, wogegen neu abzuleiten), und ehrliche Telemetrie (digest), um zu sehen, ob die Pflege Schritt hält.

7. Lokal zuerst, null Abhängigkeiten, Repo unberührt. Ein Klon, kein Installationsschritt, kein Daemon, keine Cloud; der Wissensspeicher lebt außerhalb Ihres Repositorys, und Frischeprüfungen kosten git-Vergleiche — keine Modellaufrufe.

Was KAUT tut

• Ein bekannter Ort zum Nachschauen. Der Agent prüft KAUT, bevor er Ihren Code erneut erkundet. Entweder ist die Antwort da, oder KAUT notiert die Lücke, damit sie später gefüllt wird.

• Wissen sammelt sich selbst. Nach einer erledigten Aufgabe wird das Nützliche, das der Agent gerade gelernt hat, in die Basis kondensiert — ein Nebenprodukt bereits bezahlter Arbeit, kein separates Dokumentationsprojekt.

• Es lügt nie selbstbewusst. Jede gespeicherte Tatsache bleibt mit dem Code verbunden, aus dem sie stammt. Wenn sich dieser Code ändert, wird die Tatsache automatisch als möglicherweise veraltet gekennzeichnet. Im Zweifel sagt KAUT „überprüfen Sie das erneut", statt so zu tun, als wäre alles frisch.

• Es weigert sich, zu servieren, wofür es nicht bürgen kann. Die Wissensbasis wird von KI-Agenten gelesen, also ist eine Datei, die hinter KAUTs Rücken (außerhalb seiner eigenen Versionskontrolle) bearbeitet wurde, ein potenzieller Injektionskanal. Solcher Inhalt wird vollständig zurückgehalten, bis er wiederhergestellt oder ordnungsgemäß neu committet wird — jede Antwort, die der Agent sieht, stammt aus einem herkunftsverfolgten Commit.

• Sie bleiben der Richter. Eigentümer-gesperrte Ebenen und neue Dokumente landen nie ohne Ihre Genehmigung: Updates warten als Entwürfe (kaut draft), und Sie landen oder verwerfen den gesamten Stapel in einer Sitzung (kaut review). Sie müssen nicht anwesend sein, wenn der Agent fertig ist.

• Ihr Repository wird nie berührt. Alles Wissen lebt in einem separaten Ordner außerhalb des Projekts. Ihre git-Historie, Zweige und Teamkollegen sehen es nie.

• Jeder Agent kann sich anschließen. Neben der CLI liefert KAUT einen MCP-Server (node <engine>/mcp.mjs, null Abhängigkeiten) — dieselben Lookups, Frische-Urteile und gated Schreibvorgänge als MCP-Tools, für jede MCP-fähige Umgebung oder jeden Orchestrator. Ein Server verwaltet einen ganzen Multi-Repo-Workspace (jeder Aufruf benennt sein Repo).

Architektur

flowchart LR
    subgraph clients["Clients"]
        direction TB
        HARNESS["AI agents\nany MCP-capable harness"]
        HUMAN["Humans and CI\nshell, scripts"]
        ORCH["Orchestrator, e.g. TAUT\n(optional)"]
    end

    subgraph engine["KAUT engine - stateless, zero-dep Node, no daemon"]
        direction TB
        SURF["Two surfaces\nmcp.mjs - 7 MCP tools\nkaut.mjs - CLI"]
        READP["READ path (lock-free)\nlookup / stale / digest\nfreshness verdict = pure git computation\n+ trust tier + altitude on every answer"]
        WRITEP["WRITE path (one chokepoint)\nlayered write gate + draft queue\nagent tier lands, judgment tier\nwaits for owner review"]
        MAINTP["Maintenance loop\nrefresh / touched / note\nmap collectors (stack adapters)"]
    end

    subgraph home["Knowledge data home - set once with kaut home"]
        direction TB
        STORES["One store per repo\ntyped markdown + frontmatter\nown private git = audit + rollback\njournal telemetry"]
        REG["workspaces registry\nmember stores + one system store"]
        BACK["backups/\nkaut backup / restore"]
    end

    REPOS["Your repositories\nREAD-ONLY sources\n(at most one git-ignored pointer file)"]
    OKFB["OKF v0.2 bundle\nkaut okf export"]

    HARNESS --> SURF
    HUMAN --> SURF
    ORCH --> SURF
    SURF --> READP
    SURF --> WRITEP
    SURF --> MAINTP
    READP -- "diff sources against\nthe anchor commit" --> REPOS
    MAINTP -- "derive maps from code" --> REPOS
    READP <--> STORES
    WRITEP --> STORES
    STORES --> OKFB

Die Form in vier Sätzen. Die Engine ist zustandslos — jeder Befehl (CLI oder MCP-Tool) berechnet seine Antwort aus zwei Git-Historien und beendet sich; es gibt nichts Residentes, das laufen, synchronisieren oder korrumpieren könnte. Wissen lebt außerhalb Ihrer Repositories, ein Store pro Repo im Datenverzeichnis, und jeder Store ist sein eigenes privates Git-Repository — genau das ermöglicht das Schreib-Gate, die Manipulationsbegrenzung, die Auditierung und das Rollback. Der Lesepfad blockiert nie und rät nie: Ein Urteil wird durch den Diff der typisierten Quellen eines Dokuments gegen seinen Anker-Commit in dem Moment abgeleitet, in dem Sie fragen. Der Schreibpfad hat genau einen Engpass, sodass Richtlinien (Agent-Stufe vs. Inhaber-Review) nicht durch die Wahl eines anderen Befehls umgangen werden können.

Schnellstart

1. Klonen Sie die Engine neben die Repositories, die sie bedienen soll (ein Geschwisterordner — das Setup scannt seine Nachbarn; es gibt kein npm install, die Engine hat null Abhängigkeiten):

cd ~/projects && git clone https://github.com/yurgeno/kaut.git

2. Führen Sie das Setup aus — drei Fragen, und jede Antwort hat ein Flag für scriptete Installationen:

node kaut/kaut.mjs setup

• Wissensdatenordner — wo die Stores leben (Standard: <siblings>/kaut-data). Einmalig persistiert (die kaut home-Umleitung): Jeder spätere Befehl und der MCP-Server lösen ihn selbst auf — nichts zu exportieren, nichts zu übergeben. Dieser Ordner ist Live-Daten: Die Engine fügt ihm nur etwas hinzu; nichts Bestehendes wird gelöscht oder überschrieben.

• Welche Repositories — das Setup listet jedes Geschwister-Git-Repository auf; antworten Sie mit all, Zahlen oder Namen.

• Jetzt bootstrappen? — ja erstellt/aktualisiert sofort einen Store pro ausgewähltem Repo (idempotent: bestehende Stores werden aktualisiert, nie neu befüllt); nein zeichnet nur die Konfiguration auf und gibt die Befehle pro Repo für später aus.

Nicht-interaktiv: node kaut/kaut.mjs setup --data <dir> --repos all --bootstrap --yes (--no-bootstrap, --scan <dir> zum Scannen an anderer Stelle).

3. Folgen Sie den gedruckten nächsten Schritten — das Setup endet mit genau zwei: Verbinden Sie den MCP-Server mit Ihrer Umgebung und fügen Sie den Wissensvertrag in Ihre Agent-Anweisungen ein (beides unten). Optional die mechanische Karte pro Repo generieren:

node kaut/kaut.mjs map

(Das Bootstrap hat Ihren Stack bereits erkannt und die richtigen Kollektoren eingepflanzt — siehe Unterstützte Stacks unten; ein Kollektor, dessen Eingabe fehlt, überspringt sich selbst mit einem Hinweis, und map.collectors: [] bedeutet, dass die Kartenschicht einfach leer bleibt).

Unterstützte Stacks

Bootstrap, die Wissensschleife, Frische-Urteile, das Schreib-Gate — alles davon ist stack-agnostisch: Jedes Git-Repository funktioniert. Nur die mechanische map/-Schicht ist stack-spezifisch, und das Bootstrap erkennt den Stack automatisch und befüllt map.collectors entsprechend (bestehende Konfigurationen werden nie angefasst; jeder Regler bleibt überschreibbar):

Ein Repo ohne erkennbaren Stack erhält eine leere Kartenschicht, und alles andere funktioniert gleich. Die lexikalischen Kollektoren sind ehrliche Best-Effort-Scans, die im generierten Dokument als solche gekennzeichnet sind. Adapter für weitere Stacks sind bewusst kleine Module — siehe CONTRIBUTING.md, falls Ihrer fehlt.

Ihre Agenten verdrahten — der Schritt, der es real macht

Ein Store allein ändert nichts: Ihr Agent muss wissen, dass er existiert und wann er ihn konsultieren soll. Zwei Schritte (vollständiger Leitfaden mit einfügefertigen Blöcken und einer durchgearbeiteten Sitzung: docs/AGENT-INTEGRATION.md):

1. Verbinden Sie den MCP-Server mit Ihrer Umgebung (.mcp.json für Claude Code, config.toml für Codex — Snippets im Leitfaden). Die sieben kaut_*-Tools erscheinen in jeder Sitzung, und ihre Beschreibungen lehren das Modell bereits die Disziplin: erst nachschlagen, bevor neu erkundet wird; Vertrauen nach dem Urteil ausrichten; über das Gate zurückschreiben.

2. Fügen Sie den Wissensvertrag in das ein, was Ihr Agent in jeder Sitzung lädt (CLAUDE.md / AGENTS.md / Systemprompt) — ein ~15-zeiliger Block aus dem Leitfaden, der das Verhalten zuverlässig statt gelegentlich macht: erst lesen, bevor neu abgeleitet wird; gesund + präzise = wie ist verwenden, veraltet/grob = im Code bestätigen; Ergebnisse mit kaut_note taggen; nach dem Bearbeiten von Dateien kaut_touched ausführen und reparieren oder einreihen, was die Änderung schuldet.

Optional den Vertrag als Harness-Skill verpacken (Vorlage im Leitfaden) oder ein Orchestrierungs-Framework die Verdrahtung für Sie zusammenstellen lassen — TAUT macht das aus einer Setup-Antwort. Dann: arbeiten Sie wie gewohnt. Falls Sie jemals selbst stöbern möchten, gibt node <engine>/kaut.mjs lookup den Katalog der Themen aus.

Tägliche Nutzung — es gibt keine

KAUT ist darauf ausgelegt, unsichtbar zu sein. Sie werden es in genau drei Momenten bemerken:

• Auf Ihren Befehl — sagen Sie dem Agenten, es solle speichern, was es gerade gelernt hat („persist this to KAUT"): Es filtert die Erkenntnisse der Sitzung durch den Lackmustest, schreibt sie mit korrekten Quellbindungen und committet sie in das Git des Stores. Inhaber-gate-tes Wissen stoppt weiterhin in der Entwurfswarteschlange für Ihre Prüfung.

• Wenn sich Entwürfe ansammeln — kaut review listet auf, was auf Sie wartet; genehmigen oder ablehnen Sie den Stapel in einer Sitzung (doctor warnt auch, während eine Warteschlange ansteht).

• Gelegentlich stellt der Agent eine Frage, die nur ein Mensch beantworten kann („Ist diese Regel beabsichtigt oder ein Unfall?"). Ihre Antwort wird zur wertvollsten Art von Wissen in der Basis.

Alles andere — Nachschlagen, Frische prüfen, Karte neu aufbauen — geschieht automatisch und lautlos.

Befehle

Von überall innerhalb eines Projekt-Git-Repositorys ausführen:

node <engine>/kaut.mjs setup         # guided install: data home, sibling-repo scan, bootstrap (run once, from anywhere)
node <engine>/kaut.mjs bootstrap     # create/repair the project's knowledge store (idempotent)
node <engine>/kaut.mjs index         # regenerate INDEX.md (under lock; auto-commits changes)
node <engine>/kaut.mjs doctor        # integrity checks; exit 0 = healthy
node <engine>/kaut.mjs home [<dir>]  # show or set the knowledge-data home (redirect at ~/.kaut/config.json)
node <engine>/kaut.mjs paths         # print resolved {projectId, root, engine, repo, mainBranch, source}
# reading core:
node <engine>/kaut.mjs lookup [<id>] # one-call ready block; no id = catalog; unknown id = miss (exit 0)
node <engine>/kaut.mjs stale [<id>…] # freshness verdicts for all/selected docs (read-path, no lock)
node <engine>/kaut.mjs map           # regenerate L0 maps per config map.collectors + commit
# maintenance loop:
node <engine>/kaut.mjs refresh [<id>…]        # per-doc re-derivation delta bundles (read-only)
node <engine>/kaut.mjs draft <id>             # queue a finished doc update for async owner review
node <engine>/kaut.mjs review [<id>…]         # owner side: list / diff / --approve / --reject
node <engine>/kaut.mjs touched <file>…        # which docs bind the given changed files
# telemetry:
node <engine>/kaut.mjs note <topic> <result>  # record an in-session outcome (trusted|confirmed|insufficient|stale-misled)
node <engine>/kaut.mjs digest [--since <ISO>] # aggregate journal telemetry across workspace stores
# backup / restore (the whole data home — stores, registry, setup record):
node <engine>/kaut.mjs backup                 # dated, versioned .tar.gz under <data>/backups/
node <engine>/kaut.mjs restore [latest|<file>] [--force]   # no arg = list; never overwrites without --force
# open format (OKF v0.2):
node <engine>/kaut.mjs okf check              # store-as-OKF-bundle conformance report (exit 0 = conformant)
node <engine>/kaut.mjs okf stamp              # backfill `type:` on legacy docs (through the write gate)
node <engine>/kaut.mjs okf export --out <dir> # project committed HEAD into an idiomatic OKF v0.2 bundle
# workspace (multi-repo):
node <engine>/kaut.mjs workspace init --manifest <conductor>/manifest.json
                                     # registry + member stores + ONE system store anchored to the launcher
node <engine>/kaut.mjs workspace list

MCP-Server: node <engine>/mcp.mjs — ein abhängigkeitsfreier stdio-JSON-RPC-Server, der die Sitzungsverben als MCP-Tools bereitstellt (kaut_lookup, kaut_note, kaut_refresh, kaut_touched, kaut_write, kaut_draft, kaut_status). Jedes Tool akzeptiert ein optionales repo-Argument, sodass ein Server einen ganzen Multi-Repo-Arbeitsbereich bedient. Die Inhaber-Ausführungen (review --approve, index --approve) sind bewusst nicht über MCP verfügbar.

Flags: --dry-run (Aktionen drucken, ohne zu handeln) · --json (Maschinenausgabe für stale|lookup|refresh|review|touched|digest) · --quiet · --approve / --reject (Inhaber-Ausführung) · --force (restore: bestehende Daten überschreiben; okf export: in ein nicht-leeres Verzeichnis schreiben) · --out <dir> (okf export) · --note <text> (note, review --reject) · --manifest <path> (workspace init) · --workspace <name> (doctor/stale/digest über einen Arbeitsbereich) · --since <ISO-date> (digest) · --help/-h (Verwendung, Exit 0).

Exit-Codes: 0 ok · 1 Validierungs-/Doctor-Fehler · 2 Store belegt (Sperre gehalten) · 3 Umgebung fehlt (kein Git-Repo / Store nicht gebootstrappt).

lookup und stale sind Lesepfad — sie nehmen keine Sperre und hängen nur eine Zeile an journal.jsonl an (Nutzungstelemetrie, ungetrackt). Ein Frische-Urteil ist Daten, kein Fehler: stale beendet sich mit 0, selbst wenn Dokumente veraltet sind. Urteilszeile, höchstens eine, nach Priorität tampered > disputed > broken > stale > branch-advisory; ein gesundes Dokument rendert sauber.

Operative Tiefe — Store-Layout auf der Platte, Auflösungsreihenfolge, Manipulationsbegrenzung und das Schreib-Gate im Detail, Deinstallation, Engine-Interna: docs/OPERATIONS.md.

Konfiguration

Eine Datei: kaut.config.json im Store (vom Bootstrap erstellt, sinnvolle Standardwerte). Die meisten Menschen berühren nur den map-Block (Kollektorliste und Dateispeicherorte — siehe den Schnellstart-Hinweis oben). Die vollständige Referenz dessen, was die Engine tatsächlich liest: docs/HANDBOOK.md §15.

Hilft es tatsächlich?

KAUT ist darauf gebaut, sich selbst ehrlich zu halten:

• Es führt ein Nutzungsjournal pro Store (journal.jsonl): jede Suche mit ihrem Urteil, jedes gate-te Schreiben, jedes aufgezeichnete Ergebnis. kaut digest aggregiert es über einen Arbeitsbereich zu Reichweiten-/Selbstwartungs-/Wertsignal-Zahlen.

• Sitzungen zeichnen auf, wie ein Dokument tatsächlich abgeschnitten hat (kaut note <topic> trusted|confirmed|insufficient|stale-misled) — das Ehrensystem-Wertsignal, das zeigt, wo Wissen Arbeit gespart und wo es in die Irre geführt hat.

• Benchmarking erfolgt extern (dieselbe Aufgabe mit und ohne KAUT ausführen und vergleichen); die Engine liefert bewusst keinen Benchmark-Harness mit.

Das Journal ist append-only, ungetrackte Telemetrie und wächst unbegrenzt; es ist sicher, alte Zeilen manuell zu kürzen (es ist nie Wissen, und digest sieht einfach eine kürzere Historie).

Backup

Der Datenordner ist die gesamte Datenbank — behandeln Sie ihn entsprechend. kaut backup packt das gesamte Datenverzeichnis (jeden Store mit seiner Git-Historie, das Arbeitsbereichsregister, den Setup-Datensatz) in ein datiertes, versioniertes Archiv unter <data>/backups/ — ein einfaches .tar.gz (handgerolltes ustar + node:zlib, null Abhängigkeiten), das auch jedes Standard-Tar-Tool lesen kann. kaut restore latest (oder ein Dateiname) bringt es zurück; nichts Bestehendes wird jemals ohne --force überschrieben — eine verweigerte Wiederherstellung listet die Konflikte auf und fasst nichts an.

Tests

cd <engine> && node --test          # 213 tests, zero deps (node:test)

Führen Sie das nackte node --test aus — übergeben Sie nicht das Testverzeichnis als Argument (auf Node ≥ 24 schlägt diese Form fehl, die Suite aufzulösen).

Deinstallation

Löschen Sie das Store-Verzeichnis (~/.kaut/<project-id>) und die Zeigerdatei (<repo>/.kaut.json), und entfernen Sie die .kaut.json-Zeile aus <repo>/.git/info/exclude. Ihr Repository wurde von Anfang an nie modifiziert — es gibt nichts anderes zu bereinigen.

FAQ

Ist das nur ein weiteres Agent-Gedächtnissystem? Nein. Agent-Gedächtnis erinnert sich an Gespräche und Präferenzen; KAUT ist die Dokumentation des Projekts — AI-first, quellgebunden, frischegeprüft. Der Schreibpfad durchsetzt die Grenze: Projektwissen geht an KAUT, persönliche Präferenzen gehen in das eigene Gedächtnis des Agenten.

Ist das RAG? Nein. Es gibt keine Embeddings, kein Chunking, kein Retrieval-Ranking. KAUT speichert eine kleine Menge destillierter Dokumente, die ein Agent ganz liest, jedes mit Herkunft und einem git-berechneten Frische-Urteil — und speichert bewusst nur das, was nicht billig aus dem Code ableitbar ist. RAG über Ihre Codebasis und KAUT beantworten verschiedene Fragen und koexistieren problemlos.

Ist das ein automatisch generiertes Wiki? Nein. Nichts gelangt als unverifizierter generierter Prosa in den Store: Jedes Dokument muss typisierte Quellbindungen und einen Commit-Anker tragen, mechanische Schichten werden regeneriert (nicht halluziniert), und Wissen auf Urteilsebene passiert ein menschlich-genehmigtes Gate. Und anders als ein Wiki kann ein KAUT-Dokument nicht still verrotten — seine Quellen werden bei jedem Lesen gedifft.

Ist das Store-Format proprietär? Nein — das Gegenteil. KAUT implementiert das herstellerneutrale Open Knowledge Format (OKF) v0.2: einfache typisierte Markdown-Konzeptdokumente. Jeder OKF-Konsument kann einen Store lesen, und kaut okf export erzeugt ein vollständig idiomatisches OKF-Bündel. Kein Lock-in: Ihr Wissen ist in beiden Fällen portables Markdown in einem Git-Repo.

Wird es etwas in mein Repository committen? Nein. Höchstens eine ignorierte Pointer-Datei. Der Wissensspeicher liegt außerhalb des Repos.

Muss mein Team es einführen? Nein. KAUT ist local-first: Ein Entwickler installiert es und profitiert; niemand sonst ist beteiligt oder betroffen.

Was, wenn ein gespeicherter Fakt falsch ist? Jeder Fakt trägt seine Herkunft und ein Vertrauenslabel; der Agent behandelt Fakten mit niedrigem Vertrauen skeptisch und verifiziert sie gegen den Code. Der Speicher führt eine vollständige Historie, sodass fehlerhafte Einträge nachverfolgt und zurückgerollt werden können.

Was kostet der Betrieb? Der erste Kartenaufbau ist der teure Teil (Minuten). Die tägliche Wartung ist darauf ausgelegt, fast nichts zu kosten: Frischeprüfungen sind reine Git-Vergleiche – keine KI-Aufrufe.

Mehr erfahren

• Das Projekt-Wiki — Erste Schritte, Projekt verbinden, Kernkonzepte, der Wartungszyklus, FAQ und Fehlerbehebung in geführter Form

• docs/HANDBOOK.md — wie alles funktioniert, in menschlicher Sprache, aber in voller Detailtiefe

• docs/OPERATIONS.md — Betreiberreferenz: Layout auf der Festplatte, Auflösung, Manipulationsschutz, Schreibsperre, Engine-Interna

• docs/AGENT-INTEGRATION.md — Anbindung von Agenten an den Speicher: der Wissensvertrag, Snippets pro Harness, eine Skill-Vorlage, eine durchgearbeitete Sitzung

• docs/MCP.md — die MCP-Server-Referenz: Registrierung, alle 7 Tools, Protokoll

• SCHEMA.md — der normative Datenvertrag, den diese Engine implementiert (inkl. der OKF v0.2 Konformitätszuordnung)

• CHANGELOG.md — Versionshistorie

• CONTRIBUTING.md · SECURITY.md · CODE_OF_CONDUCT.md

Lizenz & Zitierung

Apache-2.0 — siehe LICENSE und NOTICE. Wenn Sie KAUT verwenden oder auf den Konzepten aufbauen, die es implementiert, zitieren Sie es bitte über CITATION.cff.

Kontakt: Yuriy Orlov yuriy.orlov@undertrust.dev