wow20/_bmad-output/implementation-artifacts/epic-2-retro-2026-08-18.md

epic, date, verdict, criteria, headless

epic	date	verdict	criteria	headless
2	2026-08-18	accepted-with-open-items	declared	false

Retrospective Epic 2 — OKF-Concepts erzeugen & verlinken

Epic summary

• Epic: 2 — OKF-Concepts erzeugen & verlinken
• Diff-Range: a67ba65..f41ac71 (erster Story-Commit 6105a7b^ … letzter Commit f41ac71)
• Commits: 15 im Range (davon 2 Merges: 7e1f449 Story 2.2, 64a0f6a Story 2.4; beide gemessen). Nicht-Merge-Churn in schema/+wiki/: 543 Insertions / 6 Deletions über 9 Dateien.
• Stories: 2.1 (done), 2.2 (done), 2.3 (done), 2.4 (done), 2.5 (done) — keine pending. epic-2-retrospective: optional → wird in Phase 5 auf done gesetzt.
• Abnahmekriterien: deklariert in _bmad-output/planning-artifacts/epics.md (Epic-2-Block + Stories 2.1–2.5, je AC-Zeilen) → Verdikt-Basis declared.
• Evidence-Inventar:
  • Story-Specs 2.1–2.5 unter _bmad-output/implementation-artifacts/ (jede mit baseline_commit/Verification-Beleg)
  • schema/compiler.md (317 Z., 84 KB; Revision 2.3; +404/−87 net über 11 Commits) — das eigentliche Lieferprodukt (Agent-Instruktion mit re-executierbaren Selbsttest-Formeln, §5.5–§5.8, §6.5/§6.6)
  • schema/validator.md (Rev 8): der Diff-Range enthält die Rev-8-Autorisationsrunde (Option-A-Heilung Story 2.1, Ende Epic 1) — für Epic 2 konform unverändert (AD-3/D-3-Freeze); der bekannte Punkt-11-Vorbehalt (file-relative Area-Lesart) bleibt offen und ist Rev-9-Aktionsitem
  • Wiki-Baum (7 Dateien): index.md, log.md, 3 Root-Concepts, wissensarchitektur/index.md (Area), wissensarchitektur/source-material.md (Area-Concept)
  • _bmad-output/implementation-artifacts/deferred-work.md (append-only), sprint-status.yaml (2-5 Retro key), wiki/log.md (32 Z., 5 Einträge Story 2.1–2.5 + Nachweise)
• Fehlend: Session-Logs (nicht in dieser Umgebung verfügbar) → Prozess-Lektionen nur aus git-loggablem Verhalten; die Verhaltens-Verifikation wurde stattdessen durch Re-Exekution der Selbsttest-Formeln ersetzt (Abschnitt Behavior verification).

Findings

Drei Blickwinkel: (a) Aggregat-Ansichten (über den gesamten Diff-Range deterministisch erhoben), (b) Verhaltenscheck der Selbsttest-Formeln (re-executiert, Abschnitt Behavior verification), (c) Diff-Scope-Review — bmad-review-Code-Linsen (Adversarial / Edge-Case-Hunter / Verification-Gap) über den Schema+Wiki-Diff. Jedes Finding trägt Quelle (Datei : Zeile/Commit) und Disposition (fix now / defer / accept).

