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

epic, date, verdict, criteria, headless

epic	date	verdict	criteria	headless
1	2026-08-15	accepted-with-open-items	profiled	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).