wow20/schema/compiler.md

Compiler-Instruktion — OKF-Concepts aus Source Material erzeugen (Story 2.1)

Status: abgeleitet (Story 2.1) — deterministische, agent-unabhängige Compiler-Instruktion für die Erzeugung neuer Concepts aus Source Material. Normative Grundlage: schema/wiki-compiler.md (autorisiert, Story 1.3) — insbesondere §2 Bundleroot, §3 Feldsubset (§3.1–§3.7), §5 log.md-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen. Prüfgrundlage: schema/validator.md (abgeleitet, Story 1.4; Revision 8) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h). Ableitungsdatum: 2026-08-16 Kanonischer Producer-Actor: wow-compiler/0.1.0

0. Zweck & Aufruf

Diese Datei ist der einzige Ort der Concept-Erzeugungs-Instruktion des Projekts. Sie ist rein textuell — kein ausführbarer Code, kein Standalone-Programm (D-3). Sie wird von einem vorhandenen agentischen Host (AD-11) als deterministische Anweisung befolgt; sie ersetzt kein LLM-Reasoning, sondern kanalisiert es in eine reproduzierbare, textuell nachvollziehbare Abfolge (AD-5, AD-6, AD-17h).

Aufruf: Der Producer führt den Run in der folgenden festen Ablaufstruktur aus (deterministische Reihenfolge): (0) Input prüfen, (1) Interpretieren, (2) Reconcile, (3) Synthetisieren, (4) Mutieren, (5) Validieren. Jede erzeugte Concept-Datei MUSS anschließend gegen schema/validator.md als SUCCESS nachweisbar sein — erst dann gilt der Run als erfolgreich. Bei einem Validierungs-FAIL wird das Bundle nicht als erfolgreicher Run behandelt, raw/ bleibt unangetastet (AD-3), und die Fehlerursache ist textuell identifizierbar (NFR-4). Die Commit-Boundary ist die Mutations-Boundary (AD-17f): Zwischenstände vor Erreichen der Success-Bedingung werden nicht als fertige Mutation veröffentlicht.

Entscheidungsebenen (keine eigene Norm):

Behauptung (Normativ):  schema/wiki-compiler.md  (§7: abschließende 14-Punkte-Liste)
Ableitung (Story 2.1):  schema/compiler.md       (Erzeugungs-Instruktion)
Bestätigung (Story 1.4): schema/validator.md      (mechanische Prüfung, kein LLM-Urteil)

1. Input (was der Compiler konsumiert)

