8.6 KiB
Epic 3 Context: Inkrementelle Kompilation & Synthese
Goal
Der Compiler verarbeitet neues Source Material gegen das bestehende Knowledge Bundle, statt es bei jedem Lauf aus sämtlichen Rohquellen neu aufzubauen (Compounding Knowledge). Bestehende Concepts werden durch neue Erkenntnisse erweitert, präzisiert oder in eindeutig belegten Fällen korrigiert; mehrere Sources werden zu einer gemeinsamen Wissensrepräsentation mit gemischter, claim-granularer Provenienz synthetisiert; unverändertes Wissen bleibt erhalten. Relevanz und Reconcile-Routing sind textual-deterministisch — ohne Embedding- oder Vector-Infrastruktur. Konkurrierende Producer koordinieren sich über eine atomare, worktree-übergreifende Root-Scope-Lease mit transaktionalem Dirty-Tree-, Rollback- und Release-Lifecycle. Klassifikationspflichtige Kollisionen und Widersprüche werden bis Epic 4 fail-closed als strukturierter Hold erhalten. Epic 3 gilt erst nach einem realen, unabhängigen Source→Compilation→Wiki-Abnahmegate als abgeschlossen (AD-5, AD-6, AD-13, AD-17a/b/d-f/h).
Stories
- Story 3.1: Inkrementellen Datenfluss implementieren (Interpret → Reconcile → Synthesize → Update)
- Story 3.2: Relevanzbestimmung textual-deterministisch umsetzen (grep/ripgrep/Traversal)
- Story 3.3: Bestehende Concepts erweitern/präzisieren/korrigieren
- Story 3.4: Wissen aus mehreren Sources synthetisieren
- Story 3.5: Leasing & Dirty-Tree-Schutz für konkurrierende Producer umsetzen
- Story 3.6: Lease-Staleness & Recovery-Basis absichern
- Story 3.7: Reason/Mutate-Trennung und Konsistenz-Endzustand sicherstellen
- Story 3.8: Determinismus-Vertrag (AD-17h) als Agent-Instruktions-Validator umsetzen (wieder geöffnet)
- Story 3.9: Deterministische Relevanz- und Reconcile-Routing schließen
- Story 3.10: Inkrementelle Update- und Synthese-Erhaltung absichern
- Story 3.11: Root-Scope-Leasing atomar und worktree-übergreifend akquirieren
- Story 3.12: Lease-Lifecycle und Commit-Abschluss transaktional schließen
- Story 3.13: Epic-3-Verifikations- und Abnahmegate
Requirements & Constraints
- Ein Compilation Run nimmt neues Source Material und das bestehende Wiki als Input; das Wiki wird inkrementell weiterentwickelt, nie vollständig regeneriert. Unverändertes Wissen bleibt erhalten; Git-Änderungen konzentrieren sich auf die durch die neue Erkenntnis betroffenen Concepts (FR-4, FR-12).
- Neue Informationen führen nicht automatisch zu neuen Dateien: bestehende Concepts werden erweitert, präzisiert oder korrigiert, ohne ihre Struktur zu zerstören; Beziehungen und Provenienz bleiben soweit weiterhin gültig erhalten (FR-6).
- Mehrere Sources zum selben Thema münden in eine gemeinsame Wissensrepräsentation statt getrennter Zusammenfassungen. Das Ergebnis reflektiert den erkannten Wissensstand, konsolidiert Redundanzen und übernimmt die relevante Source-Provenienz der beteiligten Sources (FR-7, AD-4).
- Unvollständiges oder ungeprüftes Wissen wird ohne künstliche Gewissheit dargestellt; klassifikationspflichtige Widersprüche werden bis Epic 4 unverändert in einem strukturierten Hold erhalten (NFR-7).
- Relevanzbestimmung, Routing, Planung und nicht-konfligierende Mutationen sind textual-deterministisch; Embeddings, Vector-Search, Knowledge-Graph-DB und RAG gehören nicht in den Compiler-Kern (AD-13, AD-17h, PRD-No-Goals).
- Ein Run verwendet ausschließlich veröffentlichte (committete) Inhalte als Input, nie Zwischenstände während der Mutation (AD-17).
raw/bleibt immutable und dient als Recovery-Basis; ein fehlgeschlagener Run verändert es nicht (AD-3).
Technical Decisions
- Inkrementeller Datenfluss (AD-5, A0-6): Interpret → Reconcile → Synthesize → Update affected Concepts. Startpunkt ist immer das bestehende Bundle — niemals "Regenerate Everything" aus allen Rohquellen. Validiert durch die Incrementality-Anforderung (SM-1, FT-6).
- Reason/Mutate-Trennung (AD-6, A0-7): Logische Phasen Analyse → Reconcile → Plan Changes → Mutate → Validate. Keine eigene Workflow Engine; ein Agent kann die Phasen in einer Session durchführen, der beobachtbare Endzustand des Bundles muss bei Abbruch konsistent sein.
- Deterministische Relevanz und Reconcile-Routing (A0-18): Ein geschlossenes Term-Ziehverfahren beziehungsweise ein explizites Term-Manifest, identische Normalisierung von Suchterm und Body sowie literal-sichere Suche führen zu einer nachvollziehbaren Candidate-Liste. Eine exklusive Routing-Tabelle unterscheidet
UPDATE,CREATE,ORPHAN/HOLDund echtenNO_OP; gleiches Eingabemanifest erzeugt dieselben Kandidaten und Entscheidungen. - Keine eigenständige LLM-Runtime: Der ausführende agentische Host (Claude/Codex-Adapter) orchestriert die Sequenz gemäß AD-17 (Lease holen, innerhalb des geleasten Bereichs mutieren, committen, freigeben); keine separaten Prozesse oder ein Server (AD-11).
- Atomare Root-Scope-Lease (AD-17a/b, A0-12/13): Producer behalten
lease/<area>/<id>als Branch-Konvention, akquirieren aber genau einen atomaren, scope-bezogenen Lock im clone-geteilten Zustand. Die Run-ID ist Lock-Inhalt, nicht Exklusivitätsschlüssel; unterschiedliche IDs und Worktrees konkurrieren um dieselbe Root-Scope (wiki/inklusivelog.md,index.mdund aller Root-Dateien). - Fail-closed Kollisionsgrenze: Zwei Branches mit ungleichen Änderungen am selben Concept-Pfad werden nie textuell automatisch gemerged. Epic 3 erhält beide Commit-Hashes und den Scope in einem strukturierten Hold; AD-16-Klassifikation, semantische Auflösung und Disagreement-Dokumentation sind Story 4.1/4.2 (AD-17c/g, A0-14/17).
- Transaktionaler Dirty-Tree-/Rollback-/Release-Lifecycle (AD-6, AD-17d-f, A0-7/15/16): Eine eindeutige Zustandsmaschine schützt getrackte und ungetrackte Fremdänderungen, restauriert bei FAIL explizit den Baseline-Commit und hinterlässt bei SUCCESS Mutation, zulässigen Nachweis, Lease-Freigabe und einen sauberen Worktree dauerhaft. Eine lebende Lease wird nicht allein durch Generationserhöhung stale.
- Determinismus-Vertrag (AD-17h/FT-10, A0-19): Ein kanonisches Eingabemanifest bindet Baseline, geordnete Sources und jeden output-sichtbaren Run-/Zeit-/Identitätswert. Zwei getrennte saubere Worktrees und frische Agent-Kontexte erzeugen denselben Bundle-State und rekonstruierbare Run-Receipts; hart codierte Pläne oder Concept-Bodies sind kein Nachweis.
- Geteilte A0-21-Grenze: Epic 3 beweist mit Story 3.10 den Incrementality-Teil — Erhaltung unabhängigen und weiterhin gültigen vorhandenen Wissens. Die spezifische Erhaltung und Konfliktbehandlung menschlicher Korrekturen (FT-9) bleibt bei Story 4.3.
- Synthese bleibt source-grounded (AD-4): Bestehende Concepts dürfen Kontext und Synthese liefern, fachliche Aussagen müssen aber auf nachvollziehbare Sources zurückführbar bleiben; Wiki-Links ersetzen nie die Provenienz zur ursprünglichen Evidenz.
- Epic-3-Abnahmegate: Ein portables, fail-fast ausführbares Gate ruft den vollständigen autorisierten Bundle-Validator auf und lässt einen frischen Agent-Kontext die kanonische Instruktion
schema/compiler.mdüber einer repräsentativen Fixture ausführen. Der Harness schreibt keine erwarteten Wiki-Ausgänge selbst. Ein unabhängiger Consumer-Smoke-Test prüft nur die Epic-5-Abhängigkeit und nimmt FR-15/FR-16 nicht vorweg. Ein Defizit des autorisierten Validator-Vertrags blockiert das Gate und verlangt eine separat genehmigte Epic-1-Remediation.
Cross-Story Dependencies
- Baut auf dem Workspace aus Epic 1 auf (
raw/immutable, Bundle-Root, Schema-Validierung) und konsumiert die in Epic 2 erzeugten, OKF-konformen, verlinkten Concepts mit claim-granularer Provenienz als vorhandenes Wissen. - Story 3.9 liefert die deterministische Routing-Basis für Story 3.10. Parallel dazu liefert Story 3.11 die atomare Lease-Basis für Story 3.12.
- Story 3.8 wird nach 3.9–3.12 mit echten unabhängigen Runs abgeschlossen; Story 3.13 ist anschließend das finale Epic-Abnahmegate.
- AD-17c/A0-14 sind geteilt: Epic 3 verantwortet die No-Auto-Merge-/fail-closed-Sicherheitsgrenze, Epic 4 Klassifikation und semantische Auflösung. AD-17g/A0-17 verbleiben vollständig in Epic 4. A0-21 ist ebenfalls geteilt: Story 3.10 verantwortet den Incrementality-Teil, Story 4.3 Human Curation/FT-9.
- Das Leasing-/Dirty-Tree-Modell dieses Epics koordiniert Compiler-Runs mit menschlicher Bearbeitung (Q-2) und liefert die Grundlage für die Git-Nachvollziehbarkeit und Auflösungs-Dokumentation, auf die Epic 5 aufsetzt.
- Keine UX/Design-Anteile relevant: v1 ist datei-/CLI-basiert ohne GUI (A-3, AD-11).