NAOME

Ein autopoietisches Software-OS für autonome, beweisgetriebene Software-Evolution

Naome ist eine deterministische transaktionale Grundlage

Naome versteht Softwareentwicklung als deterministische Transaktionslogik. Eine Nutzerintention wird in eine abgegrenzte Aufgabe und eine Änderungstransaktion übersetzt, isoliert ausgeführt und nur übernommen, wenn der Kernel jede Zustandsänderung nachweisen kann. So wird aus losem Editieren ein belegter Wechsel im Systemzustand. Das ist die praktische Einbettung von Kernthese und Prozesspipeline.

Die Leitidee: Software als sich selbst ordnendes OS

Entscheidend ist der Systemgedanke: Ein Repository ist nicht nur ein Code-Container, sondern ein betriebbares Software-OS mit persistenter Zustandslogik, Policies und Ausführungsregeln. Der Kernel hält diese Garantien, alle anderen Komponenten erhöhen nur die Produktivität.

Autonomie funktioniert nur mit verifizierbaren Beweisen

Mit wachsender Projektkomplexität reichen manuelle Notizen oder reine Chat-Historie nicht mehr aus. Naome speichert Beweise, Fehler und Architekturentscheidungen strukturiert, sodass neue Aufgaben aus vorhandener, geprüfter Erfahrung lernen können, statt dieselben Fehler erneut zu reproduzieren. Die praktische Konsequenz dazu liegt in Wissen & Betrieb und Umsetzungsstand.

So ergänzen sich Kernel, Kontext und Gates

Autonomie bedeutet nicht weniger Kontrolle, sondern reproduzierbare Kontrolle: Hintergrund-Belege, Gate-Ergebnisse und regelbasierte Kontexte sind maschinenlesbar und überprüfbar. Sobald Ergebnisse ungültig werden, stoppt der Ablauf, bis neue Beweise vorliegen. Diese Schleife verbindet sich mit Policy & Gates und Prozesspipeline.

Warum Stabilität aus deterministischen Abläufen entsteht

Kernel, Kontext-Engine und Gate-Runner bilden eine Schleife: Der Kernel definiert den erlaubten Zustand, der Kontext begrenzt den Arbeitsraum, und Gates entscheiden vor dem Merge über technische Sicherheit. Damit können Agenten Vorschläge liefern, ohne dass das Repository unkontrolliert aus dem Ruder läuft. Die gleiche Kontrolle ist in Policy & Gates und Umsetzungsstand beschrieben.

Zentrale These: Der Kernel hält den Zustand, Adapter bleiben austauschbar

Deterministische Transaktionsmaschine statt nur intelligente Patch-Hilfe

Im Zentrum von NAOME steht eine deterministische Transaktionsmaschine, die Scope, Übergänge und Beweislogik kontrolliert. Agenten können Patch-Entwürfe liefern, aber der Kernel übernimmt die formale Ausführung: Isolierung, Invariante-Checks und Merge nur bei nachgewiesen gültigen Übergängen. Das Prinzip ist ausführlich in Kern im Detail beschrieben.

Menschliche Intention wird zu strukturierter Spezifikation

Eine Nutzeridee wird nicht direkt ausgeführt, sondern zuerst in ein GoalSpec überführt und anschließend in TaskSpecs mit klaren Constraints, nötigen Artefakten und exakt definiertem Scope zerlegt. So sinkt Mehrdeutigkeit und der Ablauf bleibt planbar, auditierbar und überprüfbar. Die Umwandlung wird in der Prozesspipeline verankert.

Nur der Kernel darf Systemzustand verändern

Nur der Kernel darf den foundationalen Systemzustand verändern. Agenten bleiben externe Vorschlagsgeber und dürfen keine direkten Commits in die Wahrheitsebene schreiben. Das macht Rollbacks, Recovery und Nachvollziehbarkeit auch bei vielen parallelen Aufgaben stabil. Für die Grenzen dieses Modells siehe Policy & Gates.

Git, Codex und IDEs bleiben ersetzbare Adapter

Git, Codex, IDEs und externe Hilfssysteme beschleunigen die Arbeit, definieren aber nicht die Grundsemantik. NAOME kann weiterhin funktionieren, wenn ein Adapter getauscht wird, solange Kernlogik, Policy und Evidenzverarbeitung im Kernel verbleiben. Die Abgrenzung zu Adaptern ist die Kehrseite des Modells in Stack & Zustand.

Foundation als einzige Quelle der Wahrheit

