feat: Concepts aus Source Material erzeugen (Story 2.1) inkl. Review

Co-Authored-By: Claude <noreply@anthropic.com>
2026-08-16 11:55:09 +02:00
parent a67ba65910
commit 6105a7bbc0
11 changed files with 551 additions and 6 deletions
@@ -98,3 +98,15 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-14)
  summary: Negativ-Fixture für `resource`-Pfade, die außerhalb `raw/` landen aber existieren (z. B. `README.md`) — §6.2 Schritt 5 deckt den Fall ab, aber das Durchstechen ist nur durch Beispiele belegt. Fixture bei nächster Validator-Revision ergänzen (analog §7.3).
  evidence: Retrospective F-14.
 ## Folge-Aufgaben aus Story-2.1-Review (Defer-Kontexte; 2026-08-16)
 > Diese Einträge sichern die im Step-04-Review von Story 2.1 als Defer klassifizierten Befunde als konkrete Folge-Aufgaben. Sie sind **nicht** durch die Nachschärfungen (compiler.md Revision 1.2, validator.md Revision 7, index.md, log.md, sprint-status) behoben.
 - source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Story-2.1-Review)
  summary: Content-Truth-Verifikation einführen — kein bestehender Check verifiziert, dass der Body eines Concepts seinen deklarierten `raw/`-Quellen (Inhalt) entspricht. Die drei Concepts sind aktuell inhaltlich korrekt (Spot-Checks im Review bestätigt), aber Validator (§3 rein strukturell), spec-Verification (grep-Smoke) und compiler.md-Selbsttests (Kriterien 1–3) decken nur Form/Existenz, nicht den Inhalt. Verifikation, dass erfundenes/gegenläufiges Body-Content nicht als kuratierte Wahrheit durchgeht, ist die Kern-Fähigkeit (FR-2/FR-5).
  evidence: Verification-Gap-Review (Story 2.1): Demonstriert — Body-Fälschung bei byte-identischem Frontmatter ändert kein Verdikt und keinen grep-Check. Für Story 2.2 (Claim-granulare Provenienz, AD-4a/A0-3) bzw. eine spätere Inhaltstreue-Prüfung.
 - source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Story-2.1-Review)
  summary: Determinismus-Selbsttest-Dokumentation in `schema/compiler.md` schärfen — §6.6-Interpretations-Hinweis behauptet, die ✓-Form sei „genau diese Form … im Demonstrationslauf erfüllt"; da `generated.at` pro Run variiert (Ausführungszeitpunkt, AD-15), ist der Selbsttest (Kriterium 2 „at-Normalform") als Form-Verifikation über die Normalform statt über einen festen `at`-Sekundenwert zu formulieren, damit ein „Regenerate"-Vergleich auf einem OTHER-Diff-Basis nicht an der Run-Zeit scheitert (Punkt-14-sicher). Für Story 2.3 (Determinismus/A0-7-Verifikation) bzw. nächste Validator-Revision.
  evidence: Edge-Case-Review (Story 2.1): „Determinism self-test compares generated.at which varies per run" — eines von mehreren als Defer klassifizierten Findings (die übrigen ebenfalls in diesem Block).
@@ -0,0 +1,42 @@
 # Epic 2 Context: OKF-Concepts erzeugen & verlinken
 <!-- Compiled from planning artifacts. Edit freely. Regenerate with compile-epic-context if planning docs change. -->
 ## Goal
 Aus dem lokal bereitgestellten Source Material (Epic 1) entstehen eigenständige, OKF-0.2-konforme Concepts: neue kuratierte Wissenseinheiten, die nicht an die Struktur der Quelle gebunden sind. Jede belegte Aussage trägt claim-granulare Provenienz auf `raw/`-Evidenz; maschinell erzeugte Concepts tragen die v1-Trust-Metadaten (`generated` ohne `verified`). Concepts werden über genau eine erlaubte Markdown-Linkform (AD-7b) miteinander verlinkt, per deterministischer Bereichszuordnung (AD-7c) in eine Bundle-Hierarchie eingeordnet und über `index.md` progressiv entdeckbar — ohne proprietäre Datenbank.
 ## Stories
 - Story 2.1: Concepts aus Source Material erzeugen (OKF-konform)
 - Story 2.2: Claim-granulare Provenienz dokumentieren
 - Story 2.3: Concepts verlinken (eine erlaubte Linkform)
 - Story 2.4: Deterministische Bereichszuordnung & Concept-Hierarchie
 - Story 2.5: Progressive Discovery über `index.md` bereitstellen
 ## Requirements & Constraints
 - Concepts werden anhand erkannter Wissenseinheiten erzeugt, nicht 1:1 pro Source-Abschnitt; mehrere Abschnitte einer Source können in verschiedene Concepts fließen. Concepts sind eigenständiges kuratiertes Wissen, keine Kopie oder Zusammenfassung des Quelldokuments (FR-5).
 - Jedes erzeugte Concept ist OKF-0.2-konform: Markdown mit YAML-Frontmatter, `type` als einziges Pflichtfeld; optional `sources`, `generated`, `verified`, `status`, `stale_after`. Das zulässige Feldsubset und seine Validität bindet `schema/wiki-compiler.md` (AD-1a). Kein eigener OKF-Dialekt.
 - Provenienz ist claim-granular: jede belegte Aussage trägt einen Inline-Verweis auf `raw/`-Evidenz; Kontext-/Synthese-Umformulierungen tragen einen expliziten Kontext-Marker ("übernommen aus `<Concept>` auf Basis von `<source>`, nicht eigenständig belegt") (AD-4a, A0-3).
 - `sources`-Einträge lösen ausschließlich auf `raw/`-Pfade oder extern referenzierte immutable Evidenz auf — nie auf `wiki/`-Concept-Pfade (AD-4b, A0-4).
 - Es muss wirkungsvoll verhindert werden, dass generierte Concepts als eigene Evidenz verwendet werden: kein generiertes Concept darf ein anderes generiertes Concept als alleinige Provenienz führen — prüfbar über die Schema-Validierung (AD-4c, A0-5).
 - Beziehungen zwischen Concepts werden als normale Markdown-Links ausgedrückt — in genau einer erlaubten Form: bundle-relativ, mit oder ohne Endung, nie beides (FR-10, AD-7b, A0-9). Links sind die Navigations-/Beziehungsschicht, nicht die Provenienz; keine proprietäre Link-Datenbank, herkömmliche Markdown-Tools müssen den Link auflösen können (AD-8).
 - Bereichszuordnung ist textual-deterministisch zu bestimmen (bestehender `index.md`-Link oder Top-Level-Kollisions-Hold auf bestehende Pfade), nie per Embedding/Vector-Infrastruktur (AD-7c, A0-10, AD-13).
 - Concepts bleiben unmittelbar menschlich lesbares Markdown und für LLM-Agenten über Standard-Dateioperationen erschließbar; unvollständiges, ungeprüftes Wissen wird ohne künstliche Gewissheit dargestellt (NFR-2, NFR-3, NFR-7).
 ## Technical Decisions
 - **Concept-Identität (AD-7a, A0-8):** Identität ist der relative OKF-Pfad ohne `.md`-Endung (`wiki/spring/index.md` → `spring`); genau eine kanonische ID-Normalisierung für alle Producer. Renames sind semantische Änderungen und erfordern einen Redirect-/Deprecation-Eintrag in `log.md`, damit alte IDs maschinell auffindbar bleiben (AD-7d).
 - **Linkform ist gepinnt (AD-7b):** exakt eine Form (bundle-relativ, mit oder ohne Endung) — verhindert, dass zwei Producer aus demselben Baum unterschiedliche IDs berechnen. Der Link-Bestand ist die Navigationsschicht; eine spätere Graph-Ableitung ist optional und nie kanonisch (AD-8).
 - **Provenienzmodell (AD-4a..c):** Inline-`raw/`-Verweise pro Aussage plus Kontext-Marker für Übernahmen; `sources` zeigen nie auf `wiki/`; die "keine abgeleitete Provenienz"-Regel ist Teil der `schema/wiki-compiler.md`-Validierung.
 - **Hierarchie & Discovery (AD-9, AD-1):** `wiki/` ist Bundleroot; Areas folgen `<area>/index.md` + `<concept>.md`. Discovery läuft Bundle-Root `index.md` → Area-`index.md` → Concepts; ein neu angelegtes Concept wird im `index.md` seines Bereichs verlinkt. Search ist optionale, spätere, Consumer-seitige Optimierung; das Bundle bleibt ohne geladene Indizes (z.B. nach Git-Clone) vollständig verständlich.
 - **Trust-Metadaten v1 (AD-15, A0-20):** maschinell erzeugte Concepts erhalten `generated: { by, at }`, `verified` bleibt ungesetzt; Lifecycle optional über `status` (`draft` | `stable` | `deprecated`) und `stale_after`.
 - **Kein Server, keine Datenbank:** alle erzeugten Artefakte sind normale textuelle Dateien im Git-Workspace; jede Änderung bleibt über Git-Diff nachvollziehbar (AD-1, AD-11, AD-14).
 ## Cross-Story Dependencies
 - Setzt Workspace-Trennung, Bundle-Root und das OCKF-Feldsubset aus Epic 1 (Story 1.1, 1.3, 1.4) voraus; die Schema-Validierung von Story 1.4 erzwingt auch AD-4c (keine abgeleitete Provenienz).
 - Die hier erzeugten Concepts, Links und `index.md`-Strukturen sind die Eingabe für die inkrementelle Kompilation und Synthese (Epic 3) sowie für Widerspruchs- und Kuratierungs-Kontexte (Epic 4).
 - Identität und Verlinkung dieses Epics werden von den Consumers in Epic 5 unverändert gelesen.
 - Keine UX-/Design-Anteile relevant für diesen Epic: v1 ist datei-/CLI-basiert ohne GUI (A-3, AD-11).
