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`.