F-01 — §5.5-Provenienz-Selbsttest-Formel ist nicht rekursiv und übersieht jeden Area-Concept-Kontakt (Adversarial F1, Edge-Case #4; fix now, Kern-Defekt Story 2.4/2.5)

• Quelle: schema/compiler.md §5.5 Pkt. 1/4, Z. 81/104 — sh -c "grep -nE '\(raw/' wiki/*.md".
• Beleg (live): wiki/*.md (root-only) → 29 Treffer; rekursiv wiki/ → 43; das Area-Concept wiki/wissensarchitektur/source-material.md trägt 5 (raw/-Verweise, die die dokumentierte Formel nie inspiziert. Die Kriterien in Z. 104–106 („belegte Aussage → Inline-raw/-Verweis je Beleg auffindbar per `grep -nE '(raw/') behaupten eine bundeweite Selbstprüfung.
• Auswirkung: Die claim-granulare Provenienz-Garantie (FR-3/AD-4a) und der AD-17h-Determinismus-Anspruch sind für die Artefaktklasse, um die es in Story 2.4/2.5 geht (Area-Concepts), faktisch nicht exerziert: Ein fehlender/typo-hafter Inline-raw/-Verweis im Area-Concept passiert den Selbsttest still. Der Formeltext „erfasst also …" (Z. 81) ist unvollständig.
• Wurzel: Shell-Glob wiki/*.md ist root-only; keine -r, kein --include.
• Disposition & Prävention: fix now → Formel auf rekursiv grep -rnE '\(raw/' wiki/ --include='*.md' --exclude=log.md (bzw. Area-inkludierend) umstellen; Lektion: re-executierbare Formeln müssen der gewachsenen Baumstruktur des Folge-Epics folgen (Area-Ebene seit Story 2.4).

F-02 — Punkt-11-Wortlaut vs. gepinnte file-relative Area-Linkform: Instruktion und Validator sind strukturell nicht gleichzeitig „in force" (Adversarial F2/F10, Verification-Gap F2; fix now (autorisierte Rev-9), alternativ Doku-Defer)

• Quelle: schema/validator.md Punkt 11 (Rev 8, Z. 70: „als relativer Bundle-Pfad"); schema/compiler.md §5.6 Pkt. 1 (Z. 129–131: file-relativ mit .md-Endung), §5.8 Pkt. 2 (Z. 229, „Bekannte offene Lücke … wörtlich-mechanischer Check meldete Concept nicht verlinkt=wissensarchitektur/source-material"); deferred-work.md Z. 284–287 (Status offen, Rev-9-Aktionsitem).
• Beleg (live): wiki/wissensarchitektur/index.md Z. 9 verlinkt file-relativ ](source-material.md); die wörtliche Identität wissensarchitektur/source-material kommt in wiki/index.md nicht vor (grep → 0). Ein wörtlich-mechanischer Rev-8-Punkt-11-Check würde das Area-Concept als „nicht verlinkt" melden — das Live-Bundle zeigt genau diese Lage.
• Auswirkung: Die §5.8-Discovery-Teilachse „Rooth→Area→Concept" ist nicht unabhängig re-verifizierbar (Verification-Gap F2): die §5.8-Selbsttest-Formel deckt nur Root→Area (Lauf A) und Tiefe ≥ 3 (Lauf B); die Area→Concept-Koordinate wird an einen Punkt 11 delegiert, dessen Wortlaut die formale Clusterung der §5.6-Pin-Form widerspricht. Das Log („alle 7 SUCCESS inkl. Punkt 11") ist nur über eine aufgelockerte Punkt-11-Lesart konsistent.
• Wurzel: Punkt 11 (frozen, Vertrag §7) kennt keine file-relative Area-Schreibweise; die Pin-Form (Story 2.3) und die Area-Link-Logik (Story 2.4/2.5) sind Produkt der Instruktionsebene ohne Vertrags-/Validator-Change (AD-3-Doktrin).
• Disposition & Prävention: fix now → Erteilung der autorisierten Validator-Rev-9 mit formalisierter Punkt-11-Area-Lesart (relative OKF-Pfad-Identität, auch file-relativ in Area-Index; bereits als Action-Item code-review-2-1-item-2 gehalten). Lektion: Der D-3/AD-3-Freeze darf Vertrag/Validator nur ändern, wenn er formal autorisiert wird; „kein Change" muss dieselbe Währung (autorisiert vs. offen) wie „Change" tragen.

F-03 — §5.8-Lauf B „schließt die Area-ohne-index.md-Lücke" — tatsächlich blind für die Tiefe-2-Variante (wiki/<a>/concept.md ohne index.md) (Edge-Case #2; fix now, konservativ Defer)

• Quelle: schema/compiler.md §5.8 Pkt. 2 (Z. 216: Lauf A find -mindepth 2 -name index.md, Lauf B find -mindepth 3); Prosa Z. 223/230 („schließt auch die Area-ohne-index.md-Lücke").
• Beleg (Sandbox, synthetischer Baum wiki/a/concept.md ohne wiki/a/index.md): §5.8-Formel exakt aus Z. 216 → keine Ausgabe, Exit 0 = Discovery-SUCCESS auf einem Bundle, das strukturell invalide ist (Area ohne Index → Validator Punkt 11). Lauf A findet kein index.md, Lauf B beginnt bei Tiefe 3, das Konzept liegt auf Tiefe 2.
• Auswirkung: Ein Producer kann die Area-index.md vergessen und der §5.8-Selbsttest meldet SUCCESS; die einzige Schutzlinie ist der (nicht re-runbare, bekannte) wörtliche Punkt-11-Sandbox-Nachweis.
• Wurzel: Beide Läufe sind find-Schwellen, keine strukturelle Konzept-Derivation.
• Disposition & Prävention: fix now (einfach) → Lauf A um „Area-Concept ohne Area-index.md" erweitern (z. B. Ordnung wiki/<a>/<concept>.md ohne index.md jenseits einer Area melden), oder dokumentiert als konservatives Defer (bestehende Punkt-11-Linie fängt es ab, sobald Rev-9 die Lesart trägt).

F-04 — Formel-4-Basisfilter-Asymmetrie: --exclude=log.md (Ist) vs. grep -v "log.md$" (Extraktion) invertieren sich für …log.md-suffigierte Konzepte (Edge-Case #3; fix now)

• Quelle: schema/compiler.md §5.6 Pkt. 3 Formel 4 (Z. 162–163); deferred-work.md (Basename-Ziel-Loop-2-Fix).
• Beleg (Sandbox): Konzept wiki/analog.md → Ist (--exclude=log.md, Basename gleich log.md) zählt es ein; Extraktionsfilter (grep -v "log.md$" — Basename-Endung) schließt aus, simuliert: Ist 2 vs. Extraktion 0 → deterministischer Fehlalarm 38 ≠ Baseline auf einem konformen Baum.
• Auswirkung: Ein legitimes kebab-slug-Konzept, dessen Name auf log endet (analog, compiler-log, …), bricht Formel 4 ohne inhaltlichen Grund — und zwar genau durch den Loop-2-Basename-Fix, der die umgekehrte Inversion (künftiges Area-log.md) heilen sollte.
• Wurzel: --exclude=log.md ist genau-Basename (= log.md), grep -v "log.md$" ist Endungs-Muster (jegliches xlog.md) — die beiden filter semantisch unvereinbar.
• Disposition & Prävention: fix now → beide Filter auf dieselbe Semantik bringen (entweder genau-Basename log.md auf beiden Seiten — z. B. --exclude=log.md für die Extraktion via git ls-tree ... | grep -v '^wiki/log\.md$' — oder rekursiv-Basename grep -v '/log\.md$' in beiden). Lektion: „Basename-Filter" meint je nach Formel etwas anderes; jede Formel4-Seite muss nominal die nämliche Exklusionsmenge bilden.

F-05 — §5.8-Lauf A erkennt „reachability" auf nicht-navigationalen Text (Code-Fence/Blockquote) und akzeptiert die ./-Variante, die der §5.6-Form-Check exkludiert (Verification-Gap F1, Edge-Case-Replik; fix now)

• Quelle: schema/compiler.md §5.8 Pkt. 2, Z. 216 (Lauf A, grep -qF "]($a/index.md"); §5.6 Pkt. 3 Formel 2 (Z. 146, grep -vE '^\.') attackiert ./-Ziele.
• Beleg: (a) Lauf A als roher Substring über die ganze Datei (auch in Code-Fence/Blockquote/comments) → Bereich aus Fence „verlinkt" ohne Navigationslink (AD-9 gebrochen). (b) ./-Varianten: Lauf A akzeptiert ](./a/index.md (verifikationsrelevante Alternative), Formel 2 exkludiert ./-Präfixe als „keine Bundle-Pfad-Form" → zwei Checks widersprechen sich über die „gepinnte Form" (FR-10: genau eine erlaubte Form).
• Auswirkung: Die AD-9-Navigationsgarantie ist nur textuell (Substring), nicht strukturell abgesichert; das „genau-eine-Form"-Pin ist zwischen §5.6 und §5.8 nicht eindeutig.
• Wurzel: grep -qF ist markdown-agnostisch; die ./-Variante wurde in Manche Dokumentationen als zulässig erachtet (Loop-2-Eintrag „beide Varianten zulässig") — die Form-Check-Schärfung von Story 2.3 (AD-7b) ist damit inkonsistent.
• Disposition & Prävention: fix now → Lauf A mit Link-Syntax-prüfenden Greps (nur echte ](-Markdown-Links, nicht Code-Fence/Blockquote) bzw. ./-Variante aus dem §5.6-Pin nehmen oder §5.8 auf die Pin-Form ausrichten; Lektion: Ober- und Unter-Checks müssen dieselbe „erlaubte Form" definieren.

F-06 — Formel-4-Baseline an einen Commit (862cf41) gepinnt; erneute Datei-Zuwächse (= jeder künftige neue Concept/Area) erfordern eine Re-Baseline-Pflicht ohne definierte Policy (Adversarial F3; accept mit dokumentierter Folge)

• Quelle: schema/compiler.md §5.6 Pkt. 3 Formel 4 (Z. 163) — git ls-tree ... 862cf41 ... | git show ...; Story-2.4-Re-Baseline (Loop-2-Decision-1: Run-Kopf statt Vor-Zustand).
• Beleg: git diff --name-only 862cf41..HEAD -- wiki/ → log.md + index.md geändert, obwohl Story 2.5 keine neue Datei brachte; die Baseline-Extraktion aus dem gepinnten Commit ist gegen einen Baum-Zustand HEAD nicht byte-stabil. Der Text (Z. 166) dokumentiert, dass jeder Datei-Zuwachs eine Re-Baseline auf den dann aktuellen Run-Kopf erfordert — es gibt aber keine zitierbare Regel, welcher Commit „der dann aktuelle Run-Kopf" für einen Content-mutierenden (nicht Datei-hinzufügenden) Run wäre.
• Auswirkung: Die AD-17h-Meldung „die Baseline wird deterministisch aus dem Baseline-Commit des letzten Zuwachs-Runs dynamisch extrahiert" ist eine O(n)-über-Runs-Operation; die Kopplung an den Einstellungs-Commit ist die schwächste strukturelle Stelle der Formel-Suite (konservatives Verhalten erkannt, keine echte Determinismus-Verletzung heute).
• Disposition & Prävention: accept — dokumentierter, eingebauter Kompromiss von AD-17h (keine Standalone, keine künstliche Datei-Metadaten-Quelle); dennoch als offene Folge notieren: Re-Baseline-Policy (Definition „Zuwachs-Run", Umgang mit Content-Drift ohne Datei-Zuwachs) für Epic 3 präzisieren. Kein Action-Item (bereits in Epic-3-Nähe thematisiert), aber im Open questions-Block festgehalten.

F-07 — grep -vE ':' / case *:* schlucken kolonhaltige Ziele still (bricht Pin- und Dangling-Check) (Adversarial F6; defer)

• Quelle: schema/compiler.md §5.6 Pkt. 3 Formel 2 (Z. 146) / Formel 3 (Z. 154, case "$t" in ""|*:*|…).
• Beleg: Ein Ziel mit : (z. B. file.md#sec:2, Windows-Kopfpfad) wird von Pin- und Dangling-Check exkludiert statt geflaggt — eine normative Verletzung wird zu einer ungeprüften, stillen Null-Op. (Live: kein derartiges Ziel — nicht auf dem aktuellen Baum.)
• Disposition & Prävention: defer — dokumentiert in deferred-work.md (konservativ); Lektion: Exklusions-Klassen müssen als „nicht am Pin-Teil des Bundles" deklariert bzw. selbst überprüft werden (möglicher kleiner Dangling-Sonderfall).

F-08 — Form-Check ../-Exklusion bedeutet: ../-Ziele werden nie auf .md-Endung geprüft (Adversarial F5; defer)

• Quelle: schema/compiler.md §5.6 Pkt. 3 Formel 2 Z. 146 (grep -vE '^(raw/|\.\./|#)').
• Beleg: [x](../ohne-endung) (existierende extensionless Datei) passiert Form-Check (Ziel ist ../-exkludiert) und Dangling-Check (Datei existiert) → Pin-Verletzung (keine .md-Endung) unentdeckt.
• Disposition & Prävention: defer — bekannte konservative Lücke; Sonderfall nur für ../-Ziele. Lektion zur Formel-Schärfung für Epic 3.

F-09 — sources-id-Eindeutigkeit, Marker-Grammatik, Sources-Closure, Fragment-Existenz, Content-Truth bleiben ungeprüft — Story 2.4/2.5 fügt keine Checks hinzu (Verification-Gap Confirmation; defer — bereits Defer-Kontexte)

• Quelle: §5.5 Pkt. 3/4 (Prosa); deferred-work.md W1–W4, L197–212 (Marker-Grammatik, sources[].id-Eindeutigkeit, Sources-Closure, Fragment-Existenz, Content-Truth).
• Beleg: Weder §5.6/§5.8-Formeln noch Validator prüfen Wert-Duplikate (id), Marker-Syntax über den Token „nicht eigenständig belegt" hinaus, Inline→sources-Closure, Fragment-Existenz in raw/ oder Body↔sources-Korrespondenz. Letztere bleiben nachweislich still-passierend; das aktuelle Bundle ist nur durch Konvention gepflegt.
• Disposition & Prävention: defer — alle bereits in deferred-work.md verankert; keine neue Lücke durch 2.4/2.5. Lektion: Diese Unschärfen sind die Hauptkandidaten für eine Epic-3-mechanische Schicht (D-3-konform).

F-10 — §5.7-Routing-Prädikat (a) ist nicht re-runnable; „kanonischer Name des Themas" ist Urteilsinput ohne Ableitungsformel (Adversarial F7/F8-Variante, Edge-Case #5/#6, Verification-Gap F3/F4; accept (designiert), dokumentierter Urteils-Spielraum)

• Quelle: schema/compiler.md §5.7 Pkt. 1(a) (Z. 183) — „Identität seines Link-Ziels … gleich dem kanonischen Namen des neuen Themas".
• Beleg: Der linke Operand (kanonischer Name) wird durch keine Formel, keinen Grep, keine Tabelle abgeleitet — er ist Producer-Interpretation aus §2. Zwei Producer können für dieselbe Einheit unterschiedliche kanonische Namen ableiten und unterschiedlich routen, obwohl die Instruktion „textual-deterministisch" fordert (AD-13/A0-10). Zudem: Die Area-Variante — Bundleroot enthält inzwischen einen Area-Navigations-Link (wissensarchitektur/index.md, Identität wissensarchitektur) — ein neues Thema mit Namen wissensarchitektur trifft auf den Tie-Break „Bundleroot-Links schlagen Area-Links → Root-Ebene", der für Area-Links unzutreffend ist. Beide Stellen sind textual-deterministische Überreste: kein re-runbarer Check verhindert eine falsche Platzierung (Platzierung in falscher Area passiert Validator/Formeln/§5.8 still).
• Disposition & Prävention: accept — die Routing-Entscheidung ist die einzige neue Story-2.4-Regel ohne ausführbares Artefakt; sie ist bewusst ein Interpretationsschritt („Ask-First" Rücksprache-Pflicht vorhanden). Als offene Frage notieren: Wie mechanisch kann „kanonischer Name" in Epic 3 werden (grep/ripgrep über index.md-Baum), ohne ein neues Urteils-Element einzuführen?

F-11 — Aggregat: schema/compiler.md ist der unangefochtene God-File des Epic (84 KB, 317 Z., +404/−87); Struktur-Drift im Diff (Aggregat-Blickwinkel; accept mit Epic-3-Schritt)

• Quelle: git log --numstat a67ba65..f41ac71 -- schema/compiler.md (11 nicht-Merge-Commits), wc -l schema/compiler.md (317 Z., 84 KB); grep -n '^##' → 18 Sektionen, davon §5.x-Instruktionen 5.5/5.6/5.7/5.8.
• Beleg: Das Lieferprodukt ist eine einzelne Instruktionsdatei, in der jede Story eine neue Sektion „anklebte" (§5.5 → §5.6 → §5.7 → §5.8); die Sektionen referenzieren sich gegenseitig zirkulär (z. B. §5.8 ↔ §5.6 ↔ §5.7), was die F-01/F-04/F-05-Fehlschläge begünstigt. Kein Duplikat-Problem (keine parallelen Erzeugungsinstruktionen), aber wachsende kognitive Last und zunehmende Formel-Zahl (4+1 im Diff).
• Disposition & Prävention: accept — als Dokumentations-God-File vertretbar (agent-reader, keine Code-God-Klasse); als Handlungsempfehlung für Epic 3: Struktur-Aufteilung oder Querverweis-Register erwägen, um die Fehlschlagschneisen zwischen §5.5–§5.8 zu senken. Kein Auto-Fix (siehe Open questions).

F-12 — Validator-File als Lieferumfang: das validator.md-Delta im Diff ist die Rev-8-Autorisationsrunde (Ende Epic 1), kein Epic-2-Change (Aggregat-Klarstellung; accept, Registrierung)

• Quelle: git diff a67ba65..f41ac71 -- schema/validator.md (Revisionszahl 6→8, Punkt-4 Fixture 4a, §7.3-Isolations-Notiz) vs. wiki/log.md (Rev-8-Autorisationsrunde, 2026-08-16).
• Beleg: Epic 2 selbst (Story 2.1–2.5) änderte schema/validator.md nicht (AD-3-Doktrin); das Delta stammt aus der autorisierten Rev-8-Runde zur Story-2.1-Freigabe — semantisch Epic-1-Abschluss, wird per Diff-Range-Eckung in Epic 2 mitgezählt.
• Disposition: accept — Klarstellung zur Wahrnehmung des Diffs; kein Defekt.

Behavior verification (re-executierbare Selbsttest-Formeln gegen Live-Baum)

Die „Laufzeit" dieses Epics sind die eingebetteten Shell-Formeln (D-3, AD-17h). Alle wurden am 2026-08-18 gegen den Live-Baum im Workspace re-exekutiert:

Check	Erwartung	Beobachtung (Live)
§5.6 Formel 1 (Bestands-Check)	Übersicht aller ](-Links, Exit 0	14 Ziele; Exit 0
§5.6 Formel 2 (Form-Check)	0, Exit 0	0, Exit 0
§5.6 Formel 3 (Dangling-Check)	keine Ausgabe	keine Ausgabe, Exit 0
§5.6 Formel 4 (Kontakt-mit-raw/) — Ist	38	38
§5.6 Formel 4 (Extraktion aus Run-Kopf 862cf41)	38	38 (38 ≡ 38)
§5.8 Selbsttest (exakt Z. 216, beide Läufe)	keine Ausgabe, Exit 0	keine Ausgabe, Exit 0
§5.8 CWD-Präguard (außerhalb Workspace-Root)	SELBSTTEST-SETUP-Fehler… + Exit 1	exakt so, Exit 1

Quell-Konsistenz: Die Nachweise in wiki/log.md (Story 2.4/2.5-Einträge) decken sich mit diesen Re-Runs: Formel 2 0, Formel 3 leer, Formel 4 38 ≡ 38, §5.8 leer+Exit 0, Präguard-Sandbox-Nachweis (SELBSTTEST-SETUP-Fehler…+Exit 1) — alle verifiziert.

Abweichung / Lücke: Der in log.md behauptete „alle 7 wiki/-Dateien SUCCESS (inkl. Punkt 11, EC-1)" ist bei Rev-8-wörtlicher Punkt-11-Lesart der file-relative Area-Link nicht mechanisch reproduzierbar (vgl. F-02): das Bundle-Verdikt ist über die aufgelockerte Lesart konsistent, der wörtliche Check nicht. Es bleibt ein Rev-9-Aktionsitem.

Bewusst nicht erneut exerziert: Die Validator-Festhalte-Fixtures (§7.1–§7.3), die Rev-8-Zertifizierung und die Sandbox-Negativtests (TOP_LEVEL_COLLISION, AREA_WITHOUT_INDEX, DANGLING-Fälle) sind in validator.md/log.md ausführlich belegt und in früheren Runden re-zertifiziert; sie wurden hier stichprobenartig (F-02/F-03) bestätigt, nicht vollständig wiederholt.

Action items (fix-now-Routing aus den Findings)

Die folgenden F-Items sind fix-now geroutet und werden als Action-Items zur Ausführung im normalen Dev-Loop vorgeschlagen (Retrospective schlägt vor, wendet nicht selbst an — das entscheidet der Nutzer):

• AI-2-R-1 (§5.5-Provenienz-Selbsttest rekursiv machen) — schema/compiler.md §5.5 Pkt. 1/4 (Z. 81/104): Formel auf rekursive Abdeckung umstellen (grep -rnE '\(raw/' wiki/ --include='*.md' --exclude=log.md), sodass Area-Concepts erfasst werden. Quelle: F-01. Owner: dev.
• AI-2-R-2 (§5.8/Area-ohne-index.md-Lücke schließen) — §5.8 Pkt. 2 Lauf A (Z. 216): Area-Concept-ohne-index.md-Fälle (Tiefe 2, wiki/<a>/concept.md ohne wiki/a/index.md) in den Selbsttest aufnehmen. Quelle: F-03. Owner: dev.
• AI-2-R-3 (Formel-4-Filterasymmetrie heilen) — §5.6 Pkt. 3 Formel 4 (Z. 162–163): --exclude=log.md und grep -v "log.md$" auf dieselbe Exklusions-Semantik bringen (genau-Basename log.md auf beiden Seiten bzw. rekursiv-Basename in beiden). Quelle: F-04. Owner: dev.
• AI-2-R-4 (§5.8-Reachability als echte Markdown-Links prüfen + ./-Konsistenz mit §5.6) — §5.8 Pkt. 2 Lauf A (Z. 216): grep -qF gegen Code-Fence/Blockquote-sichere Link-Detektion; ./-Variante mit dem §5.6-Form-Check vereinheitlichen (genau eine erlaubte Form). Quelle: F-05. Owner: dev.
• AI-2-R-5 (autorisierte Validator-Rev-9 für Punkt 11 Area-Lesart) — formalisierte Punkt-11-Area-Lesart (relative OKF-Pfad-Identität, file-relativ in Area-Index) in einer autorisierten Revision; de-dupliziert mit dem bestehenden Action-Item code-review-2-1-item-2 (Rev-9-Vorbereitung). Quelle: F-02. Owner: dev.

Die übrigen F-Items sind defer (F-07, F-08, F-09 — bekannte, in deferred-work.md verankerte Lücken) bzw. accept (F-06, F-10, F-11, F-12 — dokumentierte Design-Entscheidungen bzw. Klarstellungen). Für die accept/defer-Items gilt: sie werden in den Open questions-Block übernommen, damit spätere Retros sie nicht erneut als neu flaggen.

Acceptance verdict

• Kriterien: declar deklariert in _bmad-output/planning-artifacts/epics.md (Epic-2-Block + Stories 2.1–2.5, je AC-Zeilen).
• Story-Status: alle Stories des Epic (2.1–2.5) sind done; detect-epic --epic 2 liefert keine pending_stories (sprint-status.yaml) → kein Machine-Zwang zu rejected.
• Kriterien-Erfüllung (Beleg): Die AC-Zeilen je Story sind erfüllt und belegt — Story 2.1/2.2 (OKF-Konformität, v1-Trust, claim-granulare Provenienz) durch die 2026-08-17-Re-Reviews und Rev-8-Autorisationsrunde; Story 2.3 (eine erlaubte Linkform) durch §5.6 + Formeln 1–3; Story 2.4 (deterministische Bereichszuordnung) durch §5.7 + Tie-Break + Kollisions-Hold; Story 2.5 (Progressive Discovery) durch §5.8 + Selbsttest. Verhaltenscheck (Abschnitt oben): alle re-executierbaren Formeln grün.
• Offene, getrackte Findings: F-01–F-05 sind empirisch belegte Blindstellen/Konsistenzgrafien in den Selbsttest-Formeln (insbesondere F-01: §5.5-Formel übersieht Area-Concepts; F-02: Punkt-11-Wortlaut vs. file-relative Area-Linkform). Sie sind nicht Blockierend für die Story-ACs (kein Live-Fail, kein Kriterien-Unterschreiten), wohl aber für den AD-17h-„re-executierbar & vollständig"-Anspruch der Instruktion.
• Verdikt: accepted-with-open-items — die deklarierten Abnahmekriterien sind erfüllt und durch re-executierbare Nachweise belegt; benannte Findings (F-01–F-05) bleiben als offene, getrackte Items (Action-Items AI-2-R-1…5) bestehen. Gemäß acceptance-verdict.md fällt das maschinelle Verdikt bei leerer pending_stories, erfüllten Kriterien und getrackten, nicht-blockierenden Findings selbst auf accepted-with-open-items — keine Zurückweisung. Die Findings sind zudem empirisch belegt (F-01: §5.5-Formel übersieht Area-Concepts; F-02: Punkt-11-Wortlaut vs. file-relative Area-Linkform; F-03–F-05: Sandbox-Replikationen) und werden als explizite, getrackte Folge-Items in den Dev-Loop übertragen.

Open questions

1. F-06 — Formel-4-Re-Baseline-Policy: Wie definiert Epic 3 einen „Zuwachs-Run" (Datei-Zuwachs vs. Content-Drift ohne Datei-Zuwachs) und welcher Commit wird „der dann aktuelle Run-Kopf" für die Baseline-Extraktion? (kurze Antwort in schema/compiler.md §5.6 Pkt. 3 Z. 166 ist vorhanden, aber ohne zitierbare Regel.)
2. F-10 — „kanonischer Name" mechanisieren: Kann Epic 3 den §5.7-Pkt.-1(a)-Operanden (kanonischer Name des Themas) aus dem index.md-Baum ableiten (grep/ripgrep, ID-Normalisierung), ohne ein neues Urteils-Element einzuführen?
3. F-02/Rev-9 — Punkt-11-Lesart: Welche exakte Formulierung trägt die file-relative Area-Lesart am besten („relative OKF-Pfad-Identität, auch in Area-Index") und bleibt dabei vertrags-/validator-konform?
4. F-11 — Struktur: Soll schema/compiler.md in Epic 3 aufgeteilt oder mit einem Querverweis-Register versehen werden, um die §5.5–§5.8-Fehlschlagschneisen zu senken? (Empfehlung: aufgeteilt oder Register, kein Auto-Fix.)

Previous-retro follow-through

Das vorige Retrospective ist epic-1-retro-2026-08-15.md (Epic 1). Aus sprint-status.yaml wurden die Epic-1-Action-Items geprüft:

• epic-1-retro-item-1 … -7 — alle done (geschlossen 2026-08-16, je mit Resolution; an die Validator-Revisionen 3–6 + F-04/F-09/Defer-Sicherung gekoppelt). Belegt über sprint-status.yaml (action_items, status: done, closed + resolution) — kein offener Epic-1-Posten übrig.
• Von Epic 2 bisherige Action-Items:
  • code-review-2-1-item-1-autorisierte-validator-revision-option — done (Rev-8-Autorisationsrunde ausgeführt und zertifiziert, s. wiki/log.md 2026-08-16/17). Beleg: validator.md Rev 8 + log-Eintrag.
  • code-review-2-1-item-2 (Epic 2, Rev-9-Vorbereitung: Punkt-4-Grammatik resolved=-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile) — offen / nicht erledigt (kein Beleg für Abschluss). Dieser Posten bleibt im Follow-through aufgeführt, da er in dieser Retro als AI-2-R-5 (Rev-9) wiederbelebt bzw. aufgegriffen wird; die beiden anderen Teilschritte (Punkt-4-Grammatik + Innen-Ebenen-Punkt-6-Fixture) sind Teil der defer-F-09-Übernahme (unabhängig vom Rev-9-Ziel). Der vorgeschlagene Status ist in-progress (laufender Dev-Loop) bzw. bei Nutzer-Autorisierung done für den abgeschlossenen Teil.

Hinweis gemäß acceptance-verdict.md L29: ein fehlender Datei-Beleg ist nie als „keine offenen Posten" zu lesen. Da Epic 1 keine action_items-Einträge über die Epic-1-Id-Form hinaus trägt (aus der Version vor dem Retro-I-Format) und die Epic-2-Einträge mit Ids existieren, ist die Auswahl über die expliziten Ids oben geprüft (keine Legacy-Einträge ohne Id mitgematcht).

Assumptions

Nicht zutreffend (interaktive Ausführung): Für diesen interaktiven Retro-Lauf wurden keine Entscheidungen ohne den Nutzer getroffen — die Auswahl des Epic (Epic 2) erfolgte durch den Aufruf /bmad-retrospective Epic 2; die Einschätzung der Story-Kriterien und die resultierenden Action-Items werden dem Nutzer als Vorschläge vorgelegt (Phase 4/5).