Merge pull request 'Story 2 2' (#1 ) from story-2-2 into main

Reviewed-on: #1
feat: Story 2.2 bmad-code-review abgeschlossen (Rev 1.7) — done
2026-08-17 09:28:35 +00:00 · 2026-08-17 11:23:59 +02:00 · 2026-08-17 09:37:33 +02:00
10 changed files with 322 additions and 37 deletions
@@ -187,3 +187,24 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - summary: **2. Innen-Ebenen-Punkt-6-Fixture-Zeile ergänzen** — die in Rev 8 formalisierte Innen-Ebenen-Regel (Punkt 6: unautorisierte Keys in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) hat keine Fixture-Zeile in §7.1/§7.3; der einzige Punkt-6-Fixture ist Top-Level `foo: bar`, §7.3 zeigt `sources … role: x` nur als Inline-Prosa-Beispiel. In der autorisierten Revision eine Negativ-Fixture-Zeile (z. B. `sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei → `FAIL … Punkt 6`) ergänzen + Zertifizierung (isoliertes Sample) + Nachweis in `wiki/log.md` nachführen.
  evidence: bmad-code-review Re-Run (2026-08-17) — Blind Hunter + Verification-Gap; beides betrifft die gefrorene Rev 8.
  status: offen — Home: nächste autorisierte Validator-Revision (Rev 9), Validator-Kanal; **kein Story-2.1-Blocker** (Story bleibt `review`, `done`-fähig; verbleibende Schwelle = Human-Review). Verknüpft mit Action-Item `code-review-2-1-item-2`.
 ## Deferred from: code review of story-2.2 (2026-08-17)
 > **Step-04-Review (Story 2.2, 2026-08-17):** Von der Verification-Gap-Schicht als Defer klassifizierter Befund — kein Story-2.2-Blocker, da die Story die Markierungs-Syntax liefert und nicht die inhaltliche/kleine Closure-Verifikation.
 - source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: Sources-Closure-Verifikation einführen — jeder inline-referenzierte `raw/`-Pfad eines Concept-Bodies (per deterministischer Extraktion aus `(raw/…`-Verweisen) MUSS im `sources`-Frontmatter desselben Concepts deklariert sein (inkl. neuer `sources`-Einträge für Relokation/Zielwechsel, §5.5-Pkt.-1b-Regel). Aktuell prüft nur der `grep -nE '\(raw/'`-Existenz-Smoke die Präsenz des Verweises, nicht seine Zuordnung zu einer deklarierten Ressource; EC-1 prüft nur die deklarierten `sources`-Ressourcen, nicht inline-referenzierte. Ein inline-Verweis auf eine nicht deklarierte `raw/`-Datei (Beispiel im Story-2.2-Body behoben) bliebe sonst unsichtbar.
  evidence: Verification-Gap-Review (Story 2.2): Demonstriert an `wiki/wissensarchitektur-trennung-states.md` (Consumer-Unabhängigkeit zitierte `raw/epics/…` ohne `sources`-Deklaration — im Story-2.2-Patch behoben); kein re-runnable Check deckt die Abgeschlossenheit ab (D-3-konforme Deterministische Closure-Prüfung, analog grep-Pipeline, kein Standalone).
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde (Rev 9-Kandidat), Validator-/Instruktions-Kanal; **kein Story-2.2-Blocker** (Story liefert die Markierungs-Syntax, nicht die Closure-Prüfung).
 - source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: **Stellen-Kennung-Existenz im Rohdokument wird nirgends geprüft** — §5.5 Pkt.1 macht die Existenz des `#`-Fragments im referenzierten Rohdokument zur harten Regel (ganzer Sinn der s1/s2-Korrektur), aber kein Check verifiziert sie: nicht der strukturelle Validator (keiner der 14 Punkte liest Fragment-Targets), nicht die Spec-Verification-Greps (nur `(raw/`-Präsenz), nicht die Selbsttest-Formel. Fragment-Typo (z. B. `#FR-19`) oder verbotenes Concept-`id`-Fragment `#s1` durchläuft den gesamten Pfad mit SUCCESS und liefert genau die Falsch-Attribution, die die Regel verhindern soll (Worked-Example-Grammatik ungeprüft). D-3-konforme deterministische Prüfung (Fragment tritt als Zeilenanker/Sektionstitel in `raw/<pfad>` auf; Negativ: kein `^s[0-9]+$`-Fragment), Schwester zu W1.
  evidence: Verification-Gap-Review (bmad-code-review Story 2.2, 2026-08-17): Validator-14-Punkte-Katalog + EC-1 im Volltext gelesen (keine Fragment-Auflösung); alle aktuellen Fragmente der drei Concepts händisch gegen `raw/` verifiziert (alle auflösen) — aber nichts pinnt es; Demonstrationsfall `…(raw/epics/…md#FR-19)` → SUCCESS.
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde (Rev 9-Kandidat), Schwester zu W1; **kein Story-2.2-Blocker**.
 - source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: **Kontext-Marker-Grammatik (Selbstreferenz-Verbot, Musterwahl, exakter Token-Platz) ungeprüft** — §5.5 Pkt.2 definiert die Marker-Muster mit obligatorischem exaktem Token „nicht eigenständig belegt" und das neue Selbstreferenz-Verbot (Rev 1.6); der Lauf-Gate-Selbsttest (Pkt.4) und die Spec-Manual-Checks behaupten nur Token-Präsenz, nicht die Musterform oder das Selbstreferenz-Verbot. Ein Selbstreferenz-Marker (Concept nennt sich selbst als Ursprung) trägt den exakten Token und passiert jede re-runnable Prüfung mit SUCCESS — das Verbot ist durch nichts erzwingbar. Demonstrationsfall `übernommen aus wiki/<eigenes-Concept> auf Basis von raw/epics/… nicht eigenständig belegt` → SUCCESS. D-3-konforme Prüfung (Token pro Concept extrahieren, Pattern-Match gegen die kanonischen Formen, `<Concept-Pfad>` gegen eigenen OKF-Pfad vergleichen), Schwester zu W1.
  evidence: Verification-Gap-Review (bmad-code-review Story 2.2, 2026-08-17): Punkt 9-Inhaltsscan prüft nur `okf_version`/`type: bundle`; die drei aktuellen Marker-Stellen (`knowledge-kompilation:37,52`, `llm-wiki-prinzip:40`, `wissensarchitektur:30`) konform gelesen — aber nichts pinnt die Grammatik; die Pre-Patch-Selbstreferenz (Klassifikation P5) beweist, dass der Fehler nur durch Review-Lesbarkeit, nicht durch re-runnable Checks auffindbar war.
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde, Schwester zu W1; **kein Story-2.2-Blocker**.
 - source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: **`sources`-`id`-Eindeutigkeit je Concept ohne Check und ohne Selbsttest-Hook** — §5.5 Pkt.3 führt die Regel „`id`-Werte je Concept eindeutig" ein und wird in allen drei Concepts angewendet (neue `id: s1`/`s2`), aber Validator Punkt 6 prüft Keys (nicht Wert-Duplikate), Punkt 13 nur Top-Level-Frontmatter-Duplikate, die Spec-Greps prüfen Feldpräsenz/`resource`-Werte, und §5.5 Pkt.4 (Selbsttest-Kriterien) führt die id-Eindeutigkeitsregel gar nicht auf. Duplizierte `id`-Werte (z. B. beide `s1` in `knowledge-kompilation:4-7`) liefern SUCCESS. D-3-konforme Prüfung (kein `sources[].id`-Wert tritt im selben File doppelt auf) + Eintrag in §5.5 Pkt.4, Schwester zu W1.
  evidence: Verification-Gap-Review (bmad-code-review Story 2.2, 2026-08-17): Punkt 6/13 im Volltext gelesen; Demonstrationsfall beide Einträge `id: s1` → alle Punkte + Greps SUCCESS.
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde, Schwester zu W1; **kein Story-2.2-Blocker**.
@@ -0,0 +1,31 @@
 # Review-Klassifikation Story 2.2 (Step-04-Review, 2026-08-17)
 > Drei Review-Layer (Blind Hunter, Edge Case Hunter, Verification Gap) auf dem Stand des Story-2.2-Diffs (baseline `bb32acd`, tracked + untracked Spec). Klassifikation gemäß step-04-review.md: dedupliziert, Severity-Einstufung durch den Workflow (Reviewer-Severity verworfen), Triage. **Kein** `intent_gap`, **kein** `bad_spec` → kein Loopback; Story-2.2-Problem = `patch` + `defer`.
 ## Triage-Ergebnis (dedupliziert, je Kern-Finding)
 | # | Befund (Kern) | Quelle | Severity | Kategorie | Behandlung |
 |---|---|---|---|---|---|
 | P1 | §5.5-Widerspruch „kein Frontmatter-Change" vs. tatsächliche `sources`-/`id`-Hinzufügungen | BH-1 | medium | patch | §5.5-Klarstellung (schema/compiler.md) |
 | P2 | §5.5 `#<id>`-Fragment-Semantik: sources-`id` (s1/s2) existiert nicht im Rohdokument; `<pfad>#<id>`-Form teilweise ohne Gültigkeit | BH-2, BH-6, VG-3 | medium | patch | Inline-Verweis-Form präzisieren (Stellen-Kennung, volle Pfade, kein sources-`id`-Fragment) |
 | P3 | Body: `§0 Dokumentzweck` vs. englischer PRD-Titel; `#s1`/`#s2`-Fragmente; Pfad-Elision `#A0-6` ohne Pfad | BH-3, VG-3 | medium | patch | llm-wiki-prinzip + wissensarchitektur Body-Fixes |
 | P4 | `wissensarchitektur`::FR-16-Verweis zitiert `raw/epics/…` **ohne** `sources`-Deklaration → Relokations-Regel §5.5 Pkt. 1b verletzt (widerspricht dem eigenen Diff) | VG-1, VG-2 | high | patch | FR-16-Beleg auf PRD §4.5 allein; epics-Verweis entfernen |
 | P5 | Kontext-Marker: Selbstreferenz (Concept nennt sich als Ursprung); Direkt- übernahme-aus-raw Fall fehlt; Forward-Referenz-Wortlaut weicht von §5.5 ab | BH-5, VG-4, EC-3 | medium | patch | Marker-Grammatik + Body-Marker anpassen |
 | P6 | Kein worked example; §5.5-Pkt.-1„zulässig beide / erkennbar"-Unbestimmtheit gegen AD-17h-Grep | BH-3, BH-13 | medium | patch | §5.5: Grep-Formel `\(raw/|\]\(raw/`, verbindliche Default-Form, worked example |
 | P7 | `wiki/log.md` Eintrag: `#s2`-Fragment + Quell-Deklarations-Wortlaut (wissensarchitektur-Diagramm) an die korrigierten Markers angleichen | (VG-3 Ableitung) | low | patch | log.md-Nachführ-Eintrag minimal reinigen |
 | D1 | Sources-Closure-Verifikation (jeder inline-referenzierte `raw/`-Pfad ⊆ `sources`) — kein re-runnable Check (D-3-konform) | VG-1/VG-2 | medium | defer | deferred-work.md, Abschnitt „Deferred from: code review of story-2.2 (2026-08-17)" |
 ## Rejects (Rauschen, still verworfen)
 - **BH-8** (Status-Inkonsistenz Spec `in-review` vs. sprint-status `in-progress` vs. log `SUCCESS`) — normaler Workflow-Fluss (Review beginnt, Story bleibt bis `done` `in-progress`; log ist Lauf-Protokoll). **reject**.
 - **BH-14** (index.md-Vereinfachung der Konzept-Beschreibung) — bewusst vereinfachtes Discovery-Niveau; kein Konflikt mit claim-granularer Provenienz der Bodies. **reject**.
 - **BH-15** (I/O-Matrix unvollständig) — Scope-/Frozen-Entscheidung (nur 2 Szenarien in der Approve-Baseline); kein bad_spec. **reject**.
 - **VG-5** („A0-7 orphan") — **widerlegt** durch Faktencheck: `A0-7` existiert in `raw/epics/epics-2026-08-14.md` (Zeile 55, Bezeichner `- **A0-7 — Reason/Mutate-Trennung (AD-6):**`). Der Verweis `raw/epics/…md#A0-7` in `knowledge-kompilation-inkrementell.md` ist korrekt. **reject**.
 ## Patches an den Implementierungs-Subagenten (Kontext intakt, synchron)
 Die patch-Findings P1–P7 wurden dem Step-3-Implementierungs-Subagenten als vollständiges Paket gesendet (Datei, Defekt, Fix-Anforderung; deutsche Ausgaben; Re-Run der Spec-Verification). Danach: erneute Verifikation aller Checks.
 ## Verifikations-Hinweis
 Der Validator (`schema/validator.md`) ist eine reine Text-Instruktion (D-3, kein CLI). „Validator-Lauf: alle 5 wiki/-Dateien SUCCESS" ist die human/manuell-mechanische Ausführung der §3-/§6-Regeln. Dies entspricht der etablierten Konvention (Story 1.4/2.1).
@@ -0,0 +1,158 @@
 ---
 title: 'Claim-granulare Provenienz dokumentieren (Story 2.2)'
 type: 'feature'
 created: '2026-08-17'
 status: 'done'
 review_loop_iteration: 2
 baseline_commit: bb32acdf3f1a3547424da0f878bd06383921b22a
 context:
  - _bmad-output/implementation-artifacts/epic-2-context.md
 ---
 <frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
 ## Intent
 **Problem:** Die drei Concepts aus Story 2.1 tragen Provenienz nur auf Concept-Ebene (`sources`-Frontmatter); belegte Aussagen und Kontext-/Synthese-Umformulierungen sind claim-granular nicht auf `raw/`-Evidenz rückführbar (AD-4a, A0-3). Instanz: `knowledge-kompilation-inkrementell.md` deklariert nur `raw/epics/…`, enthält aber ein ASCII-Diagramm aus `raw/architecture-spine/…`.
 **Approach:** `schema/compiler.md` um Sektion „Claim-granulare Provenienz" erweitern (Inline-`raw/`-Verweise je belegter Aussage, Kontext-Marker je Übernahme, `id`-Attribution aus Vertrag §3.3) und die drei Concepts + `wiki/index.md` + `wiki/log.md` nachkonformieren. Kein Standalone-Tool, keine neue §7-Klasse, keine Vertragsänderung.
 ## Boundaries & Constraints
 **Always:**
 - Provenienz = Body-Text-Konvention (Inline-`raw/`-Verweis je belegter Aussage; Kontext-Marker „übernommen aus `<Concept-Pfad>` auf Basis von `<source>`, nicht eigenständig belegt" je Übernahme — AD-4a/A0-3). Kein Frontmatter-Change, kein neues Feld.
 - Nachrüstung mutiert ausschließlich `wiki/` (Concept-Bodies, `index.md`, `log.md`). `raw/`, `schema/wiki-compiler.md`, `schema/validator.md` unverändert (AD-3). `schema/compiler.md` = einziger Instruktions-Ort (D-3).
 - Neue `sources`-Einträge: nur §3.3-Subset; `id` je Concept eindeutig; `resource` nie `wiki/` (AD-4b); kein generiertes Concept führt ein anderes als alleinige Provenienz (AD-4c).
 - `generated`/`verified`/`status` unangetastet (v1-Default A0-20). Epic-3/4-Fähigkeiten im Body als Forward-Referenz ohne eigene Behauptung markiert.
 - Revisionslog der Instruktion + `wiki/log.md` (Vertrag §5) dokumentieren die Änderung.
 **Ask First:** Neue §7-Klasse / Vertragsänderung · Standalone-Programm (D-3) · `wiki/<area>/`-Anlage (Story 2.4).
 **Never:** OKF-Dialekt · Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` · Validator-Verhaltenswechsel (bleibt strukturell; Content-Truth = eigenständige Arbeit) · Vorwegnahme Story 2.3/2.4 · Falsch-Attribution.
 ## I/O & Edge-Case Matrix
 | Scenario | Input | Expected | Error Handling |
 |----------|-------|----------|----------------|
 | HAPPY_PATH | 3 Concept-Bodies, Kern + Übernahmen (z. B. ASCII-Diagramm) | Belegte Aussagen mit Inline-Verweis; Übernahmen mit Marker; Diagramm-Quelle deklariert; Validator SUCCESS | N/A |
 | UNBELEGTE_AUSSAGE | Aussage nicht auf `sources` rückführbar | Als Übernahme mit Marker geführt (nicht erfunden belegt) | Run bricht nicht ab; textuell sichtbar |
 </frozen-after-approval>
 ## Code Map
 - `schema/compiler.md` — **mutiert**: Sektion „Claim-granulare Provenienz" (Inline-Verweise, Kontext-Marker, `id`); Revisionslog (§8); §7-Selbstbegrenzung.
 - `schema/wiki-compiler.md` — **read-only**: §3.3 `sources`/`id`, §5 `log.md`, §7 abschließende Liste.
 - `schema/validator.md` — **read-only (Rev 8)**: bleibt strukturell.
 - `wiki/llm-wiki-prinzip.md`, `wiki/knowledge-kompilation-inkrementell.md`, `wiki/wissensarchitektur-trennung-states.md` — **mutiert**: Body um Inline-Verweise/Kontext-Marker.
 - `wiki/index.md` — **mutiert**: Beschreibungen um `(aus <raw-Pfad>)`.
 - `wiki/log.md` — **append-only**: Nachrüst-Eintrag inkl. Diagramm-Quell-Deklaration.
 - `raw/architecture-spine/…` (AD-4a :143), `raw/epics/…`, `raw/prd/…` — **read-only Evidenz**.
 - `_bmad-output/implementation-artifacts/epic-2-context.md` — Planungskontext (read-only).
 - `sprint-status.yaml` — **mutiert**: Status-Übergang (Review-Workflow-Sync, `backlog` → `review`).
 ## Tasks & Acceptance
 **Execution:**
 - [x] `schema/compiler.md` — Sektion „Claim-granulare Provenienz" (nach §5, vor §6): Inline-`raw/`-Verweis je belegter Aussage (+ `id`), Kontext-Marker je Übernahme, eindeutiges `id`-Scoping (§3.3), Selbsttest-Kriterien (belegte Aussage → `raw/`-Verweis; Übernahme → Marker; kein unautorisierter Key) — AD-4a/4c, AD-13, AD-17h. **inkl. Review-Patch-Runde (Rev 1.6): Stellen-Kennungs-Semantik, volle Pfade, Direktübernahme-Marker, worked example, korrigierte Grep-Formel.**
 - [x] `schema/compiler.md` — Revisionslog (§8, Fortlauf) + §7-Selbstbegrenzung „→ Story 2.2".
 - [x] Nachrüst-Schritt: 3 Concept-Bodies — belegte Aussagen mit Inline-`raw/`-Verweisen; Übernahmen (insbesondere ASCII-Diagramm → `raw/architecture-spine/…`) mit Kontext-Marker + ggf. zusätzlichem `sources`-Eintrag; Epic-3/4-Formulierungen als Forward-Referenz.
 - [x] `wiki/index.md` — Beschreibungen um `(aus <raw-Pfad>)`.
 - [x] `wiki/log.md` — Nachrüst-Eintrag (§5-Format).
 - [x] Validator-Lauf — alle 5 `wiki/`-Dateien SUCCESS (Punkte 1/6/11/14, EC-1) (manuell-mechanisch, D-3; kein CLI).
 - [x] `sprint-status.yaml` — Story 2.2 → `in-progress`.
 **Acceptance Criteria:**
 - Given Concept mit fachlichen Aussagen, when nach Story 2.2 verarbeitet, then trägt jede belegte Aussage einen Inline-Verweis auf `raw/`-Evidenz (AD-4a).
 - Given Kontext-/Synthese-Umformulierung, when übernommen, then trägt sie den expliziten Kontext-Marker — inklusive ASCII-Diagramm.
 - Given `sources`-Dokumentation, when gesetzt, then lösen Werte ausschließlich auf `raw/`-Pfade auf (AD-4b); kein generiertes Concept führt ein anderes als alleinige Provenienz (AD-4c) — formseitig prüfbar.
 - Given Nachrüst-Inhalte, when validiert, then bleibt das Bundle vollständig Validator-SUCCESS (keine neue Invaliditätsklasse, keine Vertrags-/`raw/`-Mutation).
 - Given Instruktions-Bestand, when geprüft, then rein textuell (D-3), deterministisch (AD-17h), referenziert den Vertrag.
 ### Review Findings (bmad-code-review, 2026-08-17)
 > Vier Layer (Blind Hunter, Edge Case Hunter, Verification Gap, Acceptance Auditor) auf `bb32acd → story-2-2`. Dedupliziert, Severity durch Workflow gesetzt (Reviewer-Severity verworfen). 1 `decision-needed` (entschieden 2026-08-17 → Option 1), 12 `patch`, 4 `defer`, 2 dismissed (Status-Drift als Workflow-Bug — 2.1-Präzedenz; non-behavioral Screen-outs).
 **Decision-Needed**
 - [x] [Review][Decision] **D1 — Referenzform: Komma-Form vs. verbindliche `#`-Form** — **Entschieden (2026-08-17): Option 1** — Komma-Form als zulässige Variante in §5.5 Pkt.1 formal zulassen; Bodies bleiben unverändert. Umsetzung als Patch **P12** (siehe unten).
 **Patch**
 - [x] [Review][Patch] **P1 — Selbsttest-Grep-Formel defekt (ungeschlossenes Klammerpaar)** `schema/compiler.md:76,99` — `grep -nE '(raw/|]\(raw/'` öffnet eine Gruppe, schließt sie nie → `exit 2 „Unmatched ( or \("` (reproduziert). AC-5/AD-17h (deterministischer Selbsttest) liefert einen Fehler statt deterministischer Ausgabe. Rev-1.6-„Korrektur" war unnötig: `\(raw/` (noch in Spec Verification) erfasst bereits beide Formen. Fix: eine funktionierende Formel in compiler.md Pkt.1+Pkt.4 **und** Spec Verification synchron halten.
 - [x] [Review][Patch] **P2 — „Pkt. 1b" referenziert, aber nicht definiert** `schema/compiler.md:68,112` + `_bmad-output/implementation-artifacts/deferred-work.md:196` — die Relokations-Regel ist ein unnummeriertes Sub-Bullet unter Pkt.1; das Label „1b" existiert in §5.5 nicht. Fix: Sub-Bullet als „1b" nummerieren (hält alle drei Referenzen) oder alle drei Referenzen umschreiben.
 - [x] [Review][Patch] **P3 — Marker-Muster-Zahl inkonsistent** `schema/compiler.md:81,100` — Pkt.2 öffnet mit „zwei Marker-Muster", definiert dann drei (Zwischen-Concept, Direktübernahme, Forward-Referenz); Pkt.4 wiederholt „einen der beiden". Fix: „drei" / Forward-Referenz als Variante kennzeichnen.
 - [x] [Review][Patch] **P4 — §8 Normreferenzen nicht für §5.5 ergänzt** `schema/compiler.md:172-177` — fehlen `AD-4a`, `A0-3` (Kernnormen des §5.5) sowie `AD-16`, `AD-9`, `AD-13`, `AD-14` (jetzt in den Bodies zitiert). Fix: Spine-/Epics-Zeile um die tatsächlich genutzten Normen erweitern.
 - [x] [Review][Patch] **P5 — `wiki/log.md`-Eintrag: veralteter Status** `wiki/log.md:4` — Eintrag endet „— Story 2.2 `in-progress`", während derselbe Diff `sprint-status.yaml` auf `review` setzt. Fix: auf `review` angleichen.
 - [x] [Review][Patch] **P6 — Spec `review_loop_iteration: 0`** `spec…md:6` — trotz abgeschlossener Step-04-Review-Loop + Patch-Runde (P1–P7) und Defers; Vergleich `spec-2-1` = 2. Fix: tatsächliche Iterationszahl setzen.
 - [x] [Review][Patch] **P7 — Suggested-Review-Order-Statuszeile falsch** `spec…md:124` — „Story-Status `in-progress` (nach Human-Review → `review`)" zeigt auf `sprint-status.yaml:47`, die hier bereits `review` ist; Klammer dreht die Workflow-Richtung um (Human-Review → `done`). Fix: Zeile korrigieren.
 - [x] [Review][Patch] **P8 — Code Map lässt `sprint-status.yaml` aus** `spec…md:43` — die Code Map enumeriert alle mutierten Dateien, außer `sprint-status.yaml`, den die eigene Verification `git diff --stat` aufführt. Fix: ergänzen.
 - [x] [Review][Patch] **P9 — deferred-work-Eintrag bricht Datei-Format** `_bmad-output/implementation-artifacts/deferred-work.md:195-197` — neu eingeführter Eintrag trägt `source_spec:`/`summary:`/`evidence:`, aber kein `status:`/`Home:` wie alle bestehenden. Fix: `status:`-Zeile mit Owner ergänzen.
 - [x] [Review][Patch] **P10 — Gefrorener Block: „Kein Frontmatter-Change" wörtlich widersprüchlich** `spec…md:74` — der Frozen-Block sagt „Kein Frontmatter-Change, kein neues Feld", der Diff ergänzt aber `id`-Werte + zwei `sources`-Einträge. Rev 1.6 löste das nur auf compiler.md-Seite; das Spec Change Log dokumentiert die Angleichung nicht. Fix: Angleichungs-Hinweis („kein neues Feld *über das §3.3-Subset hinaus*") im (nicht gefrorenen) Change Log nachführen — Frozen-Block unverändert lassen.
 - [x] [Review][Patch] **P11 — Forward-Referenz-Zitat „Epic-3-Abschnitt" mehrdeutig** `wiki/knowledge-kompilation-inkrementell.md:52` — `raw/epics/…` trägt zwei „Epic 3"-Headings (`### Epic 3` Zeile 90, `## Epic 3` Zeile 258). Fix: auf die eine Sektion disambiguieren (exakter Sektionstitel/Nummer).
 - [x] [Review][Patch] **P12 — D1-Umsetzung: Komma-Form als zulässige Variante in §5.5 Pkt.1 formal zulassen** `schema/compiler.md:72-77` — §5.5 Pkt.1 neben der verbindlichen Default-Form `(raw/<datei.md>#<stellen-kennung>)` die **Komma-Form** `(raw/<datei.md>, <stellen-kennung>)` als zulässige zweite Form zulassen (für Stellen-Kennungen, die im Rohdokument als Sektionstitel/Nummer ohne Bezeichner-`id` vorliegen, z. B. `§ 1 Vision`, `§ 4.5 FR-16`) — analog zum bereits vorhandenen Präzedenzfall „Link-Form ggü. Plain-Form bis Story 2.3 formal offen, beide zulässig, sofern der volle `raw/`-Pfad am Verweis erkennbar und Grep-greifbar". Zusätzlich: **Multi-Beleg-Serialisierung** festlegen (Komma-Gruppierung `#ID1, #ID2` unter einem Pfad explizit zulassen ODER je Kennung vollen Pfad wiederholen — Konsistenz mit den Bodies; vgl. `wiki/wissensarchitektur-trennung-states.md:15`). Worked Example um ein Komma-Form-Beispiel ergänzen. Bodies bleiben unverändert (Form ist dort dann konform). Rev-1.7-Eintrag im §8-Revisionslog.
 **Defer (vorbestehend / Scope)**
 - [x] [Review][Defer] **W1 — Sources-Closure (inline `raw/`-Pfad ⊆ `sources`)** — bereits in `deferred-work.md` (Abschnitt „Deferred from: code review of story-2.2") verankert; kein neues Handeln.
 - [x] [Review][Defer] **W2 — Stellen-Kennung-Existenz im Rohdokument wird nirgends geprüft** `schema/compiler.md:74` — Fragment-Typo (z. B. `#FR-19`, `#AD-1b`) oder verbotenes Concept-`id`-Fragment `#s1` durchläuft Grep + 14 Validator-Punkte + EC-1 (Datei existiert) → SUCCESS; Falsch-Attribution ohne Pin. D-3-/kein-Standalone-Kontext; Schwester zu W1.
 - [x] [Review][Defer] **W3 — Kontext-Marker-Grammatik (Selbstreferenz-Verbot, Musterwahl) ungeprüft** `schema/compiler.md:81-94` — ein Selbstreferenz-Marker (Concept nennt sich als Ursprung) trägt den exakten Token und passiert jede re-runnable Prüfung; das Rev-1.6-Selbstreferenz-Verbot ist durch nichts erzwingbar. Schwester zu W1.
 - [x] [Review][Defer] **W4 — `sources`-`id`-Eindeutigkeit je Concept ohne Check** `schema/compiler.md:96` — duplizierte `id`-Werte (z. B. beide `s1`) passieren Validator Punkt 6 (prüft Keys, nicht Werte) + Punkt 13 (Top-Level) + Spec-Greps; §5.5 Pkt.4 führt die Regel nicht. Schwester zu W1.
 ## Spec Change Log
 - **2026-08-17 (Erstellung):** Initiale Approve-Baseline.
 - **2026-08-17 (Patch-Runde, Step-04-Review):** Review-Findings (patch-Klasse) umgesetzt: §5.5-Klarstellungen (Rev 1.6 in `schema/compiler.md`), Body-Vereinheitlichung (Stellen-Kennungs-Sektionstitel statt Concept-`id`-Fragmente, volle `raw/`-Pfade je Beleg, Direktübernahme-Marker ohne Selbstreferenz, FR-16-Beleg auf PRD §4.5 allein), `index.md`/`log.md`-Angleichungen. Klassifikation: `review-2-2-klassifikation.md`. Defer: sources-Closure-Verifikation → `deferred-work.md`.
 - **2026-08-17 (bmad-code-review, 4 Layer — Patch-Runde 2):** 1 `decision-needed` (D1 Referenzform → **Option 1: Komma-Form als zulässige Variante** in §5.5 Pkt.1) + 12 `patch` umgesetzt (`schema/compiler.md` → **Rev 1.7**: Grep-Formel behoben, Komma-Form + Multi-Beleg-Serialisierung, 1a/1b-Nummerierung, drei Marker-Muster, Forward-Referenz-Disambiguierung, §8-Normreferenzen; `wiki/log.md` Status `review`; `wiki/knowledge-kompilation-inkrementell.md` Forward-Referenz-Zitat; Spec-Interna: Code Map + `sprint-status.yaml`, Verification-Grep-Synchronisation, Review-Order-Statuszeile, `review_loop_iteration`). Defer: W2–W4 (neue Schwester-Gaps zu W1: Fragment-Existenz, Marker-Grammatik, `id`-Eindeutigkeit — keine re-runnable Prüfung möglich ohne Standalone, D-3) → `deferred-work.md`.
  - **Angleichung zum Frozen-Block (Review-Finding P10):** Die frozen-Block-Zeile „Kein Frontmatter-Change, kein neues Feld" ist als „**kein neues Feld *über das §3.3-Subset hinaus*\" zu lesen — das Hinzufügen/Erweitern bestehender `sources`-Einträge (`resource`/`id`, Relokation/Zielwechsel, §5.5 Pkt. 1b) ist Teil der Konvention und erfolgt im vorliegenden Diff (drei Concepts, zwei neue `sources`-Einträge + `id`-Vergabe). Der Frozen-Block selbst bleibt unverändert; diese Leseanweisung ist hier dokumentiert, weil die wörtliche Formulierung mit dem deliverierten Change kollidierte (Rev 1.6 hat die Angleichung nur auf `compiler.md`-Seite vorgenommen).
 ## Verification
 **Commands:**
 - `git diff --stat` — `schema/compiler.md`, 3 x `wiki/*.md`, `wiki/index.md`, `wiki/log.md`, `sprint-status.yaml`; KEINE `raw/`-/`schema/wiki-compiler.md`-Mutation.
 - `sh -c "grep -nE '\(raw/' wiki/*.md"` — je belegter Aussage ein Inline-`raw/`-Verweis (die Formel `grep -nE '\(raw/'` ist die verbindliche Selbsttest-Formel, `schema/compiler.md` §5.5 Pkt.1/Pkt.4, Rev 1.7; das Teilmuster `(raw/` erfasst Plain-Form und Markdown-Linkform).
 - Validator-Lauf (deterministisch) — alle `wiki/`-Dateien SUCCESS (Punkte 1/6/11/14, EC-1).
 - `grep -nE '^(type|sources|generated|verified|status|stale_after):' wiki/*.md` — nur §3-Felder; `grep -nE 'resource:' wiki/*.md` — jeder Wert existierender `/`-getrennter `raw/`-Pfad.
 **Manual checks (if no CLI):**
 - Belegte Aussage → Inline-`raw/`-Verweis; Übernahme → Kontext-Marker („übernommen aus … auf Basis von …, nicht eigenständig belegt").
 - `sources`-`id` je Concept eindeutig; keine unautorisierten Keys; `schema/compiler.md` rein textuell (D-3), deterministisch (AD-17h), referenziert den Vertrag.
 - `wiki/log.md` enthält datierten Nachrüst-Eintrag inkl. Diagramm-Quell-Deklaration.
 ## Suggested Review Order
 **Instruktions-Basis (§5.5 Claim-granulare Provenienz — der Einstiegspunkt)**
 - Konvention: Inline-`raw/`-Verweis je belegter Aussage, Kontext-Marker je Übernahme, `id`-Scoping — der verbindliche Standard für alles Folgende.
  [`compiler.md:66`](../../schema/compiler.md#L66)
 - Selbsttest-Formel & Sicherstellung der Grep-Auffindbarkeit (AD-17h).
  [`compiler.md:76`](../../schema/compiler.md#L76)
 - Revisionslog dokumentiert Nachrüstung (1.5) und Review-Patch-Runde (1.6).
  [`compiler.md:188`](../../schema/compiler.md#L188)
 **Nachkonformierte Concept-Bodies (die eigentliche Provenienz-Arbeit)**
 - Belegte Aussagen mit vollem `raw/`-Verweis; Diagramm als Direktübernahme aus `raw/architecture-spine/…` mit Marker; Forward-Referenz auf Epic 3.
  [`knowledge-kompilation-inkrementell.md:37`](../../wiki/knowledge-kompilation-inkrementell.md#L37)
 - SoC-Diagramm als Direktübernahme aus `raw/prd/…` (§ 8.3) mit Marker; FR-16-Beleg auf PRD § 4.5 allein (Relokations-Regel eingehalten).
  [`wissensarchitektur-trennung-states.md:30`](../../wiki/wissensarchitektur-trennung-states.md#L30)
 - Datenfluss-Diagramm als Direktübernahme aus `raw/prd/…` (§ 0 Document Purpose); PRD-Attribution über Sektionstitel (keine s-Fragmente).
  [`llm-wiki-prinzip.md:40`](../../wiki/llm-wiki-prinzip.md#L40)
 **Bundle-Index & Nachweisführung**
 - `index.md`-Beschreibungen mit `(aus <raw-Pfad>)` inkl. Diagramm-Quellen.
  [`index.md:29`](../../wiki/index.md#L29)
 - `log.md`-Nachrüst-Eintrag (Vertrag §5-Format) inkl. Diagramm-Quell-Deklaration.
  [`log.md:4`](../../wiki/log.md#L4)
 - Defer-Kontext: sources-Closure-Verifikation (jeder inline-referenzierte `raw/`-Pfad ⊆ `sources`) für spätere Fokussierung.
  [`deferred-work.md:196`](./deferred-work.md#L196)
 - Story-Status `done` (bmad-code-review 2026-08-17 abgeschlossen, alle Findings aufgelöst; Human-Review-Freigabe in dieser Review-Runde).
  [`sprint-status.yaml:47`](./sprint-status.yaml#L47)
@@ -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-17-2026 07:35
+last_updated: 08-17-2026 11:19
 project: wow20
 project_key: NOKEY
 tracking_system: file-system
@@ -44,7 +44,7 @@ development_status:
  epic-2: in-progress
  2-1-concepts-aus-source-material-erzeugen-okf-konform: done
-  2-2-claim-granulare-provenienz-dokumentieren: backlog
+  2-2-claim-granulare-provenienz-dokumentieren: done
  2-3-concepts-verlinken-eine-erlaubte-linkform: backlog
  2-4-deterministische-bereichszuordnung-concept-hierarchie: backlog
  2-5-progressive-discovery-über-index-md-bereitstellen: backlog
@@ -63,7 +63,7 @@ development_status:
  epic-4: backlog
  4-1-information-vor-jeder-änderung-klassifizieren-new-confirming: backlog
-  4-2-disagreements-in-log-md-explizit-dokumentieren: backlog
+  4-2-disagreements-in-log-md-explizit-dokumentieren: backlog3.3.
  4-3-menschliche-kuratierung-respektieren-human-curation: backlog
  4-4-trust-metadaten-maschinell-vs-human-reviewed-unterscheiden: backlog
  epic-4-retrospective: optional
@@ -58,11 +58,68 @@ Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
 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 großen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) ist Story 2.2 und wird hier **nicht** gefordert.
+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 großen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) folgt §5.5 — für neu erzeugte Concepts unmittelbar bei der Erzeugung, für bestehende Bodies per Nachrüstung (Story 2.2).
 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). Bei Validierungs-FAIL wird der Teilzustand **explizit zurückgerollt**: neue Concept-Datei(en) gelöscht, zugehörige Index-Verlinkung(en) aus `wiki/index.md` entfernt, `log.md`-Eintrag(e) wieder entfernt — das Bundle nimmt seinen Zustand vor dem Run wieder ein (keine partielle Mutation bleibt liegen).
 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).
 ## 5.5 Claim-granulare Provenienz (Story 2.2)
 Provenienz ist **claim-granular** (AD-4a, A0-3): Nicht nur das Concept als Ganzes trägt `sources`, sondern **jede belegte Aussage** im Body trägt einen Inline-`raw/`-Verweis. Kontext-/Synthese-Umformulierungen — Aussagen, die nicht direkt auf `raw/`-Evidenz rückführbar sind, sondern aus Concept-Kontext, direkt aus einer rohen Quelle (ohne Zwischen-Concept) oder aus Synthese mehrerer Quellen stammen — tragen einen expliziten **Kontext-Marker**. Diese Sektion ist eine Body-Text-Konvention; sie fügt **kein neues Frontmatter-Feld über das §3.3-Subset hinaus** hinzu — das Hinzufügen bzw. Erweitern von `sources`-Einträgen (`resource`/`id`) **IST Teil der Konvention** (Relokation/Zielwechsel, Pkt. 1b) und kollidiert nicht mit dieser Selbstbegrenzung (AD-4a; der Vertrag §3 legt das Feldsubset abschließend fest). Sie gilt für **Neu-Erzeugung und Nachrüstung bestehender Concept-Bodies gleichermaßen**. `wiki-compiler.md` und `validator.md` bleiben unverändert (AD-3); diese Sektion ist der einzige Instruktions-Ort der Provenienz-Konvention (D-3, Story 2.2).
 1. **Inline-`raw/`-Verweis je belegter Aussage:** Eine Aussage ist „belegt", wenn sie sich fachlich auf eine konkrete Evidenzstelle in `raw/` zurückführen lässt. Sie trägt dann unmittelbar am Ende der Aussage (bzw. am Ende des zugehörigen Absatzes/Listenelements) einen Inline-Verweis in der verbindlichen Default-Form:
   `(raw/<datei.md>#<stellen-kennung>)`
   Daneben ist die **Komma-Form** als zulässige zweite Form festgelegt:
   `(raw/<datei.md>, <stellen-kennung>)`
   - Die Komma-Form wird verwendet, wenn die Stellen-Kennung im Rohdokument **als Sektionstitel/Nummer ohne Bezeichner-`id`** vorliegt (z. B. `§ 1 Vision`, `§ 4.5 FR-16`, `§ 0 Document Purpose`) — ein `#`-Fragment wäre hier ein künstlicher Anker. Für Bezeichner-`id`s (`FR-*`, `A0-*`, `AD-*`) bleibt die `#`-Form die Default-Form. Bis Story 2.3 bleibt die Frage „Link-Form `(<pfad>)` ggü. `[<text>](<pfad>)`" formal offen — beide sind zulässig, sofern der volle `raw/`-Pfad am Verweis erkennbar ist und der Grep die Form erfasst (analog: beide Fragment-Formen `#`/Komma sind zulässig, sofern die Stellen-Kennung im Rohdokument existiert).
   - Die **Stellen-Kennung** (hinter `#` bzw. nach dem Komma) ist eine **KENNUNG, die im referenzierten Rohdokument tatsächlich existiert** — z. B. ein Bezeichner-`id` der rohen Datei (wie `FR-12`, `A0-6`, `AD-5` in `raw/epics/…` bzw. `raw/architecture-spine/…`) oder der exakte Sektionstitel des Rohdokuments (z. B. `§ 1 Vision`). Die **Concept-eigene `sources`-Feld-`id` (`s1`, `s2`, …) ist NICHT als Fragment zu verwenden**, weil sie im Rohdokument nicht existiert — der Verweis würde im Rohdokument nicht auflösen (keine Falsch-Attribution). Die `sources`-`id` dient ausschließlich der vertragsgemäßen internen Zitat-Attribution (Vertrag §3.3), nicht als Inline-Fragment.
   - **Multi-Beleg-Serialisierung:** Mehrere Belege desselben Rohdokuments innerhalb eines Inline-Verweises werden semikolon-getrennt mit vollem Pfad je Beleg aufgelistet: `(raw/epics/epics-2026-08-14.md#FR-12; raw/epics/epics-2026-08-14.md#A0-6)`. Innerhalb eines Belegs dürfen mehrere `#`-Kennungen unter demselben Pfad komma-gruppiert werden, wenn sie dieselbe Stellen-Kennung-Form tragen: `(raw/architecture-spine/architecture-spine-2026-08-14.md#AD-2, #AD-3, #AD-1)`; bei **gemischten Formen** (`#`-Kennung + Sektionstitel) bleibt der Pfad je Beleg vollständig: `(raw/architecture-spine/…md#AD-3; raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns)`. **Keine Pfad-Elision** über Beleg-Grenzen hinweg (also niemals allein `#A0-6` ohne vorangestellten Pfad als eigenständiger Beleg).
   - **Deterministische Selbsttest-Formel:** Die Verweise sind per `grep -nE '\(raw/'` auffindbar (das Teilmuster `(raw/` trifft beide Plain-Formen `(raw/…)` und die Markdown-Linkform `[<text>](raw/…)`). Die Formel ist als `sh -c "grep -nE '\(raw/' wiki/*.md"` re-executierbar und liefert deterministische Ausgabe (AD-17h).
   - **1a. Pfad-Form:** ausschließlich `/`-getrennte relative Workspace-Pfade **innerhalb `raw/`** — nie `wiki/` (AD-4b), kein `..`, kein führendes `/`, kein Backslash, keine URL-Form (spiegelbildlich zu §4.2 und Vertrag §3.3). Um zusätzliche Validierungsoberfläche ohne importierte Struktur zu vermeiden, verweist der Inline-Beleg üblicherweise auf dasselbe `raw/`-Ziel, das auch im `sources`-Frontmatter des Concepts deklariert ist — die EC-1-Existenzprüfung (§6.5-Kriterium 3 / Validator §6.1) bleibt damit unverändert anwendbar.
   - **1b. Relokation/Zielwechsel:** Zeigt eine Aussage auf einen anderen `raw/`-Pfad als die `sources`-Deklaration des Concepts (z. B. das ASCII-Diagramm aus `raw/architecture-spine/…` in einem Concept mit `sources: raw/epics/…`), so ist **zusätzlich ein passender `sources`-Eintrag** im Frontmatter zu ergänzen, dessen `resource` auf jenen Pfad zeigt (EC-1-Existenz, Punkt 3/4). Das Diagramm-Quell ist damit sowohl body- als auch frontmatter-seitig deklariert (Story-2.1-Instanz: ASCII-Diagramm in `knowledge-kompilation-inkrementell.md`).
 2. **Kontext-Marker je Übernahme (AD-4a/A0-3):** Eine **Übernahme** ist eine Kontext-/Synthese-Umformulierung: Formulierung, die aus Concept-Kontext, direkt aus einer rohen Quelle oder aus der Synthese mehrerer Quellen stammt und nicht eigenständig gegen `raw/` belegt ist. Es gibt **drei Marker-Muster** (zwei Grundmuster + Forward-Referenz-Variante) — alle MÜSSEN den exakten Token „nicht eigenständig belegt" enthalten (deterministischer Selbsttest, mindestens eine Form pro Übernahme):
   - **Übernahme über ein Zwischen-Concept** (Ursprungs-Concept existiert): minimal nach Vertrag §3.3/A0-3-Wortlaut
     > übernommen aus `<Concept-Pfad>` auf Basis von `<source>`, nicht eigenständig belegt
     Dabei ist `<Concept-Pfad>` der relative OKF-Pfad des Ursprungs-Concepts ohne `.md` (AD-7a), `<source>` der zugrunde liegende `raw/`-Pfad. **Kein Selbstreferenz-Muster:** Ein Concept, das sich selbst als Ursprung nennt, ist Falsch-Attribution und verboten — gibt es kein Zwischen-Concept, ist Muster (2) zu verwenden.
   - **Direktübernahme aus `raw/` ohne Zwischen-Concept** (z. B. ein Diagramm direkt aus einer rohen Datei):
     > übernommen aus `<source>` (rohe Quelle), nicht eigenständig belegt
     Dabei ist `<source>` der zugrunde liegende `raw/`-Pfad.
   Die Marker stehen direkt bei der übernommenen Aussage (Absatz-/Listen-Ebene), damit die Zuordnung claim-granular bleibt. **Epic-3/4-Fähigkeiten**, die im Körper eines Concepts nur als Forward-Referenz erscheinen (noch nicht erzeugt/validiert), tragen die **Forward-Referenz-Variante** des Markers (drittes Muster) ebenfalls mit dem exakten Token — nicht eigenständig belegt, als Forward-Referenz übernommen (die „auf Basis von"-Angabe wird hier nur gesetzt, wenn nicht bereits aus der Kontext-/Konzeptzeile ersichtlich): „… als Forward-Referenz übernommen, nicht eigenständig belegt (raw/epics/epics-2026-08-14.md, Story 3.1: Inkrementellen Datenfluss implementieren)".
 3. **Eindeutiges `id`-Scoping (Vertrag §3.3):** `id`-Werte in `sources`-Einträgen sind **je Concept eindeutig** (innerhalb eines Concepts darf kein `id` doppelt vorkommen). Über Concepts hinweg ist `id` nicht global eindeutig — der Adressraum ist der Concept-Pfad + `id` (AD-7a). Bei der Nachrüstung bestehender Concepts ohne `id` können `id`s deterministisch vergeben werden (`s1`, `s2`, … in Dokumentreihenfolge).
 4. **Selbsttest-Kriterien (AD-17h, Story-2.2-Projektion):** Vor Abschluss eines Runs prüft der Producer:
   - **Belegte Aussage → Inline-`raw/`-Verweis:** Jede Aussage, die fachlich eine Evidenzstelle referenziert, trägt einen solchen Verweis mit vollem `raw/`-Pfad je Beleg (per `grep -nE '\(raw/'` auffindbar — erfasst auch die Markdown-Linkform).
   - **Übernahme → Kontext-Marker:** Jede Kontext-/Synthese-Umformulierung, jede Direktübernahme aus `raw/` und jede Epic-3/4-Forward-Referenz trägt eines der drei Marker-Muster aus Pkt. 2 — alle enthalten den exakten Token „nicht eigenständig belegt".
   - **Kein unautorisierter Key:** Das Nachrüsten verändert ausschließlich den Body und die zulässigen §3.3-`sources`-Felder (`resource`, `id`, `title`, `author`, `usage_count`, `last_modified`); keine zusätzlichen Frontmatter-Felder, keine §7-Klasse (Punkt 6).
   - Wenn eine Aussage weder belegt noch als Übernahme markiert werden kann, wird sie **als Übernahme mit Marker geführt** — niemals erfunden belegt (UNBELEGTE_AUSSAGE: textuell sichtbar, Run bricht nicht ab).
 5. **Worked Example (grammatisch verbindlich, BH-13):** Die folgende kanonische Form macht den §5.5-Standard eindeutig ablesbar. Eine **belegte Aussage** mit Inline-Verweis (voller Pfad, Fragment = im Rohdokument existierende Stellen-Kennung):
   > Alle erzeugten Concepts sind OKF-0.2-konform (raw/epics/epics-2026-08-14.md#FR-9).
   Dasselbe als **Komma-Form** (Stellen-Kennung = Sektionstitel ohne Bezeichner-`id` im Rohdokument):
   > Das zentrale Produktversprechen lautet: Knowledge should compound (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).
   Eine **Übernahme mit Kontext-Marker** — Direktübernahme eines Diagramms aus einer rohen Quelle (kein Zwischen-Concept, kein Selbstverweis):
   > Das Datenfluss-Diagramm (Interpret → Reconcile → Synthesize → Update) stammt direkt aus der rohen Quelle raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5 — übernommen aus raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5 (rohe Quelle), nicht eigenständig belegt.
   Die **Diagramm-Quell-Deklaration** erfolgt zugleich frontmatter-seitig: gehört das Diagramm nicht zur `sources`-Deklaration des Concepts, wird ein zusätzlicher `sources`-Eintrag ergänzt (Pkt. 1b — Relokation/Zielwechsel, EC-1-Existenz bleibt erfüllt).
 ## 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).
@@ -111,7 +168,7 @@ Interpretations-Hinweis: Die „✗"-Zeilen zeigen die deterministische Fehlerur
 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).
+- **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`) → 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.
@@ -125,9 +182,9 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begren
 - `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).
- 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).
+- 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`), AD-9 (Progressive Discovery), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-13 (Retrieval gehört zu Consumers), 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), A-4 (nur lokale Sources).
+- PRD (raw/prd): FR-2 (Sources vs. Curated), FR-5 (Concept-Erzeugung), FR-9 (OKF-Konformität), FR-16 (Consumer-Unabhängigkeit), A-4 (nur lokale Sources).
- Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5.
+- Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5; A0-3 (Kontext-Marker-Wortlaut, §5.5); FR-6/FR-12/FR-14, A0-6/A0-7/A0-11/A0-18 (Belege der nachkonformierten Concept-Bodies).
 **Revisionslog:**
@@ -136,3 +193,6 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begren
 - **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.
 - **Revision 1.3 (2026-08-16, bmad-code-review Story 2.1):** Nachschärfungen aus dem Review-Patch-Block — §1-Überschrift ins Deutsche („Input (was der Compiler konsumiert)"); Prüfgrundlagen-Referenz auf `validator.md` Revision 7 angeglichen (§0-Header, §8); §6.6 canonical-Key-Reihenfolge-Zeile von der ✗-Liste auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Normalform ohne §7-Punkt) und das irreführende „§6.4"-Label auf §4.2 berichtigt; §1.2 vs. §1.4-Evidenz-Widerspruch aufgelöst (§1.2 präzisiert auf verarbeitbare Evidenz, §1.4 Artefakt-Ausnahme als dokumentarische Konvention der Source-Bereitstellung nach `raw/README.md` gekennzeichnet).
 - **Revision 1.4 (2026-08-17, bmad-code-review Re-Run Story 2.1, Stand nach Validator-Rev-8):** Nachschärfungen aus dem unabhängigen Re-Review — Prüfgrundlagen-Referenz auf `validator.md` Revision 8 angehoben (§0-Header, §8); §6.6-Referenzlabels berichtigt (canonical Key-Reihenfolge, Duplikat-Keys, `okf_version`/`type: bundle` → §4.5, `sources`-Eintrag-Key-Subset → §4.2; berichtigt die Rev-1.2-Korrektur, die das Label fälschlich von §4.5 auf §4.4 bewegt hatte); §1.4 „Aufträge" → „Formate", §5.2 „grossen" → „großen"; §3.2 Kollision-Hold um Run-Fortsetzung mit den übrigen Einheiten und Gesamt-Run-Status („teilweise erfolgreich") ergänzt; §5.3/§6.3 um explizite Rollback-Sequenz für den Teilzustand (Concept-Datei + Index-Verlinkung + `log.md`-Eintrag) bei Validierungs-FAIL ergänzt.
 - **Revision 1.5 (2026-08-17, Story 2.2):** Sektion „Claim-granulare Provenienz" als §5.5 eingefügt (nach §5, vor §6) — Inline-`raw/`-Verweis je belegter Aussage (+ `id`-Attribution, Vertrag §3.3), Kontext-Marker je Übernahme („übernommen aus … auf Basis von …, nicht eigenständig belegt"), eindeutiges `id`-Scoping je Concept, Selbsttest-Kriterien (belegte Aussage → Verweis; Übernahme → Marker; kein unautorisierter Key; UNBELEGTE_AUSSAGE als Marker statt erfundener Beleg) — AD-4a/4b/4c, AD-13, AD-17h. §7-Selbstbegrenzung entsprechend umformuliert (Claim-granulare Provenienz jetzt in §5.5 verankert, nicht mehr deklariert als „verbleibt in Story 2.2"). Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/`; kein Standalone (D-3); keine Vertragsänderung.
 - **Revision 1.6 (2026-08-17, Story-2.2-Re-Review, Patch-Runde):** §5.5-Klarstellungen aus dem Review — (1) „kein Frontmatter-Change"-Widerspruch aufgelöst: Konvention fügt kein neues Feld über §3.3 hinaus hinzu, während das Hinzufügen/Erweitern von `sources`-Einträgen (`resource`/`id`, Relokation/Zielwechsel) ausdrücklich Teil der Konvention ist; (2) Inline-Verweis-Form präzisiert: Fragment = im Rohdokument existierende Stellen-Kennung (Bezeichner-`id` oder Sektionstitel), Concept-eigene `sources`-`id` (`s1`, …) ist NICHT als Fragment zu verwenden; voller `raw/`-Pfad je Beleg, keine Pfad-Elision; die Selbsttest-Formel auf `grep -nE '(raw/|]\(raw/'` erweitert; (3) Kontext-Marker um Direktübernahme-Fall „übernommen aus `<source>` (rohe Quelle)" ergänzt, Selbstreferenz-Muster verboten; (4) Forward-Referenz-Wortlaut an den exakten Token „nicht eigenständig belegt" gebunden; (5) Worked Example (belegte Aussage + Diagramm-Direktübernahme + Diagramm-Quell-Deklaration, BH-13) ergänzt. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/`; kein Standalone (D-3); keine Vertragsänderung.
 - **Revision 1.7 (2026-08-17, bmad-code-review Story 2.2, Patch-Runde 2):** (1) Selbsttest-Grep-Formel behoben — `grep -nE '(raw/|]\(raw/'` war eine ungültige ERE (ungeschlossenes Klammerpaar, `exit 2`); jetzt `grep -nE '\(raw/'` (das Teilmuster `(raw/` erfasst Plain-Form und Markdown-Linkform gleichermaßen), Pkt.1 und Pkt.4, re-executierbar (AD-17h); (2) Komma-Form `(raw/<datei.md>, <stellen-kennung>)` als zulässige zweite Inline-Form in Pkt.1 formal festgelegt (für Stellen-Kennungen ohne Bezeichner-`id` im Rohdokument, z. B. Sektionstitel `§ 1 Vision`), analog zum Link-Form-Präzedenzfall bis Story 2.3 — Worked Example um Komma-Form-Beispiel ergänzt (D1-Entscheidung, Option 1); (3) Multi-Beleg-Serialisierung in Pkt.1 festgelegt (Semikolon + voller Pfad je Beleg; Komma-Gruppierung mehrerer `#`-Kennungen unter einem Pfad zulässig; bei gemischten Formen voller Pfad je Beleg; keine Pfad-Elision über Beleg-Grenzen); (4) Relokations-Sub-Bullets als **1a/1b** nummeriert (Label „Pkt. 1b" in §5.5-Intro, Pkt.5 und `deferred-work.md` existiert damit); (5) Marker-Muster-Zahl korrigiert: „drei" (zwei Grundmuster + Forward-Referenz-Variante), Pkt.2 und Pkt.4; Forward-Referenz-Beispiel-Zitat auf eindeutigen Sektionstitel `Story 3.1: Inkrementellen Datenfluss implementieren` disambiguiert (raw/epics trägt zwei „Epic 3"-Headings); (6) §8-Normreferenzen um AD-4a, AD-9, AD-13, AD-14, AD-16 (Spine), FR-16 (PRD), A0-3, FR-6/12/14, A0-6/7/11/18 (Epics) ergänzt. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/`; kein Standalone (D-3); keine Vertragsänderung.
@@ -27,7 +27,7 @@ wiki/
 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`).
+- [Knowledge Compilation & Inkrementelle Evolution](knowledge-kompilation-inkrementell.md) — inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update (aus `raw/epics/epics-2026-08-14.md`; Datenfluss-Diagramm aus `raw/architecture-spine/architecture-spine-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`).
+- [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`; Separation of Concerns aus `raw/prd/prd-wow20-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).
@@ -2,6 +2,9 @@
 type: concept
 sources:
  - resource: raw/epics/epics-2026-08-14.md
    id: s1
  - resource: raw/architecture-spine/architecture-spine-2026-08-14.md
    id: s2
 generated:
  by: wow-compiler/0.1.0
  at: 2026-08-16T09:23:33Z
@@ -9,11 +12,11 @@ generated:
 # 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.
+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 (raw/epics/epics-2026-08-14.md#FR-12; raw/epics/epics-2026-08-14.md#A0-6).
 ## 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:
+Jeder Compilation Run beginnt mit dem aktuell vorhandenen Knowledge Bundle und verändert nur die durch neue Erkenntnisse betroffenen Concepts (raw/epics/epics-2026-08-14.md#A0-6; raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5). Der logische Datenfluss lautet:
 ```text
 Existing Knowledge
@@ -29,19 +32,21 @@ 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.
+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 (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5).
 Das Diagramm des Datenflusses (Existing Knowledge + New Source Material → Interpret → Reconcile → Synthesize → Update affected Concepts) stammt direkt aus der rohen Quelle `raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5` — übernommen aus `raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5` (rohe Quelle), nicht eigenständig belegt.
 ## Folgen für die Fähigkeiten
- **Inkrementelle Evolution (FR-12):** Unverändertes Wissen bleibt erhalten; Änderungen konzentrieren sich auf durch neue Erkenntnisse betroffene Concepts.
+- **Inkrementelle Evolution (FR-12):** Unverändertes Wissen bleibt erhalten; Änderungen konzentrieren sich auf durch neue Erkenntnisse betroffene Concepts (raw/epics/epics-2026-08-14.md#FR-12).
- **Aktualisierung statt neuer Dateien (FR-6):** Neue Informationen führen nicht automatisch zu neuen Dateien — bestehendes Wissen wird erweitert, präzisiert oder korrigiert.
+- **Aktualisierung statt neuer Dateien (FR-6):** Neue Informationen führen nicht automatisch zu neuen Dateien — bestehendes Wissen wird erweitert, präzisiert oder korrigiert (raw/epics/epics-2026-08-14.md#FR-6).
- **Konsistenz bei Fehlern (AD-6):** Analyse, Änderungsplanung, Mutation und Validierung sind logisch getrennt; ein teilweise fehlgeschlagener Run hinterlässt kein inkonsistentes Bundle.
+- **Konsistenz bei Fehlern (AD-6):** Analyse, Änderungsplanung, Mutation und Validierung sind logisch getrennt; ein teilweise fehlgeschlagener Run hinterlässt kein inkonsistentes Bundle (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-6; raw/epics/epics-2026-08-14.md#A0-7).
- **Nachvollziehbarkeit (FR-14):** Änderungen erfolgen an textuellen Artefakten und sind über normale Versionskontrolle (Git-Diff) nachvollziehbar.
+- **Nachvollziehbarkeit (FR-14):** Änderungen erfolgen an textuellen Artefakten und sind über normale Versionskontrolle (Git-Diff) nachvollziehbar (raw/epics/epics-2026-08-14.md#FR-14).
 ## 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.
+Die Inhaltsklassifikation vor jeder Änderung (NEW / CONFIRMING / CORRECTING / CONTRADICTING / REDUNDANT) (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-16; raw/epics/epics-2026-08-14.md#A0-11) und die deterministische Relevanzbestimmung per textueller, deterministischer Mittel (grep/ripgrep, Markdown-Traversal, Link-Following) sind Teil der inkrementellen Kompilation (raw/epics/epics-2026-08-14.md#A0-18; raw/architecture-spine/architecture-spine-2026-08-14.md#AD-13).
 ## 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.
+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 — als Forward-Referenz übernommen, nicht eigenständig belegt (raw/epics/epics-2026-08-14.md, Story 3.1: Inkrementellen Datenfluss implementieren).
@@ -2,6 +2,7 @@
 type: concept
 sources:
  - resource: raw/prd/prd-wow20-2026-08-14.md
    id: s1
 generated:
  by: wow-compiler/0.1.0
  at: 2026-08-16T09:23:33Z
@@ -9,15 +10,15 @@ generated:
 # 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.
+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 (raw/prd/prd-wow20-2026-08-14.md, § 0 Document Purpose).
 ## 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.
+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 (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).
 ## 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.
+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 (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).
 ## Datenfluss
@@ -34,8 +35,10 @@ 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.
+Das Ergebnis ist ein einfaches, portables Knowledge Bundle aus Markdown-Dateien, das weder eine spezielle Datenbank noch eine proprietäre Knowledge-Plattform benötigt (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).
 Das Datenfluss-Diagramm (Sources → LLM Wiki Compiler → Curated OKF Wiki → Humans / LLM Agents / BMAD / Coding Agents / other Consumers) stammt direkt aus der rohen Quelle `raw/prd/prd-wow20-2026-08-14.md` (§ 0 Document Purpose) — übernommen aus `raw/prd/prd-wow20-2026-08-14.md` (rohe Quelle), nicht eigenständig belegt.
 ## 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.
+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 (raw/prd/prd-wow20-2026-08-14.md, § 5 Non-Goals).
@@ -1,6 +1,8 @@
 # Log
 ## 2026-08-17
 - **Story 2.2 «Claim-granulare Provenienz dokumentieren» → `done` (bmad-code-review 2026-08-17, 4 Layer, abgeschlossen):** Review auf `bb32acd → story-2-2` — 1 `decision-needed` (D1 Referenzform → Option 1: Komma-Form als zulässige Variante), 12 `patch` (alle umgesetzt), 4 `defer`, 2 dismissed. `schema/compiler.md` → **Revision 1.7**: defekte Selbsttest-Grep-Formel behoben (ungeschlossene ERE `'(raw/|]\(raw/'` → `'\(raw/'`), Komma-Form + Multi-Beleg-Serialisierung in §5.5 Pkt.1, Relokations-Sub-Bullets als 1a/1b nummeriert, drei Marker-Muster, Forward-Referenz-Disambiguierung auf `Story 3.1: Inkrementellen Datenfluss implementieren`, §8-Normreferenzen um AD-4a/AD-9/AD-13/AD-14/AD-16/FR-16/A0-3 ergänzt. `wiki/knowledge-kompilation-inkrementell.md` Forward-Referenz-Zitat disambiguiert. Defer W2–W4 (Fragment-Existenz, Marker-Grammatik, `sources`-`id`-Eindeutigkeit — keine re-runnable Prüfung ohne Standalone, D-3) + W1 (sources-Closure) in `deferred-work.md`. Re-Verifikation: `sh -c "grep -nE '\(raw/' wiki/*.md"` 27 Treffer, alle 3 Diagramm-Marker + Forward-Referenz mit exaktem Token, `sources`-`id` je Concept eindeutig, `wiki-compiler.md`/`validator.md`/`raw/` unverändert. Klassifikation: `review-2-2-klassifikation.md`. `sprint-status.yaml`: Story 2.2 → `done`.
 - **Story 2.2 «Claim-granulare Provenienz dokumentieren» — Nachrüstung (Datei-Bodies, `index.md`, `log.md`):** `schema/compiler.md` um §5.5 „Claim-granulare Provenienz" erweitert (nach §5, vor §6): Inline-`raw/`-Verweis je belegter Aussage + `id`-Attribution (Vertrag §3.3), Kontext-Marker je Übernahme (übernommen aus `<raw-Quelle>` (rohe Quelle) bzw. übernommen aus `<Concept>` auf Basis von `<raw-Quelle>`, jeweils „nicht eigenständig belegt"), eindeutiges `id`-Scoping je Concept, Selbsttest-Kriterien (AD-4a/4c, AD-13, AD-17h); Revisionslog (§8) → Revision 1.5 (Nachrüstung) bzw. 1.6 (Review-Patch-Runde: Stellen-Kennungs-Semantik, volle Pfade, Direktübernahme-Marker, worked example, korrigierte Grep-Formel), §7-Selbstbegrenzung entsprechend angepasst. `wiki/index.md` (Descriptions um `(aus <raw-Pfad>)`), `wiki/knowledge-kompilation-inkrementell.md`, `wiki/llm-wiki-prinzip.md`, `wiki/wissensarchitektur-trennung-states.md` nachkonformiert — jede belegte Aussage trägt Inline-Verweis; Übernahmen tragen Kontext-Marker (keine Selbstreferenz, keine Concept-`id`-Fragmente `#s1`/`#s2`). **Diagramm-Quell-Deklaration:** Das ASCII-Diagramm in `wiki/knowledge-kompilation-inkrementell.md` (Datenfluss) stammt aus `raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5` — zusätzlicher `sources`-Eintrag (`id: s2`) ergänzt; das Diagramm in `wiki/wissensarchitektur-trennung-states.md` (Sources → Compilation → Knowledge Bundle → Consumers) aus `raw/prd/prd-wow20-2026-08-14.md` (§ 8.3 Separation of Concerns) — zusätzlicher `sources`-Eintrag (`id: s2`) ergänzt. `sources`-`id` je Concept eindeutig; keine unautorisierten Keys. `wiki-compiler.md`/`validator.md`/`raw/` unverändert. Validator-Lauf: alle 5 `wiki/`-Dateien SUCCESS (Punkte 1/6/11/14, EC-1) — Story 2.2 `review`.
 - **Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» → `done` (Human-Review-Freigabe erteilt):** Nutzer hat die verbleibende Schwelle (menschliche Review-Freigabe) überschritten — Status `review` → `done`, `sprint-status.yaml` nachgeführt. Alle 8 ACs PASS, kein AC-/Vertrags-Blocker; offene Folge-Arbeit (autorisierte Validator-Rev 9) ist kein Story-2.1-Blocker und bleibt als Action-Item `code-review-2-1-item-2` in `deferred-work.md` verankert.
 - bmad-code-review Re-Run Story 2.1 (unabhängig, 4 Layer, Stand nach Validator-Rev-8): alle 8 ACs PASS, 17 Patch / 4 Defer / 2 Dismiss. 15 Patches umgesetzt — `schema/compiler.md` → Revision 1.4 (Prüfgrundlage Rev 8, §6.6-Referenzlabels §4.5/§4.2, §3.2 Kollision-Hold-Run-Fortsetzung, §5.3/§6.3 Rollback-Sequenz, Sprachkorrekturen), `wiki/log.md` (verlorener Bullet, Rev-8-Datum 08-17), `wiki/index.md` (Baumdiagramm um Root-Concepts-Ebene), Doku-/Referenz-Konsistenz (`deferred-work.md` Dedupe + n=21, `review-input-dryrun-…md` 16+2-Auflösung, `epic-2-context.md` AD-4c tautologisch, spec Verification/Change-Log, `sprint-status.yaml` closed-Datum). 2 Patches auf der gefrorenen `validator.md` (Rev 8) geholdert → nächste autorisierte Validator-Revision (Rev 9: Punkt-4-Grammatik `resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile; s. `deferred-work.md`).
 - **Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» → `review` (Freigabe zur Human-Review):** Option-A-Voraussetzung erfüllt — autorisierte Validator-Revision 8 ausgeführt und zertifiziert (s. Eintrag 2026-08-16). `spec-2-1-…`-Re-Review-Verdikt aktualisiert: Story ist `done`-fähig; einzige verbleibende Schwelle ist die menschliche Review-Freigabe (`review` → `done`). Action-Item `code-review-2-1-item-1-autorisierte-validator-revision-option` → `done` (Autorisations-Runde: `validator-revision-8-autorisationsrunde-f14-innen-ebenen.md`). `sprint-status.yaml`: Story 2.1 → `review`.
@@ -2,6 +2,9 @@
 type: concept
 sources:
  - resource: raw/architecture-spine/architecture-spine-2026-08-14.md
    id: s1
  - resource: raw/prd/prd-wow20-2026-08-14.md
    id: s2
 generated:
  by: wow-compiler/0.1.0
  at: 2026-08-16T09:23:33Z
@@ -9,14 +12,14 @@ generated:
 # 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 Architektur von Wiki of Wikis trennt drei Verantwortungsbereiche, die nie vermischt werden dürfen: Quellen, Kompilation und kuratiertes Wissen mit seinen Konsumenten (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-2, #AD-3, #AD-1; raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
 ## 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.
+- **`raw/` — immutable Source Material/Evidenz:** Jede Datei unter `raw/` ist Evidenz. Ein Compilation Run darf bestehendes Source Material niemals verändern (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-3); neue Versionen einer Source werden als neue beziehungsweise versionierte Source behandelt (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-3).
- **`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).
+- **`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 (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-1; raw/prd/prd-wow20-2026-08-14.md, § 8.2 Plain Files as Canonical State).
-Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Kompilation.
+Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Kompilation (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-2; raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
 ## Separation of Concerns
@@ -24,21 +27,23 @@ Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Kompilation.
 Sources  →  Compilation  →  Knowledge Bundle  →  Consumers
 ```
- Eine Source darf nicht automatisch Teil des Curated Knowledge werden.
+> Das Diagramm (Sources → Compilation → Knowledge Bundle → Consumers) stammt direkt aus der rohen Quelle `raw/prd/prd-wow20-2026-08-14.md` (§ 8.3 Separation of Concerns) — übernommen aus `raw/prd/prd-wow20-2026-08-14.md` (rohe Quelle), nicht eigenständig belegt.
- 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).
+- Eine Source darf nicht automatisch Teil des Curated Knowledge werden (raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
 - Ein Consumer darf nicht zur Voraussetzung für Kompilation oder Speicherung werden (raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
 - Der Compiler ist ein Producer des Bundle-Artefakts — kein Wissensserver und keine eigene Agent-Runtime (raw/architecture-spine/architecture-spine-2026-08-14.md#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.
+Das Knowledge Bundle ist nicht auf einen bestimmten LLM-Agenten oder Workflow zugeschnitten (raw/prd/prd-wow20-2026-08-14.md, § 4.5 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 (raw/prd/prd-wow20-2026-08-14.md, § 4.5 FR-16).
-Retrieval (Search, RAG, Graph-Traversal) ist Consumer-Verhalten, nicht Kern des Compilers (AD-13).
+Retrieval (Search, RAG, Graph-Traversal) ist Consumer-Verhalten, nicht Kern des Compilers (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-13; raw/prd/prd-wow20-2026-08-14.md, § 5 Non-Goals).
 ## Konvergenzregeln
 | Betrachtet | Quelle |
 |---|---|
-| Canonical evidence | `raw/` bzw. referenzierte externe Source |
+| Canonical evidence | `raw/` bzw. referenzierte externe Source (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-4b) |
-| Canonical knowledge | `wiki/` |
+| Canonical knowledge | `wiki/` (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-1) |
-| Discovery | Hierarchie + `index.md` |
+| Discovery | Hierarchie + `index.md` (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-9) |
-| Update history | Git + optional OKF `log.md` |
+| Update history | Git + optional OKF `log.md` (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-14) |