feat: Story 3.3 Review-Loop-1-Patches (bmad-code-review, 3 Layer; kein Loopback) — Präzedenz-Reihenfolge Korrigieren→Präzisieren→Erweitern→No-Op (AD-17h), No-Op als Nicht-Form, Korrigieren-Original-Wortlaut-Erhaltung; Sandbox U1–U9 (U8/U9 Negativ-Kontrollen, volle byte-Identität, reelle S-N-Anker, -eq 1-Konsolidierung, Frontmatter-Reihenfolge/Duplikat); 5 Defers → deferred-work.md; Spec done + Suggested Review Order; Story done

Co-Authored-By: Claude <noreply@anthropic.com>

schema/compiler.md

@@ -267,6 +267,11 @@ Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik
    - **No-Op-Kandidat (Review-Loop-2-Präzisierung):** Erhebt die Kandidatenerhebung einen Pfad, dessen Body die neue Evidenz **bereits vollständig enthält** (keiner der drei Update-Formen greift — keine neue belegte Aussage, keine Schärferung, keine Ersetzung), ist der Kandidat ein **No-Op**: **keine** Body-Mutation, **kein** `generated.at`-Bump, **kein** `sources`-Zusatz, **kein** `log.md`-Eintrag — der Pfad bleibt byte-identisch (Erhaltungs-Invariante, Pkt. 5). Die Entscheidung „keiner der drei Formata greift" ist selbst textuell deterministisch: sie trifft nur, wenn die neue Evidenz keine Aussage trägt, die im Body nicht bereits als belegte Aussage vorhanden ist (Term-/Stellen-Abgleich mit §5.5-Inline-Verweisen); im Zweifel (neue belegte Aussage auch nur in abgewandelter Form) greift Erweitern/Präzisieren — der No-Op ist die *engere* Auslegung.
    - **Mehrfach-Treffer-Konsolidierung (ein Run, mehrere Einheiten auf denselben Concept-Pfad):** Ergeben mehrere neue Wissenseinheiten desselben Runs auf **demselben** bestehenden Concept-Pfad ein Update, werden ihre Mutationen in **einem einzigen Update dieses Pfads** konsolidiert (eine Body-Änderung, **ein** `log.md`-Eintrag „Story 3.1-Update", ein konsolidierter `sources`-Zuwachs, **ein** `generated.at`-Zeitstempel — der einmalige `at` des Runs). Die Reihenfolge der Einheiten wird dabei textual-deterministisch aus der Verarbeitung der Evidenz abgeleitet: REIHENFOLGE = **Auftritt der Einheiten in der Zuwachs-Sicht** (Datei-Reihenfolge des R-1-Zuwachsbefunds, dann Stellen-Reihenfolge innerhalb der Datei); nur bei Einheiten desselben Ortes (identischer Dateipfad + identische Stelle) greift die lexicografische Ordnung als Tie-Break (Review-Loop-2-Präzisierung: die Reihenfolge ist für *alle* Einheiten definiert, nicht nur für vollständig unabhängige). Die AD-16-Default-Erhaltung bleibt für jede betroffene Stelle gewahrt.
    - **Commit-Boundary = Mutations-Boundary (AD-17f, §0):** Auch im Update-Pfad werden **Zwischenstände nie als fertige Mutation veröffentlicht** — die Mutationen der Update-Kandidaten werden als Ganzes committet, und zwar erst, nachdem der Diff-Selbsttest (Pkt. 5) ohne Ghost-Diff abgeschlossen ist. Ein Ghost-Diff ist dann als **Abbruch-Vorlauf „korrigierter Teil-Run"** im `log.md`-Eintrag des betroffenen Runs gekoppelt (siehe Disagreement-/Run-Notiz Pkt. 4), damit die Ursache textuell nachvollziehbar bleibt.
+   - **Operationelle Ausführungs-Ebene je Update-Form (Präzisierungsebene, Story 3.3 / Revision 2.8; Präzisierung des frozen Story-3.1-Regeltexts, keine Re-Negotiation — die operationellen Regeln sind die deterministische Brücke Regel → Run, AD-17h/A0-19):** Die folgenden Ausführungs-Regeln präzisieren, **was der Producer bei jedem Form-Fall konkret tut und was er unangetastet lässt**. Je Update-Form gelten (a) das **Abgrenzungskriterium** (Welche Form greift wann? — ausschließlich aus der committeten Evidenz abgeleitet), (b) die **Struktur-Erhaltungsregel** (was bleibt unverändert — die „Struktur" aus FR-6/AC-2: Frontmatter-Subset, bestehende belegte Aussagen mit §5.5-Inline-Verweisen, §5.6-Pin) und (c) der **Textgenauigkeits-Rahmen** (wie geschärft wird). **No-Op ist keine eigene Form, sondern die Nicht-Form** (keiner der drei Form-Bullets greift) mit eigenem Abgrenzungskriterium und der Erhaltungsregel „volle Byte-Identität". **Abgrenzungs-Reihenfolge (Prozess, AD-17h):** Der Producer prüft die Abgrenzungskriterien **in fester Reihenfolge Korrigieren → Präzisieren → Erweitern → No-Op** (strikt pro Evidenz-Einheit) und wählt die **erste zutreffende** Form: (1) ersetzt die Evidenz eine bestehende belegte Aussage als fehlerhaft/überholt → **Korrigieren**; (2) sonst schärft sie eine bestehende Formulierung/Abgrenzung (ersetzte Wortlautfolge → Ersetzungsbeleg nötig) → **Präzisieren**; (3) sonst trägt sie eine neue belegte Aussage, die noch nicht existiert → **Erweitern**; (4) sonst → **No-Op** (engere Auslegung). Damit ist jeder Einheit genau eine Form zugeordnet (kein Form-Überlapp, gleiche Evidenz → gleiche Form). Gleicher Git-State + gleiche Eingabemenge → identischer Update-Vorgang (AD-17h); der `generated.at`-Wanduhr-Gap (gleiches Eingabeset, unabhängige Runs, verschiedene `at`) bleibt offene A0-20-Konvention mit Home **Story 3.8** (oben, `generated.at`-Konvention) — unverändert bindend.
+     - **Korrigieren — Abgrenzungskriterium:** greift genau dann, wenn die Evidenz eine bestehende Aussage als **fehlerhaft/überholt ersetzt** (ersetzte Wortlautfolge liegt vor → Ersetzungsbeleg nötig). **Struktur-Erhaltungsregel (Korrigieren):** die ersetzte Aussage wird **nicht still gelöscht**, sondern explizit durch die ersetzende Aussage **abgelöst**; die Ersetzung trägt den **Ersetzungsbeleg** (§5.5, AD-16-Default Erhaltung); die Ablösung erfolgt an der Position der ersetzten Aussage — dabei bleibt die Aussage **in ihrer ursprünglichen Wortlautfolge als abgelöster Bestand** erhalten (die Beleg-Kennung bleibt gültig, nur die Aussage-Fortschreibung wechselt), der Rest des Bodys bleibt unverändert. **Textgenauigkeits-Rahmen (Korrigieren):** nur die fehlerhafte/überholte Aussage wird ersetzt; keine flankierende Umschreibung.
+     - **Präzisieren — Abgrenzungskriterium:** greift genau dann, wenn die Evidenz eine **bestehende Formulierung/Abgrenzung schärft** (präzisierende Information an derselben Aussage, ohne Ersatz). **Struktur-Erhaltungsregel (Präzisieren):** die geschärfte Aussage bleibt an ihrer **Position**, das Satzgefüge wird **nicht umgebaut**, umgebende Aussagen, §5.5-Inline-Verweise anderer Aussagen und die §5.6-Linkform bleiben unverändert; der Beleg wird bei der Aussage neu/nachgeführt (§5.5). **Textgenauigkeits-Rahmen (Präzisieren):** Schärfen = Formulierung/Abgrenzung **an der Aussage selbst**; **kein Satz-Umbau** (keine Neustrukturierung des Absatzes), **kein Neuschreiben ohne Ersetzungsbeleg** — jede ersetzte Formulierung braucht die neue/fortgeführte `raw/`-Evidenz als Inline-Verweis.
+     - **Erweitern — Abgrenzungskriterium:** greift dann, wenn die neue committete Evidenz eine **neue belegte Aussage** trägt, die im bestehenden Body **nicht** existiert (Term-/Stellen-Abgleich gegen die §5.5-Inline-Verweise; kein bestehender Anker). **Struktur-Erhaltungsregel (Erweitern):** die neue Aussage wird als **eigener Absatz angefügt** (Body-Ende); bestehende belegte Aussagen bleiben **byte-identisch**, keine Umschreibung bestehender Absätze; Frontmatter nur `sources`-**Zuwachs um den echten neuen Beleg** + ein `generated.at`-Bump. **Textgenauigkeits-Rahmen (Erweitern):** die neue Aussage wird eigenständig formuliert, trägt den §5.5-Inline-Beleg mit existierender Stellen-Kennung; kein Satz-Umbau des Bestands. *(Überlappt eine Einheit mehrere Formen — z. B. sie trägt zugleich eine neue belegte Aussage und eine Schärfung einer bestehenden —, ordnet der Producer die Einheit der in der Abgrenzungs-Reihenfolge ersten zutreffenden Form zu (deterministisch, AD-17h); die Textgenauigkeits-Rahmen der übrigen Formen gelten für die jeweiligen Teilbestandteile unverändert.)*
+     - **No-Op — Abgrenzungskriterium (Nicht-Form, engere Auslegung, bestehende Regel oben):** greift nur, wenn **keine** der drei Formen greift (die Evidenz ist bereits vollständig im Body); im Zweifel trifft eine der drei Formen — die Entscheidung ist textuell deterministisch (Term-/Stellen-Abgleich). **Erhaltungsregel (No-Op):** volle Byte-Identität (keine Mutation, kein `at`-Bump, kein `sources`-Zusatz, kein `log.md`-Eintrag).
 3. **Index-/Link-Form unverändert (§5.6-Pin):** Ein reines Body-Update ändert die Concept-Identität nicht → der bestehende Index-Link (Bundleroot oder Area-`index.md`) bleibt unverändert gültig; **kein neuer Link** bei reinem Body-Update (kein Index-`index.md`-Zusatz). Die **`log.md`-Eintragspflicht** (Pkt. 4) bleibt davon **unberührt**: *jedes* Update — auch ein reines Body-Update — MUSS seinen `log.md`-Eintrag „Story 3.1-Update" führen; nur der **Index-**Link bleibt unverändert. Wird durch das Update eine Concept-Kategorie (Root vs. Area) oder die Identität berührt, ist das **Ask-First** (AD-7d-Renames/Redirects; nicht Teil von Story 3.1). Neue zulässige Concept-Links (Beziehungsschicht, §5.6) werden nur gesetzt, wenn die neue Erkenntnis eine echte, inhaltsbegründete Beziehung rechtfertigt.
 4. **`log.md`-Eintragspflicht (Vertrag §5):** Jedes Update wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (Header = ISO-Datum `YYYY-MM-DD`, neueste zuerst), verknüpft mit dem mutierten Concept-Pfad und den genutzten `raw/`-Quellen. Für Updates wird der Eintrag als „**Story 3.1-Update**" markiert (disambiguierbar von Anlage-Einträgen). Konflikt-/Erhaltungsfälle (Pkt. 2 „Korrigieren" ohne Ersetzungsevidenz) werden explizit als Disagreement-Eintrag mit dem mutierten Concept-Pfad geführt (AD-16b, Vertrag §5) — der Epic-4-Interface-Fall bleibt dokumentiert, ohne Korrektur-Klassifikation hier.
 5. **Erhaltungs-Invariante (Kern) + deterministischer Diff-Selbsttest (AD-17h, FT-6/FR-12):** Ein Compilation Run darf nur die Concepts **neu anlegen oder verändern**, die durch den erkannten Erkenntnis-Zuwachs tatsächlich betroffen sind. **Nicht betroffene Concept-Pfade bleiben byte-identisch unverändert** — es gibt **nie** „Regenerate Everything" (AD-5, A0-6). Die Inkrementalität ist als **re-executierbarer Diff-Selbsttest** mechanisch kontrollierbar: Nach jedem Run prüft der Producer ab der Workspace-Root
@@ -276,9 +281,10 @@ Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik
    ```
    (erste Zeile: modifizierte/gelöschte Pfade gegen die Baseline; zweite Zeile: zusätzlich ungetrackte neue Pfade `??` und staged-Änderungen — die Duplikat-Kontrolle „keine neue Datei" braucht die `??`-Sicht, die `git diff` allein nicht liefert; `<Baseline-Commit>` siehe Pkt. 6 R-1)
    dass die geänderten Dateien eine Teilmenge von **(Kandidatenliste ∪ Neu-Anlage-Zielpfade ∪ `log.md` ∪ nachgeführte `index.md`)** — mit der Kandidatenliste aus §3 Pkt. 2 (betroffene *bestehende* Concepts, relative OKF-Pfade ohne `.md`) **plus** den Zielpfaden aller im selben Run neu angelegten Concepts (§5.1/§5.7 — Misch-Runs) plus `log.md` und jede nachgeführte `index.md` als zusätzliche zulässige Einträge. **Probe-Zeitpunkt (D-1-Präzisierung):** die Probe läuft **vor dem Commit**, am Ende des P2-Check-Blocks (Pkt. 6) — nach dem Commit wäre `git diff` leer und die Probe vacuous (Commit-Boundary = Mutations-Boundary, AD-17f: der Run committiert erst, nachdem die Probe ohne Ghost-Diff abgeschlossen ist). **Pfad-Normalisierung vor dem Teilmenge-Vergleich:** die Proben-Ausgabe trägt `wiki/`-Präfix und `.md`-Endung; die Kandidaten-/Ziel-Pfade sind definiert als relative OKF-Pfade *ohne* `.md` — für den Vergleich werden von jedem Proben-Eintrag `wiki/`-Präfix und `.md`-Suffix gestrippt (deterministischer Normalisierungsschritt). Jede Abweichung (**Ghost-Diff** auf einem nicht betroffenen Pfad) ist ein Instruktions-Verstoß (FT-6): Der Producer behebt sie textuell benannt (NFR-4) und **rollt den Ghost-Diff zurück, bevor der Run als gültig vermerkt wird** — der beobachtbare Endzustand des Bundles bleibt damit konsistent (AD-6-Backstop). **Rollback-Mechanik:** der Ghost-Diff betrifft nur Pfade *außerhalb* der erlaubten Menge; der Producer stellt die betroffenen Pfade aus dem Baseline-Zustand wieder her (für modifizierte Pfade: `git checkout -- <wiki/pfad>`; für ungetrackte neue Dateien: Datei löschen; für Index-Änderungen: `git checkout -- wiki/index.md` bzw. die Area-`index.md`) — der Teilzustand-Rollback des §5.3 Pkt. 3 / §6 Pkt. 3 greift daneben unverändert. Für Story 3.1 selbst (Instruktions-Story ohne Inhalts-Mutation) ist der Nachweis: `git diff --name-only -- wiki/` liefert ausschließlich `wiki/log.md` — keine Concept-Datei, keine `index.md` (die aggressive `git diff --stat -- wiki/`-Default-Effektiv-ausgabe zeigt denselben Pfad, `wiki/log.md | 1 +`). *(Anmerkung: `schema/compiler.md` und `deferred-work.md` liegen **außerhalb** `wiki/` und sind daher kein Teil dieser Diff-Probe — sie gehören zum Instruktions-, nicht zum Bundle-Baum; der Ghost-Diff-Begriff dieser Sektion gilt nur für `wiki/`.)*
+   Die Probe verifiziert dabei **zwei Ebenen** (Struktur-Erhaltungs-Bezug, Story 3.3): **(1) die Pfad-Mengen-Ebene** (obiger Teilmenge-Vergleich — welche Pfade der Run berührt hat) und **(2) die Struktur-Ebene je berührtem Pfad** — die Struktur-Erhaltung „ohne die Struktur zu zerstören" (FR-6/AC-2) wird pro betroffenem Concept-Pfad über die Pkt.-2-Regeln geprüft (Frontmatter-Subset-Konformität: nur `sources`-Zuwachs um echte neue Belege + `generated.at`-Bump, kein neuer Key, keine Entfernung ohne Beleg; bestehende belegte Aussagen nicht umgeschrieben ohne dass Präzisieren/Korrigieren greift; §5.5-Inline-Verweise weiterhin gültig soweit Beleg Body-Bestand; §5.6-Linkform unverändert, keine neuen Links außer bei echten Beziehungen — Verstöße sind textuell zu benennen (NFR-4) und werden vor dem Commit behoben, sonst gilt der Pfad als Ghost-Diff mit Rollback gemäß dieser Pkt.-5-Konsequenz).
 6. **Run-Vorphase-Bausteine (Defer R-1 + P2, in den Update-Pfad eingearbeitet):** Beide sind **keine** neuen Prozesse — wiederverwendbare, reproduzierbare textuelle Check-Blöcke innerhalb der Instruktions-Ausführung (D-3):
    - **Change-Detection (Defer R-1, Input-Zuwachserkennung):** Vor der Interpretation bestimmt der Producer, **welche `raw/`-Dateien Zuwachs** sind (neu/modifiziert). Deterministische Mittel: `git diff --name-only <Baseline-Commit> -- raw/` auf das `raw/`-Verzeichnis und/oder der **SHA-256-Record aus `raw/**/source.md`** (Provenienz-Sidecar, §1 Pkt. 4). Als `<Baseline-Commit>` dient der **letzte committete Zustand des Workspace** (deterministisch: der HEAD der vorherigen Mutations-Boundary, AD-17f). **Auflösungs-Regel (D-2-Präzisierung, Review-Loop 2):** der Producer **notiert den `<Baseline-Commit>` (vollen SHA) im `wiki/log.md`-Eintrag des Runs** — damit ist er deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14: Git liefert Historie, nicht Domain-State; der log.md-Eintrag ist der State-Referenz-Punkt, keine Git-Historie-Interpretation). **Diskrepanz-Regel:** widersprechen sich `git diff`-Befund und SHA-256-Record für dieselbe Datei, **gewinnt der `git diff`-Befund** (Commit-Boundary = Mutations-Boundary, AD-17f); der SHA-256-Record bleibt Sekundär-Fingerprint. Ist der SHA-256-Record unlesbar/fehlend, wird die Datei dennoch als Zuwachs **nicht doppelt** verarbeitet (textueller Hinweis) und gegen den `git diff`-Befund abgeglichen (kein Doppel-Verdikt). **Fallback:** existiert keine vorherige Mutations-Boundary (frischer Workspace ohne Lauf-Historie), gilt **alle `raw/`-Dateien als Zuwachs**. Die Diff-Probe in Pkt. 5 läuft gegen **dasselbe** `<Baseline-Commit>` (Review-Loop-2-Korrektur des Rev-2.4.1-Claims: die Pkt.-5-Probe trägt das Baseline-Commit-Argument explizit).
-   - **Pre-Run-Reconcile-Check-Block (Defer P2):** Vor jeder Mutation durchläuft der Producer den gebündelten Vorprüf-Block und hält ihn textuell fest: (1) **Input-Zustand** (AD-17a, I/O-Matrix `INPUT_UNCOMMITTED`; Review-Loop-2-D-3): Working-Copy von `raw/` und `wiki/` gegen HEAD prüfen — bei Abweichung (uncommitteder Zustand) bricht der Run mit dem **textuell benannten Abbruch „published/committed Input erforderlich"** ab, **vor** Interpretation und vor jeder Mutation (keine Mutation gegen Zwischenstände); (2) Ziel-Pfade (Ausgangs-Kandidatenliste, §3 Pkt. 2); (3) Quellen-Existenz (EC-1 via Validator-Punkt: jede referenzierte `raw/`-Datei existiert als Datei); (4) Betroffenheits-Kandidatenliste (§3 Pkt. 2, textuell-deterministisch); (5) `wiki/index.md`-V-1-Vorbedingung (fehlende Bundleroot → Run-FAIL, §3 Pkt. 3, Vertrag §2). Dieser Block ist der in `deferred-work.md` als P2 notierte Pre-Plan-Schritt und wird durch Story 3.1 als Teil des inkrementellen Runs ausgeführt. **Zeitpunkt (Review-Loop-2-Präzisierung):** der Block wird **nach Reconcile (2) und vor Mutieren (4)**, am **Anfang der Mutationsphase**, einmal pro Run durchgeführt — die Kandidatenliste (Elemente 2/4) existiert zu diesem Zeitpunkt bereits; die **Diff-Probe (Pkt. 5) läuft am Ende desselben Blocks, nach den Mutationen, vor dem Commit**. Die Kandidatenliste, die hier festgehalten wird, ist **die** Kandidatenliste, gegen die der Diff-Selbsttest (Pkt. 5) prüft (keine zweite, davon abweichende Erhebung nach der Mutation).
+   - **Pre-Run-Reconcile-Check-Block (Defer P2):** Vor jeder Mutation durchläuft der Producer den gebündelten Vorprüf-Block und hält ihn textuell fest: (1) **Input-Zustand** (AD-17a, I/O-Matrix `INPUT_UNCOMMITTED`; Review-Loop-2-D-3): Working-Copy von `raw/` und `wiki/` gegen HEAD prüfen — bei Abweichung (uncommitteder Zustand) bricht der Run mit dem **textuell benannten Abbruch „published/committed Input erforderlich"** ab, **vor** Interpretation und vor jeder Mutation (keine Mutation gegen Zwischenstände); (2) Ziel-Pfade (Ausgangs-Kandidatenliste, §3 Pkt. 2); (3) Quellen-Existenz (EC-1 via Validator-Punkt: jede referenzierte `raw/`-Datei existiert als Datei); (4) Betroffenheits-Kandidatenliste (§3 Pkt. 2, textuell-deterministisch); (5) `wiki/index.md`-V-1-Vorbedingung (fehlende Bundleroot → Run-FAIL, §3 Pkt. 3, Vertrag §2); (6) **Struktur-Erhaltungs-Check (Story-3.3-Ergänzung als zusätzliches textuelles Element):** vor dem Commit prüft der Producer an den betroffenen Concept-Pfaden, dass keinerlei unbefugte Keys im Frontmatter entstanden sind (Vertrag §3.3/§3.4-Subset, §6.5-Kriterium-1), **keine stille Löschung** bestehender belegter Aussagen/Provenienz erfolgt ist (AD-16, Pkt. 2 „Korrigieren"-Form) und **keine Links** verändert oder ohne echte Beziehung neu gesetzt wurden (§5.6-Pin, Pkt. 3); Verstöße sind textuell benannt (NFR-4) und vor dem Commit zu beheben; die Kandidatenliste bleibt **die** Liste gegen die der Diff-Selbsttest (Pkt. 5) prüft (keine zweite Erhebung nach der Mutation). Dieser Block ist der in `deferred-work.md` als P2 notierte Pre-Plan-Schritt und wird durch Story 3.1 als Teil des inkrementellen Runs ausgeführt. **Zeitpunkt (Review-Loop-2-Präzisierung):** der Block wird **nach Reconcile (2) und vor Mutieren (4)**, am **Anfang der Mutationsphase**, einmal pro Run durchgeführt — die Kandidatenliste (Elemente 2/4) existiert zu diesem Zeitpunkt bereits; die **Diff-Probe (Pkt. 5) läuft am Ende desselben Blocks, nach den Mutationen, vor dem Commit**.
 7. **Worked Example (an die reale Ist-Lage gebunden, re-executiert; Review-Loop-2-Korrektur):** Ein Run mit neuer committeter Evidenz `raw/epics/epics-2026-08-14.md#FR-12` (Zuwachs über die bisher verarbeitete Stelle hinaus; die Kennung FR-12 existiert real in der Datei) trifft über `rg -l 'FR-12' -g '!log.md' wiki/` das bestehende Root-Concept `wiki/knowledge-kompilation-inkrementell.md` (Term-/Konzept-Überschneidung — re-executierter Befund: der Grep-Ausgabe-Pfad ist `knowledge-kompilation-inkrementell`, `wiki/log.md` exkludiert gemäß §3.2-Pkt.-2a; das Rev-2.4.1-Beispiel `wissensarchitektur/source-material.md` enthielt den Term **nicht** und ist damit korrigiert). Der Run aktualisiert diesen Pfad (Body-Erweiterung mit neuem §5.5-Inline-Beleg `(raw/epics/epics-2026-08-14.md#FR-12)`, `sources`-Ergänzung um diesen `resource` — sofern nicht bereits deklariert, sonst No-Op gemäß Pkt. 2, `generated.at` = aktueller Run-Zeitstempel, `log.md`-Eintrag „Story 3.1-Update"). Die Diff-Probe (Pkt. 5, `<Baseline-Commit>`-Form) zeigt ausschließlich `log` und `knowledge-kompilation-inkrementell` (betroffen, normalisiert) — kein Ghost-Diff, keine `index.md` im Diff (der Index-Link bleibt unverändert).
 
 ## 6. Validieren (mechanische Bestätigung)
@@ -373,3 +379,4 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
 - **Revision 2.5 (2026-08-19, Story 3.2):** Neue Sektion **§3.2 „Relevanzbestimmung (Story 3.2)"** eingefügt (nach §3, vor §4) — die **verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung** („Erhebung nach §3.2"): (1) **Term-Ziehverfahren** deterministisch (bedeutungstragende Token-Folgen nach §2-Interpretation; Normalisierung lowercasing + `[-–_ ]`→`-`-Kollaps; **kanonischer Schreibweisen-Resolver `schema/canonical-terms.md`** — committete, append-only Registry (canon. Form + erlaubte Varianten), damit Bestandteil des Git-States und deterministisch pinbar; genau eine canon. Form je Semantik A0-18; kein stiller Ausschluss nicht auflösbarer Varianten — Verwendung wie notiert; mehrere Terme je Einheit → Vereinigung), (2) **dreistufige term-übergreifende Erhebung über `wiki/`** — (a) `rg -l '<term>' --exclude=log.md wiki/` (grep-Äquivalent `grep -rl … --exclude=log.md`; `log.md` **strukturell** exkludiert, Candidate-Liste auf Concept-Pfade definiert), (b) `index.md`-Traversal (gewurzelte Erreichbarkeit Root → Area → Concept, §5.8; TRAVERSAL_REACH_ONLY; fehlende Bundleroot → Run-FAIL V-1), (c) Link-Following mit **besuchter Menge** (file-relativ auflösen, §5.7 Pkt. 4; Zyklen enden, LINK_FOLLOWING_ZYKLUS); (3) **Candidate-Liste + Determinismus-Vertrag (AD-17h/A0-19):** relative OKF-Pfade ohne `.md` (Strip `wiki/`-Präfix + `.md`-Suffix), **Zuwachs-Sicht-Ordnung** mit Reihenfolge auch für Stufe-b/c (nach Stufe-a; lexikografisch als deterministischer Tie-Break), keine Duplikate (besuchte Menge), NO_MATCH → leere Candidate-Liste → UNTOUCHED_CONCEPT (Story-3.1-Pfad); Determinismus-Selbsttest (Membership + Zwei-Run-Identität) in Spec-Verification und `wiki/log.md` belegt. **§3 Pkt. 2:** Story-3.2-Vorbehalt **aufgelöst** — Pkt. 2 bleibt Kern-Anker, die Erhebung zeigt auf die neue Sektion („Erhebung nach §3.2"), `rg -l '<term>' --exclude=log.md wiki/` als Stufe-a-Form genannt. **§7:** Story-3.2-Vorbehalt **aufgelöst** (Relevanzbestimmung in §3.2 verankert; verbleibende 3.x-Themen: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6). **§8:** Normreferenzen um **AD-13** (bereits gelistet, §3.2-angeankert), **A0-18** (Deterministische Relevanzbestimmung, §3.2) und **A0-19** (Determinismus-Vertrag, §3.2 — war im Ist-§8 noch nicht gelistet, wird als Determinismus-Referenz ergänzt) sowie **PRD OQ-3** (Compilation Scope, §3.2) ergänzt; **`schema/canonical-terms.md`** als nebengeordnete committete Resolver-Registry referenziert (kein `schema/`-Root-Change; gleiche read-only-Hierarchie, append-only). Em-Dash-`—`-Varianten-Lücke als offene Determinismus-Frage an **Story 3.8** übergeben (nicht stillschweigend ergänzt). **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. **`sprint-status.yaml`:** Key `3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip` `backlog` → **`in-progress`**. `wiki/log.md`-Eintrag (append-only, bestehende Bullets unverändert), `deferred-work.md`-epic-3-context-Eintrag → aufgegriffen (append-only), Determinismus-Selbsttest + Validator-Lauf (7/7 SUCCESS) siehe `wiki/log.md`-Nachweis.
 - **Revision 2.4.2 (2026-08-19, Story 3.1, bmad-code-review Loop 2, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4 = 1/1/1/1):** (1) **Diff-Selbsttest (Pkt. 5) operationalisiert + Blind-Spots geschlossen (D-1):** Probe erweitert auf `git diff --name-only <Baseline-Commit> -- wiki/` **plus** `git status --porcelain -- wiki/` (erfasst ungetrackte neue Dateien `??` — die Duplikat-Kontrolle „keine neue Datei" braucht diese Sicht; `git diff` allein ist blind für Untracked); **Probe-Zeitpunkt fixiert vor dem Commit** (am Ende des P2-Blocks, nach den Mutationen) — nach dem Commit wäre die Probe vacuous (leere Ausgabe, AD-17f); erlaubte Teilmenge-Menge um **Neu-Anlage-Zielpfade** (§5.1/§5.7) ergänzt — Misch-Runs (Neu-Anlage + Update im selben Run) markieren neu angelegte Pfade nicht fälschlich als Ghost-Diff; **Pfad-Normalisierung** definiert (Strip `wiki/`-Präfix + `.md`-Suffix vor dem Teilmenge-Vergleich, da Kandidaten/Ziel-Pfade als relative OKF-Pfade *ohne* `.md` definiert sind); **Rollback-Mechanik** für den Ghost-Diff deterministisch benannt (modifizierte Pfade via `git checkout -- <wiki/pfad>`, ungetrackte neue Dateien gelöscht, Index via `git checkout -- <index>`; §5.3/§6.3-Teilzustand-Rollback greift daneben unverändert). (2) **R-1-Baseline deterministisch + Abweichungsregel (D-2):** `<Baseline-Commit>` (HEAD der vorherigen Mutations-Boundary, AD-17f) wird vom Producer **im `wiki/log.md`-Run-Eintrag notiert** (voller SHA) — deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14); **Diskrepanz-Regel**: widersprechen `git diff`-Befund und SHA-256-Record derselben Datei, **gewinnt `git diff`** (Commit-Boundary-Prinzip), SHA-256 bleibt Sekundär-Fingerprint; **Fallback**: ohne vorherige Mutations-Boundary gelten alle `raw/`-Dateien als Zuwachs; Rev-2.4.1-Claim „derselbe Baseline-Commit wie Pkt. 5" **korrigiert** (die Pkt.-5-Probe trägt das Baseline-Commit-Argument jetzt explizit). (3) **INPUT_UNCOMMITTED-Abbruch (D-3) + Anker-Divergenz:** neuer P2-Check-Block-Element (1) **Input-Zustand** — Working-Copy von `raw/`/`wiki/` gegen HEAD prüfen, bei Abweichung **benannter Abbruch „published/committed Input erforderlich"** vor Interpretation und vor jeder Mutation (AD-17a, I/O-Matrix-`INPUT_UNCOMMITTED` — zuvor nur Referenz auf §1 Pkt. 1, keine Zustandsprüfung/Abbruchmeldung); die **Spec↔Anker-Divergenz** (frozen Spec zitiert 3× „§1.1", §1 ist eine nummerierte Liste Pkt. 1–4 ohne §1.1-Label; Rev-2.4.1 korrigierte nur die Anker *in* compiler.md) wird hier als dokumentierte Fußnote gesichert — die Spec bleibt frozen (nur per menschlicher Renegotiation änderbar). (4) **Sandbox-Edge-Test-Nachweis (D-4):** die fünf I/O-Matrix-Szenarien (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) + die D-3-Abbruch-Kontrolle sind als re-executierbare Sandbox-Skripte mit **konkreten deterministischen Ausgaben** in der Spec-`## Verification`-Sektion (Sandbox-Beleg) verankert — die `wiki/log.md`- und `deferred-work.md`-Verweise („in der Spec-Verification enthalten") auflösbar. (5) **Instruktions-Präzisierungen:** P2-Block-**Zeitpunkt** (nach Reconcile, am Anfang der Mutationsphase; Diff-Probe am Block-Ende) — löst den Widerspruch „einmal an der Spitze erhoben" vs. „Kandidatenliste entsteht erst im Reconcile"; **No-Op-Kandidat**-Regel (Pkt. 2: Pfad, der die Evidenz bereits vollständig enthält → keine Mutation/kein `at`-Bump/kein `log.md`-Eintrag, byte-identisch — die engere Auslegung); **Mehrfach-Treffer-Reihenfolge** für *alle* Einheiten definiert (Zuwachs-Sicht-Ordnung; lexicografisch nur als Tie-Break bei identischem Ort — AD-17h); **Update-Pfad-Rollback** in §5.3 Pkt. 3 (modifizierte Pfade aus Baseline-Commit wiederherstellen); **`generated.at`↔AD-17h-Gap** explizit als offener Punkt mit Home Story 3.8 benannt (Wanduhr-`at` erzeugt bei gleichem Input unterschiedliche Bundle-States; Konvention bleibt bis dahin bindend, Wechsel = Ask-First); **Term-Ableitung** (Pkt. 2 (a)) als §2-Interpretation abgegrenzt — die Erhebung *mit festem Term* ist textuell-deterministisch, der Term-Mechanismus (Kanonisierung/Synonyme) Story 3.2; **Link-Following** mit besuchter Menge (keine Schleife bei zyklischen Links); **Worked Example (Pkt. 7) auf den realen Ist-Baum korrigiert** (`rg -l 'FR-12' wiki/` trifft `wiki/knowledge-kompilation-inkrementell.md`, **nicht** `wissensarchitektur/source-material.md` — Rev-2.4.1-Beispiel enthielt den Term nicht); stale-Anker `§3.2-Kollisionsprüfung` (Pkt. 3-Zuordnung) und `§3-Voraussetzungsprüfung` (P2-Block) sowie §5.8-Pkt.-3-Zeiger („Pkt. 1" → „Pkt. 2") nachgeführt. **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
 - **Revision 2.7 (2026-08-19, Story 3.2, Step-04-Review Loop 3, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4/D-5 = 1/1/1/1/1, jeweils empfohlene Option; + 2 Patches; D-3-Instruktions-Patch, kein neuer Inhalt):** (1) **§3.2-Pkt.-3b-Ordnung auf reine Lexikografie gehoben (D-4):** Stufe-a-Treffer waren „in der Reihenfolge des ziehenden Terms, dann lexikografisch als deterministischer Tie-Break" — die Term-Ordnung selbst war für Mehrfach-Terme (Pkt. 1c) nirgends festgelegt, zwei rechtmäßige Term-Ordnungen erzeugten zwei unterschiedliche Listen (AD-17h-Lücke). Jetzt: **innerhalb jeder Stufe rein lexikografisch aufsteigend (LC_ALL=C)**; die Term-Verarbeitungsreihenfolge dient nur der Interpretation/Erhebung, **nicht** der Listen-Ordnung — dieselbe Treffermenge → identische Liste. (2) **`schema/canonical-terms.md`-Lookup-Semantik vervollständigt (D-5):** Lookup-Verfahren deterministisch fixiert (lowercasing → `[-–_ ]`→`-`-Kollaps → **Lookup der normalisierten Form**; Spalten tragen ausschließlich normalisierte Formen), **Eindeutigkeits-Invariante** (jede normalisierte Form in genau einem Eintrag — Canon **oder** Variante, nie beides/zweimal) + **Konflikt-Verfahren** (keine stille Anhängung; `deferred-work.md`-Handoff / Ask-First, analog zur Umbenennungs-Regel). (3) **Statuskette `in-progress → done` dokumentiert (D-1):** der Review-Loop-Abschluss-Flip `in-progress → done` (Sprint-Sync-Konvention, Story-3.1-Präzedenz) war in keinem `wiki/log.md`-Eintrag als eigener Schritt belegt — nachgeführt als neuer oberster `wiki/log.md`-Bullet (append-only; die gefrorene Always-Klausel `→ in-progress` beschreibt den Implementierungsstand, der Review-Abschluss `done` ist der übliche Folgezustand). (4) **Mini-Sandbox um T5/T6/T7 erweitert + T1/T4-Asssertionen + T2-Kommentar-Korrektur (D-2 + Patch P-1):** T5 `LINK_FOLLOWING_ZYKLUS` (A→B→A-Links; besuchte Menge → endliche, doppelungsfreie Liste), T6 `TRAVERSAL_REACH_ONLY` (Term nur in Area-`index.md` → gewurzelte Concept-Pfade als Kandidaten; `index.md` selbst ist kein Concept-Kandidat), T7 `TERM_ABLEITUNG_SYNONYM` (Registry-Test-Doppel: Schreibvarianten → canonische Form via Lookup auf normalisierter Form; Negativ-Fall: nicht auflösbar → wie notiert, kein stiller Ausschluss); T1/T4 tragen jetzt harte Pass/Fail-Asssertionen (`exit 1` bei Abweichung) — die exakte Candidate-Liste wird erzwungen, nicht nur ausgegeben; der T2-Kommentar zu `index` korrigiert (Stufe-a-Treffer auf `wiki/index.md` löst Stufe b aus; `index.md` ist kein Concept-Kandidat). (5) **Selbsttest-Beleg (b) gegen den realen Sandbox-Ist-Baum re-executiert (D-3):** der Rev-2.5-Log-Beleg (b) beschrieb einen nicht-committierten Baum (Term `quanten-protocol`, `sub/beta.md`, SHA-256 `159092bb…`) — Stale-Evidenz-Falle (B1-Präzedenz). Der Nachweis wird jetzt gegen die echte `run-sandbox.sh`-Ausgabe (Term `deterministische-relevanz-bestimmung`, root-level `alpha`/`beta`/`gamma`) neu belegt; der Rev-2.5-Eintrag bleibt historisch unverändert, die Korrektur steht als neuer `wiki/log.md`-Bullet (append-only). (6) **Typos im normativen Text korrigiert (Patch P-2):** `Determinsmus` → `Determinismus` (§8-Referenzen + Log-/Defer-Belege), `§3.2-beankert` → `§3.2-angeankert`, `Membrum` → `Mitglied` (Spec-Design-Notes), `Konventionelle Determinismus-Lücke` → `Bekannte Determinismus-Lücke` (Defer-Beleg; `compiler.md:53` sagt „Bekannte"), `Resovierung` → `Auflösung` (Spec-Change-Log/-Verification). **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. (Revisionslog-Reihenfolge-Anomalie 2.6/2.5 bleibt als dokumentierter Defer bestehen — nicht in dieser Runde umgeordnet.)
+- **Revision 2.8 (2026-08-19, Story 3.3):** §5.9-Update-Formen **operationell ausformuliert** (dieselbe Evidenz + formale Struktur → identisches Update-Ergebnis, AD-17h/A0-19): (1) **Pkt. 2 — Präzisierungsebene je Update-Form** (als Sub-Bullet an die Commit-Boundary-Regel angefügt; der frozen Story-3.1-Regeltext bleibt textuell **unverändert** als normative Basis, die operationellen Regeln sind die Ausführungs-Ebene darunter — keine Re-Negotiation): je Form **(a) Abgrenzungskriterium** (aus der committeten Evidenz: neue belegte Aussage → Erweitern; Schärfung einer bestehenden Formulierung/Abgrenzung ohne Ersatz → Präzisieren; Ersetzung einer fehlerhaften/überholten → Korrigieren; keines davon → No-Op, engere Auslegung), **(b) Struktur-Erhaltungsregel** (das Geschützte — Frontmatter-Subset nur als `sources`-Zuwachs um echten neuen Beleg + `generated.at`-Bump; bestehende belegte Aussagen nicht umgeschrieben ohne dass Präzisieren/Korrigieren greift; §5.5-Inline-Verweise gültig soweit Beleg Body-Bestand; §5.6-Linkform unverändert, keine neuen Links außer bei echten Beziehungen) und **(c) Textgenauigkeits-Rahmen für Präzisieren** (Schärfen an der Aussage, kein Satz-Umbau, kein Neuschreiben ohne Ersetzungsbeleg). (2) **Pkt. 5 — Erhaltungs-Invariante um den Struktur-Erhaltungs-Bezug ergänzt:** die Diff-Probe verifiziert zwei Ebenen — die Pfad-Mengen-Ebene (bestehender Teilmenge-Vergleich) und die **Struktur-Ebene je berührtem Pfad** (pro betroffenem Concept-Pfad über die Pkt.-2-Regeln geprüft: Frontmatter-Subset, keine Umschreibung belegter Aussagen außerhalb der Formen, Inline-Verweise, Linkform — Verstöße textuell benannt (NFR-4), vor dem Commit zu beheben, sonst Ghost-Diff mit Rollback). (3) **Pkt. 6 — P2-Check-Block um den Struktur-Erhaltungs-Check erweitert** (Element (6), zusätzliches textuelles Element: keine unbefugten Keys — Vertrag §3.3/§3.4-Subset, keine stille Löschung — AD-16/„Korrigieren"-Form, Links unverändert/keine neuen ohne echte Beziehung — §5.6-Pin; Verstöße textuell benannt (NFR-4) und vor dem Commit behoben). (4) **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert; kein Leasing-Scope (AC-4 → Story 3.5/3.6, AD-17.3-Hinweis unverändert in §7). **`sprint-status.yaml`:** Key `3-3-bestehende-concepts-erweitern-präzisieren-korrigieren` bleibt **`in-progress`** (Review-Abschluss `done` erfolgt gemäß Workflow-Konvention durch den Review-Schritt). Sandbox-Nachweis und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.3, Revision 2.8).