feat: Story 2.1 auf done setzen (Human-Review-Freigabe) + Re-Run-Patches Rev 1.4

Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» ist done:
- spec-2-1: status review -> done + Change-Log-Eintrag
- sprint-status.yaml: Story 2.1 -> done, last_updated 08-17 07:35
- wiki/log.md: done-Eintrag (Human-Review-Freigabe)
- open bleibt: Action-Item code-review-2-1-item-2 (Validator-Rev 9, kein Blocker)

Umsetzung der Unabhängig-Re-Run-Patches (4 Layer, 15/17):
- schema/compiler.md -> Revision 1.4 (Pruefgrundlage Rev 8, §6.6-Labels §4.5/§4.2,
  §3.2 Kollision-Hold-Run-Fortsetzung, §5.3/§6.3 Rollback-Sequenz, Sprachkorrekturen)
- wiki/index.md Baumdiagramm um Root-Concepts-Ebene
- deferred-work Dedupe + n=21, review-input-dryrun Aufloesung, epic-2-context
  AD-4c tautologisch, validator-revision-8 status done/DoD, spec Verification

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

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

@@ -115,13 +115,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 
 > **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".
+> **Dedupe-Verweis (bmad-code-review Re-Run, 2026-08-17):** „Content-Truth-Verifikation einführen" und „Determinismus-Selbsttest-Dokumentation schärfen" wurden am 2026-08-16 bereits im Block „Folge-Aufgaben aus Story-2.1-Review (Defer-Kontexte; 2026-08-16)" oben erfasst (gleicher Tag, nahezu identischer Text, nur anderes `source_spec`-Label). Die Ownership liegt dort; dieser Code-Review-Block trägt beide Punkte **nicht** ein zweites Mal (vermeidet Doppel-Erledigung). Konkret: Content-Truth → Story 2.2; Determinismus-Selbsttest → Story 2.3 / nächste Validator-Revision.
 
 - 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).
@@ -150,7 +144,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 > **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).
+  summary: Fixture-Selbsttest des Validator-Prüfwerkzeugs vor jedem Bundle-Lauf etablieren (P1) — jede Negativ-Fixture (`validator.md` §7.1, n=21) 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)
@@ -168,3 +162,28 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
   summary: 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).
