wow20/_bmad-output/implementation-artifacts/spec-3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile-synthesize-update.md

title, type, created, status, review_loop_iteration, baseline_commit, context

title	type	created	status	review_loop_iteration	baseline_commit	context
Inkrementellen Datenfluss implementieren (Interpret → Reconcile → Synthesize → Update) (Story 3.1)	feature	2026-08-18	done	2	802a5576eb	_bmad-output/implementation-artifacts/epic-3-context.md

Intent

Problem: Die Compiler-Instruktion (schema/compiler.md) kennt heute nur den Neu-Anlage-Pfad (Erzeugung neuer Concepts). Die Erweiterung/Präzisierung/Korrektur bestehender Concepts wird an zwei Stellen explizit als Epic-3-Vorbehalt ausgeschlossen (compiler.md:40 §3.2-Kollision-Hold „Aktualisierung ist Epic 3"; compiler.md:287 §7), und der §0-Aufruf (compiler.md:13) beschreibt die Phasenfolge Interpret → Reconcile → Synthetisieren → Mutieren → Validieren nur als Erzeugungs-Ablauf. Damit ist der zweite Compilation Run gegen bestehendes Wissen (FR-4) instruktionsseitig nicht definiert: Es gibt keinen deterministischen Pfad, wie ein Run neue Evidenz mit den tatsächlich betroffenen Concepts verrechnet, ohne unverändertes Wissen zu regenerieren (AD-5, A0-6, FR-6, FR-12).

Approach: Story 3.1 verankert den inkrementellen Datenfluss als Erweiterungs-Instruktion in schema/compiler.md (D-3, rein textuell — kein Code, kein Standalone): (a) das bestehende Reconcile (§3) wird vom bloßen Dateikollisions-Hold zum Update-Routing (erkannte bestehende Wissenseinheit → Update-Kandidat, kein Duplikat, kein stilles Überschreiben); (b) eine neue Update-Mutations-Sektion (§5.9) spezifiziert, wie ein bestehendes Concept erweitert/präzisiert/korrigiert wird (FR-6) und wie Inline-Provenienz (§5.5) und sources nachgeführt werden; (c) die Erhaltungs-Invariante wird verankert: nicht betroffene Concept-Pfade bleiben bit-identisch unverändert (FT-6, FR-12), Git-Änderungen konzentrieren sich auf betroffene Concepts — nachweisbar über einen deterministischen Diff-Selbsttest; (d) die Defer-BausteineR-1 (Input-Zuwachserkennung: welche raw/-Dateien sind neu/modifiziert — via git diff und/oder SHA-256-Record aus source.md) und P2 (Pre-Run-Reconcile-Check-Block als wiederverwendbarer, textueller Vorprüf-Block) werden als Teil des inkrementellen Runs eingearbeitet. Vertrag (schema/wiki-compiler.md), Validator (schema/validator.md) und raw/ bleiben read-only (AD-3); keine neue §7-Invaliditätsklasse.

Boundaries & Constraints

Always:

• Story 3.1 ist eine Instruktions-Story (D-3). Der inkrementelle Datenfluss wird ausschließlich in schema/compiler.md als deterministische Text-Instruktion verankert. Kein ausführbares Programm, kein Standalone-Validierungs-Tool, keine neue §7-Invaliditätsklasse, kein Change an schema/wiki-compiler.md / schema/validator.md / raw/ (AD-3).
• Das Update ersetzt den Abbruch, nicht die Erhaltung. Wo heute der Kollisions-Hold bei „Concept existiert bereits" den Run für die Einheit abbricht, tritt das Update-Routing: eine erkannte bestehende Wissenseinheit wird im bestehenden Concept-Pfad aktualisiert (keine neue Datei, kein Duplikat — FR-6). Beibehaltende und neue belegte Aussagen werden sauber geführt. Kein stummer Überschreib (bestehende Provenienz/Inhalte werden nie ohne Beleg entfernt — AD-16-Default behält die Erhaltung; die AD-16-Klassifikation selbst ist Epic 4, Story 4.1, und wird hier nicht vorweggenommen).
• Erhaltungs-Invariante (Kern): Ein Compilation Run darf nur die Concepts neu anlegen oder verändern, die durch den erkannten neuen Erkenntnis-Zuwachs tatsächlich betroffen sind. Nicht betroffene Concept-Pfade bleiben byte-identisch unverändert (FT-6, FR-12); es gibt nie „Regenerate Everything" aus allen Rohquellen (AD-5, A0-6). Nachweisbar über einen re-executierbaren Diff-Selbsttest (git diff --stat auf wiki/ zeigt ausschließlich betroffene Dateien + log.md + Index-Nachführungen).
• published/committed als Input (AD-17.2/AD-17a): Der Run verarbeitet ausschließlich veröffentlichte (committete) Inhalte als Input — neues Source Material, sobald es unter raw/ committet ist, und das bestehende wiki/ aus committetem Zustand. Zwischenstände während einer Mutation sind nie Input (§1.1 bleibt bestehende Regel, wird referenziert).
• Reconcile-Ergebnis ist die Update-Kandidatenliste. Der Reconcile-Schritt erzwingt, dass der Producer die Menge der betroffenen Concepts als nachvollziehbare Kandidatenliste (Concept-Pfade) erhebt, bevor mutiert wird. Der feinkörnige Relevanz-Findungsmechanismus (grep/ripgrep/Markdown-Traversal/Link-Following als eigene Ausformulierung) ist Story 3.2 vorbehalten; Story 3.1 bindet die Kandidatenerhebung an textuelle, deterministische Mittel (Konzept-/Term-Überschneidung zwischen neuer Evidenz und bestehenden Concept-Bodies via grep/ripgrep, index.md-Traversal, Link-Following) — keine Embeddings/Vector (AD-13).
• Kein Leasing-/Dirty-Tree-Scope in 3.1. Leasing, Dirty-Tree-Schutz, Staleness, Merge-vermittelte Kollision sind Story 3.5/3.6. Story 3.1 behält die bestehende Commit-Boundary = Mutations-Boundary-Regel (AD-17f, compiler.md:13/:63) bei und ändert sie nicht.
• Defer-Bausteine werden mitgezogen: deferred-work R-1 (Input-Zuwachserkennung via git diff + SHA-256-Record aus source.md) und P2 (Pre-Run-Reconcile-Check-Block bündeln) werden als Teil der inkrementellen Run-Instruktion eingearbeitet und in deferred-work.md als aufgegriffen markiert (append-only, keine Duplikate).
• sprint-status.yaml: Key 3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile → in-progress.

Ask First: AD-7d-Renames/Redirects bestehender Concepts · Einführung einer echten Kollisions-Klassifikation (CORRECTING/CONTRADICTING etc.) vor Epic 4 · Wechsel des generated.at-Verhaltens bei Updates gegenüber der hier festgelegten Konvention (s. Design Notes) · Validator-/Vertrags-/raw/-Change · Änderung der Commit-Boundary-Regel.

Never: Änderungen an schema/wiki-compiler.md/schema/validator.md/raw/ (AD-3) · neue §7-Invaliditätsklasse · Einführung eines Standalone-Programms/Validators (D-3) · „Regenerate Everything" über bestehende Concepts (AD-5, A0-6) · stummer Überschreib oder Löschung bestehender Provenienz ohne Beleg (AD-16-Default: Erhaltung) · Embedding/Vector-Suche (AD-13) · Duplikat-Anlage eines bestehenden Concept-Pfads.

I/O & Edge-Case Matrix

Scenario	Input / State	Expected Output / Behavior	Error Handling
HAPPY_PATH_UPDATE	Bestehendes Concept wiki/<a>/<c>.md + neue committete Evidenz raw/… betrifft es (Term-/Konzept-Überschneidung)	Update-Routing: Concept wird im bestehenden Pfad erweitert/präzisiert (§5.9); Inline-Provenienz + sources nachgeführt (nur echt neue Belege ergänzt); log.md-Eintrag (Vertrag §5-Format) mit Story 3.1; kein neues File, kein Duplikat	N/A
UNTOUCHED_CONCEPT	Neue Evidenz betrifft ein bestehendes Concept nicht (keine Überschneidung)	Concept bleibt unverändert: keine Dateiänderung, kein Index-, kein log.md-Zusatz (FT-6/FR-12); Diff-Selbsttest zeigt keinen Ghost-Diff auf diesem Pfad	N/A
INPUT_UNCOMMITTED	Run erhält uncommittete Zwischenstände (Arbeitskopie wiki//raw/ abweichend von HEAD) als Input	Run lehnt ab bzw. bezieht nur published/committed Zustand ein (AD-17a); keine Mutation gegen Zwischenstände	textuell benannter Abbruch „published/committed Input erforderlich" (§1.1-Fortsetzung)
CHANGE_DETECTION (R-1)	raw/ enthält (a) eine neue, (b) eine unveränderte Evidenzdatei	Zuwachserkennung: nur die neue/modifizierte Datei wird als Zuwachs interpretiert (git-diff-basiert und/oder SHA-256-Record aus source.md); unveränderte bleiben außen vor	unlesbarer/fehlender SHA-256-Record → Hinweis, Datei dennoch als Zuwachs nicht doppelt verarbeiten
CONCEPT_COLLISION_BESTEHEND	Erkannte Wissenseinheit = bereits existierendes Concept (Ziel-Pfad belegt)	Statt bisherigem Kollision-Hold-Abbruch: Update-Routing (§5.9) — Mutation im bestehenden Pfad; kein Duplikat, kein stummer Überschreib; Index-Link bleibt unverändert gültig	Widersprechender Inhalt ohne Ersetzungsevidenz → Erhaltung; explizite Ablage in log.md (Epic-4-Interface, keine Korrektur-Klassifikation hier)
PRE_RUN_RECONCILE (P2)	Run-Start mit neuem Zuwachs	Pre-Run-Reconcile-Check-Block (Zielpfade, Quellen-Existenz EC-1, Betroffenheits-Kandidatenliste, wiki/index.md-V-1) wird vor jeder Mutation durchlaufen und textuell festgehalten	fehlende Bundleroot → Run-FAIL (V-1, besteht fort)

Code Map

• schema/compiler.md — primär mutiert (D-3, einziger Instruktions-Ort):
  • §0-Aufruf (:13): Ablaufstruktur um die Update-Variante präzisieren — die sechs Phasen bleiben; Reconcile/Mutieren betreffen auch bestehende Concepts.
  • §3 Reconcile (:37–41): Pkt. 2 Kollision-Hold (:40) — Epic-3-Abbruch („Aktualisierung ist Epic 3") ersetzen durch Update-Routing (→ §5.9); Candidate-Erhebung (betroffene Concepts) textuell-deterministisch; Pkt. 3 V-1-Prüfung (:41) bleibt.
  • Neue §5.9 „Inkrementelles Update bestehender Concepts (Story 3.1)" nach §5.8 (nach :233, vor §6 :234): (1) Update-Stimulus = Reconcile-Kandidatenliste (betroffene Concept-Pfade); (2) Mutationsmechanik — Erweitern (Absatz/Beleg ergänzen), Präzisieren (Aussage schärfen, Beleg neu/nachführen), Korrigieren (ersetzte Aussage + Ersetzungsbeleg, keine stille Löschung), Frontmatter-sources nur um echte neue Belege ergänzen, generated.at = aktueller Run-Zeitstempel (Konvention, s. Design Notes), vorhandenes verified bleibt stehen; (3) Index-/Link-Form unverändert (§5.6-Pin), kein neuer Link bei reinem Body-Update; (4) log.md-Eintragspflicht (Vertrag §5; „Story 3.1-Update" markieren); (5) deterministischer Diff-Selbsttest der Erhaltungs-Invariante (nur betroffene Dateien + log.md + Index im git diff --stat auf wiki/); (6) Change-Detection (Defer R-1: git diff auf raw/ und/oder SHA-256-Record aus raw/**/source.md bestimmt den Zuwachs) und Pre-Run-Reconcile-Check-Block (Defer P2) als wiederverwendbare textuelle Check-Blöcke der Run-Vorphase.
  • §7 (:287): Epic-3-Vorbehalt auf die verbleibenden 3.x-Themen kürzen (Synthese über mehrere Concepts → 3.4; Leasing/Dirty-Tree → 3.5/3.6; Relevanz-Verfeinerung → 3.2) — das Update-Thema ist damit aus dem Vorbehalt entlassen.
  • §8 Revisionslog (:291–317): Revision 2.4 (Story 3.1) + Normreferenzen unverändert (AD-5, AD-6, AD-17h sind schon gelistet; A0-6/FR-6/FR-12 ggf. ergänzen); Abschlussklausel (kein Vertrag-/Validator-/raw/-Change, keine neue §7-Klasse, kein Standalone).
• wiki/log.md — append: Story-3.1-Eintrag (Vertrag §5-Format, ## YYYY-MM-DD Gruppe nach :3) mit Update-Semantik, Erhaltungs-Invariante, Diff-Selbsttest-Beleg (Ist-Baum: kein Ghost-Diff), Statuswechsel 3-1-… backlog → in-progress, per-Datei-Validator-Verdikt-Zeile (Ist-Baum SUCCESS) — Analogie Story-2.5-Eintrag (log.md:5).
• _bmad-output/implementation-artifacts/deferred-work.md — mutiert (append-only): Defer R-1 (:126–128) und P2 (:160–162): status-Nachführungs-Notiz „aufgegriffen (2026-08-18, Story 3.1 — §5.9)" — bestehende Einträge nicht verändern, nur Status-Ergänzung im vorgegebenen append-only-Stil.
• _bmad-output/implementation-artifacts/sprint-status.yaml — mutiert: Key 3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile (:54) → in-progress.
• schema/validator.md, schema/wiki-compiler.md, raw/…, bestehende Concept-Inhalte — read-only (AD-3). Story 3.1 mutiert selbst keine Concept-Inhalte (Instruktions-Story); Demo-/Nachweis-Läufe laufen im Sandbox-Baum oder gegen den Ist-Baum ohne Inhalts-Mutation (Diff-Selbsttest + Validator-Verdikt).

Tasks & Acceptance

Execution:

• schema/compiler.md — §3-Pkt.-2-Hold → Update-Routing; Candidate-Erhebung; neue §5.9 (Mutationsmechanik, log.md, Diff-Selbsttest, R-1-Change-Detection, P2-Check-Block); §0-Präzisierung; §7-Vorbehalt kürzen; §8-Revision 2.4. Kein Vertrag-/Validator-/raw/-Change.
• wiki/log.md — Story-3.1-Eintrag (Vertrag §5-Format) mit Update-Semantik, Erhaltungs-Invariante + Diff-Selbsttest-Beleg, Statuswechsel, Validator-Verdikt.
• deferred-work.md — R-1-/P2-Einträge mit „aufgegriffen (Story 3.1)"-Statusnachführung markieren (append-only); sprint-status.yaml — Key 3-1-… → in-progress.
• Edge-Tests im Sandbox-Baum (I/O-Matrix): HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT (kein Diff), CONCEPT_COLLISION_BESTEHEND (kein Duplikat), CHANGE_DETECTION (nur Zuwachs), PRE_RUN_RECONCILE.

Acceptance Criteria:

• Given ein bestehendes Bundle und neues Source Material, when ein Compilation Run startet, then folgt er dem inkrementellen Datenfluss Interpret → Reconcile → Synthesize → Update affected Concepts (AD-5, A0-6) — instruktionsseitig in schema/compiler.md (§3 + neue §5.9) verankert.
• Given ein Run, when er einen bestehenden Concept-Pfad nicht betrifft, then bleibt dessen Inhalt unverändert erhalten — keine Regeneration (FT-6, FR-12); belegt durch den re-executierbaren Diff-Selbsttest (nur betroffene Dateien + log.md + Index im git diff --stat).
• Given ein Lauf, when er abgeschlossen ist, then konzentrieren sich die Git-Änderungen auf durch die neue Erkenntnis betroffene Concepts (AD-5, FR-6) — kein Ghost-Diff, kein Duplikat bestehender Concept-Pfade.
• Given der Run-Input, when verarbeitet, then verwendet er ausschließlich published/committed Inhalte und nie Zwischenstände während der Mutation (AD-17.2/AD-17a) — bestehende §1.1-Regel bleibt und wird referenziert.
• Given die Instruktion, when geprüft, then bleibt schema/validator.md/schema/wiki-compiler.md/raw/ unverändert (AD-3), es gibt keine neue §7-Klasse und kein Standalone (D-3) — der Validator läuft auf dem Ist-Bundle SUCCESS (per-Datei-Verdikt-Nachweis in wiki/log.md).

Review Findings

bmad-code-review 2026-08-19 (Loop 2, 4 Layer: blind-hunter / edge-case-hunter / verification-gap / acceptance-auditor; Diff-Baseline 802a557 → efc543c). Verifiziert am Ist-Baum: grep "Aktualisierung ist Epic 3" schema/compiler.md → kein Treffer (Rev-2.4.1-Claim korrekt); rg -l 'FR-12' wiki/ → wiki/knowledge-kompilation-inkrementell.md + wiki/log.md (Worked-Example-Ziel wissensarchitektur/source-material.md NICHT getroffen).

Decision-needed (alle 2026-08-19 per Nutzer-Entscheidung 1/1/1/1 aufgelöst — jeweils empfohlene Option gewählt):

• [Review][Decision] D-1: Diff-Selbsttest-Probe neu definieren — git diff --name-only -- wiki/ ist blind für (a) ungetrackte neue Dateien (Duplikat-Verstoß unsichtbar), (b) den Zustand nach dem Commit (leere Ausgabe = vacuous Test, Commit-Boundary = Mutations-Boundary AD-17f), und die erlaubte Menge enthält keine Neu-Anlage-Zielpfade (Misch-Runs → jede Neu-Anlage fälschlich Ghost-Diff; §5.9 Pkt. 5 vs. §3 Pkt. 2 „betroffene bestehende Concepts"). Empfohlene Lösung (P1): Probe = git diff --name-only <Baseline-Commit> -- wiki/ + git status --porcelain -- wiki/, fixiert VOR dem Commit (im P2-Block), erlaubte Menge = Kandidatenliste ∪ Neu-Anlage-Zielpfade (§5.1/§5.7) ∪ log.md ∪ index.md; Ausgabe-Pfade normalisieren (Stripping wiki/-Präfix + .md). Resolution (Nutzer 1/1, 2026-08-19, Option 1 — empfohlen): wie Empfohlene Lösung umgesetzt (Baseline + porcelain + Neu-Anlage + Normalisierung, Pre-Commit-Zeitpunkt).
• [Review][Decision] D-2: R-1-Baseline deterministisch auflösbar machen + Abweichungsregel — „HEAD der vorherigen Mutations-Boundary" (Rev-2.4.1-F12) ist ohne Lauf-State-Record nicht deterministisch feststellbar (AD-14: Git liefert Historie, nicht Domain-State; log.md ist Dokumentation, kein State); der Claim „derselbe Baseline-Commit wie Pkt. 5" ist faktisch falsch (Pkt.-5-Probe hat kein Commit-Argument); bei git-diff ↔ SHA-256-Record-Diskrepanz ist die Ergebnis-Regel undefiniert. Empfohlene Lösung (P2): Baseline-Commit wird vom Producer im wiki/log.md-Run-Eintrag notiert; bei Diskrepanz gewinnt git diff (Commit-Boundary = Mutations-Boundary), SHA-256 bleibt Sekundär-Fingerprint; Fallback für Workspace ohne vorherige Mutations-Boundary definieren (alles als Zuwachs). Resolution (Nutzer 1/1, 2026-08-19, Option 1 — empfohlen): Baseline-Commit wird vom Producer im wiki/log.md-Run-Eintrag notiert; bei Diskrepanz gewinnt git diff; SHA-256 = Sekundär-Fingerprint; Fallback „alles als Zuwachs".
• [Review][Decision] D-3: INPUT_UNCOMMITTED-Abbruch implementieren + Anker-Divergenz dokumentieren — das gefrorene I/O-Matrix-Szenario verlangt den textuell benannten Abbruch „published/committed Input erforderlich"; implementiert ist nur die Referenz auf §1 Pkt. 1 (keine Zustandsprüfung, keine Abbruchmeldung, kein Test, kein Defer). Die gefrorene Spec zitiert 3× „§1.1" (Zeilen 26/42/74), das in schema/compiler.md nicht existiert (§1 ist eine nummerierte Liste Pkt. 1–4) — Rev-2.4.1 korrigierte nur die Anker in compiler.md. Empfohlene Lösung (P3): Input-Zustandsprüfung (Working-Copy vs. HEAD für raw/ + wiki/) als P2-Check-Block-Element mit genanntem Abbruch; die Spec↔Anker-Divergenz als dokumentierte Fußnote (Rev-Log + log.md), da die Spec frozen bleibt. Resolution (Nutzer 1/1, 2026-08-19, Option 1 — empfohlen): Input-Zustandsprüfung (Working-Copy vs. HEAD für raw/ + wiki/) als P2-Check-Block-Element mit genanntem Abbruch; Anker-Divergenz als dokumentierte Fußnote (Rev-Log + log.md).
• [Review][Decision] D-4: Sandbox-Edge-Test-Nachweis als hängenden Zeiger heilen — wiki/log.md:4 und deferred-work.md behaupten „deterministische Formel-Ausgaben je Szenario in der Spec-Verification", aber die ## Verification-Sektion der Spec enthält keine Szenario-Ausgaben (keine Sandbox-Bäume, keine Befehle, keine ausgeführten Outputs; repo-weit existiert kein Execution-Record für die fünf Szenarionyme, nur frozen Matrix + Tasks + Prosa). Repo-Idiom (spec-2-1 „Verification Record (Ausführungs-Beleg)", spec-2-5 Pkt. 1) liefert die Vorlage. Empfohlene Lösung (P4): fünf synthetische Sandbox-Bäume (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) ausführen, echte Ausgaben als „Verification Record (Ausführungs-Beleg)" in die (nicht gefrorene) ## Verification schreiben, log.md/deferred-work.md-Zeile darauf zeigen. Resolution (Nutzer 1/1, 2026-08-19, Option 1 — empfohlen): volle Sandbox-Execution der fünf I/O-Matrix-Szenarien; echte Ausgaben als „Verification Record (Ausführungs-Beleg)" in die nicht gefrorene ## Verification.

Patch:

• [Review][Patch] Worked Example §5.9 Pkt. 7 nicht reproduzierbar: rg -l 'FR-12' wiki/ trifft am Ist-Baum wiki/knowledge-kompilation-inkrementell.md + wiki/log.md, NICHT wiki/wissensarchitektur/source-material.md (dort 0 Treffer) — das „an die reale Ist-Lage gebundene" Example reproduziert sich nicht [schema/compiler.md:259]
• [Review][Patch] P2-Check-Block-Zeitpunkt widersprüchlich: „einmal pro Run führend an der Spitze erhoben", aber die Kandidatenliste entsteht erst im Reconcile — Block muss nach Reconcile, an der Spitze von Mutieren, durchlaufen werden [schema/compiler.md:258]
• [Review][Patch] Stale-Anker „§3.2-Kollisionsprüfung" — §3 ist eine nummerierte Liste (Pkt. 1/2/3), §3.2 existiert nicht [schema/compiler.md:42]
• [Review][Patch] Stale-Referenz „§3-Voraussetzungsprüfung" (P2-Block Pkt. 4 zitiert §3 Pkt. 3 und diese Pseudo-Sektion doppelnd) [schema/compiler.md:258]
• [Review][Patch] §5.8 Pkt. 3: Zeiger „die in Pkt. 1 als offen notierte Punkt-11-Grenze" — die Lücken-Notiz stand in Pkt. 2 [schema/compiler.md:232]
• [Review][Patch] Befehls-/Ausgabe-Inkonsistenz der Diff-Selbsttest-Belege: wiki/log.md:4 (b) zitiert git diff --stat -- wiki/ (Rev-2.4.1: „statt --stat" umgestellt), deferred-work.md notiert den --name-only-Befehl mit --stat-stiler Ausgabe („1 Insertion") [wiki/log.md:4; _bmad-output/implementation-artifacts/deferred-work.md:172]
• [Review][Patch] Log-Eintrag dokumentiert „Revision 2.4", der Commit enthält 2.4 + 2.4.1; die Step-04-Review-Patch-Runde und in-progress → review sind nur implizit (sprint-status-Zweizeitstempel) [wiki/log.md:4]
• [Review][Patch] F17-Defer-Eintrag: kein source_spec-Feld (Schemaabweichung zu allen anderen Einträgen), „Executive spiegelt" = undefinierter Akteur in D-3-Semantik, „Nutzer-Entscheidung 1/1 (Story 3.2)" referenziert eine nicht existierende Story (3.2 ist backlog) [_bmad-output/implementation-artifacts/deferred-work.md:177-179]
• [Review][Patch] No-Op-Kandidat (Kandidat mit null substantiellem Delta) undefiniert: Mutation/at-Bump/log.md-Eintrag? — Spurious-Churn vs. verpasste Pflichteintrag; zusätzlich: Konsolidierungsreihenfolge nur für „vollständig unabhängige" Einheiten definiert (lexicografisch), partiell-abhängige haben keine Regel (AD-17h) [schema/compiler.md:241-248]
• [Review][Patch] Update-Pfad-Rollback undefiniert: §5.3/§6.3 definieren Teilzustand-Rollback nur für neue Dateien („gelöscht, Index entfernt, log.md-Eintrag entfernt"); für modifizierte bestehende Concepts fehlt die Rücksetzregel (Validierungs-FAIL im Update-Pfad) [schema/compiler.md:265-266]
• [Review][Patch] generated.at = Wanduhr-Zeitstempel kollidiert mit AD-17h-Determinismus (zwei unabhängige Runs, gleicher Input → verschiedene at-Werte → verschiedene Bundle-States); P1-Konvention heilt nur Drift innerhalb eines Runs — die Lücke ist weder in §5.9 noch in deferred-work.md als Gap benannt (Story-3.8-Anker) [schema/compiler.md:246]
• [Review][Patch] Term-Ableitung für die Kandidatenerhebung (a) rg -l '<konzeptterm>' wiki/ nicht deterministisch: welcher Term, welche Normalisierung, Case-Sensitivity, mehrere Terme pro Einheit? — ist Interpretationsentscheidung (genau das, was AD-13 für Auswahl ausschließt); Story-3.2-Vorbehalt ist nur für den „feinkörnigen Mechanismus" formuliert, nicht für die Term-Ableitung [schema/compiler.md:41]
• [Review][Patch] Probe-Ausgabe-Pfade nicht normiert: git diff --name-only liefert wiki/-Präfix + .md; die Kandidatenliste ist definiert als „relative OKF-Pfade ohne .md" — die Teilmenge-Vergleichsoperation ist nicht definiert (Stripping-Regel fehlt) [schema/compiler.md:255]
• [Review][Patch] Fallback fehlt: kein vorheriger Mutations-Boundary-Commit vorhanden (frischer Workspace) → <Baseline-Commit> für R-1 Change-Detection nicht auflösbar [schema/compiler.md:257]
• [Review][Patch] Link-Following (Kandidatenerhebung (c)) ohne visited-set/Tiefen-Schranke — zyklische Concept-Links → unendliche Traversal / unbeschränkte Kandidatenmenge [schema/compiler.md:41]
• [Review][Patch] Ghost-Diff-Rollback-Mechanik nicht spezifiziert: „rollt den Ghost-Diff zurück" ist Prozess-Beschreibung ohne Mechanismus (welcher Befehl? git restore? §5.3-Sequenz?); für D-3/AD-17h muss die Rücksetz-Aktion deterministisch beschreibbar sein [schema/compiler.md:255]

Defer (vorbestehend, nicht von Story 3.1 verursacht):

• [Review][Defer] V-1-Cross-Referenz dreistufig (compiler §3 Pkt. 3 / Validator-Voraussetzungsprüfung / Vertrag §2) und nie explizit aufgelöst — bestehendes Referenz-Idiom der Instruktion [schema/compiler.md:258] — deferred, pre-existing
• [Review][Defer] epic-3-context.md ist ein neues Artefakt außerhalb der Spec-Code-Map, nirgends referenziert/dokumentiert (log.md/deferred-work) — Kontext-Datei wird vom build-Verfahren erzeugt, keine Story-Inhalts-Mutation [_bmad-output/implementation-artifacts/epic-3-context.md] — deferred, pre-existing

Spec Change Log

• 2026-08-19 (bmad-code-review Loop 2 — Resolution & Patch-Runde): 4 decision-needed per Nutzer-Entscheidung 1/1/1/1 aufgelöst (D-1 Probe-Befestigung + Neu-Anlage + Normalisierung; D-2 Baseline-Commit-Notiz + Diskrepanz-Regel + Fallback; D-3 INPUT_UNCOMMITTED-Abbruch als P2-Element + Anker-Divergenz-Fußnote; D-4 Sandbox-Execution + Verification Record); 16 patch umgesetzt — schema/compiler.md → Revision 2.4.2 (Diff-Selbsttest operationalisiert, R-1-Baseline + Abweichungsregel, P2-Block um Input-Zustand + Zeitpunkt, No-Op-Kandidat, Mehrfach-Treffer-Reihenfolge, Update-Pfad-Rollback §5.3, AD-17h-Gap benannt, Term-Ableitung abgegrenzt, visited-set, Worked Example korrigiert, stale-Anker nachgeführt) + wiki/log.md (2026-08-19-Eintrag: Befund-Befehlsform korrigiert, Rev 2.4.1/2.4.2 + Review-Handoff dokumentiert, Sandbox-Zeiger auflösbar, Baseline-Commit-Konvention) + deferred-work.md (F17-Eintrag: source_spec + Akteurskorrektur + Story-3.2-Referenz behoben; VG-Beleg: Befehls-/Ausgabe-Form korrigiert, Zeiger auf diesen Verification Record); 2 defer in deferred-work.md verankert; 6 dismissed (s. Review Findings-Einleitung); ## Verification Record (Ausführungs-Beleg) angehängt (re-executierbares Sandbox-Skript + echte Outputs, S1–S5 I/O-Matrix + S6 D-3-Kontrolle); Frontmatter review_loop_iteration → 2; sprint-status.yaml: 3-1-… → done, last_updated 08-19-2026.
• 2026-08-19 (bmad-code-review Loop 2): Review Findings-Sektion angehängt (4 decision-needed, 16 patch, 2 defer, 6 dismissed als Noise — u. a.: Key-Abkürzungs-Muster in sprint-status ist Projekt-Schema, Chronologie „Review-Ergebnis im selben Commit wie Review-Handoff" ist prozedural korrekt, Validator-7/7-Lauf gilt für Endzustand inkl. Append, AA-Teilbehauptung „Hold-String überlebt in Rev-1.4-Log" ist am Ist-Baum widerlegt — grep liefert keinen Treffer).
• 2026-08-18 (Erstellung): Initiale Approve-Baseline.

Design Notes

Warum §5.9 als eigene Sektion statt Umbau von §5: Die 5.x-Sektionen sind die nachgelagerten Spezifikations-Ebenen der Mutationsphase (§5.5 Claim-Provenienz, §5.6 Links, §5.7 Bereichszuordnung, §5.8 Discovery). Das inkrementelle Update ist die nächste Spezifikations-Ebene desselben §5 (Mutieren) — konsistent als §5.9, verortet nach §5.8 vor §6. Der bestehende §3-Reconcile wird nicht umgeschrieben, sondern seine Pkt.-2-Ausnahme („Aktualisierung ist Epic 3") durch das Update-Routing ersetzt — der Kollisions-Hold-Teil („nicht stumm überschreiben") bleibt als Schutzprinzip erhalten und wird lediglich um den Update-Ausweg ergänzt.

Erhaltungs-Invariante als Diff-Selbsttest: Die Inkrementalität ist nur dann AD-17h-fest belegbar, wenn sie mechanisch kontrollierbar ist. Konvention: Nach jedem Run prüft der Producer über git diff --stat -- wiki/ (bzw. git status --porcelain), dass die geänderten Dateien ⊆ (betroffene Concepts ∪ log.md ∪ nachgeführte index.md) sind. Eine Abweichung (Ghost-Diff) ist ein Instruktions-Verstoß (FT-6) und wird textuell benannt. Für Story 3.1 selbst (Instruktions-Story ohne Inhalts-Mutation) ist der Nachweis: Ist-Baum zeigt keinen neuen Ghost-Diff nach dem Instruktions-Ergänzungs-Commit.

generated.at-Konvention bei Updates (A0-20): Ein maschinelles Update eines maschinell erzeugten Concepts bleibt maschinell → generated bleibt gesetzt, at wird auf den aktuellen Run-Zeitstempel aktualisiert (einmalige at-Festlegung pro Run, Dryrun-P1-Konvention). verified wird durch ein maschinelles Update nicht gesetzt und ein vorhandenes human-verified wird nicht entfernt (menschliche Kuratierung ist Bestandswissen, A0-21/FR-13-Nähe). Ein menschliches Update ändert generated/verified nicht automatisch.

Defer-Bausteine inside der Run-Vorphase: Defer R-1 (Change-Detection) beantwortet „welche raw/-Dateien sind Zuwachs" — als textueller Check-Block vor der Interpretation (git-diff-basiert und/oder SHA-256-Record aus source.md); Defer P2 bündelt die bestehenden textuellen Vorprüfungen (Zielpfad, Quellen-Existenz EC-1 via Validator-Punkt, Reconcile-Kandidaten-Erhebung, V-1) zu einem wiederverwendbaren Pre-Run-Reconcile-Check-Block. Beide sind keine neuen Prozesse — nur reproduzierbare Check-Blöcke innerhalb der Instruktions-Ausführung (D-3).

Verification

Commands (re-executierbar, ab Workspace-Root):

1. Instruktions-Integrität: grep -n "5.9" schema/compiler.md liefert die neue Sektion; grep -n "Aktualisierung ist Epic 3" schema/compiler.md liefert keinen Treffer mehr (Hold durch Update-Routing ersetzt); §7-Vorbehalt enthält „Update" nicht mehr.
2. Diff-Selbsttest (Erhaltungs-Invariante): vor dem Story-Commit den Ist-Baum-Status aufzeichnen, nach dem Commit git diff --stat -- wiki/ prüfen — erwartet: nur die von Story 3.1 berührten Dateien (log.md, ggf. index.md) bzw. nach dem Instruktions-Commit der Story selbst kein weiterer Ghost-Diff; auf dem Sandbox-Baum: HAPPY_PATH_UPDATE zeigt ausschließlich betroffene Datei + log.md + Index.
3. Validator-Lauf: alle wiki/-Dateien SUCCESS (unverändert zur Story 2.5; der Validator ist eine reine Text-Instruktion, human-mechanisch ausgeführt, D-3 — es gibt keinen CLI-Invoker); das per-Datei-Verdikt wird als Ausführungs-Nachweis im log.md-Eintrag geführt.

Manual checks:

• §3-Pkt.-2-Hold ersetzt (Update-Routing) und §5.9 vorhanden (Update-Semantik, Diff-Selbsttest, R-1/P2-Bausteine); compiler.md §8-Revision 2.4 mit Abschlussklausel; kein schema/validator.md-/schema/wiki-compiler.md-/raw/-Diff; §7-Vorbehalt gekürzt; wiki/log.md-Eintrag datiert mit Story-3.1-Semantik, Diff-Selbsttest-Beleg, Statuswechsel backlog → in-progress, per-Datei-Verdikt; deferred-work.md-R-1-/P2-Einträge als aufgegriffen markiert (append-only); sprint-status.yaml konsistent (3-1-… → in-progress).

Verification Record (Ausführungs-Beleg, 2026-08-19 — bmad-code-review Loop 2, D-4-Resolution)

Re-executierbar: bash _bmad-output/implementation-artifacts/sandbox-3-1/run-sandbox.sh (ab Workspace-Root; Git-Bash; Sandbox-Bäume unter /tmp/sb31-XXXXXX, reiner Test-Baum — nie der reale wiki/-Bundle; kein Carry-over über Szenarien via isolate(): Branch auf Baseline + git reset --hard + git clean). Das Skript setzt das compiler.md-§5.9-Update-Szenario auf einem synthetischen Basis-Baum (wiki/index.md + alpha.md + beta.md + log.md, raw/alpha-v1.md + raw/beta-v1.md, committer Baseline) gegen die fünf I/O-Matrix-Szenarien + die D-3-Abbruch-Kontrolle durch. Die Probe-Funktion implementiert die D-1-Probe wörtlich: { git diff --name-only <BASE> -- wiki/ ; git status --porcelain -- wiki/ | awk '{print $2}' } → Normalisierung (Strip wiki/-Präfix + .md-Suffix, LC_ALL=C sort -u).

Baseline-Commit (Sandbox-Baum, reiner Test-Baum): f7335a3f4f98aafcbb1294bc8a4ba5ca76db143a

S1 — HAPPY_PATH_UPDATE (Zuwachs raw/alpha-v2.md mit Term-Ueberschneidung quanten-protocol-schlüssel; Mutation im bestehenden Pfad wiki/alpha.md + log.md):

--- Kandidaten-Erhebung: rg -l 'quanten-protocol-schlüssel' wiki/ ---
wiki/alpha.md
--- Probe (git diff --name-only <BASE> -- wiki/ + git status --porcelain -- wiki/, normalisiert) ---
alpha
log
--- Erwartet: log, alpha (betroffen); beta NICHT; keine neue Datei (porcelain o.??) ---
 M wiki/alpha.md
 M wiki/log.md
--- Duplikat-Check: existiert alpha.md weiterhin exakt 1x? ---
wiki/alpha.md
0
0 untracked

→ Probe ⊆ erlaubte Menge (alpha betroffen, log = log.md; beta NICHT; keine ungetrackte Datei = kein Duplikat). FT-6/FR-12 erfüllt.

S2 — UNTOUCHED_CONCEPT (Zuwachs raw/gamma.md, Term gamma-observatorium-thema; kein Kandidat, keine Mutation):

--- Kandidaten-Erhebung: rg -l 'gamma-observatorium-thema' wiki/ ---
(leer — kein Kandidat)
--- Folge: keine Mutation, kein log.md-Zusatz (UNTOUCHED_CONCEPT) ---
--- Probe ---
(leere Ausgabe = kein Ghost-Diff; leere Menge ist Teilmenge jeder erlaubten Menge)

→ Konzept bleibt unverändert (keine Dateiänderung, kein Index-, kein log.md-Zusatz).

S3 — CONCEPT_COLLISION_BESTEHEND (Zielpfad wiki/alpha.md belegt → Update-Routing):

--- Vor-Mutation-Check: Ziel-Pfad wiki/alpha.md belegt? ---
JA — Update-Routing (kein Duplikat, kein stummer Ueberschreiben)
--- Vor-Mutation-Zustand (muss leer sein) ---
(leer)
--- Mutation im bestehenden Pfad (Update) ---
--- Nach-Mutation: nur M-Eintraege, KEIN ?? (keine neue Datei = kein Duplikat) ---
 M wiki/alpha.md
 M wiki/log.md
--- Probe ---
alpha
log

→ Statt Kollision-Hold: Mutation im bestehenden Pfad; nur M-Einträge, kein ?? (keine neue Datei = kein Duplikat); Index-Link unverändert gültig.

S4 — CHANGE_DETECTION (R-1) (Zuwachs raw/alpha-v2.md; alpha-v1.md/beta-v1.md unverändert):

--- git diff --name-only <BASE> -- raw/ ---
raw/alpha-v2.md
--- Erwartet: AUSSCHLIESSLICH raw/alpha-v2.md (alpha-v1.md/beta-v1.md bleiben aussen) ---
--- SHA-256-Abgleich (Sekundaer-Fingerprint, D-2): alpha-v1 unveraendert? ---
21e7fc1dd09baa0d3fed56bf36e7eba19b1b3376f236b79ecbce8a907761b50b *raw/alpha-v1.md
21e7fc1dd09baa0d3fed56bf36e7eba19b1b3376f236b79ecbce8a907761b50b *-
--- (identische Summen = unveraendert; bei Diskrepanz gewinnt git diff, D-2) ---

→ Nur die neue Datei wird als Zuwachs interpretiert (git-diff-basiert); unveränderte bleiben außen vor; SHA-256-Record bestätigt (identische Summen), Sekundär-Fingerprint gemäß D-2-Diskrepanz-Regel.

S5 — PRE_RUN_RECONCILE (P2) (Setup: wiki/index.md fehlt → fehlende Bundleroot):

--- Check-Block: (4) wiki/index.md-V-1-Vorbedingung ---
Run-FAIL (V-1, Vertrag §2): wiki/index.md fehlt — keine Mutation darf erfolgen
--- Zustand nach Abbruch + Rueckstellung (muss leer sein — der Run selbst mutierte nichts) ---
(leer)

→ Pre-Run-Reconcile-Check-Block durchlaufen vor jeder Mutation; fehlende Bundleroot → Run-FAIL (V-1, besteht fort); der Run mutierte nichts (Zustand nach Abbruch leer; die Rückstellung ist Setup, kein Run-Zustand).

S6 — INPUT_UNCOMMITTED (D-3-Abbruch-Kontrolle) (Setup: raw/alpha-v1.md im Working-Copy abweichend von HEAD):

--- Check-Block: Working-Copy vs. HEAD fuer raw/ + wiki/ ---
Abbruch: published/committed Input erforderlich (AD-17a) — ungepublishter Zustand:
 M raw/alpha-v1.md

→ P2-Check-Block-Element (1) Input-Zustand: Working-Copy von raw/+wiki/ gegen HEAD; bei Abweichung benannter Abbruch „published/committed Input erforderlich" vor Interpretation und vor jeder Mutation — die gefrorene I/O-Matrix-Verpflichtung (Szenario INPUT_UNCOMMITTED) ist jetzt als Check-Block-Element in schema/compiler.md §5.9 Pkt. 6 (1) implementiert (Rev 2.4.2, D-3-Resolution).

Gesamtergebnis: Alle 5 I/O-Matrix-Szenarien + die D-3-Abbruch-Kontrolle deterministisch ausgeführt — keine Abweichung vom Erwartungsverhalten; die wiki/log.md- und deferred-work.md-Verweise auf „deterministische Formel-Ausgaben/Nachweise je Szenario in der Spec-Verification" sind damit auflösbar (D-4).

Suggested Review Order

Inkrementeller Datenfluss — Update-Routing (Einstieg)

• §3 Reconcile: Kollision-Hold durch Update-Routing ersetzt — der architektonische Kern der Story compiler.md:40

• Textuell-deterministische Kandidatenliste (AD-13) als Update-Stimulus compiler.md:41

• §0-Aufruf: sechs Phasen für Neu-Anlage- und Update-Variante präzisiert compiler.md:13

§5.9 Update-Mutationsmechanik (neue Sektion)

• §5.9-Überblick: einziger Instruktions-Ort der Update-Mutationsmechanik (D-3) compiler.md:236

• Update-Stimulus: Kandidatenliste, published/committed-Input (§1 Pkt. 1, AD-17a) compiler.md:240

• Mutationsmechanik: Erweitern/Präzisieren/Korrigieren + Mehrfach-Treffer-Konsolidierung compiler.md:242

• Index-/Link-Form unverändert (§5.6-Pin); log.md-Eintragspflicht bleibt davon unberührt compiler.md:249

• Worked Example an den realen Ist-Baum gebunden (FR-12, kein Ghost-Diff) compiler.md:259

Erhaltungs-Invariante & Diff-Selbsttest (Review-Patch-Kern)

• Diff-Selbsttest operationalisiert: git diff --name-only -- wiki/ ⊆ Kandidatenliste ∪ log.md ∪ Index compiler.md:251

• Run-Vorphase-Bausteine: Change-Detection (R-1, Baseline = HEAD der vorherigen Mutations-Boundary) + Pre-Run-Reconcile-Check-Block (P2) compiler.md:255

• Revisionslog 2.4.1: Review-Patch-Runde mit Abschlussklausel (AD-3/D-3 gehalten) compiler.md:348

Referenz-Abgrenzung §5.7/§5.8

• §5.7 Pkt. 3: Top-Level-Kollision → Update-Routing, kein MOVE compiler.md:199

• §5.8 Pkt. 2: Rev-9-Punkt-11-Area-Lesart als geschlossene Lücke dokumentiert compiler.md:231

• §5.8 Pkt. 3: §5.8-Hold bewusst nicht das Update-Routing (Zwei-Ebenen-Kartografie) compiler.md:232

Nachweise (Log, Deferred-Work, Sprint-Status)

• wiki/log.md: Story-3.1-Nachweis mit Diff-Selbsttest-Beleg und Rev-9-Präzisierung log.md:4

• deferred-work.md: R-1 (Change-Detection) und P2 (Pre-Run-Reconcile) als aufgegriffen markiert deferred-work.md:129

• Review-Findings-Protokoll (VG-Nachweis, F9/F12, F17-Defer als Folge-Aufgabe) deferred-work.md:164

• sprint-status.yaml: Story 3.1 in-progress (Sprint-Sync konsistent) sprint-status.yaml:54