feat: Story 3.2 Code-Review-Loop-3-Patches (bmad-code-review, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4/D-5 = 1/1/1/1/1 + P-1/P-2) — compiler.md Revision 2.7, §3.2-Pkt.-3b-lexikografisch, canonical-terms-Lookup-Semantik + Invariante + Konflikt-Verfahren, Sandbox T5-T7 + T1/T4-Asssertionen (7/7 PASS), Stale-Beleg (b) korrigiert, Statuskette in-progress → done, P-2-Typos, Story done

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

schema/canonical-terms.md

@@ -15,11 +15,17 @@ Diese Datei ist die einzige committete Registry des **kanonischen Schreibweisen-
 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.
+- **erlaubte Schreibvarianten** — Schreibweisen, die auf die canonische Form normalisiert werden (bündel-findend per `-`-Kollaps: `[-–_ ]` → `-`, lowercased gemäß §3.2-Normalisierung). **Gespeicherte Form:** canonical-Form- und Variantenzeile tragen ausschließlich die **bereits normalisierte** Form (lowercased, `-`-gekollabst) — die Spalte enthält also nie das Roh-Notat, sondern dessen Normalisierungs-Resultat. `[]` = 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).
 
+**Lookup-Verfahren (deterministische Reihenfolge):** Die Auflösung eines gezogenen Terms folgt exakt dieser Ordnung: (1) **lowercasing**; (2) **Binde-Varianten-Kollaps** `[-–_ ]` → `-` (§3.2 Pkt. 1b); (3) **Lookup der normalisierten Form** in der Registry — Treffer in der Spalte *canonische Form* oder in der Spalte *erlaubte Schreibvarianten* → Ergebnis ist die **canonische Form** desselben Eintrags. Ist die normalisierte Form nicht auffindbar, gilt der Term **wie notiert** (Kollaps-normalisiert; §3.2 Pkt. 1b — kein stiller Ausschluss). Normalisierung und Lookup sind dadurch vollständig deterministisch: gleiche Normalisierungs-Regeln + gleiche Registry (Git-State) → gleiche Auflösung.
+
+**Eindeutigkeits-Invariante:** Jede normalisierte Form kommt in der Registry **genau einmal** vor — als canonische Form **oder** als Variante eines Eintrags, nie in beiden Spalten und nie in zwei Einträgen (auch nicht als Canon eines Eintrags und Variante eines anderen). Wird diese Invariante verletzt, ist der Resolver-Zustand nicht eindeutig auflösbar.
+
 **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.
 
+**Konflikt-Verfahren (keine stillen Anhängungen):** Soll ein neuer Eintrag eine normalisierte Form tragen, die bereits in der Registry vorkommt (Canon oder Variante — auch mit abweichender Semantik), wird **nicht** angehängt (das würde die Eindeutigkeits-Invariante verletzen): der Konflikt wird in `deferred-work.md` notiert und dem Nutzer als Ask-First-Frage vorgelegt (Analogie: Umbenennungsregel oben), bis eine Entscheidung eine eindeutige Auflösung erlaubt.
+
 ## Registry
 
 | canonische Form | erlaubte Schreibvarianten | Semantik |