+
+## Deferred from: code review of story-2.1 (2026-08-17)
+
+> **Unabhängiger Re-Run (bmad-code-review, 2026-08-17)** auf dem Stand nach Validator-Rev-8 (HEAD `ae5e0aa`). Die tragenden Story-2.1-Artefakte sind validator-clean (alle 8 ACs PASS); die Defer-Einträge unten sind bewusst nicht in Story 2.1 behobene bzw. vorbestehende Punkte.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
+  summary: Content-Truth-Verifikation — keine Änderung zum bereits deferrierten Punkt (Story 2.2), aber der Re-Run liefert eine konkrete, prüfbare Instanz: das ASCII-Datenfluss-Diagramm-Layout in `wiki/knowledge-kompilation-inkrementell.md` stammt aus `raw/architecture-spine/…`, während das Concept `sources: raw/epics/…` deklariert (Inhalt kuratiert/korrekt, nur die exakte Diagrammform nicht von der deklarierten Source gedeckt).
+  evidence: Acceptance-Auditor (Informational) + Blind Hunter; die anderen beiden Concepts sind vollständig in ihren deklarierten Sources verankert.
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
+  summary: Concept-Bodies präsentieren Epic-3/4-Fähigkeiten als aktuelle Tatsache ohne Forward-Referenz-Marker — `knowledge-kompilation-inkrementell.md`: „Verbindung zu Regelwerken" (NEW/CONFIRMING-CORRECTING-Klassifikation, grep/ripgrep-Relevanzbestimmung → Story 3.2/4.1) und „FR-6 Aktualisierung statt neuer Dateien" (→ Story 3.1, die `compiler.md` §7 explizit nicht baut und deren Kollision-Hold §3.2 auf bestehendem Pfad abbricht). Zu markieren, sobald die Claim-Provenienz-/Kontext-Marker-Logik (Story 2.2) existiert.
+  evidence: Blind Hunter (2 Einzelfindings); Epic-3/4-Zuordnung belegt in `raw/epics/…` (Story 3.1/3.2, 4.1).
+
+- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
+  summary: `wiki/log.md` akkumuliert Meta-/Prozess-Einträge (Review-Verdikt, Action-Item-Statusflips, Validator-Revision-Ankündigungen) ohne Marker, der sie von Vertrag-§5-„fachlichen Änderungen" unterscheidet — vorbestehendes Muster (die Retrospective-Follow-up-Einträge tun dasselbe), nicht neu durch diesen Diff verursacht; F17 defert Log-Content-Validierung bewusst.
+  evidence: Blind Hunter; pre-existing.
+
+### Geholderte validator.md-Patches — Arbeitsauftrag für die nächste autorisierte Validator-Revision (Rev 9)
+
+> **Herkunft:** Unabhängiger bmad-code-review Re-Run (2026-08-17), Patches 16/17. Beide betreffen die am 2026-08-17 autorisierte, gefrorene `schema/validator.md` (Rev 8) — ihre Anwendung setzt einen **neuen Autorisierungsschlag** auf `schema/` voraus und wurde im Re-Run bewusst **nicht** mitgepatcht (Frieren-Prinzip, Analogie zur Option-A-Heilung F-14). `validator.md` selbst bleibt bis zur autorisierten Revision unverändert.
+
+- summary: **1. Punkt-4-Fehlerursachen-Grammatik um `resolved=`-Token erweitern** — Fixture 4a (§7.1) erwartet `FAIL … Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)`, aber die §3-Punkt-4-Vorlage `(..-Traversal|absolut|URL|Backslash|file://)` trägt kein `resolved=`-Token; §7 verlangt „exakt die aus §3". In der autorisierten Revision die Punkt-4-Vorlage um ein optionales `resolved=<Pfad>`-Token ergänzen (oder die Fixture-Vorlage an die Vorlage angleichen) + Zertifizierung der Fixture 4a (isoliert, genau Punkt 4) neu ausführen.
+- 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`.

_bmad-output/implementation-artifacts/epic-2-context.md

@@ -36,7 +36,7 @@ Aus dem lokal bereitgestellten Source Material (Epic 1) entstehen eigenständige
 
 ## Cross-Story Dependencies
 
-- Setzt Workspace-Trennung, Bundle-Root und das OCKF-Feldsubset aus Epic 1 (Story 1.1, 1.3, 1.4) voraus; die Schema-Validierung von Story 1.4 erzwingt auch AD-4c (keine abgeleitete Provenienz).
+- Setzt Workspace-Trennung, Bundle-Root und das OCKF-Feldsubset aus Epic 1 (Story 1.1, 1.3, 1.4) voraus. AD-4c (keine abgeleitete Provenienz) ist in v1 tautologisch erfüllt — `sources` zeigt ausschließlich auf `raw/`, daher kann kein generiertes Concept ein anderes generiertes Concept als alleinige Provenienz führen (Vertrag §6.1: erzeugt **kein** eigenes Validitätsprädikat; kein eigener Validator-Check).
 - Die hier erzeugten Concepts, Links und `index.md`-Strukturen sind die Eingabe für die inkrementelle Kompilation und Synthese (Epic 3) sowie für Widerspruchs- und Kuratierungs-Kontexte (Epic 4).
 - Identität und Verlinkung dieses Epics werden von den Consumers in Epic 5 unverändert gelesen.
 - Keine UX-/Design-Anteile relevant für diesen Epic: v1 ist datei-/CLI-basiert ohne GUI (A-3, AD-11).

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

@@ -29,8 +29,10 @@ scope: review-context
   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.
+  alle 18 Sandbox-Bundle-Dateien (0 FAIL): 16 Root- (5 reale + 11 radium-) + 2
+  `spring/`-Dateien.
+  Darunter die 5 realen Bundle-Dateien zuzüglich 11 radium- + 2 spring-Dateien
+  (= 16 Root- + 2 spring/ = 18).
 - **`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).

_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: 'review'
-review_loop_iteration: 1
+status: 'done'
+review_loop_iteration: 2
 baseline_commit: a67ba659108006a54eb54b84592d1dba046af96e
 context:
   - _bmad-output/implementation-artifacts/epic-2-context.md
@@ -119,9 +119,40 @@ Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifizier
 
 **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
+### Review Findings (bmad-code-review, 2026-08-17 — unabhängiger Re-Run auf dem Stand nach Validator-Rev-8)
 
