wow20/_bmad-output/implementation-artifacts/epic-3-retro-2026-08-24.md

epic, date, verdict, criteria, headless

epic	date	verdict	criteria	headless
3	2026-08-24	accepted-with-open-items	declared	false

Retrospective Epic 3 — Inkrementelle Kompilation & Synthese

Epic summary

• Epic: 3 — Inkrementelle Kompilation & Synthese
• Diff-Range: efc543c^..3f57586 (erster Story-Commit efc543c (Story 3.1), letzter 3f57586 (3.13 done-Flip); 44 Commits, 1 Merge 5a78271 (gemessen, erst-parent-diff))
• Commits/Churn (nicht-Merge): 43 nicht-Merge-Commits; Top-Dateien: sandbox-3-13/run-sandbox.sh (+1716/−711, 11 Commits), schema/compiler.md (+318/−87, 21 Commits), deferred-work.md (+386/−14, 23), spec-3-13 (+265/−27), sprint-status.yaml (28 Commits), wiki/log.md (+49/−4)
• Stories: 3.1–3.13 alle done; pending_stories leer (detect-epic --epic 3, 2026-08-24) → kein Machine-Zwang zu rejected. epic-3-retrospective: optional → Phase 5 auf done.
• Abnahmekriterien: deklariert in _bmad-output/planning-artifacts/epics.md (Epic-3-Block Z. 259–451 + je Story-AC-Zeilen) → Verdikt-Basis declared.
• Evidence-Inventar:
  • Epic-Spec: planning-artifacts/epics.md (Epic-3-Block, ACs je Story deklariert)
  • Story-Specs 3.1–3.13 unter _bmad-output/implementation-artifacts/spec-3-*.md (13 Dateien)
  • epic-3-context.md (kontextuell kompiliert, mit Ist-Zustand je AD)
  • schema/compiler.md (548 Z. nach Epic 3; +318/−87 net über 21 Commits) — das Hauptlieferprodukt
  • schema/canonical-terms.md (+40/−1, Story 3.2)
  • Sandbox-Suiten: sandbox-3-1 … sandbox-3-13 (je run-sandbox.sh; 3-13 gehärtet 1005 Z.)
  • deferred-work.md (673 Z.; +386/−14, 23 Commits — append-only Register)
  • sprint-status.yaml (28 Commits im Range)
  • wiki/log.md (78 Z. nach Epic 3; +49/−4)
  • Voriges Retro: epic-2-retro-2026-08-18.md (verdict accepted-with-open-items, Action-Items AI-2-R-1…5)
  • sprint-change-proposal-2026-08-20.md (genehmigte Story-3.8-Re-Öffnung)
  • Merge-Eckung: merge_files für 5a78271 (Story 3.8-PR-Merge) enthält teils Epic-2-Restchurn (z. B. epic-2-retro, spec-2-5, validator.md Rev-9) — wird im Aggregat NICHT zu files addiert, nur als Kontext notiert.