Die Foundation ist die verbindliche Basis für Versionsstand, Invarianten und Freigaberegeln. Alles andere ist Komfortschicht – UX, Kontextgeneratoren, Assistenz. Die Architektur ist absichtlich strikt, damit Komfort niemals auf Kosten von Korrektheit geht. Der Release-Weg dazu steht in Policy & Gates und Roadmap.

Roadmap-Architektur: Von V0 Foundation bis zur V1.9 Plattform-Ebene

V0: Foundation Scaffold

V0 definiert das minimale Fundament: Source-Registrierung, deterministische Hash-Erfassung, Snapshots und lokaler Event-Store. Das System erstellt einen reproduzierbaren Ausgangszustand für jeden Source-Ordner (Revision, Dateihashes, Revisionen, Modell-Snapshots) und schreibt alle Beobachtungen append-only. In diesem Schritt ist NAOME bewusst nicht-invasiv: Es überprüft Konfiguration, Scans und Zustandsintegrität, verändert aber noch keinen Produktionszustand. Das ist die technische Basis, auf der Ausbauphasen aufbauen.

V1.4.19: Background Proof Foundation

V1.4.19 verlagert Verifikation von einfachen Statusanzeigen auf reproduzierbare Receipts. Jeder Gate-Lauf liefert strukturierte Artefakte mit Command, Umgebung, Dauer, Exit-Code, Exit-Grund und Aktualitätszustand. Dadurch kann die Foreground-Pipeline auf belastbare Zustände reagieren, statt teure Checks wiederholt manuell oder ad-hoc neu auszuführen. Die praktische Logik ist der Kern von Proof-Basis.

V1.5: Kontext- und Architektur-Härtung

Mit V1.5 wird Kontext zu einer aktiven Kontrollschicht: Relevante Dateien, relevante Tests und betroffene Module werden zielgerichtet berechnet statt breit geliefert. Architekturprüfungen werden als harte Regeln formuliert, und Fehler werden typisiert (Compile, Test, Scope-Verstoß, Architekturabweichung, Regression), damit der Kernel exakt entscheiden kann. Hohe Risikobereiche oder unzureichende Schutzartefakte werden früh blockiert. Die Steuerung wird weiter in Prozesspipeline und Policy & Gates konkretisiert.

V1.6: Multi-Worktree Sessions

V1.6 erlaubt echte Parallelität, ohne Sicherheit einzubüßen. Jedes Task bekommt einen eigenen Worktree, eigene Laufzeitartefakte und klare Diff-Fingerprints; ein lane-basiertes Scheduler-Modell priorisiert Quality-, Test-, Release- und Heavy-Work ohne gegenseitige Verdrängung. Über einen Konflikt-Score (safe/caution/blocked) werden Dateimodifikationen kollisionsfrei serialisiert. Für die Konfliktlogik siehe Policy & Gates.

V1.7: Deterministic Local Git OS

V1.7 formt die lokale Git-Nutzung zur deterministischen Plattform statt zu einem manuellen Integrationsprozess. Merge-Reihenfolge, Warteschlangenlogik und Stale-Erkennung werden vor jeder Integration erneut geprüft und simulierbar gemacht. Die Folge: viele interne Arbeitseinheiten können intern parallel entstehen, während `main`/`next` extern klar, linear und prüfbar bleiben. Diese Veröffentlichungspfade sind in Roadmap explizit beschrieben.

V1.8: Public Release Flow

V1.8 definiert den externen Release-Vertrag: Lokale Entwicklung darf vielschichtig sein, veröffentlicht wird jedoch nur ein geprüftes Release-Niveau. Interne Transaktionen, interne Branches und Zwischenzustände bleiben lokal verfügbar, aber nur kuratierte Snapshots gehen in `next` und dann in `main`. So entsteht eine verständliche Historie für Review und Deployment. Die gleichen Sicherheitsgarantien findet man unter Policy & Gates.

V1.9: Repo-nativer Wissensgraph

V1.9 ersetzt chaotische Chat-Historien durch strukturiertes Repository-Wissen. Entscheidungen, Risiken, Constraints, Muster und Task-Ergebnisse werden als typisierte Knoten und Kanten gespeichert, inklusive Abhängigkeiten und Gültigkeitszuständen. Agenten erhalten damit fokussierte, komprimierte Kontexte statt langer unfilterbarer Gesprächsverläufe. Siehe hierzu auch Wissen & Betrieb.

V2: Autopoietischer Factory-Kernel und selbstverbessernder Agent-Fabrik-Modus

