feat: Story 3.1 Inkrementellen Datenfluss implementieren (Interpret→Reconcile→Synthesize→Update) — compiler.md Revision 2.4/2.4.1, Update-Routing + §5.9, Diff-Selbsttest, Review-Patch-Runde; Review-Handoff auf story-3-1

- schema/compiler.md: §3 Pkt. 2 Update-Routing (statt Kollision-Hold) + textuell-deterministische Kandidatenliste (AD-13); §5.9 Update-Mutationsmechanik (Erweitern/Präzisieren/Korrigieren, sources nur echte Belege, generated.at-Konvention, log.md-Eintragspflicht Story-3.1-Update, Mehrfach-Treffer-Konsolidierung); Erhaltungs-Invariante + deterministischer Diff-Selbsttest (git diff --name-only -- wiki/ ⊆ Kandidatenliste∪log.md∪Index, Ghost-Diff-Rück-Rollen); Run-Vorphase-Bausteine (Defer R-1 Change-Detection + P2 Pre-Run-Reconcile; Baseline = HEAD der vorherigen Mutations-Boundary); §0-Aufruf Update-Variante; §5.7/§5.8-Referenzen nachgeführt; §7 Update entlassen; §8 Prüfgrundlage Revision 9 (Punkt-11-Area-Lesart, Rev-9-Lücke geschlossen) + Revisionslog 2.4/2.4.1 (Step-04-Review-Patch-Runde, AD-3/D-3 gehalten, Worked Example real) - wiki/log.md: Story-3.1-Nachweis (Diff-Selbsttest wiki/log.md, per-Datei-Verdikt, Rev-9-Präzisierung, Sprint in-progress→review) - deferred-work.md: R-1/P2 aufgegriffen (2026-08-18 §5.9); Review-Findings-Protokoll bzw. F17-Defer (git-lose Ausweichform ab Story 3.2) - sprint-status.yaml: Story 3.1 → in-progress → review (Sprint-Sync), last_updated 22:30 - neu: epic-3-context.md, spec-3-1-… (status done, Suggested Review Order) Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-19 05:22:30 +02:00
parent 802a5576eb
commit efc543c9e1
6 changed files with 284 additions and 15 deletions
@@ -126,6 +126,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - source_spec: `raw/README.md` (Konvention, Story 1.2) — R-1
  summary: R-1 (Compiler-Input-Interface) — Verdikt **Bestanden**: `schema/compiler.md` definiert seine Source-Eingabe als Menge beliebiger `raw/`-Dateien (Set-Interface, §1.2 „jede Datei unter `raw/` ist Evidenz"), nicht als einzelnen Pfad. Der erkennungsseitige Mechanismus, WELCHE `raw/`-Dateien wann verarbeitet werden („Run-ohne-Pfad"-Nutzererwartung aus DRYRUN.md: Kompilation via git diff + SHA-256-Record aus den `source.md`-Records), ist bewusst nicht in Story 2.1 enthalten und gehört als Erkennungs-/Auswahl-Mechanismus in die AD-5-Home-Story (Epic 3, Story 3.1/3.2).
  evidence: Code Review (Story 2.1) R-1 — Epic-3-Forward-Risk, keine AC-Verletzung.
  status: aufgegriffen (2026-08-18, Story 3.1 — §5.9): Input-Zuwachserkennung als Change-Detection-Baustein des inkrementellen Runs in `schema/compiler.md` §5.9 Pkt. 6 verankert (Determinismus `git diff` auf `raw/` und/oder SHA-256-Record aus `raw/**/source.md`; unveränderte `raw/`-Dateien bleiben außen vor; fehlender/unlesbarer SHA-256-Record → textueller Hinweis, keine Doppel-Verarbeitung).
 - source_spec: `raw/README.md` / `schema/compiler.md` §1.2–§1.4 — R-2
  summary: R-2 (Nicht-Markdown-Quellen) — Verdikt **Bestanden**: die Compiler-Instruktion liest Sources endungsneutral als Datei (§1.2/§1.4), unterstellt keine `.md`-Endung; PDF ist zulässige Evidenz (Vertrag §3.3 verlangt nur einen Dateipfad unter `raw/`, Validator EC-1 prüft nur Existenz). Die Konventions-/Asset-Zuordnungsfrage (Namensschema für Nicht-Markdown-Quellen) bleibt offen und gehört zu Epic 2/3 (Nutzer-Input-Gestaltung für den Dryrun-Forderungskatalog). Als dokumentarischer Hinweis: §1.2/§1.4-Widerspruch („jede Datei ist Evidenz" vs. „Artefakt-Dateien sind KEIN Input") in der Instruktion selbst klären (siehe Patch-Findings in der Story).
@@ -160,6 +161,27 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
  summary: Pre-Run-Reconcile-Vorphase als deterministischen Pre-Plan-Schritt bündeln und dokumentieren (P2) — die textuellen Reconcile-Prüfungen (Ziel-Pfad-Kollision, Quellen-Existenz, AD-5-Relevanz der Quelle auf bestehende Concepts, `index.md`-Vorbedingung V-1) zu einem wiederverwendbaren Check-Block zusammenfassen (statt manueller Mehrfach-Checks, Bericht §3.2). Kein neuer Standalone-Prozess — nur ein reproduzierbarer Check-Block innerhalb der Instruktions-Ausführung; als Compiler-Instruktions-Schärfung (Story 2.1-Follow-up) oder Epic-3-Home (AD-5) einzuarbeiten.
  evidence: Prozess-Optimierungs-Bericht §3.2/§4.4; Review-Input §4 (D-3-konform).
  status: aufgegriffen (2026-08-18, Story 3.1 — §5.9): Pre-Run-Reconcile-Check-Block als wiederverwendbarer textueller Vorprüf-Block der Run-Vorphase in `schema/compiler.md` §5.9 Pkt. 6 verankert (Ziel-Pfade bzw. Ausgangs-Kandidatenliste, Quellen-Existenz EC-1 via Validator-Punkt, Betroffenheits-Kandidatenliste §3 Pkt. 2, `wiki/index.md`-V-1-Vorbedingung — fehlende Bundleroot → Run-FAIL, Vertrag §2); vor jeder Mutation durchlaufen und textuell festgehalten; kein neuer Standalone-Prozess (D-3).
 ## Review-Findings Story 3.1 (Step-04-Review, 2026-08-18) — Patch-/Klärungs-Protokoll
 > **Herkunft:** Step-04-Review der Story 3.1 (Patch-Runde) über die drei Review-Layer (Blind Hunter / Edge Case Hunter / Verification Gap). Die klassifizierten Findings wurden direkt umgesetzt (Patch-Runde in `schema/compiler.md` Revision **2.4.1** + den Begleitdateien); die folgenden Einträge halten Befunde fest, die nicht geschehener Patch sind, sondern **Konzuls-Status**, und sichern verbleibende Gaps als konkrete Folge-Aufgaben.
 - summary: **Story-3.1-Review: Diff-Selbsttest-Ausgabe (Pkt. 5) und Sandbox-Edge-Test-Scenarien (I/O-Matrix) waren als Beleg-Verdikt nur prosa-behauptet, nicht als konkrete deterministische Ausgabe nachgewiesen** (Verification-Gap-Reviewer). Heilung: `wiki/log.md`-Eintrag 2026-08-18 wurde in einen realen **Story-3.1-Update-Beurteilungs-Nachweis** umgeschrieben — `git diff --name-only -- wiki/` liefert exakt `wiki/log.md` (deterministischer Ist-Ausgabe-Befund, kein Ghost-Diff); die fünf Sandbox-Edge-Tests der I/O-Matrix (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) sind als deterministische Proben auf synthetischen Bäumen re-executierbar dokumentiert. Die konkreten Formel-Ausgaben je Szenario sind in der Spec-Verification der Story-3.1-Spezifikation enthalten.
  evidence: Step-04-Review Story 3.1, VG-Reviewer; Verifikations-Nachweis.
  status: umgesetzt (2026-08-18, Story 3.1 Patch-Runde) —
   - `git diff --name-only -- wiki/` → `wiki/log.md` (1 Insertion) — kein Ghost-Diff
   - Sandbox-Edge-Tests der I/O-Matrix → deterministische Formel-Ausgaben je Szenario
   - `git status --porcelain` → 4 modificiert + 2 untracked (der Schema-/Artefakt-/Spec-Teil liegt außerhalb `wiki/` und ist kein Ghost-Diff)
 - summary: **Story-3.1-Review: Verbleibende Defer-/Klärungs-Punkte als konkrete Folge-Aufgaben** (Blind-/Edge-Case-Hunter F9/F12/F17, VG-Reviewer F7-F8): (F9) §1-Anker §1.1/§1.4 → §1 Pkt. 1/Pkt. 4 nachgeführt (Patch in Revision 2.4.1); (F12) Defer-R-1-Baseline („gegen den git-diff-Befund") deterministisch bestimmt — HEAD der vorherigen Mutations-Boundary (AD-17f), Patch in Revision 2.4.1; (F17) Producer ohne Git (Ausweichform) — offener Punkt, siehe eigener Defer-Eintrag unten.
  evidence: Step-04-Review Story 3.1, EH/BH/VG (F9/F12/F17).
  status: umgesetzt/einzuordnen (2026-08-18, Patch-Runde) — F9/F12 als Patch in Revision 2.4.1; F17 als neue Defer-Aufgabe unten.
 - summary: **Neue Folge-Aufgabe (Story-3.1-Review F17): „Git-interaktion" des Producers bei einem Producer ohne Git-Tooling** (`git diff`/`git status`/Baseline-Commit sind für Zuwachserkennung und Diff-Selbsttest vorausgesetzt, AD-17h); Ausweichform für Umgebungen, in denen kein Git-Tooling verfügbar ist. Als Teil des Determinismus-Vertrags (AD-17h) werden `git`-Befunde als verlässlich behandelt; eine git-lose Partition ist als Ausweichform zu beschreiben (dokumentarische Konvention, D-3) — Vorschlag: Executive spiegelt die Zuwachserkennung über ein textuelles Eingabe-Manifest statt des `git diff`-Befunds und die Diff-Probe über ein Datei-Baseline-Manifest (Checksummen) — bis dahin bleibt Git für den Producer vorausgesetzt (NFR-1/NFR-5, Git-Bash auf win32).
  evidence: Step-04-Review Story 3.1, EH (F17); Nutzer-Entscheidung 1/1 (Story 3.2).
  status: open — nach Story 3.2/Epic-3-Klärung als Ausweichform zu spezifizieren.
 - summary: **Story-3.1-Review: „Git-zentrierte Zuwachserkennung" setzt einen validen Git-Zustand voraus; die AD-17-Grenze (nur published/committed Input) wird durch die eingefügte Erhaltungs-Invariante (§5.9 Pkt. 5, Erhaltungs-Diff) und die Ghost-Diff-Konsequenz (Rück-Rollen vor Run-Gültigkeit, `log.md`-Kopplung als Abbruch-Vorlauf) hinreichend verbunden** — Kein neuer Folge-Gap; dokumentiert für die Nachvollziehbarkeit des Review-Nachweises.
  status: Kein Gap — abgeschlossen (Patch in Revision 2.4.1).
 - source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
  summary: Provenienz-Checksumme bei mehrfacher Verwendung einer Quelle im Blick behalten (P2, Vorbereitung Epic 3/Story 2.2) — bei 11 Concepts aus einer Quelle (`raw/MetaModel.pdf`) ist eine wie auch immer geartete SHA-256/`last_modified`-Angabe Kandidat für `sources`-Metadaten; erst ab der zulässigen Schema-Erweiterung (Story 2.2 Claim-provenienz / Epic 3) in der Instruktion verankern. NICHT jetzt implementieren — `sources`-Subset (Vertrag §3.3, Punkt 6/§7) bleibt unverändert.
@@ -0,0 +1,50 @@
 # Epic 3 Context: Inkrementelle Kompilation & Synthese
 <!-- Compiled from planning artifacts. Edit freely. Regenerate with compile-epic-context if planning docs change. -->
 ## 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 korrigiert; Informationen aus mehreren Sources werden zu einer gemeinsamen Wissensrepräsentation mit gemischter, claim-granularer Provenienz synthetisiert; unverändertes Wissen bleibt erhalten. Die Relevanzbestimmung ("welche bestehenden Concepts sind betroffen") ist textual-deterministisch (grep/ripgrep, Markdown-Traversal, Link-Following) — ohne Embedding- oder Vector-Infrastruktur. Konkurrierende Producer koordinieren sich über ein leasing-/branch-basiertes Workspace-Modell mit Root-Scope-Lease und Dirty-Tree-Schutz; Mutationen sind commit-gebunden, und jeder Run endet in einem konsistenten, über denselben Git-State reproduzierbaren Bundle (AD-5, AD-6, AD-13, AD-17a..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
 ## 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, ungeprüftes oder teilweise widersprüchliches Wissen wird dargestellt, ohne künstliche Gewissheit zu erzeugen (NFR-7).
 - Relevanzbestimmung und Merges 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 Relevanzbestimmung (A0-18):** Führt zu einer nachvollziehbaren Candidate-Liste von Concept-Pfaden über grep/ripgrep auf `wiki/`, Markdown-Traversal von `index.md` und Link-Following — deterministisch statt probabilistisch. Gleichsam Grundlage für die Bereichszuordnung (gleiches textuelles Prinzip wie AD-7c).
 - **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).
 - **Leasing-Modell (AD-17a..f, A0-12..A0-16):** Producer arbeiten auf `lease/<area>/<id>`-Branches; Lease-Akquise gegen einen eindeutigen Commit-Object-Wert (Merge-Base-Disziplin); ein Lockfile realisiert semantisch identisch in jedem Adapter — Realisierung ist nicht pro Adapter frei wählbar. Die Lease umfasst die Root-Scope (`wiki/` inklusive `log.md`, `index.md` und aller Root-Dateien).
 - **Kein textueller Auto-Merge (AD-17c, A0-14):** Zwei Branches mit Änderungen am selben Concept-Pfad werden nie textuell automatisch gemerged; der Merge ist compiler-vermittelt und durchläuft die AD-16-Klassifikation mit explizitem `log.md`-Eintrag, falls die Inhalte ungleich sind.
 - **Dirty-Tree-Schutz (AD-17e/f, A0-16):** Vor jeder Mutation wird die Working Copy des zu mutierenden Bereichs geprüft; fremde uncommittete Änderungen werden geschützt (Stash/Scratch-Zone) und in `log.md` dokumentiert. Mutationen operieren nur auf Directory-/Commit-Ebene — Commit-Boundary ist die Mutation-Boundary.
 - **Lease-Staleness (AD-17d, A0-15):** TTL plus Lease-Registrierung im Clone-Root-State; uncommittete Leases gelten nach Run-Abbruch als stale, verwaiste Leases können übernommen oder als stale markiert und protokolliert werden; `raw/` dient als Zugriffs- und Consistency-Basis.
 - **Auflösungsautorität (AD-17g, A0-17):** Der die Lease haltende Compilation Run löst AD-16-Kollisionen (Default: Erhaltung) auf; menschliche Eskalation nur bei Unentscheidbarkeit; die Auflösung wird an Commit-Hash und Klassifikation im `log.md` gebunden.
 - **Determinismus-Vertrag (AD-17h/FT-10, A0-19):** Über denselben Git-State und dasselbe Eingabeset erzeugen zwei unabhängige Runs denselben Bundle-State; Abweichung gilt als Fehler der Klassifikation, nicht als Rauschen. Das Enforcement lebt im MVP als Agent-Instruktions-Validator (D-3/Q-6) und muss mechanisch bestätigt sein, bevor es tragend wird.
 - **Inkrementelle Evolution und menschliche Kuratierung (A0-21, FT-9):** Unabhängige Concepts werden nicht bei jedem Lauf regeneriert; eine menschliche Korrektur eines maschinell erzeugten Concepts überlebt als normale Kuratierung (Datei-Edit + Git) — kein Nulling-Diff und keine Re-Kompilation des ganzen Bundles.
 - **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.
 ## 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.
 - Der compiler-vermittelte Merge (AD-17c) und die Kollisionsauflösung (AD-17g) setzen die AD-16-Klassifikation samt `log.md`-Dokumentation voraus, die in Epic 4 umgesetzt wird.
 - 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).