• Fehlend: Session-Logs (nicht in dieser Umgebung verfügbar) → Prozess-Lektionen nur aus git-loggablem Verhalten; project-context.md existiert nicht (persistent fact file:**/project-context.md leer).
• Prozess-Hinweis (für Phase 2): Story 3.13 durchlief ≥ 6 dokumentierte Re-Runs (Erst-Lauf 2026-08-22 grün → Härtung Review-Loop-1 → Re-Runs #2–#5, #5 rot an E.4 = echter AD-16-Befund → Rev-3.8-Epic-1-Remediation → Re-Runs #6–#10, #10 grün) und 2 Review-Loops (38 rohe Findings im Loop-2). Commit-Log zeigt die Kette vollständig.

Findings

Jeder Befund trägt eine Quellen-Referenz (Datei:Zeile / Commit / Log). Befunde ohne belegbare Quelle wurden verworfen.

F-1 — Sandbox-Helfer-Duplikation ist by design, aber das semantische Primitive norm() ist zwischen 4 Suiten bereits in zwei Strukturanvarianten divergiert

Quellen: sandbox-3-{8,9,10,11}/run-sandbox.sh (norm()-Definitionen); deferred-work.md L552 (D-7), L559 (W-3.9-1), L572–573 (3.10-Kopie).

Was kein einzelner Diff zeigt (Aggregate-View): Die Suite-Helfer-Duplikation selbst ist gewollt — jede Sandbox ist selbstenthalten und in einem frischen /tmp-Bundle re-exekutierbar (12/12 Suites liefen unabhängig grün, s. Behavior). Die Duplikation ist also kein God-Class-Defekt. Aber beim einen Helfer, der eine normative Semantik trägt — norm() = die §3.2/§5.14-Kanon-Form, auf die AD-13/AD-17h (textueller Determinismus) aufbauen — hat sich über die 4 Suiten, die ihn definieren (3-8, 3-9, 3-10, 3-11), eine strukturelle Divergenz entwickelt:

• 3-8, 3-9, 3-10 (3 identische Kollaps-Formen): sed-Kollaps [-–—_ ]→- plus Case-Folding (tr 'A-Z' 'a-z' bzw. tolower).
• 3-11 (divergent): sed-Kollaps [–—]→-, _→␣, ␣→- ohne jeden Case-Folding-Schritt.

Die Divergenz ist im Moment maschiert: 3-11s einziger Aufruf (Z. 382) liegt neben redundanten Schwesterglobs (*run-a5*, *a5*), die den fehlenden Fall-Abgleich überdecken. Sie ist aber eine Latenz, kein Zufallsartefakt — und sie trifft genau das Primitive, das Epic 3 als deterministisch verkauft.

Relation zu bekanntem Deferral: deferred-work.md L552/559/572 dokumentiert bereits, dass norm() keine LC_ALL-Pinning trägt (D-7, Home: Sandbox-Härtung). Das Retro erweitert diesen Befund: (a) 3-11 ist zusätzlich die einzige Suite mit LC_ALL=0 (kein Locale-Pin überhaupt), und (b) die Kopien haben sich bereits divergiert — eine künftige Vereinheitlichung muss daher erst 4 driftete Implementierungen reconcilieren, nicht nur einen Pin ergänzen. Stufe: Latenz/Robustheit (keine gegenwärtige Fehlfunktion, alle Suites grün), aber normativ relevant für AD-13.

F-2 — compiler.md ist das einzige Hauptlieferprodukt und wuchs zu einer 548-Zeilen-/15-Sektionen-Datei (God-File-Risiko, aber strukturell sauber)

Quellen: schema/compiler.md (wc -l = 548; grep -nE '^## 5\.'); git-churn +318/−87 über 21 Commits (s. Epic summary).

Was kein einzelner Diff zeigt: Epic 3 legte ## 5.9–## 5.18 an (Z. 257–440 ≈ 183 neue Zeilen) — die Sektionen-Blase von §5 wuchs von 5 auf 15. Die Datei ist das einzige normative Hauptartefakt des ganzen Projekts; jede Epic-3-Story mutiert denselben Datei-Block, was den §5-Bereich zum natürlichen Konfliktherd macht (tatsächlich: 21 Commits an einer Datei, der churn-höchste Wert des Epics nach der Sandbox). Aber die Struktur ist sauber: lineare Nummerierung, je Sektion ein Story-Verweis, kein Code-Verschnitt. Das Risiko ist Wartbarkeit/Review-Fläche, nicht inkohärenter Zustand — die Sandbox-Suiten und der §6-Validator decken die Semantik mechanisch ab. Stufe: Beobachtung (Wachstums-Trend), kein Defekt.

F-3 — §5-Sektions-Nummerierung ist nicht zusammenhängend (Kosmetik, aber verwirrend)

Quellen: schema/compiler.md grep -nE '^## 5\.' — vorhanden: 5.5, 5.6, 5.7, 5.8, 5.9, 5.10, 5.11 … 5.18.

Befund: ## 5.1–## 5.4 existieren nicht (der Block beginnt bei 5.5), und die Nummerierung folgt Story-Nummern, nicht logischer Reihenfolge: 5.10 = Story 3.4, 5.11 = Story 3.5, 5.17 = Story 3.11. Das ist konsistent innerhalb der Story-Mapping-Konvention, aber ein Leser, der nach „§5.10 = zehnter Unterabschnitt" sucht, wird irregeleitet. Stufe: Kosmetik/Lesbarkeit; kein semantischer Defekt. (Kein fix-now; optional für eine spätere Instruktions-Revision.)

F-4 — Verhalten: A==B-Determinismus-Assertion wird nicht-vakuum ausgeübt (positiver Befund, bestätigt AD-17h)

Quellen: sandbox-3-10/run-sandbox.sh E-9 (Re-Exekution dieser Retro, Exit 0): „Zwei-Run-Identitaet (gleicher Eingang -> identische Bytes); at-Wanduhr-Gap-Exzeption real ausgeuebt (nur generated.at differiert); Nicht-Vakuum bei Zustandswechsel", PASS=9 FAIL=0.

Befund (Bestätigung, kein Defekt): Die Determinismus-Vertrags-Assertion, auf der Story 3.8/AD-17h stehen, ist in der Sandbox real und nicht tautologisch — sie erzwingt echte Byte-Äquivalenz (nur das erlaubte generated.at-Feld differiert) und übt den Zustandswechsel-Nicht-Vakuum-Fall aus. Das ist die einzige Stelle im Epic, an der die „A==B" -Kernaussage mechanisch verifiziert wird, und sie hält. Dies schützt das Epic gegen die häufigste Falsch-Grün-Mode bei Determinismus-ACs (leere/triviale A==B). Abgrenzung zu F-10: F-4 bestätigt die mechanische Assertion (Sandbox, deterministisch); F-10 zeigt, dass die frische-LLM-Ausführung derselben A==B-Prämisse über reale Agent-Kontexte empirisch nicht robust ist (Lauf A no-op). Beide gelten gleichzeitig — der Kern-Mechanismus ist grün, die Ausführung ist es nicht.

Befunde aus der Diff-scope-Review (bmad-review über efc543c^..3f57586)

Methode/Abgrenzung: Adversarial- und Verification-Gap-Linsen lieferten 22 bzw. 2 rohe Befunde; Edge-Case-Hunter stallte ohne Output (600s-Watchdog) — die Coverage-Lücke wird hier notiert, nicht aufgefüllt. Jeder Befund unten wurde in dieser Retro unabhängig gegen die Quelle verifiziert (Zeilengleichung, nicht nur Agent-Wiedergabe). Konsolidierung: VG#1 = Adversarial#1 (gleicher Befund, zwei Linsen); VG#2 ist eigenständig. Die übrigen Adversarial-Befunde (Leasing-Cluster, CREATE-Coverage, Em-Dash) sind eigenständig. Reihenfolge nach Materialität für die Determinismus-/Sicherheits-Ansprüche des Epics.

F-5 — MIDNIGHT-Dateigruppen-Bruch: der Kern-Determinismus-AC ist am Tagesgrenze nicht erfüllbar (Spec-Selbstwiderspruch + unbelegte Verifikation) [HÖCHSTE MATERIALITÄT]

Quellen (alle in dieser Retro verifiziert): schema/compiler.md:277 (§5.9 Pkt. 4) + :375 (§5.14 Pkt. 3) + :548; sandbox-3-13/run-sandbox.sh:650-653 (classify_diff) + :819-828 (E.9); schema/validator.md:135-137 (F17).

Befund: Der §5.14-Zwei-Run-Vertrag ist der Kern-AC des Epics (AD-17h, FT-10, AC-1/AC-6). Er erlaubt in §5.14 Pkt. 3 genau eine benannte Differenz — den generated.at-Wanduhr-Gap — und erklärt die Ausnahme "ausschließlich auf den at-Feld-Wert" bezogen, "alle übrigen Bestandteile … byte-identisch". Aber §5.9 Pkt. 4 (Z. 277) verlangt den log.md-Eintrag in kanonischer Form mit einer ## YYYY-MM-DD-Datumsgruppen-Header (neueste zuerst) — und behauptet gleichzeitig, der Eintrag trage "keinen Wanduhr-Wert … der Wanduhr-Wert lebt ausschließlich im Frontmatter-generated.at, nie im log.md-Body". Die ## YYYY-MM-DD-Header ist aber ein Wanduhr-Datum im Body — weder generated.at noch an einen Git-Wert gebunden (es existiert nirgends eine git show --format=%cs/%cd-Bindung für die Header, verifiziert). Damit ist die Ausnahme-Menge "genau eine" vom §5.9-Wortlaut selbst widersprochen, und classify_diff (Z. 650-653) maskiert nur die at: -Frontmatter-Zeilen — eine +/--Änderung der ## YYYY-MM-DD-Header zählt als NON_AT → spurious HARD-FAIL für einen konformen Lauf, der die Mitternacht-/Timezone-Grenze zwischen Run A und Run B überschreitet. E.9 (Z. 819-828) prüft nur "Lauf-Eintrag vorhanden + trägt Baseline $BASE" — nirgends wird beansprucht, dass beide Läufe in die gleiche Datumsgruppe fallen. Validator-F17 validiert die Datumsgruppe explizit nicht (v1). Heute grün nur, weil beide Agent-Läufe in derselben Session am selben Tag laufen (Re-Run #10, 2026-08-24). Bereits im ausgelieferten Artefakt vorhanden (nicht nur latenz): wiki/log.md trägt 10 ## YYYY-MM-DD-Wallclock-Header (2026-08-24 … 2026-08-15, in dieser Retro gezählt) — der §5.9-Pkt.-4-Header ist also in der realen Auslieferung geübt; zwei gleich-tägige Läufe sind byte-identisch (Gate grün), aber der Kern-Anspruch "genau eine Ausnahme" ist vom §5.9-Wortlaut selbst widersprochen. Cross-Suite-Beweis der Inkonsistenz (VG-Linsenzusatz): die Suite umgeht den Gap inkonsistent — 3-10 (Z. 303/605) nutzt reale $(date +%Y-%m-%d) (die einzige Suite, die die Wanduhr-Abhängigkeit real ausübt), während 3-1/3-5/3-6/3-8/3-9/3-12 fixe Tage hartkodieren und 3-9 R-8 die Header weglässt. Kein Test übt jemals einen echten Header-Unterschied zwischen zwei Läufen aus. Stufe: Defekt (Kern-AC nicht am Tagesgrenze erfüllbar; Spec-Selbstwiderspruch). Fix-Optionen (Vorschlag, nicht auto-applied): (a) die ## -Header-Zeile in classify_diff als benannte Ausnahme wie at-Zeilen klassifizieren, oder (b) die Header auf einen Git-Wert pinnen (git show -s --format=%cs $BASE), sodass "identische Datumsgruppe" (§5.9/§5.14) verifizierbar statt ungetestet ist; und §5.9-Z.277-Wortlaut ("keinen Wanduhr-Wert … nie im Body") mit der Header-Realität in Einklang bringen.

F-6 — Unreconciliertes Leasing-Cluster: drei Lock-Modelle koexistieren; §5.18 invertiert §5.12s Gen-only-Stale-Regel ohne Supersession-Notiz

Quellen (verifiziert): schema/compiler.md:327 (§5.12 Pkt. 1), :419 (§5.17 Pkt. 1), :428/:430 (§5.18 Pkt. 0/Pkt. 1), :419-424 (§5.17 Pkt. 2).

Befund: Drei Lock-Modelle stehen nebeneinander, ohne dass ein sie eindeutig ersetzt: §5.11 (worktree-lokales Lockfile, nicht-atomares check-then-act, TOCTOU), §5.17 (atomare create-only-Root-Scope-Ref git update-ref <lock-ref> <wert> $ZERO_SHA), §5.18 (Lifecycle/Übernahme). §5.17 (Z. 417/419) demotiert das §5.11-Lockfile explizit ("trägt aber keine Exklusivität mehr allein … TOCTOU-Race … geschlossen"). Aber §5.12 Pkt. 1 (Z. 327) definiert Staleness allein generationen-basiert ("Gen kleiner = älter … gilt als stale … blockiert keinen nachfolgenden Run"), während §5.18 Pkt. 1 (Z. 430) dies invertiert: eine lebende Lease ist "durch eine höhere sichtbare Generation allein nicht stale … nie allein aus der Gen-Registry (§5.12), sondern aus bestätigtem Abbruch oder abgelaufener Liveness". §5.18 (Z. 428) beansprucht zugleich "Fugen-Identität: §5.12 (Pkt. 1–7) … bleiben textuell unverändert" — die behaviorale Supersession hat also keine Supersession-Notiz, und §5.12s "TTL-Ablauf-Äquivalent"-Wortlaut bleibt wörtlich intakt (leserisch widersprüchlich). Zusätzlich: der Area-Scope-Pfad behält das nicht-atomare §5.11-TOCTOU-Modell (nur der Root-Scope bekommt §5.17). Stufe: Defekt (inkohärentes Sicherheitsmodell; zwei widersprüchliche Staleness-Regeln ohne Supersession). Fix-Option: §5.12 Pkt. 1 um eine Supersession-Notiz zu §5.18 ergänzen (bzw. §5.18 als normative Staleness-Autorität kennzeichnen) + die Root-vs.-Area-Asymmetrie explizit machen.

F-7 — Leasing wird von keinem realen Agent-Lauf ausgeübt: das Gate (3-13) hat null Leasing-Verifikation (missing-adoption)

Quellen (verifiziert): sandbox-3-13/run-sandbox.sh — grep -cE 'update-ref|refs/leases|scopelock|\.lock|lease/|root-scope' = 0 (in dieser Retro ausgeführt); AGENT_PROMPT (Z. 567-582) verlangt nur wiki/-Mutationen + 4-Feld-Receipt, kein Lease-Lock-Wert, keinen Shared-Ref-Namespace-Check; sandbox-3-11 (eigene scopelock_acquire-Helfer, Z. 124-129), sandbox-3-12 (scopelock_-Helfer, L-2 CAS Z. 367-434), sandbox-3-5 (check-then-act acquire() Z. 206 — verifiziert das demotierte Modell).

Befund: Die §5.17-atomare Root-Scope-Akquise ist der eigentliche Sicherheitsgewinn des Leasing-Clusters (schließt das TOCTOU-Race). Sie wird aber nur von Sandbox-internen Bash-Helfern (3-11/3-12) bewiesen — kein realer Agent-Kontext führt sie aus. Das Abnahmegate 3-13, das die realen Agent-Läufe (E.1-E.9) enthält, referenziert nirgends update-ref/refs/leases/scopelock/.lock (0 Treffer) — seine Agent-Läufe mutieren ausschließlich wiki/. Fehlt also in der realen Ausführung der §5.17-Pfad, schweift das supersedierte check-then-act-TOCTOU-Modell (§5.11) zurück, ohne dass ein roter Test es auffängt: 3-11 A-2 beweist nur die Atomarität des Git-Ref-Primitivs in seinem eigenen Bash-Helfer, nicht, dass der Agent den §5.17-Pfad annimmt statt des §5.11-Lockfiles. Stufe: Defekt (Sicherheits-Invariante "genau ein aktiver Root-Scope-Holder" unverified im realen Execution-Pfad). Fix-Option: ein Gate-Szenario (analog E.9, mit Known-Value-Witness), das in wt-a verifiziert, dass refs/leases/wiki existiert und git rev-parse 'refs/leases/wiki^{}' == git hash-object des Run-IDs ist — d. h. der reale Agent hat die scope-bezogene Ref mit Run-ID-Inhalt im geteilten Ref-Namespace gesetzt.

F-8 — Gate-Coverage-Gap: der reale Agent-A/B übt nur den UPDATE-Kern; CREATE/Synthese delegiert an agent-less Sub-Runs

Quellen (verifiziert): sandbox-3-13/run-sandbox.sh:23,56-59,477-480 (D-3.13-6 Option 2, Re-Run #5-Befund).

Befund: Die einzige reale Agent-A/B (E.1-E.9, AC-6/AC-7) übt den UPDATE-/Erhaltungs-Kern (Zuwachs raw/alpha-v2.md = bestätigender UPDATE). Der CREATE-/Synthese-Kern ist bewusst nicht in der A/B-Fixture — aus gutem dokumentierten Grund (Z. 57: "CREATE-Fall 24/26 der NON_AT-Abweichungen treibend", Re-Run #5). CREATE/Synthese gelten stattdessen über die agent-less Sub-Runs 3-3/3-4. Das ist eine bewusste Scope-Entscheidung (D-3.13-6 Option 2), kein Still-Vorbeilass — aber es bedeutet, dass die CREATE-/Synthese-Determinismus-ACs (genau der Fall, der historisch die meisten NON_AT-Abweichungen trieb) nur mechanisch, nie von einem realen Agent verifiziert werden. Kombiniert mit F-5 (Dateigruppen-Bruch) und F-7 (kein realer Leasing-Lauf) ergibt sich ein Muster: die real-Agent-Abdeckung ist schmaler, als es die AD-17h-"zwei unabhängige Runs"-Kernclaim des Epics nahelegt. Stufe: Befund/Scope-Decision (dokumentiert, aber material für die Akzeptanz — die Determinismus-ACs hängen teils an mechanischen Surrogaten). Kein Fix-now; in das Verdict als offene Coverage-Frage einzureichen (s. Open questions).

F-9 — Em-Dash-Kollaps-Klasse: Cross-File-Divergenz zwischen canonical-terms.md (ohne Em-Dash) und compiler.md (mit Em-Dash); append-only-Registry kann sich nicht selbst heilen

Quellen (verifiziert): schema/canonical-terms.md:18,21 (Kollaps-Klasse [-–_ ] — ohne Em-Dash) vs. schema/compiler.md:51,54a ([-–— _] — mit Em-Dash; "die Kollaps-Klasse ist um den Em-Dash — ergänzt", Story 3.8).

Befund: canonical-terms.md ist die committete, append-only Registry des Schreibweisen-Resolvers (§3.2) und dokumentiert den Binde-Varianten-Kollaps als [-–_ ] (En-Dash, Bindestrich, Unterstrich, Leerzeichen — kein Em-Dash). Die Instruktion, auf die es sich normativ stützt (compiler.md §3.2 Pkt. 1b / §5.14 Pkt. 5, Story 3.8), erweitert die Kollaps-Klasse um den Em-Dash — ([-–— _]) und erklärt die Alt-Fassung für superseded. Weil canonical-terms.md append-only ist (bestehende Einträge "nie editiert") und die Leer-Registry-Format-Zeile (Z. 18/21) die ältere, Em-Dash-freie Klasse trägt, dokumentiert die Registry eine schmalere Kollaps-Klasse als die Instruktion — und kann sich (append-only-Regel) nicht selbst korrigieren. Ein Term mit Em-Dash (wissen — relevanz) wird von der Instruktion zur selben canonischen Form normalisiert wie seine En-Dash-Variante, aber die Registry-Dokumentation zeigt nicht, dass das so ist. Stufe: Defekt (normative Cross-File-Inkonsistenz; deterministisch, aber inkonsistent dokumentiert). Fix-Option: canonical-terms.md-Formatzeile um den Em-Dash ergänzen (append-only-konform als neue Format-Zeile / Korrekturnotiz) — erfordert eine autorisierte Instruktions-/Registry-Runde (kein stiller Edit, AD-3/D-3).

F-10 — Live-Re-Exekution des Abnahmegates ist ROT am Kern-AC: ein frischer LLM-Agent no-op-ppte (silent non-execution); der Fail-Closed-Mechanismus hat die Divergenz korrekt erfasst [NEU, empirisch]

Quellen (in dieser Retro ausgeführt/verifiziert): Live-Gate-Log /tmp/epic3-gate-rerun-1787575069.log — Z. 1234 ($BASE=6150f943…), Z. 1242 (HEAD-A=6150f943… = identisch zu $BASE), Z. 1240 („(a) keine Mutationen staged — kein Commit nötig" = nur bei wt-a), Z. 1248 (A/B-Classifier: NON_AT=6 AT=2), Z. 1249 (HARD-FAIL (E.4)); GATE_EXIT=1 (Task-Output). Committed Gegenbeleg: /tmp/gate-313-run10.log Z. 1230 (NON_AT=0 AT=2), Z. 1275 (FAILED=0 PASS_COUNT=51), Z. 1277 (SANDBOX-3-13-OK).

Befund: Die unabhängige Live-Re-Exekution des Abnahmegates 3-13 (zwei frische Agent-Kontexte A/B via claude.exe -p --bare; CLAUDE_BIN korrekt auf die echte claude.exe v2.1.198, nicht der winpty-Shim — s. Log-Z. 5) ist ROT an E.4 (dem Kern-Determinismus-AC) — dem Kern-Determinismus-AC (AD-17h/FT-10, §5.14): NON_AT=6 AT=2, HARD-FAIL, GATE_EXIT=1. Die Ursache ist weder F-5 (kein Midnight-/Datumsgruppen-Bruch: beide Läufe am selben Tag 2026-08-24, keine Tagesgrenze) noch F-8 (kein CREATE-/Synthese-Subpfad — es ist der UPDATE-Kern). Die Ursache ist ein frischer-LLM-Non-Execution-Fehlschlag: Lauf A hat gar keine Mutation ausgeführt (HEAD-A == $BASE, „keine Mutationen staged") und trotzdem RUN_DONE a emittiert, während Lauf B den vollen UPDATE ausführte (sources-Zeile raw/alpha-v2.md, Body-Änderung, log.md ## 2026-08-24-Eintrag mit Baseline $BASE). Alle 6 NON_AT-Zeilen liegen einseitig auf B — es ist keine A-gegen-B-Inhaltsdivergenz, sondern A=leer vs. B=voll. Entscheidend: A und B liefen in derselben Umgebung, mit demselben Prompt, auf derselben Worktree-Baseline — B lief korrekt, A no-op-ppte. Das ist fresher-LLM-Non-Determinismus auf der Ausführungs-Ebene: die AD-17h-Aussage „zwei frische Agent-Kontexte … produzieren byte-identische Bundle-States" gilt nur, wenn beide Kontexte die Arbeit auch ausführen — und das ist nicht garantiert. Positiver Gegenbefund (Gate-Integrität): der Fail-Closed-Mechanismus (E.4 classify_diff → HARD-FAIL, exit 1) hat die Divergenz korrekt und prompt erfasst — das Gate ist nicht grün-gewaschen; es tut, was §5.14/AD-17h verlangen. Root-Cause offen: das Sandbox-Root / run-a.out-Transkript des Live-Runs ist nicht erhalten (Root aufgeräumt, find ohne Treffer), daher kann die warum-Frage (Agent-„keine Änderung nötig"-Fehleinschätzung, --bare-Verhalten, Timeout, Kontext-Verlust) nicht abschließend beantwortet werden — der Befund steht auf der beobachteten Gate-Evidenz; die Root-Cause-Diagnose bleibt offen. Stufe: Defekt (neuer, empirischer) — der Kern-A/B-Determinismus-AC ist empirisch nicht robust über frische LLM-Runs (Committed-Grün ≠ Live-Grün); zusätzlich Observability-Lücke (kein erhaltener Agent-Transkript → nicht erklärbar). Abgrenzung: F-5 = Spec-Selbstwiderspruch der Ausnahme-Menge + ungetestete Tagesgrenze; F-8 = delegierter CREATE-Subpfad (agent-less). F-10 ist beides nicht: es trifft den tatsächlich vom Gate geübten UPDATE-Kern an der Ausführungs-Ebene (Agent no-op) und ist empirisch beobachtet, nicht spekulativ. Fix-Optionen (Vorschlag, nicht auto-applied): (a) Run-Vollständigkeits-Guard: RUN_DONE nur, wenn ≥ 1 Mutation staged ist, sonst RUN_ABORTED — schließt die A-leer-Maske, dass ein no-op-Agent für „erledigt" gilt; (b) Divergenz-Retry bei E.4-HARD-FAIL (divergierenden Lauf max. N× neu, mit expliziter Retry-Protokollierung — keine stille Wiederholung); (c) die AD-17h-Claim-Schärfe um die Ausführungs-Voraussetzung erweitern („zwei frische Kontexte, die die Mutation beide ausführen"); (d) Agent-Transkript-Erhaltung im Gate (run-a.out/run-b.out im Sandbox-Root sichern, nicht aufräumen) für Root-Cause-Analyse.

Behavior verification

Methode: Die 12 rein-shell-Subsuiten (3-1…3-12) wurden in dieser Retro unabhängig re-executiert (frisch, kein Committed-Beleg) — jede mit Exit 0. Das Abnahmegate sandbox-3-13 (LLM-gesteuert: Sektion D Validator-Agent + Sektion E zwei frische Agent-Kontexte A/B via timeout 2700 "$CLAUDE_BIN" -p --bare) wurde als End-to-End-Re-Run dieser Retro ausgeführt und ist abgeschlossen; CLAUDE_BIN auf die echte claude.exe (v2.1.198) gesetzt, da der winpty-Shim C:\Users\mita\bin\claude in headless -p-Runs schlägt (Gate hat P-3-Override; siehe Memory wow2-claude-shim-winpty-headless). Ergebnis: ROT — HARD-FAIL (E.4), GATE_EXIT=1 (s. F-10 und unten).

Subsuiten — harte Re-Exekution (alle Exit 0):

Suite	Szenarien	Ergebnis	Bemerkung
3-1	V-1 (Vertrag §2) + 13 weitere	PASS 14/14	Run-FAIL bei fehlender Bundleroot korrekt ausgelöst; FAILED=0
3-2	7 Tests	PASS	abgeschlossen
3-3	U1–U9	PASS	unbefugter Frontmatter-Key → Struktur-HARD-FAIL (Pkt. 8)
3-4	S1–S6 + N1–N3 + Form-Wahl	PASS	Duplikat/Ghost-Diff-??-Negativkontrolle nicht vacuous
3-5	L1–L6 + N1 + D1 + D2	PASS	Leasing
3-6	STALE-1…STALE-6	PASS	Leasing-Staleness
3-7	CONSIST-1…7	PASS	VALIDATION_FAIL → §6-Pkt.-3-Rollback, AD-17f Teilerfolg-Never
3-8	DET-1…DET-8	PASS	ORPHAN datumsgruppierter log-Eintrag, Erhaltungs-Invariante (nur log.md mutiert)
3-9	R-1, R-1b, R-2…R-9	PASS	0 HARD-FAIL
3-10	E-1…E-9 (Zwei-Run-Identität)	PASS 9/0	E-9: A==B byte-identisch, nur generated.at differiert; „Nicht-Vakuum bei Zustandswechsel" — A==B-Assertion ist real, nicht tautologisch
3-11	A-1…A-8	PASS	atomare Root-Scope-Lease-Akquise (§5.17 Rev 3.6)
3-12	L-1…L-9	PASS	9 harte Assertions, self-contained /tmp-Bundle

LLM-Gate 3-13 — Live-Re-Exekution dieser Retro (ABGESCHLOSSEN, ROT):

Phase	Ergebnis
A Setup (A.2–A.4)	PASS (A.5 Pre-Check FAIL = mein uncommittetes Retro-Dokument hat das real-Repo-Porcelain verschmutzt; fail() ist nicht fatal — Zähler-Bemerkung, Gate läuft weiter)
B–C (12 Sub-Runs)	PASS — 3-1…3-12 alle OK, C.12 „ALLE 12 Sub-Runs grün"
D Validator (D.1–D.6)	PASS — 4/4 SUCCESS
D-NEG	PASS — 3×FAIL + 1×SUCCESS (Positiv-Kontrolle)
E.1–E.3 (Fixture, $BASE, Worktrees)	PASS — $BASE=6150f943…
E.4 A/B-Vergleich	HARD-FAIL — NON_AT=6 AT=2; HEAD-A==BASE (Lauf A no-op), Lauf B voll UPDATE; GATE_EXIT=1

Verhaltens-Fazit (korrigiert nach Live-Ergebnis): Das deterministische Rückgrat des Epics (inkrementeller Dataflow, textuelle Relevance, atomare Lease, deterministischer Rollback) ist unabhängig reproduzierbar grün (12/12 Subsuiten Exit 0; im Gate: C 12/12, D, D-NEG) und — entscheidend für AD-13/AD-17h — die A==B-Determinismus-Assertion wird in 3-10 nicht-vakuum ausgeübt (Zustandswechsel erzwingt echte Byte-Äquivalenz statt Trivials). Aber die live End-to-End-Abnahme (zwei frische LLM-Agent-Kontexte auf dem UPDATE-Kern) ist an E.4 ROT: Lauf A no-op-ppte, Lauf B lief korrekt (F-10). Das heißt konkret: das deterministic Kernel ist grün, die frische-LLM-Ausführung des Kern-ACs ist es empirisch nicht robust — und zwar am selben Tag, ohne Midnight-Bruch (also nicht F-5) und im UPDATE-Kern, nicht im delegierten CREATE-Subpfad (also nicht F-8). Das authoritative grüne Gate bleibt der committed Re-Run #10 (2026-08-24, 09c1c83): FAILED=0 PASS_COUNT=51, SANDBOX-3-13-OK, Exit 0 (/tmp/gate-313-run10.log Z. 1230/1275/1277). Die Live-Re-Exekution ist eine unabhängige Wiederholung — und sie bestätigt das Kern-Risiko, das F-5/F-8 spekulativ benannt haben: der frische-LLM-Pfad ist nicht deterministisch robust. Sie ersetzt aber nicht den grünen Committed-Beleg, auf dem das Verdikt steht; sie verstärkt jedoch die Argumentation, dass F-5 (und neu F-10) als blocking eingestuft werden sollten.

Action items

Jedes Item: Befund-Ref + Disposition (fix-now → Action-Item; defer → mit Kontext nachführbar) + Owner. Remediation und Spec-Reconciliation sind hier proponiert, nicht auto-applied — ProMods entscheidet über die Ausführung (AD-3/D-3: compiler.md/validator.md/canonical-terms.md sind read-only; eine Spec-Änderung erfordert eine autorisierte Revision).

ID	Befund	Action	Owner	Art
AI-3-R-1	F-5	Dateigruppen-Determinismus heilen: die ## YYYY-MM-DD-Header in wiki/log.md entweder auf einen Git-Wert pinnen (git show -s --format=%cs $BASE in §5.9 Pkt. 4 / AGENT_PROMPT) oder die ## -Header-Zeile in classify_diff (3-13:650-653) als benannte Ausnahme wie at-Zeilen klassifizieren; und den §5.9-Z.277-Wortlaut („keinen Wanduhr-Wert … nie im log.md-Body") mit der Header-Realität in Einklang bringen. Schließt den §5.14-„genau eine Ausnahme"-Selbstwiderspruch.	ProMods (Autorisierung) + dev	Spec-Reconciliation (fix-now-Vorschlag)
AI-3-R-2	F-6	§5.12↔§5.18-Staleness-Reconciliation: in §5.12 Pkt. 1 (Z. 327, „TTL-Ablauf-Äquivalent" = Gen-only-stale) eine Supersession-Notiz zu §5.18 Pkt. 1 (Z. 430) + Story 3.12-AC (Z. 426: Stale verlangt bestätigten Abbruch/abgelaufene Liveness) ergänzen; §5.18 als normative Staleness-Autorität kennzeichnen.	ProMods + dev	Spec-Reconciliation (defer)
AI-3-R-3	F-7	Gate-Leasing-Verifikation ergänzen: ein 3-13-Szenario (analog E.9, Known-Value-Witness), das im realen Agent-Lauf (wt-a) verifiziert: refs/leases/wiki existiert und git rev-parse 'refs/leases/wiki^{}' == git hash-object der Run-ID — beweist, dass der reale Agent den §5.17-atomaren Pfad annimmt (nicht das supersedierte §5.11-check-then-act-Lockfile).	dev+review	Remediation (Gate-Härtung, defer)
AI-3-R-4	F-9	Em-Dash-Kollaps-Klasse Cross-File-Reconciliation: canonical-terms.md-Formatzeile (Z. 18/21, [-–_ ]) append-only-konform um den Em-Dash — ergänzen (Korrekturnotiz auf die §3.2/§5.14-Z.51/54a-Klasse [-–— _]).	ProMods + dev	Spec-Reconciliation (defer)
AI-3-R-5	F-1	norm()-Vereinheitlichung + LC_ALL-Pinning: die 4 drifteten norm()-Kopien (3-8/3-9/3-10/3-11) auf eine kanonische Implementierung (mit Case-Folding) vereinheitlichen + LC_ALL=C-Pinning (3-11 ist heute LC_ALL=0). Sharpening des bekannten D-7/W-3.9-1-Defers.	dev	Defer (Home: Sandbox-Härtung)
AI-3-R-6	F-8	Fresh-LLM-CREATE-Residual (Nutzer-Defer D-3.13-L2-3): der nicht-deterministische CREATE-/Synthese-Unterpfad (Re-Run-#5: 24/26 NON_AT) bleibt benanntes Residual; Substitutions-Notiz (mechanisch gepinnt ≙ frischer LLM für die Mechanik-Struktur) ist ausgeführt. Kandidat für spätere compiler.md-Revision oder Epic-4-Determinismus-Überarbeitung.	ProMods / Epic 4	Defer (Nutzer-Entscheidung, bereits dokumentiert)
AI-3-R-7	F-2/F-3	Beobachtung (kein fix-now): compiler.md §5-Wachstum (5→15 Sektionen, 548 Z.) + nicht zusammenhängende §5-Nummerierung (5.10 = Story 3.4 …). Für eine spätere strukturelle Revision notiert.	—	Accept-as-is / observe
AI-3-R-8	F-10 (NEU, empirisch)	Frischer-LLM-Non-Execution absichern (Kern-AC-Robustheit): (a) Run-Vollständigkeits-Guard im Gate — RUN_DONE nur, wenn ≥ 1 Mutation staged, sonst RUN_ABORTED (schließt die „no-op-Agent gilt als erledigt"-Maske); (b) Divergenz-Retry bei E.4-HARD-FAIL (max. N×, explizit protokolliert, keine stille Wiederholung); (c) AD-17h-Claim-Schärfe um die Ausführungs-Voraussetzung erweitern; (d) Agent-Transkript-Erhaltung im Gate (run-a.out/run-b.out nicht aufräumen) → Root-Cause-Diagnose (aktuell offen, Root aufgeräumt).	dev+review	Remediation (Gate-Härtung; fix-now-Vorschlag, da empirisch am Kern-AC)

Carry-forward (nicht neue Epic-3-Items): die 4 offenen Epic-2-Items AI-2-R-1…4 (epic-2-retro-item-10…13, s. Previous-retro follow-through) bleiben open — sie betreffen §5.5/§5.6/§5.8 (Bestands-Sektionen, nicht im Epic-3-Scope). Empfehlung: in einer Folge-Story „Instruktion-/Sandbox-Vereinheitlichung" gebündelt mit AI-3-R-5 (norm()/LC_ALL) abarbeiten (s. Open questions).

Acceptance verdict

Verdikt: accepted-with-open-items · Kriterien: declared (ACs je Story in planning-artifacts/epics.md Epic-3-Block Z. 259–451) · pending_stories: leer (alle 13 Stories 3.1–3.13 done, detect-epic --epic 3, 2026-08-24) → kein Machine-Zwang zu rejected.

Begründung (Evidenz):

1. Kriterien demonstrativ erfüllt:

   • Abnahmegate (Story 3.13) grün auf Re-Exekution: Committed Re-Run #10 (2026-08-24, 09c1c83): FAILED=0 PASS_COUNT=51, SANDBOX-3-13-OK, Exit 0 — A.5 Pre-Check, C 12/12, D 4/4 SUCCESS, D-NEG 3×FAIL+1×SUCCESS, E.4 NON_AT=0 AT=2 (Bundle-State identisch bis auf at:), E.6 Feldsatz-exakt + Known-Value-Witness, E.9 kanonische Baseline $BASE-Form, F G-1..G-8, G-8 Porcelain-Clean + AD-3 ohne Diff. In dieser Retro zusätzlich: alle 12 deterministischen Subsuiten (3-1…3-12) unabhängig re-executiert → alle Exit 0; das LLM-Gate 3-13 wurde als End-to-End-Re-Run ausgeführt und ist abgeschlossen — aber ROT an E.4 (NON_AT=6 AT=2, GATE_EXIT=1; Lauf A no-op, Lauf B korrekt — F-10). Der grüne Committed-Beleg (Re-Run #10) steht weiterhin; die Live-Re-Exekution widerlegt ihn nicht, bestätigt aber das Kern-Risiko.
   • Determinismus-Kern nicht-vakuum (F-4): die A==B-Assertion (3-10 E-9) erzwingt echte Byte-Äquivalenz, nur generated.at differiert, Zustandswechsel-Nicht-Vakuum ausgeübt — AD-17h/FT-10 halten mechanisch.
   • Leasing-Semantik (3-5/3-6/3-11/3-12) grün: atomare Akquise (3-11 A-1..A-8), Staleness/Recovery (3-6 STALE-1..6), Lifecycle/Rollback/Release (3-12 L-1..L-9).
   • Textuelle Determinismus-Relevance, kein Embedding (3-2/3-8/3-9/3-10): AD-13 in allen Läufen gewahrt.

2. Offene, benannte, getrackte Befunde (kein accepted — deshalb -with-open-items): F-5, F-6, F-7, F-9 sind keine „Epic erledigt, kleine Nachträge" — sie sind reale Defekte/Verifikations-Lücken, alle mit Quelle, Owner und Disposition (AI-3-R-1…6). F-10 (neu, empirisch): die Live-Re-Exekution des Gates ist ROT am Kern-AC — frischer-LLM-Non-Execution auf der Ausführungs-Ebene (AI-3-R-8). F-8 ist ein Nutzer-Defer (D-3.13-L2-3). F-1/F-2/F-3 sind Latenz/Beobachtung.

Die zwei material-entscheidenden Items — F-5 (Midnight-Dateigruppen-Bruch, Spec) + F-10 (Live-Kern-AC-ROT, empirisch): Der §5.14-Determinismus-Vertrag ist der Kern-AC des Epics (AD-17h, FT-10, AC-1/AC-6). F-5 zeigt, dass er im Wortlaut selbst widersprüchlich ist (erlaubt „genau eine" Ausnahme = generated.at, verlangt aber eine zweite, ungepinnte Wanduhr-Wand im log.md-Body via §5.9 Pkt. 4) und an der Tagesgrenze ungeschützt/ungetestet. F-10 zeigt, dass der Mechanismus über frische LLM-Runs empirisch nicht robust ist (Live-Run: Lauf A no-op, Lauf B korrekt, E.4 HARD-FAIL, GATE_EXIT=1). Zusammen: der Kern-AC hat sowohl eine Spec-Lücke (F-5) als auch eine Ausführungs-Verlässlichkeits-Lücke (F-10). Beide sind durch autorisierte Revisionen (AI-3-R-1) bzw. Gate-Härtung (AI-3-R-8) zu schließen. Das rechtfertigt accepted-with-open-items (nicht accepted): die Befunde sind getrackt, bequellen, haben Owner und Fix-Pfade — aber sie sind nicht „kleine Nachträge".

Eskalationsgrenze (ProMods-Entscheidung): F-5 und F-10 sind die Befunde, die dieses Verdikt von accepted-with-open-items auf rejected kippen könnten — wenn ProMods sie als blocking einstuft. F-5 = Selbstwiderspruch im Kern-Determinismus-AC; F-10 = der Kern-Determinismus-AC ist empirisch (nicht nur spekulativ) nicht robust über frische LLM-Runs. Dazu F-7: die sicherheitskritische Leasing-Invariante „genau ein aktiver Root-Scope-Holder" wird nur durch Sandbox-interne Bash-Helfer, nicht durch den realen Agent-Lauf verifiziert. Das ist eine bewusste Abwägung: der deterministische Kern ist grün (12/12 Subsuiten, Re-Run #10 grün) und das Gate ist fail-closed-korrekt (F-10 wurde erfasst, nicht verschwiegen); die Befunde sind getrackt, bequellen und haben Fix-Pfade. Entscheidung ProMods (2026-08-24): F-5/F-10 = tracked gap → das Verdikt accepted-with-open-items ist final. Konsequenz: AI-3-R-8 (F-10-Ausführungs-Robustheit) ist Voraussetzung dafür, dass Epic 4 auf deterministischem CREATE/Synthese aufbaut (Open question 3) — ein spätes Umstufen auf blocking würde Epic 4 halten.

Open questions

1. F-5 + F-10: gap oder blocking? (gemeinsam die Eskalationsgrenze) — F-5 = Selbstwiderspruch im Kern-Determinismus-AC (§5.14 „genau eine Ausnahme" vs. §5.9 Pkt. 4 zweite Wanduhr-Wand) + ungeschützte Tagesgrenze (Spec-Ebene). F-10 = derselbe Kern-AC ist empirisch nicht robust über frische LLM-Runs (Live-Re-Exekution ROT an E.4, Lauf A no-op) (Ausführungs-Ebene). Diese Einstufung ist eine ProMods-Entscheidung: als blocking → Verdikt rejected (Epic 4 wird gehalten, da es an den §5.14-Vertrag andockt); als tracked gap → accepted-with-open-items (Empfehlung dieser Retro, da der deterministische Kern grün ist — 12/12 Subsuiten + Re-Run #10 — und das Gate fail-closed die Divergenz erfasst hat, nicht verschwiegen; F-5 liegt in der Spec-Schärfe, F-10 in der Ausführungs-Verlässlichkeit, beide mit Fix-Pfaden AI-3-R-1 / AI-3-R-8). — Entscheidung ProMods (2026-08-24): tracked gap („Ich folge Deiner Empfehlung") → Verdikt accepted-with-open-items ist final; Bedingung: AI-3-R-8 (F-10, Ausführungs-Robustheit) vor dem CREATE-Aufbau von Epic 4 abarbeiten.

2. F-10 Root-Cause offen — Der Lauf-A-Non-Execution-Treiber ist nicht abschließend bestimmbar (Sandbox-Root / run-a.out aufgeräumt, kein erhaltener Agent-Transkript). Soll (a) das Gate Agent-Transkripte erhalten (AI-3-R-8 d), damit ein nächster roter Live-Run diagnostizierbar ist, und/oder (b) ein erneuter kontrollierter Live-Run (mit Transkript-Erhaltung) als Root-Cause-Nachweis gefahren werden? Empfehlung: (a) sofort (Gate-Härtung, klein), (b) optional als Verifikation.

3. F-8: CREATE-/Synthese-Coverage — Der fresh-LLM-CREATE-Unterpfad (24/26 NON_AT, Re-Run #5) ist als Nutzer-Defer (D-3.13-L2-3) dokumentiert. Soll das Residual in Epic 4 (Determinismus-Überarbeitung) oder in einer separaten compiler.md-Revision vor Epic 4 gelandet werden? (Empfehlung: vor Epic 4, da Epic 4 auf deterministischem CREATE aufbauen wird.) — Verstärkt durch F-10: da die frische-LLM-Ausführung empirisch nicht robust ist (F-10), ist die CREATE-Coverage-Lücke (F-8) nicht nur eine delegierte Mechanik, sondern teilt dieselbe Ausführungs-Verlässlichkeits-Riskoklasse.

4. Gebündelte Spec-Vereinheitlichung: die 4 offenen Epic-2-Items (AI-2-R-1…4) + AI-3-R-5 (norm()/LC_ALL) + AI-3-R-4 (Em-Dash) betreffen alle die §5-Formel-/Normalisierungs-Fläche bzw. die Kollaps-Klasse. Empfehlung: eine „Instruktion-/Sandbox-Vereinheitlichungs"-Story in Epic 4 (oder als Epic-3.5-Hotfix) bündelt sie — statt je eigener Revision. ProMods: bündeln oder einzeln?

5. Session-Logs fehlen: Prozess-Lektionen (warum Story 3.13 ≥ 6 Re-Runs + 2 Review-Loops brauchte) sind nur aus dem git-loggbaren Verhalten ableitbar (Commit-Kette vollständig); keine Session-/Transcript-Evidenz in dieser Umgebung. Kein Befund davon abgeleitet.

Previous-retro follow-through

Basis: sprint-status.yaml → action_items (Epic 2), gekreuzt gegen schema/compiler.md (Ist-Zustand, efc543c^..3f57586-Range) und epic-2-retro-2026-08-18.md. Die 5 Epic-2-Aktionsitems (AI-2-R-1…5) sind in sprint-status.yaml als epic-2-retro-item-10…14 / code-review-2-1-item-* gebucht.

Epic-2-Item	AI-Ref	Inhalt	Ist-Zustand (Epic 3-Ende)	Status
epic-2-retro-item-10	AI-2-R-1 (F-01)	§5.5-Selbsttest-Formel rekursiv machen (grep -rnE (raw/ über wiki/ inkl. Area-Concepts)	nicht umgesetzt — compiler.md:104/127 steht weiterhin bei grep -nE '\(raw/' wiki/*.md (Nicht-rekursiv, wiki/*.md greift keine wiki/<area>/*.md an)	OPEN (übernommen, nicht gelöst)
epic-2-retro-item-11	AI-2-R-2 (F-03)	§5.8-Lauf A um Area-Concept-ohne-index.md (Tiefe-2, wiki/<a>/concept.md ohne wiki/a/index.md) erweitern	nicht umgesetzt — compiler.md:239 Lauf (A) scannt weiterhin nur -name index.md; Lauf (B) (:239, -mindepth 3) erfasst nur Tiefe ≥ 3 → ein Tiefe-2-Concept ohne index.md ist beiden Läufen unsichtbar	OPEN (übernommen, nicht gelöst)
epic-2-retro-item-12	AI-2-R-3 (F-04)	§5.6-Formel-4-Filter-Asymmetrie heilen (--exclude=log.md vs grep -v log.md$ auf eine Semantik)	nicht umgesetzt — compiler.md:185 (Ist) --exclude=log.md vs :186 (Baseline) grep -v "log.md$" — die Asymmetrie (Basename-Basename-Exklusion vs Anker-Basename-Filter) steht weiterhin side-by-side	OPEN (übernommen, nicht gelöst)
epic-2-retro-item-13	AI-2-R-4 (F-05)	§5.8-Reachability als echte Markdown-Links prüfen + ./-Variante mit §5.6-Pin vereinheitlichen	teilweise — „echte Markdown-Links"-Hälfte umgesetzt (Loop-3-Fix, :244: prüft jetzt Linksyntax ]( statt bloßem Klammer-Paar); ./-Vereinheitlichung nicht umgesetzt — :239 Lauf A akzeptiert weiterhin ](./$a/index.md), während der §5.6-Form-Check (:169) ./-Präfix-Ziele via grep -vE '^\.' aus der Form-Zählung nimmt → die ./-Asymmetrie bleibt	OPEN (Halbteil gelöst, Kern-./-Teil übernommen, nicht gelöst)
epic-2-retro-item-14	AI-2-R-5 (F-02)	Autorisierte Validator-Rev-9 für Punkt-11-Area-Lesart	umgesetzt — validator.md Revision 9, Punkt-11-Area-Lesart formalisiert (file-relative Referenz in index.md); zertifiziert	done (closed 2026-08-18)

Fazit: Von den 5 Epic-2-Retro-Items ist 1 (AI-2-R-5) geschlossen (bereits 2026-08-18, vor dem Epic-3-Range) und 4 (AI-2-R-1…4) sind nach wie vor offen — alle vier betreffen Bestands-Sektionen (§5.5/§5.6/§5.8), die Epic 3 nicht im Scope hatte (Epic 3 = neue Sektionen §5.9–§5.18 + Determinismus-Vertrag §5.14/§6.5). Der Churn an compiler.md in Epic 3 (21 Commits) traf diese drei Self-Test-Formeln nicht, daher blieben die Lücken strukturell erhalten. Das ist kein Epic-3-Defekt (die Items waren korrekt an Epic 3 angehängt als open), aber es bestätigt den in F-2 genannten Wartungspunkt: die §5-Formel-Fläche ist der natürliche Ort, an dem Epic-übergreifende Self-Test-Lücken akkumulieren — eine Folge-Story/Revision sollte die 4 offenen AI-2-R-Items gebündelt abarbeiten (natürliche „Sandbox-/Instruktion-Vereinheitlichung"-Home, s. deferred-work.md).

Kein Status-Transition-Vorschlag an sprint-status.yaml für die Epic-2-Items — die 4 offenen bleiben open (nachweislich nicht gelöst), item-14 ist bereits done.