1. Voraussetzung: Der Run verarbeitet ausschließlich veröffentlichte (committete) Inhalte als Input (AD-17a — „Der Compiler darf nur veröffentlichte (committed) Inhalte als Input verwenden"); Zwischenstände während einer Mutation sind nie Input.
2. Evidenz: Das Source Material unter raw/ — jede Datei unter raw/, die als evidierenfähige Source verarbeitet wird, ist Evidenz (AD-2/AD-3). Vom Compiler erzeugte Concepts DÜRFEN ausschließlich auf solche raw/-Dateien als sources-resource zeigen.
3. Bestehendes Bundle: Das aktuelle wiki/ (Bundleroot index.md, log.md, bestehende Concepts) ist der zweite Input; der Run beginnt mit dem vorhandenen Bundle und verändert nur, was durch neue Erkenntnisse betroffen ist (AD-5 — niemals „Regenerate Everything").
4. Nicht-Evidenz (Artefakt-/Grenzdateien) sind KEIN Input: raw/README.md, jede raw/**/source.md (Provenienz-Sidecar), schema/, adapters/ — sie sind keine zu verarbeitende Evidenz und dürfen nie als sources-resource eines Concepts verwendet werden. (Dokumentarische Konvention der Source-Bereitstellung nach raw/README.md — eine nicht-mechanische Ausnahme zur Evidenz-Erwartung; zu verarbeitende Evidenz kann auch andere Formate als .md tragen, z. B. PDF.)

2. Interpretieren (Wissenseinheiten erkennen)

1. Der Producer liest die bereitgestellten Evidenzdateien und identifiziert darin abgegrenzte Wissenseinheiten (ein Thema, ein Konzept, ein zusammenhängender Sachverhalt).
2. Nicht 1:1 pro Dokument, nicht 1:1 pro Abschnitt (FR-5): Ein Dokument kann mehrere Wissenseinheiten enthalten, die in mehrere Concepts fließen; eine Wissenseinheit kann aus mehreren Abschnitten/Dokumenten stammen. Die Anzahl der Concepts ergibt sich aus den erkannten Einheiten, nicht aus der Datei- oder Abschnittszählung der Source.
3. Grenze der Interpretation (Curated ≠ Copy, FR-2/SM-2): Eine Wissenseinheit wird nur dann zum Concept, wenn sie eigenständig formuliertes kuratiertes Wissen ergibt. Bloße Kopie, das Einfügen großer Quellblöcke oder eine Zusammenfassung des Quelldokuments sind keine Wissensintegration und DÜRFEN nicht erzeugt werden.
4. Ein Concept wird in Deutsch formuliert (Projekt-Sprachkonvention) und ist für Menschen unmittelbar als Markdown lesbar (NFR-2).

3. Reconcile (gegen das bestehende Bundle)

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. Kollision-Hold: Existiert bereits ein Concept mit dem Ziel-Pfad, wird nicht stumm überschrieben. Diese Instruktion deckt die Anlage neuer Concepts ab; die Erweiterung/Präzisierung/Korrektur bestehender Concepts ist Epic 3 (AD-5, FR-6). Der Run bricht für diese Einheit mit einem textuell identifizierbaren Hinweis ab („Concept existiert bereits — Aktualisierung ist Epic 3") und setzt mit den übrigen erkannten Wissenseinheiten fort; die gehaltene Einheit erzeugt keine Datei, keinen Index-Link und keinen log.md-Eintrag. Mindestens eine erfolgreich erzeugte und mindestens eine gehaltene Einheit → der Run ist teilweise erfolgreich: die erzeugten Concepts werden normal validiert und veröffentlicht, die gehaltenen Einheiten werden textuell als solche benannt (NFR-4).
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 werden (Run-FAIL, Vertrag §2).

4. Synthetisieren (Provenienz & Trust)

Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:

1. type (Pflicht, §3.1): ein nicht-leerer String; für fachliche Wissenseinheiten ist concept die Standard-Klasse.
2. sources (optional, §3.3): Liste von Maps; je Eintrag MUSS resource gesetzt sein. Regeln:
   • resource ist ein /-getrennter relativer Workspace-Pfad innerhalb raw/ — nie wiki/ (AD-4b/Punkt 3), kein .., kein führendes /, kein Backslash/Windows-Trenner, keine URL-Form (Punkt 4).
   • Jede referenzierte Datei MUSS unter raw/ zum Zeitpunkt des Runs als Datei existieren (EC-1; Verzeichnisse sind unzulässig).
   • Zusätzlich zu resource sind optional zulässig: id, title, author, usage_count (Ganzzahl ≥ 0), last_modified (YYYY-MM-DD, reale Kalenderdaten).
   • Key-Subset je Eintrag (Innen-Ebene, Vertrag §3.3): Innerhalb eines sources-Eintrags sind ausschließlich die Felder resource, id, title, author, usage_count, last_modified erlaubt — jeder andere Key ist eine unautorisierte Verletzung und löst beim Validator Punkt 6 aus (nicht nur die Top-Level-Felder zählen).
3. generated (v1-Default, §3.4/A0-20): Map { by, at }. by ist zwingend und nicht leer; Produkt-Konvention: wow-compiler/0.1.0 (dieser Compiler). at ist der Ausführungszeitpunkt in vollem ISO-8601-Datetime (YYYY-MM-DDTHH:MM:SS mit Z/±HHMM/±HH:MM), nie ein reines Datum (Validator §4.3, Punkt 14). verified bleibt ungesetzt — maschinell erzeugt und ungeprüft (A0-20).
4. status/stale_after (optional): nur Werte aus §3.6 (draft/stable/deprecated) bzw. §3.7 (YYYY-MM-DD). Bei der Erzeugung neuer Concepts bleibt beides in der Regel ungesetzt — die Absenz von status bedeutet laut Vertrag §3.6 per Definition den Default stable; der Compiler trifft also bewusst keine Lebenszyklus-Entscheidung, sondern überlässt den Default der Vertrags-Semantik.
5. Frontmatter-Reihenfolge (kanonische Normalform, Validator §4.1): type, sources, generated, verified, status, stale_after. Duplikat-Keys sind verboten (Punkt 13). Keine unautorisierten Felder (Punkt 6); okf_version/type: bundle NIE in Concepts (Punkt 9).

5. Mutieren (Dateien schreiben)

1. Ziel-Pfad: Das neue Concept ist eine Markdown-Datei unter wiki/. Der Ziel-Pfad ergibt sich aus der deterministischen Bereichszuordnung (§5.7): (a) verweist bereits ein bestehender index.md-Link auf das erkannte Thema, wird das Concept in dessen Bereich angelegt (wiki/<area>/<concept-kebab-case>.md); (b) sonst Default Root-Ebene (wiki/<concept-kebab-case>.md). Nie Embedding/Vector (AD-7c, A0-10, AD-13). Die „Area-Zuordnung ist Story 2.4"-Backlog-Klausel ist mit §5.7 aufgelöst.
   • Konvention für den Dateinamen: kebab-case-Slug aus der Concept-Identität (kein Sonderzeichen, keine Endung .md-Dopplung). Der Dateiname definiert die Concept-Identität (relativer OKF-Pfad ohne .md, AD-7a).
2. Dateiinhalt: YAML-Frontmatter gemäß §4 (kein weiteres Feld), gefolgt von einem Markdown-Body, der die Wissenseinheit eigenständig und lesbar darstellt (NFR-2, NFR-3). Der Body darf keine großen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) folgt §5.5 — für neu erzeugte Concepts unmittelbar bei der Erzeugung, für bestehende Bodies per Nachrüstung (Story 2.2).
3. Index-Regel (Punkt 11/§6): Nach Anlage MUSS das neue Concept in der index.md seines Bereichs verlinkt werden — für Root-Concepts in der Bundleroot wiki/index.md, für Area-Concepts in der jeweiligen Area-index.md (wiki/<area>/index.md, §5.7) — seine Identität (relativer OKF-Pfad ohne .md) als relativer Bundle-Pfad referenziert; die genau-eine-Form-Festlegung ist in §5.6 gepinnt (file-relativ, mit .md-Endung; §5.7 Pkt. 4). Ohne diese Verlinkung ist das Bundle strukturell invalide (§7 Punkt 11).
   • All dies (Anlage + Verlinkung + log.md) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f). Bei Validierungs-FAIL wird der Teilzustand explizit zurückgerollt: neue Concept-Datei(en) gelöscht, zugehörige Index-Verlinkung(en) aus wiki/index.md entfernt, log.md-Eintrag(e) wieder entfernt — das Bundle nimmt seinen Zustand vor dem Run wieder ein (keine partielle Mutation bleibt liegen).
4. Dokumentation (log.md, Vertrag §5): Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in wiki/log.md dokumentiert (neueste zuerst; Header = ISO-Datum YYYY-MM-DD), verknüpft mit dem neuen Concept-Pfad und den genutzten raw/-Quellen. log.md bleibt ohne Frontmatter (Punkt 10).

5.5 Claim-granulare Provenienz (Story 2.2)

Provenienz ist claim-granular (AD-4a, A0-3): Nicht nur das Concept als Ganzes trägt sources, sondern jede belegte Aussage im Body trägt einen Inline-raw/-Verweis. Kontext-/Synthese-Umformulierungen — Aussagen, die nicht direkt auf raw/-Evidenz rückführbar sind, sondern aus Concept-Kontext, direkt aus einer rohen Quelle (ohne Zwischen-Concept) oder aus Synthese mehrerer Quellen stammen — tragen einen expliziten Kontext-Marker. Diese Sektion ist eine Body-Text-Konvention; sie fügt kein neues Frontmatter-Feld über das §3.3-Subset hinaus hinzu — das Hinzufügen bzw. Erweitern von sources-Einträgen (resource/id) IST Teil der Konvention (Relokation/Zielwechsel, Pkt. 1b) und kollidiert nicht mit dieser Selbstbegrenzung (AD-4a; der Vertrag §3 legt das Feldsubset abschließend fest). Sie gilt für Neu-Erzeugung und Nachrüstung bestehender Concept-Bodies gleichermaßen. wiki-compiler.md und validator.md bleiben unverändert (AD-3); diese Sektion ist der einzige Instruktions-Ort der Provenienz-Konvention (D-3, Story 2.2).

1. Inline-raw/-Verweis je belegter Aussage: Eine Aussage ist „belegt", wenn sie sich fachlich auf eine konkrete Evidenzstelle in raw/ zurückführen lässt. Sie trägt dann unmittelbar am Ende der Aussage (bzw. am Ende des zugehörigen Absatzes/Listenelements) einen Inline-Verweis in der verbindlichen Default-Form:

   (raw/<datei.md>#<stellen-kennung>)

   Daneben ist die Komma-Form als zulässige zweite Form festgelegt:

   (raw/<datei.md>, <stellen-kennung>)

   • Die Komma-Form wird verwendet, wenn die Stellen-Kennung im Rohdokument als Sektionstitel/Nummer ohne Bezeichner-id vorliegt (z. B. § 1 Vision, § 4.5 FR-16, § 0 Document Purpose) — ein #-Fragment wäre hier ein künstlicher Anker. Für Bezeichner-ids (FR-*, A0-*, AD-*) bleibt die #-Form die Default-Form. Die Form-Frage „(<pfad>) ggü. [<text>](<pfad>)" ist mit §5.6 geschlossen: Concept-Links (Concept-Bodies + wiki/index.md) stehen in der gepinnten Form; raw/-Provenienz-Verweise dieser Sektion bleiben in der Plain-/Komma-Form (andere Schicht — vom Pin ausgenommen, §5.6 Pkt. 2), sofern der volle raw/-Pfad am Verweis erkennbar ist und der Grep die Form erfasst (analog: beide Fragment-Formen #/Komma sind zulässig, sofern die Stellen-Kennung im Rohdokument existiert).

   • Die Stellen-Kennung (hinter # bzw. nach dem Komma) ist eine KENNUNG, die im referenzierten Rohdokument tatsächlich existiert — z. B. ein Bezeichner-id der rohen Datei (wie FR-12, A0-6, AD-5 in raw/epics/… bzw. raw/architecture-spine/…) oder der exakte Sektionstitel des Rohdokuments (z. B. § 1 Vision). Die Concept-eigene sources-Feld-id (s1, s2, …) ist NICHT als Fragment zu verwenden, weil sie im Rohdokument nicht existiert — der Verweis würde im Rohdokument nicht auflösen (keine Falsch-Attribution). Die sources-id dient ausschließlich der vertragsgemäßen internen Zitat-Attribution (Vertrag §3.3), nicht als Inline-Fragment.

   • Multi-Beleg-Serialisierung: Mehrere Belege desselben Rohdokuments innerhalb eines Inline-Verweises werden semikolon-getrennt mit vollem Pfad je Beleg aufgelistet: (raw/epics/epics-2026-08-14.md#FR-12; raw/epics/epics-2026-08-14.md#A0-6). Innerhalb eines Belegs dürfen mehrere #-Kennungen unter demselben Pfad komma-gruppiert werden, wenn sie dieselbe Stellen-Kennung-Form tragen: (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-2, #AD-3, #AD-1); bei gemischten Formen (#-Kennung + Sektionstitel) bleibt der Pfad je Beleg vollständig: (raw/architecture-spine/…md#AD-3; raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns). Keine Pfad-Elision über Beleg-Grenzen hinweg (also niemals allein #A0-6 ohne vorangestellten Pfad als eigenständiger Beleg).

   • Deterministische Selbsttest-Formel: Die Verweise sind per grep -nE '\(raw/' auffindbar (das Teilmuster (raw/ trifft beide Plain-Formen (raw/…) und die Markdown-Linkform [<text>](raw/…)). Die Formel ist als sh -c "grep -nE '\(raw/' wiki/*.md" re-executierbar und liefert deterministische Ausgabe (AD-17h).

   • 1a. Pfad-Form: ausschließlich /-getrennte relative Workspace-Pfade innerhalb raw/ — nie wiki/ (AD-4b), kein .., kein führendes /, kein Backslash, keine URL-Form (spiegelbildlich zu §4.2 und Vertrag §3.3). Um zusätzliche Validierungsoberfläche ohne importierte Struktur zu vermeiden, verweist der Inline-Beleg üblicherweise auf dasselbe raw/-Ziel, das auch im sources-Frontmatter des Concepts deklariert ist — die EC-1-Existenzprüfung (§6.5-Kriterium 3 / Validator §6.1) bleibt damit unverändert anwendbar.

   • 1b. Relokation/Zielwechsel: Zeigt eine Aussage auf einen anderen raw/-Pfad als die sources-Deklaration des Concepts (z. B. das ASCII-Diagramm aus raw/architecture-spine/… in einem Concept mit sources: raw/epics/…), so ist zusätzlich ein passender sources-Eintrag im Frontmatter zu ergänzen, dessen resource auf jenen Pfad zeigt (EC-1-Existenz, Punkt 3/4). Das Diagramm-Quell ist damit sowohl body- als auch frontmatter-seitig deklariert (Story-2.1-Instanz: ASCII-Diagramm in knowledge-kompilation-inkrementell.md).

2. Kontext-Marker je Übernahme (AD-4a/A0-3): Eine Übernahme ist eine Kontext-/Synthese-Umformulierung: Formulierung, die aus Concept-Kontext, direkt aus einer rohen Quelle oder aus der Synthese mehrerer Quellen stammt und nicht eigenständig gegen raw/ belegt ist. Es gibt drei Marker-Muster (zwei Grundmuster + Forward-Referenz-Variante) — alle MÜSSEN den exakten Token „nicht eigenständig belegt" enthalten (deterministischer Selbsttest, mindestens eine Form pro Übernahme):

   • Übernahme über ein Zwischen-Concept (Ursprungs-Concept existiert): minimal nach Vertrag §3.3/A0-3-Wortlaut

     übernommen aus <Concept-Pfad> auf Basis von <source>, nicht eigenständig belegt

     Dabei ist <Concept-Pfad> der relative OKF-Pfad des Ursprungs-Concepts ohne .md (AD-7a), <source> der zugrunde liegende raw/-Pfad. Kein Selbstreferenz-Muster: Ein Concept, das sich selbst als Ursprung nennt, ist Falsch-Attribution und verboten — gibt es kein Zwischen-Concept, ist Muster (2) zu verwenden.

   • Direktübernahme aus raw/ ohne Zwischen-Concept (z. B. ein Diagramm direkt aus einer rohen Datei):

     übernommen aus <source> (rohe Quelle), nicht eigenständig belegt

     Dabei ist <source> der zugrunde liegende raw/-Pfad.

   Die Marker stehen direkt bei der übernommenen Aussage (Absatz-/Listen-Ebene), damit die Zuordnung claim-granular bleibt. Epic-3/4-Fähigkeiten, die im Körper eines Concepts nur als Forward-Referenz erscheinen (noch nicht erzeugt/validiert), tragen die Forward-Referenz-Variante des Markers (drittes Muster) ebenfalls mit dem exakten Token — nicht eigenständig belegt, als Forward-Referenz übernommen (die „auf Basis von"-Angabe wird hier nur gesetzt, wenn nicht bereits aus der Kontext-/Konzeptzeile ersichtlich): „… als Forward-Referenz übernommen, nicht eigenständig belegt (raw/epics/epics-2026-08-14.md, Story 3.1: Inkrementellen Datenfluss implementieren)".

3. Eindeutiges id-Scoping (Vertrag §3.3): id-Werte in sources-Einträgen sind je Concept eindeutig (innerhalb eines Concepts darf kein id doppelt vorkommen). Über Concepts hinweg ist id nicht global eindeutig — der Adressraum ist der Concept-Pfad + id (AD-7a). Bei der Nachrüstung bestehender Concepts ohne id können ids deterministisch vergeben werden (s1, s2, … in Dokumentreihenfolge).

4. Selbsttest-Kriterien (AD-17h, Story-2.2-Projektion): Vor Abschluss eines Runs prüft der Producer:

   • Belegte Aussage → Inline-raw/-Verweis: Jede Aussage, die fachlich eine Evidenzstelle referenziert, trägt einen solchen Verweis mit vollem raw/-Pfad je Beleg (per grep -nE '\(raw/' auffindbar — erfasst auch die Markdown-Linkform).
   • Übernahme → Kontext-Marker: Jede Kontext-/Synthese-Umformulierung, jede Direktübernahme aus raw/ und jede Epic-3/4-Forward-Referenz trägt eines der drei Marker-Muster aus Pkt. 2 — alle enthalten den exakten Token „nicht eigenständig belegt".
   • Kein unautorisierter Key: Das Nachrüsten verändert ausschließlich den Body und die zulässigen §3.3-sources-Felder (resource, id, title, author, usage_count, last_modified); keine zusätzlichen Frontmatter-Felder, keine §7-Klasse (Punkt 6).
   • Wenn eine Aussage weder belegt noch als Übernahme markiert werden kann, wird sie als Übernahme mit Marker geführt — niemals erfunden belegt (UNBELEGTE_AUSSAGE: textuell sichtbar, Run bricht nicht ab).

5. Worked Example (grammatisch verbindlich, BH-13): Die folgende kanonische Form macht den §5.5-Standard eindeutig ablesbar. Eine belegte Aussage mit Inline-Verweis (voller Pfad, Fragment = im Rohdokument existierende Stellen-Kennung):

   Alle erzeugten Concepts sind OKF-0.2-konform (raw/epics/epics-2026-08-14.md#FR-9).

   Dasselbe als Komma-Form (Stellen-Kennung = Sektionstitel ohne Bezeichner-id im Rohdokument):

   Das zentrale Produktversprechen lautet: Knowledge should compound (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).

   Eine Übernahme mit Kontext-Marker — Direktübernahme eines Diagramms aus einer rohen Quelle (kein Zwischen-Concept, kein Selbstverweis):

   Das Datenfluss-Diagramm (Interpret → Reconcile → Synthesize → Update) stammt direkt aus der rohen Quelle raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5 — übernommen aus raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5 (rohe Quelle), nicht eigenständig belegt.

   Die Diagramm-Quell-Deklaration erfolgt zugleich frontmatter-seitig: gehört das Diagramm nicht zur sources-Deklaration des Concepts, wird ein zusätzlicher sources-Eintrag ergänzt (Pkt. 1b — Relokation/Zielwechsel, EC-1-Existenz bleibt erfüllt).

5.6 Concept-Links (Story 2.3)

Beziehungen zwischen Concepts werden mit normalen Markdown-Links ausgedrückt — genau eine erlaubte Form (FR-10, AD-8, AD-7b, A0-9). Der Pin verhindert, dass zwei Producer aus demselben Baum unterschiedliche IDs berechnen (AD-7b). Die Link-Schicht ist die Navigations-/Beziehungsschicht, nicht die Provenienz (AD-8): ein Body-Link ändert keine Aussagen, kein sources und kein Frontmatter.

1. Pin (genau eine Form): Ein Concept-Link — im Concept-Body wie in wiki/index.md und Area-index.md — steht in der Form:

   "[<text>](<file-relativer Pfad mit .md-Endung>)"

   Ziel ist die Concept-OKF-Identität (relativer OKF-Pfad, AD-7a) + die .md-Endung (AD-7b, A0-9). Das Auflösungsmodell ist file-relativ zur .md-Datei (§5.7 Pkt. 4): Bei Root-Dateien sind file-relativ und bundle-relativ identisch (die bestehenden Concept-Links in wiki/index.md stehen bereits in dieser Form — Null-Migration, byte-identisch); in Areas bezeichnen ../ die Aufwärts-Ziele innerhalb wiki/ (z. B. [LLM-Wiki-Prinzip](../llm-wiki-prinzip.md) aus wiki/<area>/<concept>.md). Rationale: Ziele sind explizite Dateien — auch mit Areas eindeutig (Story 2.4); Standard-Markdown-Tools lösen den Link ohne Konventionswissen dateirelativ auf (FR-10, AD-8) — eine Form, beide Ebenen (Root + Area) (AD-7b).

2. Geltungsbereich & Ausnahmen: Der Pin gilt für Concept-Links in Concept-Bodies, in wiki/index.md und in Area-index.md. Explizit ausgenommen (andere Schicht bzw. außerhalb des Pins): raw/-Provenienz-Verweise in der Plain-/Komma-Form aus §5.5, ../schema/-Links (außerhalb des Bundles — andere Schicht), http-Links (externe Referenzen) und Gleichseit-Anker mit #-Beginn — der Form-Check und der Dangling-Check in Pkt. 3 exkludieren sie. Die ../-Exklusion ist Story 2.4 aufgelöst: ../-Ziele sind seit der deterministischen Bereichszuordnung (§5.7) in-Bundle-Aufwärts-Pfade — sie werden validiert (Formel 2/3, Pkt. 3) und müssen nach ..-Auflösung unter wiki/ bleiben; ../schema/… bleibt als andere Schicht exkludiert (Abgrenzung über das Zielverzeichnis unter wiki/, nicht über das bloße ../-Präfix). Die Formeln in Pkt. 3 scannen den kompletten wiki/-Baum mit Ausnahme von log.md (Dokumentation, keine Link-/Provenienz-Schicht — sie zitiert die Formel-Texte selbst und würde die Zählungen verunreinigen); ein ](-Link in log.md ist damit weder Pin-Objekt noch Formel-Trigger.

3. Selbsttest-Formeln (re-executierbar, AD-17h): Vor Abschluss eines Runs, der Links anlegt oder verändert, prüft der Producer die folgenden vier Formeln ab der Workspace-Root (rekursiv — künftige Area-Concepts unter wiki/<area>/ werden erfasst, Story 2.4/2.5):

   Alle Formeln exkludieren log.md (Scan-Scope, Pkt. 2) und erfassen leere Ziele ]() ([^)]* statt [^)]+).

   (1) Bestands-Check (Link-Überblick — alle ](-Links unter wiki/):

   sh -c "grep -roE ']\([^)]*\)' --include='*.md' --exclude=log.md wiki/"
   

   (2) Form-Check (erwartet Ausgabe 0, Exit 0 — jeder interne Link in der gepinnten Form; jede Formverletzung (fehlende .md-Endung, Mischform, leeres Ziel) erhöht den Zähler um 1; || true bindet den Exit-Code — grep -c liefert Exit 1 bei Ausgabe 0, der gewünschten SUCCESS-Konfiguration):

   sh -c "grep -rohE ']\([^)]*\)' --include='*.md' --exclude=log.md wiki/ | sed -E 's/^\]\(//; s/\)$//' | sort -u | grep -vE '^(raw/|\.\./|#)' | grep -vE '^\.' | grep -vE ':' | grep -cvE '^[^#]+\.md$' || true"
   

   Exkludiert: raw/-Provenienz (§5.5, andere Schicht), ../schema/, ./-Präfix-Ziele (^\. — nicht root-relativ/keine Bundle-Pfad-Form), externe Ziele (alle enthalten : — http://, https://, mailto:, protocol-less Hostnamen; interne OKF-Ziele sind Kebab-Case und enthalten nie :), Gleichseit-Anker (#…). Cross-Page-Anker file.md#sec werden weiterhin gezählt (normative Frage, s. deferred-work.md). Story-2.4-../-Schärfung: ../-Ziele werden weiterhin von der Exklusions-Stufe grep -vE '^(raw/|\.\./|#)' aus der Form-Zählung genommen — denn in-Bundle-Aufwärts-Ziele (../<ziel>.md, Auflösung bleibt unter wiki/, §5.7 Pkt. 4) sind formkonform; die Containment-Prüfung (Ziel-Auflösung muss unter wiki/ bleiben, sonst DANGLING) ist Aufgabe des Dangling-Checks (Pkt. 3, Formel 3).

   (3) Dangling-Check (erwartet: keine Ausgabe — jedes interne Ziel existiert relativ zum Quell-Verzeichnis (file-relatives Auflösungsmodell, §5.7 Pkt. 4 / AD-7b); ein nicht existierendes Ziel liefert DANGLING: <pfad>; leere Ziele liefern DANGLING: (leeres Ziel); Out-of-Bundle-..-Traversal wird gesperrt: ein Ziel, dessen ..-Auflösung aus wiki/ austritt (z. B. ../../README.md oder ../../schema/compiler.md aus einem Area-Concept), wird als DANGLING: <pfad> gemeldet — der reine -f-Existenztest würde sonst still passieren, weil die aufgelöste Datei außerhalb wiki/ existiert):

   sh -c 'grep -roE "]\([^)]*\)" --include="*.md" --exclude=log.md wiki/ | sed -E "s#^([^:]+):\]\(([^)]*)\)\$#\1|\2#" | sort -u | while IFS="|" read -r src t; do case "$t" in ""|*:*|raw/*|./*|/*) if [ "$t" = "" ]; then echo "DANGLING: (leeres Ziel)"; fi; continue;; esac; case "$t" in "#"*) continue;; esac; case "$t" in "../schema/"*) if [ "$(dirname "$src")" = "wiki" ]; then continue; fi;; esac; p=${t%%#*}; f="/$(dirname "$src")/$p"; while printf "%s" "$f" | grep -qE "/[^/]+/\.\.(/|$)"; do f=$(printf "%s" "$f" | sed -E "s#/[^/]+/\.\.(/|$)#/#g"); done; f=${f#/}; case "$f" in wiki/*) [ -f "$f" ] || echo "DANGLING: $t";; *) echo "DANGLING: $t";; esac; done'
   

   Die Formel führt die Quell-Datei der Link-Quelle mit (grep -roE → datei:](ziel) → sed → datei|ziel) und löst jedes interne Ziel einheitlich relativ zum Quell-Verzeichnis auf (file-relatives Auflösungsmodell, §5.7 Pkt. 4): f="/$(dirname "$src")/$p" — bei Root-Dateien ist das identisch zum bisherigen Bundleroot-Resolve (wiki/…), bei Area-Dateien adressiert dasselbe-Verzeichnis-Ziele korrekt (source-material.md aus wiki/<area>/index.md → wiki/<area>/source-material.md) und ../-Ziele die Aufwärts-Pfade innerhalb wiki/ (../llm-wiki-prinzip.md → wiki/llm-wiki-prinzip.md). Nach Kollabierung der X/..-Segmente (Fixed-Point-while-Schleife) wird der aufgelöste Pfad gegen wiki/* geprüft — bleibt er unter wiki/ und existiert die Datei, keine Ausgabe; verlässt er wiki/ (Out-of-Bundle-..-Escape, z. B. ../../README.md → README.md unterhalb wiki/) oder existiert die Datei nicht, DANGLING: <pfad>. ../schema/* bleibt als andere Schicht exkludiert — quellenbasiert (Loop-2-Fix): die Exklusion gilt nur, wenn die Quell-Datei auf der Bundleroot-Ebene liegt (dirname <quelle> = wiki, z. B. wiki/index.md) — dort löst einstufiges ../schema/… garantiert außerhalb des Bundles auf (schema/…), bestehende Root-Links bleiben damit byte-identisch und pin-frei (§5.7 Pkt. 4). Aus einer Area-Datei löst einstufiges ../schema/… dagegen auf wiki/schema/… (in-Bundle — die Exklusion greift dann nicht), und das Ziel läuft durch die normale Auflösung + Containment + Existenztest: nicht existent → DANGLING: …. Aus Areas ausbrechende ../../schema/* fällt ebenfalls nicht unter die Exklusion und wird als DANGLING gesperrt (Loop-1-Fix). Das Fragment wird vor dem Existenztest gestripped (file.md#sec → file.md — kein falscher DANGLING für existierende Ziele; die Pin-Form-Frage bleibt beim Form-Check). Exkludiert wie beim Form-Check (Ausnahme ../schema/). (Bekannt-konservativ: Ziele mit ) werden am ersten ) abgeschnitten → falsch benannte Ursache, aber keine Stille — dokumentiert in deferred-work.md.)

   (4) Kontakt-mit-raw/-Unverändert-Check (erwartet: Ist ≡ Baseline — der Pin berührt raw/-Provenienz-Verweise nicht; die Baseline wird deterministisch aus dem Baseline-Commit des letzten Zuwachs-Runs dynamisch extrahiert, AD-17h — keine „identisch"-Behauptung ohne extrahierbare Baseline; einschließende Einzelanführungszeichen um das sh -c-Argument, damit $f erst in der inneren Shell expandiert; Story-2.4-Re-Baseline (Loop-2-Fix): Dieser Run ist ein expliziter Datei-Zuwachs-Run (neue Area-Dateien) — die Baseline-Extraktion läuft auf den Kopf dieses Zuwachs-Runs (862cf410c624072833cd959da9a2fb26235716f6), nicht auf den Story-2.3-7e1f449… und nicht auf den baseline_commit-Wert der Story-2.4-Spec-Frontmatter (66451b6e6c9e139fb3aa3bbf4b01291e1e2d273a = Zustand vor dem Zuwachs, extrahiert 30); der Filter ist grep -v "log.md$" (Basename, damit ein künftiges Area-log.md konsistent mit dem --exclude=log.md der Ist-Zählung exkludiert wird):

   sh -c "grep -roE '\(raw/' --include='*.md' --exclude=log.md wiki/ | wc -l"
   sh -c 'git ls-tree -r --name-only 862cf410c624072833cd959da9a2fb26235716f6 -- wiki/ | grep -v "log.md$" | while read -r f; do git show "862cf410c624072833cd959da9a2fb26235716f6:$f"; done | grep -oE "\(raw/" | wc -l'
   

   Beide Vorkommen-Zählungen müssen übereinstimmen — die Ist-Zählung erfolgt auf dem aktuellen Baum, die Extraktion aus dem Baseline-Commit des letzten Zuwachs-Runs (aktuell: Run-Kopf 862cf41, dieser Run: 38 ≡ 38, log.md-exkludiert). Die Zahlen sind ein Formatbeleg, kein fester Wert: Auf dem Baum von Story 2.3 lag die Baseline bei 30 (extrahiert aus 7e1f449…/66451b6… — beide tragen den Vor-Zuwachs-Zustand); der Zuwachs (neues Area-Concept wiki/wissensarchitektur/source-material.md) erhöht die Ist-Zählung auf 38. Der Check verlangt die aktuelle Baseline aus dem Run-Kopf 862cf41 — ein Producer, der aus dem Vor-Zuwachs-Zustand (7e1f449… oder 66451b6…) extrahiert, würde 30 erhalten und die Formel bräche auf dem neuen Baum (38 ≠ 30). Bei jedem weiteren Datei-Zuwachs ist die Baseline-Extraktion erneut auf den dann aktuellen Run-Kopf durchzuführen (die Zählung wächst um die (raw/-Vorkommen der neu angelegten Dateien).

4. NFR-4-Regel: Jede Form-Verletzung (Pkt. 3, Formel (2) > 0), jeder Dangling-Link (Pkt. 3, Formel (3), Ausgabe DANGLING: …) und jedes leere Ziel (Formel (3), Ausgabe DANGLING: (leeres Ziel)) ist ein Run-FAIL mit textuell benannter Ursache — der verletzende Ziel-Pfad bzw. die Meldung ist exakt die Formel-Ausgabe. Der Link wird korrigiert oder entfernt, bevor der Run abschließt — kein stiller Vorbeilass.

5. Worked Example: Der Body-Link [LLM-Wiki-Prinzip](llm-wiki-prinzip.md) (in wiki/wissensarchitektur-trennung-states.md) ist in der gepinnten Form. Form-Check-Auflösung: Ziel llm-wiki-prinzip.md trifft ^[^#]+\.md$ → zählt als 0; keine Ausnahme-Klasse greift. Dangling-Check-Auflösung: wiki/llm-wiki-prinzip.md existiert → keine Ausgabe. Der gleiche Link in wiki/index.md (Bestands-Check, Pkt. 3, Formel (1)) löst identisch auf.

   Area-../-Beispiel (Story 2.4): Der Body-Link [LLM-Wiki-Prinzip](../llm-wiki-prinzip.md) in wiki/wissensarchitektur/source-material.md ist in der gepinnten file-relativen Form. Form-Check: Ziel ../llm-wiki-prinzip.md fällt unter die ../-Exklusions-Stufe → zählt als 0 (keine Form-Verletzung). Dangling-Check (einheitlich file-relativ, Quell-Verzeichnis wiki/wissensarchitektur): Auflösung wiki/wissensarchitektur/../llm-wiki-prinzip.md → kollabiert wiki/llm-wiki-prinzip.md, bleibt unter wiki/, existiert → keine Ausgabe. Gleiches Modell für dasselbe-Verzeichnis-Ziele von der Area-index.md aus: [source-material.md](source-material.md) in wiki/wissensarchitektur/index.md → wiki/wissensarchitektur/source-material.md existiert → keine Ausgabe. Die Formel-2/3-../-Schärfung macht genau diesen in-Bundle-Aufwärts-Pfad — und die einheitliche file-relative Auflösung alle Area-Ziele — zulässig.

   Negativ-Beispiel 1: [Test](ohne-endung) — Ziel ohne .md-Endung. Form-Check (Pkt. 3, Formel (2)) liefert 1 (Ziel ohne-endung zählt als Übertretung), Dangling-Check (Pkt. 3, Formel (3)) liefert DANGLING: ohne-endung — deterministische Fehlerursache, Run-FAIL gemäß Pkt. 4 (der Link wird korrigiert zu [Test](ohne-endung.md) oder entfernt).

   Negativ-Beispiel 2 (Out-of-Bundle-..-Escape, Loop-1-Review-Fix): Ein Body-Ziel [x](../../README.md) aus wiki/wissensarchitektur/source-material.md — der -f-Existenztest allein löst wiki/wissensarchitektur/../../README.md zur existierenden Workspace-README.md auf und würde still passieren. Formel 3 (Pkt. 3) sperrt: Auflösung kollabiert zu README.md, das nicht unter wiki/ bleibt → DANGLING: ../../README.md — Run-FAIL gemäß Pkt. 4, keine Stille. Analog [x](../../schema/compiler.md) → DANGLING: ../../schema/compiler.md (der aufgelöste schema/…-Zielpfad liegt außerhalb des Bundles; die ../schema/*-Exklusion gilt nur für das einstufige Root-index.md-Muster ../schema/*, nicht für aus Areas ausbrechende ../../schema/*). Nur das einstufige ../schema/* aus Root-Ebenen-Quellen bleibt als andere Schicht exkludiert (§5.7 Pkt. 4). In-Bundle-Variante (Loop-2-Fix): [x](../schema/compiler.md) aus wiki/wissensarchitektur/source-material.md — Auflösung wiki/schema/compiler.md (unter wiki/, Datei existiert nicht) → DANGLING: ../schema/compiler.md; die quellenbasierte ../schema/*-Exklusion greift nur für Bundleroot-Ebenen-Quellen, nicht für Area-Quellen — kein stiller Vorbeilass (NFR-4).

   Hinweis: Der Validator (strukturell unverändert, Story-2.2-Präzedenz) akzeptiert im Punkt-11-Check weiterhin beide Schreibweisen; der Pin liegt auf Instruktions-Ebene (Selbsttest-Formeln, Pkt. 3).

5.7 Deterministische Bereichszuordnung & Concept-Hierarchie (Story 2.4)

Bereichszuordnung und Concept-Hierarchie sind textual-deterministisch (AD-7c, A0-10, AD-13) — nie per Embedding/Vector-Infrastruktur (AD-13). Diese Sektion ist der einzige Instruktions-Ort der Bereichszuordnungs-Regel (D-3). Sie fügt kein Prädikat, keine neuen §7-Invaliditätsklassen und keinen Schema-/Validator-Change hinzu (Story-2.2/2.3-Präzedenz; Validator Punkt 11 akzeptiert Areas bereits strukturell: Area-index.md, verlinkt im nächsten Vorfahren). Eine als Area gedachte Anlage (wiki/<area>/index.md + Concept darunter) ist ab dieser Story konform, nicht mehr Bereichs-Hinweis (§5.1).

1. Routing-Regel („wohin gehört ein Thema"): Für jede erkannte neue Wissenseinheit wird der Ziel-Bereich deterministisch bestimmt:

   • (a) First-Class-Link aus dem bestehenden index.md-Baum: Textuelles Treffer-Prädikat (Loop-2-Fix, kein „inhaltlich deckungsgleich"-Urteil — AD-13): Ein bestehender index.md-Link (Bundleroot oder Area-index.md) ist ein Treffer, wenn die Identität seines Link-Ziels (relativer OKF-Pfad ohne .md, Pkt. 2) gleich dem kanonischen Namen des neuen Themas (Pkt. 2) ist. Liegt genau ein Treffer vor, wird das neue Concept in den Bereich dieses Links angelegt (wiki/<area>/<concept>.md); der Bereich existiert damit bereits als wiki/<area>/index.md. Mehrfachtreffer — deterministisches Tie-Break (Loop-2-Fix): Bundleroot-Links schlagen Area-Links (ein Bundleroot-Treffer verweist auf ein Root-Concept → neues Concept auf Root-Ebene gemäß (b), da kein Area-Bereich zugeordnet ist); unter mehreren Area-Treffern gewinnt die lexicografisch kleinste Area-Pfad-Zeichenfolge (z. B. wiki/a/… vor wiki/b/…). Die Auswahl ist damit textual-deterministisch aus dem bestehenden index.md-Baum ableitbar (AD-7c, A0-10).
   • (b) Default Root-Ebene: Existiert kein solcher Link, wird das Concept auf Root-Ebene angelegt (wiki/<concept-kebab-case>.md, §5.1). Neue Areas werden nur konsolidiert erzeugt (mehrere neue Concepts desselben erkannten Themas im selben Run, die einen eigenständigen Bereich rechtfertigen) — nicht pro Einzel-Concept erfinden (AD-7c, A0-10; Rücksprache-Pflicht §0 Ask-First der Story-Spezifikation).
   • Kein Embedding/Vector, kein reines LLM-Urteil als Entscheidungsbasis (AD-7c/AD-13, A0-10).

2. Kanonische ID-Normalisierung (AD-7a, A0-8): Identität = relativer OKF-Pfad ohne .md — genau eine Normalisierung, für alle Producer (auch per Basename-Filter für log.md-Exklusion, Formel 4):

   OKF-Pfad	Identität
   wiki/spring/index.md	spring
   wiki/spring/testing.md	spring/testing
   wiki/wissensarchitektur/index.md	wissensarchitektur
   wiki/wissensarchitektur/source-material.md	wissensarchitektur/source-material
   wiki/llm-wiki-prinzip.md	llm-wiki-prinzip

   Eine als Area gedachte Anlage (wiki/<area>/index.md + Concept darunter) ist damit konform; der Bereichs-Hinweis aus §5.1 ist aufgelöst. Konzept-ids (s. sources[].id, §5.5 Pkt. 3) sind unabhängig davon je Concept eindeutig — Adressraum ist Concept-Pfad + id.

3. Top-Level-Kollisions-Hold (A0-10, fixierter §3.2): Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3.1/§3.2, AD-7a), löst der fixierte §3.2-Kollisions-Hold aus — kein neues Prädikat, kein stiller Overwrite, kein Index-Link, keine Datei: der Run bricht für diese Einheit textuell ab („Concept existiert bereits — Aktualisierung ist Epic 3") und setzt mit den übrigen Einheiten fort (§3.2; „teilweise erfolgreich"). 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).

6. Validieren (mechanische Bestätigung)

1. Nach Abschluss aller Mutationen wird das gesamte Bundle gemäß schema/validator.md geprüft (§3 14 Punkte je Datei + §6-Fachprüfungen; Verdikt-Grammatik §5).
2. Erfolgsbedingung: Alle Dateien unter wiki/ — Bundleroot, Area-index.md, log.md, sämtliche neuen Concepts — liefern SUCCESS (kein FAIL; stale_after-WARN wäre nur Berichtskanal). Dabei ist insbesondere Punkt 11 (Index-Regel) zu bestätigen: jedes neue Concept ist in der index.md seines Bereichs verlinkt (Root-Concepts in wiki/index.md, Area-Concepts in wiki/<area>/index.md, §5.7 Pkt. 5).
3. Bei jedem FAIL gilt der Run als gescheitert; es werden keine weiteren Mutationen durchgeführt, raw/ bleibt unangetastet (AD-3), und die Fehlerursache wird textuell benannt (NFR-4). Der bereits geschriebene Teilzustand (neue Concept-Dateien, Index-Verlinkungen, log.md-Einträge) wird gemäß §5.3 zurückgerollt, sodass das Bundle seinen Zustand vor dem Run wieder einnimmt.
4. Der Producer hält das Verdikt-Ergebnis (je Datei SUCCESS/FAIL) als Ausführungs-Nachweis fest (z. B. in der Story-Spezifikations-Verification oder im Run-Bericht).

6.5 Determinismus- & Selbsttest-Norm (Nachprüf-Sektion)

Jede Erzeugungsentscheidung dieser Instruktion ist textual-deterministisch begründbar (AD-13): die erkannten Wissenseinheiten (§2), die Reconcile-Kollisionsprüfung (§3), die Frontmatter-Werte (§4) und die Ziel-Pfade (§5) folgen aus dem Input ohne probabilistische Verfahren. Es gibt keine Embedding-/Vector-Infrastruktur und kein reines LLM-Urteil als alleinige Entscheidungsbasis.

Vor Abschluss eines Runs prüft der Producer jedes erzeugte Concept gegen die folgenden drei Selbsttest-Kriterien (AD-17h-konform; der Validator in §6 bleibt die mechanische Prüfung, diese Kriterien sind seine Vorab-Projektion):

1. Vollständige §3-Subset-Konformität: Das Frontmatter enthält ausschließlich Keys aus {type, sources, generated, verified, status, stale_after} in kanonischer Reihenfolge (§4.1 des Validators); type ist gesetzt und non-empty; keine Duplikat-Keys (Punkt 13, auch innerhalb von sources/generated/verified-Einträgen); Keine unautorisierten Keys — weder auf Top-Level-Ebene noch innerhalb von sources/generated/verified-Einträgen (Vertrag §3.3/§3.4/§3.5, Punkt 6); okf_version/type: bundle kommen nicht vor (Punkt 9).
2. at-Normalform: generated.at (und ggf. verified[].at) ist ein volles ISO-8601-Datetime YYYY-MM-DDTHH:MM:SS mit Z/±HHMM/±HH:MM — keine reine Datumsangabe (Punkt 14; Validator §4.3).
3. sources-Existenz: Jeder sources[].resource verweist auf einen /-getrennten relativen Pfad unter raw/, der zum Validierungszeitpunkt als Datei existiert (EC-1); kein .., kein führendes /, kein Backslash, keine URL-Form, kein wiki/-Pfad (Punkt 3/4, §6.2).

Weicht ein erzeugtes Concept in mindestens einem Kriterium ab, wird es nicht als erfolgreiche Erzeugung behandelt; der Run korrigiert oder verwirft die Datei und dokumentiert die Abweichung textuell (NFR-4) — es fließt nichts Ungeprüftes in das Bundle.

6.6 Positiv-/Negativ-Beispiele (Referenztabellen)

Die folgende Tabelle macht jede Erzeugungsregel dieser Instruktion reproduzierbar nachprüfbar (AD-17h, Verifikations-Kultur aus Story 1.4 — Verifikations-Beleg). „✓" = ideal-konform (erwartet: Validator-SUCCESS), „✗" = verletzte Regel (erwartet: Validator-FAIL mit der genannten Fehlerursache).

Regel (§)	✓ Positiv-Beispiel	✗ Negativ-Beispiel (Fehlerursache)
§4.1 type Pflicht (§3.1)	type: concept	type: (leer) → Punkt 1
§4.1 Feldsubset (§3)	nur type, sources, generated	foo: bar → Punkt 6
§4.2 sources[].resource → raw/ (§3.3, AD-4b)	resource: raw/prd/prd-wow20-2026-08-14.md	resource: wiki/foo.md → Punkt 3
§4.2 Path-Grammatik (§3.3, Punkt 4)	/-getrennt, relativ, unter raw/	resource: ../outside.md → Punkt 4
§4.2 EC-1-Existenz (§3.3, §6.2)	resource: raw/prd/prd-wow20-2026-08-14.md (Datei existiert)	resource: raw/fehlt.md → EC-1
§4.3 generated.by Pflicht (§3.4)	generated: {by: wow-compiler/0.1.0, at: …}	generated: {at: …} (ohne by) → Punkt 7
§4.3 generated.at volles ISO-8601-Datetime (§3.4, Validator §4.3)	at: 2026-08-16T09:23:33Z	at: 2026-08-16 (reines Datum) → Punkt 14
§4.3 verified ungesetzt (A0-20)	(kein verified)	verified: {by: human:x, at: …} → Punkt 6 (unautorisiertes Feld, nur maschinelle Erzeugung A0-20), hier nicht erzeugt
§4.5 canonical Key-Reihenfolge (Validator §4.1)	type → sources → generated	— (kein Validator-FAIL: Reihenfolge ist Output-Normalform, kein §7-Punkt; der Compiler erzeugt sie deterministisch und die Normalform-Abweichung tritt damit nicht auf)
§4.5 keine Duplikat-Keys (Punkt 13)	jeder Key einmal	zweimal type: → Punkt 13
§4.2 sources-Eintrag-Key-Subset (Vertrag §3.3)	nur resource, id, title, author, usage_count, last_modified	resource … + z. B. role: x → Punkt 6 (unautorisiertes Feld, Innen-Ebene)
§4.5 kein okf_version/type: bundle (Punkt 9)	(nicht vorhanden)	okf_version: "0.2" → Punkt 9
§5.1/§5.7 Ziel-Pfad & Verlinkung (Punkt 11, §6; §5.7 Pkt. 1/5)	Root: wiki/<slug>.md + Link in wiki/index.md; Area: wiki/<area>/<slug>.md + Link in wiki/<area>/index.md (konform, §5.7)	Concept ohne Link in der index.md seines Bereichs → Punkt 11; Area ohne index.md → Punkt 11 („Area ohne index.md=")
§5.4 log.md-Dokumentation (§5)	datumsgruppierter Eintrag mit Concept-Pfad + Quellen	fehlender Eintrag → kein Validator-FAIL, aber dokumentarische Pflicht verletzt
§5.6 Concept-Link-Form (FR-10, AD-7b, A0-9)	[<text>](<concept-pfad>.md) (file-relativ, .md-Endung; in Areas ../-fähig, §5.7 Pkt. 4)	[…](concept-pfad) ohne .md → Form-Check (Pkt. 3, Formel 2) > 0, Run-FAIL (NFR-4)
§4.2 Alle-Pfad-Formen-Vermeidung (Punkt 4)	/-getrennt, relativ, unter raw/	..-Traversal, führendes /, Backslash (raw\foo.md), URL-Form (https://…) → Punkt 4
§7 Selbstbegrenzung (kein Standalone, D-3)	rein textuelle Instruktion	Code-/Executable-Abschnitt → D-3-Verstoß

Interpretations-Hinweis: Die „✗"-Zeilen zeigen die deterministische Fehlerursache, die der Validator (Story 1.4) für die jeweilige Abweichung ausgibt. Die „✓"-Zeilen sind die Vorgabe, unter der ein neu erzeugtes Concept den Run passieren kann — genau diese Form wurde im Demonstrationslauf (2026-08-16) gegen alle 3 erzeugten Concepts erfüllt.

7. Selbstbegrenzung (Scope der Instruktion)

Diese Instruktion ist auf die Erzeugung neuer Concepts auf Root-Ebene und in Areas gemäß §5.7 begrenzt. Folgendes verbleibt in anderen Stories und wird hier nicht vorweggenommen:

• Claim-granulare Provenienz je belegter Aussage (Inline-raw/-Verweise, Kontext-Marker) — in §5.5 dieser Instruktion verankert (Story 2.2; AD-4a, A0-3). Keine neue §7-Klasse, kein Standalone, keine Vertragsänderung.
• Deterministische Area-Zuordnung & Concept-Hierarchie (Anlage von wiki/<area>/index.md + wiki/<area>/<concept>.md) — in §5.7 dieser Instruktion verankert (Story 2.4; AD-7c, A0-10, A0-8, AD-13). Keine neue §7-Klasse, kein Validator-Change.
• Progressive Discovery über index.md (Navigation, Area-Indizes, Suche) → Story 2.5 (AD-9, FR-11).
• 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).
• Aktualisierung bestehender Concepts (Erweitern/Präzisieren/Korrigieren) und Synthese über mehrere Concepts → Epic 3 (AD-5, FR-6/FR-7).
• Standalone-Compiler / eigene LLM-Runtime / MCP → verboten in v1 (D-3, D-4, AD-11).
• OKF-Dialekt / Schema-Erweiterung → niemals (AD-1a; Vertrag §7 „abschließende Liste").

8. Normreferenzen & Revisionslog

Normreferenzen (read-only):

• schema/wiki-compiler.md — autorisierter Vertrag (Story 1.3): §2 Bundleroot, §3.1–§3.7 Feldsubset & Formate, §5 log.md-Typ, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
• schema/validator.md — Prüfgrundlage (Story 1.4, Revision 8): §3 14 Punkte, §4 Normalform (Reihenfolge §4.1, ISO-8601 §4.3), §5 Verdikt, §6 Fachprüfungen (EC-1 Existenz, EC-3 Kalender, EC-11 non-md).
• Architektur-Spine (raw/architecture-spine): AD-2/AD-3 (raw immutable), AD-4a (claim-granulare Provenienz, §5.5), AD-5 (inkrementelle Kompilation), AD-6 (Reason/Mutate-Trennung), AD-7a (Identität = OKF-Pfad ohne .md, §5.7), AD-7b (genau eine Linkform gepinnt, §5.6), AD-7c (deterministische Bereichszuordnung, §5.7), AD-7d (Renaming/Redirect-Pflicht — nicht in den ACs, Epic 3), AD-8 (Standard-Markdown-Links = Navigations-/Beziehungsschicht, §5.6), AD-9 (Progressive Discovery, §5.7), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-13 (Retrieval gehört zu Consumers / keine Embedding-Bereichszuordnung, §5.7), AD-14 (Git liefert Historie, nicht Domain-State), AD-15 (Trust-Metadaten v1), AD-16 (Konflikte werden explizit bewahrt), AD-17a (nur veröffentlichte/committete Inhalte als Input), AD-17f (Commit-Boundary = Mutations-Boundary), AD-17h (Determinismus), D-3 (kein Standalone).
• PRD (raw/prd): FR-2 (Sources vs. Curated), FR-5 (Concept-Erzeugung), FR-9 (OKF-Konformität), FR-10 (Concepts miteinander verlinken, §5.6), FR-16 (Consumer-Unabhängigkeit), A-4 (nur lokale Sources).
• Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5; A0-3 (Kontext-Marker-Wortlaut, §5.5), A0-8 (Concept-Identität/Normalisierung, §5.7), A0-9 (eine erlaubte Linkform, §5.6), A0-10 (deterministische Bereichszuordnung, §5.7), A0-13 (Lease-Root-Scope); FR-6/FR-12/FR-14, A0-6/A0-7/A0-11/A0-18 (Belege der nachkonformierten Concept-Bodies).
• PRD §4.3 (FR-11 — progressive Discovery, §5.7 Pkt. 5) und §8.2/§8.3 (Canonical State; Separation of Concerns).

Revisionslog:

• Revision 1 (2026-08-16): Erstes abgeleitetes Artefakt — Concept-Erzeugung als deterministische Instruktion: Input-Grenzen (§1), Interpretieren (Wissenseinheiten, kein 1:1/keine Kopie, §2), Reconcile (Kollision-Hold, §3), Synthetisieren (Frontmatter-Normalform, §4), Mutieren (Root-Ebene + Index-Regel + log.md, §5), Validieren (Validator-SUCCESS als Erfolgsbedingung, §6), Selbstbegrenzung (§7).
• Revision 1.1 (2026-08-16): Nach dem Demonstrationslauf ergänzt — §6.5 Determinismus- & Selbsttest-Norm (drei Nachprüf-Kriterien: §3-Subset-Konformität, at-Normalform, sources-Existenz; AD-17h-konform) und §6.6 Positiv-/Negativ-Beispiele (Referenztabellen je Erzeugungsregel mit deterministischer Fehlerursache). Revisionslog (§8) nachgeführt; §6-Nummerierung angepasst.
• Revision 1.2 (2026-08-16, Step-04-Review): Nachschärfungen aus dem Story-2.1-Review — Input-Regel korrekt auf AD-17a statt AD-17.2 referenziert (§1); sources-Eintrag-Key-Subset (Innen-Ebene, Vertrag §3.3) in §4.2 und als §6.5-Kriterium-1 / §6.6-Tabellenzeile ergänzt; status-Absenz-Formulierung an die Vertrags-Definition (Absenz = stable, §3.6) angebunden (§4.4); Klarstellung Bereichs-Ziele bis Story 2.4 (§5.1/§6.6); §6.6-Fehlerursache der verified-Zeile auf Punkt 6 korrigiert; §6.6-Referenzlabel von §4.5 auf §4.4 korrigiert; §6.6 um vollständige Punkt-4-Pfad-Verbote ergänzt; AD-17f als Commit-Boundary in §0/§5.3/§6.6 sichtbar gemacht.
• Revision 1.3 (2026-08-16, bmad-code-review Story 2.1): Nachschärfungen aus dem Review-Patch-Block — §1-Überschrift ins Deutsche („Input (was der Compiler konsumiert)"); Prüfgrundlagen-Referenz auf validator.md Revision 7 angeglichen (§0-Header, §8); §6.6 canonical-Key-Reihenfolge-Zeile von der ✗-Liste auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Normalform ohne §7-Punkt) und das irreführende „§6.4"-Label auf §4.2 berichtigt; §1.2 vs. §1.4-Evidenz-Widerspruch aufgelöst (§1.2 präzisiert auf verarbeitbare Evidenz, §1.4 Artefakt-Ausnahme als dokumentarische Konvention der Source-Bereitstellung nach raw/README.md gekennzeichnet).
• Revision 1.4 (2026-08-17, bmad-code-review Re-Run Story 2.1, Stand nach Validator-Rev-8): Nachschärfungen aus dem unabhängigen Re-Review — Prüfgrundlagen-Referenz auf validator.md Revision 8 angehoben (§0-Header, §8); §6.6-Referenzlabels berichtigt (canonical Key-Reihenfolge, Duplikat-Keys, okf_version/type: bundle → §4.5, sources-Eintrag-Key-Subset → §4.2; berichtigt die Rev-1.2-Korrektur, die das Label fälschlich von §4.5 auf §4.4 bewegt hatte); §1.4 „Aufträge" → „Formate", §5.2 „grossen" → „großen"; §3.2 Kollision-Hold um Run-Fortsetzung mit den übrigen Einheiten und Gesamt-Run-Status („teilweise erfolgreich") ergänzt; §5.3/§6.3 um explizite Rollback-Sequenz für den Teilzustand (Concept-Datei + Index-Verlinkung + log.md-Eintrag) bei Validierungs-FAIL ergänzt.
• Revision 1.5 (2026-08-17, Story 2.2): Sektion „Claim-granulare Provenienz" als §5.5 eingefügt (nach §5, vor §6) — Inline-raw/-Verweis je belegter Aussage (+ id-Attribution, Vertrag §3.3), Kontext-Marker je Übernahme („übernommen aus … auf Basis von …, nicht eigenständig belegt"), eindeutiges id-Scoping je Concept, Selbsttest-Kriterien (belegte Aussage → Verweis; Übernahme → Marker; kein unautorisierter Key; UNBELEGTE_AUSSAGE als Marker statt erfundener Beleg) — AD-4a/4b/4c, AD-13, AD-17h. §7-Selbstbegrenzung entsprechend umformuliert (Claim-granulare Provenienz jetzt in §5.5 verankert, nicht mehr deklariert als „verbleibt in Story 2.2"). Keine Änderung an wiki-compiler.md/validator.md/raw/; kein Standalone (D-3); keine Vertragsänderung.
• Revision 1.6 (2026-08-17, Story-2.2-Re-Review, Patch-Runde): §5.5-Klarstellungen aus dem Review — (1) „kein Frontmatter-Change"-Widerspruch aufgelöst: Konvention fügt kein neues Feld über §3.3 hinaus hinzu, während das Hinzufügen/Erweitern von sources-Einträgen (resource/id, Relokation/Zielwechsel) ausdrücklich Teil der Konvention ist; (2) Inline-Verweis-Form präzisiert: Fragment = im Rohdokument existierende Stellen-Kennung (Bezeichner-id oder Sektionstitel), Concept-eigene sources-id (s1, …) ist NICHT als Fragment zu verwenden; voller raw/-Pfad je Beleg, keine Pfad-Elision; die Selbsttest-Formel auf grep -nE '(raw/|]\(raw/' erweitert; (3) Kontext-Marker um Direktübernahme-Fall „übernommen aus <source> (rohe Quelle)" ergänzt, Selbstreferenz-Muster verboten; (4) Forward-Referenz-Wortlaut an den exakten Token „nicht eigenständig belegt" gebunden; (5) Worked Example (belegte Aussage + Diagramm-Direktübernahme + Diagramm-Quell-Deklaration, BH-13) ergänzt. Keine Änderung an wiki-compiler.md/validator.md/raw/; kein Standalone (D-3); keine Vertragsänderung.
• Revision 1.7 (2026-08-17, bmad-code-review Story 2.2, Patch-Runde 2): (1) Selbsttest-Grep-Formel behoben — grep -nE '(raw/|]\(raw/' war eine ungültige ERE (ungeschlossenes Klammerpaar, exit 2); jetzt grep -nE '\(raw/' (das Teilmuster (raw/ erfasst Plain-Form und Markdown-Linkform gleichermaßen), Pkt.1 und Pkt.4, re-executierbar (AD-17h); (2) Komma-Form (raw/<datei.md>, <stellen-kennung>) als zulässige zweite Inline-Form in Pkt.1 formal festgelegt (für Stellen-Kennungen ohne Bezeichner-id im Rohdokument, z. B. Sektionstitel § 1 Vision), analog zum Link-Form-Präzedenzfall bis Story 2.3 — Worked Example um Komma-Form-Beispiel ergänzt (D1-Entscheidung, Option 1); (3) Multi-Beleg-Serialisierung in Pkt.1 festgelegt (Semikolon + voller Pfad je Beleg; Komma-Gruppierung mehrerer #-Kennungen unter einem Pfad zulässig; bei gemischten Formen voller Pfad je Beleg; keine Pfad-Elision über Beleg-Grenzen); (4) Relokations-Sub-Bullets als 1a/1b nummeriert (Label „Pkt. 1b" in §5.5-Intro, Pkt.5 und deferred-work.md existiert damit); (5) Marker-Muster-Zahl korrigiert: „drei" (zwei Grundmuster + Forward-Referenz-Variante), Pkt.2 und Pkt.4; Forward-Referenz-Beispiel-Zitat auf eindeutigen Sektionstitel Story 3.1: Inkrementellen Datenfluss implementieren disambiguiert (raw/epics trägt zwei „Epic 3"-Headings); (6) §8-Normreferenzen um AD-4a, AD-9, AD-13, AD-14, AD-16 (Spine), FR-16 (PRD), A0-3, FR-6/12/14, A0-6/7/11/18 (Epics) ergänzt. Keine Änderung an wiki-compiler.md/validator.md/raw/; kein Standalone (D-3); keine Vertragsänderung.
• Revision 1.8 (2026-08-17, Story 2.3): Neue Sektion „Concept-Links" als §5.6 eingefügt (nach §5.5, vor §6): genau-eine-Form-Pin bundle-relativ mit .md-Endung (AD-7b, A0-9, FR-10; Rationale Null-Migration der 3 Concept-Links, explizite Datei-Ziele, Standard-Markdown-Tools/AD-8), Geltungsbereich (Concept-Bodies + wiki/index.md) mit expliziten Ausnahmen (raw/-Provenienz-Verweise §5.5, ../schema/-Links, http-Links, Gleichseit-Anker #…), vier re-executierbare Selbsttest-Formeln (Bestands-, Form-, Dangling-Check + Kontakt-mit-raw/-Unverändert-Check mit deterministischer Baseline-Extraktion aus dem baseline_commit via git show, AD-17h; rekursiv lauffest für künftige Areas, Story 2.4/2.5), NFR-4-Regel (jede Form-Verletzung → Run-FAIL mit textuell benannter Ursache) und Worked Example. Die „bis Story 2.3"-Klauseln in §5.3 Pkt. 3 und §5.5 Pkt. 1 referenzieren jetzt §5.6; §7-Selbstbegrenzung-Bullet entsprechend umformuliert. Demonstrative Umsetzung: zwei inhaltsbegründete Cross-Links in wiki/wissensarchitektur-trennung-states.md (→ llm-wiki-prinzip.md, → knowledge-kompilation-inkrementell.md; keine erzwungene Gegenseitigkeit, AD-8). Keine Änderung an wiki-compiler.md/validator.md/raw/ (der Punkt-11-Check akzeptiert bis auf Weiteres beide Schreibweisen — Einschränkung wäre eigene Autorisierung); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung.
• Revision 1.9 (2026-08-17, Story 2.3, Step-04-Review Loop 1, Patch-Runde): §5.6-Formeln geschärft — (1) leere-Ziele-Erfassung ([^)]* statt [^)]+ in Formel 1/2/3), (2) log.md-Exklusion in allen vier Formeln (--exclude=log.md) + Scan-Scope-Klarstellung in Pkt. 2 (Formeln scannen den wiki/-Baum mit Ausnahme von log.md — sie zitiert die Formel-Texte selbst), (3) externe-Ziel-Exklusion über : statt http-Präfix (Formel 2 grep -vE ':'; Formel 3 case *:*) — http:///https:///mailto:/protocol-less Hostnamen exkludiert, legale http…-Dateinamen nicht mehr fälschlich exkludiert, (4) Exit-Code-Bindung || true am Ende des Form-Checks (grep -c liefert Exit 1 bei Ausgabe 0 — der gewünschten SUCCESS-Konfiguration), (5) Fragment-Strip im Dangling-Check vor dem Existenztest (p=${t%%#*} — concepts.md#s1 bei existierender Datei liefert keinen falschen DANGLING; die Form-Frage bleibt beim Form-Check) und leere Ziele melden DANGLING: (leeres Ziel) statt still exkludiert; (6) raw/-Check (Formel 4) auf dynamische Baseline-Extraktion umgestellt (git ls-tree -r --name-only <baseline_commit> -- wiki/ + git show je Datei, wiki/log.md gefiltert; einschließende Einzelanführungszeichen, damit $f erst in der inneren Shell expandiert) mit erwarteter Zählung 30 (log.md-exkludiert) und Voraussetzung „unveränderte wiki/-Dateimenge" (bei Datei-Zuwachs in späteren Runs Baseline-Extraktion neu durchführen). Pkt. 4 (NFR-4-Regel) um leere Ziele erweitert; Pkt. 5 (Worked Example) um Negativ-Beispiel ([Test](ohne-endung) → Form-Check 1 + DANGLING: ohne-endung) und Verweis-Korrektur („Pkt. 3.1" → „Pkt. 3, Formel (1)") ergänzt; §6.6 um §5.6-Referenzzeile (✓ gepinnte Form / ✗ fehlende .md → Form-Check > 0, Run-FAIL). Keine Änderung an wiki-compiler.md/validator.md/raw/; kein Standalone (D-3); keine neue §7-Klasse; keine Vertragsänderung.
• Revision 2.0 (2026-08-17, Story 2.3, bmad-code-review, Review-Runde): §5.6-Pin-Schärfung aus dem Code-Review (Blind-Hunter + Edge-Case-Hunter): (1) Formel 2 (Form-Check) um die Exklusions-Stufe grep -vE '^\.' erweitert — Ziele mit ./-Präfix (und damit nicht-root-relative Pfade) werden definiert aus dem Pin ausgenommen, statt still als „interne .md-Form" durchzugehen; die erläuternde Exklusions-Aufzählung in Pkt. 2 entsprechend ergänzt (./-Präfix-Ziele: nicht root-relativ/keine Bundle-Pfad-Form); (2) Formel 3 (Dangling-Check) case-Muster um ./* und /* erweitert — ./-Präfix-Ziele und absolute Wurzel-Pfade werden konsistent exkludiert (Analog zu ../*), statt DANGLING: ./foo.md-Fehlbenennung zu erzeugen. Beide Formeln bleiben deterministisch re-executierbar (AD-17h) und werden in der Spec-Verification byte-identisch gespiegelt (verifiziert: 5/5 Formel-Strings identisch compiler↔spec). Positiv-Kontrolle nach Patch: Form-Check 0 (Exit 0), Dangling-Check leere Ausgabe, Bestands-Check 8 Links, raw/-Baseline 30 ≡ 30. Keine Änderung an wiki-compiler.md/validator.md/raw/; kein Standalone (D-3); keine neue §7-Klasse; keine Vertragsänderung. (Die zugehörigen Defer-Findings — Image-Scope, Multi-Line-, Reference-Style- und Leading-Space-Ziele, künftiges Area-log.md — sind in deferred-work.md dokumentiert, Story-2.4-Kandidat.)
• Revision 2.1 (2026-08-18, Story 2.4): Neue Sektion §5.7 „Deterministische Bereichszuordnung & Concept-Hierarchie" eingefügt (nach §5.6, vor §6): (1) Routing-Regel textual-deterministisch (index.md-Erst-Link → Bereich, sonst Root; neue Areas nur konsolidiert; nie Embedding/Vector — AD-7c/A0-10/AD-13), (2) kanonische ID-Normalisierung mit Beispieltabelle wiki/<area>/index.md → <area> (AD-7a/A0-8), (3) Kollisions-Hold → Verweis auf den fixierten §3.2 (kein neues Prädikat, kein MOVE, A0-10), (4) file-relatives Link-Auflösungsmodell (../-fähig, eine Form, §5.6-Pin unverändert) inkl. Out-of-Bundle-..-Containment, (5) Area-index.md-Regel (frontmatterlos, Punkt 10; Area ohne index.md → wörtliche Punkt-11-Meldung FAIL … Punkt 11: Index-Regel verletzt (Area ohne index.md=…) — kein inventiertes AREA_WITHOUT_INDEX-Label; §5.7 Pkt. 5), (6) Worked Example Area-Concept. Nachgeführt: §5.1 Pkt. 1 (Ziel-Pfad → §5.7-Verweis, „Area-Zuordnung ist Story 2.4"-Backlog-Klausel aufgelöst), §5.3 Pkt. 3 (Index-Regel area-bewusst: Concept → index.md seines Bereichs), §5.6 Pkt. 1/2/3/4/5 (file-relatives Auflösungsmodell; ../-Exklusion aufgelöst → in-Bundle-Auflösung; Formel 2 Exklusions-Erläuterung um ../-Zähl-Freistellung ergänzt; Formel 3 um Quell-Datei-Spur (grep -roE + datei|ziel-sed) und in-Bundle-..-Auflösung mit Containment inkl. ../schema/*-Exklusion erweitert — Out-of-Bundle-..-Escape (../../README.md, ../../schema/compiler.md) wird als DANGLING gesperrt, Loop-1-Review-A1-Fix; Formel 4 neu auf den baseline_commit dieser Spezifikation 66451b6… basiert — nicht den Story-2.3-7e1f449…, Loop-1-Review-A2-Fix — mit Basename-Filter grep -v "log.md$"), §6.6 (Referenzzeile §5.1/§5.7), §6 Pkt. 2 (Erfolgsbedingung Punkt 11 area-bewusst), §7-Selbstbegrenzung-Bullet → „in §5.7 verankert", §8-Normreferenzen um AD-7c/AD-7d/A0-8/A0-10/A0-13/PRD-§8.2/§8.3 ergänzt. Keine Änderung an wiki-compiler.md/validator.md/raw/; keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.
• Revision 2.2 (2026-08-18, Story 2.4, bmad-code-review Loop 2, 4 Layer; Nutzer-Entscheidungen 1/1/1): (1) Formel 3 (Dangling-Check) quellenbasierte ../schema/*-Exklusion (Decision 2): case "$t" in …|../schema/*) um Quell-Bedingung geschärft — die Exklusion greift nur, wenn die Quell-Datei auf Bundleroot-Ebene liegt (dirname <quelle> = wiki); aus Area-Quellen läuft einstufiges ../schema/… durch die bestehende Auflösung + wiki/*-Containment + -f-Existenztest (nicht existent → DANGLING: …, kein stiller Vorbeilass, NFR-4); Negativ-Beispiel 2 um die In-Bundle-Variante [x](../schema/compiler.md) aus wiki/wissensarchitektur/source-material.md → DANGLING: ../schema/compiler.md ergänzt (Sandbox-Nachweis); (2) Formel 4 (Kontakt-mit-raw/) Re-Baseline auf den Run-Kopf (Decision 1): Extraktions-Commit von 66451b6… auf 862cf410c624072833cd959da9a2fb26235716f6 (Kopf dieses Zuwachs-Runs, Extraktion = 38) umgestellt — der gepinnte Selbsttest lief auf dem Zuwachs-Baum deterministisch 38 ≠ 30 = Run-FAIL (bekannt-böser Zustand aus Loop-1-A2, nur halb geheilt); Erwartungstext jetzt „Ist ≡ Extraktion aus dem Baseline-Commit des letzten Zuwachs-Runs" (aktuell: Run-Kopf 862cf41, 38 ≡ 38); 66451b6/30 bleibt als Referenz des Vor-Zuwachs-Zustands dokumentiert; Wieder-Baseline-Klausel für künftige Zuwachs-Runs; (3) §5.7 Pkt. 1(a) textuelles Treffer-Prädikat + deterministisches Tie-Break (Decision 3): „inhaltlich deckungsgleichen Eintrag" (Urteil, AD-13-Verstoß) ersetzt — Treffer = Identität des index.md-Link-Ziels ≡ kanonischer Name des neuen Themas (Pkt. 2); Mehrfachtreffer → Bundleroot-Links vor Area-Links (Bundleroot-Treffer = Root-Concept-Verweis → Default Root-Ebene gemäß (b)), dann lexicografisch kleinste Area-Pfad-Zeichenfolge; (4) file-relative Pin-Wortwahl nachgeführt — §5.3 Pkt. 3 (Oxymoron „file-relativ bundle-relativ" aufgelöst: „file-relativ, mit .md-Endung; §5.7 Pkt. 4"), §6.6-Zelle (bzw. das doppelte Leerzeichen) und §7-Bullet; (5) §7-Scope-Einleitung „auf die Erzeugung neuer Concepts auf Root-Ebene begrenzt" → „Root-Ebene und in Areas gemäß §5.7"; (6) Typos („akte-Baseline" → „aktuelle Baseline", „Kopf dieser Spezifikation" → „Baseline-Commit des letzten Zuwachs-Runs"). Positiv-Kontrolle nach Patch (re-executiert): Formel 2 (Form-Check) 0 (Exit 0), Formel 3 (Dangling-Check) leere Ausgabe, Formel 4 38 ≡ 38. Keine Änderung an wiki-compiler.md/validator.md/raw/ (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.