chore: Epic-1-Retrospective Action Items AI-1..AI-7 umsetzen

Re-Konsistenz des Validators mit dem autorisierten Vertrag (schema/validator.md 3->6):
- F-01/AI-1: at-Nur-Datum-Toleranz zurueckgenommen (reines Datum => FAIL Punkt 14), Fixture 14c umgebaut, +HHMM-Positiv; Vertrag unveraendert
- F-02/AI-2: neue Fixture-Tabelle 7.3 (EC-1 Existenz, EC-3 Kalender, stale_after-WARN, EC-11 non-md); Zertifizierung in wiki/log.md nachgefuehrt
- F-03/AI-3: 3.2-Voraussetzungen als fachliche Pruefklasse V-1/V-2 gelabelt (FAIL (Voraussetzung)); 5-Grammatik + Fixtures angeglichen
- F-05/AI-5: BOM-/Leerzeilen-Stripping der Frontmatter-Erkennung auf Punkte 2/8/10 vereinheitlicht (3-Praaembel); Positiv-Fixtures 2a/8b
- F-06/F-08 (AI-7): offene Punkte (today-Zeitzone, .MD-Grossschreibung) im Validator verankert

Weitere Retro-Follow-ups:
- F-09/AI-4: source.md-Provenienz korrigiert (_bmad-output/ ist versioniert, Commit 6cc667d + SHA-256 byte-identisch)
- F-10/AI-6: strenger Vertrag<->Validator<->Fixtures-Abgleich (14 Punkte, keine Punkt 15) als Pflicht-Re-Check in spec-1-4; bleibt in D-3
- F-04/F-06/F-07/F-08/F-11/F-14 (AI-7): Defer-Kontexte in deferred-work.md gesichert
- Action Items AI-1..AI-7 auf done gesetzt (sprint-status.yaml)

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

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

@@ -5,6 +5,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
   summary: Checksum-/Fingerprint (SHA-256) der evtl. Git-Revision der Herkunftsquelle in `source.md` aufnehmen, damit die Provenienz reproduzierbar ist.
   evidence: Blind-Hunter-Review (Finding 1/2): `source.md`-Provenienz ist ohne Fingerprint der Quelle in einem reinen Clone nicht verifizierbar; AD-3-basiertes „neue, datierte Datei"-Schema braucht einen Maschinen-Lesbaren Stand.
+  status: umgesetzt (2026-08-16, Retrospective F-09/AI-4) — Commit-Hash `6cc667d` + SHA-256 der jeweiligen Herkunftsdatei in allen drei `raw/*/source.md` aufgenommen; Byte-Identität zur materialisierten Evidenz geprüft.
 
 - source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
   summary: Maschinen-lesbares, validierbares Metadaten-Schema (YAML-frontmatter) für `source.md` einführen.
@@ -65,3 +66,35 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
 - source_spec: `_bmad-output/implementation-artifacts/spec-1-4-schema-validierung-für-bundle-implementieren.md`
   summary: Genau-eine-erlaubte-Linkform für den Punkt-11-Index-Check festlegen (mit vs. ohne `.md`-Endung) — Story 2.3.
   evidence: Step-04-Review (Story 1.4, Loop 1): Der Validator-Punkt-11-Check akzeptiert beide Linkformen (relativer Bundle-Pfad mit oder ohne `.md`-Endung), weil die genau-eine-Form-Regel (A0-9/AD-7b) erst Story 2.3 definiert. Der Determinsmus-Anspruch des Validators bleibt gewahrt (beide Formen zählen als verlinkt); eine Endungs-Festlegung würde die abschließende §7-Liste erweitern und gehört in Story 2.3.