V2 ist die ausgereifte Betriebsphase: Die Factory steuert dauerhaft Recovery, Priorisierung, Ressourcen und Sicherheitsregeln, ohne dass die Qualität der Kontrolle leidet. Der Kernel verwaltet Konflikte, Recovery-Events und deterministische Merge-Pfade automatisch unter festen Invarianten. Gleichzeitig arbeitet der selbstverbessernde Modus mit Wissensranking und Evidenz-Dichte, so dass künftige Tasks mit besseren Start-Vorbedingungen geplant werden. Die Gesamtlogik zieht weiter zu Wissen & Betrieb.

Beweisbasierte Ausführung ab V1.4.19 und darüber hinaus

Background Proof Foundation: Receipts vor Status-Flags

Erster Schritt dieser Schicht ist, Gate-Ergebnisse aus dem statusbasierten Denken zu lösen. Statt nur 'grün/rot' werden vollständige Receipts erzeugt: Befehl, Umgebung, Laufzeit, Standardausgabe/Fehlerausgabe und Abhängigkeitszustand werden persistiert und versioniert. Das ist die Beweislage, auf der Proof-Basis und Policy & Gates aufsetzen.

Dark Factory: Entkopplung schwerer Checks

Schwere Qualitätssicherung läuft im Hintergrund und getrennt vom interaktiven Agent-Flow. Separate Lanes kapseln Qualität, Kompilierung, Tests und Release-Checks mit eigenen Ressourcen- und Prioritätsregeln, was die Arbeit stabiler und reproduzierbarer macht. Diese Trennung wird durch Roadmap und Stack & Zustand ergänzt.

Multi-Worktree-Sessions für paralleles Arbeiten

Mehrere Tasks können parallel in isolierten Worktrees arbeiten, jeweils mit eigenem Laufzeitzustand und eigenen Laufpfaden. Konfliktanalyse prüft Scope- und Modulpunktüberschneidungen frühzeitig und klassifiziert Risiko als sicher, vorsichtig oder blockiert.

Deterministische lokale Git-OS und Merge-Planung

Die lokale Git-Schicht wird deterministisch betrieben: geordnete Merge-Queues, Basiskontext-Validierung und erneute Integrationsprüfung vor jedem Schritt. Wenn Abhängigkeiten geändert sind, wird die Reihenfolge neu berechnet, statt implizit inkonsistente States zu akzeptieren. Siehe die Orchestrierung in Roadmap.

Public Release Flow mit main/next als vertrauenswürdiger Historie

Die externe Historie bleibt bewusst sauber: Viele lokale Kandidaten, aber nur geprüfte Release-Snapshots werden für `next` und später `main` veröffentlicht. So bleiben Deployability, Reviewbarkeit und Rückrollbarkeit in der Produktion nachvollziehbar. Das korrespondiert mit den Freigaberichtlinien unter Policy & Gates.

Repo-nativer Wissensgraph als langfristiges Gedächtnis

Lernkurven, Entscheidungen und Fehlermuster wandern von Chatprotokollen in strukturierte Repo-Artefakte: Entscheidungstypen, Constraints, Risiken, Aufgabenbezüge und Beziehungen zwischen ihnen. Das reduziert irrelevantes Rauschen und liefert fokussierten Kontext für zukünftige Tasks. Diese Gedächtnisstrategie steht näher beschrieben in Wissen & Betrieb.

Wie der V1-Kernel jede Änderung vor Merge beweist

Minimale Kernelmodule und Invarianten

Der V1-Kernel bleibt bewusst schlank und modular: `naome-core`, `naome-store`, `naome-source`, `naome-vcs`, `naome-policy`, `naome-gates` und `naome-daemon` kapseln je eine klare Verantwortung. Module dürfen keine stillen Seiteneffekte über ihre Grenzen hinweg erzeugen; zentrale Invarianten sind einheitlicher Zustands-Owner, deterministische Übergänge und reproduzierbare Ergebnisse. Diese Struktur ist die Umsetzung von Stack & Zustand.

Factory State Machine mit Recovery

Der Factory-Lebenszyklus ist explizit: `Stopped`, `Booting`, `Running`, `Degraded`, `Recovery`, `ShuttingDown`. Jeder Übergang ist beobachtbar und rückholbar. In Recovery wird nach Fehlern auf persistiertes Event- und Snapshot-Material zurückgegangen, bevor produktive Arbeit fortgesetzt wird. Für die Zustandslogik siehe Prozesspipeline.

