chore: Sandbox-Dryrun (PDF/RADIUM) als Review-Input sichern + Folge-Eintraege

Review-Input fuer Story 2.1: Probelauf in D:\mita\wow-2nd-sandbox mit
Compiler Rev 1.3 gegen raw/MetaModel.pdf (11 radium-Concepts OKF-konform,
R-2 praktisch belegt). review-input-dryrun-2-1-pdf-radium.md: belegte
Fakten, korrigierter Punkt-11-Befund (Identity-Match in index.md des
naechsten Vorfahren statt absoluter Pfadaufloesung - Tooling-Defekt,
kein Instruktions-Defekt), Zuordnung der Optimierungs-Massnahmen (P1/P2/P3).

deferred-work.md: Folge-Eintraege aus dem Sandbox-Dryrun (P1: Validator-
Fixture-Selbsttest, .compile-run/-Konvention, einmaliges at pro Run; P2:
Pre-Run-Reconcile-Vorphase, Provenienz-Checksumme -> Story 2.2/Epic 3).
Arbeitsauftrag Option-A (F-14/innen-Ebenen/OBS-1) als umgesetzt markiert
(Validator-Revision 8, 2026-08-17).

Co-Authored-By: Claude <noreply@anthropic.com>

_bmad-output/implementation-artifacts/deferred-work.md