@@ -0,0 +1,213 @@
 ---
 title: 'Concepts aus Source Material erzeugen (OKF-Konform) (Story 2.1)'
 type: 'feature'
 created: '2026-08-16'
 status: 'done'
 review_loop_iteration: 0
 baseline_commit: a67ba659108006a54eb54b84592d1dba046af96e
 context:
  - _bmad-output/implementation-artifacts/epic-2-context.md
 ---
 <frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
 ## Intent
 **Problem:** Der Workspace kann Sources unter `raw/` (Story 1.2) halten und deren OKF-Konformität validieren (Story 1.4), aber es existiert noch keine deterministische, agentische Anweisung, die aus diesen Sources **neue, eigenständige OKF-0.2-Concepts** erzeugt (FR-5, FR-9) — der erste Compile-Run steht aus.
 **Approach:** Eine agent-unabhängige Compiler-Instruktion `schema/compiler.md` schaffen, die die Concept-Erzeugung als deterministischen, textuell nachvollziehbaren Agenten-Prozess beschreibt (Interpret → Reconcile → Synthesize → Mutation, AD-5/AD-7), und sie in einem **ersten Demonstrationslauf** gegen die drei vorhandenen `raw/`-Sources anwenden — Ergebnis: konkrete, OKF-validierbare Root-Concepts + Verlinkung in `wiki/index.md`.
 ## Boundaries & Constraints
 **Always:**
 - `schema/compiler.md` ist der **einzige Ort** der Erzeugungs-Instruktion; er ist rein textuell (kein ausführbarer Code, D-3) und agent-unabhängig (AD-10), liegt außerhalb des Bundles neben Vertrag und Validator (AD-1).
 - Concepts MÜSSEN OKF-0.2-konform sein: Markdown mit YAML-Frontmatter, `type` als einziges Pflichtfeld und nicht leer (§3.1, Stolperstein Punkt 1); Feldsubset strikt nach §3 (`type`, `sources`, `generated`, `verified`, `status`, `stale_after`), keine unautorisierten Keys (Stolperstein Punkt 6). `okf_version`/`type: bundle` NIE in Concepts (Punkt 9).
 - Trust-Metadaten v1 (A0-20, AD-15): maschinell erzeugt → `generated: { by: wow-compiler/0.1.0, at: <ISO-8601-Datetime> }`, `verified` ungesetzt. `at` ist VOLLES ISO-8601-Datetime (`YYYY-MM-DDTHH:MM:SS` mit `Z`/`±HHMM`/`±HH:MM`), nie reines Datum (Validator Revision ≥3, Punkt 14).
 - `sources` zeigt ausschließlich auf `/`-getrennte, relative Workspace-Pfade unter `raw/` (§3.3, AD-4b); jede referenzierte `raw/`-Datei MUSS zum Validierungszeitpunkt als Datei existieren (EC-1) — nie auf `wiki/`-Pfade (Punkt 3), kein `..`/URL/absolut/Backslash (Punkt 4).
 - Concepts sind eigenständige Wissenseinheiten (FR-5): nicht 1:1 pro Abschnitt, nicht bloße Kopie/Zusammenfassung des Quelldokuments (FR-2); mehrere Source-Abschnitte können in verschiedene Concepts fließen. V1-Instruktion erzeugt Concepts **auf Root-Ebene** unter `wiki/` (Story 2.4 regelt Area-Zuordnung später); neue Concepts MÜSSEN in `wiki/index.md` verlinkt werden (Punkt 11 / Index-Regel §6).
 - Der Demonstrationslauf mutiert ausschließlich `wiki/` (Concepts + `index.md` + zulässiger `log.md`-Eintrag); `raw/` bleibt unangetastet (AD-3); `schema/wiki-compiler.md` und `schema/validator.md` bleiben unverändert (autorisiert).
 - `log.md`-Eintrag (optional, Vertrag §5-konform): datumsgruppiert, neueste zuerst; dokumentiert die angelegten Concepts inkl. Quell-Pfad.
 - Instruktion und Konzepte in Deutsch.
 **Ask First:**
 - Eine bewusste Abweichung vom Feldsubset oder eine neue Invaliditätsart (Verschärfung des §7-Katalogs) — alles, was den autorisierten Vertrag ändern würde, ist explizit menschlich zu genehmigen.
 - Die Einführung eines Standalone-Programms (Python/TS/etc.) als Compiler — D-3 widerspricht; nur mit menschlicher Zustimmung (Rückkehrpunkt dokumentiert).
 - Die Anlage eines `wiki/<area>/`-Verzeichnisses in dieser Story (Area-Zuordnung ist Story 2.4) — nicht ohne menschliche Genehmigung.
 **Never:**
 - Kein eigener OKF-Dialekt, keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md` (autorisiert, Story 1.3/1.4), keine Änderung an `raw/` (immutable, AD-3).
 - Kein Standalone-/Executable-Compiler (D-3); keine LLM-Runtime-Implementierung im Bundle; kein MCP.
 - Keine claim-granulare Inline-Provenienz-Ausarbeitung (Story 2.2), keine deterministische Area-Zuordnung/Hierarchie (Story 2.4), keine vollständige Discovery-Logik über `index.md`/Progressive Discovery (Story 2.5) — diese Stories bleiben unangetastet, dürfen aber nicht behindert werden.
 - Keine Löschung/Umbenennung bestehender Concepts oder `log.md`-Einträge; keine stillschweigende Verlinkung außerhalb `wiki/index.md`.
 - Kein LLM-Urteil in der Instruktion als alleinige Entscheidungsbasis: Wo Relevanz/Klassifikation nötig ist, wird sie textual-deterministisch begründet (AD-13).
 ## I/O & Edge-Case Matrix
 | Scenario | Input / State | Expected Output / Behavior | Error Handling |
 |----------|--------------|---------------------------|----------------|
 | HAPPY_PATH | 3 neue Sources unter `raw/` (prd, epics, architecture-spine), leeres `wiki/` (nur `index.md`, `log.md`) | Compiler erzeugt 3 dem Source-Inhalt entsprechende, eigenständige Root-Concepts (`wiki/<slug>.md`) mit `type`, `sources`→existing `raw/`-Pfade, `generated {by, at}` ohne `verified`; verlinkt alle 3 in `wiki/index.md`; Validator-Lauf ergibt SUCCESS | N/A |
 | CONCEPT_OHNE_TYPE | Compiler legt Concept ohne/leeres `type` an | Concept ist strukturell invalide (Punkt 1) | Instruktion verlangt zwingend `type`; Run bricht mit textueller Fehlerursache ab, `wiki/`-Änderungen bis dahin rückmelden |
 | FEHLENDE_RAW | `sources`-`resource` verweist auf nicht existente `raw/`-Datei | Fachlich invalide (EC-1) → Run-FAIL | Instruktion: nur real existierende `raw/`-Dateien als `resource`; Verweis auf strukturierte Prüfung |
 | LEERE_QUELLE / KEINE_WISSENSEINHEITEN | Source enthält keine klar abgegrenzten Wissenseinheiten (z.B. nur README/Artefakt wie `raw/README.md`) | Wird NICHT zu einem Concept verdichtet; ggf. als Hinweis in `log.md` | Artefakt-Dateien (`source.md`, `README.md`) sind keine Evidenz (raw/README.md) → ausgeschlossen |
 | VERALTETE_SOURCE | `source.md` verweist auf Commit, der nicht mehr existiert | Provenienz-Hinweis bleibt im Sidecar; `raw/`-Datei selbst ist Evidenz | Fehlende Commit-Auflösbarkeit blockiert die Concept-Erzeugung nicht (Sidecar ist Artefakt, nicht Input) |
 | KEIN_CONTENT | Concept würde nur Source-Copy sein | Kein Concept anlegen; Wissen ist nicht neu → nichts erzeugen | FR-2-konform: Kopieren/Zusammenfassen ist keine Wissensintegration |
 </frozen-after-approval>
 ## Code Map
 - `schema/compiler.md` — **Zieldatei (neu)**: deterministische Compiler-Instruktion zur Concept-Erzeugung; Kern des Reviews.
 - `schema/wiki-compiler.md` — **Normative Grundlage (read-only, Story 1.3)**: §1 Geltungsbereich, §2 Bundleroot, §3.1–3.7 Feldsubset & Formate (inkl. §3.3 `sources`/`resource`, §3.4 `generated`, §3.5 `verified`, §3.6 `status`, §3.7 `stale_after`), §5 `log.md`, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
 - `schema/validator.md` — **Pflicht-Referenz (read-only, Story 1.4)**: §3.2 Voraussetzungsprüfungen V-1/V-2; §4.1 kanonische Key-Reihenfolge; §4.3 ISO-8601-Normalform (`at` voll, keine reine Datumsangabe); §6 fachliche Prüfungen (EC-1 Existenz); §6.2 Punkt-4-vor-3-Priorität; Punkt-11-Index-Check (Root-Concepts → Bundleroot `wiki/index.md`).
 - `wiki/index.md` — **Zieldatei (mutiert im Demonstrationslauf)**: Bundleroot (Frontmatter exklusiv `type: bundle`/`okf_version: "0.2"`); nimmt die Root-Concept-Links auf (Punkt 11); kein eigenes Frontmatter-Feld anfassen.
 - `wiki/log.md` — **Zieldatei (append-only)**: zulässiger Protokolleintrag (Vertrag §5) über angelegte Concepts; kein Frontmatter.
 - `raw/prd/prd-wow20-2026-08-14.md`, `raw/epics/epics-2026-08-14.md`, `raw/architecture-spine/architecture-spine-2026-08-14.md` — **Evidenz (read-only, Story 1.2)**: Demonstrations-Sources; `resource`-Ziele der neuen Concepts.
 - `raw/README.md`, `raw/*/source.md` — Artefakt-/Grenzdateien (keine Evidenz); nicht als Concepts konsumierbar.
 - `adapters/README.md`, `adapters/claude/README.md` — Adapter-Kontext (read-only, AD-10); Story 5.3 Zuständigkeit, kein Ort für Erzeugungslogik.
 - `_bmad-output/planning-artifacts/architecture/architecture-wow20-2026-08-14/ARCHITECTURE-SPINE.md` — AD-5 (inkrementell, Interpret→Reconcile→Synthesize→Update), AD-7-Reihe (Identität/Verlinkung/Areas: Story 2.3/2.4), AD-17 (Lease/branch, nur committete Inputs), D-3 (kein Standalone-Compiler).
 - `_bmad-output/implementation-artifacts/epic-2-context.md` — primärer Planungskontext (read-only).
 ## Tasks & Acceptance
 **Execution:**
 - [x] `schema/compiler.md` — Compiler-Instruktion anlegen: Zweck & Aufruf (Agent führt Schritte deterministisch aus), Eingabe (committete `raw/`-Evidenz, AD-17) und Ausgabe (OKF-validierbare Concepts), der logische Fluss Interpret→Reconcile→Synthesize→Mutation (AD-5), die Erzeugungs-/Auswahlregeln (Wissenseinheiten statt 1:1-Abschnitte, FR-5; keine Kopie, FR-2; artefakt-Evidenz-Ausschluss), die Pflicht-Frontmatter-Vorgabe für neue Concepts (`type` gesetzt; §3-Subset; `generated { by: wow-compiler/<version>, at: volles ISO-8601 }` ohne `verified`, A0-20; canonische Key-Reihenfolge §4.1; `sources`→existierende `raw/`-Pfade, EC-1), die Verlinkungs-Pflicht (neue Root-Concepts in `wiki/index.md` verlinken, Punkt 11/§6), Dokumentationspflicht (`log.md`, Vertrag §5) und die Selbstbegrenzung (keine Area-Anlage [Story 2.4], keine claim-granulare Provenienz-Ausarbeitung [Story 2.2], kein Standalone-Code, keine OKF-Erweiterung [D-3, AD-1a]) — FR-5, FR-9, NFR-2/3/4.
 - [x] `schema/compiler.md` — Determinismus-/Selbsttest-Norm: jede Erzeugungsentscheidung textual-deterministisch begründbar (AD-13); eine Nachprüf-Sektion, die ein erzeugtes Concept gegen den Validator abprüfbar macht (vollständige §3-Subset-Konformität, `at`-Normalform, `sources`-Existenz) — AD-17h-konform, ohne LLM-Doppelurteil (der Validator bleibt die mechanische Prüfung).
 - [x] `schema/compiler.md` — Positiv-/Negativ-Beispiele (Referenztabellen): je Regel ein Beispiel-Concept (ideal-konform vs. verletzte Regel) — AD-17h/Verifikations-Kultur aus Story 1.4 (Verifikations-Beleg).
 - [x] Demonstrationslauf (Agent führt Instruktion aus): 3 eigenständige Root-Concepts aus den 3 `raw/`-Evidenzdateien erzeugen (je `wiki/<slug>.md`: `type`, `sources` mit existierenden `raw/`-Pfaden, `generated {by, at}` ohne `verified`, inhaltlich eigenständig kuratiert), alle in `wiki/index.md` verlinken, `wiki/log.md`-Eintrag ergänzen.
 - [x] Validator-Lauf gegen das mutierte Bundle: erzeugte Concepts + `index.md` + `log.md` MÜSSEN SUCCESS liefern (Punkt 11 inklusive: Root-Concept links in Bundleroot); Ergebnis im Spezifikations-Verification dokumentieren.
 - [x] `_bmad-output/implementation-artifacts/sprint-status.yaml` — Story 2.1 von `backlog` auf `in-progress` setzen (nach Start der Implementierung).
 **Acceptance Criteria:**
 - Given eine neue Source mit mehreren Abschnitten, when ein Compilation Run sie verarbeitet, then erzeugt der Compiler eigenständige Concepts gemäß den erkannten Wissenseinheiten — nicht 1:1 pro Abschnitt, nicht an die Source-Struktur gebunden (FR-5).
 - Given die Concept-Erzeugung, when ein Concept geschrieben wird, then ist es OKF-0.2-konform: Markdown mit YAML-Frontmatter, `type` als verpflichtendes, nicht leeres Feld; vollständiges §3-Subset ohne unautorisierte Keys (AD-1a, FR-9).
 - Given ein erzeugtes Concept, when dessen V1-Trust-Metadaten gesetzt werden, then sind sie `generated: { by, at }` (volles ISO-8601) ohne `verified` (A0-20, AD-15).
 - Given der Demonstrationslauf, when der Validator danach ausgeführt wird, then ist das Bundle mit den neuen Root-Concepts + `index.md`-Verlinkung + `log.md`-Eintrag vollständig SUCCESS (insbesondere Punkt 1, 6, 11, 12, 14).
 - Given `sources`-Referenzen, when sie dokumentiert werden, then lösen sie ausschließlich auf real existierende `raw/`-Dateien auf — nie auf `wiki/`-Pfade (AD-4b, EC-1).
 - Given ein erzeugtes Concept, when es inhaltlich eine bloße Kopie/Zusammenfassung der Quelle wäre, then erzeugt der Compiler es nicht (FR-2: Kopieren ist keine Wissensintegration).
 - Given ein neues Concept auf Root-Ebene, when es angelegt wird, then wird es in `wiki/index.md` verlinkt (Punkt 11/§6), ohne Area-Verzeichnis anzulegen (Story 2.4).
 - Given die Instruktion, when sie ausgeführt wird, then ist sie eine eigenständige, deterministische, agent-unabhängige Anweisung (D-3, AD-17h) — kein Standalone-Programm.
 ## Spec Change Log
 - (leer bis zum ersten Review-Loopback)
 ## Design Notes
 **Warum eine Instruktion, kein Programm (D-3):** Genau wie der Validator (Story 1.4) ist der Compiler eine textuelle Agent-Instruktion — der deterministische Kern ist `schema/compiler.md`, ausgeführt von einem vorhandenen agentischen Host (AD-11). Das hält die Story klein, revisionierbar (Git) und prüfbar (AD-17h). Ein Standalone-Compiler ist explizit D-3-verboten und nur als dokumentierter Rückkehrpunkt für eine spätere Story zugelassen.
 **Root-Ebene statt Areas (Umgehung des Punkt-11-/Area-Dilemmas):** Story 2.4 besitzt die deterministische Area-Zuordnung; Story 2.5 die Discovery-Navigation. Story 2.1 darf diesen Stories nicht vorgreifen. Daher entstehen die ersten Concepts **direkt unter `wiki/`** (`wiki/<concept>.md`) und werden — wie es der Punkt-11-Check des Validators für Root-Concepts verlangt — in der Bundleroot `wiki/index.md` verlinkt. Es wird kein `wiki/<area>/`-Verzeichnis angelegt. Story 2.4 kann diese Root-Concepts später per deterministischer Zuordnung in Areas verschieben (mit AD-7d-Rename-Eintrag in `log.md`).
 **Demonstrationslauf = der eigentliche „Beweis":** Die Instruktion allein wäre nur Theorie. Der Run gegen die 3 `raw/`-Evidenzdateien erzeugt echte Concepts und wird anschließend gegen den **autorisierten Validator** (Story 1.4) geprüft — das ist die mechanische Bestätigung der Konformität (Kultur aus Story 1.4: Validator-Selbstprüfung gegen Fixtures). Die `at`-Zeitstempel werden zum Ausführungszeitpunkt in UTC-ISO-8601 gesetzt.
 **Zeitstempel-Determinismus:** Der `at`-Wert ist ein Ausführungszeitpunkt und damit per se nicht deterministisch über Runs hinweg — das ist beabsichtigt (Trust-Metadaten beschreiben den Erzeugungsmoment, AD-15). Deterministisch sind Pfad, Struktur, Frontmatter-Form und `sources`-Auflösung; der Verdikt-Erfolg hängt nicht von einer festen `at`-Sekunde ab.
 ## Verification
 **Commands:**
 - `git status --short && git diff --stat` — expected: neue Datei `schema/compiler.md` + `wiki/<slug>.md`-Concepts + `wiki/index.md`-Änderung + `wiki/log.md`-Eintrag + `sprint-status.yaml`-Update; KEINE `raw/`-, `schema/wiki-compiler.md`-, `schema/validator.md`-Mutationen.
 - Validator-Instruktion gegen Bundle ausführen (manuell/deterministisch, siehe `schema/validator.md` §5-Grammatik): `grep -nE 'Punkt 11|concept nicht verlinkt' schema/validator.md` + praktischer SUCCESS-Lauf des Validators gegen `wiki/` — expected: alle neuen Concepts + `index.md` + `log.md` liefern `SUCCESS` (kein FAIL, kein WARN-Blocker).
 - Frontmatter-Konformitäts-Smoke: `grep -nE '^(type|sources|generated|verified|status|stale_after):' wiki/*.md` — expected: nur §3-Felder je Concept; `type` gesetzt; `generated.at` im Format `YYYY-MM-DDTHH:MM:SS` (mit Offset-Suffix).
 - `sources`-Auflösung: `grep -nE 'resource:' wiki/*.md` — expected: jeder Wert ist ein existierender `/`-getrennter `raw/`-Pfad (kein `..`, kein `wiki/`, keine URL).
 - `git log --oneline -3 -- raw/` — expected: keine neuen Commits/Einträge unter `raw/` (immutable).
 - `at`-Format-Smoke (Punkt 14): `grep -nE '^  at: [0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|[+-][0-9]{2}:?[0-9]{2})$' wiki/*.md` (je `generated.at`/`verified.at` ein volles ISO-8601-Datetime; reines Datum wäre FAIL Punkt 14).
 - `sources`-Eintrag-Key-Subset (Vertrag §3.3/Punkt 6): `grep -nE '^  - [a-z_]+:' wiki/*.md` — expected: je `sources`-Eintrag ausschließlich `resource` (bzw. erlaubte optionale: `id`/`title`/`author`/`usage_count`/`last_modified`); kein unautorisierter Key.
 **Manual checks (if no CLI):**
 - `schema/compiler.md` ist rein textuell (kein Programmcode/Executable-Abschnitt) und beginnt mit Zweck & Aufruf.
 - Alle Erzeugungsregeln sind deterministisch formuliert und auf Vertrag/Validator zurückführbar (kein reines LLM-Urteil).
 - `wiki/log.md` enthält einen datierten Eintrag über die angelegten Concepts mit Quell-Pfaden.
 - Jede Concept-Datei ist menschlich lesbares Markdown (NFR-2) und nicht bloße Kopie der Quelle (FR-2).
 ## Verification Record (Ausführungs-Beleg, 2026-08-16)
 **Demonstrationslauf:** `schema/compiler.md` (Revision 1.1) angelegt; 3 Root-Concepts erzeugt; `wiki/index.md` + `wiki/log.md` mutiert. `sprint-status.yaml`: epic-2 + Story 2.1 → `in-progress`.
 **Validator-Lauf gegen das mutierte Bundle (gemäß `schema/validator.md`, Revision 6, deterministisch ohne LLM-Urteil):**
 | Datei | Punkte 1–14 | §6/V §6.1 EC-1 | Verdikt |
 |---|---|---|---|
 | `wiki/index.md` | 8, 9, 13 ✓ (Punkt 8 OK, kein Punkt-9-Inhalt, keine Duplikate) | — | SUCCESS |
 | `wiki/log.md` | 10 ✓ (kein Frontmatter), 9 ✓ | — | SUCCESS |
 | `wiki/llm-wiki-prinzip.md` | 1, 2, 6, 7, 12, 13, 14 ✓ (`type: concept`, `generated.by` gesetzt, `at` = `2026-08-16T09:23:33Z` volles ISO-8601, canonical key order, keine Duplikate) | EC-1 ✓ (`raw/prd/prd-wow20-2026-08-14.md` existiert als Datei) | SUCCESS |
 | `wiki/knowledge-kompilation-inkrementell.md` | 1, 2, 6, 7, 12, 13, 14 ✓ | EC-1 ✓ (`raw/epics/epics-2026-08-14.md` existiert) | SUCCESS |
 | `wiki/wissensarchitektur-trennung-states.md` | 1, 2, 6, 7, 12, 13, 14 ✓ | EC-1 ✓ (`raw/architecture-spine/architecture-spine-2026-08-14.md` existiert) | SUCCESS |
 **Punkt 11 (Index-Regel):** Alle 3 Root-Concept-Identitäten `llm-wiki-prinzip`, `knowledge-kompilation-inkrementell`, `wissensarchitektur-trennung-states` sind in `wiki/index.md` verlinkt (`grep -c` je = 1) ✓.
 **Punkt 3/4 (Keine `wiki/`-Auflösung, Pfad-Grammatik):** Alle `resource`-Werte sind `/`-getrennte `raw/`-Pfade ohne `..`, ohne führendes `/`, ohne Backslash, ohne URL ✓.
 **Scope:** Keine Mutation unter `raw/` (`git log raw/` ohne neue Commits), `schema/wiki-compiler.md` und `schema/validator.md` unverändert (autorisiert) ✓. Frontmatter-Smoke `grep -nE '^(type|sources|generated|verified|status|stale_after):' wiki/*.md` → nur §3-Felder in Concepts, kein `okf_version`/`type: bundle` ✓.
 **Gesamtergebnis:** `SUCCESS` für alle 5 Bundle-Dateien — kein FAIL. Run als erfolgreich gewertet (Integrations-/Verifikations-Beleg).
 ## Spec Change Log
 - **2026-08-16 (Step-04-Review):** `sources`-Eintrag-Key-Subset als Zusatz-Verification-Check ergänzt (Vertrag §3.3, Punkt 6); `at`-Format-Smoke als Punkt-14-Beleg unter die Verification-Checks aufgenommen; `status: in-review` (Review begonnen). Keine Änderung am `<frozen-after-approval>`-Intent.
 - **2026-08-16 (Erstellung):** Initiale Approve-Baseline.
 ## Edge-Case-Matrix-Audit
 | Scenario | Abgedeckt durch | Befund |
 |---|---|---|
 | HAPPY_PATH | §5 Demonstrationslauf | ✓ 3 Concepts erzeugt, verlinkt, validiert |
 | CONCEPT_OHNE_TYPE | §4.1 (Punkt 1) + §6.5 Kriterium 1 | ✓ Instruktion verlangt zwingend non-empty `type`; Abweichung → Run-FAIL mit textueller Ursache |
 | FEHLENDE_RAW | §4.2 + §6.5 Kriterium 3 (EC-1) | ✓ nur real existierende `raw/`-Dateien als `resource` |
 | LEERE_QUELLE / KEINE_WISSENSEINHEITEN | §1.3/§1.4 (Artefakt-Ausschluss) | ✓ `raw/README.md`, `raw/**/source.md` sind kein Input/keine Evidenz; werden nie `resource` |
 | VERALTETE_SOURCE | §1.4 (Sidecar = Artefakt, nicht Input) | ✓ fehlende Commit-Auflösbarkeit blockiert Erzeugung nicht |
 | KEIN_CONTENT | §2.3 (FR-2, Curated ≠ Copy) | ✓ bloße Kopie/Zusammenfassung → kein Concept |
 ## Step-04-Review-Nachschärfungen (2026-08-16)
 Nach den drei Review-Layern (Blind Hunter, Edge Case Hunter, Verification Gap) angewendet:
 - `schema/compiler.md` auf Revision 1.2: Input-Regel auf AD-17a statt AD-17.2 referenziert; `sources`-Eintrag-Key-Subset (Innen-Ebene, Vertrag §3.3) in §4.2, §6.5-Kriterium-1 und §6.6 ergänzt; `status`-Absenz Formulierung an Vertrag §3.6 (Absenz = `stable`) angebunden; Bereichs-Ziel-Ablehnung bis Story 2.4 (§5.1/§6.6); §6.6-Fehlerursache der `verified`-Zeile auf Punkt 6 korrigiert (statt „semantisch (Trust)"); §6.6-Referenzlabel von §4.5 auf §4.4 korrigiert; §6.6 um vollständige Punkt-4-Pfad-Verbote ergänzt; AD-17f als Commit-Boundary sichtbar (§0/§5.3/§6.6).
 - `schema/validator.md` auf Revision 7: §7.3-Isolations-Hinweis um Innen-Ebenen-Key-Subset-Fälle (Punkt 6 in `sources`/`generated`/`verified`-Einträgen) erweitert.
 - `wiki/index.md`: Workspace-Absatz präzisiert — `schema/` enthält drei Artefakte (Vertrag, Validator, Compiler-Instruktion) statt nur „Compiler-Schema-Vertrag".
 - `wiki/log.md`: Review-Eintrag ergänzt (Nachschärfungen + `at`-Konsistenz-Prüfung).
 - `sprint-status.yaml`: Story 2.1 → `review` (Review begonnen).
 **Verifiziert gegen Fehlalarme:** `at: 2026-08-16T09:23:33Z` entspricht 11:23:33 Lokalzeit (+0200) und deckt sich mit den Datei-Mutationszeitpunkten (11:24) — kein Befund auf die Ausführungszeit; Consumer-Namen (BMAD/Claude Code/Codex) sind in `raw/prd`, Spine und Epics verbatim belegt; Key-Reihenfolge liegt korrekt in Validator §4.1 (Zeile 104); „Mutieren" (AD-6/A0-7) steht im Einklang mit dem inkrementellen „Update"-Fluss (A0-6).
 **Defer-Kontexte (in `deferred-work.md` notiert):** Content-Truth-Verifikation (kein check prüft die inhaltliche Übereinstimmung eines Concept-Bodys mit seinen `raw/`-Quellen; Story 2.2/Deferred) sowie eine `at`-basierten Determinismus-Selbsttest-Divergenz (die `at`-Sekunde variiert pro Run, während der §6.6-Interpretations-Hinweis eine feste Form behauptet — mit der `at`-Run-Zeit semantisch konsistent, als Selbsttest-Dokumentation für Story 2.3/nächste Validator-Revision zu schärfen).
 ## Suggested Review Order
 **Einstieg (Design-Intent der Story)**
 - Deterministic compiler instruction — the single artifact that makes Story 2.1 load-bearing: one place, textual (D-3), flow Interpret→Reconcile→Synthesize→Mutate→Validate.
  [`compiler.md`](../../schema/compiler.md#L1)
 **Feldsubset & Trust — Intake der drei Artefakte**
 - New compiler instruction: `sources`-entry key-subset (Innen-Ebene, Vertrag §3.3) and `generated` (by/at, no verified) — the §4 production rules in canonical form.
  [`compiler.md`](../../schema/compiler.md#L48)
 - Authorized contract: field subset, `sources` key-subset per entry, `generated` by/at — the normative anchor Story 2.1 derives from (unchanged, authorized).
  [`wiki-compiler.md`](../../schema/wiki-compiler.md#L53)
 - Validator (Rev 7): §7.3-Isolations-Hinweis auf Innen-Ebenen-Key-Subset erweitert — Punkt 6 deckt auch `sources`/`generated`/`verified`-Eintragsebenen ab (Revisionslog nachgeführt, unverändert autorisiert).
  [`validator.md`](../../schema/validator.md#L260)
 **Wissenseinheiten — Konzepte aus den Quellen**
 - `LLM-Wiki-Prinzip` — Anker-Concept: Compounding, Knowledge Compiler vs. Retrieval; Trust-Metadaten gemäß A0-20 (generated ohne verified).
  [`llm-wiki-prinzip.md`](../../wiki/llm-wiki-prinzip.md#L1)
 - `Knowledge Compilation & Inkrementelle Evolution` — AD-5-Datenfluss, FR-12/FR-6/FR-14; Abgrenzung zu Epic 3.
  [`knowledge-kompilation-inkrementell.md`](../../wiki/knowledge-kompilation-inkrementell.md#L1)
 - `Wissensarchitektur: Source Material, Curated Knowledge & Consumer` — AD-2/AD-3-Grenzen, Consumer-Unabhängigkeit, Konvergenzregeln.
  [`wissensarchitektur-trennung-states.md`](../../wiki/wissensarchitektur-trennung-states.md#L1)
 **Verlinkung & Dokumentation — Bundle-Integrität**
 - Bundleroot-Index: `## Concepts` mit den 3 Root-Concept-Links + korrigierter Workspace-Beschreibung (drei `schema/`-Artefakte).
  [`index.md`](../../wiki/index.md#L24)
 - Bundle-Log: Story-2.1-Demonstrationslauf- und Review-Einträge (datumsgruppiert, ohne Frontmatter).
  [`log.md`](../../wiki/log.md#L3)
 **Status & Tracking — Peripherie**
 - Sprint-Status: epic-2/Story-2.1 auf `review` (Review begonnen), nach Abschluss auf `done` zu flippen.
  [`sprint-status.yaml`](../../_bmad-output/implementation-artifacts/sprint-status.yaml#L45)
@@ -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-16-2026 10:30
+last_updated: 08-16-2026 11:48
 project: wow20
 project_key: NOKEY
 tracking_system: file-system
@@ -42,8 +42,8 @@ development_status:
  1-4-schema-validierung-für-bundle-implementieren: done
  epic-1-retrospective: done
-  epic-2: backlog
+  epic-2: in-progress
-  2-1-concepts-aus-source-material-erzeugen-okf-konform: backlog
+  2-1-concepts-aus-source-material-erzeugen-okf-konform: review
  2-2-claim-granulare-provenienz-dokumentieren: backlog
  2-3-concepts-verlinken-eine-erlaubte-linkform: backlog
  2-4-deterministische-bereichszuordnung-concept-hierarchie: backlog
@@ -0,0 +1,136 @@
 # Compiler-Instruktion — OKF-Concepts aus Source Material erzeugen (Story 2.1)
 > **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 6) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h).
 > **Ableitungsdatum:** 2026-08-16
 > **Kanonischer Producer-Actor:** `wow-compiler/0.1.0`
 ## 0. Zweck & Aufruf
 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.
 **Entscheidungsebenen (keine eigene Norm):**
 ```text
 Behauptung (Normativ):  schema/wiki-compiler.md  (§7: abschließende 14-Punkte-Liste)
 Ableitung (Story 2.1):  schema/compiler.md       (Erzeugungs-Instruktion)
 Bestätigung (Story 1.4): schema/validator.md      (mechanische Prüfung, kein LLM-Urteil)
 ```
 ## 1. Input (what the compiler consumes)
 1. **Voraussetzung:** Der Run verarbeitet ausschließlich **veröffentlichte (committete) Inhalte** als Input (AD-17a — „Der Compiler darf nur veröffentlichte (committed) Inhalte als Input verwenden"); Zwischenstände während einer Mutation sind nie Input.
 2. **Evidenz:** Das Source Material unter `raw/` — jede Datei unter `raw/` ist Evidenz (AD-2/AD-3). Vom Compiler erzeugte Concepts DÜRFEN ausschließlich auf solche `raw/`-Dateien als `sources`-`resource` zeigen.
 3. **Bestehendes Bundle:** Das aktuelle `wiki/` (Bundleroot `index.md`, `log.md`, bestehende Concepts) ist der zweite Input; der Run beginnt mit dem vorhandenen Bundle und verändert nur, was durch neue Erkenntnisse betroffen ist (AD-5 — niemals „Regenerate Everything").
 4. **Nicht-Evidenz (Artefakt-/Grenzdateien) sind KEIN Input:** `raw/README.md`, jede `raw/**/source.md` (Provenienz-Sidecar), `schema/`, `adapters/` — sie sind keine zu verarbeitende Evidenz und dürfen **nie** als `sources`-`resource` eines Concepts verwendet werden.
 ## 2. Interpretieren (Wissenseinheiten erkennen)
 1. Der Producer liest die bereitgestellten Evidenzdateien und **identifiziert darin abgegrenzte Wissenseinheiten** (ein Thema, ein Konzept, ein zusammenhängender Sachverhalt).
 2. **Nicht 1:1 pro Dokument, nicht 1:1 pro Abschnitt** (FR-5): Ein Dokument kann mehrere Wissenseinheiten enthalten, die in mehrere Concepts fließen; eine Wissenseinheit kann aus mehreren Abschnitten/Dokumenten stammen. Die Anzahl der Concepts ergibt sich aus den erkannten Einheiten, nicht aus der Datei- oder Abschnittszählung der Source.
 3. **Grenze der Interpretation (Curated ≠ Copy, FR-2/SM-2):** Eine Wissenseinheit wird nur dann zum Concept, wenn sie **eigenständig formuliertes kuratiertes Wissen** ergibt. Bloße Kopie, das Einfügen großer Quellblöcke oder eine Zusammenfassung des Quelldokuments sind **keine** Wissensintegration und DÜRFEN nicht erzeugt werden.
 4. Ein Concept wird in **Deutsch** formuliert (Projekt-Sprachkonvention) und ist für Menschen unmittelbar als Markdown lesbar (NFR-2).
 ## 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").
 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).
 ## 4. Synthetisieren (Provenienz & Trust)
 Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
 1. **`type`** (Pflicht, §3.1): ein nicht-leerer String; für fachliche Wissenseinheiten ist `concept` die Standard-Klasse.
 2. **`sources`** (optional, §3.3): Liste von Maps; je Eintrag MUSS `resource` gesetzt sein. Regeln:
   - `resource` ist ein `/`-getrennter relativer Workspace-Pfad **innerhalb `raw/`** — nie `wiki/` (AD-4b/Punkt 3), kein `..`, kein führendes `/`, kein Backslash/Windows-Trenner, keine URL-Form (Punkt 4).
   - Jede referenzierte Datei MUSS unter `raw/` zum Zeitpunkt des Runs als **Datei existieren** (EC-1; Verzeichnisse sind unzulässig).
   - Zusätzlich zu `resource` sind optional zulässig: `id`, `title`, `author`, `usage_count` (Ganzzahl ≥ 0), `last_modified` (`YYYY-MM-DD`, reale Kalenderdaten).
   - **Key-Subset je Eintrag (Innen-Ebene, Vertrag §3.3):** Innerhalb eines `sources`-Eintrags sind **ausschließlich** die Felder `resource`, `id`, `title`, `author`, `usage_count`, `last_modified` erlaubt — jeder andere Key ist eine unautorisierte Verletzung und löst beim Validator Punkt 6 aus (nicht nur die Top-Level-Felder zählen).
 3. **`generated`** (v1-Default, §3.4/A0-20): Map `{ by, at }`. `by` ist zwingend und nicht leer; Produkt-Konvention: `wow-compiler/0.1.0` (dieser Compiler). `at` ist der **Ausführungszeitpunkt in vollem ISO-8601-Datetime** (`YYYY-MM-DDTHH:MM:SS` mit `Z`/`±HHMM`/`±HH:MM`), nie ein reines Datum (Validator §4.3, Punkt 14). `verified` bleibt **ungesetzt** — maschinell erzeugt und ungeprüft (A0-20).
 4. **`status`/`stale_after`** (optional): nur Werte aus §3.6 (`draft`/`stable`/`deprecated`) bzw. §3.7 (`YYYY-MM-DD`). Bei der Erzeugung neuer Concepts bleibt beides in der Regel **ungesetzt** — die Absenz von `status` bedeutet laut Vertrag §3.6 per Definition den Default `stable`; der Compiler trifft also bewusst keine Lebenszyklus-Entscheidung, sondern überlässt den Default der Vertrags-Semantik.
 5. **Frontmatter-Reihenfolge (kanonische Normalform, Validator §4.1):** `type`, `sources`, `generated`, `verified`, `status`, `stale_after`. Duplikat-Keys sind verboten (Punkt 13). Keine unautorisierten Felder (Punkt 6); `okf_version`/`type: bundle` NIE in Concepts (Punkt 9).
 ## 5. Mutieren (Dateien schreiben)
 1. **Ziel-Pfad:** Das neue Concept ist eine Markdown-Datei unter `wiki/`. In dieser Story (keine deterministische Area-Zuordnung; Story 2.4) werden neue Concepts **auf Root-Ebene** angelegt: `wiki/<concept-kebab-case>.md`. Es wird **kein** `wiki/<area>/`-Verzeichnis angelegt; ein als Area gedachtes Ziel (Unterverzeichnis) wird bis Story 2.4 **abgelehnt** und führt zu einem textuell identifizierbaren Hinweis („Area-Zuordnung ist Story 2.4").
   - Konvention für den Dateinamen: kebab-case-Slug aus der Concept-Identität (kein Sonderzeichen, keine Endung `.md`-Dopplung). Der Dateiname definiert die Concept-Identität (relativer OKF-Pfad ohne `.md`, AD-7a).
 2. **Dateiinhalt:** YAML-Frontmatter gemäß §4 (kein weiteres Feld), gefolgt von einem Markdown-Body, der die Wissenseinheit eigenständig und lesbar darstellt (NFR-2, NFR-3). Der Body darf keine grossen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) ist Story 2.2 und wird hier **nicht** gefordert.
 3. **Index-Regel (Punkt 11/§6):** Nach Anlage MUSS das neue (Root-)Concept in der Bundleroot `wiki/index.md` verlinkt werden — seine Identität (relativer OKF-Pfad ohne `.md`) als relativer Bundle-Pfad referenziert, mit oder ohne `.md`-Endung (eine genau-eine-Form-Festlegung ist Story 2.3). Ohne diese Verlinkung ist das Bundle strukturell invalide (§7 Punkt 11).
   - All dies (Anlage + Verlinkung + `log.md`) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f).
 4. **Dokumentation (`log.md`, Vertrag §5):** Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (neueste zuerst; Header = ISO-Datum `YYYY-MM-DD`), verknüpft mit dem neuen Concept-Pfad und den genutzten `raw/`-Quellen. `log.md` bleibt ohne Frontmatter (Punkt 10).
 ## 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).
 2. **Erfolgsbedingung:** Alle Dateien unter `wiki/` — Bundleroot, `log.md`, sämtliche neuen Concepts — liefern `SUCCESS` (kein FAIL; `stale_after`-WARN wäre nur Berichtskanal). Dabei ist insbesondere Punkt 11 (Index-Regel) zu bestätigen: jeder neue Root-Concept-Pfad ist in `wiki/index.md` verlinkt.
 3. Bei jedem FAIL gilt der Run als gescheitert; es werden **keine** weiteren Mutationen durchgeführt, `raw/` bleibt unangetastet (AD-3), und die Fehlerursache wird textuell benannt (NFR-4).
 4. Der Producer hält das Verdikt-Ergebnis (je Datei SUCCESS/FAIL) als Ausführungs-Nachweis fest (z. B. in der Story-Spezifikations-Verification oder im Run-Bericht).
 ## 6.5 Determinismus- & Selbsttest-Norm (Nachprüf-Sektion)
 Jede Erzeugungsentscheidung dieser Instruktion ist **textual-deterministisch begründbar** (AD-13): die erkannten Wissenseinheiten (§2), die Reconcile-Kollisionsprüfung (§3), die Frontmatter-Werte (§4) und die Ziel-Pfade (§5) folgen aus dem Input ohne probabilistische Verfahren. Es gibt keine Embedding-/Vector-Infrastruktur und kein reines LLM-Urteil als alleinige Entscheidungsbasis.
 Vor Abschluss eines Runs prüft der Producer jedes erzeugte Concept gegen die folgenden **drei Selbsttest-Kriterien** (AD-17h-konform; der Validator in §6 bleibt die mechanische Prüfung, diese Kriterien sind seine Vorab-Projektion):
 1. **Vollständige §3-Subset-Konformität:** Das Frontmatter enthält ausschließlich Keys aus {`type`, `sources`, `generated`, `verified`, `status`, `stale_after`} in kanonischer Reihenfolge (§4.1 des Validators); `type` ist gesetzt und non-empty; keine Duplikat-Keys (Punkt 13, auch innerhalb von `sources`/`generated`/`verified`-Einträgen); Keine unautorisierten Keys — weder auf Top-Level-Ebene noch innerhalb von `sources`/`generated`/`verified`-Einträgen (Vertrag §3.3/§3.4/§3.5, Punkt 6); `okf_version`/`type: bundle` kommen nicht vor (Punkt 9).
 2. **`at`-Normalform:** `generated.at` (und ggf. `verified[].at`) ist ein **volles ISO-8601-Datetime** `YYYY-MM-DDTHH:MM:SS` mit `Z`/`±HHMM`/`±HH:MM` — keine reine Datumsangabe (Punkt 14; Validator §4.3).
 3. **`sources`-Existenz:** Jeder `sources[].resource` verweist auf einen `/`-getrennten relativen Pfad unter `raw/`, der zum Validierungszeitpunkt als **Datei existiert** (EC-1); kein `..`, kein führendes `/`, kein Backslash, keine URL-Form, kein `wiki/`-Pfad (Punkt 3/4, §6.2).
 Weicht ein erzeugtes Concept in mindestens einem Kriterium ab, wird es **nicht** als erfolgreiche Erzeugung behandelt; der Run korrigiert oder verwirft die Datei und dokumentiert die Abweichung textuell (NFR-4) — es fließt nichts Ungeprüftes in das Bundle.
 ## 6.6 Positiv-/Negativ-Beispiele (Referenztabellen)
 Die folgende Tabelle macht jede Erzeugungsregel dieser Instruktion reproduzierbar nachprüfbar (AD-17h, Verifikations-Kultur aus Story 1.4 — Verifikations-Beleg). „✓" = ideal-konform (erwartet: Validator-SUCCESS), „✗" = verletzte Regel (erwartet: Validator-FAIL mit der genannten Fehlerursache).
 | Regel (§) | ✓ Positiv-Beispiel | ✗ Negativ-Beispiel (Fehlerursache) |
 |---|---|---|
 | §4.1 `type` Pflicht (§3.1) | `type: concept` | `type:` (leer) → Punkt 1 |
 | §4.1 Feldsubset (§3) | nur `type`, `sources`, `generated` | `foo: bar` → Punkt 6 |
 | §4.2 `sources[].resource` → `raw/` (§3.3, AD-4b) | `resource: raw/prd/prd-wow20-2026-08-14.md` | `resource: wiki/foo.md` → Punkt 3 |
 | §4.2 Path-Grammatik (§3.3, Punkt 4) | `/`-getrennt, relativ, unter `raw/` | `resource: ../outside.md` → Punkt 4 |
 | §4.2 EC-1-Existenz (§3.3, §6.2) | `resource: raw/prd/prd-wow20-2026-08-14.md` (Datei existiert) | `resource: raw/fehlt.md` → EC-1 |
 | §4.3 `generated.by` Pflicht (§3.4) | `generated: {by: wow-compiler/0.1.0, at: …}` | `generated: {at: …}` (ohne `by`) → Punkt 7 |
 | §4.3 `generated.at` volles ISO-8601-Datetime (§3.4, Validator §4.3) | `at: 2026-08-16T09:23:33Z` | `at: 2026-08-16` (reines Datum) → Punkt 14 |
 | §4.3 `verified` ungesetzt (A0-20) | (kein `verified`) | `verified: {by: human:x, at: …}` → Punkt 6 (unautorisiertes Feld, nur maschinelle Erzeugung A0-20), hier nicht erzeugt |
 | §4.4 canonical Key-Reihenfolge (Validator §4.1) | `type` → `sources` → `generated` | Reihenfolge `generated` vor `type` → Normalform-Abweichung (kein FAIL, aber nicht erzeugt) |
 | §4.4 keine Duplikat-Keys (Punkt 13) | jeder Key einmal | zweimal `type:` → Punkt 13 |
 | §4.4 `sources`-Eintrag-Key-Subset (Vertrag §3.3) | nur `resource`, `id`, `title`, `author`, `usage_count`, `last_modified` | `resource …` + z. B. `role: x` → Punkt 6 (unautorisiertes Feld, Innen-Ebene) |
 | §4.4 kein `okf_version`/`type: bundle` (Punkt 9) | (nicht vorhanden) | `okf_version: "0.2"` → Punkt 9 |
 | §5.1 Root-Pfad & Verlinkung (Punkt 11, §6) | `wiki/<slug>.md` + Link in `wiki/index.md` | Concept ohne Link in `index.md` → Punkt 11; `wiki/<area>/<slug>.md` → Bereichs-Hinweis (Story 2.4) |
 | §5.4 `log.md`-Dokumentation (§5) | datumsgruppierter Eintrag mit Concept-Pfad + Quellen | fehlender Eintrag → kein Validator-FAIL, aber dokumentarische Pflicht verletzt |
 | §6.4 Allen-Pfad-Formen-Vermeidung (Punkt 4) | `/`-getrennt, relativ, unter `raw/` | `..`-Traversal, führendes `/`, Backslash (`raw\foo.md`), URL-Form (`https://…`) → Punkt 4 |
 | §7 Selbstbegrenzung (kein Standalone, D-3) | rein textuelle Instruktion | Code-/Executable-Abschnitt → D-3-Verstoß |
 Interpretations-Hinweis: Die „✗"-Zeilen zeigen die deterministische Fehlerursache, die der Validator (Story 1.4) für die jeweilige Abweichung ausgibt. Die „✓"-Zeilen sind die Vorgabe, unter der ein neu erzeugtes Concept den Run passieren kann — genau diese Form wurde im Demonstrationslauf (2026-08-16) gegen alle 3 erzeugten Concepts erfüllt.
 ## 7. Selbstbegrenzung (Scope der Instruktion)
 Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begrenzt. Folgendes verbleibt in anderen Stories und wird hier **nicht** vorweggenommen:
 - **Claim-granulare Provenienz** je belegter Aussage (Inline-`raw/`-Verweise, Kontext-Marker) → Story 2.2 (AD-4a, A0-3).
 - **Deterministische Area-Zuordnung & Concept-Hierarchie** (Anlage von `wiki/<area>/index.md` + `wiki/<area>/<concept>.md`) → Story 2.4 (AD-7c, A0-10).
 - **Progressive Discovery über `index.md`** (Navigation, Area-Indizes, Suche) → Story 2.5 (AD-9, FR-11).
 - **Eine genau-eine-Linkform** (mit/ohne `.md`-Endung) → Story 2.3 (AD-7b, A0-9) — der Punkt-11-Check akzeptiert beide Schreibweisen.
 - **Aktualisierung bestehender Concepts** (Erweitern/Präzisieren/Korrigieren) und **Synthese über mehrere Concepts** → Epic 3 (AD-5, FR-6/FR-7).
 - **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").
 ## 8. Normreferenzen & Revisionslog
 **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 6): §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).
 - Architektur-Spine (raw/`architecture-spine`): AD-2/AD-3 (raw immutable), AD-5 (inkrementelle Kompilation), AD-6 (Reason/Mutate-Trennung), AD-7a (Identität = OKF-Pfad ohne `.md`), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-15 (Trust-Metadaten v1), 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), A-4 (nur lokale Sources).
 - Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5.
 **Revisionslog:**
 - **Revision 1 (2026-08-16):** Erstes abgeleitetes Artefakt — Concept-Erzeugung als deterministische Instruktion: Input-Grenzen (§1), Interpretieren (Wissenseinheiten, kein 1:1/keine Kopie, §2), Reconcile (Kollision-Hold, §3), Synthetisieren (Frontmatter-Normalform, §4), Mutieren (Root-Ebene + Index-Regel + log.md, §5), Validieren (Validator-SUCCESS als Erfolgsbedingung, §6), Selbstbegrenzung (§7).
 - **Revision 1.1 (2026-08-16):** Nach dem Demonstrationslauf ergänzt — §6.5 Determinismus- & Selbsttest-Norm (drei Nachprüf-Kriterien: §3-Subset-Konformität, `at`-Normalform, `sources`-Existenz; AD-17h-konform) und §6.6 Positiv-/Negativ-Beispiele (Referenztabellen je Erzeugungsregel mit deterministischer Fehlerursache). Revisionslog (§8) nachgeführt; §6-Nummerierung angepasst.
 - **Revision 1.2 (2026-08-16, Step-04-Review):** Nachschärfungen aus dem Story-2.1-Review — Input-Regel korrekt auf AD-17a statt AD-17.2 referenziert (§1); `sources`-Eintrag-Key-Subset (Innen-Ebene, Vertrag §3.3) in §4.2 und als §6.5-Kriterium-1 / §6.6-Tabellenzeile ergänzt; `status`-Absenz-Formulierung an die Vertrags-Definition (Absenz = `stable`, §3.6) angebunden (§4.4); Klarstellung Bereichs-Ziele bis Story 2.4 (§5.1/§6.6); §6.6-Fehlerursache der `verified`-Zeile auf Punkt 6 korrigiert; §6.6-Referenzlabel von §4.5 auf §4.4 korrigiert; §6.6 um vollständige Punkt-4-Pfad-Verbote ergänzt; AD-17f als Commit-Boundary in §0/§5.3/§6.6 sichtbar gemacht.
