# 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):**

```text
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-`id`s (`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 `id`s 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
   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
   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
   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
   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-`id`s (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).

## 5.8 Progressive Discovery über `index.md` (Story 2.5)

Progressive Discovery ist die **schrittweise Navigation** eines Consumers von der Bundle-Übersicht zu den Concepts über die `index.md`-Hierarchie (AD-9, FR-11) — die **erste Discovery-Ebene** des Bundles. Diese Sektion ist der **einzige Instruktions-Ort** der Discovery-Semantik (D-3, Story 2.5). Sie fügt **kein** Prädikat, keine neuen §7-Invaliditätsklassen und keinen Schema-/Validator-Change hinzu (AD-3); der Validator bleibt bei Punkt 11 als strukturelle Index-/Verlinkungs-Prüfung (Area-Existenz + Concept-in-Index verlinkt). Die Discovery-Vollständigkeit (Root → Area → Concept) ist **keine** neue §7-Invaliditätsklasse — sie wird deterministisch als **Instruktions-Selbsttest** (Pkt. 2) belegt: Verstöße gegen die gewurzelte Erreichbarkeit bzw. die Zwei-Ebenen-Kartografie werden vom Producer vor Abschluss des Runs über eine **re-executierbare Selbsttest-Formel** textuell benannt (NFR-4-analog, Run-FAIL-artiger Nachweis). Sie antwortet zugleich auf die offene Defer-Frage **F-07** (verschachtelte Areas/Unter-Ebenen, `wiki/a/b/concept.md`): die Kartografie ist ab Story 2.5 konsolidiert **Zwei-Ebenen** (Pkt. 3).

1. **Discovery-Pfad (AD-9, FR-11):** Ein Consumer startet die Navigation an der **Bundle-Root** `wiki/index.md` und folgt dann den Area-`index.md`-Dateien zu den Concepts:

   - **Bundleroot `wiki/index.md`** — Einstiegspunkt: verlinkt die **Root-Concepts** (direkt, §5.7 Pkt. 5) und die **Area-`index.md`-Dateien** (Navigation Root → Area, AD-9).
   - **Area-`index.md`** (`wiki/<area>/index.md`, **frontmatterlos**, Vertrag §2/§6, Validator Punkt 10) — verlinkt ihre **Area-Concepts** in der gepinnten §5.6-Form (§5.7 Pkt. 5).
   - **Concept** (`wiki/<concept>.md` bzw. `wiki/<area>/<concept>.md`) — das Ziel der Navigation.

   Erwarteter Erreichbarkeits-Satz **(gewurzelte Erreichbarkeit, Root → Area → Concept)**: jedes Root-Concept ist aus der Bundleroot erreichbar; jede Area ist aus der Bundleroot verlinkt (AD-9); jedes Area-Concept ist aus seiner Area-`index.md` erreichbar. Originäre Aussage-Pflicht des §5.7-Discovery-Bildes bleibt §5.7 Pkt. 5 (ein neues Area-Concept MUSS in `wiki/<area>/index.md` verlinkt sein, ein neues Root-Concept in `wiki/index.md` — §5.3 Pkt. 3); §5.8 erläutert die Discovery-**Semantik** dieser bestehenden Regeln, macht den Erreichbarkeits-Satz als Kriterium explizit und bindet ihn an die re-executierbare Selbsttest-Formel (Pkt. 2).