Transaktions-State-Machine und harte Übergangskriterien

Die Transaktion ist ein formaler Ablaufplan mit harten Bedingungen zwischen Zuständen: erstellt, geplant, Worktree erstellt, Agent-Lauf, Patch erfasst, Patch validiert, Gates geprüft, Merge-Entscheidung, Merge/Fehlschlag/Abbruch. Unvollständige oder veraltete Zustände werden nicht toleriert, sondern sauber verworfen. Für den Übergang zu konkreten Abläufen siehe Prozesspipeline.

Domänenobjekte: SourceFolder, Snapshot, GoalSpec, TaskSpec

`SourceFolder` hält Registrierung und Repository-Kontext, `SourceSnapshot` hält Hash- und Revisionsherkunft, `GoalSpec` bildet die Nutzungsabsicht inkl. Constraints ab, und `TaskSpec` legt Scope, erwartete Outputs und Gate-Anforderungen fest. So bleibt aus einem Wunsch eine geprüfte, versionierte Aufgabe statt losem Kommentar. Die Objekte werden in der Ausbauphasen-Progression eingeführt.

Patch Envelope und deterministische Merge-Entscheidung

Der Agent liefert die Diff-Idee, aber der Kernel berechnet ein `PatchEnvelope` aus dem tatsächlichen Worktree-Zustand. Damit werden Baseline, geänderte Dateien und betroffene Pfade verifiziert. Ein Merge erfolgt nur bei vollständiger Gatesignatur, intakten Invarianten und bestätigter Reproduzierbarkeit – nicht nach optischem Gutdünken. Siehe für die Freigabelogik Policy & Gates.

Ereignisprotokoll ohne versteckte Seiteneffekte

Jede wichtige Aktion schreibt ins Event-Protokoll: Scans, Gate-Läufe, Patch-Erzeugung, Freigaben, Fehlschläge, Recovery. Damit sind Entscheidungen nachvollziehbar, Replays möglich, und ein Audit kann ohne zusätzliche Annahmen exakt klären, warum ein Task zugelassen oder abgelehnt wurde. Diese Persistenz korrespondiert mit dem Umsetzungsstand.

Warum Agenten Patches liefern, aber nicht den Zustand halten

Agenten sind Produktivitätsschichten, nicht die Quelle der Wahrheit. Sie liefern Änderungsvorschläge, aber die Kernel-Logik entscheidet über Validierung, Rollback-Pfad, Freigabe und Integration. So bleibt der Kontrollpfad stabil, auch wenn mehrere Tools oder Modelle parallel an derselben Aufgabe arbeiten. Der praktische Einsatz liegt in Erste Schritte.

Vom Intent zur reproduzierbaren, überprüfbaren Änderung

User Intent → GoalSpec

Die Pipeline beginnt mit einer belastbaren Intent-Erfassung. Eine Nutzereingabe wird in ein `GoalSpec` überführt, das Erfolgskriterien, Grenzen, Risiko-Kennzeichnung und Scope-Hinweise enthält. So wird lose Sprache von auszuführendem Auftrag klar getrennt. Das ist die operative Umsetzung der Kernthese.

GoalSpec → TaskSpec

Aus jedem `GoalSpec` werden konkrete `TaskSpec`-Einheiten mit konkretem Scope, erwartbaren Ausgaben, Verboten und Pflichtbelegen erzeugt. Ziel ist atomare Ausführung: jede Aufgabe kann unabhängig verifiziert werden. Die Grenze zu diesem Modell finden Sie in Policy & Gates.

TaskSpec → Transaction

Zu jeder Aufgabe entsteht eine Transaktion mit Basis-Revision, erlaubtem Scope, Worktree-Pfad, Gate-Plan und Policy-Metadaten. Diese Transaktion läuft über feste Checkpoints, sodass keine Phase übersprungen oder unzulässig zurückgespult werden kann. Die Transaktionslogik ist in Kern im Detail beschrieben.

Agent-Lauf mit strikt definiertem Output-Contract

Der Agent erhält nur den zugeschnittenen Task-Vertrag und nicht die komplette Systemlogik als offenen Auftrag. Er muss Patch-Orte, Zusammenfassung, Testauswirkungen und mögliche Fehlersignale liefern. Die Entscheidung bleibt beim Kernel, nicht beim Modell. Genau hier greift der Sicherheitsrahmen aus Policy & Gates.

Patch-Validierung und Rollback-Tauglichkeit

