mita/wow20
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
validator-rev-9
wow20/schema/compiler.md
T

82 KiB
Raw Permalink Blame History

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

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-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.3 Pkt. 3) 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 gemäß §5.6 Pkt. 4-analoger NFR-4-Regel, kein stiller Vorbeilass). Prämisse (Loop-3-Fix): die Formel setzt POSIX-sh mit GNU-find/grep/sort (z. B. Git-Bash auf win32, NFR-1/NFR-5) und die Arbeitsverzeichnisse wiki/index.md ab — die CWD-Präguard der Formel meldet SELBSTTEST-SETUP-Fehler: … mit Exit 1, wenn wiki/index.md fehlt (falsches CWD), statt mit leeren Ausgabe + Exit 0 als SUCCESS durchzugehen:

    sh -c '[ -f wiki/index.md ] || { echo "SELBSTTEST-SETUP-Fehler: Workspace-Root (wiki/index.md fehlt)"; exit 1; }; find wiki -mindepth 2 -name index.md | while IFS= read -r f; do a="${f#wiki/}"; a="${a%/index.md}"; case "$a" in */*) continue;; esac; grep -qF "]($a/index.md" wiki/index.md || grep -qF "](./$a/index.md" wiki/index.md || echo "UNREACHABLE AREA: $a"; done; find wiki -mindepth 3 -type f -name "*.md" | LC_ALL=C sort -u | while IFS= read -r f; do d="${f#wiki/}"; a="${d%%/*}"; echo "NESTED AREA: $a"; done | LC_ALL=C 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 = echtes Markdown-Link-Ziel in gepinnter §5.6-Form ](a/index.md bzw. ](./a/index.md in der Bundleroot (Loop-3-Fix: das Muster prüft die Linksyntax ](, nicht das bloße Klammer-Paar — ein Prosa-Ausdruck (a/index.md ohne ]( besteht den Check nicht; grep -qF (Fix-String) statt ERE, damit ERE-Metazeichen im Area-Namen kein stilles Durchpassen erzeugen). 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 -type f -name "*.md" — 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. LC_ALL=C sort -u konsolidiert Mehrfach-Meldungen (mehrere Dateien unter derselben ersten Ebene → eine Meldung; C-Locale macht die Meldungsreihenfolge umgebungsunabhängig deterministisch, AD-17h). Zwei Zustände (Loop-3-Klarstellung): (1) Hold-Zeitpunkt — der Erstellungskandidat wird im Mutieren-Schritt (Pkt. 3) angehalten: keine Datei, kein Index-Link; (2) Formel-Befund — existiert eine Markdown-Datei in Tiefe ≥ 3 unter der Bundleroot (nachträglich oder auf einem synthetischen Prüfbaum), meldet dieser Lauf NESTED AREA: <a>; der Sandbox-Nachweis im log.md-Eintrag belegt die Detektion auf einem synthetischen Baum mit angelegter Testdatei.

    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 (Trigger: Mutieren-Schritt, Pkt. 3 — keine Datei, kein Index-Link, Meldung, Run „teilweise erfolgreich"; nachträgliche bestehende Tiefe-≥-3-Dateien meldet Lauf (B)) — 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. (Bekannte offene Lücke des Punkt-11-Checks: die file-relative Area-Lesart — ein wörtlich-mechanischer Check meldete Concept nicht verlinkt=wissensarchitektur/source-material; Behebung steht im Rev-9-Aktionsitem, s. deferred-work.md, Spec-2.4-Defer.) 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). Tiefen-Definition (Loop-3-Klarstellung): „Tiefe" ist die Segment-Anzahl unter der Bundleroot — wiki/<a>/<b>/… hat Tiefe ≥ 3 (zwei Verzeichnisstufen plus Datei); das ist exakt die find -mindepth 3-Schwelle von Lauf (B). Die Meldung benennt immer die erste Ebene <a> der nicht-zulässigen Struktur. Trigger im Run-Flow (Loop-3-Fix): der Hold feuert im Mutieren-Schritt (§0-Ablaufstruktur, Schritt (4)) — der Producer prüft vor Anlage eines Ziel-Pfads dessen Tiefe unter der Bundleroot; Tiefe ≥ 3 → Hold (kein §5.7-Routing kann Tiefe ≥ 3 strukturell erzeugen, der Hold sichert die Regel zusätzlich). Lauf (B) der Selbsttest-Formel bleibt der nachträgliche Baum-Check gegen bestehende Tiefe-≥-3-Dateien. 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 -rn <term> wiki/ (rekursiv) bzw. rg <term> wiki/ (ripgrep) über den Markdown-Baum (NFR-3 „Standard-Dateioperationen"); die rekursive Form ist verbindlich — ein nicht-rekursives grep -n <term> wiki/ schlägt auf ein Verzeichnis fehl (Exit 2). 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.3 Pkt. 3) sowie (b) — rein informierend — über einen zusätzlichen Body-Link in gepinnter file-relativer §5.6-Form ([<text>](../<concept>.md)) aus einem bestehenden Area-Concept heraus verlinkt werden (z. B. aus wiki/wissensarchitektur/source-material.md; der Inhalt bleibt Root-Concept; der Area-Body-Link ist zusätzliche Erreichbarkeit, keine Neuzuordnung; ein Link aus einer Concept-Body-Datei ist ein Body-Link, kein Index-Link — §5.6 Pkt. 2). 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=")
§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 (Story-2.5-Vorbehalt auf „Suche"-Rest gekürzt — Navigation/Area-Indizes jetzt in §5.8 verankert, Suche = Consumer-Thema; die Vorbehalt-Zeile lag in der Baseline main bei Z. 253, nach dem §5.8-Einschub bei Z. 285), §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.
Reference in New Issue View Git Blame Copy Permalink