2. **Gewurzelte Erreichbarkeit als deterministisches Discovery-Kriterium + re-executierbarer Selbsttest (AD-17h):** Die Discovery-Vollständigkeit ist textuell prüfbar: jede Area `wiki/<area>/` MUSS von der Bundleroot aus verlinkt sein (Root-→-Area-Pfad, AD-9). Die Area→Concept-Verlinkung („jedes Area-Concept in seiner Area-`index.md`") ist durch den **Validator Punkt 11** (`Concept nicht verlinkt=<concept>`) mechanisch abgedeckt und wird hier bewusst **nicht dupliziert** (so auch der Erreichbarkeits-Satz für Root-Concepts, siehe unten). Der Producer führt vor Abschluss eines Runs, der Areas oder Area-Concepts anlegt/verlinkt, den folgenden Selbsttest ab der Workspace-Root aus (erwartet: **keine** Ausgabe; jede Ausgabe = textuell benannter Selbsttest-Befund, der vor Run-Abschluss zu beheben ist — Run-FAIL-artig gemäß §5.6-Pkt.-4-analoger NFR-4-Regel, kein stiller Vorbeilass):

   ```sh
   sh -c 'for f in $(find wiki -mindepth 2 -name index.md); do a="${f#wiki/}"; a="${a%/index.md}"; case "$a" in */*) continue;; esac; grep -qE "\($a/index\.md|\(\./$a/index\.md" wiki/index.md || echo "UNREACHABLE AREA: $a"; done; find wiki -mindepth 3 -type f -name "*.md" | sort -u | while read -r f; do d="${f#wiki/}"; a="${d%%/*}"; echo "NESTED AREA: $a"; done | sort -u'
   ```

   Die Formel prüft in zwei unabhängigen Läufen — je Verletzung **genau eine** deterministische Meldung:

   **(A) Index-Erreichbarkeits-Check** (erster Lauf): `find wiki -mindepth 2 -name index.md` — jede Ein-Ebenen-Area-`index.md` (`wiki/<area>/index.md`) MUSS aus `wiki/index.md` verlinkt sein (Root→Area, AD-9); verlinkt = Ziel in gepinnter §5.6-Form `(a/index.md` bzw. `(./a/index.md`. Fehlt der Link, **`UNREACHABLE AREA: <area>`** (textuell benannter Instruktions-Selbsttest-Befund, Run-FAIL gemäß §5.6-Pkt.-4-analoger NFR-4-Regel). `*/*`-Kandidaten (`wiki/a/b/index.md`) werden hier übersprungen — ihre Verletzung ist keine Erreichbarkeit, sondern die Struktur selbst und wird in (B) gemeldet.

   **(B) Zwei-Ebenen-Detektion** (zweiter Lauf): `find wiki -mindepth 3 -name "*.md" -type f` — jede Markdown-Datei mit drei Segment-Ebenen unter der Bundleroot (`wiki/<a>/<b>/…`) ist ein Zwei-Ebenen-Kandidat → **`NESTED AREA: <a>`** (die erste Ebene der nicht-zulässigen Struktur). Dieser Lauf schließt auch die **Area-ohne-`index.md`-Lücke**: `wiki/a/b/concept.md` (ohne `index.md`) war dem reinen `index.md`-Scan unsichtbar und wird jetzt erfasst (BH1/EC1). `sort -u` konsolidiert Mehrfach-Meldungen (mehrere Dateien unter derselben ersten Ebene → eine Meldung).

   Beide Läufe ohne Ausgabe = Discovery-SUCCESS. Die Meldungen sind **Instruktions-Selbsttest-Befunde** — kein Validator-Punkt, keine neue §7-Klasse (AD-3).

   - **`UNREACHABLE AREA: <area>`** — eine Area-`index.md` existiert, ist aber von der Bundleroot **nicht** verlinkt (kein Root→Area-Pfad): die Area bleibt für die Navigation unsichtbar (AD-9). Die Meldung ist ein textuell benannter **Instruktions-Selbsttest-Befund** (Run-FAIL gemäß §5.6 Pkt. 4-analoger NFR-4-Regel) — **kein** Validator-Punkt, **keine** neue §7-Klasse.
   - **`NESTED AREA: <area>`** — jede Markdown-Datei in einem Zwei-Ebenen-Pfad (Tiefe ≥ 3, Lauf (B), Pkt. 3): ein `wiki/a/b/index.md`-Kandidat wie auch ein `wiki/a/b/concept.md` **ohne** `index.md` (die Area-ohne-Index-Lücke, die der reine `index.md`-Scan übersähe) sind Fälle der **konsolidierten Zwei-Ebenen-Kartografie** (Pkt. 3): die Verzeichnisstruktur ist keine zugelassene Anlageform; ein solcher Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (keine Datei, kein Index-Link, Meldung, Run „teilweise erfolgreich") — **analog**, aber **bewusst nicht** über den §3.2-Kollisions-Hold der Dateikollision bestehender Concepts (§3.2, Z. 40, bliebe ungeschärft für brandneue Pfade).
   - Der Erreichbarkeits-Satz für **Root-Concepts** (jedes Root-Concept in `wiki/index.md` verlinkt) ist durch den Validator-Punkt-11-Check (§3 Punkt 11) abgedeckt und wird hier nicht dupliziert; der Selbsttest deckt die vom Validator offene Lücke (Root→Area-Navigation) ab. Die §5.6-Formeln (Z. 133–166) decken die **Link-Form** weiterhin ab (der Selbsttest prüft die Erreichbarkeit, nicht die Form — die Form bleibt beim §5.6-Form-Check).
3. **Konsolidierte Zwei-Ebenen-Kartografie (antwortet Defer F-07, schließt es):** Das Bundle-Navigationsmodell besteht ab Story 2.5 aus **einer** Area-Ebene: Root-Concepts (direkt aus der Bundleroot) + Areas (`wiki/<area>/`), jede mit genau einer frontmatterlosen `wiki/<area>/index.md`, die ihre Area-Concepts in gepinnter §5.6-Form verlinkt; die Bundleroot verlinkt die Area-`index.md`-Dateien (Navigation Root → Area, AD-9). **Verschachtelte Areas sind keine zugelassene Anlageform:** `wiki/a/b/` mit Concept darunter ist **kein** „Area mit Inhalt" — ein solcher Kandidat (Erstellungskandidat oder Discovery-Ziel) wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten: keine Datei, kein Index-Link, textuelle Meldung **`NESTED AREA: <area>`** (Pkt. 2); der Run bricht für dieses Gebilde mit „teilweise erfolgreich" ab (die übrigen erkannten Einheiten laufen weiter, NFR-4). Der Hold ist **§5.8-lokal** verankert (dieser Absatz) und trägt die **Discovery-Entscheidung** der Story — er ist **bewusst nicht** der §3.2-Kollisions-Hold der Dateikollision (§3.2, Z. 40): jener bleibt ausschließlich dem Fall vorbehalten, dass ein Ziel-Pfad bereits als Concept existiert („Concept existiert bereits — Aktualisierung ist Epic 3"); ein brandneuer Zwei-Ebenen-Pfad kollidiert mit keinem existierenden Pfad und wird daher über diesen §5.8-Hold gelenkt, nicht über §3.2. Die F-07-Frage „was ist Area mit Inhalt" ist damit instruktionsseitig deterministisch beantwortet: **Area mit Inhalt = `wiki/<area>/` mit `index.md` + Area-Concepts auf der Area-Ebene**; eine tiefere Verschachtelung ist kein eigener Bereich, sondern ein **§5.8-Zwei-Ebenen-Verstoß** (nicht erlaubt). Keine zweite Discovery-Ebene über die Zwei-Ebenen-Struktur hinaus (Boundaries, „Never").
4. **Suche = Consumer-grep (AD-13, FR-11, NFR-3):** Die Navigation ist die **primäre** Discovery (gewurzelte Erreichbarkeit, Pkt. 1–2). Die **Suche ist konsumenten-/extern-seitig** — die Discovery braucht **keine proprietäre Datenbank, keinen Such-Dienst, kein Embedding/Vector, kein Index-Datei-Format** (AD-8, AD-13): ein Consumer führt die textuell-deterministische Suche selbst aus, z. B. `grep -n <term> wiki/` bzw. `grep -rn <term> wiki/` (oder `ripgrep`) über den Markdown-Baum (NFR-3 „Standard-Dateioperationen"). Das Bundle bleibt ohne geladene Indizes — z. B. nach einem Git-Clone — vollständig verständlich (NFR-2, NFR-5). Der Story-2.5-Vorbehalt (§7 Z. 253 auf „Suche"-Rest gekürzt) ist damit aufgelöst: die Suche ist ein Consumer-Thema, kein Bundle-/Instruktions-Thema mehr.
5. **Discovery-Demo (optional, kein MOVE):** Bestehende Root-Concepts werden **nicht** in Areas verschoben (Kuratierung/AD-7d ist Epic-3-Nähe). Als Discovery-Demo **kann** (optional) ein **neues** Root-Concept `wiki/<concept>.md` ergänzt und (a) in der Bundleroot (§5.7 Pkt. 5) sowie (b) — rein informierend — über einen zusätzlichen Index-Link in gepinnter §5.6-Form aus einem bestehenden Area-Concept heraus verlinkt werden (der Inhalt bleibt Root-Concept; der Area-Link ist zusätzliche Erreichbarkeit, keine Neuzuordnung). Beide Verlinkungen halten die einheitliche Zwei-Ebenen-Kartografie (Pkt. 3). Die Durchführung ist **optional** (Matrix-Zeile `DISCOVERY_DEMO_ROOT_AREA_LINK`); sie **erhöht** die `(raw/`-Zählung der §5.6-Formel-4-Baseline (neuer Zuwachs-Run, Re-Baseline-Pflicht) und ist nur zusammen mit dem Nachweis dieses neuen Baselines zusätzlich durchzuführen — wird sie weggelassen, bleibt Formel 4 unverändert `38 ≡ 38` (kein Re-Baseline-Bedarf). Die hier beschriebene Regel ist die Demo-**Instruktion**; ob das konkrete Demo-Concept in diesem Run angelegt wird, entscheidet der Producer im Rahmen der optionalen Durchführung.

## 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=<area>") |
| §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) — in **§5.8** dieser Instruktion verankert (Story 2.5; AD-9, FR-11, AD-13, NFR-3). **Suche** bleibt konsumenten-/extern-seitig (Consumer-grep über `wiki/`, §5.8 Pkt. 4 — kein Bundle-/Instruktions-Thema mehr). Keine neue §7-Klasse, kein Schema-/Validator-Change.
- **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/§5.8), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-13 (Retrieval gehört zu Consumers / Suche = Consumer-grep / keine Embedding-Bereichszuordnung, §5.7/§5.8), 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-11 (Progressive Discovery siehe PRD-§4.3-Zeile unten — Discovery-Pfad/gewurzelte Erreichbarkeit, §5.8), FR-16 (Consumer-Unabhängigkeit), NFR-3 (Agent Readability — Standard-Dateioperationen/grep über `wiki/`, §5.8 Pkt. 4), 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/§5.8) 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.
- **Revision 2.3 (2026-08-18, Story 2.5):** Neue Sektion **§5.8 „Progressive Discovery über `index.md` (Story 2.5)"** eingefügt (nach §5.7, vor §6): (1) **Discovery-Pfad** (Bundleroot `wiki/index.md` → Area-`index.md` frontmatterlos → Area-Concepts in gepinnter §5.6-Form; Root-Concepts direkt aus der Bundleroot — AD-9/FR-11, gewurzelte Erreichbarkeit Root → Area → Concept), (2) **gewurzelte Erreichbarkeit als deterministisches Discovery-Kriterium + re-executierbarer Selbsttest** (`UNREACHABLE AREA: <area>` für unverlinkte Area; `NESTED AREA: <area>` für Zwei-Ebenen-Kandidaten inkl. der Area-ohne-`index.md`-Lücke `wiki/a/b/concept.md`; gekoppelte Meldungen an den Run-Nachweis gemäß §5.6-Pkt.-4-analoger NFR-4-Regel; Instruktions-Selbsttest, **keine** neue §7-Klasse — schließt die Validator-Navigation-Lücke, ohne Validator-Change, AD-3), (3) **konsolidierte Zwei-Ebenen-Kartografie** (respondiert Defer **F-07**, schließt es): Root + eine Area-Ebene; `wiki/a/b/` ist keine zugelassene Anlageform — der Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (keine Datei, kein Index-Link, Meldung `NESTED AREA: <area>`, Run „teilweise erfolgreich"); §3.2 bleibt der Dateikollision bestehender Concepts vorbehalten (Loopback-1-Renegotiation, Option A); (4) **Suche = Consumer-grep** (`grep -n <term> wiki/` / ripgrep, AD-13 — keine Such-Datenbank, kein Embedding, kein Index-Datei-Format), (5) **Discovery-Demo (optional, kein MOVE)** — Hinweis auf Formel-4-Re-Baseline-Pflicht bei Durchführung. Nachgeführt: **§7 Z. 253** (Story-2.5-Vorbehalt auf „Suche"-Rest gekürzt — Navigation/Area-Indizes jetzt in §5.8 verankert, Suche = Consumer-Thema), **§8-Normreferenzen** (AD-9/AD-13 → §5.8, FR-11 → §5.8/§5.7 Pkt. 5, NFR-3 neu, PRD-§4.3-Zeile nachgeführt) + **Revisionslog 2.3**. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/` (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.