Die Validierung prüft geänderte Dateien, Scope-Verletzungen, Reproduzierbarkeit zur Base-Revision und alle Pflichtnachweise. Fehlen erforderliche Schutzartefakte (z. B. Regressionstests bei Bugfixes), wird die Transaktion gestoppt und zur Nachbesserung markiert. Diese Regeln verbinden sich direkt mit den Gate-Kriterien unter Policy & Gates.

Gate-Ausführung, Evidenzsammlung und Merge-Policy

Gate-Ausführung läuft deterministisch und evidence-first: Jeder Gate-Lauf schreibt maschinenlesbare Ergebnisse (Status, Dauer, Outputs, Umgebung). Die Merge-Policy wertet diese Artefakte zusammen mit Approval-Zustand aus und erlaubt keine bloß oberflächliche Freigabe. Damit ist diese Sektion eng mit Policy & Gates verzahnt.

Fehlererfassung und fehlergetriebene Schutzaufgaben

Fehler werden klassifiziert (`compile`, `test`, `scope`, `architecture` usw.) und in persistierte Failure-Events überführt. Wiederkehrende Fehler erzeugen Folgeaufgaben mit Schutznachweis (neue Tests, Regeln, Checks), damit bekannte Fehlerquellen systematisch abgefedert werden. Die Lernrückkopplung erfolgt in Wissen & Betrieb.

Technik-Stack und Datenmodell für deterministisches Verhalten

V1-Stack: Rust, Tokio, SQLite, Git Worktrees

Der V1-Stack ist bewusst minimal und deterministisch: Rust für Kernlogik, Tokio für async Scheduling und Prozesssteuerung, SQLite mit WAL für lokale Persistenz und Git Worktrees für isolierte Ausführungsumgebungen. Diese Kombination vermeidet externe Orchestrierungsdienste, unterstützt aber trotzdem robuste Langläufer-Prozesse, Neustart-Sicherheit und reproduzierbare Beweise. Diese Architektur steht in Verbindung mit Kern im Detail.

Workspace-Crates für Policy, Gates und Daemon

Naome ist als Cargo-Workspace aufgebaut, mit getrennten Crates für Core-Policy, Transaktions-State, Store, Source-Modell, Gates, VCS, Daemon-Runtime und CLI. Jede Einheit hat eine klare Verantwortung: Der Kernel bleibt Vertragsverantwortlicher für State und Policy, Adapter konsumieren und liefern Artefakte, ohne deren Herkunft zu bestimmen. Dadurch sinkt Kopplung und Kernlogik bleibt testbar, auswechselbar und wartbar. Dazu passt die modulare Darstellung in Kernthese.

Source-Modell: Dateien, Imports, Tests und Graph-Ebenen

Das Source-Modell beginnt in V1 mit Datei-Snapshots (Pfad, Hash, Erweiterung, Größe, Sprache) und erweitert sich schrittweise um Import-Kanten, Test-Zuordnungen und Ownership-Grenzen. In V2 ergänzt der Architektur-Graph Abhängigkeits- und Verhaltensschichten, doch frühe Phasen bleiben bewusst klein, damit Kontextauswahl, Risikobewertung und Scope-Checks schnell bleiben. Die Entwicklung dieses Modells wird in Roadmap vertieft.

Event-Logs, Projektionen und Wiederherstellung nach Neustart

Alle Zustandsänderungen werden append-only als Events gespeichert; Projektionen bauen daraus Runtime-Zustand, UI-Zustände und Scheduler-Sicht. Nach dem Neustart rekonstruiert der Daemon den Factory-State, aktive Sessions, Lanes und offene Transaktionen aus Events und Snapshots. Es gibt keinen versteckten In-Memory-Wahrheitsstatus: Verhalten nach Reboot orientiert sich am persistierten Evidenzstand. Das ist Grundlage für die Stabilität in Umsetzungsstand.

Datenbanktabellen für Ziele, Tasks, Transaktionen und Gates

Zum Start gehören u. a. `source_folders`, `source_snapshots`, `event_log`, `goals`, `tasks`, `transactions`, `patches`, `agent_runs`, `gate_runs`, `gate_results`, `failures`, `locks` und `memory_entries`. Das Schema ist bewusst explizit mit IDs, Zustandsmarkern und Zeitstempeln, damit Audits, Replays und Rollbacks nachvollziehbar und reproduzierbar bleiben. Die Reihenfolge dieser Einführung folgt den Ausbauphasen.