-- (leer bis zum ersten Review-Loopback)
+**Kernbefund:** Alle 8 Acceptance Criteria **PASS**; die tragenden Story-2.1-Artefakte (compiler.md, 3 Concepts, index/log, validator Rev 8) sind validator-clean (`raw/` unangetastet, keine Area-Verzeichnisse, kein Executable-Code, keine unautorisierten Keys in keiner Ebene, EC-1/Punkt 11 erfüllt). Kein `high`. Die Findings sind Doku-/Referenz-Konsistenz, zwei Instruction-Vollständigkeits-Lücken und ein `medium`-Governance-Item. Unabhängig verifiziert, nicht aus dem Vordingsvermerk übernommen.
+
+**patch:**
+
+- [x] [Review][Patch] `schema/compiler.md` §0/§8 nennt die Prüfgrundlage `validator.md` „Revision 7", aber der Validator ist jetzt **Revision 8** — die von OBS-1 geschlossene Referenzkette ist damit nur halbschließend (3 Layer: Blind + Acceptance + Verification-Gap) [schema/compiler.md:5, schema/compiler.md:127]
+- [x] [Review][Patch] `wiki/log.md` (2026-08-16): die `schema/compiler.md`-Rev-1.3-Zeile hat ihren `-`-Bullet verloren (nur führendes Leerzeichen) und rendert als Fortsetzung des Rev-8-Eintrags — zwei Ereignisse in einem Listeneintrag, bricht die §5-Flach-Bullet-Konvention, die dieser Diff selbst in Patch #5 durchgesetzt hat [wiki/log.md:8]
+- [x] [Review][Patch] `schema/compiler.md` §6.6: Referenz-Labels in 4 Zeilen falsch („§4.4 canonical Key-Reihenfolge", „§4.4 keine Duplikat-Keys", „§4.4 sources-Eintrag-Key-Subset", „§4.4 kein okf_version") — aber §4.4 dieser Datei ist die `status`/`stale_after`-Regel; canonical-order ist §4.5, sources-Key-Subset ist §4.2. Die Rev-1.2-Logzeile dokumentiert, das Label sei „von §4.5 auf §4.4 korrigiert" — d. h. die vorgegebene Korrektur bewegte es an die falsche Stelle [schema/compiler.md:99-102]
+- [x] [Review][Patch] `wiki/index.md`: das Baum-Diagramm (code-block) ist veraltet — es zeigt das Bundle weiterhin nur als `<area>/…` ohne Root-Concepts, während `## Concepts` direkt darunter 3 neue Root-Dateien auflistet; die Struktur-Skizze widerspricht nun dem Dateisatz, den sie dokumentiert [wiki/index.md:12-20]
+- [x] [Review][Patch] `deferred-work.md`: „Content-Truth-Verifikation einführen" und „Determinismus-Selbsttest-Dokumentation schärfen" erscheinen je **zweimal** (Folge-Aufgaben-Block + Code-Review-Block) mit nahezu identischem Text, aber unterschiedlichem `source_spec`-Label und (für Determinismus) unterschiedlichem Home — Ownership mehrdeutig, lädt zu Doppel-Erledigung ein [deferred-work.md]
+- [x] [Review][Patch] `deferred-work.md` (Sandbox-Dryrun-P1): „jede Negativ-Fixture (`validator.md` §7.1, **n=17**)" — die §7.1-Tabelle hat nach Revision 8 **21** Zeilen (nach Rev 7: 20); Zählung in einem frisch geschriebenen Eintrag falsch [deferred-work.md]
+- [x] [Review][Patch] `review-input-dryrun-2-1-pdf-radium.md` §1: interne Inkonsistenz der Datei-Auflösung — „13 Root- + 5 spring/" vs. „die 5 realen … zuzüglich 11 radium- + 2 spring-" (impliziert 16 Root- und 5 vs. 2 spring) [review-input-dryrun-2-1-pdf-radium.md]
+- [x] [Review][Patch] `validator-revision-8-autorisationsrunde-…md`: Frontmatter `status: 'draft'` **und** alle 4 Definition-of-Done-Boxen `- [ ]`, obwohl die Runde ausgeführt, zertifiziert und downstream `done` ist (Action-Item done, log.md-Zertifizierung, deferred-work „umgesetzt") — die Legitimität, Rev 8 als „autorisiert" zu führen, stützt sich auf ein nicht finalisiertes Dokument; Status finalisieren + DoD abhaken (3 Layer: Blind + Acceptance + Verification-Gap) [validator-revision-8-autorisationsrunde-f14-innen-ebenen.md:5,76-79]
+- [x] [Review][Patch] Spec: doppelte `## Spec Change Log`-Sektion — die obere enthält weiterhin nur „(leer bis zum ersten Review-Loopback)", die untere die tatsächlichen Einträge; das Re-Re-Review-Verdikt (der bedeutendste Zustandswechsel nach Log-Start) fehlt im Change Log [spec-2-1-…md]
+- [x] [Review][Patch] Rev-8-Runde: Datums-Diskrepanz — `wiki/log.md`, `sprint-status.yaml` (`closed`) und der validator-Rev-8-Logeintrag sagen **2026-08-16**, aber der ausführende Commit `e6c36fc` sowie `deferred-work.md` („umgesetzt 2026-08-17") und das `→ review`-Flip-Verdikt sagen **2026-08-17**; aus den Artefakten ist nicht konsistent ableitbar, an welchem Tag die Runde lief [wiki/log.md:7, sprint-status.yaml:161]
+- [x] [Review][Patch] `epic-2-context.md`: „die Schema-Validierung von Story 1.4 **erzwingt auch AD-4c** (keine abgeleitete Provenienz)" — übertrieben; Vertrag §6.1 (A0-5/AD-4c) sagt, die Regel sei in v1 „tautologisch erfüllt" und „erzeugt kein eigenes Validitätsprädikat", und der Validator hat keinen AD-4c-Check. Der frisch angelegte Epic-Kontext schreibt Erzwingung einem Mechanismus zu, der per Definition noch nicht existiert [epic-2-context.md]
+- [x] [Review][Patch] `schema/compiler.md` Sprache: §5.2 „Der Body darf keine **grossen** Quell-Exzerpte enthalten" (→ „großen") und §1.4 „zu verarbeitende Evidenz kann auch andere **Aufträge** als `.md` tragen" (→ „Formate"/„Endungen") — beide in normativem Kontext (FR-2-Bodylimit, Evidenz-Definition) [schema/compiler.md:28,61]
+- [x] [Review][Patch] Spec `## Verification` + `## Suggested Review Order` veraltet: erwarten „KEINE … `schema/validator.md`-Mutationen" und „Validator (Rev 7) … unverändert autorisiert" — beides wird vom Diff widersprochen (validator.md ist jetzt Rev 8 und mutiert); die Spec wurde nie angepasst, um zu verzeichnen, dass Option A den legitimen Diff-Inhalt geändert hat [spec-2-1-…md]
+- [x] [Review][Patch] `schema/compiler.md` §3.2 Kollision-Hold: definiert nur das Ergebnis je Einheit („bricht für diese Einheit ab"), aber **nicht**, ob der Run die übrigen Einheiten fortsetzt und was der Gesamt-Run-Status bei teils-gehaltener Einheit ist — Run-Ergebnis nicht deterministisch ableitbar [schema/compiler.md:40]
+- [x] [Review][Patch] `schema/compiler.md` §5.3/§6.3: „keine weiteren Mutationen auf FAIL" + „Commit-Boundary ist die Mutations-Boundary" fehlt eine **explizite Rollback-Sequenz** für den Teilzustand (Concept-Datei + Index-Zeile + log-Zeile bereits geschrieben), der zwischen „Mutieren" und einem fehlgeschlagenen „Validieren" existiert — teilweise Mutationen könnten inkonsistent im Bundle liegen [schema/compiler.md:63,70]
+- [ ] [Review][Patch] `schema/validator.md` §7.1 Fixture 4a: das erwartete Verdikt — **GEGEHOLDERT (2026-08-17):** betrifft die gerade autorisierte, gefrorene `validator.md` (Rev 8); Anwendung setzt einen neuen Autorisierungsschlag auf `schema/` voraus und wird separat bestätigt, nicht automatisch mitgepatcht. `Punkt 4: … (resolved=README.md)` ist aus der §3-Punkt-4-Vorlage `(..-Traversal|absolut|URL|Backslash|file://)` **nicht ableitbar** — die Vorlage trägt kein `resolved=`-Token (Punkt 4 deckt zwar „außerhalb raw/ durch Auflösung", die Fehlerursachen-Grammatik listet es aber nicht); §7 verlangt „exakt die aus §3". *Betrifft die (gerade autorisierte) frozen `validator.md`* [schema/validator.md:63,214]
+- [ ] [Review][Patch] `schema/validator.md` Rev 8: die „formalisierte" **Innen-Ebenen-Punkt-6-Regel** hat keine Fixture-Zeile — **GEGEHOLDERT (2026-08-17):** betrifft die gerade autorisierte, gefrorene `validator.md` (Rev 8); Anwendung setzt einen neuen Autorisierungsschlag auf `schema/` voraus und wird separat bestätigt, nicht automatisch mitgepatcht. in §7.1/§7.3 — der einzige Punkt-6-Fixture ist Top-Level `foo: bar` (Zeile 6), die §7.3-Notiz zeigt `sources … role: x` nur als Inline-Beispiel, nicht als Tabellen-Fixture; die Zertifizierung dieses Falls existiert nur als Prosa in log.md/spec/sprint-status, kein re-runbares Sample ist committed, obwohl §7 behauptet, die Tabellen machten „jede mechanische Bedingung reproduzierbar nachprüfbar". *Betrifft die (gerade autorisierte) frozen `validator.md`* [schema/validator.md:214,260]
+
+**defer:**
+
+- [x] [Review][Defer] Content-Truth-Verifikation: kein Check verifiziert den Body eines Concepts gegen seinen deklarierten `raw/`-Quellen-Inhalt. Konkrete Instanz: `knowledge-kompilation-inkrementell.md` — das ASCII-Datenfluss-Diagramm-Layout stammt aus `raw/architecture-spine/…`, deklariert ist `sources: raw/epics/…` (Inhalt an sich ist kuratiert/korrekt, nur die exakte Diagrammform ist nicht von der deklarierten Source gedeckt) — deferred, Story 2.2 (bereits in deferred-work.md) [wiki/knowledge-kompilation-inkrementell.md]
+- [x] [Review][Defer] Concepts präsentieren Epic-3/4-Fähigkeiten als aktuelle Tatsache ohne Forward-Referenz-Marker: `knowledge-kompilation-inkrementell.md` „Verbindung zu Regelwerken" (NEW/CONFIRMING-CORRECTING-Klassifikation + grep/ripgrep-Relevanz → Story 3.2/4.1) und „FR-6 Aktualisierung statt neuer Dateien" (→ Story 3.1, die `compiler.md` §7/§3.2 explizit nicht baut und deren Kollision-Hold auf bestehendem Pfad sogar abbricht) — deferred, Story 2.2/3 [wiki/knowledge-kompilation-inkrementell.md:62-67]
+- [x] [Review][Defer] Determinismus-Selbsttest: §6.6-Interpretations-Hinweis behauptet „genau diese Form … im Demonstrationslauf erfüllt", die ✓-Zeile pinnt `at: 2026-08-16T09:23:33Z`, aber `generated.at` variiert pro Run (AD-15) — für einen Regenerate-Vergleich hält nur die Normalform, nicht „genau diese Form" — deferred, Story 2.3 (bereits in deferred-work.md) [schema/compiler.md:97,108]
+- [x] [Review][Defer] `wiki/log.md`: die neuen 2026-08-16/17-Einträge sind überwiegend Prozess/Meta-Content (Review-Verdikt, Action-Item-Statusflips, Validator-Revision-Ankündigungen) statt Vertrag-§5-„fachliche Änderungen … verknüpft mit dem mutierten Concept-Pfad"; kein Marker unterscheidet Meta- von Fach-Einträgen, kein Validierungs-Hook (F17 defert Log-Content-Validierung bewusst) — vorbestehendes Muster (Retrospective-Follow-up-Einträge), nicht neu durch diesen Diff verursacht — deferred, pre-existing [wiki/log.md]
+
+**dismiss (2 — nicht persistent):**
+- Consumer-Namen (BMAD/Claude Code/Codex) in `wissensarchitektur-trennung-states.md` **sind** in der deklarierten `raw/architecture-spine/…` belegt (Zeilen 324/334/700–701) — kein Content-Truth-Verstoß (False Positive des Blind-Hunters).
+- Sandbox-Dryrun-Artefakte (`review-input-dryrun-…md`, `deferred-work.md`-Dryrun-Block) sind additiv, nicht-normativ, klar als externer Kontext aus `D:\mita\wow-2nd-sandbox` gelabelt — kein Befund gegen `schema/`/`wiki/`/`raw/`.
 
 ## Design Notes
 
@@ -136,7 +167,7 @@ Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifizier
 ## Verification
 
 **Commands:**
-- `git status --short && git diff --stat` — expected: neue Datei `schema/compiler.md` + `wiki/<slug>.md`-Concepts + `wiki/index.md`-Änderung + `wiki/log.md`-Eintrag + `sprint-status.yaml`-Update; KEINE `raw/`-, `schema/wiki-compiler.md`-, `schema/validator.md`-Mutationen.
+- `git status --short && git diff --stat` — expected: neue Datei `schema/compiler.md` + `wiki/<slug>.md`-Concepts + `wiki/index.md`-Änderung + `wiki/log.md`-Eintrag + `sprint-status.yaml`-Update; KEINE `raw/`- oder `schema/wiki-compiler.md`-Mutationen. (Hinweis 2026-08-17: `schema/validator.md` ist zwischenzeitlich im Rahmen der autorisierten Option-A-Revision 8 mutiert — der ursprüngliche Diff-Erwartungswert „KEINE `schema/validator.md`-Mutationen" gilt für den Story-2.1-Erstellungs-Diff, nicht mehr für den Gesamt-Stand nach Validator-Rev-8.)
 - Validator-Instruktion gegen Bundle ausführen (manuell/deterministisch, siehe `schema/validator.md` §5-Grammatik): `grep -nE 'Punkt 11|concept nicht verlinkt' schema/validator.md` + praktischer SUCCESS-Lauf des Validators gegen `wiki/` — expected: alle neuen Concepts + `index.md` + `log.md` liefern `SUCCESS` (kein FAIL, kein WARN-Blocker).
 - Frontmatter-Konformitäts-Smoke: `grep -nE '^(type|sources|generated|verified|status|stale_after):' wiki/*.md` — expected: nur §3-Felder je Concept; `type` gesetzt; `generated.at` im Format `YYYY-MM-DDTHH:MM:SS` (mit Offset-Suffix).
 - `sources`-Auflösung: `grep -nE 'resource:' wiki/*.md` — expected: jeder Wert ist ein existierender `/`-getrennter `raw/`-Pfad (kein `..`, kein `wiki/`, keine URL).
@@ -174,6 +205,9 @@ Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifizier
 
 ## Spec Change Log
 
+- **2026-08-17 (Human-Review-Freigabe → `done`):** Nutzer-Freigabe erteilt — Story 2.1 ist `done` (Status `review` → `done`); die letzte verbleibende Schwelle (menschliche Review-Freigabe) ist damit überschritten. Alle 8 ACs PASS, kein AC-/Vertrags-Blocker; offene Folge-Arbeit (autorisierte Validator-Revision 9: Punkt-4-Grammatik `resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile) ist kein Story-2.1-Blocker und bleibt in `deferred-work.md` / Action-Item `code-review-2-1-item-2` verankert. `sprint-status.yaml`: Story 2.1 → `done`.
+- **2026-08-17 (Code-Review-Re-Run, Patches 15/17 umgesetzt):** Unabhängiger Re-Run (4 Layer) auf dem Stand nach Validator-Rev-8: 17 Patch / 4 Defer / 2 Dismiss, alle 8 ACs PASS. 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), `wiki/index.md` (Baumdiagramm), `deferred-work.md` (Dedupe, n=21), `review-input-dryrun-…md` (Datei-Auflösung 16+2), `validator-revision-8-…md` (status done, DoD), `epic-2-context.md` (AD-4c tautologisch), spec Verification/Suggested-Review-Order (Rev 8), `sprint-status.yaml` (closed-Datum 08-17). 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` „Arbeitsauftrag Rev 9", Action-Item `code-review-2-1-item-2`). Status bleibt `review` (`done`-fähig; verbleibende Schwelle = Human-Review).
+- **2026-08-17 (Re-Review):** Re-Re-Review-Verdikt — Option-A-Voraussetzung erfüllt (autorisierte Validator-Revision 8 ausgeführt und zertifiziert: F-14-Fixture 4a, Innen-Ebenen-Key-Subset formalisiert, Header „Revision 6" → „Revision 8"); Story 2.1 `review`-fähig und `done`-fähig; verbleibende Schwelle bis `done` ausschließlich die menschliche Review-Freigabe.
 - **2026-08-16 (Step-04-Review):** `sources`-Eintrag-Key-Subset als Zusatz-Verification-Check ergänzt (Vertrag §3.3, Punkt 6); `at`-Format-Smoke als Punkt-14-Beleg unter die Verification-Checks aufgenommen; `status: in-review` (Review begonnen). Keine Änderung am `<frozen-after-approval>`-Intent.
 - **2026-08-16 (Erstellung):** Initiale Approve-Baseline.
 
@@ -217,7 +251,7 @@ Nach den drei Review-Layern (Blind Hunter, Edge Case Hunter, Verification Gap) a
 - Authorized contract: field subset, `sources` key-subset per entry, `generated` by/at — the normative anchor Story 2.1 derives from (unchanged, authorized).
   [`wiki-compiler.md`](../../schema/wiki-compiler.md#L53)
 
-- Validator (Rev 7): §7.3-Isolations-Hinweis auf Innen-Ebenen-Key-Subset erweitert — Punkt 6 deckt auch `sources`/`generated`/`verified`-Eintragsebenen ab (Revisionslog nachgeführt, unverändert autorisiert).
+- Validator (Rev 8): F-14-Negativ-Fixture 4a (§7.1, Punkt 4) + Innen-Ebenen-Key-Subset formalisiert (Punkt 6 → §7.3-Isolations-Notiz, autorisiert) + Header-Revisionszahl auf 8 angehoben (OBS-1 behoben) — autorisierte Option-A-Revision, 2026-08-17 ausgeführt und zertifiziert.
   [`validator.md`](../../schema/validator.md#L260)
 
 **Wissenseinheiten — Konzepte aus den Quellen**

_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-17-2026 05:40
+last_updated: 08-17-2026 07:35
 project: wow20
 project_key: NOKEY
 tracking_system: file-system
@@ -43,7 +43,7 @@ development_status:
   epic-1-retrospective: done
 
   epic-2: in-progress
-  2-1-concepts-aus-source-material-erzeugen-okf-konform: review
+  2-1-concepts-aus-source-material-erzeugen-okf-konform: done
   2-2-claim-granulare-provenienz-dokumentieren: backlog
   2-3-concepts-verlinken-eine-erlaubte-linkform: backlog
   2-4-deterministische-bereichszuordnung-concept-hierarchie: backlog
@@ -159,10 +159,16 @@ action_items:
          'Revision 7', OBS-1). Danach Story 2.1 zur Review-Freigabe wiedervorlegen."
     owner: "dev"
     status: done
-    closed: "2026-08-16"
+    closed: "2026-08-17"
     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"
+  - id: "code-review-2-1-item-2-validator-rev9-punkt4-grammar-innen-ebenen-fixture"
+    epic: 2
+    action: "Autorisierte Validator-Revision 9 vorbereiten (bmad-code-review Re-Run 2026-08-17, geholderte Patches 16/17): 1) Punkt-4-Fehlerursachen-Grammatik um `resolved=`-Token erweitern (Fixture 4a ableitbar machen); 2) Innen-Ebenen-Punkt-6-Fixture-Zeile in §7.1/§7.3 ergänzen (Rev-8-Formalisierung re-runbar belegen). Danach Zertifizierung (isolierte Fixtures + reales Bundle) und `wiki/log.md`-Nachweis."
+    owner: "dev"
+    status: open
+    ref: "_bmad-output/implementation-artifacts/deferred-work.md"

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

@@ -2,7 +2,7 @@
 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'
+status: 'done'
 based_on_commit: f91ef89078ee8e4c8a979cfb70f20ead1ffe854b
 related:
   - _bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md
@@ -73,7 +73,7 @@ Nach erfolgreicher Ausführung + Zertifizierung:
 
 ## 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).
+- [x] `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).
+- [x] Zertifizierung 1–3 dokumentiert (Fixture 4a FAIL, Innen-Ebenen Punkt 6 FAIL, reales Bundle SUCCESS).
+- [x] `schema/wiki-compiler.md`, `schema/compiler.md`, `raw/`, `adapters/`, `wiki/`-Concepts unverändert (außer `wiki/log.md`-Einträge).
+- [x] Sprint-Tracking aktualisiert (Action-Item done, Story 2.1 `done` nach Human-Review).