wow20/_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md

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

title	type	created	status	review_loop_iteration	baseline_commit	context
Relevanzbestimmung textual-deterministisch umsetzen (grep/ripgrep + Markdown-Traversal + Link-Following) (Story 3.2)	feature	2026-08-19	in-review	2	e3e7ec346d	_bmad-output/implementation-artifacts/epic-3-context.md

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.
• sprint-status.yaml: Key 3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip → in-progress.

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).

I/O & Edge-Case Matrix

Scenario	Input / State	Expected Output / Behavior	Error Handling
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)

Code Map

• schema/compiler.md — primär mutiert (D-3, einziger Instruktions-Ort):
  • §3 Reconcile Pkt. 2 (:41): Story-3.2-Vorbehalt auflösen — der feinkörnige Term-/Relevanz-Mechanismus wird eingearbeitet (Term-Ziehverfahren, Kanonisierungs-Resolver, drei Erhebungs-Stufen grep/ripgrep + Traversal + Link-Following, Candidate-Liste als relative OKF-Pfade ohne .md, Determinismus-Beschreibung); verortet als neue Sektion §3.2 „Relevanzbestimmung (Story 3.2)" direkt nach §3 — Kern-Anker bleibt Pkt. 2 („Erhebung nach §3.2").
  • §7 Selbstbegrenzung (:319): Story-3.2-Vorbehalt entfernen („Feinkörnige Relevanz-Verfeinerung" entlassen) — verbleibende 3.x-Themen: Synthese → 3.4, Leasing/Dirty-Tree → 3.5/3.6.
  • §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.)
  • §1 Pkt. 1/4, §5.6, §5.7, §5.8 — read-only / nur Referenz (Linkform, Bereichszuordnung, Discovery bleiben unverändert).
• 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.
• _bmad-output/implementation-artifacts/sprint-status.yaml — mutiert: Key 3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip (:55) → in-progress.
• 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:

• 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.)
• 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.)
• 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.)
• 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.

Spec Change Log

• 2026-08-19 (bmad-code-review Loop 2 — bad_spec-Loopback): 5 bad_spec-Findings ausgelöst, Code-Änderungen auf Baseline revertiert, nicht-gefrorene Spec-Tail-Sektionen geamendet:
  • 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):

1. Vorbehalts-Auflösung: grep -n "Story 3.2 vorbehalten" schema/compiler.md liefert keinen Treffer mehr (beide Vorbehalte aufgehoben: §3 Pkt. 2 + §7).
2. Neue Sektion: grep -n "Relevanzbestimmung\|3.2" schema/compiler.md liefert die neue §3.2-Sektion; §7-Vorbehalt enthält „3.2" nicht mehr; §8 trägt Revision 2.5 + 2.6 (Patch-Runde: §4-Kopf, rg-tool-korrekte Formen).
3. Determinismus-Selbsttest (Membership + Identität):
   • 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.
   (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).