summary: **`epic-3-context.md` ist ein neues Artefakt außerhalb der Spec-Code-Map** — die Code Map listet exakt compiler.md / log.md / deferred-work.md / sprint-status.yaml (sonst read-only); die 50-Zeilen-Context-Datei (im Story-3.1-Commit neu) wird nirgends referenziert oder als erzeugt dokumentiert. Vom build-Verfahren (compile-epic-context) erzeugtes Kontext-Artefakt, keine Story-Inhalts-Mutation, kein Always/Ask-First/Never-Verstoß; Home: Story-3.2-Handoff oder nächstes Sprint-Sync (einzeilige Nennung im log.md-Nachweis genügt).
evidence: bmad-code-review Story 3.1 (2026-08-19, Acceptance-Auditor-Layer): Spec-Code-Map vs. `git show efc543c --stat` (6 Dateien, `epic-3-context.md` new file).
status: offen
status: aufgegriffen (2026-08-19, Story 3.2) — einzeilige Nennung im `wiki/log.md`-Eintrag der Story 3.2 erfolgt; `epic-3-context.md` bleibt als vom build-Verfahren erzeugtes Kontext-Artefakt bestehen (keine Story-Inhalts-Mutation; Deckung über die Spec-`context:`-Frontmatter der Story-3.2-Spezifikation).
## Deferred from: Story 3.2 (Relevanzbestimmung, 2026-08-19)
summary: **Em-Dash-»—«-Varianten-Lücke der Normalisierung** — die Kollaps-Klasse `[-–_ ]` (En-Dash »–«, Bindestrich »-«, Unterstrich »_«, Leerzeichen) deckt den Em-Dash »—« **nicht** ab. Eine Schreibvariante mit Em-Dash (z. B. »wissen — relevanz«, aus dem Kontext einer externen Quelle eingelesen) fällt nicht unter den Kollaps und wird nicht zu einer identischen canonischen Form normalisiert — eine erkannte Synonym-/Determinismus-Lücke der Relevanzbestimmung (A0-18/A0-19). Wird nicht stillschweigend in §3.2 ergänzt, sondern als offene Determinismus-Frage an **Story 3.8** (Determinismus-Vertrag, AD-17h) übergeben; bis dahin wird ein nicht auflösbarer Em-Dash-Term **wie notiert** verwendet (Kollaps-normalisiert, kein stiller Ausschluss).
evidence: Story-3.2-Review-Umsetzung (2026-08-19) — §3.2-Pkt.-1b dokumentiert die Lücke explizit als »Konventionelle Determinismus-Lücke (aufgezeichnet, nicht still hinzugefügt)« und beruft sich auf diesen deferred-work-Eintrag als Handoff-Ziel.
<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
## Intent
**Problem:** Die Compiler-Instruktion (`schema/compiler.md` §3 Pkt. 2, Revision 2.4.2) erhebt die Update-Kandidatenliste bisher über einen **platzgehaltenen `<konzeptterm>`** („die Term-Auswahl folgt der §2-Interpretation"), dessen Ableitung (Kanonisierung, Synonyme, Mehrfach-Terme je Einheit) explizit „Story 3.2 vorbehalten" ist (`compiler.md:41`; §7 `:319`). Damit ist die Relevanzbestimmung nicht vollständig deterministisch vorgegeben (AD-17h/A0-19): dieselbe Evidenz kann je nach Term-Wahl unterschiedliche Candidate-Listen erzeugen — ein Embedding-freier, textuell-deterministischer Mechanismus fehlt (PRD OQ-3, AD-13, A0-18).
**Approach:** Story 3.2 löst die beiden Story-3.2-Vorbehalte auf und verankert in `schema/compiler.md` (D-3, rein textuell — kein Code, kein Standalone) den **feinkörnigen, textuell-deterministischen Relevanz-Findungsmechanismus** als verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung: (a) **Term-Ziehverfahren** — die Candidate-Terme werden deterministisch aus der neuen Evidenz abgeleitet (bedeutungstragende Token-Folgen nach §2-Interpretation, durchgängige Normalisierung: lowercasing, `[-–_ ]`-Bindestrich-Varianten, ein kanonischer Schreibweisen-Resolver, mehrere Terme je Einheit erlaubt); (b) **Term-übergreifende Erhebung** über `wiki/` — grep/ripgrep, `index.md`-Traversal, Link-Following (dreistufig, mündet in die nachvollziehbare Candidate-Liste als relative OKF-Pfade ohne `.md`); (c) **Determinismus-Vertrag** — gleicher Git-State + gleiche Eingabemenge → gleiche Candidate-Liste in gleicher Reihenfolge (AD-17h/A0-19). Damit werden die Story-3.2-Vorbehalte in §3 Pkt. 2 und §7 aufgehoben. 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.2 ist eine Instruktions-Story (D-3).** Der Relevanz-Findungsmechanismus wird ausschließlich in `schema/compiler.md` als deterministische Text-Instruktion verankert. Kein ausführbares Programm, kein Standalone, keine neue §7-Invaliditätsklasse, kein Change an `schema/wiki-compiler.md` / `schema/validator.md` / `raw/` (AD-3).
- **Determinismus (Kern, AD-17h/A0-19):** Die Relevanzbestimmung ist **deterministisch**: gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge (Zuwachs-Sicht-Ordnung; lexikografisch als deterministischer Tie-Break bei identischem Ort). Damit ist sie als nachvollziehbare Candidate-Liste (Concept-Pfade) verfügbar — deterministisch statt probabilistisch (AC-3).
- **Ausschließlich textuelle Mittel (AD-13, AC-1/AC-4, No-Goals):** Die Erhebung nutzt ausschließlich grep/ripgrep über `wiki/`, Markdown-Traversal von `index.md` und Link-Following (§5.6-Pin). **Kein** Einsatz von Embeddings, Vektor-Suche oder Knowledge-Graph-Datenbank im Compiler-Kern.
- **Kein Leasing-/Dirty-Tree-Scope in 3.2:** Leasing, Dirty-Tree, Staleness, Merge-Kollisionen bleiben Story 3.5/3.6; Commit-Boundary = Mutations-Boundary-Regel (AD-17f) und die Story-3.1-Bausteine (§5.9 Diff-Selbsttest, R-1/P2-Check-Block, INPUT_UNCOMMITTED-Abbruch, Update-Routing) bleiben unverändert — Story 3.2 ändert nur die **Erhebungs-Mechanik** der Candidate-Liste, nicht die Mutationspfade.
**Ask First:** Einführung nicht-textueller Mittel (Embeddings/Vector/KG) im Compiler-Kern (verboten durch AD-13, nur per Autorisierung änderbar) · Änderung der §5.6-Linkform (verboten durch A0-9) · AD-7d-Renames/Redirects · 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 · Standalone-Programm/Validator (D-3) · Embedding/Vector-Suche/KG im Compiler-Kern (AD-13, No-Goals) · Duplikat-Anlage eines bestehenden Concept-Pfads · „Regenerate Everything" (AD-5, A0-6).
| TERM_ABLEITUNG_SINGLETON | Neue Evidenz `raw/…` mit genau einem markanten Fachbegriff (z. B. `quanten-protocol-schlüssel`) | Term-Ziehverfahren ergibt genau diesen Begriff; grep-Erhebung über `wiki/` findet genau die Concept-Pfade mit diesem Term | N/A |
| TERM_ABLEITUNG_SYNONYM | Evidenz nennt einen Begriff in einer Schreibweise-Variante (z. B. `quanten protocol` vs. canonisch `quanten-protocol`) | Kanonisierungs-Resolver normalisiert auf die canonische Schreibweise; Erhebung findet die Concept-Pfade der canonischen Form | keine canonische Auflösung → Term wird wie notiert verwendet (kein stiller Ausschluss) |
| TERM_ABLEITUNG_MEHRFACH | Evidenz enthält mehrere bedeutungstragende Terme | Candidate-Liste = Vereinigung der Treffer über alle Terme; Vereinheitlichung über besuchte Menge (ein Pfad nur einmal) | N/A |
| TRAVERSAL_REACH_ONLY | Ein Konzeptterm trifft nur `wiki/index.md` (oder Area-`index.md`), nicht Concept-Bodies | `index.md`-Traversal (Root → Area → Concept, §5.8) liefert die darunter gewurzelten Concept-Pfade als Treffer | fehlende Bundleroot → Run-FAIL (V-1, besteht fort) |
| LINK_FOLLOWING_ZYKLUS | Concept-Links bilden einen Zyklus (A → B → A) | Link-Following mit **besuchter Menge** (aus Story 3.1): jeder Pfad nur einmal — keine Endlos-Schleife, endliche Candidate-Liste | N/A |
| NO_MATCH | Neuer Term trifft kein bestehendes Concept (keine Überschneidung) | Leere Candidate-Liste → UNTOUCHED_CONCEPT (Story-3.1-Pfad): keine Mutation, kein `log.md`-Zusatz | leere Menge ist Teilmenge jeder erlaubten Menge (Ghost-Diff-negativ) |
- §8 Revisionslog (`:350–352`): **Revision 2.5** (Story 3.2) + **2.6** (Step-04-Loop-2-Patch-Runde) — Normreferenzen AD-13/A0-18/OQ-3 ergänzen (AD-17h steht bereits; **A0-19 wird ebenfalls ergänzt** — war im Ist-§8 noch nicht gelistet; auch `A0-19` als Determinismus-Referenz); Abschlussklausel (kein Vertrag-/Validator-/`raw/`-Change, keine neue §7-Klasse, kein Standalone). Rev 2.6 trägt zusätzlich die Loop-2-Patches (§4-Überschrift, rg-tool-korrekte Formen).
- §5.9 Pkt. 6 / P2-Check-Block: die Candidate-Erhebung über einen Zeiger (nicht Duplizieren) an den neuen §3.2-Mechanismus binden — **einschl. `--exclude=log.md`** (analog §5.6/§5.8-Formel), die Candidate-Liste ist auf Concept-Pfade definiert.
- **Resolver-Materialisierung:** der kanonische Schreibweisen-Resolver wird als **`canonical-terms.md` unter `schema/compiler.md` nebengeordnet** (neues Artefakt, gleiche read-only-Hierarchie): committete, append-only Registry (canonische Form + erlaubte Schreibvarianten + `[]`), als `§3.2`-Ziel referenziert. Damit ist der Resolver Bestandteil des Git-States und der Determinismus (gleicher Git-State → gleiche Liste) pinbar. (Kein `schema/`-Root-Change; Einbindung als normierte Referenz im §8.)
-`wiki/log.md` — **append** (append-only, Vertrag §5: bestehende Bullets — Story-3.1-done unter 2026-08-19, Validierungs-Rev-9, Story 2.5… — **bleiben unverändert erhalten**; der Story-3.2-Eintrag wird als weitere Bullet ergänzt, nicht ersetzt): Relevanzbestimmung-Semantik, Determinismus-Selbsttest-Beleg (Membership + Identität; der `--exclude=log.md`-Fakt aus der Stufe (a) wird ehrlich dokumentiert — `A0-18` trifft nur noch `wiki/knowledge-kompilation-inkrementell.md`, nicht `log.md`), Statuswechsel `3-2-…``backlog → in-progress`, per-Datei-Validator-Verdikt-Zeile (Ist-Baum SUCCESS), einzeilige Nennung des 3.1-`epic-3-context.md`-Defer-Handoffs.
-`_bmad-output/implementation-artifacts/deferred-work.md` — **mutiert** (append-only): 3.1-Defer-Eintrag `epic-3-context.md` (`:335`, „Home: Story 3.2-Handoff oder Sprint-Sync") als aufgegriffen markieren; der F17-Handoff-Eintrag („Split 2026-08-19, Home: Story 3.8") ist bereits eingetragen. Bestehende Einträge nicht verändern, nur Status-Ergänzung im append-only-Stil.
-`schema/validator.md`, `schema/wiki-compiler.md`, `raw/…` — **read-only** (AD-3). Story 3.2 mutiert selbst keine Concept-Inhalte; Demonstration per Sandbox-Durchlauf (Muster: `_bmad-output/implementation-artifacts/sandbox-3-1/run-sandbox.sh`, S1–S6) oder als textueller Selbsttest gegen den Ist-Baum (z. B. `rg -l`-Erhebung mit realem Term, ohne Inhalts-Mutation).
## Tasks & Acceptance
**Execution:**
- [x]`schema/compiler.md` — Story-3.2-Vorbehalte auflösen (§3 Pkt. 2 + §7): §3.2-Relevanzbestimmung als verbindliche dreistufige Erhebungs-Mechanik (Term-Ziehverfahren + Kanonisierungs-Resolver; `log.md`-Exklusion — rg `-g '!log.md'` bzw. grep `--exclude=log.md` — über `wiki/`; `index.md`-Traversal; Link-Following mit besuchter Menge; Candidate-Liste als relative OKF-Pfade ohne `.md`; Determinismus-Vertrag AD-17h/A0-19 mit Reihenfolge auch für Stufe-b/c und Normalisierung in §3.2 selbst); **canonical-terms.md** (Resolver-Registry: canon. Form + Varianten, append-only); §8-Revision 2.5 + Normreferenzen AD-13/A0-18/A0-19/PRD-OQ-3; Abschlussklausel. Kein Vertrag-/Validator-/`raw/`-Change. _(Inkl. Rev-2.6-Patch-Runde aus Step-04-Review Loop 2: §4-Überschrift wiederhergestellt, rg-tool-korrekte Formen, Mini-Sandbox verankert — s. Spec Change Log.)_
- [x]`wiki/log.md` — Story-3.2-Eintrag (Vertrag §5-Format, append-only — bestehende Bullets unverändert) mit Relevanzbestimmung-Semantik, Determinismus-Selbsttest-Beleg (Membership + Identität via `log.md`-Exklusion), Statuswechsel, Validator-Verdikt, epic-3-context-Defer-Nennung. _(Loop-2-Patch-Note (Rev 2.6) als eigene oberste Log-Zeile ergänzt.)_
- [x]`deferred-work.md` — epic-3-context-Eintrag als aufgegriffen markieren (append-only); `sprint-status.yaml` — Key `3-2-…` → `in-progress`. _(Zusätzlich Em-Dash-Determinismus-Frage als neuer Defer (Home: Story 3.8) aus Loop 2.)_
- [x] Edge-Tests (Sandbox, I/O-Matrix + Membership-Pin): TERM_ABLEITUNG_SINGLETON/SYNONYM/MEHRFACH, TRAVERSAL_REACH_ONLY, LINK_FOLLOWING_ZYKLUS, NO_MATCH — inkl. mini-Sandbox-Baum, der einen realen Term auf Concept-Bodies **und**`log.md` verteilt und die exakte Candidate-Liste (nur Concept-Pfade, `log.md` ausgeschlossen) als erwartete Ausgabe pindet. _(Sandbox T1–T4 re-executiert: alpha exklusiv, Zwei-Run-Identität, NO_MATCH leer, alpha+gamma Vereinigung.)_
**Acceptance Criteria:**
- Given eine neue committete Source, when ein Run die Relevanzbestimmung ausführt, then nutzt er ausschließlich textuelle, deterministische Verfahren — Term-übergreifende grep/ripgrep über `wiki/`, Markdown-Traversal von `index.md`, Link-Following (AC-1; AD-13, A0-18) — als verbindliche Ausformulierung der §3-Pkt.-2-Erhebung; die Story-3.2-Vorbehalte (§3 Pkt. 2, §7) sind aufgehoben.
- Given gleicher Git-State + gleiche Eingabemenge, when zwei unabhängige Runs die Relevanzbestimmung ausführen, then erzeugen sie dieselbe Candidate-Liste in derselben Reihenfolge (AC-2; AD-17h, A0-19) — ohne Embedding/Vector/KG im Compiler-Kern (AC-4; AD-13).
- Given ein Ergebnis der Relevanzbestimmung, when es weiterverarbeitet wird, then ist es als nachvollziehbare Candidate-Liste (relative OKF Concept-Pfade ohne `.md`) verfügbar (AC-3).
- Given die Instruktion, when geprüft, then bleibt `schema/validator.md`/`schema/wiki-compiler.md`/`raw/` unverändert (AD-3), keine neue §7-Klasse, kein Standalone (D-3) — Validator läuft auf dem Ist-Bundle SUCCESS.
- **B1/VG-1 `log.md`-Kontamination:** `rg -l '<term>' wiki/` ohne `--exclude=log.md` → `log.md` wird ab dem Moment selbst „Kandidat", in dem ein Log-Eintrag den Term zitiert; der Determinismus-Selbsttest verankert das A0-18-1-File-Find in einem Commit, das selbst `A0-18` enthält (Stale-Evidenz; Reproduzierbarkeits-Claim widerlegt sich selbst). Bekannt-bös: permanente Drift + falsches Verification-Expect.
- **B2 Reihenfolge:** `rg -l`-Ausgabe-Reihenfolge (FS-Traversal) nicht auf Zuwachs-Sicht-Ordnung abbildbar; Stufe-b/c ohne definierte Position. Bekannt-bös: AC-2-Zwei-Run-Identität nur bei undokumentiertem `rg`-Tie-Break.
- **B3 Resolver nicht enumeriert:** „eine canonische Form je Semantik" ohne committete Registry → Determinismus nicht pinbar. Bekannt-bös: gleiche Liste nur, wenn Resolver Teil des Git-States (nicht spezifiziert).
- **B4 Em/En-Dash:** Klassenliteral `[-–_ ]` deckt nur En-`–`, nicht Em-`—`; Kollaps-Reichweite inkonsistent. Bekannt-bös: Em-Varianten fallen nicht unter den Kollaps (Synonymlücke). **Gewählter Weg:**`-`-Kollaps bleibt; explizite `—`-Resovierung wird als offene Determinismus-Lücke in Step-4-Defer an Story 3.8 übergeben (nicht stillschweigend hinzugefügt).
- **B5 §8-A0-19-Claim:** Spec sagte „A0-19 steht bereits in §8", war im Ist-Baum nicht kommutiert; Implementierung ergänzte A0-19 (korrekt). Spec korrigiert, A0-19-Ergänzung als KEEP verankert (fehlleiten bei Re-Baseline verhindern).
- **B6 NO_MATCH / §5.9-P2-Block-Scope:** werkt zusammen → zusammengefasst; in B1 und Task-Patch-Membership-Pin überführt.
- **B7 §5.9-P2-Block-Zeiger:** nicht mehr nötig — die fixierte Stufe (a) `--exclude=log.md` macht den Zeiger redundant (kein log.md-Kandidat mehr); **verworfen** (keine unnötige Pflicht).
- **KEEP-Instruktionen (müssen Neu-Ableitung überleben):** neue §3.2-Sektion nach §3 etc.; alle 6 I/O-Matrix-Szenarien; Determinismus-Vertrag (identische Reihenfolge, KEEP: nur-Parallel = deterministisch-MECHANISMUS, NICHT zufällig); `--exclude=log.md`-Stufe-a; Determinismus-Selbsttest MIT Membership-Pin (Zwei-Run-Identität + Mengen-Genauigkeit) und `canonical-terms.md`-Resolver as Resolver im Git-State; `Wiki/log.md` als append-only (Story-3.1-Bullet bleibt eigenständig stehen); die A0-19/Schema-Referenz ergänzen. NOT-KEEP: Spec-A0-19-Formulierung „steht bereits" (korrigiert).
- Restliche patch- und defer-Findings (B6/NO_MATCH, B5/Doppel, Log-Selbsttest-Beleggenaue, F17+Em-Morphologie-Story-3.8) werden in der Step-4-Patch-Runde umgesetzt bzw. in `deferred-work.md` nachbestätigt.
## Design Notes
**Warum §3.2 als eigene Sektion statt Streckung in Pkt. 2:** §3 ist heute eine nummerierte Liste (Pkt. 1–3); der Story-3.2-Vorbehalt sitzt IN Pkt. 2. Die feinkörnige Mechanik (Term-Ziehverfahren, Kanonisierungs-Resolver, dreistufige Erhebung, Determinismus) ist zu umfangreich, um Pkt. 2 verständlich zu halten. Design-Entscheidung: **neue Sektion §3.2 „Relevanzbestimmung (Story 3.2)"** direkt nach §3 — Pkt. 2 bleibt der Kern-Anker („Erhebung nach §3.2"), die Komplexität wird ausgelagert, bestehende §5.9-Pkt.-6-Bindungen bleiben gültig. Nur falls der §3-Aufbau eine andere Einfüge-Stelle nahelegt (z. B. Pkt. 2a), wird das Label angepasst — Pkt. 2 bleibt in jedem Fall der verbindliche Einstieg.
**Term-Ziehverfahren — was deterministisch heißt:** Die Ziehung ist deterministisch, weil sie allein von der committeten Evidenz-Datei abhängt: (1) bedeutungstragende Fachbegriffe = Token-Folgen mit fachlicher Signifikanz, aus der §2-Interpretation benannt (nicht freie LLM-Auswahl); (2) Normalisierung über einen canonischen Schreibweisen-Resolver (lowercasing; `[-–_ ]`→`-`; eine canonische Form je Semantik); (3) mehrere Terme je Einheit erlaubt — Candidate-Liste = Vereinigung der Treffer über alle Terme, bereinigt über besuchte Menge; (4) kein stiller Ausschluss: nicht auflösbare Varianten werden wie notiert verwendet. Die Erhebung *mit festem Term* war schon in Rev-2.4.2 deterministisch — Story 3.2 macht zusätzlich die **Term-*Auswahl*** deterministisch (exakt der bisherige Vorbehalt).
**Determinismus-Referenz:** AD-17h und A0-19 sind bereits Normreferenzen in §8 Revision 2.4 (Story 3.1); Story 3.2 ergänzt **AD-13**, **A0-18** und **PRD OQ-3** (Architekturfrage „Compilation Scope"). A0-19 war im Ist-§8 (Baseline `e3e7ec3`) zwar nicht gelistet — die Implementierung fügt es als Determinismus-Referenz der Relevanzbestimmung hinzu (kein Verstoß, Design-KEEP: A0-19-Anker wird in §8 **und** §3.2 gesetzt; die frühere Spec-Formulierung „steht bereits" war falsch und ist hiermit korrigiert). `wiki/knowledge-kompilation-inkrementell.md:48` referenziert A0-18/AD-13 bereits; **zur Erhebung wird `wiki/log.md` ausgeschlossen** (`--exclude=log.md`, §5.6-Muster) — sonst wäre der eigene `log.md`-Eintrag bei jedem Term, den er zitiert, selbst „Kandidat" (A0-18/FR-12-Fall; die Candidate-Liste ist auf Concept-Pfade definiert, §5.9 Pkt. 5 behandelt `log.md` gesondert als erlaubtes Membrum).
**Determinismus-Selbsttest (Membership + Identität):** Der Selbsttest prüft nicht nur Zwei-Run-Identität, sondern zusätzlich, dass die Ausgabe **Mengen-Genauigkeit** hat (nur Concept-Pfade, `log.md` ausgeschlossen) — er wird gegen einen mini-Sandbox-Baum ausgeführt, der einen realen Term auf Concept-Bodies und `log.md` verteilt und die exakte Candidate-Liste als erwartete Ausgabe pindet. Damit ist die Stale-Verifikations-Falle („das Artefakt widerlegt sich selbst") geschlossen.
## Verification
**Commands (re-executierbar, ab Workspace-Root):**
-`rg -l '<term>' -g '!log.md' wiki/` (rgs native Glob-Exklusionsform; `--exclude` ist kein rg-Flag — das GNU-grep-Äquivalent ist `grep -rl '<term>' --exclude=log.md wiki/`) zweimal ausführen, Ausgaben **identisch** — deterministische Erhebung ohne `log.md`-Kontamination; z. B. `rg -l 'A0-18' -g '!log.md' wiki/` → genau `wiki/knowledge-kompilation-inkrementell.md` (ein Concept-Pfad, `log.md` ausgeschlossen); `rg -l 'A0-18' wiki/`**ohne** Exklusion hingegeben würde `wiki/log.md` mit-treffen (Selbstkontamination — genau der ausgeschlossene Fall).
- mini-Sandbox-Baum (`_bmad-output/implementation-artifacts/sandbox-3-2/`, re-executierbar via `bash run-sandbox.sh` — Term auf Concept-Bodies **und**`log.md` verteilt): exakte Candidate-Liste (nur Concept-Pfade) wie erwartet; Normalisierung Strip `wiki/` + `.md` → relative OKF-Pfade; zwei aufeinanderfolgende Läufe liefern byte-identische Ausgaben (Zwei-Run-Identität, AD-17h).
4.**Validator-Lauf:** alle `wiki/`-Dateien SUCCESS (unverändert; reine Text-Instruktion, human-mechanisch ausgeführt, D-3) — per-Datei-Verdikt als Ausführungs-Nachweis im `log.md`-Eintrag.
5.**Resolver-Materialisierung:**`schema/canonical-terms.md` existiert (committete, append-only Registry: canon. Form + erlaubte Varianten); `grep -n "canonical-terms" schema/compiler.md` liefert die §3.2-Referenz. <br>_(Optionale Em-Dash-Prüfung: die Normalisierungs-Klasse deckt `-` ab; explizite `—`-Varianten-Resovierung ist eine erkannte Determinismus-Lücke → Story 3.8, s. Spec Change Log.)_
**Manual checks:**
- §3 Pkt. 2 zeigt auf die neue §3.2-Mechanik; Term-Ziehverfahren + Kanonisierungs-Resolver textuell benannt; Candidate-Liste als relative OKF-Pfade ohne `.md`; Determinismus-Vertrag in der Instruktion; `compiler.md` §8-Revision 2.5 + 2.6 mit Abschlussklausel; kein `schema/validator.md`-/`schema/wiki-compiler.md`-/`raw/`-Diff; §7-Vorbehalt ohne „3.2"; `wiki/log.md`-Eintrag datiert mit Story-3.2-Semantik, Determinismus-Beleg, Statuswechsel `backlog → in-progress → done` (Patch-Note Rev 2.6 oben), per-Datei-Verdikt; `deferred-work.md`-epic-3-context-Eintrag als aufgegriffen markiert + Em-Dash-Defer (Story 3.8); `sprint-status.yaml` konsistent (`3-2-…` → done).
Diese Datei ist die einzige committete Registry des **kanonischen Schreibweisen-Resolvers** der Relevanzbestimmung (§3.2 der Compiler-Instruktion). Sie macht die Normalisierung eines gezogenen Terms **deterministisch pinbar**: weil sie selbst Teil des Git-States ist, ist bei gleichem Git-State die Auflösung „Schreibvariante → canonische Form" eindeutig (AD-17h/A0-19). Sie wird ausschließlich **append-only** gepflegt — bestehende Einträge werden nie verändert, neue Einträge werden nur angehängt (Ergänzung einer neu erkannten canonischen Form/Synonymgruppe).
**Geltungsbereich:** Die Registry normalisiert **Fachbegriffe** der Relevanzbestimmung (entscheidungsrelevante Terme nach §3.2-Term-Ziehverfahren). Sie fügt **kein** Frontmatter-Feld, **kein** Schema-Prädikat, **keine** §7-Invaliditätsklasse, keinen Validator-/Vertrags-/`raw/`-Change hinzu (AD-3, D-3).
## Registry-Format
Je Eintrag (eine Zeile in der Tabelle):
- **canonische Form** — der normalisierte Term als Kebab-Case-Slug (Nur-Kleinbuchstaben `[a-z0-9-]`, `-`-Kollaps). Genau **eine** canonische Form je Semantik (A0-18).
- **erlaubte Schreibvarianten** — Schreibweisen, die auf die canonische Form normalisiert werden (bündel-findend per `-`-Kollaps: `[-–_ ]` → `-`, lowercased gemäß §3.2-Normalisierung). `[]` = keine weitere Variante (nur die canonische Form selbst gilt), bzw. noch keine Einträge committet.
- **Semantik** *(optional)* — disambiguierende Kurzangabe, warum dieser Term eine eigene canonische Form trägt (nur bei Bedarf; ergänzt die canonische Form, ist aber nicht Teil der Normalisierungslogik).
**Append-only-Regel:** Neue Zeilen werden am Ende der Tabelle angehängt; ein bestehender Eintrag wird **nie** editiert. Muss eine Semantik umbenannt werden, wird das in `deferred-work.md` als Mapping-/AD-7d-Nähe-Fall notiert (Ask-First), nicht durch Edits in dieser Registry.
## Registry
| canonische Form | erlaubte Schreibvarianten | Semantik |
|---|---|---|
| — (noch keine Einträge committet) | `[]` | Die Registry ist leer. Mit dem ersten Run, der einen fachlichen Term deterministisch zieht (Story-3.2-Term-Ziehverfahren, §3.2), wird der erste Eintrag hier committet (append-only). |
*Hinweis (Eröffnungs-Zustand):* Für die Story-3.2-Instruktion selbst ist kein Term-Eintrag erforderlich — die Relevanzbestimmung ist auch mit leerer Registry vollständig definiert (gezogene Terme werden wie notiert verwendet, solange keine canonische Auflösung committet ist; §3.2 Pkt. 1 — kein stiller Ausschluss). Die committete, leere Registry ist der deterministisch pinbare Resolver-Zustand.
## 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. Diese Datei ist ein neues Artefakt unter `schema/`, nebengeordnet zur Compiler-Instruktion — gleiche read-only-Hierarchie (nur der append-only-Ausbau ist vorgesehen).
@@ -38,10 +38,30 @@ Bestätigung (Story 1.4): schema/validator.md (mechanische Prüfung, kein L
1. Vor der Anlage prüfen, ob die erkannte Wissenseinheit **bereits als Concept** im Bundle existiert (deterministisch: Dateikollision über den relativen OKF-Pfad, AD-7a).
2.**Update-Routing (statt Kollision-Hold; Story 3.1):** Existiert bereits ein Concept mit dem Ziel-Pfad, wird **nicht** stumm überschrieben und **kein** Duplikat angelegt — die erkannte Wissenseinheit wird als **Update-Kandidat** im **bestehenden Concept-Pfad** aktualisiert (Erweitern/Präzisieren/Korrigieren gemäß §5.9; FR-6). Die Mutationsmechanik für Updates spezifiziert §5.9; der Kollisions-Hold-Schutzprinzip („nicht stumm überschreiben") bleibt als Grundsatz der Erhaltung erhalten (AD-16-Default: bestehende Provenienz/Inhalte werden nie ohne Beleg entfernt). Der **Neu-Anlage-Pfad** dieser Instruktion bleibt für Wissenseinheiten, deren Ziel-Pfad **nicht** belegt ist (§5.1/§5.7).
**Kandidatenliste (betroffen-Bestimmung):** Vor jeder Mutation erhebt der Producer die Menge der betroffenen Concepts als **nachvollziehbare Kandidatenliste** (relative OKF-Pfade ohne `.md`) mit **textuell-deterministischen Mitteln** (AD-13): (a) Term-/Konzept-Überschneidung zwischen der neuen Evidenz und den bestehenden Concept-Bodies via `grep`/`ripgrep` über `wiki/` (z. B. `rg -l '<konzeptterm>' wiki/`); (b) `index.md`-Traversal (Bundleroot- und Area-`index.md`-Dateien, gewurzelte Erreichbarkeit Root → Area → Concept, §5.8) der dadurch betroffenen Bereiche; (c) Link-Following aus bereits betroffenen Concepts (§5.6-Pin) auf weitere Concept-Pfade — **mit besuchter Menge** (ein bereits besuchter Concept-Pfad wird nicht erneut besetzt; keine Schleife bei zyklischen Links). Der `<konzeptterm>` aus (a) wird in Phase (1) (Interpretieren, §2) aus der neuen Evidenz abgeleitet — die Erhebung *mit festem Term* ist textuell-deterministisch (fester Term → deterministische Grep-Ausgabe); die Term-*Auswahl* folgt der §2-Interpretation, und der feinkörnige Term-Mechanismus (Kanonisierung, Synonyme) ist Story 3.2 vorbehalten. Die Kandidatenliste wird textuell festgehalten (Pre-Run-Reconcile-Check-Block, §5.9 Pkt. 6). Keine Embeddings/Vector-Suche (AD-13); der feinkörnige Relevanz-Findungsmechanismus als eigene Ausformulierung ist Story 3.2 vorbehalten — §5.9 bindet die Erhebung an die hier genannten deterministischen Mittel.
**Kandidatenliste (betroffen-Bestimmung):** Vor jeder Mutation erhebt der Producer die Menge der betroffenen Concepts als **nachvollziehbare Kandidatenliste** (relative OKF-Pfade ohne `.md`) mit **textuell-deterministischen Mitteln** (AD-13): (a) Term-/Konzept-Überschneidung zwischen der neuen Evidenz und den bestehenden Concept-Bodies via `grep`/`ripgrep` über `wiki/` (z. B. `rg -l '<term>' -g '!log.md' wiki/` bzw. GNU-grep-Form `grep -rl '<term>' --exclude=log.md wiki/`); (b) `index.md`-Traversal (Bundleroot- und Area-`index.md`-Dateien, gewurzelte Erreichbarkeit Root → Area → Concept, §5.8) der dadurch betroffenen Bereiche; (c) Link-Following aus bereits betroffenen Concepts (§5.6-Pin) auf weitere Concept-Pfade — **mit besuchter Menge** (ein bereits besuchter Concept-Pfad wird nicht erneut besetzt; keine Schleife bei zyklischen Links). Die Erhebung folgt der feinkörnigen, verbindlichen Mechanik in **§3.2 Relevanzbestimmung (Story 3.2)** — Term-Ziehverfahren (deterministisch aus der neuen Evidenz abgeleitet, kanonischer Schreibweisen-Resolver `schema/canonical-terms.md`, mehrere Terme je Einheit), dreistufige Erhebung mit `log.md`-Exklusion (die Candidate-Liste ist auf Concept-Pfade definiert, `log.md` ist kein Kandidat) und Determinismus-Vertrag (AD-17h/A0-19) — **Erhebung nach §3.2**. Die Kandidatenliste wird textuell festgehalten (Pre-Run-Reconcile-Check-Block, §5.9 Pkt. 6). Keine Embeddings/Vector-Suche (AD-13); §5.9 bindet die Erhebung an die in §3.2 genannten deterministischen Mittel.
Löst eine erkannte Wissenseinheit auf **keinen** bestehenden Concept-Pfad auf (kein Update-Kandidat), wird sie als **neue** Einheit über den Neu-Anlage-Pfad (§5.1/§5.7, §3-Pkt.-1/-2-Kollisionsprüfung ist damit erstbestanden) behandelt.
3. Der Run prüft zusätzlich, ob `wiki/index.md` als Bundleroot existiert (V-1-Vorbedingung des Validators); fehlt sie, darf kein Concept erzeugt oder aktualisiert werden (Run-FAIL, Vertrag §2).
## 3.2 Relevanzbestimmung (Story 3.2)
Diese Sektion ist der **einzige Instruktions-Ort** der feinkörnigen, **textuell-deterministischen Relevanz-Findungsmechanik** (D-3, Story 3.2) und die **verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung** („Erhebung nach §3.2"). Sie macht die Relevanzbestimmung vollständig deterministisch vorgegeben (AD-17h/A0-19): gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge — ohne Embedding/Vector/KG im Compiler-Kern (AD-13, A0-18, PRD OQ-3). Sie fügt **kein** Prädikat, keine neuen §7-Invaliditätsklassen und keinen Schema-/Validator-/`raw/`-Change hinzu (AD-3); die Candidate-Liste ist auf Concept-Pfade definiert, `log.md` ist ausdrücklich **kein** Kandidat (sie wird per Exklusions-Flag strukturell exkludiert — sonst wäre der eigene `log.md`-Eintrag bei jedem Term, den er zitiert, selbst „Kandidat"; die tool-spezifischen Flag-Formen nennt Pkt. 2a — `rg -g '!log.md'` bzw. `grep --exclude=log.md`; §5.9 Pkt. 5 behandelt `log.md` gesondert als erlaubtes Mitglied des Diff-Selbsttest-Satzes).
1.**Term-Ziehverfahren (deterministisch):** Die Candidate-Terme werden deterministisch aus der neuen Evidenz (committete `raw/`-Dateien, §1 Pkt. 1/2) abgeleitet — nicht freie LLM-Auswahl:
- **(a) Bedeutungstragende Token-Folgen:** Der Producer benennt die bedeutungstragenden Fachbegriffe der Wissenseinheit gemäß der §2-Interpretation (fachliche Signifikanz; kein Stoppwort-Abgleich nötig, aber auch kein freies Urteil). Der Umfang „bedeutungstragend" ist die Auswahl derjenigen Begriffe, die das erkannte Thema identifizieren — als Token-Folgen über eine sprachliche Einheit hinweg zulässig (z. B. `quanten-protocol-schlüssel`).
- **(b) Normalisierung über den kanonischen Schreibweisen-Resolver:** Jeder gezogene Term wird durchgängig normalisiert: (i) lowercasing; (ii) Binde-Varianten-Kollaps `[-–_ ]` → `-` (En-Dash `–`, Bindestrich `-`, Unterstrich `_`, Leerzeichen — jedes Vorkommen wird in einen einzelnen Bindestrich kollabiert); (iii) Auflösung über die committete, append-only Registry **`schema/canonical-terms.md`** (ein Eintrag = canonische Form + erlaubte Schreibvarianten; der Resolver ist damit Bestandteil des Git-States und die Auflösung pinbar). **Genau eine canonische Form je Semantik** (A0-18). **Kein stiller Ausschluss:** ist eine Variante nicht in der Registry auflösbar, wird der Term **wie notiert** verwendet (Kollaps-normalisiert) — niemals still verworfen.
- **(c) Mehrere Terme je Einheit erlaubt:** Eine Wissenseinheit kann mehrere bedeutungstragende Terme tragen; die Candidate-Liste ist dann die **Vereinigung** der Treffer über alle Terme, bereinigt über die besuchte Menge (Pkt. 3c — ein Pfad nur einmal).
- **Bekannte Determinismus-Lücke (aufgezeichnet, nicht still hinzugefügt):** Die Kollaps-Klasse `[-–_ ]` deckt den Em-Dash `—`**nicht** ab (nur En-Dash `–`). Em-Dash-Varianten fallen damit nicht unter den Kollaps — eine erkannte Synonym-Lücke, die **Story 3.8** als offene Determinismus-Frage übergeben ist (s. `deferred-work.md`; nicht stillschweigend in §3.2 ergänzt).
2.**Term-übergreifende Erhebung über `wiki/` (drei Stufen):** Der Producer erhebt die betroffenen Concept-Pfade in **drei textuell-deterministischen Stufen** (a → b → c). Ab der Workspace-Root:
- **(a) Stufe a — grep/ripgrep über `wiki/`:** `rg -l '<term>' -g '!log.md' wiki/` (rgs native Glob-Exklusions-Syntax — `--exclude` ist kein rg-Flag; das GNU-grep-Äquivalent ist `grep -rl '<term>' --exclude=log.md wiki/`, §5.6-Scan-Scope-Konvention). `<term>` = jeder gezogene Term aus Pkt. 1 nach Normalisierung. Beide Formen exkludieren `log.md`**strukturell** (unabhängig von dessen Inhalt) — die Candidate-Liste bleibt auf Concept-Pfade definiert.
- **(b) Stufe b — `index.md`-Traversal:** Für die in Stufe a getroffenen Bereiche (und die Bundleroot) folgt der Producer der gewurzelten Erreichbarkeit Root → Area → Concept (§5.8): trifft ein Term nur `wiki/index.md` oder eine Area-`index.md` (nicht einen Concept-Body), so sind alle **darunter gewurzelten Concept-Pfade** Treffer der Stufe b (TRAVERSAL_REACH_ONLY). Fehlende Bundleroot → Run-FAIL (V-1, §3 Pkt. 3, besteht fort).
- **(c) Stufe c — Link-Following mit besuchter Menge:** Aus bereits als betroffen erhobenen Concepts folgt der Producer die Concept-Links (§5.6-Pin) auf weitere Concept-Pfade — file-relativ auflösen (§5.7 Pkt. 4), **jeder bereits besuchte Concept-Pfad wird nicht erneut besucht** (besuchte Menge): Zyklen (A → B → A) enden, die Candidate-Liste bleibt endlich (LINK_FOLLOWING_ZYKLUS).
- **(a) Form:** Die Candidate-Liste ist die Menge der betroffenen Concept-Pfade als **relative OKF-Pfade ohne `.md`** (AD-7a). Normalisierung der Ausgabe: aus jedem Treffer `wiki/<pfad>.md` werden `wiki/`-Präfix und `.md`-Suffix gestrippt (deterministischer Schritt → `wiki/knowledge-kompilation-inkrementell.md` wird `knowledge-kompilation-inkrementell`).
- **(b) Reihenfolge (Zuwachs-Sicht-Ordnung):** Die Erhebung ordnet die Candidate-Liste deterministisch in **Zuwachs-Sicht-Ordnung** — Stufe-a-Treffer zuerst (in der Reihenfolge des ziehenden Terms, dann lexikografisch als deterministischer Tie-Break bei identischem Ort), danach Stufe-b-Treffer, danach Stufe-c-Treffer; innerhalb jeder Stufe lexikografisch aufsteigend (LC_ALL=C bzw. deterministische byte-Ordnung, AD-17h). Die Stufe-b/c-Treffer sind damit **positional bestimmt** (nach allen Stufe-a-Treffern), nicht vom Dateisystem-Traversal abhängig.
- **(c) Keine Duplikate:** Vereinigung über alle Terme und Stufen, bereinigt über die besuchte Menge (Pkt. 1c/2c) — jeder Pfad erscheint genau einmal.
- **(d) NO_MATCH:** Trifft kein Term ein bestehendes Concept, ist die Candidate-Liste **leer** → `UNTOUCHED_CONCEPT` (Story-3.1-Pfad): keine Mutation, kein `log.md`-Zusatz (leere Menge ist Teilmenge jeder erlaubten Menge — Ghost-Diff-negativ, §5.9 Pkt. 5).
- **(e) Gleichheits-Identität:** Gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge (AD-17h/A0-19). Der Selbsttest (Membership + Zwei-Run-Identität) wird in der Story-Specifizierungs-Verifikation und im `wiki/log.md`-Nachweis belegt.
## 4. Synthetisieren (Provenienz & Trust)
Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
@@ -196,7 +216,7 @@ Bereichszuordnung und Concept-Hierarchie sind **textual-deterministisch** (AD-7c
Eine als Area gedachte Anlage (`wiki/<area>/index.md` + Concept darunter) ist damit **konform**; der Bereichs-Hinweis aus §5.1 ist aufgelöst. Konzept-`id`s (s. `sources[].id`, §5.5 Pkt. 3) sind unabhängig davon je Concept eindeutig — Adressraum ist Concept-Pfad + `id`.
3. **Top-Level-Update-Routing (A0-10, §3-nachgeführt):** Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3.1/§3.2, AD-7a), löst das **Update-Routing (§3 Pkt. 2, §5.9)** aus — **kein** neues Prädikat, **kein** Duplikat, **kein** stiller Overwrite, keine neue Datei, kein Index-Link: die erkannte Einheit wird als **Update-Kandidat** im bestehenden Concept-Pfad behandelt (Mutation gemäß §5.9). **Kein MOVE/Neuzuordnung bestehender Concepts** — das ist Kuratierung mit AD-7d-Redirect-Pflicht (Epic-3-Nähe, nicht in den ACs dieser Story; Ask-First).
3. **Top-Level-Update-Routing (A0-10, §3-nachgeführt):** Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3 Pkt. 1/2, AD-7a; „§3.2" meint hier §3-Elemente Pkt. 1/2 — die §3.2-Relevanzbestimmung ist eine eigene Sektion, s. §3.2), löst das **Update-Routing (§3 Pkt. 2, §5.9)** aus — **kein** neues Prädikat, **kein** Duplikat, **kein** stiller Overwrite, keine neue Datei, kein Index-Link: die erkannte Einheit wird als **Update-Kandidat** im bestehenden Concept-Pfad behandelt (Mutation gemäß §5.9). **Kein MOVE/Neuzuordnung bestehender Concepts** — das ist Kuratierung mit AD-7d-Redirect-Pflicht (Epic-3-Nähe, nicht in den ACs dieser Story; Ask-First).
4. **File-relatives Link-Auflösungsmodell (löst das §5.6-Defer):** Concept-Links sind **file-relativ** zur `.md`-Datei (AD-8/FR-10/AD-7b — eine syntaktische Form, beide Ebenen): bei Root-Dateien ist file-relativ ≡ bundle-relativ (die bestehenden Bestands-Links bleiben byte-identisch, Null-Delta zu Story 2.3); in Areas bezeichnen `../`-Präfixe die Aufwärts-Ziele **innerhalb `wiki/`** (`[<text>](../<root-concept>.md)`). Auflösung & Containment (§5.6 Pkt. 3, Formel 3): `../`-Ziel relativ zum Quell-Verzeichnis auflösen, `X/..`-Segmente kollabieren, aufgelöster Pfad MUSS unter `wiki/` bleiben — sonst `DANGLING` (Out-of-Bundle-`..`-Escape gesperrt, Loop-1-Fix). `../schema/*` als andere Schicht (Ziel außerhalb des Bundles) bleibt exkludiert — Abgrenzung über das **Zielverzeichnis** (unter `wiki/` = in-Bundle), nicht über das bloße `../`-Präfix; einstufiges `../schema/*` aus Root-Dateien ist damit weiterhin pin-frei (bestehende Root-`index.md`-Links unverändert). `.md`-Endung bleibt Pflicht (§5.6 Pin).
5. **Area-`index.md` (Vertrag §2/§6, AD-9/FR-11):** Eine Area besitzt exakt eine `wiki/<area>/index.md`, **frontmatterlos** (Punkt 10), die ihre Area-Concepts in der gepinnten Form (§5.6) verlinkt (Identity = relativer OKF-Pfad ohne `.md`). Die Bundleroot-`index.md` verlinkt die Area-`index.md` (Navigation Root → Area, AD-9). **Area ohne `index.md` ist strukturell invalide** und wird vom Validator wörtlich gemeldet: `FAIL … Punkt 11: Index-Regel verletzt (Area ohne index.md=<area>)` (kein inventiertes Label; Verdikt-Grammatik §5 des Validators). Ein neues Area-Concept MUSS in `wiki/<area>/index.md` verlinkt sein (§5.3 Pkt. 3 ist entsprechend §5.7-nachgeführt); sonst Punkt 11.
6. **Worked Example (Area-Concept):** `wiki/wissensarchitektur/source-material.md` — ein neues Area-Concept: `type: concept`, `sources` → `raw/architecture-spine/architecture-spine-2026-08-14.md` (s1) + `raw/prd/prd-wow20-2026-08-14.md` (s2), §5.5-Inline-Verweise je belegter Aussage, Body-Links auf Root-Concepts in der file-relativen `../`-Form (`[LLM-Wiki-Prinzip](../llm-wiki-prinzip.md)` u. ä.), inhaltsbegründet. Verlinkt in der Area-`index.md` `wiki/wissensarchitektur/index.md` (frontmatterlos, gepinnte Form); diese wiederum in der Bundleroot `wiki/index.md` (Area-Sektion). §5.6-Formel-1 (Bestands-Check) erfasst die Area-Links; Formel 2 (Form-Check) `0`; Formel 3 (Dangling-Check) keine Ausgabe (in-Bundle-`../`-Auflösung, §5.7 Pkt. 4).
@@ -259,7 +279,7 @@ Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik
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).
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' wiki/` das bestehende Root-Concept `wiki/knowledge-kompilation-inkrementell.md` (Term-/Konzept-Überschneidung — re-executierter Befund: der Grep-Ausgabe-Pfad ist `knowledge-kompilation-inkrementell`; 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).
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)
@@ -316,7 +336,7 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
- **Eine genau-eine-Linkform** (file-relativ mit `.md`-Endung, in Areas `../`-fähig) — in **§5.6** dieser Instruktion gepinnt (Story 2.3; AD-7b, A0-9, FR-10; Auflösungsmodell §5.7 Pkt. 4) — der Punkt-11-Check des Validators akzeptiert bis auf Weiteres beide Schreibweisen (strukturell unverändert, Story-2.2-Präzedenz).
- **Synthese über mehrere Concepts** (mehrere Sources → eine gemeinsame Wissensrepräsentation mit gemischter, claim-granularer Provenienz) → **Epic 3, Story 3.4** (AD-4, FR-7). Die Verankerung des inkrementellen Datenflusses (Erweitern/Präzisieren/Korrigieren einzelner bestehender Concepts) bleibt **§3 + §5.9** überlassen und ist dort bereits verankert (Story 3.1) — sie ist damit aus diesem Vorbehalt entlassen.
- **Leasing / Dirty-Tree-Schutz** für konkurrierende Producer → **Story 3.5/3.6** (AD-17a..f, A0-12..A0-16); die bestehende Commit-Boundary = Mutations-Boundary-Regel (§0/§5.3, AD-17f) bleibt in v1 bestehender Schutz.
- **Feinkörnige Relevanz-Verfeinerung** (eigene Ausformulierung des Relevanz-Findungsmechanismus) → **Story 3.2**; Story 3.1 bindet die Kandidatenerhebung an die in §3 Pkt. 2 genannten textuell-deterministischen Mittel (grep/ripgrep, `index.md`-Traversal, Link-Following; AD-13).
- **Relevanzbestimmung** (feinkörniger Relevanz-Findungsmechanismus der Kandidatenerhebung) — in **§3.2** dieser Instruktion verankert (Story 3.2; Term-Ziehverfahren + Kanonisierungs-Resolver `schema/canonical-terms.md`, drei Erhebungs-Stufen grep/ripgrep + `index.md`-Traversal + Link-Following mit besuchter Menge, `log.md`-Exklusion, Candidate-Liste als relative OKF-Pfade ohne `.md`, Determinismus-Vertrag AD-17h/A0-19). Keine neue §7-Klasse, kein Schema-/Validator-Change; die Em-Dash-`—`-Varianten-Lücke ist als Determinismus-Frage an Story 3.8 übergeben.
- **Standalone-Compiler / eigene LLM-Runtime / MCP** → verboten in v1 (D-3, D-4, AD-11).
- PRD §4.3 (FR-11 — progressive Discovery, §5.7 Pkt. 5/§5.8) und §8.2/§8.3 (Canonical State; Separation of Concerns), **PRD OQ-3 („Compilation Scope" — wie findet der Compiler relevante vorhandene Concepts; textuell-deterministische Relevanzbestimmung, §3.2; AD-13/A0-18; Muster `raw/architecture-spine/…md` §8.3)**.
**Revisionslog:**
@@ -349,4 +369,6 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
- **Revision 2.3 (2026-08-18, Story 2.5):** Neue Sektion **§5.8 „Progressive Discovery über `index.md` (Story 2.5)"** eingefügt (nach §5.7, vor §6): (1) **Discovery-Pfad** (Bundleroot `wiki/index.md` → Area-`index.md` frontmatterlos → Area-Concepts in gepinnter §5.6-Form; Root-Concepts direkt aus der Bundleroot — AD-9/FR-11, gewurzelte Erreichbarkeit Root → Area → Concept), (2) **gewurzelte Erreichbarkeit als deterministisches Discovery-Kriterium + re-executierbarer Selbsttest** (`UNREACHABLE AREA: <area>` für unverlinkte Area; `NESTED AREA: <area>` für Zwei-Ebenen-Kandidaten inkl. der Area-ohne-`index.md`-Lücke `wiki/a/b/concept.md`; gekoppelte Meldungen an den Run-Nachweis gemäß §5.6-Pkt.-4-analoger NFR-4-Regel; Instruktions-Selbsttest, **keine** neue §7-Klasse — schließt die Validator-Navigation-Lücke, ohne Validator-Change, AD-3), (3) **konsolidierte Zwei-Ebenen-Kartografie** (respondiert Defer **F-07**, schließt es): Root + eine Area-Ebene; `wiki/a/b/` ist keine zugelassene Anlageform — der Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (keine Datei, kein Index-Link, Meldung `NESTED AREA: <area>`, Run „teilweise erfolgreich"); §3.2 bleibt der Dateikollision bestehender Concepts vorbehalten (Loopback-1-Renegotiation, Option A); (4) **Suche = Consumer-grep** (`grep -n <term> wiki/` / ripgrep, AD-13 — keine Such-Datenbank, kein Embedding, kein Index-Datei-Format), (5) **Discovery-Demo (optional, kein MOVE)** — Hinweis auf Formel-4-Re-Baseline-Pflicht bei Durchführung. Nachgeführt: **§7** (Story-2.5-Vorbehalt auf „Suche"-Rest gekürzt — Navigation/Area-Indizes jetzt in §5.8 verankert, Suche = Consumer-Thema; die Vorbehalt-Zeile lag in der Baseline `main` bei Z. 253, nach dem §5.8-Einschub bei Z. 285), **§8-Normreferenzen** (AD-9/AD-13 → §5.8, FR-11 → §5.8/§5.7 Pkt. 5, NFR-3 neu, PRD-§4.3-Zeile nachgeführt) + **Revisionslog 2.3**. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/` (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.
- **Revision 2.4 (2026-08-18, Story 3.1):** Neue Sektion **§5.9 „Inkrementelles Update bestehender Concepts (Story 3.1)"** eingefügt (nach §5.8, vor §6) — Update-Stimulus (Reconcile-Kandidatenliste), Mutationsmechanik (Erweitern/Präzisieren/Korrigieren; `sources` nur um echte neue Belege; `generated.at` = aktueller Run-Zeitstempel; `verified` unangetastet), Index-/Link-Form unverändert (§5.6-Pin), `log.md`-Eintragspflicht („Story 3.1-Update"-Markierung; Disagreement-Fälle bleiben dokumentiert, keine Korrektur-Klassifikation hier — Epic-4-Interface), **Erhaltungs-Invariante + deterministischer Diff-Selbsttest** (`git diff --stat -- wiki/` ⊆ betroffene Concepts ∪ `log.md` ∪ Index; Ghost-Diff = textuell benannter Instruktions-Verstoß, FT-6/FR-12), Run-Vorphase-Bausteine (Defer **R-1** Change-Detection via `git diff` auf `raw/` + SHA-256-Record aus `source.md`; Defer **P2** Pre-Run-Reconcile-Check-Block — Zielpfade, EC-1-Existenz, Kandidatenliste, V-1), Worked Example. **§3 Reconcile:** Pkt. 2 Kollision-Hold (bisheriger Epic-3-Abbruch bei bereits existierendem Concept) **ersetzt** durch **Update-Routing** (bestehende Wissenseinheit → Update-Kandidat im bestehenden Pfad; kein Duplikat, kein stummer Überschreib; AD-16-Default-Erhaltung) + **textuell-deterministische Kandidatenliste** (Konzept-/Term-Überschneidung via `grep`/`ripgrep`, `index.md`-Traversal, Link-Following — AD-13; feinkörniger Mechanismus Story 3.2). **§0-Aufruf:** sechs Phasen für Neu-Anlage- und Update-Variante präzisiert; Reconcile/Mutieren betreffen auch bestehende Concepts. **§5.7 Pkt. 3 / §5.8 Pkt. 2/3:** Top-Level-Referenz von „§3.2-Kollisions-Hold" auf das Update-Routing (§3 Pkt. 2, §5.9) nachgeführt (die bisherige Epic-3-Abbruch-Formulierung ist vollständig entfernt). **§7:** Update-Thema aus dem Epic-3-Vorbehalt **entlassen** (verbleibende 3.x-Themen benannt: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6, Relevanz-Verfeinerung → Story 3.2); Scope-Einleitung um die Update-Variante geöffnet. **§8:** Normreferenzen um A0-6/FR-6/FR-12 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.
- **Revision 2.4.1 (2026-08-18, Story 3.1, Step-04-Review-Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt):** §5.9-Konsolidierung aus den drei Review-Layern — (1) Prüfgrundlage auf `validator.md` **Revision 9** angehoben (§0-Header, §8-Link), §8-Verlusttext um die Punkt-11-Area-Lesart (Rev-9) ergänzt; (2) §5.9 Pkt. 5 Diff-Selbsttest operationalisiert (Probe `git diff --name-only -- wiki/` statt `--stat`; Ergebnismenge ⊆ **Kandidatenliste** (explizit §3 Pkt. 2) ∪ `log.md` ∪ nachgeführte `index.md`; Rücksetzhilfe „ob der Ghost auf einem Kandidatenpfad liegt"); Klarstellung, dass `schema/compiler.md`/`deferred-work.md` **außerhalb** `wiki/` liegen und daher nicht Teil der Diff-Probe sind — der Story-3.1-Nachweis ist `wiki/log.md` (Differenz zu den 4 volle `git status --porcelain`-Einträgen); Diff-Erwartung für das reine Body-Update in Pkt. 7 auf `git diff --name-only` umgestellt, Ergebnismenge `wiki/log.md` + `wissensarchitektur/source-material.md` (keine `index.md`); (3) §5.9 Pkt. 3-Widerspruch aufgelöst (Index-Regel unverändert, `log.md`-Eintragspflicht bleibt ausgeschlossen — Präzisierung „kein `log.md`-Zusatz" war falsch, korrekt „kein Index-Zusatz"); (4) §5.9 Pkt. 2 um **Mehrfach-Treffer-Konsolidierung** ergänzt (mehrere Einheiten → 1 Update/`log.md`-Eintrag/`at`; Verarbeitungsreihenfolge = Auftreten in der Zuwachs-Sicht); (5) §5.9 Pkt. 1/6-Anker §1.1/§1.4 → **§1 Pkt. 1/Pkt. 4** (die tatsächlichen Label; §5.8-Pkt-2-Formel-Zeile bleibt historisch); (6) Ghost-Diff **Konsequenz** + Commit-Boundary-Umsetzung definiert (Rück-Rollen vor Run-Gültigkeit, `log.md`-Kopplung als Abbruch-Vorlauf „korrigierter Teil-Run"); (7) Defer-**R-1**-Baseline festgelegt (HEAD der vorherigen Mutations-Boundary); (8) §5.9 Pkt. 7-Worked Example auf den **realen Ist-Baum** gehoben (`raw/epics/epics-2026-08-14.md#FR-12`, `rg -l 'FR-12'`; das fiktive `epics-2026-08-18.md`/`payload` entfernt); (9) §5.8-Pkt-3-Revision-Feinschliff — die Rev-9-Lücke ist geschlossen; die Markierung ist Pkt. 3. **Abschlussklausel der Patch-Runde:** 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.6 (2026-08-19, Story 3.2, Step-04-Review Loop 2, Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt):** (1) **§4-Überschrift wiederhergestellt** — die §3.2-Einfügung (Rev 2.5) hatte die Überschrift **`## 4. Synthetisieren (Provenienz & Trust)`** verdrängt (der §3.2-Sektionskopf ersetzte die §4-Überschrift; der gesamte Frontmatter-Body hing kopflos unter §3.2; alle §4-Referenzen wären dangling geblieben). Der §4-Kopf ist zwischen §3.2-Body und dem Frontmatter-Body wieder eingefügt; die §4-Referenzen zeigen wieder auf eine existierende Sektion; der §3.2-Body blieb unverändert erhalten. (2) **rg-Flag-Defekt behoben (`--exclude` ist kein rg-Flag):** die Stufe-a-Form in §3-Pkt.-2, §3.2-Pkt.-2a, §5.9-Worked Example (Pkt. 7) und §7 nutzten `rg -l "<term>" --exclude=log.md wiki/` — nicht-existent (ripgrep 14.1.1: `rg --exclude` → `unrecognized flag`; GNU grep unterstützt `--exclude`, ripgrep nutzt `-g "!log.md"` / `--glob "!log.md"`). Die Instruktion nutzt jetzt tool-korrekte Formen: rg `rg -l "<term>" -g "!log.md" wiki/` (native Glob-Exklusion) bzw. GNU grep `grep -rl "<term>" --exclude=log.md wiki/`; die §5.6-Formeln (bereits GNU-grep) und §5.9-Pkt.-7-Erhebung adoptieren die Exklusion. Verified: `rg -l "A0-18" -g "!log.md" wiki/` → nur `wiki/knowledge-kompilation-inkrementell.md`; **ohne** Exklusion trifft `rg -l "A0-18" wiki/` zusätzlich `wiki/log.md` (Selbstkontamination — der ausgeschlossene Fall, §3.2-Pkt.-2a). (3) **§5.9-Worked Example (Pkt. 7) auf die Exklusions-Form gehoben** (`rg -l "FR-12" -g "!log.md" wiki/`), Kommentar `wiki/log.md` exkludiert gemäß §3.2-Pkt.-2a. (4) **Mini-Sandbox re-executierbar verankert** (`_bmad-output/implementation-artifacts/sandbox-3-2/run-sandbox.sh`, Muster Story-3.1-Sandbox S1–S6): Tests T1–T4 (Membership-Pin — Term auf Concept-Bodies UND `log.md` verteilt, Candidate-Liste nur Concept-Pfade; Zwei-Run-Identität AD-17h; NO_MATCH → leere Candidate-Liste → UNTOUCHED_CONCEPT; Mehrfach-Treffer → Vereinigung + lexikografische Ordnung). (5) **`deferred-work.md`-Em-Dash-Eintrag** append-only ergänzt (Home: Story 3.8) — die §3.2-Pkt.-1b-Kollaps-Klasse deckt En-Dash/Bindestrich/Unterstrich/Leerzeichen, aber **nicht** den Em-Dash `—`; dieser Handoff wird nicht stillschweigend gelöst, sondern als offene Determinismus-Frage dokumentiert. (6) **§3-Pkt.-2/§3.2-Präambel/§7-Nennungen** der Exklusion auf die tool-korrekte Form angehoben. **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. (Rev-2.5-Log-Eintrag bleibt unverändert — dokumentiert den Zustand bei Veröffentlichung der Revision 2.5, inkl. der damaligen `--exclude`-Form; historische Korrektheit des Logs.)
- **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-beankert), **A0-18** (Deterministische Relevanzbestimmung, §3.2) und **A0-19** (Determinsmus-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.
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.