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/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).