Sicherheitsregeln, Policies und Gate-Orchestrierung

Hard-Policies: keine direkten Foundation-Änderungen

Die harte Policy setzt die Vertrauensgrenze. Foundation darf nicht direkt von außen beschrieben werden: Agenten, IDE-Plug-ins oder UI-Ebenen können keine direkten Commits in den Foundation-Trust-Bereich schreiben. Nur der Kernel darf über transaktionale Abläufe Änderungen übernehmen, nachdem Scope-, Basis-Revision-, Invarianten- und Rollback-Prüfungen bestanden wurden. So bleibt jede Integration nachvollziehbar und deterministisch. Das Trust-Modell ist in Kern im Detail und Umsetzungsstand gespiegelt.

Scope-, Freigabe- und Konfliktprävention

Scopes begrenzen, wer was verändern darf; Freigabe-Policies legen fest, wann ein menschliches OK erforderlich ist; Konfliktregeln verhindern versehentliche Überlagerung. In V1 gelten erlaubte/gesperrte Pfade, Risikoscores und Scope-spezifische Locks. Bei hoher Gefahr (z. B. auth, payments, infra) werden Transaktionen vorab freigabepflichtig. Bei Overlap konkurrierender Aufgaben wird die Ausführung seriell gesteuert. Die Umsetzung verknüpft sich mit Ausbauphasen.

Gate-Klassen von Format bis Architektur-Policy

Gates sind in Ebenen organisiert: von schnellen Sicherheitschecks (Format, Typecheck) bis hin zu semantisch schweren Prüfungen (Integration, Architektur, Security, Regression, Performance). Erforderliche Gates sind strikt aktiv, optionale Gates werden je nach Task und Projektprofil konfiguriert. Jede Gate-Definition enthält feste Parameter – Command, Timeout, Arbeitsverzeichnis, Relevanz und Erfordernis – und wird vor jedem Lauf verifiziert. Die Sequenz ist ebenfalls Bestandteil von Kern im Detail.

Regression und Recovery-Gates nach Fehlern

Nach einem Fehler aktiviert NAOME Recovery-Logik: Fehler werden klassifiziert, wiederkehrende Muster erkannt und Schutzmaßnahmen für denselben Scope verschärft. Fehlende Regressionstests, veraltete Receipts oder Architekturverstöße führen zu einem harten Re-Run mit strengeren Gates. Das Ziel ist nicht nur „erfolgreich wiederholen“, sondern sicherer fortsetzen. Die Korrekturschleife ist im Kern von Wissen & Betrieb.

Release-Regeln für main/next-Promotion

`next` hält den aktuellen geprüften Release-Kandidaten, `main` wird nur gefördert, wenn die Evidenz vollständig und stabil ist. Agenten können intern vielfältig arbeiten, aber die externe Historie bleibt linear und sauber. Das verhindert unklare Integrationszustände und stellt sicher, dass jeder Stand auf `main` reproduzierbar rückverfolgbar ist. Für die Release-Strategie siehe Roadmap.

Gedächtnis, Ranking und operative Intelligenz

Context Engine v0 bis v2 mit memorygetriebenem Kontext

Die Context Engine reift schrittweise: v0 liefert breite Kontexte auf Basis von Suchtreffern, v1 nutzt Scope, Tests, erlaubte Pfade und Risikomerkmale, v2 kombiniert diese Signale mit Memory-Zuordnung. Der Übergang ist entscheidend: weniger Kontext, aber höherer Signalanteil pro Task. Das Fortschreiten ist in Ausbauphasen und Prozesspipeline gespiegelt.

Failure-Memory und Präventionsschleifen

Jeder Fehler fließt in die Failure-Memory ein und wird als klassifiziertes Ereignis abgelegt (`Compile`, `Typecheck`, `Regression`, `Scope`, Architektur ...). Bei Wiederholung ähnlicher Fehler wird der nächste Ausführungsversuch gezielt mit zusätzlichen Schutzschritten gestartet: neue/angepasste Tests, strengere Gates, höhere Freigabe-Anforderungen. So entstehen aus Fehlern operative Gegenmaßnahmen, nicht nur Fehlerlogs. Die Ableitung dieser Regeln ist Kern von Policy & Gates.

Scheduler-Priorisierung und Konfliktklassifizierung