@@ -259,7 +259,7 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
 ### 7.3 §6-Fachliche-Zusatzprüfungen-Fixtures (EC-1, EC-3, WARN, EC-11)
-> Diese Prüfungen sind keine §7-Punkte (Fachliche Prüfungen, §6). Für Negativ-Fixtures gilt dasselbe Isolations-Prinzip wie in §7.1: jedes Sample ist sonst-valide (die 14 Punkte passieren), sodass genau die jeweilige §6-Prüfung auslöst.
+> Diese Prüfungen sind keine §7-Punkte (Fachliche Prüfungen, §6). Für Negativ-Fixtures gilt dasselbe Isolations-Prinzip wie in §7.1: jedes Sample ist sonst-valide (die 14 Punkte passieren), sodass genau die jeweilige §6-Prüfung auslöst. Das Isolations-Prinzip gilt entsprechend auch für Punkt-6-Fälle auf Innen-Ebenen (`sources`/`generated`/`verified`-Einträge): Ein unautorisierter Key innerhalb eines Eintrags (z. B. `sources:\n  - resource: …\n    role: x`) ist strukturell invalide und löst Punkt 6 aus (vertraglich §3.3–§3.5), losgelöst von der §6-Formprüfung.
 | # | Fixture (Input) | Erwartetes Verdikt |
 |---|-----------------|--------------------|