+
+- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md`
+  summary: F-03/AI-3 — gewählter Weg dokumentiert: §3.2-Voraussetzungsprüfungen als V-1/V-2-fachliche Prüfklasse (Revision 5). Die alternative Option „Vertrag §7 um Fall ‚fehlende Bundleroot' erweitern (mit Autorisierung)" wurde bewusst NICHT gewählt; sollte später ein Fall „fehlende Bundleroot" in den §7-Katalog selbst (statt als V-1) gefordert sein, ist dies nachzuholen (Vertrags-Änderung via Story-Verfahren).
+  evidence: Retrospective F-03 Disposition „Fix-now (als fachliche Prüfungen V-1/V-2 labeln … oder Vertrag §7 erweitern)" — Entscheidung für Option 1 getroffen (2026-08-16, AI-3).
+
+## Folge-Aufgaben aus Epic-1-Retrospective (Defer-Kontexte, AI-7; 2026-08-16)
+
+> Diese Einträge sichern die von der Epic-1-Retrospective (2026-08-15) als Defer klassifizierten Befunde als konkrete Folge-Aufgaben. Sie sind **nicht** durch die Validator-Revisionen 3–6 behoben — nur als Kontext für Epic-2/3 bzw. die nächste Validator-Revision notiert.
+
+- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-04)
+  summary: Verschachtelte Duplikat-Keys in `sources`/`verified`-Einträgen behandeln — Punkt 13 zählt nur doppelte Keys auf oberster Frontmatter-Ebene; YAML erlaubt mehrdeutig doppelte `resource`-Keys innerhalb eines Eintrags (Parser-abhängiger Gewinner). Bei der nächsten Validator-Revision (Epic-2-Start) klären: Abdeckung der Innen-Ebenen oder bewusst dokumentierte Abgrenzung.
+  evidence: Retrospective F-04.
+
+- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-06)
+  summary: `today`-Zeitzone für die `stale_after`-WARN (Validator §6.4) deterministisch festlegen — „heute in UTC abgeleitet" ist nicht hart definiert (Kalenderdatum des UTC-Zeitpunkts vs. lokaler Tag). Determinsmus-Anspruch (AD-17h) vor Epic-3 (Lifecycle-Konsequenz) sauber machen.
+  evidence: Retrospective F-06.
+
+- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-07)
+  summary: Index-Regel bei verschachtelten Areas/Unter-Ebenen konkretisieren — „Area als eine `index.md` tiefer als `wiki/`" lässt für `wiki/a/b/concept.md` offen, was „Area mit Inhalt" ist. Epic-2-Story 2.5 (progressive Discovery) legt die Antwort fest; vorher gilt die heutige Definition.
+  evidence: Retrospective F-07; Offene Frage 2 der Retro; spec-1-4 Story 2.3-Linkform.
+
+- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-08)
+  summary: Konvention für `.MD`-Großschreibung unter `wiki/` klären (Windows-Portabilität, NFR-1/NFR-5) — heute ist nur exakt `.md` (case-sensitive) ein Concept; auf win32 kann ein Tool `foo.MD` erzeugen. Vor Epic-2-Concepts entscheiden: Ablehnung/FAIL oder case-insensitive Behandlung.
+  evidence: Retrospective F-08.
+
+- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-11)
+  summary: Normreferenz der OKF-0.2-Spezifikation verlinkbar machen (Vertrag §8, Validator §8) — das Prosa-Zitat „OKF-Spezifikation (Google Cloud, `knowledge-catalog`)" ohne URL/Version ist nicht auflösbar; `okf_version`-Regel und §7-Punkt-14 hängen daran. Kleine Korrektur bei nächster Autorisierung (Vertrag) ergänzen.
+  evidence: Retrospective F-11.
+
+- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-14)
+  summary: Negativ-Fixture für `resource`-Pfade, die außerhalb `raw/` landen aber existieren (z. B. `README.md`) — §6.2 Schritt 5 deckt den Fall ab, aber das Durchstechen ist nur durch Beispiele belegt. Fixture bei nächster Validator-Revision ergänzen (analog §7.3).
+  evidence: Retrospective F-14.

_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md

@@ -0,0 +1,180 @@
+---
+epic: 1
+date: 2026-08-15
+verdict: accepted-with-open-items
+criteria: profiled
+headless: false
+---
+
+# Retrospective — Epic 1: Wissens-Workspace & Quellen-Aufnahme
+
+## Epic-Zusammenfassung
+
+- **Epic:** 1 — Wissens-Workspace & Quellen-Aufnahme
+- **Diff-Range:** `6a95d96..6cc667d` (8 Commits: 4 × `feat`, 4 × `chore` (je eine `done`-Setzung je Story))
+- **Stories:** 1.1 (Workspace-Stamm), 1.2 (Sources unter `raw/`), 1.3 (Schema-Vertrag autorisieren), 1.4 (Schema-Validierung) — alle `done`
+- **Pending-Stories:** keine (`detect-epic`: `story_count: 4`, `pending_stories: []`)
+- **Evidenz-Inventur:**
+  - ✅ Epic-Spec: `epic-1-context.md`; Architecture-Spine, PRD, epics (Planung)
+  - ✅ Story-Specs 1.1–1.4 (inkl. `baseline_commit` ab Story 1.3)
+  - ✅ Diff-Range + per-Story-Zuordnung via `git_evidence.py`
+  - ✅ Sprint-Status (`sprint-status.yaml`)
+  - ✅ Keine frühere Retro, keine `action_items` im Sprint-Status
+  - ⚠️ Session-Logs: **nicht vorhanden** → Prozess-Lektionen-Analyse eingeschränkt (nur aus Spec-Revisionslog & Commit-Struktur ableitbar)
+  - ⚠️ Acceptance-Kriterien: nicht als eigene Liste deklariert → **profiled** aus Stories & Epic-Context
+
+## Findings (Phase 2)
+
+Konsolidiert aus drei Sichtlinien: Aggregat-Sichten (Diff 6a95d96..6cc667d), bmad-review-Linsen (adversarial, edge-case, verification-gap — ausgeführt als drei parallele Linsen-Agenten über den Diff/Validatoren) und der Behavior-Prüfung. Jeder Befund trägt eine Quellenreferenz; nicht belegbare Befunde wurden verworfen.
+
+### F-01 (kritisch) — Validator weicht unautorisiert vom Vertrag ab: `at` als reines Datum akzeptiert, obwohl Vertrag „ISO-8601-Datetime" fordert
+
+- **Befund:** `schema/validator.md` §4.3 (Z.105) und Fixture 14c (§7.2 Z.242) erklären `at: 2027-01-01` (reiner Datumswert) zu SUCCESS („normalisiert zu T00:00:00Z"). Der autorisierte Vertrag `schema/wiki-compiler.md` verlangt für `at` (§3.4 Z.76, §3.5 Z.91) „MUSS es ein ISO-8601-**Datetime** sein" und erklärt §7 Punkt 14 (Z.186) „`at` ungleich ISO-8601-Datetime" zur strukturellen Invalidität. Ein reines Datum ist kein Datetime.
+- **Quelle:** `schema/wiki-compiler.md:76,91,186` (Vertrag, autorisiert Story 1.3) vs. `schema/validator.md:105,242` (Validator, Story 1.4).
+- **Auswirkung:** Genau der vom frozen-intent verbotene Konformitätsbruch (spec-1-3: „Keine Änderung am autorisierten Vertrag"/„keine unautorisierte Verschärfung"; spec-1-4 Boundaries: „Der Validator darf keinen Eintrag hinzufügen"). Ein Validator-konformer Producer kann `at`-Datumsangaben erzeugen, die ein strikter Vertrags-Leser als strukturell invalide verwirft — die Validierung bildet die Norm nicht 1:1 ab.
+- **Disposition:** Fix-now (Re-Konsistenz: Entweder Fixture streichen/FAIL oder Vertrag neu autorisieren — Story-Verfahren).
+
+### F-02 (kritisch) — §6-Fachliche-Zusatzprüfungen (EC-1, EC-3, stale_after-WARN) haben KEINE Referenz-Fixtures, obwohl sie Run-FAIL-gate sind; Validator-Zertifizierung deckt sie nicht ab
+
+- **Befund:** `schema/validator.md` definiert die fachlichen Prüfungen §6 (EC-1 Existenzprüfung, EC-3 Kalender-Validität, §6.4 stale_after-WARN, §6.5 non-md) — davon sind EC-1/EC-3 **Run-FAIL-gate** (§6.1 Z.155 „fachlich invalide → Run-FAIL"). Die §7-Fixture-Tabellen (§7.1/§7.2, Z.196–243) enthalten **keine einzige** Fixture-Zeile zu diesen Checks. Der Zertifizierungs-Eintrag `wiki/log.md:4` behauptet „alle Negativ-Fixtures … alle Positiv-Fixtures" geprüft zu haben — die belegen aber nur die 14 §7-Punkte + §3.2-Voraussetzungen, nicht die §6-Checks.
+- **Quelle:** `schema/validator.md:§7.1/§7.2` (Z.196–243, keine §6-Zeilen) vs. §6.1/§6.3 (Z.153–181); `wiki/log.md:3–4` (Zertifizierungs-Claim).
+- **Auswirkung:** Ein Ausführer (Epic-2-Producer) kann EC-1/EC-3 überspringen oder falsch ausführen („Phantom-`raw/`-Pfad", falsche Kalenderdaten) und bekäme trotzdem grün — das entscheidende Gate gegen Mutation mit fehlender Evidenz ist unbelegt. AD-17h („reproduzierbar prüfbar") gilt für §6 nicht.
+- **Disposition:** Fix-now (Fixtures für §6 ergänzen; Zertifizierung neu ausführen).
+
+### F-03 (kritisch) — §3.2 Voraussetzungsprüfungen sind de-facto eigenständige FAIL-Klassen, die weder in §7 noch im §5-Verdikt-Grammatik stehen
+
+- **Befund:** `schema/validator.md:§3.2` (Z.77–83) führt zwei Run-FAIL-Bedingungen ein (fehlende Bundleroot, `log.md` an Nicht-Root-Position) mit Verdikt `FAIL (Struktur) …` — ohne §7-Punkt-Nr. und ohne „Fachliche Prüfung EC-x"-Label. `§5.1` (Z.141–147) und §3.1 (Z.71–75) behaupten dagegen „abschließende Liste, keine eigene Invaliditätsklasse". Der fehlende Bundleroot ist zudem **nicht** in §7 (Punkt 8 setzt eine existierende `wiki/index.md` voraus, deckt aber „fehlt ganz" nicht ab).
+- **Quelle:** `schema/validator.md:77–83,141–147`; `schema/wiki-compiler.md:§7` (kein Fall für fehlende Bundleroot).
+- **Auswirkung:** Selbstwiderspruch des „keine neue Klasse"-Selbstzeugnisses; ein mechanischer Audit („alle 14 abgebildet") schlägt fehl oder (Struktur)-Verdikte werden nicht als Run-FAIL gelesen.
+- **Disposition:** Fix-now (als fachliche Prüfungen V-1/V-2 labeln und Fixture-Label ergänzen, oder Vertrag um Fall 15 erweitern mit Autorisierung).
+
+### F-04 — Duplikat-Keys nur auf oberster Frontmatter-Ebene gezählt; verschachtelte Duplikate in `sources`/`verified`-Einträgen nicht behandelt
+
+- **Befund:** `schema/validator.md` §3 Punkt 13 (Z.68) und Präambel (Z.52) zählen doppelte Keys „auf oberster Frontmatter-Ebene". Doppelte `resource`-Keys innerhalb eines `sources`-Eintrags (YAML erlaubt sie mehrdeutig) sind nicht abgedeckt — mit Parser-abhängigem Gewinner und doppeldeutiger Provenienz.
+- **Quelle:** `schema/validator.md:52,68` (§3 Punkt 13, nur oberste Ebene).
+- **Disposition:** Defer (mit Kontext) — in Nachfolge-Story/Verzahnung mit Validator-Revision.
+
+### F-05 — BOM-/Leerzeilen-Stripping gilt nur bei Punkt 10 (Area-index/log); Punkte 2/8 (Concept-/Bundleroot-Frontmatter-Erkennung) nicht
+
+- **Befund:** Punkt 10 (Z.65) strippt BOM `U+FEFF` + führende Leerzeilen vor `---`; Punkt 2 (Z.57) und Punkt 8 (Z.63) erkennen `---` ohne Stripping — ein BOM/Leerzeile vor Concept- oder Bundleroot-Frontmatter erzeugt ein falsches Punkt-2/8-FAIL.
+- **Quelle:** `schema/validator.md:57,63,65`.
+- **Disposition:** Fix-now (Stripping-Vorgabe auf Punkte 2/8 erweitern) ODER Defer mit Kontext.
+
+### F-06 — `today`-Zeitzone für stale_after-WARN nicht definiert
+
+- **Befund:** §6.4 (Z.180) vergleicht `today >= stale_after` „in UTC", definiert aber nicht, wie „today" abgeleitet wird (Kalenderdatum des UTC-Zeitpunkts? lokaler Tag?). Gleicher lokaler Tag ≠ gleicher UTC-Tag nach Zeitzone.
+- **Quelle:** `schema/validator.md:180`; Vertrag §3.7 (Z.114) sagt nur „Tagesdatum `today`", ohne Zeitzonenquelle.
+- **Disposition:** Defer (mit Kontext) — Determinsmus-Anspruch ist hier nicht hart garantiert.
+
+### F-07 — Punkt 11 (Index-Regel): untere Verzeichnisebenen / Areas ohne `.md`-Inhalt uneindeutig definiert
+
+- **Befund:** Area wird in §2/§3 als „eine `index.md` tiefer als `wiki/`" definiert. Der Vertrag §6 verlangt „Jede Area … MUSS eine `index.md` enthalten". Bei verschachtelten Unter-Ebenen (`wiki/a/b/concept.md`) oder Verzeichnissen ohne Concept-`.md` ist unklar, was „Area mit Inhalt" ist — Punkt-11-Verletzung agent-abhängig.
+- **Quelle:** `schema/validator.md:42,66`; `schema/wiki-compiler.md:139–146`.
+- **Disposition:** Defer (Story-2.5 Voraussetzung — progressive Discovery; als offene Frage notieren).
+
+### F-08 — Konvention `.MD` (Großschreibung) unter `wiki/` unbestimmt; Windows-Portabilität
+
+- **Befund:** §1 Punkt 3 (Z.33) behandelt non-`.md` als Nicht-Bundle-Element, „case-sensitive kleingeschrieben". Bei Windows (Projekt läuft auf win32) kann ein Tool `foo.MD` erzeugen; wird es als Concept `.md` gewertet, failt es wegen fehlendem `type`. Konvention für Großschreibung fehlt.
+- **Quelle:** `schema/validator.md:33`; NFR-1/NFR-5 (Portabilität).
+- **Disposition:** Defer (mit Kontext) — vor Epic-2-Concepts klären.
+
+### F-09 — Provenienz-Sidecars (`source.md`) behaupten fälschlich, `_bmad-output/` sei „im Repo nicht versioniert"
+
+- **Befund:** `raw/prd/source.md:14`, `raw/architecture-spine/source.md:13`, `raw/epics/source.md:13` behaupten, Herkunftspfade unter `_bmad-output/` seien „nicht versioniert". Tatsächlich sind die Herkunftsartefakte versioniert: `git ls-files _bmad-output` listet `planning-artifacts/prds/.../prd.md`, `planning-artifacts/epics.md`, `ARCHITECTURE-SPINE.md`. `.gitignore` enthält keinen `_bmad-output/`-Eintrag.
+- **Quelle:** `raw/*/source.md:13–14`; `git ls-files _bmad-output` (23 Dateien); `.gitignore`.
+- **Auswirkung:** Provenienz-Aussage ist faktisch falsch; ein Nachvollzieher kann die Herkunft nicht als feste Referenz nutzen, und ein späterer Verifikationsschritt (Deferred-Work Finding 1/2, Checksumme) widerspricht der Dokumentation.
+- **Disposition:** Fix-now (Zeile korrigieren — Quellen sind versioniert; Reproduktionshinweis auf Commit-Hash stützen) + Deferred-Work-Checksumme als Konsequenz.
+
+### F-10 — Verifikation des Validators ist dokumentarisch, nicht ausführbar: keine Testdatei, kein CI, kein Haken
+
+- **Befund:** Kein Testfile unter `schema/`/`wiki/`, kein `.github/`, keine Haken (nur `.sample`), kein Makefile/CI. Die Spec-Verification-Greps (spec-1-4:111–119) sind Existenz-/Mentions-Greps, die einen semantischen Drift nicht fangen (z. B. `grep -cE '\bFAIL\b|\bSUCCESS\b'` zählt auch Prosa-Labels). `baseline_commit` (spec-1-3:7, spec-1-4:6) wirkt nur review-zeitlich, nicht als Re-Run-Guard.
+- **Quelle:** `git ls-files | grep -i test` (keine Tests); `ls .github` (fehlt); `git log --oneline -- schema/wiki-compiler.md schema/validator.md` (Validator nur in c5f97c3, Vertrag in 2625e1d+9e163ad); `_bmad-output/implementation-artifacts/spec-1-4-...md:107–119`.
+- **Auswirkung:** F-01/F-02 konnten unentdeckt durch die „Zertifizierung" kommen (PASS-Claim in `wiki/log.md:4`); eine Vertragsänderung würde stillen Drift unentdeckt lassen.
+- **Disposition:** Fix-now (Prozess-/Verifikations-Lektion: ausführbares Fixture-Orakel oder zumindest Abgleich-Schritt Vertrag↔Validator je Autorisation).
+
+### F-11 — Vertrags-Referenz auf OKF-0.2-Spezifikation nicht verlinkbar (Prosa-Zitat), Normquelle nicht reproduzierbar
+
+- **Befund:** `schema/wiki-compiler.md:§8` (Z.195) und `schema/validator.md:251` zitieren „OKF-Spezifikation (Google Cloud, `knowledge-catalog`)" ohne URL/Version — die `okf_version`-Regel und §7 Punkt 14 hängen an dieser Quelle, die nicht auflösbar ist.
+- **Quelle:** `schema/wiki-compiler.md:195`; `schema/validator.md:251`.
+- **Disposition:** Defer (Normreferenz ergänzen) — kleine Korrektur.
+
+### F-12 — Adapter-Konformität (AD-10) wird vom Validator nicht geprüft, obwohl Vertrag sie als MUSS normiert
+
+- **Befund:** Der Vertrag verlangt `adapters/` MÜSSEN mit dem Vertrag konform sein (AD-10, Z.18); der Validator (§1 Z.30–33) erklärt `adapters/` als „nicht validiert". Kein Prüfschritt deckt die Adapter-Semantik ab.
+- **Quelle:** `schema/wiki-compiler.md:18`; `schema/validator.md:30–33`.
+- **Disposition:** Accept-as-is (dokumentierte Abgrenzung des Validators auf Bundles; Adapter-Konformität ist Chef-/Review-Verantwortung) — als akzeptierte Abweichung festhalten, damit spätere Retros nicht re-flaggen.
+
+### F-13 — `sources`-Eintrag ohne `resource` ist als „Punkt 12"-FAIL klassifiziert, obwohl Vertrag-Punkt 12 primär Formverstöße listet
+
+- **Befund:** `schema/wiki-compiler.md` §7 Punkt 12 (Z.184) nennt Formverstöße (Liste/Map/Skalar); ein Eintrag ohne `resource` ist eine valide Map ohne Pflichtangabe. Der Validator ordnet ihm Punkt 12 zu (Fixture 12a, Z.212). Die Zuordnung ist vertretbar („in nicht erlaubter Form"), aber nicht ausdrücklich im Vertrags-Wortlaut verankert.
+- **Quelle:** `schema/wiki-compiler.md:184`; `schema/validator.md:67,212`.
+- **Disposition:** Accept-as-is (interpretationsgetragen, dokumentiert in validators §3 Punkt 12 mit Vertrags-Verweis §3.3) — kein Fix-now, aber als Beobachtung für die Re-Konsistenz bei F-01 mitnehmen.
+
+### F-14 — `resource`-Pfade, die außerhalb `raw/` landen aber existieren (z. B. `README.md`), haben kein Negativ-Fixture
+
+- **Befund:** §6.2 Schritt 5 (Z.168) deckt „nicht unter `raw/`" ab, aber es fehlt ein Negativ-Fixture für diesen Fall; Determinsmus ist nur durch Beispiele belegt.
+- **Quelle:** `schema/validator.md:168` vs. §7.1 (Z.196–216, kein Fall außerhalb raw ohne Traversal).
+- **Disposition:** Defer (mit Kontext) — Fixture-Ergänzung bei nächster Validator-Revision.
+
+### F-15 — `stale_after`-Lebenszyklus-Konsequenz (Epic 3) hat keine Verankerung im Deferred-Work-Zeitplan
+
+- **Befund:** §6.4 (Z.181) verweist auf „Epic 3" für die Konsequenz der Veraltung; `deferred-work.md` listet die BH-8-Ableitung (Z.29–31), ohne konkrete Story-Zuordnung.
+- **Quelle:** `schema/validator.md:181`; `_bmad-output/implementation-artifacts/deferred-work.md:29–31`.
+- **Disposition:** Accept-as-is (Epic-3-Gate mit Story-Autorisierung ist vorgesehen; reichen als Verankerung) — als Beobachtung notieren.
+
+## Behavior-Verifikation (Phase 2)
+
+**Methodik:** Das Bundle wurde gegen die Validator-Instruktion (Story 1.4) deterministisch ausgeführt (jede §7-/§6-Bedingung als mechanische Prüfung). Ergebnis:
+
+- **Punkt 8 (Bundleroot):** `wiki/index.md` trägt exakt `type: bundle` + `okf_version: "0.2"`, kein weiteres Feld → PASS.
+- **Punkt 9 (Exklusivität):** `grep -rn "okf_version\|type: bundle" wiki/` → nur `wiki/index.md` → PASS.
+- **Punkt 10 (Frontmatter-Exklusivität):** keine Area-`index.md`/`log.md` beginnt mit `---` → PASS.
+- **Punkt 11 (Index-Regel):** keine Areas vorhanden → nicht auslösbar → PASS (leeres Bundle).
+- **Concept-Prädikat:** keine Concepts im Bundle → keine Punkt-1/2-Auslöser.
+- **§3.2-Voraussetzungen:** `wiki/index.md` existiert; kein `log.md` an Nicht-Root-Position → PASS.
+- **§6.1 EC-1 Existenz:** alle drei `raw/`-Evidenz-Dateien existieren (verifiziert) → PASS (keine Concepts, keine `resource`-Referenzen zu prüfen).
+- **§6.5 non-md:** keine non-.md-Dateien unter `wiki/` → keine Verletzung.
+
+**Geprüft-als-sauber:** Die 14 Strukturpunkte und §3.2 sind am realen Bundle zufriedenstellend. Der Lauf deckt aber nur das **leere** Bundle (keine Areas/Concepts) — die eigentliche Validator-Abbildung (F-01 bis F-08) ist anhand der Fixtures statisch geprüft, nicht durch dynamische Fixture-Ausführung. Die §6-Fixtures fehlen (F-02), daher ist die Run-FAIL-Gate-Fähigkeit des Validators für die fachlichen Checks am echten Bundle **nicht** dynamisch bestätigt.
+
+## Previous-Retro-Follow-through
+
+Keine frühere Retrospektive vorhanden; Sprint-Status enthält keine `action_items` → nichts nachzuverfolgen.
+
+## Action Items (Phase 4)
+
+Vorschläge — werden **nicht** automatisch angewendet; der Mensch entscheidet, was ausgeführt wird.
+
+| ID | Aktion | Eigentümer | Quelle |
+|----|--------|-----------|--------|
+| AI-1 | Validator `schema/validator.md` mit autorisiertem Vertrag re-konsistieren: Fixture 14c/§4.3 (`at` als reines Datum = SUCCESS) beseitigen oder als bewusste Toleranz via Story-Verfahren neu autorisieren (Änderung §3.4/§3.5/§7-Punkt-14 des Vertrags) — damit die 1:1-Abbildung wieder gilt | Story-Verfahren (Dev+Review) | F-01 |
+| AI-2 | $6-Fixtures ergänzen: EC-1 (Negativ: fehlende `raw/`-Datei; Positiv: vorhandene), EC-3 (Kalender-Validität), stale_after-WARN-Kanal, EC-11 non-md — und Validator-Zertifizierung in `wiki/log.md` gegen erweiterte Fixtures neu ausführen | Dev (Story 1.4-Follow-up) / Review | F-02 |
+| AI-3 | §3.2-Voraussetzungspflejesten als „Fachliche Prüfung V-1/V-2" labeln (statt „FAIL (Struktur)" außerhalb §5-Grammatik) oder Vertrag §7 um Fall „fehlende Bundleroot" erweitern (mit Autorisierung) | Dev (Validator-Revision) | F-03 |
+| AI-4 | `source.md`-Provenienz korrigieren: `_bmad-output/` IST versioniert (Herkunft auf Commit-Hash stützen) — Fix in `raw/<quelle>/source.md:13–14`; Deferred-Work-Checksumme (SHA-256) als Konsequenz voranbringen | Dev (Story-1.2-Follow-up) | F-09 |
+| AI-5 | BOM-/Leerzeilen-Stripping von Punkt 10 auf Punkte 2/8 erweitern (einheitliche Frontmatter-Erkennung) | Dev (Validator-Revision) | F-05 |
+| AI-6 | Ausführbare/mechanische Verifikation des Validators einführen (Fixture-Orakel-Skript oder zumindest Vertrag↔Validator-Abgleich je Autorisation) — minimiert Wiederauftreten von F-01/F-02 | Prozess (BMAD-Dev-Schleife) | F-10 |
+| AI-7 | Defer-Kontexte sichern: F-04 (verschachtelte Duplikat-Keys), F-06 (`today`-Zeitzone), F-07 (Index-Regel bei verschachtelten Areas), F-08 (`.MD`-Großschreibung), F-11 (OKF-Referenz-URL), F-14 (`raw/`-extern-Fixture) — als Folge-Aufgaben für Epic-2/3 oder Validator-Revision notieren | Epic-2/3-Planung | F-04…F-15 |
+
+Keine Zeitangaben — bewusst.
+
+## Acceptance-Verdict (Phase 4)
+
+**Verdikt: `accepted-with-open-items`**
+**Kriterien:** profiled (keine deklarative Akzeptanzliste; aus Story-Intent + Epic-Context + Vertrag §7/§8 abgeleitet).
+
+**Begründung:**
+- Alle 4 Stories sind `done`; `pending_stories` leer → kein Rejected-Zwang.
+- Die deklarierten Ziele sind im Wesentlichen erreicht: Workspace-Stamm (Stories 1.1/1.2) korrekt etabliert, `raw/`-Evidenz byte-identisch materialisiert und immutable (verifiziert), Vertrag autorisiert (1.3), Validator-Instruktion liegt vor und bildet die 14 Punkte 1:1 ab (1.4).
+- **Aber:** Drei Befunde (F-01, F-02, F-03) betreffen die Kern-Fähigkeit „Determinis­tische Validierung bildet die Norm 1:1 ab und ist reproduzierbar prüfbar" (AD-17h, F-2/AD-1b). F-01 ist ein unautorisierter Bruch mit dem Vertrag, F-02/F-03 sind Verifikations-/Klassenlücken. Die ist ein dokumentierter, nicht-blokkierender Rest, der als offene Items (AI-1…AI-3) adressiert wird.
+- Kein Blocker für nachfolgende Epics: Epic 2 kann mit dem heutigen Validator Concepts validieren (die 14 Strukturpunkte sind abgedeckt). Die F-Items sind Follow-ups, kein Stop.
+- Menschliche Bestätigung: Keine — Verdikt ist eine Maschinen-/Analysten-Entscheidung. Ein Mensch darf es überstimmen.
+
+## Offene Fragen
+
+1. **F-01 entgegen dem frozen-intent:** Ist die `at`-als-Datum-Toleranz als bewusste Vertragserweiterung gewollt (dann Story-Autorisierung) oder ein Review-Schlupf? Die Antwort ändert, ob der Vertrag oder der Validator zu ändern ist.
+2. **F-07 (Index-Regel):** Wie tief sollen Areas/Unterordner gehen? Epic-2 legt die Antwort fest (Story 2.5 progressive Discovery).
+3. **Verifikations-Tiefe:** Soll das Projekt zu einem ausführbaren Fixture-Orakel wechseln (D-3 erlaubt nur Instruktionen — ein Orakel würde die D-3-Grenze berühren)? Oder bleibt es beim dokumentarischen Abgleich?
+
+## Assumptions
+
+Interaktiver Lauf: keine headless-Annahmen. Der Epic wurde aus `detect-epic` bestätigt (höchstes Epic mit `done`-Story); der Nutzer wurde eingangs um Going-in-Themen gebeten (keine Rückmeldung — Analyse lief ohne Zusatzgewicht).

_bmad-output/implementation-artifacts/spec-1-4-schema-validierung-für-bundle-implementieren.md

@@ -112,15 +112,54 @@ Wichtige Normalform-Entscheidungen (aus Deferred-Work):
 - Konformitäts-Smoke an den Referenzfixtures: `grep -nE '\bFAIL\b|\bSUCCESS\b' schema/validator.md` — expected: je Punkt mindestens ein Beispiel mit klar bezeichneter Erwartung.
 - Verdikt-Format: `grep -nE '\b(SUCCESS|FAIL)\b' schema/validator.md` — expected: ein Verdikt-Verb pro Datei-Syntax dokumentiert.
 
+**Strenger Vertrag↔Validator-Abgleich (Retrospective F-10/AI-6, 2026-08-16):** Die dokumentarischen Greps oben sind Existenz-/Mentions-Checks und fangen semantischen Drift nicht (F-01 kam dadurch durch). Als Nachschärfung gilt ab jetzt bei jeder Autorisierung/Re-Derivation des Validators die folgende deterministische Abgleich-Liste (§7 des Vertrags ↔ exakte Validator-Prüfschritt-Zelle): Jeder der 14 Punkte MUSS in `schema/validator.md` als eigene Prüfschritt-Zeile der §3-Tabelle vorhanden sein, und **kein** zusätzlicher §7-Punkt darf existieren. Mechanisch:
+
+```text
+Equivalent-Check: die Menge der Punkt-Nummern in der §3-Tabelle = {1..14}
+                   (mechanisch: `grep -oE '^\| ([0-9]+) \|' schema/validator.md`
+                   → sort -u → {1,2,…,14}; keine Punkt-Nummer >14, keine Lücke)
+Konsistenz:        `grep -nE 'Punkt [0-9]+' schema/validator.md` — expected:
+                   jede Punkt-Nummer in der §3-Tabelle ist ein §7-Punkt des Vertrags
+Abgleich-Tabelle:  §7-Punkt-Nr. ↔ §3-Prüfschritt-Zeile ↔ Fixture-Nr. (§7.1/§7.2/§7.3)
+                   (siehe Tabelle unten im Abschnitt „Verifikations-Beleg“)
+```
+
+Diese Abgleich-Tabelle ist als „Verifikations-Beleg“ geführt (2026-08-16, Stand Validator Revision 6, Vertrag autorisiert Revision 1) und wird bei jeder künftigen Vertrags-/Validator-Änderung revalidiert.
+
 **Manual checks (if no CLI):**
 - `schema/validator.md` ist rein textuell (kein Programmcode/Executable-Abschnitt) und beginnt mit Zweck & Aufruf.
 - Alle 14 Punkte aus Vertrag §7 sind als eigene Prüfschritte vorhanden; keine darüber hinausgehende Invaliditätsklasse.
 - Die 8 Deferred-Work-Direktiven sind deterministisch beantwortet und in der Instruktion auffindbar.
 - `wiki/log.md` enthält (nach Zertifizierung) einen datierten Eintrag „Validator-Selbstprüfung gegen Fixtures: PASS".
 
+### Verifikations-Beleg — Vertrag↔Validator↔Fixtures-Abgleich (Stand 2026-08-16)
+
+Revalidierung bei jeder Vertrags-/Validator-Änderung: konsistente eine-Zuordnung, keine Punkt-15, keine Lücke.
+
+| Vertrag §7-Punkt | Validator §3-Zeile (Prüfschritt) | Fixture-Negativ (§7.1) | Fixture-Positiv (§7.2) | Anmerkung |
+|---|---|---|---|---|
+| 1 (Concept ohne `type`) | Z. „Punkt 1: concept ohne type…“ | Fixture 1 | Fixture 1 | |
+| 2 (nicht-reservierte `.md` ohne Frontmatter/`type`) | Z. „Punkt 2: …“ | Fixture 2 | Fixtures 2, 2a | 2a: BOM/Leerzeile (AI-5) |
+| 3 (`sources`→`wiki/`-Pfad) | Z. „Punkt 3: …“ | Fixture 3 | Fixture 3 | |
+| 4 (`source` außerhalb `raw/`, Grammatik) | Z. „Punkt 4: …“ | Fixture 4 | Fixture 4 | |
+| 5 (`status`-Wert) | Z. „Punkt 5: …“ | Fixture 5 | Fixture 5 | |
+| 6 (unautorisiertes Feld / Subset) | Z. „Punkt 6: …“ | Fixture 6 | Fixture 6 | |
+| 7 (leere `by`) | Z. „Punkt 7: …“ | Fixture 7 | Fixture 7 | |
+| 8 (Bundleroot-Deklaration) | Z. „Punkt 8: …“ | Fixtures 8, 8a | Fixtures 8, 8b | 8a/8b: V-1/BOM |
+| 9 (`okf_version`/`type:bundle` außerhalb) | Z. „Punkt 9: …“ | Fixture 9 | Fixture 9 | |
+| 10 (Frontmatter in Area/`log.md`) | Z. „Punkt 10: …“ | Fixtures 10, 10a | Fixture 10 | 10a: V-2 |
+| 11 (Index-Regel) | Z. „Punkt 11: …“ | Fixture 11 | Fixture 11 | Struktur-Klasse separate V/w/o §7 |
+| 12 (`sources`/`verified`/`generated`-Form) | Z. „Punkt 12: …“ | Fixtures 12, 12a | Fixtures 12, 12a | |
+| 13 (doppelter Key) | Z. „Punkt 13: …“ | Fixture 13 | Fixture 13 | |
+| 14 (Wert-Formate) | Z. „Punkt 14: …“ | Fixtures 14, 14a, 14b, 14c | Fixtures 14, 14b, 14c, 14d | 14c/BOM-14c AI-1 |
+
+**§6-/V-Fixtures (fachliche Prüfklassen, keine §7-Punkte):** §7.3 deckt EC-1 (Existenz), EC-3 (Kalender), stale_after-WARN (§6.4), EC-11 (non-md), V-1 (fehlende Bundleroot) und V-2 (`log.md`-Position) ab — siehe `schema/validator.md` §7.3 (Revision 6). Diese Zeilen belegen, dass die fachlichen Prüfungen nicht aus dem §7-Katalog fallen (F-02 belegt).
+
+**Verdikt-Grammatik (F-10-Härtung):** Der Abgleich ist maschinenlesbar (Grep-Rezept oben); eine `Punkt 15`-Zeile oder ein fehlender Punkt 1–14 schlägt den Re-Check fehl (kein LLM-Urteil). Wird bei jeder Autorisierungsschleife als Pflicht-Schritt geführt (KEEP bei Re-Derivation).
+
 - **2026-08-15, Loop 2 (Review: Blind-Hunter + Edge-Case-Hunter + Verification-Gap, kein bad_spec):** Die drei Review-Layer fanden keinen norm-beherrschenden Defekt — kein neuer Loopback. Alle Befunde waren als `patch` direkt in `schema/validator.md` lösbar (17 Patches, Revision 1→2): §3.2 Bundleroot-/Reserviert-Voraussetzungen als Nicht-§7-Pflichten, Punkt 6/9-Exemption, Punkt 9 auf Dateiinhalt, Punkt 10 BOM-Stripping, Punkt 11 deterministische Link-Prüfung (ohne Story-2.3-Vorwegnahme), Punkt 12 fehlende/leere `resource`, Punkt 14 `usage_count`-Integer-Typ, §4.3 akzeptiert `±HH:MM`, §4.4-Ausführungs-Reihenfolge mit EC-1-Aggregation, §5-WARN als Berichtskanal, §6.2 Punkt-4-vor-3-Priorität, Fixture-Ergänzungen. Drei Befunde als Deferred/Normreferenz dokumentiert (F15→Epic 4; genau-eine-Linkform→Story 2.3 mit `deferred-work.md`-Eintrag; `stale_after`-Konsequenz→Epic 3, bereits BH-8-adressiert). Abschluss: `schema/validator.md` (Revision 2) final; all 14 Punkte 1:1 abgebildet, no eigene Invaliditätsklasse.
 
-- **KEEP (muss bei Re-Derivation überleben):** die 14-Punkte-1:1-Abbildung als mechanische Prüfschritte mit deterministischer Fehlerursache; die 8 Deferred-Work-Entscheidungen (EC-1, EC-3, BH-14, F2, BH-8, EC-11, F17, F18); Verdikt-Format SUCCESS/FAIL mit textueller Ursache (NFR-4); Abbruch-Regel (erste verletzte Bedingung); Selbstbegrenzung (abschließende Liste, keine eigene Invaliditätsklasse, kein Schreibzugriff); Positiv-/Negativ-Fixtures (AD-17h); §3.2-Voraussetzungsprüfungen ausdrücklich als Nicht-§7-Pflichten.
+- **KEEP (muss bei Re-Derivation überleben):** die 14-Punkte-1:1-Abbildung als mechanische Prüfschritte mit deterministischer Fehlerursache; die 8 Deferred-Work-Entscheidungen (EC-1, EC-3, BH-14, F2, BH-8, EC-11, F17, F18); Verdikt-Format SUCCESS/FAIL mit textueller Ursache (NFR-4); Abbruch-Regel (erste verletzte Bedingung); Selbstbegrenzung (abschließende Liste, keine eigene Invaliditätsklasse, kein Schreibzugriff); Positiv-/Negativ-Fixtures (AD-17h); §3.2-Voraussetzungsprüfungen ausdrücklich als Nicht-§7-Pflichten; **der strenge Vertrag↔Validator↔Fixtures-Abgleich (F-10/AI-6, Verifikations-Beleg-Tabelle) als Pflicht-Re-Check bei jeder Autorisierung**.
 
 ## Suggested Review Order
 

_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-15-2026
+last_updated: 08-16-2026 10:30
 project: wow20
 project_key: NOKEY
 tracking_system: file-system
@@ -40,7 +40,7 @@ development_status:
   1-2-sources-lokal-unter-raw-bereitstellen: done
   1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren: done
   1-4-schema-validierung-für-bundle-implementieren: done
-  epic-1-retrospective: optional
+  epic-1-retrospective: done
 
   epic-2: backlog
   2-1-concepts-aus-source-material-erzeugen-okf-konform: backlog
@@ -73,3 +73,79 @@ development_status:
   5-2-tool-unabhängigen-zugriff-und-agent-lesbarkeit-gewährleisten: backlog
   5-3-agent-unabhängige-compiler-regeln-dünne-adapter: backlog
   epic-5-retrospective: optional
+action_items:
+  - id: "epic-1-retro-item-1-validator-schema-validator-md-mit-autori"
+    epic: 1
+    action: "Validator schema/validator.md mit autorisiertem Vertrag re-konsistieren:
+      at-als-reines-Datum-Toleranz (§4.3/Fixture 14c) beseitigen oder via Story-Verfahren
+      als Vertrags-Aenderung neu autorisieren"
+    owner: "dev+review"
+    status: done
+    closed: "2026-08-16"
+    resolution: "Option A (Nutzer): Toleranz rueckgaengig — at MUSS volles ISO-8601-Datetime
+      sein; reines Datum => FAIL Punkt 14. schema/validator.md Revision 3; Vertrag unveraendert."
+    ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-01"
+  - id: "epic-1-retro-item-2-6-fixtures-ergaenzen-ec-1-existenz-ec-3"
+    epic: 1
+    action: "§6-Fixtures ergaenzen (EC-1 Existenz, EC-3 Kalender, stale_after-WARN-Kanal,
+      EC-11 non-md) und Validator-Zertifizierung in wiki/log.md gegen erweiterte Fixtures
+      neu ausfuehren"
+    owner: "dev"
+    status: done
+    closed: "2026-08-16"
+    resolution: "Neue Fixture-Tabelle schema/validator.md §7.3 (EC-1, EC-3, WARN, EC-11);
+      Validator auf Revision 4; Zertifizierung in wiki/log.md nachgefuehrt."
+    ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-02"
+  - id: "epic-1-retro-item-3-3-2-voraussetzungspruefungen-als-fachlic"
+    epic: 1
+    action: "§3.2-Voraussetzungspruefungen als Fachliche Pruefung V-1/V-2 labeln oder
+      Vertrag §7 um Fall fehlende Bundleroot erweitern (mit Autorisierung)"
+    owner: "dev"
+    status: done
+    closed: "2026-08-16"
+    resolution: "Label-Ansatz gewaehlt: §3.2 als V-1/V-2 fachliche voraussetzungspruefung;
+      FAIL (Voraussetzung) ... (V-1|V-2); Fixtures in §7.1/§7.3; Vertrag unveraendert."
+    ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-03"
+  - id: "epic-1-retro-item-4-source-md-provenienz-korrigieren-_bmad-o"
+    epic: 1
+    action: "source.md-Provenienz korrigieren: _bmad-output/ ist versioniert; Herkunft
+      auf Commit-Hash stuetzen und Deferred-Work-Checksumme (SHA-256) voranbringen"
+    owner: "dev"
+    status: done
+    closed: "2026-08-16"
+    resolution: "raw/*/source.md korrigiert; Herkunft auf Commit 6cc667d + SHA-256 gestuetzt
+      (byte-identisch zur Evidenz); Deferred-Work-Checksumme damit vorangebracht/umgesetzt."
+    ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-09"
+  - id: "epic-1-retro-item-5-bom-leerzeilen-stripping-von-punkt-10-au"
+    epic: 1
+    action: "BOM-/Leerzeilen-Stripping von Punkt 10 auf Punkte 2/8 der Validator-Instruktion
+      erweitern (einheitliche Frontmatter-Erkennung)"
+    owner: "dev"
+    status: done
+    closed: "2026-08-16"
+    resolution: "Gemeinsame gestrippte Frontmatter-Erkennung in §3-Praaembel; Punkte 2/8/10
+      nutzen sie; Positiv-Fixtures 2a/8b ergaenzt; Revision 6; Vertrag unveraendert."
+    ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-05"
+  - id: "epic-1-retro-item-6-ausfuehrbare-mechanische-verifikation-de"
+    epic: 1
+    action: "Ausfuehrbare/mechanische Verifikation des Validators einfuehren (Fixture-Orakel
+      oder Vertrag↔Validator-Abgleich je Autorisation)"
+    owner: "process"
+    status: done
+    closed: "2026-08-16"
+    resolution: "Konsistenz-Abgleich (Nutzer): strenger Vertrag↔Validator↔Fixtures-Abgleich
+      (14 Punkte/keine Punkt 15) als Pflicht-Re-Check in spec-1-4-Verification; bleibt in
+      D-3 (kein Standalone). Verifikations-Beleg-Tabelle ergaenzt."
+    ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-10"
+  - id: "epic-1-retro-item-7-folge-aufgaben-fuer-epic-2-3-sichern-ver"
+    epic: 1
+    action: "Folge-Aufgaben fuer Epic-2/3 sichern: verschachtelte Duplikat-Keys, today-Zeitzone,
+      Index-Regel bei verschachtelten Areas, .MD-Grossschreibung, OKF-Referenz-URL,
+      raw/-extern-Fixture"
+    owner: "epic-2/3-planung"
+    status: done
+    closed: "2026-08-16"
+    resolution: "F-04/F-06/F-07/F-08/F-11/F-14 als Defer-Kontexte in deferred-work.md (append-only)
+      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"