Der Scheduler gewichtet User-Priorität, Sicherheitsdringlichkeit, Recovery-Notwendigkeit und Fehlerrisiko gegen den Integrationsaufwand. Konflikte werden dynamisch als `safe`, `caution` oder `blocked` klassifiziert. Bei `caution` kann noch parallel gearbeitet werden mit erhöhter Beobachtung, bei `blocked` wird seriell geplant, um semantische Kollisionen zu verhindern. Die Priorisierung ist Teil der Roadmap-Richtung in Ausbauphasen.

Wissensgraph-Ranking für langfristige Projekterinnerung

Der Wissensgraph speichert Entscheidungen, Risiken, Konzepte und Tasks als strukturierte Knoten mit Relationen (`depends_on`, `supersedes`, `proven_by`, `caused_by`). Für einen neuen Auftrag werden nur die relevantesten Knoten nach Relevanz, Aktualität, Stabilität und Scope-Bezug zurückgegeben. Der Agent bekommt damit kompakten Kontext statt roher Verlaufstexte. Dieses Ziel entspricht den Inhalten aus Roadmap.

Was relevant bleibt und was verliert Priorität

Relevanz ist zeitabhängig: Strategische Entscheidungen, Architekturregeln und stabile Schutzmaßnahmen behalten dauerhaft hohes Gewicht; veraltete Beobachtungen und Hypothesen verlieren an Einfluss, wenn sie nicht bestätigt werden. Dadurch bleibt das Gedächtnis lernfähig statt starr: Alte Ideen verschwinden nicht abrupt, aber unwichtige Signale werden nicht länger unkritisch verstärkt. Für Governance und Regeln siehe die Verknüpfung zu Policy & Gates.

Phasenplan vom Kernel-Nachweis zum ersten produktiven Release

Phase 1: Kernel-Typen und Event Store

In Phase 1 wird zuerst die belastbare Vertrauensschicht aufgebaut: Domänen-Typen, Event-Logik und harte State-Transitionen. Ziel ist ein reproduzierbarer Kern, der ungültige Zustände verhindert, bevor irgendeine produktive Agenten-Automation zugelassen wird. Das ist die Basis für Kern im Detail.

Phase 2: Source Registry, Snapshot und Scan

Phase 2 führt deterministische Quellmodellierung ein: Registrierung eines Source-Ordners, wiederholbarer Scan, Hash- und Revisionsbasis sowie Snapshot-Speicherung. Damit wird die Basis für belastbare Kontext-, Scope- und Gate-Entscheidungen geschaffen. Diese Phase ergänzt Stack & Zustand.

Phase 3: Gate Runner und deterministische Validierung

Phase 3 implementiert den Gate-Runner als deterministischen Ablauf: feste Commands, Zeitlimits, Pflicht- und Optional-Gates, strukturierte Outputs. Erst danach kann Merge-Entscheidung auf belegbarer Qualität statt auf impliziten Annahmen basieren. Siehe die Ausgestaltung in Policy & Gates.

Phase 4: Transaktionen ohne Agenten

Phase 4 validiert den Kern ohne Assistenzmodell: manuelle Worktree-Patches durchlaufen Transaktion, Validierung, Gates und Merge-/Rollback-Entscheidung. So wird der produktive Kontrollpfad hart belegt, bevor externe Task-Erzeuger in den Regelkreis einsteigen. Der Mechanismus ist im Abschnitt Kern im Detail beschrieben.

Phase 5: Agent-Adapter mit engen Output-Verträgen

Erst in Phase 5 wird der Agent-Adapter angebunden. Agents erhalten strenge Task-Verträge, Scope, Freigabe-Metadaten und Output-Pflichten. Der Kernel entscheidet weiterhin vollständig über Gültigkeit, Merge, Risiko und Rollback, nicht das Modell. Das operative Bindeglied ist die Prozesspipeline.

Phase 6+: Kontext und Failure-Memory

Ab Phase 6 kommen die eigentlichen Produktivitätshebel: kontextsensitivere Auswahl, Failure-Memory und Wissensrückkopplung. Wiederkehrende Fehler erzeugen präventive Aufgaben, Priorisierung verbessert sich, und die Ausführung bleibt trotzdem durch Regeln deterministisch. Damit schließt sich der Kreis zu Wissen & Betrieb.

Was heute nutzbar ist und was bewusst ausgeschlossen bleibt

Was im Repo bereits verifiziert ist

Die Kernlogik ist bereits als belastbare Basis angelegt: Source-Folder können registriert werden, deterministische Snapshots werden erzeugt, Basis-Domain-Objekte sind definiert und der Event-Stream bildet Zustandsänderungen nachvollziehbar ab. Dateimodelle, Hashes, Revisionen und Audit-Events sind damit reproduzierbar vorhanden. Die Abgrenzung dieses Stands verweist auf Ausbauphasen.