@@ -303,3 +303,4 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
 - **Revision 4 (2026-08-16):** §6-Fixtures ergänzt (Retrospective F-02, AI-2) — neue Tabelle §7.3 belegt die fachlichen Zusatzprüfungen §6: EC-1-Existenz (Positiv/Negativ/Verzeichnis/Aggregation), EC-3-Kalender-Validität (Positiv/Negativ), §6.4-`stale_after`-WARN (veraltet/nicht veraltet), EC-11-`non-md` (Ignoranz). §6.1/§6.3/§6.4/§6.5 tragen Verweise auf §7.3; §7-Einleitung nennt §6-Fixtures als eigene Sektion. Zertifizierung in `wiki/log.md` (2026-08-16) nachgeführt.
 - **Revision 5 (2026-08-16):** §3.2-Voraussetzungsprüfungen als fachliche Prüfklasse V-1/V-2 gelabelt (Retrospective F-03, AI-3) — Verdikt-Präfix ändert sich von `FAIL (Struktur) …` auf `FAIL (Voraussetzung) … (V-1|V-2, …)`; §5-Verdikt-Grammatik und §5.1-Selbstbegrenzung um die V-1/V-2-Abgrenzung ergänzt (fachliche Prüfklassen verlassen die Abschluss-Eigenschaft des §7-Katalogs nicht); §7.1-Fixtures 8a/10a an die V-1/V-2-Sprache angeglichen; §7.3 um V-1/V-2 (Positiv/Negativ, 4 Zeilen) erweitert; §3.2 erhält ein erklärendes `<details>` (Warum V-1/V-2, Verweis auf F-03/AI-3). Vertrag `schema/wiki-compiler.md` unverändert (keine Autorisierung nötig).
 - **Revision 6 (2026-08-16):** BOM-/Leerzeilen-Stripping vereinheitlicht (Retrospective F-05, AI-5) — die gemeinsame Definition „gestrippte Frontmatter-Erkennung" (§3-Präambel: UTF-8-BOM `U+FEFF` + führende Leerzeilen vor dem `---` entfernen) gilt jetzt für alle Frontmatter-erkennenden Punkte **2, 8 und 10** (zuvor nur Punkt 10). Punkt 2/8-Prüfschritt-Zellen verweisen auf §3-Präambel; Punkt 10 rückverweist darauf. Neue Positiv-Fixtures: 2a (Concept mit BOM/Leerzeile vor Frontmatter → SUCCESS) und 8b (Bundleroot mit BOM/Leerzeile vor Frontmatter → SUCCESS). Zusätzlich zwei Defer-Verweise als „offene Punkte" (§1 Punkt 3 zu `.MD`-Großschreibung, F-08; §6.4 zu `today`-Zeitzone, F-06) eingebettet — Defer-Kontexte aus AI-7. Vertrag unverändert.
 - **Revision 7 (2026-08-16, Step-04-Review Story 2.1):** §7.3-Fixture-Isolations-Hinweis um Innen-Ebenen-Key-Subset-Fälle erweitert — die Punkt-6-Formprüfung gilt nicht nur für Top-Level-Frontmatter-Felder, sondern auch für unautorisierte Keys innerhalb von `sources`/`generated`/`verified`-Einträgen (Vertrag §3.3–§3.5); Konsequenz für Fixture-Isolation (sonst-valide und nur der Innen-Ebenen-Key sticht Punkt 6 hervor) dokumentiert (§7.3). Vertrag `schema/wiki-compiler.md` unverändert (keine Autorisierung nötig, nur dokumentarische Klarstellung der bestehenden Punkt-6-Regel).
