5.4 KiB
Kanonischer Schreibweisen-Resolver — canonische Term-Formen (Story 3.2)
Status: abgeleitet (Story 3.2) — committete, append-only Registry des kanonischen Schreibweisen-Resolvers der deterministischen Relevanzbestimmung (Term-Ziehverfahren,
schema/compiler.md§3.2). Normative Grundlage:schema/compiler.md(abgeleitet, Story 3.1/3.2) — §3.2 Relevanzbestimmung (Term-Ziehverfahren, Kanonisierungs-Resolver, dreistufige Erhebung); AD-13 (textuell-deterministische Mittel), AD-17h/A0-19 (Determinismus-Vertrag: gleicher Git-State + gleiche Eingabemenge → gleiche Candidate-Liste in gleicher Reihenfolge), A0-18 (Deterministische Relevanzbestimmung), PRD OQ-3. Ableitungsdatum: 2026-08-19
Zweck
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). 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 |
|---|---|---|
| — (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).