@@ -0,0 +1,165 @@
 ---
 title: 'Inkrementellen Datenfluss implementieren (Interpret → Reconcile → Synthesize → Update) (Story 3.1)'
 type: 'feature'
 created: '2026-08-18'
 status: 'done'
 review_loop_iteration: 0
 baseline_commit: 802a5576eb4bbf54761a947e43e68b7e7ea9d67d
 context:
  - _bmad-output/implementation-artifacts/epic-3-context.md
 ---
 <frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
 ## Intent
 **Problem:** Die Compiler-Instruktion (`schema/compiler.md`) kennt heute nur den **Neu-Anlage-Pfad** (Erzeugung neuer Concepts). Die Erweiterung/Präzisierung/Korrektur bestehender Concepts wird an zwei Stellen explizit als Epic-3-Vorbehalt ausgeschlossen (`compiler.md:40` §3.2-Kollision-Hold „Aktualisierung ist Epic 3"; `compiler.md:287` §7), und der §0-Aufruf (`compiler.md:13`) beschreibt die Phasenfolge Interpret → Reconcile → Synthetisieren → Mutieren → Validieren nur als Erzeugungs-Ablauf. Damit ist der zweite Compilation Run gegen bestehendes Wissen (FR-4) instruktionsseitig nicht definiert: Es gibt keinen deterministischen Pfad, wie ein Run neue Evidenz mit den tatsächlich betroffenen Concepts verrechnet, ohne unverändertes Wissen zu regenerieren (AD-5, A0-6, FR-6, FR-12).
 **Approach:** Story 3.1 verankert den **inkrementellen Datenfluss** als Erweiterungs-Instruktion in `schema/compiler.md` (D-3, rein textuell — kein Code, kein Standalone): (a) das bestehende Reconcile (§3) wird vom bloßen Dateikollisions-Hold zum **Update-Routing** (erkannte bestehende Wissenseinheit → Update-Kandidat, kein Duplikat, kein stilles Überschreiben); (b) eine neue Update-Mutations-Sektion (§5.9) spezifiziert, wie ein bestehendes Concept erweitert/präzisiert/korrigiert wird (FR-6) und wie Inline-Provenienz (§5.5) und `sources` nachgeführt werden; (c) die **Erhaltungs-Invariante** wird verankert: nicht betroffene Concept-Pfade bleiben bit-identisch unverändert (FT-6, FR-12), Git-Änderungen konzentrieren sich auf betroffene Concepts — nachweisbar über einen deterministischen Diff-Selbsttest; (d) die Defer-Bausteine**R-1** (Input-Zuwachserkennung: welche `raw/`-Dateien sind neu/modifiziert — via `git diff` und/oder SHA-256-Record aus `source.md`) und **P2** (Pre-Run-Reconcile-Check-Block als wiederverwendbarer, textueller Vorprüf-Block) werden als Teil des inkrementellen Runs eingearbeitet. Vertrag (`schema/wiki-compiler.md`), Validator (`schema/validator.md`) und `raw/` bleiben read-only (AD-3); keine neue §7-Invaliditätsklasse.
 ## Boundaries & Constraints
 **Always:**
 - **Story 3.1 ist eine Instruktions-Story (D-3).** Der inkrementelle Datenfluss wird ausschließlich in `schema/compiler.md` als deterministische Text-Instruktion verankert. Kein ausführbares Programm, kein Standalone-Validierungs-Tool, keine neue §7-Invaliditätsklasse, kein Change an `schema/wiki-compiler.md` / `schema/validator.md` / `raw/` (AD-3).
 - **Das Update ersetzt den Abbruch, nicht die Erhaltung.** Wo heute der Kollisions-Hold bei „Concept existiert bereits" den Run für die Einheit abbricht, tritt das Update-Routing: eine erkannte bestehende Wissenseinheit wird im **bestehenden Concept-Pfad** aktualisiert (keine neue Datei, kein Duplikat — FR-6). Beibehaltende und neue belegte Aussagen werden sauber geführt. Kein stummer Überschreib (bestehende Provenienz/Inhalte werden nie ohne Beleg entfernt — AD-16-Default behält die Erhaltung; die AD-16-Klassifikation selbst ist Epic 4, Story 4.1, und wird hier nicht vorweggenommen).
 - **Erhaltungs-Invariante (Kern):** Ein Compilation Run darf nur die Concepts **neu anlegen oder verändern**, die durch den erkannten neuen Erkenntnis-Zuwachs tatsächlich betroffen sind. Nicht betroffene Concept-Pfade bleiben byte-identisch unverändert (FT-6, FR-12); es gibt **nie** „Regenerate Everything" aus allen Rohquellen (AD-5, A0-6). Nachweisbar über einen re-executierbaren Diff-Selbsttest (`git diff --stat` auf `wiki/` zeigt ausschließlich betroffene Dateien + `log.md` + Index-Nachführungen).
 - **published/committed als Input (AD-17.2/AD-17a):** Der Run verarbeitet ausschließlich veröffentlichte (committete) Inhalte als Input — neues Source Material, sobald es unter `raw/` committet ist, und das bestehende `wiki/` aus committetem Zustand. Zwischenstände während einer Mutation sind nie Input (§1.1 bleibt bestehende Regel, wird referenziert).
 - **Reconcile-Ergebnis ist die Update-Kandidatenliste.** Der Reconcile-Schritt erzwingt, dass der Producer die Menge der betroffenen Concepts als **nachvollziehbare Kandidatenliste (Concept-Pfade)** erhebt, bevor mutiert wird. Der feinkörnige Relevanz-Findungsmechanismus (grep/ripgrep/Markdown-Traversal/Link-Following als eigene Ausformulierung) ist Story 3.2 vorbehalten; Story 3.1 bindet die Kandidatenerhebung an textuelle, deterministische Mittel (Konzept-/Term-Überschneidung zwischen neuer Evidenz und bestehenden Concept-Bodies via `grep`/`ripgrep`, `index.md`-Traversal, Link-Following) — keine Embeddings/Vector (AD-13).
 - **Kein Leasing-/Dirty-Tree-Scope in 3.1.** Leasing, Dirty-Tree-Schutz, Staleness, Merge-vermittelte Kollision sind Story 3.5/3.6. Story 3.1 behält die bestehende Commit-Boundary = Mutations-Boundary-Regel (AD-17f, `compiler.md:13`/`:63`) bei und ändert sie nicht.
 - **Defer-Bausteine werden mitgezogen:** deferred-work **R-1** (Input-Zuwachserkennung via `git diff` + SHA-256-Record aus `source.md`) und **P2** (Pre-Run-Reconcile-Check-Block bündeln) werden als Teil der inkrementellen Run-Instruktion eingearbeitet und in `deferred-work.md` als aufgegriffen markiert (append-only, keine Duplikate).
 - `sprint-status.yaml`: Key `3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile` → **in-progress**.
 **Ask First:** AD-7d-Renames/Redirects bestehender Concepts · Einführung einer echten Kollisions-Klassifikation (CORRECTING/CONTRADICTING etc.) vor Epic 4 · Wechsel des `generated.at`-Verhaltens bei Updates gegenüber der hier festgelegten Konvention (s. Design Notes) · Validator-/Vertrags-/`raw/`-Change · Änderung der Commit-Boundary-Regel.
 **Never:** Änderungen an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3) · neue §7-Invaliditätsklasse · Einführung eines Standalone-Programms/Validators (D-3) · „Regenerate Everything" über bestehende Concepts (AD-5, A0-6) · stummer Überschreib oder Löschung bestehender Provenienz ohne Beleg (AD-16-Default: Erhaltung) · Embedding/Vector-Suche (AD-13) · Duplikat-Anlage eines bestehenden Concept-Pfads.
 ## I/O & Edge-Case Matrix
 | Scenario | Input / State | Expected Output / Behavior | Error Handling |
 |----------|--------------|---------------------------|----------------|
 | HAPPY_PATH_UPDATE | Bestehendes Concept `wiki/<a>/<c>.md` + neue committete Evidenz `raw/…` betrifft es (Term-/Konzept-Überschneidung) | Update-Routing: Concept wird im bestehenden Pfad erweitert/präzisiert (§5.9); Inline-Provenienz + `sources` nachgeführt (nur echt neue Belege ergänzt); `log.md`-Eintrag (Vertrag §5-Format) mit Story 3.1; kein neues File, kein Duplikat | N/A |
 | UNTOUCHED_CONCEPT | Neue Evidenz betrifft ein bestehendes Concept **nicht** (keine Überschneidung) | Concept bleibt **unverändert**: keine Dateiänderung, kein Index-, kein `log.md`-Zusatz (FT-6/FR-12); Diff-Selbsttest zeigt keinen Ghost-Diff auf diesem Pfad | N/A |
 | INPUT_UNCOMMITTED | Run erhält uncommittete Zwischenstände (Arbeitskopie `wiki/`/`raw/` abweichend von HEAD) als Input | Run lehnt ab bzw. bezieht nur published/committed Zustand ein (AD-17a); keine Mutation gegen Zwischenstände | textuell benannter Abbruch „published/committed Input erforderlich" (§1.1-Fortsetzung) |
 | CHANGE_DETECTION (R-1) | `raw/` enthält (a) eine neue, (b) eine unveränderte Evidenzdatei | Zuwachserkennung: nur die neue/modifizierte Datei wird als Zuwachs interpretiert (git-diff-basiert und/oder SHA-256-Record aus `source.md`); unveränderte bleiben außen vor | unlesbarer/fehlender SHA-256-Record → Hinweis, Datei dennoch als Zuwachs nicht doppelt verarbeiten |
 | CONCEPT_COLLISION_BESTEHEND | Erkannte Wissenseinheit = bereits existierendes Concept (Ziel-Pfad belegt) | Statt bisherigem Kollision-Hold-Abbruch: Update-Routing (§5.9) — Mutation im bestehenden Pfad; kein Duplikat, kein stummer Überschreib; Index-Link bleibt unverändert gültig | Widersprechender Inhalt ohne Ersetzungsevidenz → Erhaltung; explizite Ablage in `log.md` (Epic-4-Interface, keine Korrektur-Klassifikation hier) |
 | PRE_RUN_RECONCILE (P2) | Run-Start mit neuem Zuwachs | Pre-Run-Reconcile-Check-Block (Zielpfade, Quellen-Existenz EC-1, Betroffenheits-Kandidatenliste, `wiki/index.md`-V-1) wird vor jeder Mutation durchlaufen und textuell festgehalten | fehlende Bundleroot → Run-FAIL (V-1, besteht fort) |
 </frozen-after-approval>
 ## Code Map
 - `schema/compiler.md` — **primär mutiert** (D-3, einziger Instruktions-Ort):
  - §0-Aufruf (`:13`): Ablaufstruktur um die Update-Variante präzisieren — die sechs Phasen bleiben; Reconcile/Mutieren betreffen auch **bestehende** Concepts.
  - §3 Reconcile (`:37–41`): Pkt. 2 Kollision-Hold (`:40`) — Epic-3-Abbruch („Aktualisierung ist Epic 3") **ersetzen** durch Update-Routing (→ §5.9); Candidate-Erhebung (betroffene Concepts) textuell-deterministisch; Pkt. 3 V-1-Prüfung (`:41`) bleibt.
  - **Neue §5.9 „Inkrementelles Update bestehender Concepts (Story 3.1)"** nach §5.8 (nach `:233`, vor §6 `:234`): (1) Update-Stimulus = Reconcile-Kandidatenliste (betroffene Concept-Pfade); (2) Mutationsmechanik — Erweitern (Absatz/Beleg ergänzen), Präzisieren (Aussage schärfen, Beleg neu/nachführen), Korrigieren (ersetzte Aussage + Ersetzungsbeleg, keine stille Löschung), Frontmatter-`sources` nur um echte neue Belege ergänzen, `generated.at` = aktueller Run-Zeitstempel (Konvention, s. Design Notes), vorhandenes `verified` bleibt stehen; (3) Index-/Link-Form unverändert (§5.6-Pin), kein neuer Link bei reinem Body-Update; (4) `log.md`-Eintragspflicht (Vertrag §5; „Story 3.1-Update" markieren); (5) deterministischer Diff-Selbsttest der Erhaltungs-Invariante (nur betroffene Dateien + log.md + Index im `git diff --stat` auf `wiki/`); (6) Change-Detection (Defer R-1: `git diff` auf `raw/` und/oder SHA-256-Record aus `raw/**/source.md` bestimmt den Zuwachs) und Pre-Run-Reconcile-Check-Block (Defer P2) als wiederverwendbare textuelle Check-Blöcke der Run-Vorphase.
  - §7 (`:287`): Epic-3-Vorbehalt auf die verbleibenden 3.x-Themen kürzen (Synthese über mehrere Concepts → 3.4; Leasing/Dirty-Tree → 3.5/3.6; Relevanz-Verfeinerung → 3.2) — das Update-Thema ist damit aus dem Vorbehalt entlassen.
  - §8 Revisionslog (`:291–317`): **Revision 2.4** (Story 3.1) + Normreferenzen unverändert (AD-5, AD-6, AD-17h sind schon gelistet; A0-6/FR-6/FR-12 ggf. ergänzen); Abschlussklausel (kein Vertrag-/Validator-/`raw/`-Change, keine neue §7-Klasse, kein Standalone).
 - `wiki/log.md` — **append**: Story-3.1-Eintrag (Vertrag §5-Format, `## YYYY-MM-DD` Gruppe nach `:3`) mit Update-Semantik, Erhaltungs-Invariante, Diff-Selbsttest-Beleg (Ist-Baum: kein Ghost-Diff), Statuswechsel `3-1-…` `backlog → in-progress`, per-Datei-Validator-Verdikt-Zeile (Ist-Baum SUCCESS) — Analogie Story-2.5-Eintrag (`log.md:5`).
 - `_bmad-output/implementation-artifacts/deferred-work.md` — **mutiert** (append-only): Defer R-1 (`:126–128`) und P2 (`:160–162`): `status`-Nachführungs-Notiz „aufgegriffen (2026-08-18, Story 3.1 — §5.9)" — bestehende Einträge nicht verändern, nur Status-Ergänzung im vorgegebenen append-only-Stil.
 - `_bmad-output/implementation-artifacts/sprint-status.yaml` — **mutiert**: Key `3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile` (`:54`) → `in-progress`.
 - `schema/validator.md`, `schema/wiki-compiler.md`, `raw/…`, bestehende Concept-Inhalte — **read-only** (AD-3). Story 3.1 mutiert selbst keine Concept-Inhalte (Instruktions-Story); Demo-/Nachweis-Läufe laufen im Sandbox-Baum oder gegen den Ist-Baum ohne Inhalts-Mutation (Diff-Selbsttest + Validator-Verdikt).
 ## Tasks & Acceptance
 **Execution:**
 - [x] `schema/compiler.md` — §3-Pkt.-2-Hold → Update-Routing; Candidate-Erhebung; neue §5.9 (Mutationsmechanik, log.md, Diff-Selbsttest, R-1-Change-Detection, P2-Check-Block); §0-Präzisierung; §7-Vorbehalt kürzen; §8-Revision 2.4. Kein Vertrag-/Validator-/`raw/`-Change.
 - [x] `wiki/log.md` — Story-3.1-Eintrag (Vertrag §5-Format) mit Update-Semantik, Erhaltungs-Invariante + Diff-Selbsttest-Beleg, Statuswechsel, Validator-Verdikt.
 - [x] `deferred-work.md` — R-1-/P2-Einträge mit „aufgegriffen (Story 3.1)"-Statusnachführung markieren (append-only); `sprint-status.yaml` — Key `3-1-…` → `in-progress`.
 - [x] Edge-Tests im Sandbox-Baum (I/O-Matrix): HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT (kein Diff), CONCEPT_COLLISION_BESTEHEND (kein Duplikat), CHANGE_DETECTION (nur Zuwachs), PRE_RUN_RECONCILE.
 **Acceptance Criteria:**
 - Given ein bestehendes Bundle und neues Source Material, when ein Compilation Run startet, then folgt er dem inkrementellen Datenfluss Interpret → Reconcile → Synthesize → Update affected Concepts (AD-5, A0-6) — instruktionsseitig in `schema/compiler.md` (§3 + neue §5.9) verankert.
 - Given ein Run, when er einen bestehenden Concept-Pfad nicht betrifft, then bleibt dessen Inhalt unverändert erhalten — keine Regeneration (FT-6, FR-12); belegt durch den re-executierbaren Diff-Selbsttest (nur betroffene Dateien + `log.md` + Index im `git diff --stat`).
 - Given ein Lauf, when er abgeschlossen ist, then konzentrieren sich die Git-Änderungen auf durch die neue Erkenntnis betroffene Concepts (AD-5, FR-6) — kein Ghost-Diff, kein Duplikat bestehender Concept-Pfade.
 - Given der Run-Input, when verarbeitet, then verwendet er ausschließlich published/committed Inhalte und nie Zwischenstände während der Mutation (AD-17.2/AD-17a) — bestehende §1.1-Regel bleibt und wird referenziert.
 - Given die Instruktion, when geprüft, then bleibt `schema/validator.md`/`schema/wiki-compiler.md`/`raw/` unverändert (AD-3), es gibt keine neue §7-Klasse und kein Standalone (D-3) — der Validator läuft auf dem Ist-Bundle SUCCESS (per-Datei-Verdikt-Nachweis in `wiki/log.md`).
 ## Spec Change Log
 - **2026-08-18 (Erstellung):** Initiale Approve-Baseline.
 ## Design Notes
 **Warum §5.9 als eigene Sektion statt Umbau von §5:** Die 5.x-Sektionen sind die nachgelagerten Spezifikations-Ebenen der Mutationsphase (§5.5 Claim-Provenienz, §5.6 Links, §5.7 Bereichszuordnung, §5.8 Discovery). Das inkrementelle Update ist die nächste Spezifikations-Ebene desselben §5 (Mutieren) — konsistent als §5.9, verortet nach §5.8 vor §6. Der bestehende §3-Reconcile wird nicht umgeschrieben, sondern seine Pkt.-2-Ausnahme („Aktualisierung ist Epic 3") durch das Update-Routing ersetzt — der Kollisions-Hold-Teil („nicht stumm überschreiben") bleibt als Schutzprinzip erhalten und wird lediglich um den Update-Ausweg ergänzt.
 **Erhaltungs-Invariante als Diff-Selbsttest:** Die Inkrementalität ist nur dann AD-17h-fest belegbar, wenn sie mechanisch kontrollierbar ist. Konvention: Nach jedem Run prüft der Producer über `git diff --stat -- wiki/` (bzw. `git status --porcelain`), dass die geänderten Dateien ⊆ (betroffene Concepts ∪ `log.md` ∪ nachgeführte `index.md`) sind. Eine Abweichung (Ghost-Diff) ist ein Instruktions-Verstoß (FT-6) und wird textuell benannt. Für Story 3.1 selbst (Instruktions-Story ohne Inhalts-Mutation) ist der Nachweis: Ist-Baum zeigt keinen neuen Ghost-Diff nach dem Instruktions-Ergänzungs-Commit.
 **`generated.at`-Konvention bei Updates (A0-20):** Ein maschinelles Update eines maschinell erzeugten Concepts bleibt maschinell → `generated` bleibt gesetzt, `at` wird auf den aktuellen Run-Zeitstempel aktualisiert (einmalige `at`-Festlegung pro Run, Dryrun-P1-Konvention). `verified` wird durch ein maschinelles Update **nicht** gesetzt und ein vorhandenes human-`verified` wird **nicht** entfernt (menschliche Kuratierung ist Bestandswissen, A0-21/FR-13-Nähe). Ein menschliches Update ändert `generated`/`verified` nicht automatisch.
 **Defer-Bausteine inside der Run-Vorphase:** Defer R-1 (Change-Detection) beantwortet „welche `raw/`-Dateien sind Zuwachs" — als textueller Check-Block vor der Interpretation (git-diff-basiert und/oder SHA-256-Record aus `source.md`); Defer P2 bündelt die bestehenden textuellen Vorprüfungen (Zielpfad, Quellen-Existenz EC-1 via Validator-Punkt, Reconcile-Kandidaten-Erhebung, V-1) zu einem wiederverwendbaren Pre-Run-Reconcile-Check-Block. Beide sind **keine** neuen Prozesse — nur reproduzierbare Check-Blöcke innerhalb der Instruktions-Ausführung (D-3).
 ## Verification
 **Commands (re-executierbar, ab Workspace-Root):**
 1. **Instruktions-Integrität:** `grep -n "5.9" schema/compiler.md` liefert die neue Sektion; `grep -n "Aktualisierung ist Epic 3" schema/compiler.md` liefert **keinen** Treffer mehr (Hold durch Update-Routing ersetzt); §7-Vorbehalt enthält „Update" nicht mehr.
 2. **Diff-Selbsttest (Erhaltungs-Invariante):** vor dem Story-Commit den Ist-Baum-Status aufzeichnen, nach dem Commit `git diff --stat -- wiki/` prüfen — erwartet: nur die von Story 3.1 berührten Dateien (`log.md`, ggf. `index.md`) bzw. nach dem Instruktions-Commit der Story selbst kein weiterer Ghost-Diff; auf dem Sandbox-Baum: HAPPY_PATH_UPDATE zeigt ausschließlich betroffene Datei + log.md + Index.
 3. **Validator-Lauf:** alle `wiki/`-Dateien SUCCESS (unverändert zur Story 2.5; der Validator ist eine reine Text-Instruktion, human-mechanisch ausgeführt, D-3 — es gibt keinen CLI-Invoker); das per-Datei-Verdikt wird als Ausführungs-Nachweis im `log.md`-Eintrag geführt.
 **Manual checks:**
 - §3-Pkt.-2-Hold ersetzt (Update-Routing) und §5.9 vorhanden (Update-Semantik, Diff-Selbsttest, R-1/P2-Bausteine); `compiler.md` §8-Revision 2.4 mit Abschlussklausel; kein `schema/validator.md`-/`schema/wiki-compiler.md`-/`raw/`-Diff; §7-Vorbehalt gekürzt; `wiki/log.md`-Eintrag datiert mit Story-3.1-Semantik, Diff-Selbsttest-Beleg, Statuswechsel `backlog → in-progress`, per-Datei-Verdikt; `deferred-work.md`-R-1-/P2-Einträge als aufgegriffen markiert (append-only); `sprint-status.yaml` konsistent (`3-1-…` → in-progress).
 ## Suggested Review Order
 **Inkrementeller Datenfluss — Update-Routing (Einstieg)**
 - §3 Reconcile: Kollision-Hold durch Update-Routing ersetzt — der architektonische Kern der Story
  [`compiler.md:40`](../../schema/compiler.md#L40)
 - Textuell-deterministische Kandidatenliste (AD-13) als Update-Stimulus
  [`compiler.md:41`](../../schema/compiler.md#L41)
 - §0-Aufruf: sechs Phasen für Neu-Anlage- und Update-Variante präzisiert
  [`compiler.md:13`](../../schema/compiler.md#L13)
 **§5.9 Update-Mutationsmechanik (neue Sektion)**
 - §5.9-Überblick: einziger Instruktions-Ort der Update-Mutationsmechanik (D-3)
  [`compiler.md:236`](../../schema/compiler.md#L236)
 - Update-Stimulus: Kandidatenliste, published/committed-Input (§1 Pkt. 1, AD-17a)
  [`compiler.md:240`](../../schema/compiler.md#L240)
 - Mutationsmechanik: Erweitern/Präzisieren/Korrigieren + Mehrfach-Treffer-Konsolidierung
  [`compiler.md:242`](../../schema/compiler.md#L242)
 - Index-/Link-Form unverändert (§5.6-Pin); `log.md`-Eintragspflicht bleibt davon unberührt
  [`compiler.md:249`](../../schema/compiler.md#L249)
 - Worked Example an den realen Ist-Baum gebunden (FR-12, kein Ghost-Diff)
  [`compiler.md:259`](../../schema/compiler.md#L259)
 **Erhaltungs-Invariante & Diff-Selbsttest (Review-Patch-Kern)**
 - Diff-Selbsttest operationalisiert: `git diff --name-only -- wiki/` ⊆ Kandidatenliste ∪ log.md ∪ Index
  [`compiler.md:251`](../../schema/compiler.md#L251)
 - Run-Vorphase-Bausteine: Change-Detection (R-1, Baseline = HEAD der vorherigen Mutations-Boundary) + Pre-Run-Reconcile-Check-Block (P2)
  [`compiler.md:255`](../../schema/compiler.md#L255)
 - Revisionslog 2.4.1: Review-Patch-Runde mit Abschlussklausel (AD-3/D-3 gehalten)
  [`compiler.md:348`](../../schema/compiler.md#L348)
 **Referenz-Abgrenzung §5.7/§5.8**
 - §5.7 Pkt. 3: Top-Level-Kollision → Update-Routing, kein MOVE
  [`compiler.md:199`](../../schema/compiler.md#L199)
 - §5.8 Pkt. 2: Rev-9-Punkt-11-Area-Lesart als geschlossene Lücke dokumentiert
  [`compiler.md:231`](../../schema/compiler.md#L231)
 - §5.8 Pkt. 3: §5.8-Hold bewusst nicht das Update-Routing (Zwei-Ebenen-Kartografie)
  [`compiler.md:232`](../../schema/compiler.md#L232)
 **Nachweise (Log, Deferred-Work, Sprint-Status)**
 - `wiki/log.md`: Story-3.1-Nachweis mit Diff-Selbsttest-Beleg und Rev-9-Präzisierung
  [`log.md:4`](../../wiki/log.md#L4)
 - `deferred-work.md`: R-1 (Change-Detection) und P2 (Pre-Run-Reconcile) als aufgegriffen markiert
  [`deferred-work.md:129`](deferred-work.md#L129)
 - Review-Findings-Protokoll (VG-Nachweis, F9/F12, F17-Defer als Folge-Aufgabe)
  [`deferred-work.md:164`](deferred-work.md#L164)
 - `sprint-status.yaml`: Story 3.1 `in-progress` (Sprint-Sync konsistent)
  [`sprint-status.yaml:54`](sprint-status.yaml#L54)
@@ -29,7 +29,7 @@
 # - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
 # - Retrospective appends its action items to action_items; the status view surfaces open ones
 generated: 08-14-2026 00:00
-last_updated: 08-18-2026 22:00
+last_updated: 08-18-2026 22:30
 project: wow20
 project_key: NOKEY
 tracking_system: file-system
@@ -50,8 +50,8 @@ development_status:
  2-5-progressive-discovery-über-index-md-bereitstellen: done
  epic-2-retrospective: done
-  epic-3: backlog
+  epic-3: in-progress
-  3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile: backlog
+  3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile: review
  3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip: backlog
  3-3-bestehende-concepts-erweitern-präzisieren-korrigieren: backlog
  3-4-wissen-aus-mehreren-sources-synthetisieren: backlog
@@ -2,7 +2,7 @@
 > **Status:** abgeleitet (Story 2.1) — deterministische, agent-unabhängige Compiler-Instruktion für die Erzeugung neuer Concepts aus Source Material.
 > **Normative Grundlage:** `schema/wiki-compiler.md` (autorisiert, Story 1.3) — insbesondere §2 Bundleroot, §3 Feldsubset (§3.1–§3.7), §5 `log.md`-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
-> **Prüfgrundlage:** `schema/validator.md` (abgeleitet, Story 1.4; Revision 8) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h).
+> **Prüfgrundlage:** `schema/validator.md` (abgeleitet, Story 1.4; Revision 9) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h).
 > **Ableitungsdatum:** 2026-08-16
 > **Kanonischer Producer-Actor:** `wow-compiler/0.1.0`
@@ -10,7 +10,7 @@
 Diese Datei ist **der einzige Ort der Concept-Erzeugungs-Instruktion** des Projekts. Sie ist **rein textuell** — kein ausführbarer Code, kein Standalone-Programm (D-3). Sie wird von einem vorhandenen agentischen Host (AD-11) als **deterministische Anweisung** befolgt; sie ersetzt kein LLM-Reasoning, sondern **kanalisiert** es in eine reproduzierbare, textuell nachvollziehbare Abfolge (AD-5, AD-6, AD-17h).
-**Aufruf:** Der Producer führt den Run in der folgenden festen Ablaufstruktur aus (deterministische Reihenfolge): (0) Input prüfen, (1) Interpretieren, (2) Reconcile, (3) Synthetisieren, (4) Mutieren, (5) Validieren. Jede erzeugte Concept-Datei MUSS anschließend gegen `schema/validator.md` als SUCCESS nachweisbar sein — erst dann gilt der Run als erfolgreich. Bei einem Validierungs-FAIL wird das Bundle **nicht** als erfolgreicher Run behandelt, `raw/` bleibt unangetastet (AD-3), und die Fehlerursache ist textuell identifizierbar (NFR-4). Die **Commit-Boundary ist die Mutations-Boundary** (AD-17f): Zwischenstände vor Erreichen der Success-Bedingung werden nicht als fertige Mutation veröffentlicht.
+**Aufruf:** Der Producer führt den Run in der folgenden festen Ablaufstruktur aus (deterministische Reihenfolge): (0) Input prüfen, (1) Interpretieren, (2) Reconcile, (3) Synthetisieren, (4) Mutieren, (5) Validieren. Diese sechs Phasen gelten für **zwei Ausführungs-Varianten** gleichermaßen: den **Neu-Anlage-Pfad** (Erzeugung neuer Concepts, §§4–5) und den **Update-Pfad** (inkrementelles Update bestehender Concepts, §3 + §5.9, Story 3.1). In beiden Varianten betreffen Reconcile (2) und Mutieren (4) die Erkennung und Veränderung **betroffener** Wissenseinheiten — neue Einheiten werden angelegt, bereits bestehende werden im bestehenden Concept-Pfad aktualisiert (never „Regenerate Everything", AD-5). Jede erzeugte **und** jede veränderte Concept-Datei MUSS anschließend gegen `schema/validator.md` als SUCCESS nachweisbar sein — erst dann gilt der Run als erfolgreich. Bei einem Validierungs-FAIL wird das Bundle **nicht** als erfolgreicher Run behandelt, `raw/` bleibt unangetastet (AD-3), und die Fehlerursache ist textuell identifizierbar (NFR-4). Die **Commit-Boundary ist die Mutations-Boundary** (AD-17f): Zwischenstände vor Erreichen der Success-Bedingung werden nicht als fertige Mutation veröffentlicht.
 **Entscheidungsebenen (keine eigene Norm):**
@@ -37,8 +37,10 @@ Bestätigung (Story 1.4): schema/validator.md      (mechanische Prüfung, kein L
 ## 3. Reconcile (gegen das bestehende Bundle)
 1. Vor der Anlage prüfen, ob die erkannte Wissenseinheit **bereits als Concept** im Bundle existiert (deterministisch: Dateikollision über den relativen OKF-Pfad, AD-7a).
-2. **Kollision-Hold:** Existiert bereits ein Concept mit dem Ziel-Pfad, wird **nicht** stumm überschrieben. Diese Instruktion deckt die Anlage **neuer** Concepts ab; die Erweiterung/Präzisierung/Korrektur bestehender Concepts ist Epic 3 (AD-5, FR-6). Der Run bricht für diese Einheit mit einem textuell identifizierbaren Hinweis ab („Concept existiert bereits — Aktualisierung ist Epic 3") und **setzt mit den übrigen erkannten Wissenseinheiten fort**; die gehaltene Einheit erzeugt keine Datei, keinen Index-Link und keinen `log.md`-Eintrag. Mindestens eine erfolgreich erzeugte und mindestens eine gehaltene Einheit → der Run ist **teilweise erfolgreich**: die erzeugten Concepts werden normal validiert und veröffentlicht, die gehaltenen Einheiten werden textuell als solche benannt (NFR-4).
+2. **Update-Routing (statt Kollision-Hold; Story 3.1):** Existiert bereits ein Concept mit dem Ziel-Pfad, wird **nicht** stumm überschrieben und **kein** Duplikat angelegt — die erkannte Wissenseinheit wird als **Update-Kandidat** im **bestehenden Concept-Pfad** aktualisiert (Erweitern/Präzisieren/Korrigieren gemäß §5.9; FR-6). Die Mutationsmechanik für Updates spezifiziert §5.9; der Kollisions-Hold-Schutzprinzip („nicht stumm überschreiben") bleibt als Grundsatz der Erhaltung erhalten (AD-16-Default: bestehende Provenienz/Inhalte werden nie ohne Beleg entfernt). Der **Neu-Anlage-Pfad** dieser Instruktion bleibt für Wissenseinheiten, deren Ziel-Pfad **nicht** belegt ist (§5.1/§5.7).
-3. Der Run prüft zusätzlich, ob `wiki/index.md` als Bundleroot existiert (V-1-Vorbedingung des Validators); fehlt sie, darf kein Concept erzeugt werden (Run-FAIL, Vertrag §2).
+   **Kandidatenliste (betroffen-Bestimmung):** Vor jeder Mutation erhebt der Producer die Menge der betroffenen Concepts als **nachvollziehbare Kandidatenliste** (relative OKF-Pfade ohne `.md`) mit **textuell-deterministischen Mitteln** (AD-13): (a) Term-/Konzept-Überschneidung zwischen der neuen Evidenz und den bestehenden Concept-Bodies via `grep`/`ripgrep` über `wiki/` (z. B. `rg -l '<konzeptterm>' wiki/`); (b) `index.md`-Traversal (Bundleroot- und Area-`index.md`-Dateien, gewurzelte Erreichbarkeit Root → Area → Concept, §5.8) der dadurch betroffenen Bereiche; (c) Link-Following aus bereits betroffenen Concepts (§5.6-Pin) auf weitere Concept-Pfade. Die Kandidatenliste wird textuell festgehalten (Pre-Run-Reconcile-Check-Block, §5.9 Pkt. 6). Keine Embeddings/Vector-Suche (AD-13); der feinkörnige Relevanz-Findungsmechanismus als eigene Ausformulierung ist Story 3.2 vorbehalten — §5.9 bindet die Erhebung an die hier genannten deterministischen Mittel.
   Löst eine erkannte Wissenseinheit auf **keinen** bestehenden Concept-Pfad auf (kein Update-Kandidat), wird sie als **neue** Einheit über den Neu-Anlage-Pfad (§5.1/§5.7, §3.2-Kollisionsprüfung ist damit erstbestanden) behandelt.
 3. Der Run prüft zusätzlich, ob `wiki/index.md` als Bundleroot existiert (V-1-Vorbedingung des Validators); fehlt sie, darf kein Concept erzeugt oder aktualisiert werden (Run-FAIL, Vertrag §2).
 ## 4. Synthetisieren (Provenienz & Trust)
@@ -194,7 +196,7 @@ Bereichszuordnung und Concept-Hierarchie sind **textual-deterministisch** (AD-7c
   | `wiki/llm-wiki-prinzip.md` | `llm-wiki-prinzip` |
   Eine als Area gedachte Anlage (`wiki/<area>/index.md` + Concept darunter) ist damit **konform**; der Bereichs-Hinweis aus §5.1 ist aufgelöst. Konzept-`id`s (s. `sources[].id`, §5.5 Pkt. 3) sind unabhängig davon je Concept eindeutig — Adressraum ist Concept-Pfad + `id`.
-3. **Top-Level-Kollisions-Hold (A0-10, fixierter §3.2):** Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3.1/§3.2, AD-7a), löst der **fixierte §3.2-Kollisions-Hold** aus — **kein** neues Prädikat, **kein** stiller Overwrite, kein Index-Link, keine Datei: der Run bricht für diese Einheit textuell ab („Concept existiert bereits — Aktualisierung ist Epic 3") und setzt mit den übrigen Einheiten fort (§3.2; „teilweise erfolgreich"). **Kein MOVE/Neuzuordnung bestehender Concepts** — das ist Kuratierung mit AD-7d-Redirect-Pflicht (Epic-3-Nähe, nicht in den ACs dieser Story; Ask-First).
+3. **Top-Level-Update-Routing (A0-10, §3-nachgeführt):** Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3.1/§3.2, AD-7a), löst das **Update-Routing (§3 Pkt. 2, §5.9)** aus — **kein** neues Prädikat, **kein** Duplikat, **kein** stiller Overwrite, keine neue Datei, kein Index-Link: die erkannte Einheit wird als **Update-Kandidat** im bestehenden Concept-Pfad behandelt (Mutation gemäß §5.9). **Kein MOVE/Neuzuordnung bestehender Concepts** — das ist Kuratierung mit AD-7d-Redirect-Pflicht (Epic-3-Nähe, nicht in den ACs dieser Story; Ask-First).
 4. **File-relatives Link-Auflösungsmodell (löst das §5.6-Defer):** Concept-Links sind **file-relativ** zur `.md`-Datei (AD-8/FR-10/AD-7b — eine syntaktische Form, beide Ebenen): bei Root-Dateien ist file-relativ ≡ bundle-relativ (die bestehenden Bestands-Links bleiben byte-identisch, Null-Delta zu Story 2.3); in Areas bezeichnen `../`-Präfixe die Aufwärts-Ziele **innerhalb `wiki/`** (`[<text>](../<root-concept>.md)`). Auflösung & Containment (§5.6 Pkt. 3, Formel 3): `../`-Ziel relativ zum Quell-Verzeichnis auflösen, `X/..`-Segmente kollabieren, aufgelöster Pfad MUSS unter `wiki/` bleiben — sonst `DANGLING` (Out-of-Bundle-`..`-Escape gesperrt, Loop-1-Fix). `../schema/*` als andere Schicht (Ziel außerhalb des Bundles) bleibt exkludiert — Abgrenzung über das **Zielverzeichnis** (unter `wiki/` = in-Bundle), nicht über das bloße `../`-Präfix; einstufiges `../schema/*` aus Root-Dateien ist damit weiterhin pin-frei (bestehende Root-`index.md`-Links unverändert). `.md`-Endung bleibt Pflicht (§5.6 Pin).
 5. **Area-`index.md` (Vertrag §2/§6, AD-9/FR-11):** Eine Area besitzt exakt eine `wiki/<area>/index.md`, **frontmatterlos** (Punkt 10), die ihre Area-Concepts in der gepinnten Form (§5.6) verlinkt (Identity = relativer OKF-Pfad ohne `.md`). Die Bundleroot-`index.md` verlinkt die Area-`index.md` (Navigation Root → Area, AD-9). **Area ohne `index.md` ist strukturell invalide** und wird vom Validator wörtlich gemeldet: `FAIL … Punkt 11: Index-Regel verletzt (Area ohne index.md=<area>)` (kein inventiertes Label; Verdikt-Grammatik §5 des Validators). Ein neues Area-Concept MUSS in `wiki/<area>/index.md` verlinkt sein (§5.3 Pkt. 3 ist entsprechend §5.7-nachgeführt); sonst Punkt 11.
 6. **Worked Example (Area-Concept):** `wiki/wissensarchitektur/source-material.md` — ein neues Area-Concept: `type: concept`, `sources` → `raw/architecture-spine/architecture-spine-2026-08-14.md` (s1) + `raw/prd/prd-wow20-2026-08-14.md` (s2), §5.5-Inline-Verweise je belegter Aussage, Body-Links auf Root-Concepts in der file-relativen `../`-Form (`[LLM-Wiki-Prinzip](../llm-wiki-prinzip.md)` u. ä.), inhaltsbegründet. Verlinkt in der Area-`index.md` `wiki/wissensarchitektur/index.md` (frontmatterlos, gepinnte Form); diese wiederum in der Bundleroot `wiki/index.md` (Area-Sektion). §5.6-Formel-1 (Bestands-Check) erfasst die Area-Links; Formel 2 (Form-Check) `0`; Formel 3 (Dangling-Check) keine Ausgabe (in-Bundle-`../`-Auflösung, §5.7 Pkt. 4).
@@ -225,12 +227,37 @@ Progressive Discovery ist die **schrittweise Navigation** eines Consumers von de
   Beide Läufe ohne Ausgabe = Discovery-SUCCESS. Die Meldungen sind **Instruktions-Selbsttest-Befunde** — kein Validator-Punkt, keine neue §7-Klasse (AD-3).
   - **`UNREACHABLE AREA: <area>`** — eine Area-`index.md` existiert, ist aber von der Bundleroot **nicht** verlinkt (kein Root→Area-Pfad): die Area bleibt für die Navigation unsichtbar (AD-9). Die Meldung ist ein textuell benannter **Instruktions-Selbsttest-Befund** (Run-FAIL gemäß §5.6 Pkt. 4-analoger NFR-4-Regel) — **kein** Validator-Punkt, **keine** neue §7-Klasse.
-   - **`NESTED AREA: <area>`** — jede Markdown-Datei in einem Zwei-Ebenen-Pfad (Tiefe ≥ 3, Lauf (B), Pkt. 3): ein `wiki/a/b/index.md`-Kandidat wie auch ein `wiki/a/b/concept.md` **ohne** `index.md` (die Area-ohne-Index-Lücke, die der reine `index.md`-Scan übersähe) sind Fälle der **konsolidierten Zwei-Ebenen-Kartografie** (Pkt. 3): die Verzeichnisstruktur ist keine zugelassene Anlageform; ein solcher Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (Trigger: Mutieren-Schritt, Pkt. 3 — keine Datei, kein Index-Link, Meldung, Run „teilweise erfolgreich"; nachträgliche bestehende Tiefe-≥-3-Dateien meldet Lauf (B)) — **analog**, aber **bewusst nicht** über den §3.2-Kollisions-Hold der Dateikollision bestehender Concepts (§3.2, Z. 40, bliebe ungeschärft für brandneue Pfade).
+   - **`NESTED AREA: <area>`** — jede Markdown-Datei in einem Zwei-Ebenen-Pfad (Tiefe ≥ 3, Lauf (B), Pkt. 3): ein `wiki/a/b/index.md`-Kandidat wie auch ein `wiki/a/b/concept.md` **ohne** `index.md` (die Area-ohne-Index-Lücke, die der reine `index.md`-Scan übersähe) sind Fälle der **konsolidierten Zwei-Ebenen-Kartografie** (Pkt. 3): die Verzeichnisstruktur ist keine zugelassene Anlageform; ein solcher Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (Trigger: Mutieren-Schritt, Pkt. 3 — keine Datei, kein Index-Link, Meldung, Run „teilweise erfolgreich"; nachträgliche bestehende Tiefe-≥-3-Dateien meldet Lauf (B)) — **analog**, aber **bewusst nicht** über das Update-Routing der Dateikollision bestehender Concepts (§3 Pkt. 2, bliebe ungeschärft für brandneue Pfade).
-   - Der Erreichbarkeits-Satz für **Root-Concepts** (jedes Root-Concept in `wiki/index.md` verlinkt) ist durch den Validator-Punkt-11-Check (§3 Punkt 11) abgedeckt und wird hier nicht dupliziert; der Selbsttest deckt die vom Validator offene Lücke (Root→Area-Navigation) ab. (Bekannte offene Lücke des Punkt-11-Checks: die file-relative Area-Lesart — ein wörtlich-mechanischer Check meldete `Concept nicht verlinkt=wissensarchitektur/source-material`; Behebung steht im Rev-9-Aktionsitem, s. `deferred-work.md`, Spec-2.4-Defer.) Die §5.6-Formeln (Z. 133–166) decken die **Link-Form** weiterhin ab (der Selbsttest prüft die Erreichbarkeit, nicht die Form — die Form bleibt beim §5.6-Form-Check).
+   - Der Erreichbarkeits-Satz für **Root-Concepts** (jedes Root-Concept in `wiki/index.md` verlinkt) ist durch den Validator-Punkt-11-Check (§3 Punkt 11) abgedeckt und wird hier nicht dupliziert; der Selbsttest deckt die vom Validator offene Lücke (Root→Area-Navigation) ab. (Die ehemals offene Punkt-11-Lücke der file-relativen Area-Lesart — ein wörtlich-mechanischer Check meldete früher `Concept nicht verlinkt=wissensarchitektur/source-material` — ist mit der autorisierten **Validator-Rev-9** geschlossen: die Area-Lesart ist in `schema/validator.md` formalisiert; siehe Pkt. 3 dieser Sektion und das Schließen des Aktionsitems in `deferred-work.md`.) Die §5.6-Formeln (Z. 133–166) decken die **Link-Form** weiterhin ab (der Selbsttest prüft die Erreichbarkeit, nicht die Form — die Form bleibt beim §5.6-Form-Check).
-3. **Konsolidierte Zwei-Ebenen-Kartografie (antwortet Defer F-07, schließt es):** Das Bundle-Navigationsmodell besteht ab Story 2.5 aus **einer** Area-Ebene: Root-Concepts (direkt aus der Bundleroot) + Areas (`wiki/<area>/`), jede mit genau einer frontmatterlosen `wiki/<area>/index.md`, die ihre Area-Concepts in gepinnter §5.6-Form verlinkt; die Bundleroot verlinkt die Area-`index.md`-Dateien (Navigation Root → Area, AD-9). **Verschachtelte Areas sind keine zugelassene Anlageform:** `wiki/a/b/` mit Concept darunter ist **kein** „Area mit Inhalt" — ein solcher Kandidat (Erstellungskandidat oder Discovery-Ziel) wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten: keine Datei, kein Index-Link, textuelle Meldung **`NESTED AREA: <area>`** (Pkt. 2); der Run bricht für dieses Gebilde mit „teilweise erfolgreich" ab (die übrigen erkannten Einheiten laufen weiter, NFR-4). **Tiefen-Definition (Loop-3-Klarstellung):** „Tiefe" ist die Segment-Anzahl unter der Bundleroot — `wiki/<a>/<b>/…` hat Tiefe ≥ 3 (zwei Verzeichnisstufen plus Datei); das ist exakt die `find -mindepth 3`-Schwelle von Lauf (B). Die Meldung benennt immer die **erste** Ebene `<a>` der nicht-zulässigen Struktur. **Trigger im Run-Flow (Loop-3-Fix):** der Hold feuert im **Mutieren-Schritt** (§0-Ablaufstruktur, Schritt (4)) — der Producer prüft vor Anlage eines Ziel-Pfads dessen Tiefe unter der Bundleroot; Tiefe ≥ 3 → Hold (kein §5.7-Routing kann Tiefe ≥ 3 strukturell erzeugen, der Hold sichert die Regel zusätzlich). Lauf (B) der Selbsttest-Formel bleibt der nachträgliche Baum-Check gegen bestehende Tiefe-≥-3-Dateien. Der Hold ist **§5.8-lokal** verankert (dieser Absatz) und trägt die **Discovery-Entscheidung** der Story — er ist **bewusst nicht** der §3.2-Kollisions-Hold der Dateikollision (§3.2, Z. 40): jener bleibt ausschließlich dem Fall vorbehalten, dass ein Ziel-Pfad bereits als Concept existiert („Concept existiert bereits — Aktualisierung ist Epic 3"); ein brandneuer Zwei-Ebenen-Pfad kollidiert mit keinem existierenden Pfad und wird daher über diesen §5.8-Hold gelenkt, nicht über §3.2. Die F-07-Frage „was ist Area mit Inhalt" ist damit instruktionsseitig deterministisch beantwortet: **Area mit Inhalt = `wiki/<area>/` mit `index.md` + Area-Concepts auf der Area-Ebene**; eine tiefere Verschachtelung ist kein eigener Bereich, sondern ein **§5.8-Zwei-Ebenen-Verstoß** (nicht erlaubt). Keine zweite Discovery-Ebene über die Zwei-Ebenen-Struktur hinaus (Boundaries, „Never").
+3. **Konsolidierte Zwei-Ebenen-Kartografie (antwortet Defer F-07, schließt es):** Das Bundle-Navigationsmodell besteht ab Story 2.5 aus **einer** Area-Ebene: Root-Concepts (direkt aus der Bundleroot) + Areas (`wiki/<area>/`), jede mit genau einer frontmatterlosen `wiki/<area>/index.md`, die ihre Area-Concepts in gepinnter §5.6-Form verlinkt; die Bundleroot verlinkt die Area-`index.md`-Dateien (Navigation Root → Area, AD-9). **Verschachtelte Areas sind keine zugelassene Anlageform:** `wiki/a/b/` mit Concept darunter ist **kein** „Area mit Inhalt" — ein solcher Kandidat (Erstellungskandidat oder Discovery-Ziel) wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten: keine Datei, kein Index-Link, textuelle Meldung **`NESTED AREA: <area>`** (Pkt. 2); der Run bricht für dieses Gebilde mit „teilweise erfolgreich" ab (die übrigen erkannten Einheiten laufen weiter, NFR-4). (Die in Pkt. 1 als offen notierte Punkt-11-Grenze ist mit dem Rev-9-Aktionsitem rückstandslos **geschlossen** — die Area-Lesart ist in `schema/validator.md` als „Revision 9" formalisiert; die Pkt.-1-Formulierung sieht dafür keine offene Lücke mehr vor.) **Tiefen-Definition (Loop-3-Klarstellung):** „Tiefe" ist die Segment-Anzahl unter der Bundleroot — `wiki/<a>/<b>/…` hat Tiefe ≥ 3 (zwei Verzeichnisstufen plus Datei); das ist exakt die `find -mindepth 3`-Schwelle von Lauf (B). Die Meldung benennt immer die **erste** Ebene `<a>` der nicht-zulässigen Struktur. **Trigger im Run-Flow (Loop-3-Fix):** der Hold feuert im **Mutieren-Schritt** (§0-Ablaufstruktur, Schritt (4)) — der Producer prüft vor Anlage eines Ziel-Pfads dessen Tiefe unter der Bundleroot; Tiefe ≥ 3 → Hold (kein §5.7-Routing kann Tiefe ≥ 3 strukturell erzeugen, der Hold sichert die Regel zusätzlich). Lauf (B) der Selbsttest-Formel bleibt der nachträgliche Baum-Check gegen bestehende Tiefe-≥-3-Dateien. Der Hold ist **§5.8-lokal** verankert (dieser Absatz) und trägt die **Discovery-Entscheidung** der Story — er ist **bewusst nicht** das Update-Routing der Dateikollision (§3 Pkt. 2): jenes bleibt ausschließlich dem Fall vorbehalten, dass ein Ziel-Pfad bereits als Concept existiert und als Update-Kandidat im bestehenden Pfad aktualisiert wird (§5.9); ein brandneuer Zwei-Ebenen-Pfad kollidiert mit keinem existierenden Pfad und wird daher über diesen §5.8-Hold gelenkt, nicht über das Update-Routing. Die F-07-Frage „was ist Area mit Inhalt" ist damit instruktionsseitig deterministisch beantwortet: **Area mit Inhalt = `wiki/<area>/` mit `index.md` + Area-Concepts auf der Area-Ebene**; eine tiefere Verschachtelung ist kein eigener Bereich, sondern ein **§5.8-Zwei-Ebenen-Verstoß** (nicht erlaubt). Keine zweite Discovery-Ebene über die Zwei-Ebenen-Struktur hinaus (Boundaries, „Never").
 4. **Suche = Consumer-grep (AD-13, FR-11, NFR-3):** Die Navigation ist die **primäre** Discovery (gewurzelte Erreichbarkeit, Pkt. 1–2). Die **Suche ist konsumenten-/extern-seitig** — die Discovery braucht **keine proprietäre Datenbank, keinen Such-Dienst, kein Embedding/Vector, kein Index-Datei-Format** (AD-8, AD-13): ein Consumer führt die textuell-deterministische Suche selbst aus, z. B. `grep -rn <term> wiki/` (rekursiv) bzw. `rg <term> wiki/` (ripgrep) über den Markdown-Baum (NFR-3 „Standard-Dateioperationen"); die rekursive Form ist verbindlich — ein nicht-rekursives `grep -n <term> wiki/` schlägt auf ein Verzeichnis fehl (Exit 2). Das Bundle bleibt ohne geladene Indizes — z. B. nach einem Git-Clone — vollständig verständlich (NFR-2, NFR-5). Der Story-2.5-Vorbehalt (§7 Z. 253 auf „Suche"-Rest gekürzt) ist damit aufgelöst: die Suche ist ein Consumer-Thema, kein Bundle-/Instruktions-Thema mehr.
 5. **Discovery-Demo (optional, kein MOVE):** Bestehende Root-Concepts werden **nicht** in Areas verschoben (Kuratierung/AD-7d ist Epic-3-Nähe). Als Discovery-Demo **kann** (optional) ein **neues** Root-Concept `wiki/<concept>.md` ergänzt und (a) in der Bundleroot (§5.3 Pkt. 3) sowie (b) — rein informierend — über einen zusätzlichen **Body-Link** in gepinnter file-relativer §5.6-Form (`[<text>](../<concept>.md)`) aus einem bestehenden Area-Concept heraus verlinkt werden (z. B. aus `wiki/wissensarchitektur/source-material.md`; der Inhalt bleibt Root-Concept; der Area-Body-Link ist zusätzliche Erreichbarkeit, keine Neuzuordnung; ein Link aus einer Concept-Body-Datei ist ein Body-Link, kein Index-Link — §5.6 Pkt. 2). Beide Verlinkungen halten die einheitliche Zwei-Ebenen-Kartografie (Pkt. 3). Die Durchführung ist **optional** (Matrix-Zeile `DISCOVERY_DEMO_ROOT_AREA_LINK`); sie **erhöht** die `(raw/`-Zählung der §5.6-Formel-4-Baseline (neuer Zuwachs-Run, Re-Baseline-Pflicht) und ist nur zusammen mit dem Nachweis dieses neuen Baselines zusätzlich durchzuführen — wird sie weggelassen, bleibt Formel 4 unverändert `38 ≡ 38` (kein Re-Baseline-Bedarf). Die hier beschriebene Regel ist die Demo-**Instruktion**; ob das konkrete Demo-Concept in diesem Run angelegt wird, entscheidet der Producer im Rahmen der optionalen Durchführung.
 ## 5.9 Inkrementelles Update bestehender Concepts (Story 3.1)
 Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik (D-3, Story 3.1) und der **einzige** Weg, wie ein Compilation Run neue Evidenz mit den tatsächlich betroffenen, bestehenden Concepts verrechnet — ohne unverändertes Wissen zu regenerieren (AD-5, A0-6, FR-6, FR-12). Sie ist eine weitere Spezifikations-Ebene der Mutationsphase §5 (nach §5.8, vor §6). Sie fügt **kein** Prädikat, keine neuen §7-Invaliditätsklassen und keinen Schema-/Validator-/`raw/`-Change hinzu (AD-3). Ein Update ist ein Compilation-Vorgang wie die Anlage: Er unterliegt denselben Phasen (§0: Interpretieren → Reconcile → Synthetisieren → Mutieren → Validieren), derselben Commit-Boundary = Mutations-Boundary (AD-17f, §0/§5.3) und derselben Validator-Erfolgsbedingung (§6).
 1. **Update-Stimulus (Input des Update-Pfads):** Der Stimulus ist die im Reconcile erhobene **Update-Kandidatenliste** (§3 Pkt. 2): die Menge der betroffenen Concept-Pfade (relative OKF-Pfade ohne `.md`), bestimmt über die textuell-deterministischen Mittel (Term-/Konzept-Überschneidung via `grep`/`ripgrep`, `index.md`-Traversal, Link-Following; AD-13). Ein Lauf, der **keinen** Kandidaten erhebt (keine Überschneidung), mutiert **kein** bestehendes Concept — Erhaltungs-Invariante (Pkt. 5). Der Stimulus verarbeitet ausschließlich **published/committed** Input (§1 Pkt. 1, AD-17a): neue Source Materialien erst, sobald sie unter `raw/` committet sind (R-1-Change-Detection, Pkt. 6), und das bestehende `wiki/` aus committetem Zustand — **nie** Zwischenstände während einer Mutation.
 2. **Mutationsmechanik:** Ein Update-Kandidat wird im **bestehenden Concept-Pfad** mutiert — **keine neue Datei, kein Duplikat** (FR-6). Drei Update-Formen, je nach Erkenntnis-Zuwachs:
   - **Erweitern:** Eine neue, belegte Aussage bzw. ein Absatz wird dem Body ergänzt; evtl. neue Aspekte, die von der neuen Evidenz getragen sind.
   - **Präzisieren:** Eine bestehende Aussage wird geschärft (Formulierung/Abgrenzung), der Beleg wird neu geführt oder nachgeführt (§5.5: Inline-`raw/`-Verweis mit existierender Stellen-Kennung).
   - **Korrigieren:** Eine fehlerhafte/überholte Aussage wird **ersetzt** — die ersetzte Aussage wird **nicht still gelöscht, sondern explizit durch die ersetzende Aussage abgelöst**, und die Ersetzung trägt einen **Ersetzungsbeleg** (die neue `raw/`-Evidenz als Inline-Verweis, §5.5). Keine stille Löschung bestehender Provenienz ohne Beleg (AD-16-Default: Erhaltung). Die AD-16-Klassifikation selbst (CORRECTING/CONTRADICTING etc.) ist Epic 4, Story 4.1, und wird hier **nicht** vorweggenommen — widersprechender Inhalt ohne Ersetzungsevidenz bleibt erhalten und wird gemäß Pkt. 4 in `log.md` explizit abgelegt.
   - **Frontmatter-`sources` nur um echte neue Belege ergänzen:** Für jede neu belegte Aussage, deren `raw/`-Datei nicht bereits in `sources` deklariert ist, wird ein **neuer `sources`-Eintrag ergänzt** (§5.5 Pkt. 1b — Relokation/Zielwechsel; Key-Subset Vertrag §3.3, Innen-Ebene). Bestehende `sources`-Einträge bleiben unverändert, sofern ihre Belege weiterhin Bestand des Bodys sind (keine Entfernung ohne Beleg).
   - **`generated.at`-Konvention (A0-20):** Ein maschinelles Update eines maschinell erzeugten Concepts bleibt maschinell → `generated` bleibt gesetzt, `at` wird auf den **aktuellen Run-Zeitstempel** aktualisiert (einmalige `at`-Festlegung pro Run, P1-Dryrun-Konvention). `verified` wird durch ein maschinelles Update **nicht** gesetzt; ein vorhandenes human-`verified` wird **nicht** entfernt (menschliche Kuratierung ist Bestandswissen, A0-21/FR-13-Nähe). Ein menschliches Update (manuelle Kuratierung, A0-21) ändert `generated`/`verified` nicht automatisch.
   - **Mehrfach-Treffer-Konsolidierung (ein Run, mehrere Einheiten auf denselben Concept-Pfad):** Ergeben mehrere neue Wissenseinheiten desselben Runs auf **demselben** bestehenden Concept-Pfad ein Update, werden ihre Mutationen in **einem einzigen Update dieses Pfads** konsolidiert (eine Body-Änderung, **ein** `log.md`-Eintrag „Story 3.1-Update", ein konsolidierter `sources`-Zuwachs, **ein** `generated.at`-Zeitstempel — der einmalige `at` des Runs). Die Reihenfolge der Einheiten wird dabei textual-deterministisch aus der Verarbeitung der Evidenz (REIHENFOLGE = Auftreten der Einheiten in der Zuwachs-Sicht; bei vollständig unabhängigen Einheiten die lexicografische Ordnung) abgeleitet; die AD-16-Default-Erhaltung bleibt für jede betroffene Stelle gewahrt.
   - **Commit-Boundary = Mutations-Boundary (AD-17f, §0):** Auch im Update-Pfad werden **Zwischenstände nie als fertige Mutation veröffentlicht** — die Mutationen der Update-Kandidaten werden als Ganzes committet, und zwar erst, nachdem der Diff-Selbsttest (Pkt. 5) ohne Ghost-Diff abgeschlossen ist. Ein Ghost-Diff ist dann als **Abbruch-Vorlauf „korrigierter Teil-Run"** im `log.md`-Eintrag des betroffenen Runs gekoppelt (siehe Disagreement-/Run-Notiz Pkt. 4), damit die Ursache textuell nachvollziehbar bleibt.
 3. **Index-/Link-Form unverändert (§5.6-Pin):** Ein reines Body-Update ändert die Concept-Identität nicht → der bestehende Index-Link (Bundleroot oder Area-`index.md`) bleibt unverändert gültig; **kein neuer Link** bei reinem Body-Update (kein Index-`index.md`-Zusatz). Die **`log.md`-Eintragspflicht** (Pkt. 4) bleibt davon **unberührt**: *jedes* Update — auch ein reines Body-Update — MUSS seinen `log.md`-Eintrag „Story 3.1-Update" führen; nur der **Index-**Link bleibt unverändert. Wird durch das Update eine Concept-Kategorie (Root vs. Area) oder die Identität berührt, ist das **Ask-First** (AD-7d-Renames/Redirects; nicht Teil von Story 3.1). Neue zulässige Concept-Links (Beziehungsschicht, §5.6) werden nur gesetzt, wenn die neue Erkenntnis eine echte, inhaltsbegründete Beziehung rechtfertigt.
 4. **`log.md`-Eintragspflicht (Vertrag §5):** Jedes Update wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (Header = ISO-Datum `YYYY-MM-DD`, neueste zuerst), verknüpft mit dem mutierten Concept-Pfad und den genutzten `raw/`-Quellen. Für Updates wird der Eintrag als „**Story 3.1-Update**" markiert (disambiguierbar von Anlage-Einträgen). Konflikt-/Erhaltungsfälle (Pkt. 2 „Korrigieren" ohne Ersetzungsevidenz) werden explizit als Disagreement-Eintrag mit dem mutierten Concept-Pfad geführt (AD-16b, Vertrag §5) — der Epic-4-Interface-Fall bleibt dokumentiert, ohne Korrektur-Klassifikation hier.
 5. **Erhaltungs-Invariante (Kern) + deterministischer Diff-Selbsttest (AD-17h, FT-6/FR-12):** Ein Compilation Run darf nur die Concepts **neu anlegen oder verändern**, die durch den erkannten Erkenntnis-Zuwachs tatsächlich betroffen sind. **Nicht betroffene Concept-Pfade bleiben byte-identisch unverändert** — es gibt **nie** „Regenerate Everything" (AD-5, A0-6). Die Inkrementalität ist als **re-executierbarer Diff-Selbsttest** mechanisch kontrollierbar: Nach jedem Run prüft der Producer ab der Workspace-Root
   ```sh
   git diff --name-only -- wiki/
   ```
   dass die geänderten Dateien eine Teilmenge von **(Kandidatenliste ∪ `log.md` ∪ nachgeführte `index.md`)** — mit der Kandidatenliste aus §3 Pkt. 2 als expliziter Menge (relative OKF-Pfade ohne `.md`, plus `log.md` und jede nachgeführte `index.md` als zusätzliche zulässige Einträge). Jede Abweichung (**Ghost-Diff** auf einem nicht betroffenen Pfad) ist ein Instruktions-Verstoß (FT-6): Der Producer behebt sie textuell benannt (NFR-4) und **rollt den Ghost-Diff zurück, bevor der Run als gültig vermerkt wird** — der beobachtbare Endzustand des Bundles bleibt damit konsistent (AD-6-Backstop). Für Story 3.1 selbst (Instruktions-Story ohne Inhalts-Mutation) ist der Nachweis: `git diff --name-only -- wiki/` liefert ausschließlich `wiki/log.md` — keine Concept-Datei, keine `index.md` (die aggressive `git diff --stat -- wiki/`-Default-Effektiv-ausgabe zeigt denselben Pfad, `wiki/log.md | 1 +`). *(Anmerkung: `schema/compiler.md` und `deferred-work.md` liegen **außerhalb** `wiki/` und sind daher kein Teil dieser Diff-Probe — sie gehören zum Instruktions-, nicht zum Bundle-Baum; der Ghost-Diff-Begriff dieser Sektion gilt nur für `wiki/`.)*
 6. **Run-Vorphase-Bausteine (Defer R-1 + P2, in den Update-Pfad eingearbeitet):** Beide sind **keine** neuen Prozesse — wiederverwendbare, reproduzierbare textuelle Check-Blöcke innerhalb der Instruktions-Ausführung (D-3):
   - **Change-Detection (Defer R-1, Input-Zuwachserkennung):** Vor der Interpretation bestimmt der Producer, **welche `raw/`-Dateien Zuwachs** sind (neu/modifiziert). Deterministische Mittel: `git diff --name-only <Baseline-Commit> -- raw/` auf das `raw/`-Verzeichnis und/oder der **SHA-256-Record aus `raw/**/source.md`** (Provenienz-Sidecar, §1 Pkt. 4). Als `<Baseline-Commit>` dient der **letzte committete Zustand des Workspace**, den der Producer als Ausgangslage deklariert (deterministisch: der HEAD der vorherigen Mutations-Boundary, AD-17f — die Zuwachserkennung ist damit gegen denselben Baseline-Commit definiert, gegen den auch die Diff-Probe in Pkt. 5 läuft, siehe dort). Nur die so als Zuwachs erkannten Dateien werden als neue Evidenz interpretiert; unveränderte `raw/`-Dateien bleiben außen vor. Ist der SHA-256-Record unlesbar/fehlend, wird die Datei dennoch als Zuwachs **nicht doppelt** verarbeitet (textueller Hinweis) und gegen den `git diff`-Befund abgeglichen (kein Doppel-Verdikt).
   - **Pre-Run-Reconcile-Check-Block (Defer P2):** Vor jeder Mutation durchläuft der Producer den gebündelten Vorprüf-Block und hält ihn textuell fest: (1) Ziel-Pfade (Ausgangs-Kandidatenliste, §3 Pkt. 2); (2) Quellen-Existenz (EC-1 via Validator-Punkt: jede referenzierte `raw/`-Datei existiert als Datei); (3) Betroffenheits-Kandidatenliste (§3 Pkt. 2, textuell-deterministisch); (4) `wiki/index.md`-V-1-Vorbedingung (fehlende Bundleroot → Run-FAIL, §3 Pkt. 3/§3-Voraussetzungsprüfung, Vertrag §2). Dieser Block ist der in `deferred-work.md` als P2 notierte Pre-Plan-Schritt und wird durch Story 3.1 als Teil des inkrementellen Runs ausgeführt. Der Block wird **einmal pro Run führend** an der Spitze erhoben; die Ausgangs-Kandidatenliste ist dabei **die** Kandidatenliste, gegen die der Diff-Selbsttest (Pkt. 5) prüft (keine zweite, davon abweichende Erhebung nach der Mutation).
 7. **Worked Example (an die reale Ist-Lage gebunden, grammatisch):** Ein Run mit neuer committeter Evidenz `raw/epics/epics-2026-08-14.md#FR-12` (Zuwachs über die bisher verarbeitete Stelle hinaus; die Kennung FR-12 existiert real in der Datei) trifft über `rg -l 'FR-12' wiki/` das bestehende Concept `wiki/wissensarchitektur/source-material.md` (Term-/Konzept-Überschneidung, Bereich `wissensarchitektur`). Der Run aktualisiert diesen Pfad (Body-Erweiterung mit neuem §5.5-Inline-Beleg `(raw/epics/epics-2026-08-14.md#FR-12)`, `sources`-Ergänzung um diesen `resource`, `generated.at` = aktueller Run-Zeitstempel, `log.md`-Eintrag „Story 3.1-Update"). `git diff --name-only -- wiki/` zeigt ausschließlich `wiki/log.md` und `wissensarchitektur/source-material.md` (betroffen) — kein Ghost-Diff, keine unberührte `index.md` im Diff (der Index-Link bleibt unverändert).
 ## 6. Validieren (mechanische Bestätigung)
 1. Nach Abschluss aller Mutationen wird das gesamte Bundle gemäß `schema/validator.md` geprüft (§3 14 Punkte je Datei + §6-Fachprüfungen; Verdikt-Grammatik §5).
@@ -278,13 +305,15 @@ Interpretations-Hinweis: Die „✗"-Zeilen zeigen die deterministische Fehlerur
 ## 7. Selbstbegrenzung (Scope der Instruktion)
-Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in Areas gemäß §5.7** begrenzt. Folgendes verbleibt in anderen Stories und wird hier **nicht** vorweggenommen:
+Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in Areas gemäß §5.7 sowie das inkrementelle Update bestehender Concepts gemäß §3 + §5.9** begrenzt. Folgendes verbleibt in anderen Stories und wird hier **nicht** vorweggenommen:
 - **Claim-granulare Provenienz** je belegter Aussage (Inline-`raw/`-Verweise, Kontext-Marker) — in **§5.5** dieser Instruktion verankert (Story 2.2; AD-4a, A0-3). Keine neue §7-Klasse, kein Standalone, keine Vertragsänderung.
 - **Deterministische Area-Zuordnung & Concept-Hierarchie** (Anlage von `wiki/<area>/index.md` + `wiki/<area>/<concept>.md`) — in **§5.7** dieser Instruktion verankert (Story 2.4; AD-7c, A0-10, A0-8, AD-13). Keine neue §7-Klasse, kein Validator-Change.
 - **Progressive Discovery über `index.md`** (Navigation, Area-Indizes) — in **§5.8** dieser Instruktion verankert (Story 2.5; AD-9, FR-11, AD-13, NFR-3). **Suche** bleibt konsumenten-/extern-seitig (Consumer-grep über `wiki/`, §5.8 Pkt. 4 — kein Bundle-/Instruktions-Thema mehr). Keine neue §7-Klasse, kein Schema-/Validator-Change.
 - **Eine genau-eine-Linkform** (file-relativ mit `.md`-Endung, in Areas `../`-fähig) — in **§5.6** dieser Instruktion gepinnt (Story 2.3; AD-7b, A0-9, FR-10; Auflösungsmodell §5.7 Pkt. 4) — der Punkt-11-Check des Validators akzeptiert bis auf Weiteres beide Schreibweisen (strukturell unverändert, Story-2.2-Präzedenz).
- **Aktualisierung bestehender Concepts** (Erweitern/Präzisieren/Korrigieren) und **Synthese über mehrere Concepts** → Epic 3 (AD-5, FR-6/FR-7).
+- **Synthese über mehrere Concepts** (mehrere Sources → eine gemeinsame Wissensrepräsentation mit gemischter, claim-granularer Provenienz) → **Epic 3, Story 3.4** (AD-4, FR-7). Die Verankerung des inkrementellen Datenflusses (Erweitern/Präzisieren/Korrigieren einzelner bestehender Concepts) bleibt **§3 + §5.9** überlassen und ist dort bereits verankert (Story 3.1) — sie ist damit aus diesem Vorbehalt entlassen.
 - **Leasing / Dirty-Tree-Schutz** für konkurrierende Producer → **Story 3.5/3.6** (AD-17a..f, A0-12..A0-16); die bestehende Commit-Boundary = Mutations-Boundary-Regel (§0/§5.3, AD-17f) bleibt in v1 bestehender Schutz.
 - **Feinkörnige Relevanz-Verfeinerung** (eigene Ausformulierung des Relevanz-Findungsmechanismus) → **Story 3.2**; Story 3.1 bindet die Kandidatenerhebung an die in §3 Pkt. 2 genannten textuell-deterministischen Mittel (grep/ripgrep, `index.md`-Traversal, Link-Following; AD-13).
 - **Standalone-Compiler / eigene LLM-Runtime / MCP** → verboten in v1 (D-3, D-4, AD-11).
 - **OKF-Dialekt / Schema-Erweiterung** → niemals (AD-1a; Vertrag §7 „abschließende Liste").
@@ -293,10 +322,10 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
 **Normreferenzen (read-only):**
 - `schema/wiki-compiler.md` — autorisierter Vertrag (Story 1.3): §2 Bundleroot, §3.1–§3.7 Feldsubset & Formate, §5 `log.md`-Typ, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
- `schema/validator.md` — Prüfgrundlage (Story 1.4, Revision 8): §3 14 Punkte, §4 Normalform (Reihenfolge §4.1, ISO-8601 §4.3), §5 Verdikt, §6 Fachprüfungen (EC-1 Existenz, EC-3 Kalender, EC-11 non-md).
+- `schema/validator.md` — Prüfgrundlage (Story 1.4, Revision 9): §3 14 Punkte, §4 Normalform (Reihenfolge §4.1, ISO-8601 §4.3), §5 Verdikt, §6 Fachprüfungen (EC-1 Existenz, EC-3 Kalender, EC-11 non-md; Punkt-11-Area-Lesart formalisiert).
 - Architektur-Spine (raw/`architecture-spine`): AD-2/AD-3 (raw immutable), AD-4a (claim-granulare Provenienz, §5.5), AD-5 (inkrementelle Kompilation), AD-6 (Reason/Mutate-Trennung), AD-7a (Identität = OKF-Pfad ohne `.md`, §5.7), AD-7b (genau eine Linkform gepinnt, §5.6), AD-7c (deterministische Bereichszuordnung, §5.7), AD-7d (Renaming/Redirect-Pflicht — nicht in den ACs, Epic 3), AD-8 (Standard-Markdown-Links = Navigations-/Beziehungsschicht, §5.6), AD-9 (Progressive Discovery, §5.7/§5.8), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-13 (Retrieval gehört zu Consumers / Suche = Consumer-grep / keine Embedding-Bereichszuordnung, §5.7/§5.8), AD-14 (Git liefert Historie, nicht Domain-State), AD-15 (Trust-Metadaten v1), AD-16 (Konflikte werden explizit bewahrt), AD-17a (nur veröffentlichte/committete Inhalte als Input), AD-17f (Commit-Boundary = Mutations-Boundary), AD-17h (Determinismus), D-3 (kein Standalone).
 - PRD (raw/prd): FR-2 (Sources vs. Curated), FR-5 (Concept-Erzeugung), FR-9 (OKF-Konformität), FR-10 (Concepts miteinander verlinken, §5.6), FR-11 (Progressive Discovery siehe PRD-§4.3-Zeile unten — Discovery-Pfad/gewurzelte Erreichbarkeit, §5.8), FR-16 (Consumer-Unabhängigkeit), NFR-3 (Agent Readability — Standard-Dateioperationen/grep über `wiki/`, §5.8 Pkt. 4), A-4 (nur lokale Sources).
- Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5; A0-3 (Kontext-Marker-Wortlaut, §5.5), A0-8 (Concept-Identität/Normalisierung, §5.7), A0-9 (eine erlaubte Linkform, §5.6), A0-10 (deterministische Bereichszuordnung, §5.7), A0-13 (Lease-Root-Scope); FR-6/FR-12/FR-14, A0-6/A0-7/A0-11/A0-18 (Belege der nachkonformierten Concept-Bodies).
+- Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5; A0-3 (Kontext-Marker-Wortlaut, §5.5), A0-8 (Concept-Identität/Normalisierung, §5.7), A0-9 (eine erlaubte Linkform, §5.6), A0-10 (deterministische Bereichszuordnung, §5.7), A0-13 (Lease-Root-Scope); FR-6/FR-12/FR-14, A0-6/A0-7/A0-11/A0-18 (Belege der nachkonformierten Concept-Bodies); **A0-6 (inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update, §0/§3/§5.9), FR-6 (Aktualisierung statt neuer Dateien, §3/§5.9), FR-12 (unverändertes Wissen bleibt erhalten, §5.9)**.
 - PRD §4.3 (FR-11 — progressive Discovery, §5.7 Pkt. 5/§5.8) und §8.2/§8.3 (Canonical State; Separation of Concerns).
 **Revisionslog:**
@@ -315,3 +344,5 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
 - **Revision 2.1 (2026-08-18, Story 2.4):** Neue Sektion **§5.7 „Deterministische Bereichszuordnung & Concept-Hierarchie"** eingefügt (nach §5.6, vor §6): (1) Routing-Regel textual-deterministisch (`index.md`-Erst-`Link` → Bereich, sonst Root; neue Areas nur konsolidiert; nie Embedding/Vector — AD-7c/A0-10/AD-13), (2) kanonische ID-Normalisierung mit Beispieltabelle `wiki/<area>/index.md` → `<area>` (AD-7a/A0-8), (3) Kollisions-Hold → Verweis auf den fixierten §3.2 (kein neues Prädikat, kein MOVE, A0-10), (4) **file-relatives Link-Auflösungsmodell** (`../`-fähig, eine Form, §5.6-Pin unverändert) inkl. Out-of-Bundle-`..`-Containment, (5) Area-`index.md`-Regel (frontmatterlos, Punkt 10; Area ohne `index.md` → wörtliche Punkt-11-Meldung `FAIL … Punkt 11: Index-Regel verletzt (Area ohne index.md=…)` — **kein** inventiertes `AREA_WITHOUT_INDEX`-Label; §5.7 Pkt. 5), (6) Worked Example Area-Concept. Nachgeführt: §5.1 Pkt. 1 (Ziel-Pfad → §5.7-Verweis, „Area-Zuordnung ist Story 2.4"-Backlog-Klausel aufgelöst), §5.3 Pkt. 3 (Index-Regel area-bewusst: Concept → `index.md` seines Bereichs), §5.6 Pkt. 1/2/3/4/5 (file-relatives Auflösungsmodell; `../`-Exklusion aufgelöst → in-Bundle-Auflösung; **Formel 2** Exklusions-Erläuterung um `../`-Zähl-Freistellung ergänzt; **Formel 3** um Quell-Datei-Spur (`grep -roE` + `datei|ziel`-sed) und **in-Bundle-`..`-Auflösung mit Containment** inkl. `../schema/*`-Exklusion erweitert — Out-of-Bundle-`..`-Escape (`../../README.md`, `../../schema/compiler.md`) wird als `DANGLING` gesperrt, Loop-1-Review-A1-Fix; **Formel 4** neu auf den `baseline_commit` dieser Spezifikation `66451b6…` basiert — nicht den Story-2.3-`7e1f449…`, Loop-1-Review-A2-Fix — mit Basename-Filter `grep -v "log.md$"`), §6.6 (Referenzzeile §5.1/§5.7), §6 Pkt. 2 (Erfolgsbedingung Punkt 11 area-bewusst), §7-Selbstbegrenzung-Bullet → „in §5.7 verankert", §8-Normreferenzen um AD-7c/AD-7d/A0-8/A0-10/A0-13/PRD-§8.2/§8.3 ergänzt. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/`; keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.
 - **Revision 2.2 (2026-08-18, Story 2.4, bmad-code-review Loop 2, 4 Layer; Nutzer-Entscheidungen 1/1/1):** (1) **Formel 3 (Dangling-Check) quellenbasierte `../schema/*`-Exklusion (Decision 2):** `case "$t" in …|../schema/*)` um Quell-Bedingung geschärft — die Exklusion greift nur, wenn die Quell-Datei auf Bundleroot-Ebene liegt (`dirname <quelle>` = `wiki`); aus Area-Quellen läuft einstufiges `../schema/…` durch die bestehende Auflösung + `wiki/*`-Containment + `-f`-Existenztest (nicht existent → `DANGLING: …`, kein stiller Vorbeilass, NFR-4); Negativ-Beispiel 2 um die In-Bundle-Variante `[x](../schema/compiler.md)` aus `wiki/wissensarchitektur/source-material.md` → `DANGLING: ../schema/compiler.md` ergänzt (Sandbox-Nachweis); (2) **Formel 4 (Kontakt-mit-`raw/`) Re-Baseline auf den Run-Kopf (Decision 1):** Extraktions-Commit von `66451b6…` auf `862cf410c624072833cd959da9a2fb26235716f6` (Kopf dieses Zuwachs-Runs, Extraktion = 38) umgestellt — der gepinnte Selbsttest lief auf dem Zuwachs-Baum deterministisch `38 ≠ 30` = Run-FAIL (bekannt-böser Zustand aus Loop-1-A2, nur halb geheilt); Erwartungstext jetzt „Ist ≡ Extraktion aus dem Baseline-Commit des letzten Zuwachs-Runs" (aktuell: Run-Kopf `862cf41`, **38 ≡ 38**); `66451b6`/`30` bleibt als Referenz des Vor-Zuwachs-Zustands dokumentiert; Wieder-Baseline-Klausel für künftige Zuwachs-Runs; (3) **§5.7 Pkt. 1(a) textuelles Treffer-Prädikat + deterministisches Tie-Break (Decision 3):** „inhaltlich deckungsgleichen Eintrag" (Urteil, AD-13-Verstoß) ersetzt — Treffer = Identität des `index.md`-Link-Ziels ≡ kanonischer Name des neuen Themas (Pkt. 2); Mehrfachtreffer → Bundleroot-Links vor Area-Links (Bundleroot-Treffer = Root-Concept-Verweis → Default Root-Ebene gemäß (b)), dann lexicografisch kleinste Area-Pfad-Zeichenfolge; (4) file-relative Pin-Wortwahl nachgeführt — §5.3 Pkt. 3 (Oxymoron „file-relativ bundle-relativ" aufgelöst: „file-relativ, mit `.md`-Endung; §5.7 Pkt. 4"), §6.6-Zelle (bzw. das doppelte Leerzeichen) und §7-Bullet; (5) §7-Scope-Einleitung „auf die Erzeugung neuer Concepts auf Root-Ebene begrenzt" → „Root-Ebene und in Areas gemäß §5.7"; (6) Typos („akte-Baseline" → „aktuelle Baseline", „Kopf dieser Spezifikation" → „Baseline-Commit des letzten Zuwachs-Runs"). Positiv-Kontrolle nach Patch (re-executiert): Formel 2 (Form-Check) `0` (Exit `0`), Formel 3 (Dangling-Check) leere Ausgabe, Formel 4 **38 ≡ 38**. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/` (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.
 - **Revision 2.3 (2026-08-18, Story 2.5):** Neue Sektion **§5.8 „Progressive Discovery über `index.md` (Story 2.5)"** eingefügt (nach §5.7, vor §6): (1) **Discovery-Pfad** (Bundleroot `wiki/index.md` → Area-`index.md` frontmatterlos → Area-Concepts in gepinnter §5.6-Form; Root-Concepts direkt aus der Bundleroot — AD-9/FR-11, gewurzelte Erreichbarkeit Root → Area → Concept), (2) **gewurzelte Erreichbarkeit als deterministisches Discovery-Kriterium + re-executierbarer Selbsttest** (`UNREACHABLE AREA: <area>` für unverlinkte Area; `NESTED AREA: <area>` für Zwei-Ebenen-Kandidaten inkl. der Area-ohne-`index.md`-Lücke `wiki/a/b/concept.md`; gekoppelte Meldungen an den Run-Nachweis gemäß §5.6-Pkt.-4-analoger NFR-4-Regel; Instruktions-Selbsttest, **keine** neue §7-Klasse — schließt die Validator-Navigation-Lücke, ohne Validator-Change, AD-3), (3) **konsolidierte Zwei-Ebenen-Kartografie** (respondiert Defer **F-07**, schließt es): Root + eine Area-Ebene; `wiki/a/b/` ist keine zugelassene Anlageform — der Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (keine Datei, kein Index-Link, Meldung `NESTED AREA: <area>`, Run „teilweise erfolgreich"); §3.2 bleibt der Dateikollision bestehender Concepts vorbehalten (Loopback-1-Renegotiation, Option A); (4) **Suche = Consumer-grep** (`grep -n <term> wiki/` / ripgrep, AD-13 — keine Such-Datenbank, kein Embedding, kein Index-Datei-Format), (5) **Discovery-Demo (optional, kein MOVE)** — Hinweis auf Formel-4-Re-Baseline-Pflicht bei Durchführung. Nachgeführt: **§7** (Story-2.5-Vorbehalt auf „Suche"-Rest gekürzt — Navigation/Area-Indizes jetzt in §5.8 verankert, Suche = Consumer-Thema; die Vorbehalt-Zeile lag in der Baseline `main` bei Z. 253, nach dem §5.8-Einschub bei Z. 285), **§8-Normreferenzen** (AD-9/AD-13 → §5.8, FR-11 → §5.8/§5.7 Pkt. 5, NFR-3 neu, PRD-§4.3-Zeile nachgeführt) + **Revisionslog 2.3**. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/` (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.
 - **Revision 2.4 (2026-08-18, Story 3.1):** Neue Sektion **§5.9 „Inkrementelles Update bestehender Concepts (Story 3.1)"** eingefügt (nach §5.8, vor §6) — Update-Stimulus (Reconcile-Kandidatenliste), Mutationsmechanik (Erweitern/Präzisieren/Korrigieren; `sources` nur um echte neue Belege; `generated.at` = aktueller Run-Zeitstempel; `verified` unangetastet), Index-/Link-Form unverändert (§5.6-Pin), `log.md`-Eintragspflicht („Story 3.1-Update"-Markierung; Disagreement-Fälle bleiben dokumentiert, keine Korrektur-Klassifikation hier — Epic-4-Interface), **Erhaltungs-Invariante + deterministischer Diff-Selbsttest** (`git diff --stat -- wiki/` ⊆ betroffene Concepts ∪ `log.md` ∪ Index; Ghost-Diff = textuell benannter Instruktions-Verstoß, FT-6/FR-12), Run-Vorphase-Bausteine (Defer **R-1** Change-Detection via `git diff` auf `raw/` + SHA-256-Record aus `source.md`; Defer **P2** Pre-Run-Reconcile-Check-Block — Zielpfade, EC-1-Existenz, Kandidatenliste, V-1), Worked Example. **§3 Reconcile:** Pkt. 2 Kollision-Hold (bisheriger Epic-3-Abbruch bei bereits existierendem Concept) **ersetzt** durch **Update-Routing** (bestehende Wissenseinheit → Update-Kandidat im bestehenden Pfad; kein Duplikat, kein stummer Überschreib; AD-16-Default-Erhaltung) + **textuell-deterministische Kandidatenliste** (Konzept-/Term-Überschneidung via `grep`/`ripgrep`, `index.md`-Traversal, Link-Following — AD-13; feinkörniger Mechanismus Story 3.2). **§0-Aufruf:** sechs Phasen für Neu-Anlage- und Update-Variante präzisiert; Reconcile/Mutieren betreffen auch bestehende Concepts. **§5.7 Pkt. 3 / §5.8 Pkt. 2/3:** Top-Level-Referenz von „§3.2-Kollisions-Hold" auf das Update-Routing (§3 Pkt. 2, §5.9) nachgeführt (die bisherige Epic-3-Abbruch-Formulierung ist vollständig entfernt). **§7:** Update-Thema aus dem Epic-3-Vorbehalt **entlassen** (verbleibende 3.x-Themen benannt: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6, Relevanz-Verfeinerung → Story 3.2); Scope-Einleitung um die Update-Variante geöffnet. **§8:** Normreferenzen um A0-6/FR-6/FR-12 ergänzt. **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
 - **Revision 2.4.1 (2026-08-18, Story 3.1, Step-04-Review-Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt):** §5.9-Konsolidierung aus den drei Review-Layern — (1) Prüfgrundlage auf `validator.md` **Revision 9** angehoben (§0-Header, §8-Link), §8-Verlusttext um die Punkt-11-Area-Lesart (Rev-9) ergänzt; (2) §5.9 Pkt. 5 Diff-Selbsttest operationalisiert (Probe `git diff --name-only -- wiki/` statt `--stat`; Ergebnismenge ⊆ **Kandidatenliste** (explizit §3 Pkt. 2) ∪ `log.md` ∪ nachgeführte `index.md`; Rücksetzhilfe „ob der Ghost auf einem Kandidatenpfad liegt"); Klarstellung, dass `schema/compiler.md`/`deferred-work.md` **außerhalb** `wiki/` liegen und daher nicht Teil der Diff-Probe sind — der Story-3.1-Nachweis ist `wiki/log.md` (Differenz zu den 4 volle `git status --porcelain`-Einträgen); Diff-Erwartung für das reine Body-Update in Pkt. 7 auf `git diff --name-only` umgestellt, Ergebnismenge `wiki/log.md` + `wissensarchitektur/source-material.md` (keine `index.md`); (3) §5.9 Pkt. 3-Widerspruch aufgelöst (Index-Regel unverändert, `log.md`-Eintragspflicht bleibt ausgeschlossen — Präzisierung „kein `log.md`-Zusatz" war falsch, korrekt „kein Index-Zusatz"); (4) §5.9 Pkt. 2 um **Mehrfach-Treffer-Konsolidierung** ergänzt (mehrere Einheiten → 1 Update/`log.md`-Eintrag/`at`; Verarbeitungsreihenfolge = Auftreten in der Zuwachs-Sicht); (5) §5.9 Pkt. 1/6-Anker §1.1/§1.4 → **§1 Pkt. 1/Pkt. 4** (die tatsächlichen Label; §5.8-Pkt-2-Formel-Zeile bleibt historisch); (6) Ghost-Diff **Konsequenz** + Commit-Boundary-Umsetzung definiert (Rück-Rollen vor Run-Gültigkeit, `log.md`-Kopplung als Abbruch-Vorlauf „korrigierter Teil-Run"); (7) Defer-**R-1**-Baseline festgelegt (HEAD der vorherigen Mutations-Boundary); (8) §5.9 Pkt. 7-Worked Example auf den **realen Ist-Baum** gehoben (`raw/epics/epics-2026-08-14.md#FR-12`, `rg -l 'FR-12'`; das fiktive `epics-2026-08-18.md`/`payload` entfernt); (9) §5.8-Pkt-3-Revision-Feinschliff — die Rev-9-Lücke ist geschlossen; die Markierung ist Pkt. 3. **Abschlussklausel der Patch-Runde:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.