@@ -20,6 +20,13 @@ wiki/
 ```
 - **`log.md`** — reserviertes Protokoll des Bundles: dokumentiert fachliche Änderungen und Disagreements (AD-16b) und ist Teil der Lease-Root-Scope (AD-17b). Typdefinition folgt im Schema-Vertrag (Story 1.3).
 - Noch keine Areas vorhanden — dieses Bundle wird in späteren Epics inkrementell gefüllt.
-Der Workspace umfasst außerdem: `raw/` (immutable Source Material/Evidenz, AD-2/AD-3), `schema/` (Compiler-Schema-Vertrag, AD-1) und `adapters/` (dünne Agenten-Adapter, AD-10).
+## Concepts
 Die folgenden Root-Concepts wurden im ersten Demonstrationslauf (Story 2.1) aus dem Source Material unter `raw/` erzeugt:
 - [LLM-Wiki-Prinzip](llm-wiki-prinzip.md) — konzeptioneller Anker: Rohquellen werden von einem LLM in ein persistentes, kuratiertes Wiki überführt (aus `raw/prd/prd-wow20-2026-08-14.md`).
 - [Knowledge Compilation & Inkrementelle Evolution](knowledge-kompilation-inkrementell.md) — inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update (aus `raw/epics/epics-2026-08-14.md`).
 - [Wissensarchitektur: Source Material, Curated Knowledge & Consumer](wissensarchitektur-trennung-states.md) — die Architekturgrenzen `raw/` (immutable Evidenz) und `wiki/` (kuratiertes Bundle) (aus `raw/architecture-spine/architecture-spine-2026-08-14.md`).
 Der Workspace umfasst außerdem: `raw/` (immutable Source Material/Evidenz, AD-2/AD-3), `schema/` (drei Artefakte: Schema-Vertrag [`wiki-compiler.md`](../schema/wiki-compiler.md) (autorisiert, AD-1), Validator [`validator.md`](../schema/validator.md) (Story 1.4) und Compiler-Instruktion [`compiler.md`](../schema/compiler.md) (Story 2.1)) und `adapters/` (dünne Agenten-Adapter, AD-10).
@@ -0,0 +1,47 @@
 ---
 type: concept
 sources:
  - resource: raw/epics/epics-2026-08-14.md
 generated:
  by: wow-compiler/0.1.0
  at: 2026-08-16T09:23:33Z
 ---
 # Knowledge Compilation & Inkrementelle Evolution
 Wiki of Wikis ist ein inkrementeller Knowledge Compiler: Er verarbeitet Sources gegen das bestehende kuratierte Wissen und entwickelt das Knowledge Bundle fortlaufend weiter, statt es bei jedem Lauf vollständig neu zu erzeugen.
 ## Grundprinzip des Datenflusses
 Jeder Compilation Run beginnt mit dem aktuell vorhandenen Knowledge Bundle und verändert nur die durch neue Erkenntnisse betroffenen Concepts (AD-5). Der logische Datenfluss lautet:
 ```text
 Existing Knowledge
       +
 New Source Material
       ↓
 Interpret
       ↓
 Reconcile
       ↓
 Synthesize
       ↓
 Update affected Concepts
 ```
 Ausdrücklich nicht verwendet wird ein „Regenerate Everything"-Ansatz, bei dem alle Sources und das komplette Wiki bei jedem Lauf neu erzeugt würden — das würde den Compounding-Effekt des Wissens zerstören.
 ## Folgen für die Fähigkeiten
 - **Inkrementelle Evolution (FR-12):** Unverändertes Wissen bleibt erhalten; Änderungen konzentrieren sich auf durch neue Erkenntnisse betroffene Concepts.
 - **Aktualisierung statt neuer Dateien (FR-6):** Neue Informationen führen nicht automatisch zu neuen Dateien — bestehendes Wissen wird erweitert, präzisiert oder korrigiert.
 - **Konsistenz bei Fehlern (AD-6):** Analyse, Änderungsplanung, Mutation und Validierung sind logisch getrennt; ein teilweise fehlgeschlagener Run hinterlässt kein inkonsistentes Bundle.
 - **Nachvollziehbarkeit (FR-14):** Änderungen erfolgen an textuellen Artefakten und sind über normale Versionskontrolle (Git-Diff) nachvollziehbar.
 ## Verbindung zu Regelwerken
 Die Inhaltsklassifikation vor jeder Änderung (NEW / CONFIRMING / CORRECTING / CONTRADICTING / REDUNDANT) und die deterministische Relevanzbestimmung per textueller, deterministischer Mittel (grep/ripgrep, Markdown-Traversal, Link-Following) sind Teil der inkrementellen Kompilation.
 ## Abgrenzung
 Die inkrementelle Kompilation (Interpret → Reconcile → Synthesize → Update) ist die Grundlage von Epic 3. Epic 2 liefert dafür die Voraussetzungen: Concepts, Verlinkung und Area-Hierarchie.
@@ -0,0 +1,41 @@
 ---
 type: concept
 sources:
  - resource: raw/prd/prd-wow20-2026-08-14.md
 generated:
  by: wow-compiler/0.1.0
  at: 2026-08-16T09:23:33Z
 ---
 # LLM-Wiki-Prinzip
 Das LLM-Wiki-Prinzip ist der konzeptionelle Anker von Wiki of Wikis. Es beschreibt, wie Rohquellen durch ein LLM schrittweise in ein persistentes, kuratiertes Wiki überführt werden — statt bei jeder Anfrage erneut nach Rohdokumenten zu suchen und sie neu zu interpretieren.
 ## Kernidee: Knowledge should compound
 Das zentrale Produktversprechen lautet: **Knowledge should compound.** Einmal erarbeitete Synthese wird dauerhaft in einem kuratierten Wiki abgelegt und muss bei späteren Anfragen nicht erneut aus den Rohquellen rekonstruiert werden. Das Wiki entwickelt sich mit neuen Quellen weiter und bildet das bereits erarbeitete Wissen fortlaufend ab.
 ## Positionierung: Knowledge Compiler statt Retrieval-System
 Wiki of Wikis ist primär ein **Knowledge Compiler**, kein Retrieval-System. Es sammelt und indiziert nicht nur Dokumente, sondern verarbeitet Quellen aktiv: lesen, verstehen, in Beziehung setzen und eigenständige Wissensartikel erzeugen. Neue Quellen werden gegen das vorhandene Wiki verarbeitet; vorhandenes Wissen kann dadurch bestätigt, erweitert, präzisiert oder korrigiert werden.
 ## Datenfluss
 ```text
 Sources
   │
   ▼
 LLM Wiki Compiler
   │
   ▼
 Curated OKF Wiki
   │
   ▼
 Humans / LLM Agents / BMAD / Coding Agents / other Consumers
 ```
 Das Ergebnis ist ein einfaches, portables Knowledge Bundle aus Markdown-Dateien, das weder eine spezielle Datenbank noch eine proprietäre Knowledge-Plattform benötigt.
 ## Abgrenzung
 Retrieval (Suche, RAG, Graph-Traversal) ist ausdrücklich nicht Bestandteil des Produktkerns. Ein Consumer kann solche Verfahren später über dem Knowledge Bundle einsetzen — sie gehören jedoch nicht zu Wiki of Wikis selbst.
@@ -1,6 +1,8 @@
 # Log
 ## 2026-08-16
 - Step-04-Review (Story 2.1): Nachschärfungen aus den drei Review-Layern (Blind Hunter, Edge Case Hunter, Verification Gap) angewendet — `schema/compiler.md` auf Revision 1.2 (Input-Regel auf AD-17a referenziert statt AD-17.2, `sources`-Eintrag-Key-Subset in §4.2/§6.5/§6.6 ergänzt, `status`-Absenz an Vertrag §3.6 angebunden, Bereichs-Ziel-Klarstellung bis Story 2.4, §6.6-Fehlerursachen korrigiert, AD-17f als Commit-Boundary sichtbar), `schema/validator.md` auf Revision 7 (§7.3-Isolations-Hinweis auf Innen-Ebenen-Key-Subset erweitert), `wiki/index.md`-Workspace-Absatz korrigiert (`schema/` = drei Artefakte: Vertrag, Validator, Compiler), `sprint-status.yaml`: Story 2.1 → `review` (Review begonnen). `at`-Zeitstempel der drei Concepts (`2026-08-16T09:23:33Z` = 11:23:33 Lokalzeit +0200) decken sich mit den Datei-Mutationszeitpunkten (11:24) — im Review geprüft.
 - Story 2.1 (Demonstrationslauf): drei neue Root-Concepts aus dem Source Material unter `raw/` erzeugt und in `wiki/index.md` verlinkt — `wiki/llm-wiki-prinzip.md` (aus `raw/prd/prd-wow20-2026-08-14.md`), `wiki/knowledge-kompilation-inkrementell.md` (aus `raw/epics/epics-2026-08-14.md`), `wiki/wissensarchitektur-trennung-states.md` (aus `raw/architecture-spine/architecture-spine-2026-08-14.md`). Trust-Metadaten gemäß A0-20: `generated { by: wow-compiler/0.1.0, at: <ISO-8601-Datetime> }`, `verified` ungesetzt. `schema/compiler.md` (Revision 1) als deterministische Compiler-Instruktion angelegt.
 - Retrospective-Follow-up (AI-1/F-01): `schema/validator.md` auf Revision 3 — `at`-Nur-Datum-Toleranz zurückgenommen. `at: 2027-01-01` ist jetzt FAIL nach Punkt 14 (reine Datumsangabe ≠ ISO-8601-Datetime); Positiv-Fixture 14c neu mit `±HHMM`-Form (`+0200`) belegt. Vertrag `schema/wiki-compiler.md` unverändert (autorisiert). Validator-Zertifizierung zugehörig geprüft: Fixture 14c (Negativ) erzeugt FAIL.
 - Retrospective-Follow-up (AI-2/F-02): `schema/validator.md` auf Revision 4 — neue Fixture-Tabelle §7.3 für die §6-Fachprüfungen (EC-1 Existenz, EC-3 Kalender, stale_after-WARN, EC-11 non-md). Zertifizierung gegen erweiterte Fixtures selbstgeprüft — Ergebnis: PASS (je §6-Fixture isoliert geprüft, genau die angesprochene Prüfung löst aus; EC-1/EC-3-FAILs sind Run-FAIL, WARN ist Berichtskanal, non-md wird ignoriert ohne Verdikt).
 - Retrospective-Follow-up (AI-3/F-03): `schema/validator.md` auf Revision 5 — §3.2-Voraussetzungsprüfungen als fachliche Prüfklasse V-1/V-2 gelabelt (Verdikt `FAIL (Voraussetzung) … (V-1|V-2)` statt `FAIL (Struktur)`), §5-Grammatik/Selbstbegrenzung sowie §7.1/§7.3-Fixtures angeglichen. Zertifizierung: V-1/V-2-Fixtures selbstgeprüft — PASS (isolierte Auslösung; kein §7-Punkt-Nr.-Konflikt).
@@ -0,0 +1,44 @@
 ---
 type: concept
 sources:
  - resource: raw/architecture-spine/architecture-spine-2026-08-14.md
 generated:
  by: wow-compiler/0.1.0
  at: 2026-08-16T09:23:33Z
 ---
 # Wissensarchitektur: Source Material, Curated Knowledge & Consumer
 Die Architektur von Wiki of Wikis trennt drei Verantwortungsbereiche, die nie vermischt werden dürfen: Quellen, Kompilation und kuratiertes Wissen mit seinen Konsumenten (AD-2, AD-3, AD-1).
 ## Die Architekturgrenzen `raw/` und `wiki/`
 - **`raw/` — immutable Source Material/Evidenz:** Jede Datei unter `raw/` ist Evidenz. Ein Compilation Run darf bestehendes Source Material niemals verändern (AD-3); neue Versionen einer Source werden als neue beziehungsweise versionierte Source behandelt.
 - **`wiki/` — kuratiertes OKF Knowledge Bundle:** Jede Datei unter `wiki/` ist eine aus Evidenz abgeleitete Wissensrepräsentation. Das Bundle ist der kanonische persistente Zustand des Systems (AD-1).
 Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Kompilation.
 ## Separation of Concerns
 ```text
 Sources  →  Compilation  →  Knowledge Bundle  →  Consumers
 ```
 - Eine Source darf nicht automatisch Teil des Curated Knowledge werden.
 - Ein Consumer darf nicht zur Voraussetzung für Kompilation oder Speicherung werden.
 - Der Compiler ist ein Producer des Bundle-Artefakts — kein Wissensserver und keine eigene Agent-Runtime (AD-11).
 ## Consumer-Unabhängigkeit
 Das Knowledge Bundle ist nicht auf einen bestimmten LLM-Agenten oder Workflow zugeschnitten (FR-16). Menschen lesen es mit normalen Markdown-Werkzeugen; Agenten wie BMAD, Claude Code oder Codex über Standard-Dateioperationen. Ein Wechsel des Consumers erfordert keine Migration des Wissensformats.
 Retrieval (Search, RAG, Graph-Traversal) ist Consumer-Verhalten, nicht Kern des Compilers (AD-13).
 ## Konvergenzregeln
 | Betrachtet | Quelle |
 |---|---|
 | Canonical evidence | `raw/` bzw. referenzierte externe Source |
 | Canonical knowledge | `wiki/` |
 | Discovery | Hierarchie + `index.md` |
 | Update history | Git + optional OKF `log.md` |