Aktuelle Grenzen und explizite V1-Reduktionen

Für V1 sind klare Grenzen gesetzt: kein blindes Agent-Autonomiewerk, keine direkte Foundation-Commit-Pipeline ohne Gate- und Policyprüfung, keine unkontrollierte Parallelintegration. Wo Unsicherheit besteht, priorisiert NAOME Stopp und Re-Validation statt unreflektierte Fortsetzung. Die Grenzziehung ist auch in Policy & Gates enthalten.

Was explizit nicht zu V1 gehört

Nicht Teil von V1 sind: ein vollwertiger Cloud- oder Kubernetes-Betriebsstack, externe Datenbanken als Pflichtkernel, ein eigenständiges LLM-Backend im Kern, umfangreiche IDE-/UI-Orchestrierung oder vollständige autonome Optimierungszyklen. NAOME bleibt bewusst lokal-first und kernel-zentriert. Für den inhaltlichen Rahmen siehe Roadmap.

Nächste sichere Meilensteine im Umsetzungsplan

Nächste Schritte sind: strengere Policyabdeckung, robustere Recovery- und Conflict-Kontrollen, klarere Merge-Queue-Deterministik sowie kontext- und gedenkbasiertes Task-Ranking. Jeder Schritt wird separat verifiziert, damit die Auslieferung sicherer wird, bevor weitere Automation eingeführt wird. Die Priorisierung entspricht Ausbauphasen.

Wie du mit Naome sicher startest

Quelle registrieren und Basissnapshot anlegen

Beginne mit einem klar registrierten Source-Ordner. Das ist die kleinste Sicherheitsgrenze: Repository-Root plus Foundation-Referenz müssen stimmen. Initialisiere den Ordner, prüfe die Registrierung und bestätige die korrekte Erkennung, bevor Tasks gestartet werden. Diese Grundlage ist die Basis für alle späteren invarianten Sicherungen. Der Einstieg ist im Kontext von Prozesspipeline zu sehen.

Snapshots, Tasks und Transaktionszustände verstehen

Arbeite in drei Ebenen: Snapshot, Task, Transaktion. Der Snapshot bildet den reproduzierbaren Ausgangszustand, der Task beschreibt das Ziel, die Transaktion führt das Ziel über kontrollierte Phasen aus. Beobachte die Zustände bewusst: erstellt, geplant, aktiv, Gates, Merge-ready oder fehlgeschlagen. Diese Begriffe sind in Kern im Detail definiert.

Aufgaben mit Scope, Risiko und Grenzen erstellen

Ein guter Task ist konkret: Er definiert erlaubte Pfade, verbotene Bereiche, erwartete Tests und harte Erfolgskriterien. Eine klare Abgrenzung verhindert, dass Agenten oder manuelle Eingriffe auf zu viele Dateien greifen und erhöht die Chance auf saubere, nachvollziehbare Integrationen. Diese Systematik ist Teil von Policy & Gates.

Gates ausführen und deterministische Ergebnisse prüfen

Gates liefern die Sicherheitsbasis. Führe sie mit festen Parametern aus, prüfe Logs, Laufzeit, Exit-Code, Environment und Aktualität. Wenn Anforderungen nicht erfüllt sind oder Artefakte unvollständig sind, gilt die Aufgabe als nicht fertig – auch wenn der Patch lokal gut aussieht. Die Akzeptanzkriterien entsprechen Policy & Gates.

Nur nach belastbarer Evidenz integrieren

Freigaben sollten immer das gesamte Task-Paket abdecken: vollständige Belege, stabile Grundlage, rollbackfähige Planung. Freigegeben wird nicht wegen einer Einordnung, sondern wegen reproduzierbarer Nachweise, die zeigen, dass die Änderung sicher integriert werden kann. Für den Integrationsrahmen siehe Prozesspipeline.

Rollback und Memory-Update als Standardablauf

Ein Fehlschlag ist kein Betriebsfehler, sondern ein Lernpunkt im System. Jede gescheiterte Transaktion sollte klare Failure-Einträge erzeugen, daraus entstehende Schutzmaßnahmen ableiten und den Kontext für künftige Tasks verbessern. So wächst die Sicherheit kontinuierlich mit jeder Aufgabe. Diese Routine wird im Abschnitt Wissen & Betrieb ausführlicher beschrieben.