@@ -110,3 +110,61 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - 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).
+
+## Deferred from: code review of story-2.1 (2026-08-16)
+
+> **Code-Review-Defer (bmad-code-review, 2026-08-16):** Diese Einträge decken die im externen Adverse-Review von Story 2.1 als Defer klassifizierten Befunde ab, die bewusst nicht in Story 2.1 behoben werden. Sie sind getrennt von den Step-04-Review-Defer-Kontexten oben (die der Implementierung selbst entstammen).
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code Review, Story 2.1)
+  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 im Review inhaltlich korrekt (Spot-Checks gegen PRD/epics/spine 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): 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` (Code Review, Story 2.1)
+  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".
+
+- source_spec: `schema/validator.md` (Story 1.4) — aufgelöst via Option A
+  summary: Frieren-Verletzung heilen — die Innen-Ebenen-Klarstellung (Punkt-6 / Key-Subset auf `sources`/`generated`-Eintragsebene), die Spot 2.1 als Rev-7-Notiz in `schema/validator.md` eingetragen hat, muss in der **nächsten autorisierten Validator-Revision** formal mitlaufen (gemeinsam mit der F-14-Negativ-Fixture). Dadurch verliert die Abweichung ihren Status als unautorisierte Mutation und Story 2.1 ist `done`-fähig. Der Rev-7-Hinweis bleibt bis dahin erhalten (kein Rückbau).
+  evidence: Code Review (Story 2.1) — Decision-Befund, aufgelöst als Option A am 2026-08-16.
+
+- source_spec: `raw/README.md` (Konvention, Story 1.2) — R-1
+  summary: R-1 (Compiler-Input-Interface) — Verdikt **Bestanden**: `schema/compiler.md` definiert seine Source-Eingabe als Menge beliebiger `raw/`-Dateien (Set-Interface, §1.2 „jede Datei unter `raw/` ist Evidenz"), nicht als einzelnen Pfad. Der erkennungsseitige Mechanismus, WELCHE `raw/`-Dateien wann verarbeitet werden („Run-ohne-Pfad"-Nutzererwartung aus DRYRUN.md: Kompilation via git diff + SHA-256-Record aus den `source.md`-Records), ist bewusst nicht in Story 2.1 enthalten und gehört als Erkennungs-/Auswahl-Mechanismus in die AD-5-Home-Story (Epic 3, Story 3.1/3.2).
+  evidence: Code Review (Story 2.1) R-1 — Epic-3-Forward-Risk, keine AC-Verletzung.
+
+- source_spec: `raw/README.md` / `schema/compiler.md` §1.2–§1.4 — R-2
+  summary: R-2 (Nicht-Markdown-Quellen) — Verdikt **Bestanden**: die Compiler-Instruktion liest Sources endungsneutral als Datei (§1.2/§1.4), unterstellt keine `.md`-Endung; PDF ist zulässige Evidenz (Vertrag §3.3 verlangt nur einen Dateipfad unter `raw/`, Validator EC-1 prüft nur Existenz). Die Konventions-/Asset-Zuordnungsfrage (Namensschema für Nicht-Markdown-Quellen) bleibt offen und gehört zu Epic 2/3 (Nutzer-Input-Gestaltung für den Dryrun-Forderungskatalog). Als dokumentarischer Hinweis: §1.2/§1.4-Widerspruch („jede Datei ist Evidenz" vs. „Artefakt-Dateien sind KEIN Input") in der Instruktion selbst klären (siehe Patch-Findings in der Story).
+  evidence: Code Review (Story 2.1) R-2 — Konventionsfrage, kein Blocker.
+
+## Deferred from: code review of story-2.1 (2026-08-16) — Arbeitsauftrag: autorisierte Validator-Revision (Option-A-Heilung)
+
+> **Konkreter Arbeitsauftrag (aus Re-Review vom 2026-08-16):** Sobald die nächste **autorisierte Validator-Revision** beginnt (Story-/Autorisierungs-Kanal, Bereich `schema/`, Konsistenz mit dem Story-1.4-Prozess), sind die folgenden drei Punkte dort formal zu tragen. Sie machen Story 2.1 `done`-fähig und schließen die Referenzkette compiler.md → validator.md sauber. `validator.md` selbst bleibt bis dahin unverändert (Frieren/AD-3).
+
+- summary: **1. F-14-Negativ-Fixture ergänzen** — ein `resource`-Pfad, der außerhalb `raw/` landet, aber existiert (z. B. `resource: README.md`), hat bislang kein Negativ-Fixture; §6.2 deckt den Fall, §7.1-Fixtures belegen ihn nicht (Retrospective F-14, epic-1-retro AI-7). In der autorisierten Revision als Negativ-Fixture ergänzen (erwartetes Verdikt: `FAIL … Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (…|…)`), Beleg unter §7.1 (Punkt 4).
+- summary: **2. Innen-Ebenen-Key-Subset-Klarstellung formal tragen** — die heute als unautorisierte Rev-7-Notiz in `validator.md` §7.3 (Punkt 6: unautorisierte Keys innerhalb `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) liegende Klarstellung wird Teil der autorisierten Revision; damit verliert sie ihren Status als unautorisierte Mutation und Story 2.1 ist `done`-fähig. (Kann mit F-14 in einer gemeinsamen Revision laufen.)
+- summary: **3. Validator-Header-Revisionszahl anheben (OBS-1)** — `schema/validator.md` §0-Header trägt weiter „Validator-Revision: 6", während der Revisionslog (§8) als letzten Eintrag „Revision 7" führt (pre-existing Selbst-Inkonsistenz). In derselben autorisierten Revision den Header auf die dann aktuelle Revisionszahl anheben — damit schließt sich die von compiler.md §0/§8 auf „Revision 7" referenzierte Kette header-seitig. (Korrektur jetzt nicht möglich, da `validator.md` friert.)
+  evidence: Re-Review (Code Review Story 2.1), 2026-08-16 — Option-A-Home-Story; Epic-1-Retrospective F-14/AI-7 (Defer-Kontexte, deferred-work.md).
+  status: umgesetzt (2026-08-17) — siehe autorisierte Validator-Revision 8 (`validator-revision-8-autorisationsrunde-f14-innen-ebenen.md`): F-14-Fixture 4a, Innen-Ebenen-Klarstellung formal getragen, Header auf „Revision 8" angehoben (OBS-1 behoben); Story 2.1 damit `done`-fähig.
+
+## Folge-Einträge aus dem Sandbox-Dryrun (PDF/RADIUM, Prozess-Optimierungs-Bericht; 2026-08-17)
+
+> **Herkunft:** Nutzer-Probelauf in `D:\mita\wow-2nd-sandbox` (Compiler Rev 1.3 gegen `raw/MetaModel.pdf`, 11 radium-Concepts OKF-konform als positivem R-2-Beleg ausgeführt) — siehe `review-input-dryrun-2-1-pdf-radium.md` im selben Verzeichnis. Der Bericht (vom Nutzer erstellt) enthält Tooling-/Prozess-Optimierungs-Maßnahmen (P1/P2/P3) **auf Ausführungs-/Werkzeug-Ebene**, keine Norm-Änderungen (D-3). Diese Einträge sichern die Folge-Aufgaben; die detaillierte Zuordnung (inkl. Konformitäts-Bewertung) steht im Review-Input-Dokument.
+
+- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
+  summary: Fixture-Selbsttest des Validator-Prüfwerkzeugs vor jedem Bundle-Lauf etablieren (P1) — jede Negativ-Fixture (`validator.md` §7.1, n=17) muss ein deterministisches FAIL mit Ursache erzeugen, jede Positiv-Fixture (§7.2/§7.3, ~20) SUCCESS; optional die „Skript-Fallen" (PyYAML-`datetime`-Parsing statt Textform §4.3, relative Link-Auflösung Punkt 11, `usage_count`-Float) als eigene Negativ-Fixtures ergänzen. Nutzen: Fehler des Prüfwerkzeugs werden vor Berührung des Bundles sichtbar (im Probelauf 2 Diagnose-Zyklen durch Falsch-FAILs des Prüfskripts vermeidbar). D-3-tauglich (rein textueller Check-Block, kein Standalone).
+  evidence: Prozess-Optimierungs-Bericht §3.1/§4.1 (Tooling-Diagnose-Zyklen, Punkt-11-Identity-Match; korrigiert: kein Instruktions-Defekt); Review-Input §2/§4 (Konformität: D-3/AD-17h).
+
+- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
+  summary: Feste `.compile-run/`-Arbeitskonvention einführen (P1) — vom Workspace getragene, per Konvention (.gitignore) ausgeschlossene Fläche für deterministische Textextraktion der Quelle (z. B. `sources-<quelle>-<datum>.txt`), Prüfskripte (inkl. Fixture-Selbsttest) und `run-protokoll.md` (Prüfsummen, Verlinkungs-Check, Verdikte je Run). Nutzen: Reproduzierbarkeit/Auditierbarkeit (AD-17h) ohne `raw/` zu berühren (AD-3), agent-übergreifend gleiche Konvention (AD-10). Kein Verstoß gegen D-3 (textuelle Artefakte, kein Standalone-Programm).
+  evidence: Prozess-Optimierungs-Bericht §3.4/§4.2; Review-Input §4 (Konformität: AD-3/AD-10/AD-17h/D-3).
+
+- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
+  summary: Einmalige `at`-Festlegung pro Compilation Run deterministisch identisch in alle erzeugten `generated.at` schreiben (P1) — der Run bestimmt **einen** Ablauf-Zeitstempel (UTC) für alle Dateien; optional als textuelle Konvention in `compiler.md` §4.3 ergänzen (Kanonisierung auf `Z`-Form, da der Validator §4.3 sowohl `±HHMM` als auch `Z` akzeptiert — keine Vertrags-Änderung nötig). Nutzen: keine Timing-Drift/Inkonsistenz über Dateien, einfachere Diff-/Nachvollziehbarkeit. Deckt sich mit dem Defer zur Determinismus-Selbsttest-Schärfung (Kriterium 2 „`at`-Normalform").
+  evidence: Prozess-Optimierungs-Bericht §3.3/§4.3; Review-Input §4 (Validator-neutral: §4.3 akzeptiert `Z` und `±HHMM`).
+
+- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
+  summary: Pre-Run-Reconcile-Vorphase als deterministischen Pre-Plan-Schritt bündeln und dokumentieren (P2) — die textuellen Reconcile-Prüfungen (Ziel-Pfad-Kollision, Quellen-Existenz, AD-5-Relevanz der Quelle auf bestehende Concepts, `index.md`-Vorbedingung V-1) zu einem wiederverwendbaren Check-Block zusammenfassen (statt manueller Mehrfach-Checks, Bericht §3.2). Kein neuer Standalone-Prozess — nur ein reproduzierbarer Check-Block innerhalb der Instruktions-Ausführung; als Compiler-Instruktions-Schärfung (Story 2.1-Follow-up) oder Epic-3-Home (AD-5) einzuarbeiten.
+  evidence: Prozess-Optimierungs-Bericht §3.2/§4.4; Review-Input §4 (D-3-konform).
+
+- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
+  summary: Provenienz-Checksumme bei mehrfacher Verwendung einer Quelle im Blick behalten (P2, Vorbereitung Epic 3/Story 2.2) — bei 11 Concepts aus einer Quelle (`raw/MetaModel.pdf`) ist eine wie auch immer geartete SHA-256/`last_modified`-Angabe Kandidat für `sources`-Metadaten; erst ab der zulässigen Schema-Erweiterung (Story 2.2 Claim-provenienz / Epic 3) in der Instruktion verankern. NICHT jetzt implementieren — `sources`-Subset (Vertrag §3.3, Punkt 6/§7) bleibt unverändert.
+  evidence: Prozess-Optimierungs-Bericht §4.5; Review-Input §4 (vertragskonform: Schema-Subset unangetastet); verknüpft mit Defer zum „`sources`-`id`-Eindeutigkeit" (BH-13).

_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md

@@ -0,0 +1,91 @@
+---
+title: 'Review-Input: Prozess-Optimierungs-Bericht Compilation Run Story 2.1 (PDF/RADIUM-Probelauf in D:\mita\wow-2nd-sandbox)'
+type: review-input
+created: '2026-08-17'
+status: incorporated
+scope: review-context
+---
+
+# Review-Input: Sandbox-Dryrun (PDF/RADIUM) zu Story 2.1
+
+> **Herkunft:** Nutzer-Durchlauf in `D:\mita\wow-2nd-sandbox` (Probelauf des
+> Compilers `schema/compiler.md` Rev 1.3 gegen die Quelle `raw/MetaModel.pdf`),
+> dokumentiert in `PROZESS-OPTIMIERUNGS-BERICHT.md` (2026-08-16).
+> **Zweck:** Zusätzlicher Review-Kontext für Story 2.1 — R-2 wird praktisch
+> belegt (PDF `sources[].resource` wird endungsneutral verarbeitet), zusätzlich
+> empirische Befunde zur Ausführungs-/Tooling-Ebene.
+> **Charakter:** Prozess-Optimierungs-Bericht. Keine Änderung an `raw/`,
+> `schema/`, `adapters/`, `wiki/spring/` in der Sandbox; Bericht deklariert
+> bewusste Selbstbegrenzung (D-3, keine Norm-Änderung).
+
+## 1. Belegte Fakten (empirisch)
+
+- **Run konform:** 11 neue Root-Concepts aus `raw/MetaModel.pdf`
+  (28 Seiten, 11 Wissenseinheiten, AD-5: fachfremde Quelle betrifft keine
+  bestehenden Concepts → kein Update/keine Kollision). Verlinkung in
+  `wiki/index.md` (11 Link-Zeilen mit `(aus raw/MetaModel.pdf)`), 11
+  `- neu:`-Einträge in `wiki/log.md` (§5-Format, `sources: raw/MetaModel.pdf`).
+- **Quelle unverändert:** SHA-256 von `raw/MetaModel.pdf` konstant vor/nach
+  Run (`4fe7aaa0…eea5ec`). EC-11 bestätigt: `raw/report/report-2026-08-16.pdf`
+  bleibt unberührt (kein `.md`, kein Verdikt).
+- **Validator-Run-Ergebnis (Sandbox-Selbstauskunft, Anhang A):** SUCCESS für
+  alle 18 Sandbox-Bundle-Dateien (0 FAIL): 13 Root- + 5 `spring/`-Dateien.
+  Darunter die 5 realen Bundle-Dateien zuzüglich 11 radium- + 2 spring-Dateien.
+- **`at`-Konsistenz:** Alle 11 `at`-Stempel der neuen Concepts einheitlich
+  (`2026-08-16T09:23:33Z`), `verified` ungesetzt (v1-Default AD-15), Innen-Ebenen-
+  Key-Subset eingehalten (Punkt 6), kanonische Reihenfolge (§6.6).
+
+## 2. Korrigierter technischer Befund zum Validator-Tooling (§3 Punkt 11)
+
+Der Bericht (3.1 #2) wertet `wiki/spring/testing.md` → „Punkt 11 FAIL
+(Index-Regel)" als inkonsistenten Schema-Fehlalarm. **Korrektur laut
+`validator.md` §3 Punkt 11:** Ein Concept ist verlinkt, wenn seine **Identität
+(relativer OKF-Dateipfad ohne `.md`)** in der `index.md` des **nächsten
+Vorfahren** (Area-`index.md`; für Root-Concepts Bundleroot `wiki/index.md`)
+als relativer Bundle-Pfad referenziert ist — **mit oder ohne `.md`-Endung**
+(normative Zelle, Rev 7/8 unterscheiden sich hier nicht).
+
+Konsequenz: Für `wiki/spring/testing.md` ist die zuständige `index.md`
+`wiki/spring/index.md`, erwartetes Token `spring/testing`. Ein „nackte"
+Identitäts-Suche ohne relative Auflösung ist ein **Implementierungs-Defekt des
+Prüfwerkzeugs** — kein Instruktions-Defekt. Da diese Zeile des Validators eine
+buchstabenidentische Aussage des Prüfpfads verlangt (keine Dateisystem-Pfad-
+Auflösung mit Absoluthalten), steht der Befund **nicht** als Findings-Item für
+`validator.md`; er ist als Tooling-Lernfall (Fixture-Selbsttest, Abschnitt 4
+des Berichts) zu führen.
+
+## 3. Bestätigte Instruktions-Aussagen (R-1/R-2-Bezug)
+
+- **R-2 bestätigt (praktisch belegt):** `compiler.md` §1.2/§1.4 verarbeitet
+  die PDF-Quelle endungsneutral (PDF als Datei unter `raw/`); `sources[].
+  resource: raw/MetaModel.pdf` ist Vertrag-§3.3-konform (Dateipfad unter
+  `raw/`, kein `wiki/`-Pfad, AD-4b); Validator EC-1 prüft nur Existenz.
+  Der Befund 3.1 #1 (PyYAML-Timestamp-Parsing als Tooling-Falle) ist
+  §4.3-konform vermeidbar — der Validator verlangt **Textform**-Prüfung des
+  ISO-8601-Datetime (§4.3 Normalform), nicht Parsing zum `datetime`-Objekt.
+- **R-1 unverändert (Set-Interface):** `compiler.md` §1.2 definiert die Source-
+  Eingabe als Menge beliebiger `raw/`-Dateien; der Sandbox-Lauf (1 Quelle) ist
+  als Teilmenge des Sets operiert, nicht als Einzelpfad-Interface.
+
+## 4. Review-Zuordnung der Optimierungs-Maßnahmen (Bericht §4)
+
+| Maßnahme | Prio | Review-Zuordnung | Konformität |
+|---|---|---|---|
+| Fixture-Selbsttest des Validator-Tools vor Bundle-Lauf | P1 | Tooling-Schärfung; Folge-Eintrag `deferred-work.md` (Zuordnung Story 2.1/Epic 3) | D-3-tauglich (rein textueller Check-Block), kein neuer Standalone |
+| Feste `.compile-run/`-Arbeitskonvention (außerhalb `raw/`) | P1 | Tooling-Konvention; Folge-Eintrag `deferred-work.md` | AD-3-konform (nichts unter `schema/`/`raw/`), AD-17h-relevant |
+| Einmaliges `at` pro Run (UTC, `Z`-Form) | P1 | Klarstellung `compiler.md` §4.3 als Konvention; kein Vertrags-Bruch (Validator akzeptiert ±HHMM wie Z) | Validator-neutral |
+| Pre-Run-Reconcile-Vorphase deterministisch bündeln | P2 | Folge-Eintrag `deferred-work.md` (Zuordnung Epic 3, AD-5) | D-3-konform |
+| Provenienz-Checksumme in `sources` (Vorbereitung Epic 3) | P2 | Eintrag `deferred-work.md` (Zuordnung Story 2.2/Epic 3) — NICHT jetzt implementieren (Schema-Subset §3.3 unverändert) | vertragskonform |
+| Area-Reife für längere fremde Quellen | P3 | Zuordnung Story 2.4 (deterministische Area-Zuordnung) — bis dahin Root-Ebene normativ korrekt (Rev-1.3-Konvention) | Story-2.4-Kontext |
+| Deterministik offener Punkte (`.MD`, `today`-Zeitzone) | P3 | Verweist auf bestehende „Offene Punkte" (F-06/F-08, Validator Rev. 6, §1 Punkt 3/§6.4) — aktuell kein Sonderfall im Bundle | keine neue Festlegung nötig |
+
+## 5. Fazit für den Review
+
+- Der Probelauf ist ein **Positiv-Beleg** für Story 2.1 (R-2 praktisch
+  bestätigt); keine neuen AC- oder Vertrags-Verstöße erkennbar.
+- Die gemeldeten Tooling-Falsch-FAILs sind **Prüfwerkzeug-Lernfälle** (kein
+  Instruktions-/Validator-Defekt) — als Folge-Einträge (`deferred-work.md`),
+  nicht als Findings gegen `schema/*`.
+- Die „Optimierungs-Maßnahmen" sind **Tooling-/Konventions-Ebene** und
+  berühren keine autorisierten Schemata; P1-Punkte sind als dokumentierte
+  Konventionen direkt umsetzbar, P2/P3-Einträge der Story-Zuordnung folgen.

_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md

@@ -2,8 +2,8 @@
 title: 'Concepts aus Source Material erzeugen (OKF-Konform) (Story 2.1)'
 type: 'feature'
 created: '2026-08-16'
-status: 'done'
-review_loop_iteration: 0
+status: 'review'
+review_loop_iteration: 1
 baseline_commit: a67ba659108006a54eb54b84592d1dba046af96e
 context:
   - _bmad-output/implementation-artifacts/epic-2-context.md
@@ -87,6 +87,38 @@ context:
 - 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.
 
+### Review Findings (bmad-code-review, 2026-08-16)
+
+**patch:**
+
+- [x] [Review][Patch] `schema/compiler.md` §1-Überschrift ist Englisch („Input (what the compiler consumes)") — Verstoß gegen eigene Always-Regel „Instruktion … in Deutsch"; fix: `## 1. Input (was der Compiler konsumiert)` [schema/compiler.md:23] — **erledigt, Rev 1.3**
+- [x] [Review][Patch] `schema/compiler.md` enthält „Revision 6"-Referenz auf die Prüfgrundlage, während der Commit `validator.md` Rev 7 liefert — Selbstwiderspruch des Instruktions-Selbstbilds; fix: Revisionszahl angleichen (bzw. bei Rev-7-Rückbau konsistent „Revision 6" lassen) [schema/compiler.md:5, schema/compiler.md:127] — **erledigt, auf Revision 7 angeglichen, Rev 1.3**
+- [x] [Review][Patch] `schema/compiler.md` §6.6-Referenztabelle enthält eine irreführende Zeile: canonical-Key-Reihenfolge wird als „✗"-Abweichung gelistet, aber als „kein FAIL, aber nicht erzeugt" beschrieben und das Label „§6.4" verweist auf eine reine Pfad-Regel (Punkt 4); fix: Zeile aus der ✗-Tabelle herausnehmen (kein Validator-FAIL) bzw. Label auf §4.4 korrigieren [schema/compiler.md:102] — **erledigt: Zeile auf reine ✓-Vorgabe, Label auf §4.2, Rev 1.3**
+- [x] [Review][Patch] `schema/compiler.md` §1.2 vs. §1.4 widersprechen sich: „jede Datei unter `raw/` ist Evidenz" (extensiv) vs. „Artefakt-/Grenzdateien (`raw/README.md`, `raw/**/source.md`) sind KEIN Input" (restriktiv) — neue normative Regel, die so weder im Vertrag noch im Spine noch im Validator steht; fix: in §1.4 die nicht-mechanisch prüfbare Sonderregel als dokumentarische Konvention (nicht als Input-Verdikt) kennzeichnen; alternativ im Change Log als Klarstellung nachführen — **erledigt: §1.2 präzisiert, §1.4 als dokumentarische Konvention gekennzeichnet, Rev 1.3**
+- [x] [Review][Patch] `wiki/log.md`-Einträge weichen vom Vertrags-§5-Beispielformat ab (freie Prosa statt „`- neu:` … angelegt (sources: …)"); keine Maschine prüft das, aber der dokumentierte Doku-Standard wird nicht eingehalten; fix: Einträge an das §5-Beispielformat angleichen [wiki/log.md] — **erledigt: drei Demonstrationslauf-Einträge auf §5-Format umgestellt**
+
+**defer:**
+
+- [x] [Review][Defer] Contract-Verletzung: `schema/validator.md` im Commit mutiert (Rev-7-Notiz §7.3), obwohl Always/Never + AD-3 es als unverändert autorisiert frieren [schema/validator.md:262] — **aufgelöst via Option A (2026-08-16):** `validator.md` bleibt mit Rev-7-Hinweis erhalten (inhaltlich korrekt, kein Rückbau); Heilung über die nächste **autorisierte Validator-Revision** (F-14-Fixture + Innen-Ebenen-Klarstellung dort formal tragen — vgl. `deferred-work.md`); Story 2.1 bleibt bis dahin `in-progress`, Review-Wiedervorlage vor `done`. (Grund: Frieren-Prinzip wahren, ohne die nützliche Klarstellung zu verwerfen.)
+- [x] [Review][Defer] Content-Truth-Verifikation: kein Check verifiziert den Inhalt eines Concepts gegen seine deklarierten `raw/`-Quellen (Verification-Gap) — deferred, Story 2.2 [wiki/*.md]
+- [x] [Review][Defer] Determinismus-Selbsttest-Dokumentation: §6.6-Interpretations-Hinweis behauptet eine starte „genau diese Form", obwohl `generated.at` pro Run variiert (AD-15) — deferred, Story 2.3 [schema/compiler.md:106]
+- [x] [Review][Defer] R-1 (Compiler-Input-Interface): Compiler definiert seine Source-Eingabe als **Menge beliebiger `raw/`-Dateien (Set-Interface)** — Verdikt **Bestanden**. Der übergebene dryrun-Fall „einzelner Pfad" existiert nicht mehr. Empfehlung gemäß Review-Vorgabe ergänzend: den Mechanismus der Source-Auswahl (welche `raw/`-Dateien wann verarbeitet werden) als Konventions-/Erkennungsproblem für Epic 3/AD-5-Home-Story in `deferred-work.md` festhalten — Firm-Zwang, die „Run-ohne-Pfad"-Lücke der Nutzererwartung bleibt offen (Story 3.1/3.2) — deferred, Epic 3
+- [x] [Review][Defer] R-2 (Nicht-Markdown-Quellen): Compiler-Instruktion liest Sources **endungsneutral als Datei** (§1.2/§1.4, Verdikt **Bestanden**); die Konventions-/Asset-Zuordnungsfrage für PDF bleibt als dokumentierte Konvention offen — deferred, Epic 2/3 [raw/README.md]
+
+### Re-Review Verifikationsvermerk (bmad-code-review, 2026-08-16)
+
+Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifiziert, kein neuer Bruch:
+
+- ✅ P-1..P-5 (compiler.md Rev 1.3, log.md §5-Format, spec-status, deferred-work, sprint-status) sauber umgesetzt und im Working Tree verifiziert.
+- ✅ **AC-Abgleich** gegen `epics.md` Story 2.1: unverändert gültig (type-Pflicht, §3-Subset, v1-Trust `generated {by,at}` ohne `verified`, Wissenseinheiten ≠ 1:1, Index-Pflicht, kein Area, D-3-Textinstruktion) — kein neuer Verstoß durch die Patches.
+- ✅ **Validator-Run gegen das Bundle** (gemäß `schema/validator.md`): **SUCCESS für alle 5 Bundle-Dateien** (`index.md`, `log.md`, 3 Concepts) — Points 1–14 ✔, V-1/V-2 ✔, EC-1/EC-3/EC-11 ✔, Punkt 11 (alle 3 Identitäten verlinkt) ✔. Keine Abweichung.
+- ✅ **AD/Provenienz:** AD-3 (`raw/` unangetastet, leerer Diff), AD-5 (nur neue Root-Concepts), AD-10 (`adapters/` unverändert, keine abweichende Knowledge-Semantik), D-3 (rein textuell, kein Executable-Block), AD-4b (alle `sources[].resource` → existierende `raw/`-Dateien, nie `wiki/`), v1-Default (`generated` gesetzt, `verified` ungesetzt).
+- ✅ **R-1** (Menge von Source-Pfaden, Set-Interface — compiler.md §1.2 definiert die gesamte evidierenfähige `raw/`-Menge; Einzelpfad-Interface existiert nicht): **Bestanden**, kein Finding. Erkennungs-Mechanismus bewusst deferriert (AD-5-Home-Story, Epic 3, Story 3.1/3.2).
+- ✅ **R-2** (Nicht-Markdown-Quellen): Instruktion liest Sources endungsneutral als Datei (Vertrag §3.3: nur Dateipfad unter `raw/`; Validator EC-1: nur Existenz); PDF zulässig; §1.4 dokumentarische Konvention (§1.2/§1.4-Widerspruch via Rev 1.3 Patch #4 sauber aufgelöst, kein neuer Bruch): **Bestanden**.
+- ✅ **Option A intakt (Re-Re-Review, 2026-08-17):** `validator.md` Rev-7-Notiz unverändert erhalten (kein Rückbau); `done`-Fähigkeit war korrekt an die nächste autorisierte Validator-Revision gekoppelt. **Diese Revision ist jetzt ausgeführt:** **Revision 8 (2026-08-16, Autorisations-Runde)** trägt formal die F-14-Negativ-Fixture 4a (§7.1, Punkt 4: `resource` außerhalb `raw/`), die Innen-Ebenen-Key-Subset-Klarstellung (Punkt 6 → §7.3-Isolations-Notiz) und die Header-Anhebung „Revision 6" → „Revision 8" (OBS-1). Zertifizierung selbstgeprüft PASS: Fixture 4a isoliert → FAIL Punkt 4; Innen-Ebenen-Sample → FAIL Punkt 6 (Key=role); reales Bundle → SUCCESS. Vertrag `schema/wiki-compiler.md` und `schema/compiler.md` unverändert.
+
+**Verdikt (Re-Re-Review, 2026-08-17):** Die offene Option-A-Voraussetzung ist **erfüllt** — die autorisierte Validator-Revision 8 ist ausgeführt und zertifiziert. Story 2.1 ist damit **`review`-fähig und `done`-fähig**; keinerlei AC-/Vertrags-Blocker in den Story-Artefakten, keine neuen Findings aus den Nachzieh-Patches. Verbleibende Schwelle bis `done` ist ausschließlich die **menschliche Review-Freigabe** (Human-Review, Status `review` → `done`), nicht mehr eine technische Voraussetzung.
+
 ## Spec Change Log
 
 - (leer bis zum ersten Review-Loopback)

_bmad-output/implementation-artifacts/sprint-status.yaml

@@ -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 11:48
+last_updated: 08-17-2026 05:40
 project: wow20
 project_key: NOKEY
 tracking_system: file-system
@@ -149,3 +149,20 @@ action_items:
       mit Epic-/Validator-Zuordnung notiert; F-06/F-08 zusaetzlich im Validator Rev. 6 als
       'Offene Punkte' verankert."
     ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-04"
+  - id: "code-review-2-1-item-1-autorisierte-validator-revision-option"
+    epic: 2
+    action: "Autorisierte Validator-Revision starten (Option-A-Heilung fuer Story 2.1):
+      1) F-14-Negativ-Fixture (resource ausserhalb raw/, existiert) ergaenzen;
+      2) Innen-Ebenen-Key-Subset-Klarstellung (Punkt 6 in sources/generated/verified)
+         formal tragen (bisher unautorisierte Rev-7-Notiz);
+      3) Validator-Header-Revisionszahl anheben (Header 'Revision 6' vs. Revisionslog
+         'Revision 7', OBS-1). Danach Story 2.1 zur Review-Freigabe wiedervorlegen."
+    owner: "dev"
+    status: done
+    closed: "2026-08-16"
+    resolution: "schema/validator.md auf Revision 8: F-14-Fix-Fixture 4a (§7.1, Punkt 4),
+      Innen-Ebenen-Key-Subset formalisiert (Punkt-6-Zelle verweist auf §7.3, autorisiert),
+      Header-Revisionszahl auf 8 angehoben (OBS-1 behoben). Zertifizierung PASS (Fixture
+      4a FAIL Punkt 4; Innen-Ebenen FAIL Punkt 6; reales Bundle SUCCESS). Story 2.1
+      zur Review-Freigabe wiedervorgelegt (status: review)."
+    ref: "_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md"

_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md

@@ -0,0 +1,79 @@
+---
+title: 'Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren (Option-A-Heilung Story 2.1)'
+type: 'authorization-round'
+created: '2026-08-16'
+status: 'draft'
+based_on_commit: f91ef89078ee8e4c8a979cfb70f20ead1ffe854b
+related:
+  - _bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md
+  - _bmad-output/implementation-artifacts/deferred-work.md
+---
+
+# Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren
+
+> **Zweck:** Heilt die offene Option-A-Voraussetzung von Story 2.1 (Review vom 2026-08-16) über den **autorisierungsfähigen** Kanal (Frieren-Prinzip wahren). `schema/validator.md` wird erst **in dieser Revision** verändert — die heute im Revisionslog als unautorisierte Notiz geführte Rev-7-Klarstellung wird damit formal getragen, die Revisionszahl im Header angehoben und die von Retrospective F-14 geforderte Negativ-Fixture ergänzt.
+
+## Warum Revision 8 (nicht 7)?
+
+Der Revisionslog (§8) führt bereits einen Eintrag „Revision 7" (2026-08-16, Step-04-Review Story 2.1) — er ist inhaltlich korrekt, aber als **unautorisierte Mutation** in den Commit gelangt. Der Revisionslog ist append-only; die Rev-7-Notiz bleibt als Historie erhalten. Die **nächste autorisierte Revision** wird daher **Revision 8**: Ihr Logeintrag formalisiert die Rev-7-Klarstellung und die F-14-Fixture, der Header wird auf **8** angehoben (behebt damit zugleich OBS-1: Header „Revision 6" vs. Revisionslog „Revision 7").
+
+## Geltungsbereich
+
+**Genau eine Datei wird geändert:** `schema/validator.md`.
+**Unverändert (nicht anfassen):** `schema/wiki-compiler.md` (autorisiert, Story 1.3), `schema/compiler.md` (Rev 1.3, bereits committet), `raw/` (immutable, AD-3), `adapters/`, alle `wiki/`-Dateien.
+
+## 1. F-14-Negativ-Fixture ergänzen (§7.1, Punkt 4)
+
+Retrospective F-14: Ein `resource`-Pfad, der **außerhalb `raw/` landet, aber existiert** (z. B. `README.md` an der Workspace-Root), hat kein Negativ-Fixture; §6.2 Schritt 5 deckt den Fall, §7.1-Fixtures belegen ihn nicht.
+
+**Patch:** In der §7.1-Fixture-Tabelle (nach Zeile Punkt 4, als `4a`) ergänzen:
+
+```text
+| 4a | `sources: [{resource: README.md}]` (Datei `README.md` existiert an der Workspace-Root, ausserhalb `raw/`) | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)` |
+```
+
+**Isolations-Prinzip:** Sample ist sonst-valide (Punkt 3 passiert, da nicht `wiki/`; alle übrigen Punkte ok) → genau Punkt 4 löst aus.
+
+## 2. Innen-Ebenen-Key-Subset formal tragen (§7.3 / Punkt 6)
+
+Die Rev-7-Notiz wird von „dokumentarische Klarstellung (keine Autorisierung nötig)" zur **formal getragenen Regel** dieser Revision aufgewertet:
+
+**Patch (redaktionell, §7.3-Einleitung als Teil der Revision):** Der bestehende Isolations-Hinweis zur Innen-Ebenen-Punkt-6-Abdeckung (bereits im Text vorhanden, unter der filigranen Notiz von Rev 7) wird als **ordentlicher, autorisierter Inhalt** der Revision 8 geführt — inhaltlich identisch, lediglich als legitimierter Bestandteil (nicht mehr „nur dokumentarisch"). Zusätzlich wird die Punkt-6-Prüfschritt-Zelle (§3-Tabelle, Zeile 6) um den expliziten Verweis „Innen-Ebenen: §7.3-Isolations-Notiz (autorisiert, Revision 8)" ergänzt, damit die mechanische Prüfung unzweideutig auf die Innen-Ebenen-Fälle verweist.
+
+## 3. Validator-Header anheben (OBS-1) + Revisionslog nachführen
+
+**Patch §0-Header:**
+- `> **Validator-Revision:** 6` → `> **Validator-Revision:** 8`
+- `> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 6 — …)` → `2026-08-16 (Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisiert; Option-A-Heilung Story 2.1)`
+
+**Patch §8-Revisionslog (append-only, neuer Eintrag):**
+
+```text
+- **Revision 8 (2026-08-16, Autorisations-Runde):** Option-A-Heilung Story 2.1 — drei Änderungen: (1) F-14-Negativ-Fixture 4a ergänzt (§7.1, Punkt 4: `resource` außerhalb `raw/`, aber existierend, z. B. `README.md`; Retrospective F-14); (2) Innen-Ebenen-Key-Subset-Klarstellung (Punkt 6 in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) als formal getragener Inhalt bestätigt — formalisiert die Rev-7-Notiz (die bislang als unautorisierte Mutation geführt war) und verankert den §7.3-Isolations-Hinweis als autorisierten Bestandteil; Punkt-6-Zelle um Innen-Ebenen-Verweis ergänzt; (3) Header-Revisionszahl von „Revision 6" auf „Revision 8" angehoben (behebt die pre-existing Header-Log-Diskrepanz, OBS-1). Vertrag `schema/wiki-compiler.md` unverändert (keine Vertrags-Autorisierung nötig — Punkt 6 deckt Innen-Ebenen bereits, §3.3–§3.5).
+```
+
+## 4. Zertifizierung (Pflicht, wie bei Revisions 3–6)
+
+Gemäß Validator-Zertifizierungs-Kultur (F-02, wiki/log.md) ist die Revision **mechanisch zu belegen**:
+
+1. **F-14-Fixture 4a isoliert:** Sample `sources: [{resource: README.md}]` mit existierender `README.md` an der Workspace-Root gegen den revidierten Validator ausführen → erwartet `FAIL … Punkt 4: resource ausserhalb raw/ …`, **kein** Vorab-FAIL durch andere Punkte.
+2. **Punkt 6 Innen-Ebenen isoliert:** `sources:\n  - resource: raw/prd/prd-wow20-2026-08-14.md\n    role: x` gegen den revidierten Validator → erwartet `FAIL … Punkt 6: … unautorisierter Key in sources/generated/verified` (sonst-valides Sample).
+3. **Regression auf das reale Bundle:** Validator-Run gegen alle 5 `wiki/`-Dateien → weiterhin **SUCCESS für alle** (keine neu ausgelösten FAILs durch die Fixture-/Hinweis-Änderung; die Revision fügt keine neue §7-Invaliditätsklasse hinzu → Abschluss-Eigenschaft gewahrt).
+4. Ergebnis der Zertifizierung in `wiki/log.md` dokumentieren (datumsgruppiert, §5-Format).
+
+## 5. Folge-Tracking nach Autorisierung
+
+Nach erfolgreicher Ausführung + Zertifizierung:
+
+1. `sprint-status.yaml` — Action-Item `code-review-2-1-item-1-autorisierte-validator-revision-option` → `status: done`, `closed: <datum>`, `resolution:` mit Rev-8-Nummer + `ref` auf diese Datei.
+2. **Story 2.1 freigeben** — in `spec-2-1-…okf-konform.md`: Re-Review-Verdikt-Absatz finalisieren („Option A erfüllt: next authorized revision = Rev 8, tragen F-14 + Innen-Ebenen + Header"), `status: in-progress → review` (Human-Review), danach `done`.
+3. `sprint-status.yaml` — Story 2.1 `2-1-concepts-…`: `in-progress → review → done` (je nach Ablauf); `epic-2` bleibt `in-progress`.
+4. `wiki/log.md` — Einträge für Validator-Rev-8-Zertifizierung und Story-2.1-Freigabe.
+5. `deferred-work.md` — Defer/Sektion „Arbeitsauftrag" bleibt als Historie; kein Rückbau.
+
+## Erfolgskriterien (Definition of Done dieser Runde)
+
+- [ ] `schema/validator.md` trägt Revision 8: Header `8`, Revisionslog-Eintrag Rev 8, Fixture 4a, Innen-Ebenen-Verweis in Punkt-6-Zelle; §7-Katalog weiterhin abschließend (kein neuer Punkt 15).
+- [ ] Zertifizierung 1–3 dokumentiert (Fixture 4a FAIL, Innen-Ebenen Punkt 6 FAIL, reales Bundle SUCCESS).
+- [ ] `schema/wiki-compiler.md`, `schema/compiler.md`, `raw/`, `adapters/`, `wiki/`-Concepts unverändert (außer `wiki/log.md`-Einträge).
+- [ ] Sprint-Tracking aktualisiert (Action-Item done, Story 2.1 `done` nach Human-Review).

schema/compiler.md

@@ -2,7 +2,7 @@
 
 > **Status:** abgeleitet (Story 2.1) — deterministische, agent-unabhängige Compiler-Instruktion für die Erzeugung neuer Concepts aus Source Material.
 > **Normative Grundlage:** `schema/wiki-compiler.md` (autorisiert, Story 1.3) — insbesondere §2 Bundleroot, §3 Feldsubset (§3.1–§3.7), §5 `log.md`-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
-> **Prüfgrundlage:** `schema/validator.md` (abgeleitet, Story 1.4; Revision 6) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h).
+> **Prüfgrundlage:** `schema/validator.md` (abgeleitet, Story 1.4; Revision 7) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h).
 > **Ableitungsdatum:** 2026-08-16
 > **Kanonischer Producer-Actor:** `wow-compiler/0.1.0`
 
@@ -20,12 +20,12 @@ 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. Input (was der Compiler konsumiert)
 
 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.
+2. **Evidenz:** Das Source Material unter `raw/` — jede Datei unter `raw/`, die als evidierenfähige Source verarbeitet wird, 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.
+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. (Dokumentarische Konvention der Source-Bereitstellung nach `raw/README.md` — eine nicht-mechanische Ausnahme zur Evidenz-Erwartung; zu verarbeitende Evidenz kann auch andere Aufträge als `.md` tragen, z. B. PDF.)
 
 ## 2. Interpretieren (Wissenseinheiten erkennen)
 
@@ -96,13 +96,13 @@ Die folgende Tabelle macht jede Erzeugungsregel dieser Instruktion reproduzierba
 | §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 canonical Key-Reihenfolge (Validator §4.1) | `type` → `sources` → `generated` | — (kein Validator-FAIL: Reihenfolge ist Output-Normalform, kein §7-Punkt; der Compiler erzeugt sie deterministisch und die Normalform-Abweichung tritt damit nicht auf) |
 | §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 |
+| §4.2 Alle-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.
@@ -124,7 +124,7 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begren
 **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).
+- `schema/validator.md` — Prüfgrundlage (Story 1.4, Revision 7): §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.
@@ -134,3 +134,4 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begren
 - **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.
+- **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).

schema/validator.md

@@ -2,9 +2,9 @@
 
 > **Status:** abgeleitet (Story 1.4) — deterministische, agent-unabhängige Validierungs-Instruktion auf Basis des autorisierten Schema-Vertrags.
 > **Normative Grundlage:** `schema/wiki-compiler.md` (autorisiert, Story 1.3) — insbesondere §1 Geltungsbereich, §2 Bundleroot/Frontmatter, §3 Feldsubset (§3.3–§3.7), §5 `log.md`-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste struktureller Invalidität, §8 Normreferenzen.
-> **Validator-Revision:** 6 (Revisionslog in §8)
+> **Validator-Revision:** 8 (Revisionslog in §8)
 > **Ableitungsdatum:** 2026-08-15
-> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 6 — Retrospective F-01/AI-1, F-02/AI-2, F-03/AI-3, F-05/AI-5)
+> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisiert; Option-A-Heilung Story 2.1)
 
 ## 0. Zweck & Aufruf
 
@@ -62,7 +62,7 @@ Wert-Semantik des YAML-Checks: Frontmatter ist als YAML zu parsen. Wiederholte F
 | 3 | `sources`-`resource` löst auf einen `wiki/`-Concept-Pfad auf | Concept-Frontmatter, je `sources[].resource` | Löst der (bereinigte, §6.2) Pfad relativ zur Workspace-Root auf einen Pfad auf, der **innerhalb** `wiki/` liegt? | `Punkt 3: resource loest auf wiki/-Concept-Pfad (Pfad=<resource>)` |
 | 4 | `sources`-`resource` landet bei Auflösung außerhalb `raw/` (inkl. `..`-Traversal) oder ist URL-Form; zudem Verstöße der Pfad-Grammatik | Concept-Frontmatter, je `sources[].resource` | Enthält der `resource`-Wert `..`-Path-Segment, führenden `/`, `file://`-Präfix, Backslash/Windows-Trenner, oder einen absoluten/URL-Form-Wert (`http://`, `https://`, etc.) ODER liegt der aufgelöste Pfad außerhalb `raw/`? | `Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal|absolut|URL|Backslash|file://)` |
 | 5 | verbotener `status`-Wert | Concept-Frontmatter | Ist `status` gesetzt und **nicht** ∈ {`draft`, `stable`, `deprecated`}? | `Punkt 5: verbotener status-Wert (Wert=<status>)` |
-| 6 | nicht autorisiertes Frontmatter-Feld oder unautorisierter Key in `sources`/`generated`/`verified`-Eintrag | Concept- & Bundleroot-Frontmatter | Enthält das Frontmatter ein Feld außerhalb des erlaubten Subsets (Concept: `type`/`sources`/`generated`/`verified`/`status`/`stale_after`; Bundleroot: `type`+`okf_version`)? ODER enthält ein `sources`-Eintrag Keys außerhalb {`resource`,`id`,`title`,`author`,`usage_count`,`last_modified`}; ein `generated` Keys außerhalb {`by`,`at`}; ein `verified`-Eintrag Keys außerhalb {`by`,`at`}? **Exemption:** `okf_version` und `type: bundle` sind von der Punkt-6-Subset-Prüfung ausgenommen und werden ausschließlich über Punkt 8/9 geprüft (Entscheidungsnotiz unter dieser Tabelle). | `Punkt 6: nicht autorisiertes Feld (Key=<key>) bzw. unautorisierter Key in sources/generated/verified` |
+| 6 | nicht autorisiertes Frontmatter-Feld oder unautorisierter Key in `sources`/`generated`/`verified`-Eintrag | Concept- & Bundleroot-Frontmatter | Enthält das Frontmatter ein Feld außerhalb des erlaubten Subsets (Concept: `type`/`sources`/`generated`/`verified`/`status`/`stale_after`; Bundleroot: `type`+`okf_version`)? ODER enthält ein `sources`-Eintrag Keys außerhalb {`resource`,`id`,`title`,`author`,`usage_count`,`last_modified`}; ein `generated` Keys außerhalb {`by`,`at`}; ein `verified`-Eintrag Keys außerhalb {`by`,`at`}? **Exemption:** `okf_version` und `type: bundle` sind von der Punkt-6-Subset-Prüfung ausgenommen und werden ausschließlich über Punkt 8/9 geprüft (Entscheidungsnotiz unter dieser Tabelle). Innen-Ebenen: siehe §7.3-Isolations-Notiz (autorisiert, Revision 8). | `Punkt 6: nicht autorisiertes Feld (Key=<key>) bzw. unautorisierter Key in sources/generated/verified` |
 | 7 | leere/fehlende `by`-Angabe in `generated` oder `verified` | Concept-Frontmatter | Ist `generated.by` nicht gesetzt ODER leer ODER reiner Whitespace? Gleiches je `verified[].by`? | `Punkt 7: leere/fehlende by-Angabe in generated/verified` |
 | 8 | Bundleroot `wiki/index.md` ohne `type: bundle`/`okf_version: "0.2"` oder abweichender `okf_version`-Wert | Bundleroot `wiki/index.md` | Fehlt der Frontmatter-Block `---` (Erkennung auf dem gestrippten Dateianfang, §3-Präambel) ODER fehlt `type: bundle` (exakt dieser Wert) ODER fehlt `okf_version: "0.2"` (nur der Stringliteral `0.2` zulässig, z. B. NIE `0.3`)? | `Punkt 8: Bundleroot ohne type: bundle/okf_version \"0.2\" oder falscher okf_version-Wert` |
 | 9 | `okf_version: "0.2"` oder `type: bundle` außerhalb der Bundleroot | jede `.md`-Datei außer `wiki/index.md` im Bundle (Area-`index.md`, `log.md`, Concepts) | Kommt `okf_version: "0.2"` (§2-Wert) oder `type: bundle` **irgendwo im Dateiinhalt** einer dieser Dateien vor (nicht nur im Frontmatter)? Maßgeblich ist der Vertragswortlaut „darf … in irgendeiner anderen Bundle-Datei vorkommen" (§2/§7 Punkt 9). — Entscheidungsnotiz zu Punkt 6/9 siehe unter dieser Tabelle. | `Punkt 9: okf_version/type: bundle ausserhalb der Bundleroot (Datei=<pfad>)` |
@@ -211,6 +211,7 @@ Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte (§7.1/§7.2) **s
 | 2 | `.md` unter `wiki/` ohne `---`-Frontmatter | `FAIL wiki/x.md Punkt 2: nicht-reservierte .md-Datei ohne Frontmatter/ohne type` |
 | 3 | `sources: [{resource: wiki/foo.md}]` | `FAIL wiki/x.md Punkt 3: resource loest auf wiki/-Concept-Pfad (Pfad=wiki/foo.md)` |
 | 4 | `sources: [{resource: ../outside.md}]` | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal\|absolut\|URL\|Backslash\|file://)` |
+| 4a | `sources: [{resource: README.md}]` (existiert an der Workspace-Root, ausserhalb `raw/`; Kein `..`/URL/Backslash — Punkt 4 durch aufgelöste Lage) | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)` |
 | 5 | `status: published` | `FAIL wiki/x.md Punkt 5: verbotener status-Wert (Wert=published)` |
 | 6 | Concept mit `foo: bar` (nicht autorisiert) | `FAIL wiki/x.md Punkt 6: nicht autorisiertes Feld (Key=foo)` |
 | 7 | `generated: {at: 2026-08-15T10:00:00Z}` (ohne `by`) | `FAIL wiki/x.md Punkt 7: leere/fehlende by-Angabe in generated/verified` |
@@ -304,3 +305,4 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
 - **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).
+- **Revision 8 (2026-08-16, Autorisations-Runde):** Option-A-Heilung Story 2.1 — drei Änderungen: (1) **F-14-Negativ-Fixture 4a** ergänzt (§7.1, Punkt 4: `resource` außerhalb `raw/`, aber existierend, z. B. `README.md` an der Workspace-Root; Retrospective F-14) — erwartet `FAIL … Punkt 4`, Isolations-Prinzip gewahrt; (2) **Innen-Ebenen-Key-Subset formalisiert** — die Rev-7-Klarstellung (Punkt 6 in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) wird als formal getragener Inhalt dieser autorisierten Revision bestätigt, und die Punkt-6-Zelle verweist explizit auf die §7.3-Isolations-Notiz (autorisiert, Revision 8); (3) **Header-Revisionszahl** von „Revision 6" auf „Revision 8" angehoben (behebt die pre-existing Header-Log-Diskrepanz, OBS-1). Vertrag `schema/wiki-compiler.md` unverändert (keine Vertrags-Autorisierung nötig — Punkt 6 deckt Innen-Ebenen bereits, §3.3–§3.5).

wiki/log.md

@@ -1,8 +1,15 @@
 # Log
 
+## 2026-08-17
+- **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`.
+
 ## 2026-08-16
+- Autorisierte Validator-Revision 8 (Option-A-Heilung Story 2.1): `schema/validator.md` Revisionslog-Eintrag „Revision 8" + Header-Revisionszahl auf 8 angehoben (behebt OBS-1: Header „Revision 6" vs. Log „Revision 7"). Drei Änderungen: (1) F-14-Negativ-Fixture 4a in §7.1 (Punkt 4: `resource: README.md` außerhalb `raw/`, existierend → `FAIL … Punkt 4`; Retrospective F-14); (2) Innen-Ebenen-Key-Subset formalisiert — Punkt-6-Zelle verweist auf die §7.3-Isolations-Notiz (autorisiert, Revision 8); (3) Revisionslog nachgeführt. Vertrag `schema/wiki-compiler.md` und `schema/compiler.md` unverändert (keine neue §7-Invaliditätsklasse). Zertifizierung selbstgeprüft: Fixture 4a isoliert → FAIL Punkt 4 (resolved=README.md) (Punkt 3 nicht verletzt, keine anderen Punkte); Innen-Ebenen-Sample (`sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei) → FAIL Punkt 6 (Key=role); reales Bundle (5 `wiki/`-Dateien) → SUCCESS (keine neu ausgelösten FAILs).
+ `schema/compiler.md` auf Revision 1.3 — §1-Überschrift ins Deutsche, Prüfgrundlage auf validator.md Revision 7 angeglichen, §6.6-canonical-Reihenfolge-Zeile von ✗- auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Label §4.2 statt „§6.4"), §1.2/§1.4-Evidenz-Widerspruch aufgelöst (Artefakt-Ausnahme als dokumentarische Konvention). `wiki/log.md`-Demonstrationslauf-Einträge an Vertrags-§5-Format angeglichen (`- neu:` … angelegt (sources: …)). Story 2.1 bleibt `in-progress` (Option A: Heilung der validator.md-Rev-7-Klarstellung über die nächste autorisierte Validator-Revision).
 - 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.
+- neu: `llm-wiki-prinzip` angelegt (sources: raw/prd/prd-wow20-2026-08-14.md) — Root-Concept, Trust-Metadaten A0-20 (`generated { by: wow-compiler/0.1.0, at: <ISO-8601-Datetime> }`, `verified` ungesetzt)
+- neu: `knowledge-kompilation-inkrementell` angelegt (sources: raw/epics/epics-2026-08-14.md) — Root-Concept, Trust-Metadaten A0-20
+- neu: `wissensarchitektur-trennung-states` angelegt (sources: raw/architecture-spine/architecture-spine-2026-08-14.md) — Root-Concept, Trust-Metadaten A0-20
 - 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).