wow20/schema/compiler.md

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

Status: abgeleitet (Story 2.1) — deterministische, agent-unabhängige Compiler-Instruktion für die Erzeugung neuer Concepts aus Source Material. Normative Grundlage: schema/wiki-compiler.md (autorisiert, Story 1.3) — insbesondere §2 Bundleroot, §3 Feldsubset (§3.1–§3.7), §5 log.md-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen. Prüfgrundlage: schema/validator.md (abgeleitet, Story 1.4; Revision 9) — 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. Diese sechs Phasen gelten für zwei Ausführungs-Varianten gleichermaßen: den Neu-Anlage-Pfad (Erzeugung neuer Concepts, §§4–5) und den Update-Pfad (inkrementelles Update bestehender Concepts, §3 + §5.9, Story 3.1). In beiden Varianten betreffen Reconcile (2) und Mutieren (4) die Erkennung und Veränderung betroffener Wissenseinheiten — neue Einheiten werden angelegt, bereits bestehende werden im bestehenden Concept-Pfad aktualisiert (never „Regenerate Everything", AD-5). Jede erzeugte und jede veränderte 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. Update-Routing (statt Kollision-Hold; Story 3.1): Existiert bereits ein Concept mit dem Ziel-Pfad, wird nicht stumm überschrieben und kein Duplikat angelegt — die erkannte Wissenseinheit wird als Update-Kandidat im bestehenden Concept-Pfad aktualisiert (Erweitern/Präzisieren/Korrigieren gemäß §5.9; FR-6). Die Mutationsmechanik für Updates spezifiziert §5.9; der Kollisions-Hold-Schutzprinzip („nicht stumm überschreiben") bleibt als Grundsatz der Erhaltung erhalten (AD-16-Default: bestehende Provenienz/Inhalte werden nie ohne Beleg entfernt). Der Neu-Anlage-Pfad dieser Instruktion bleibt für Wissenseinheiten, deren Ziel-Pfad nicht belegt ist (§5.1/§5.7). Kandidatenliste (betroffen-Bestimmung): Vor jeder Mutation erhebt der Producer die Menge der betroffenen Concepts als nachvollziehbare Kandidatenliste (relative OKF-Pfade ohne .md) mit textuell-deterministischen Mitteln (AD-13): (a) Term-/Konzept-Überschneidung zwischen der neuen Evidenz und den bestehenden Concept-Bodies via grep/ripgrep über wiki/ (z. B. rg -l '<term>' -g '!log.md' wiki/ bzw. GNU-grep-Form grep -rl '<term>' --exclude=log.md wiki/); (b) index.md-Traversal (Bundleroot- und Area-index.md-Dateien, gewurzelte Erreichbarkeit Root → Area → Concept, §5.8) der dadurch betroffenen Bereiche; (c) Link-Following aus bereits betroffenen Concepts (§5.6-Pin) auf weitere Concept-Pfade — mit besuchter Menge (ein bereits besuchter Concept-Pfad wird nicht erneut besetzt; keine Schleife bei zyklischen Links). Die Erhebung folgt der feinkörnigen, verbindlichen Mechanik in §3.2 Relevanzbestimmung (Story 3.2) — Term-Ziehverfahren (deterministisch aus der neuen Evidenz abgeleitet, kanonischer Schreibweisen-Resolver schema/canonical-terms.md, mehrere Terme je Einheit), dreistufige Erhebung mit log.md-Exklusion (die Candidate-Liste ist auf Concept-Pfade definiert, log.md ist kein Kandidat) und Determinismus-Vertrag (AD-17h/A0-19) — Erhebung nach §3.2. Die Kandidatenliste wird textuell festgehalten (Pre-Run-Reconcile-Check-Block, §5.9 Pkt. 6). Keine Embeddings/Vector-Suche (AD-13); §5.9 bindet die Erhebung an die in §3.2 genannten deterministischen Mittel. Löst eine erkannte Wissenseinheit auf keinen bestehenden Concept-Pfad auf (kein Update-Kandidat), wird sie als neue Einheit über den Neu-Anlage-Pfad (§5.1/§5.7, §3-Pkt.-1/-2-Kollisionsprüfung ist damit erstbestanden) behandelt.
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 oder aktualisiert werden (Run-FAIL, Vertrag §2).

3.2 Relevanzbestimmung (Story 3.2)

Diese Sektion ist der einzige Instruktions-Ort der feinkörnigen, textuell-deterministischen Relevanz-Findungsmechanik (D-3, Story 3.2) und die verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung („Erhebung nach §3.2"). Sie macht die Relevanzbestimmung vollständig deterministisch vorgegeben (AD-17h/A0-19): gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge — ohne Embedding/Vector/KG im Compiler-Kern (AD-13, A0-18, PRD OQ-3). Sie fügt kein Prädikat, keine neuen §7-Invaliditätsklassen und keinen Schema-/Validator-/raw/-Change hinzu (AD-3); die Candidate-Liste ist auf Concept-Pfade definiert, log.md ist ausdrücklich kein Kandidat (sie wird per Exklusions-Flag strukturell exkludiert — sonst wäre der eigene log.md-Eintrag bei jedem Term, den er zitiert, selbst „Kandidat"; die tool-spezifischen Flag-Formen nennt Pkt. 2a — rg -g '!log.md' bzw. grep --exclude=log.md; §5.9 Pkt. 5 behandelt log.md gesondert als erlaubtes Mitglied des Diff-Selbsttest-Satzes).

1. Term-Ziehverfahren (deterministisch): Die Candidate-Terme werden deterministisch aus der neuen Evidenz (committete raw/-Dateien, §1 Pkt. 1/2) abgeleitet — nicht freie LLM-Auswahl:
   • (a) Bedeutungstragende Token-Folgen: Der Producer benennt die bedeutungstragenden Fachbegriffe der Wissenseinheit gemäß der §2-Interpretation (fachliche Signifikanz; kein Stoppwort-Abgleich nötig, aber auch kein freies Urteil). Der Umfang „bedeutungstragend" ist die Auswahl derjenigen Begriffe, die das erkannte Thema identifizieren — als Token-Folgen über eine sprachliche Einheit hinweg zulässig (z. B. quanten-protocol-schlüssel).
   • (b) Normalisierung über den kanonischen Schreibweisen-Resolver: Jeder gezogene Term wird durchgängig normalisiert: (i) lowercasing; (ii) Binde-Varianten-Kollaps [-–_ ] → - (En-Dash –, Bindestrich -, Unterstrich _, Leerzeichen — jedes Vorkommen wird in einen einzelnen Bindestrich kollabiert); (iii) Auflösung über die committete, append-only Registry schema/canonical-terms.md (ein Eintrag = canonische Form + erlaubte Schreibvarianten; der Resolver ist damit Bestandteil des Git-States und die Auflösung pinbar). Genau eine canonische Form je Semantik (A0-18). Kein stiller Ausschluss: ist eine Variante nicht in der Registry auflösbar, wird der Term wie notiert verwendet (Kollaps-normalisiert) — niemals still verworfen.
   • (c) Mehrere Terme je Einheit erlaubt: Eine Wissenseinheit kann mehrere bedeutungstragende Terme tragen; die Candidate-Liste ist dann die Vereinigung der Treffer über alle Terme, bereinigt über die besuchte Menge (Pkt. 3c — ein Pfad nur einmal).
   • Bekannte Determinismus-Lücke (aufgezeichnet, nicht still hinzugefügt): Die Kollaps-Klasse [-–_ ] deckt den Em-Dash — nicht ab (nur En-Dash –). Em-Dash-Varianten fallen damit nicht unter den Kollaps — eine erkannte Synonym-Lücke, die Story 3.8 als offene Determinismus-Frage übergeben ist (s. deferred-work.md; nicht stillschweigend in §3.2 ergänzt).
2. Term-übergreifende Erhebung über wiki/ (drei Stufen): Der Producer erhebt die betroffenen Concept-Pfade in drei textuell-deterministischen Stufen (a → b → c). Ab der Workspace-Root:
   • (a) Stufe a — grep/ripgrep über wiki/: rg -l '<term>' -g '!log.md' wiki/ (rgs native Glob-Exklusions-Syntax — --exclude ist kein rg-Flag; das GNU-grep-Äquivalent ist grep -rl '<term>' --exclude=log.md wiki/, §5.6-Scan-Scope-Konvention). <term> = jeder gezogene Term aus Pkt. 1 nach Normalisierung. Beide Formen exkludieren log.md strukturell (unabhängig von dessen Inhalt) — die Candidate-Liste bleibt auf Concept-Pfade definiert.
   • (b) Stufe b — index.md-Traversal: Für die in Stufe a getroffenen Bereiche (und die Bundleroot) folgt der Producer der gewurzelten Erreichbarkeit Root → Area → Concept (§5.8): trifft ein Term nur wiki/index.md oder eine Area-index.md (nicht einen Concept-Body), so sind alle darunter gewurzelten Concept-Pfade Treffer der Stufe b (TRAVERSAL_REACH_ONLY). Fehlende Bundleroot → Run-FAIL (V-1, §3 Pkt. 3, besteht fort).
   • (c) Stufe c — Link-Following mit besuchter Menge: Aus bereits als betroffen erhobenen Concepts folgt der Producer die Concept-Links (§5.6-Pin) auf weitere Concept-Pfade — file-relativ auflösen (§5.7 Pkt. 4), jeder bereits besuchte Concept-Pfad wird nicht erneut besucht (besuchte Menge): Zyklen (A → B → A) enden, die Candidate-Liste bleibt endlich (LINK_FOLLOWING_ZYKLUS).
3. Candidate-Liste (Ausgabe) + Determinismus-Vertrag:
   • (a) Form: Die Candidate-Liste ist die Menge der betroffenen Concept-Pfade als relative OKF-Pfade ohne .md (AD-7a). Normalisierung der Ausgabe: aus jedem Treffer wiki/<pfad>.md werden wiki/-Präfix und .md-Suffix gestrippt (deterministischer Schritt → wiki/knowledge-kompilation-inkrementell.md wird knowledge-kompilation-inkrementell).
   • (b) Reihenfolge (Zuwachs-Sicht-Ordnung): Die Erhebung ordnet die Candidate-Liste deterministisch in Zuwachs-Sicht-Ordnung — Stufe-a-Treffer zuerst, danach Stufe-b-Treffer, danach Stufe-c-Treffer; innerhalb jeder Stufe rein lexikografisch aufsteigend (LC_ALL=C bzw. deterministische byte-Ordnung, AD-17h). Die Reihenfolge des ziehenden Terms bestimmt nur die Verarbeitungsreihenfolge der Terme in Stufe a (Interpretation/Erhebung), nicht die Reihenfolge der Candidate-Liste: dieselbe Treffermenge → identische Liste, unabhängig davon, in welcher Reihenfolge die Terme gezogen/verarbeitet wurden (AD-17h/A0-19). Die Stufe-b/c-Treffer sind damit positional bestimmt (nach allen Stufe-a-Treffern), nicht vom Dateisystem-Traversal abhängig.
   • (c) Keine Duplikate: Vereinigung über alle Terme und Stufen, bereinigt über die besuchte Menge (Pkt. 1c/2c) — jeder Pfad erscheint genau einmal.
   • (d) NO_MATCH: Trifft kein Term ein bestehendes Concept, ist die Candidate-Liste leer → UNTOUCHED_CONCEPT (Story-3.1-Pfad): keine Mutation, kein log.md-Zusatz (leere Menge ist Teilmenge jeder erlaubten Menge — Ghost-Diff-negativ, §5.9 Pkt. 5).
   • (e) Gleichheits-Identität: Gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge (AD-17h/A0-19). Der Selbsttest (Membership + Zwei-Run-Identität) wird in der Story-Specifizierungs-Verifikation und im wiki/log.md-Nachweis belegt.

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). Update-Pfad-Ergänzung (Review-Loop-2): bei einem FAIL im Update-Pfad (§5.9) gilt derselbe Grundsatz für modifizierte Pfade — die vor dem Run geänderten Concept-Pfade (und die log.md-Einträge des Runs) werden aus dem Baseline-Zustand wiederhergestellt (z. B. git checkout -- <wiki/pfad>; der Baseline-Commit ist der in R-1/Pkt. 6 notierte <Baseline-Commit>), sodass kein teilweise aktualisierter Concept-State liegen bleibt.
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-Update-Routing (A0-10, §3-nachgeführt): Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3 Pkt. 1/2, AD-7a; „§3.2" meint hier §3-Elemente Pkt. 1/2 — die §3.2-Relevanzbestimmung ist eine eigene Sektion, s. §3.2), löst das Update-Routing (§3 Pkt. 2, §5.9) aus — kein neues Prädikat, kein Duplikat, kein stiller Overwrite, keine neue Datei, kein Index-Link: die erkannte Einheit wird als Update-Kandidat im bestehenden Concept-Pfad behandelt (Mutation gemäß §5.9). 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 das Update-Routing der Dateikollision bestehender Concepts (§3 Pkt. 2, 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 ehemals offene Punkt-11-Lücke der file-relativen Area-Lesart — ein wörtlich-mechanischer Check meldete früher Concept nicht verlinkt=wissensarchitektur/source-material — ist mit der autorisierten Validator-Rev-9 geschlossen: die Area-Lesart ist in schema/validator.md formalisiert; siehe Pkt. 3 dieser Sektion und das Schließen des Aktionsitems in deferred-work.md.) 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). (Die in Pkt. 2 als offen notierte Punkt-11-Grenze ist mit dem Rev-9-Aktionsitem rückstandslos geschlossen — die Area-Lesart ist in schema/validator.md als „Revision 9" formalisiert; die Pkt.-1-Formulierung sieht dafür keine offene Lücke mehr vor.) 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 das Update-Routing der Dateikollision (§3 Pkt. 2): jenes bleibt ausschließlich dem Fall vorbehalten, dass ein Ziel-Pfad bereits als Concept existiert und als Update-Kandidat im bestehenden Pfad aktualisiert wird (§5.9); ein brandneuer Zwei-Ebenen-Pfad kollidiert mit keinem existierenden Pfad und wird daher über diesen §5.8-Hold gelenkt, nicht über das Update-Routing. 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.

5.9 Inkrementelles Update bestehender Concepts (Story 3.1)

Diese Sektion ist der einzige Instruktions-Ort der Update-Mutationsmechanik (D-3, Story 3.1) und der einzige Weg, wie ein Compilation Run neue Evidenz mit den tatsächlich betroffenen, bestehenden Concepts verrechnet — ohne unverändertes Wissen zu regenerieren (AD-5, A0-6, FR-6, FR-12). Sie ist eine weitere Spezifikations-Ebene der Mutationsphase §5 (nach §5.8, vor §6). Sie fügt kein Prädikat, keine neuen §7-Invaliditätsklassen und keinen Schema-/Validator-/raw/-Change hinzu (AD-3). Ein Update ist ein Compilation-Vorgang wie die Anlage: Er unterliegt denselben Phasen (§0: Interpretieren → Reconcile → Synthetisieren → Mutieren → Validieren), derselben Commit-Boundary = Mutations-Boundary (AD-17f, §0/§5.3) und derselben Validator-Erfolgsbedingung (§6).

1. Update-Stimulus (Input des Update-Pfads): Der Stimulus ist die im Reconcile erhobene Update-Kandidatenliste (§3 Pkt. 2): die Menge der betroffenen Concept-Pfade (relative OKF-Pfade ohne .md), bestimmt über die textuell-deterministischen Mittel (Term-/Konzept-Überschneidung via grep/ripgrep, index.md-Traversal, Link-Following; AD-13). Ein Lauf, der keinen Kandidaten erhebt (keine Überschneidung), mutiert kein bestehendes Concept — Erhaltungs-Invariante (Pkt. 5). Der Stimulus verarbeitet ausschließlich published/committed Input (§1 Pkt. 1, AD-17a): neue Source Materialien erst, sobald sie unter raw/ committet sind (R-1-Change-Detection, Pkt. 6), und das bestehende wiki/ aus committetem Zustand — nie Zwischenstände während einer Mutation.
2. Mutationsmechanik: Ein Update-Kandidat wird im bestehenden Concept-Pfad mutiert — keine neue Datei, kein Duplikat (FR-6). Drei Update-Formen, je nach Erkenntnis-Zuwachs:
   • Erweitern: Eine neue, belegte Aussage bzw. ein Absatz wird dem Body ergänzt; evtl. neue Aspekte, die von der neuen Evidenz getragen sind.
   • Präzisieren: Eine bestehende Aussage wird geschärft (Formulierung/Abgrenzung), der Beleg wird neu geführt oder nachgeführt (§5.5: Inline-raw/-Verweis mit existierender Stellen-Kennung).
   • Korrigieren: Eine fehlerhafte/überholte Aussage wird ersetzt — die ersetzte Aussage wird nicht still gelöscht, sondern explizit durch die ersetzende Aussage abgelöst, und die Ersetzung trägt einen Ersetzungsbeleg (die neue raw/-Evidenz als Inline-Verweis, §5.5). Keine stille Löschung bestehender Provenienz ohne Beleg (AD-16-Default: Erhaltung). Die AD-16-Klassifikation selbst (CORRECTING/CONTRADICTING etc.) ist Epic 4, Story 4.1, und wird hier nicht vorweggenommen — widersprechender Inhalt ohne Ersetzungsevidenz bleibt erhalten und wird gemäß Pkt. 4 in log.md explizit abgelegt.
   • Frontmatter-sources nur um echte neue Belege ergänzen: Für jede neu belegte Aussage, deren raw/-Datei nicht bereits in sources deklariert ist, wird ein neuer sources-Eintrag ergänzt (§5.5 Pkt. 1b — Relokation/Zielwechsel; Key-Subset Vertrag §3.3, Innen-Ebene). Bestehende sources-Einträge bleiben unverändert, sofern ihre Belege weiterhin Bestand des Bodys sind (keine Entfernung ohne Beleg).
   • generated.at-Konvention (A0-20): Ein maschinelles Update eines maschinell erzeugten Concepts bleibt maschinell → generated bleibt gesetzt, at wird auf den aktuellen Run-Zeitstempel aktualisiert (einmalige at-Festlegung pro Run, P1-Dryrun-Konvention). verified wird durch ein maschinelles Update nicht gesetzt; ein vorhandenes human-verified wird nicht entfernt (menschliche Kuratierung ist Bestandswissen, A0-21/FR-13-Nähe). Ein menschliches Update (manuelle Kuratierung, A0-21) ändert generated/verified nicht automatisch. AD-17h-Gap (Review-Loop-2, Home: Story 3.8): der Run-Zeitstempel (Wanduhr) bedeutet, dass zwei unabhängige Runs über dasselbe Eingabeset unterschiedliche at-Werte — damit unterschiedliche Bundle-States — erzeugen; die AD-17h-Determinismus-Verankerung (gleicher Git-State + gleiches Eingabeset → gleicher Bundle-State; Story 3.8) muss die Behandlung von at (z. B. Ausnahmemenge im Bundle-State-Vergleich oder Ableitung aus dem Git-State) definieren. Bis dahin bleibt die hier festgelegte Konvention (frozen Spec-Design-Note, A0-20; ein Wechsel des generated.at-Verhaltens ist Ask-First) bindend.
   • No-Op-Kandidat (Review-Loop-2-Präzisierung): Erhebt die Kandidatenerhebung einen Pfad, dessen Body die neue Evidenz bereits vollständig enthält (keiner der drei Update-Formen greift — keine neue belegte Aussage, keine Schärferung, keine Ersetzung), ist der Kandidat ein No-Op: keine Body-Mutation, kein generated.at-Bump, kein sources-Zusatz, kein log.md-Eintrag — der Pfad bleibt byte-identisch (Erhaltungs-Invariante, Pkt. 5). Die Entscheidung „keiner der drei Formata greift" ist selbst textuell deterministisch: sie trifft nur, wenn die neue Evidenz keine Aussage trägt, die im Body nicht bereits als belegte Aussage vorhanden ist (Term-/Stellen-Abgleich mit §5.5-Inline-Verweisen); im Zweifel (neue belegte Aussage auch nur in abgewandelter Form) greift Erweitern/Präzisieren — der No-Op ist die engere Auslegung.
   • Mehrfach-Treffer-Konsolidierung (ein Run, mehrere Einheiten auf denselben Concept-Pfad): Ergeben mehrere neue Wissenseinheiten desselben Runs auf demselben bestehenden Concept-Pfad ein Update, werden ihre Mutationen in einem einzigen Update dieses Pfads konsolidiert (eine Body-Änderung, ein log.md-Eintrag „Story 3.1-Update", ein konsolidierter sources-Zuwachs, ein generated.at-Zeitstempel — der einmalige at des Runs). Die Reihenfolge der Einheiten wird dabei textual-deterministisch aus der Verarbeitung der Evidenz abgeleitet: REIHENFOLGE = Auftritt der Einheiten in der Zuwachs-Sicht (Datei-Reihenfolge des R-1-Zuwachsbefunds, dann Stellen-Reihenfolge innerhalb der Datei); nur bei Einheiten desselben Ortes (identischer Dateipfad + identische Stelle) greift die lexicografische Ordnung als Tie-Break (Review-Loop-2-Präzisierung: die Reihenfolge ist für alle Einheiten definiert, nicht nur für vollständig unabhängige). Die AD-16-Default-Erhaltung bleibt für jede betroffene Stelle gewahrt.
   • Commit-Boundary = Mutations-Boundary (AD-17f, §0): Auch im Update-Pfad werden Zwischenstände nie als fertige Mutation veröffentlicht — die Mutationen der Update-Kandidaten werden als Ganzes committet, und zwar erst, nachdem der Diff-Selbsttest (Pkt. 5) ohne Ghost-Diff abgeschlossen ist. Ein Ghost-Diff ist dann als Abbruch-Vorlauf „korrigierter Teil-Run" im log.md-Eintrag des betroffenen Runs gekoppelt (siehe Disagreement-/Run-Notiz Pkt. 4), damit die Ursache textuell nachvollziehbar bleibt.
3. Index-/Link-Form unverändert (§5.6-Pin): Ein reines Body-Update ändert die Concept-Identität nicht → der bestehende Index-Link (Bundleroot oder Area-index.md) bleibt unverändert gültig; kein neuer Link bei reinem Body-Update (kein Index-index.md-Zusatz). Die log.md-Eintragspflicht (Pkt. 4) bleibt davon unberührt: jedes Update — auch ein reines Body-Update — MUSS seinen log.md-Eintrag „Story 3.1-Update" führen; nur der **Index-**Link bleibt unverändert. Wird durch das Update eine Concept-Kategorie (Root vs. Area) oder die Identität berührt, ist das Ask-First (AD-7d-Renames/Redirects; nicht Teil von Story 3.1). Neue zulässige Concept-Links (Beziehungsschicht, §5.6) werden nur gesetzt, wenn die neue Erkenntnis eine echte, inhaltsbegründete Beziehung rechtfertigt.
4. log.md-Eintragspflicht (Vertrag §5): Jedes Update wird als datumsgruppierter Eintrag in wiki/log.md dokumentiert (Header = ISO-Datum YYYY-MM-DD, neueste zuerst), verknüpft mit dem mutierten Concept-Pfad und den genutzten raw/-Quellen. Für Updates wird der Eintrag als „Story 3.1-Update" markiert (disambiguierbar von Anlage-Einträgen). Konflikt-/Erhaltungsfälle (Pkt. 2 „Korrigieren" ohne Ersetzungsevidenz) werden explizit als Disagreement-Eintrag mit dem mutierten Concept-Pfad geführt (AD-16b, Vertrag §5) — der Epic-4-Interface-Fall bleibt dokumentiert, ohne Korrektur-Klassifikation hier.
5. Erhaltungs-Invariante (Kern) + deterministischer Diff-Selbsttest (AD-17h, FT-6/FR-12): Ein Compilation Run darf nur die Concepts neu anlegen oder verändern, die durch den erkannten Erkenntnis-Zuwachs tatsächlich betroffen sind. Nicht betroffene Concept-Pfade bleiben byte-identisch unverändert — es gibt nie „Regenerate Everything" (AD-5, A0-6). Die Inkrementalität ist als re-executierbarer Diff-Selbsttest mechanisch kontrollierbar: Nach jedem Run prüft der Producer ab der Workspace-Root

   git diff --name-only <Baseline-Commit> -- wiki/
   git status --porcelain -- wiki/
   

   (erste Zeile: modifizierte/gelöschte Pfade gegen die Baseline; zweite Zeile: zusätzlich ungetrackte neue Pfade ?? und staged-Änderungen — die Duplikat-Kontrolle „keine neue Datei" braucht die ??-Sicht, die git diff allein nicht liefert; <Baseline-Commit> siehe Pkt. 6 R-1) dass die geänderten Dateien eine Teilmenge von (Kandidatenliste ∪ Neu-Anlage-Zielpfade ∪ log.md ∪ nachgeführte index.md) — mit der Kandidatenliste aus §3 Pkt. 2 (betroffene bestehende Concepts, relative OKF-Pfade ohne .md) plus den Zielpfaden aller im selben Run neu angelegten Concepts (§5.1/§5.7 — Misch-Runs) plus log.md und jede nachgeführte index.md als zusätzliche zulässige Einträge. Probe-Zeitpunkt (D-1-Präzisierung): die Probe läuft vor dem Commit, am Ende des P2-Check-Blocks (Pkt. 6) — nach dem Commit wäre git diff leer und die Probe vacuous (Commit-Boundary = Mutations-Boundary, AD-17f: der Run committiert erst, nachdem die Probe ohne Ghost-Diff abgeschlossen ist). Pfad-Normalisierung vor dem Teilmenge-Vergleich: die Proben-Ausgabe trägt wiki/-Präfix und .md-Endung; die Kandidaten-/Ziel-Pfade sind definiert als relative OKF-Pfade ohne .md — für den Vergleich werden von jedem Proben-Eintrag wiki/-Präfix und .md-Suffix gestrippt (deterministischer Normalisierungsschritt). Jede Abweichung (Ghost-Diff auf einem nicht betroffenen Pfad) ist ein Instruktions-Verstoß (FT-6): Der Producer behebt sie textuell benannt (NFR-4) und rollt den Ghost-Diff zurück, bevor der Run als gültig vermerkt wird — der beobachtbare Endzustand des Bundles bleibt damit konsistent (AD-6-Backstop). Rollback-Mechanik: der Ghost-Diff betrifft nur Pfade außerhalb der erlaubten Menge; der Producer stellt die betroffenen Pfade aus dem Baseline-Zustand wieder her (für modifizierte Pfade: git checkout -- <wiki/pfad>; für ungetrackte neue Dateien: Datei löschen; für Index-Änderungen: git checkout -- wiki/index.md bzw. die Area-index.md) — der Teilzustand-Rollback des §5.3 Pkt. 3 / §6 Pkt. 3 greift daneben unverändert. Für Story 3.1 selbst (Instruktions-Story ohne Inhalts-Mutation) ist der Nachweis: git diff --name-only -- wiki/ liefert ausschließlich wiki/log.md — keine Concept-Datei, keine index.md (die aggressive git diff --stat -- wiki/-Default-Effektiv-ausgabe zeigt denselben Pfad, wiki/log.md | 1 +). (Anmerkung: schema/compiler.md und deferred-work.md liegen außerhalb wiki/ und sind daher kein Teil dieser Diff-Probe — sie gehören zum Instruktions-, nicht zum Bundle-Baum; der Ghost-Diff-Begriff dieser Sektion gilt nur für wiki/.)
6. Run-Vorphase-Bausteine (Defer R-1 + P2, in den Update-Pfad eingearbeitet): Beide sind keine neuen Prozesse — wiederverwendbare, reproduzierbare textuelle Check-Blöcke innerhalb der Instruktions-Ausführung (D-3):
   • Change-Detection (Defer R-1, Input-Zuwachserkennung): Vor der Interpretation bestimmt der Producer, welche raw/-Dateien Zuwachs sind (neu/modifiziert). Deterministische Mittel: git diff --name-only <Baseline-Commit> -- raw/ auf das raw/-Verzeichnis und/oder der SHA-256-Record aus raw/**/source.md (Provenienz-Sidecar, §1 Pkt. 4). Als <Baseline-Commit> dient der letzte committete Zustand des Workspace (deterministisch: der HEAD der vorherigen Mutations-Boundary, AD-17f). Auflösungs-Regel (D-2-Präzisierung, Review-Loop 2): der Producer notiert den <Baseline-Commit> (vollen SHA) im wiki/log.md-Eintrag des Runs — damit ist er deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14: Git liefert Historie, nicht Domain-State; der log.md-Eintrag ist der State-Referenz-Punkt, keine Git-Historie-Interpretation). Diskrepanz-Regel: widersprechen sich git diff-Befund und SHA-256-Record für dieselbe Datei, gewinnt der git diff-Befund (Commit-Boundary = Mutations-Boundary, AD-17f); der SHA-256-Record bleibt Sekundär-Fingerprint. Ist der SHA-256-Record unlesbar/fehlend, wird die Datei dennoch als Zuwachs nicht doppelt verarbeitet (textueller Hinweis) und gegen den git diff-Befund abgeglichen (kein Doppel-Verdikt). Fallback: existiert keine vorherige Mutations-Boundary (frischer Workspace ohne Lauf-Historie), gilt alle raw/-Dateien als Zuwachs. Die Diff-Probe in Pkt. 5 läuft gegen dasselbe <Baseline-Commit> (Review-Loop-2-Korrektur des Rev-2.4.1-Claims: die Pkt.-5-Probe trägt das Baseline-Commit-Argument explizit).
   • Pre-Run-Reconcile-Check-Block (Defer P2): Vor jeder Mutation durchläuft der Producer den gebündelten Vorprüf-Block und hält ihn textuell fest: (1) Input-Zustand (AD-17a, I/O-Matrix INPUT_UNCOMMITTED; Review-Loop-2-D-3): Working-Copy von raw/ und wiki/ gegen HEAD prüfen — bei Abweichung (uncommitteder Zustand) bricht der Run mit dem textuell benannten Abbruch „published/committed Input erforderlich" ab, vor Interpretation und vor jeder Mutation (keine Mutation gegen Zwischenstände); (2) Ziel-Pfade (Ausgangs-Kandidatenliste, §3 Pkt. 2); (3) Quellen-Existenz (EC-1 via Validator-Punkt: jede referenzierte raw/-Datei existiert als Datei); (4) Betroffenheits-Kandidatenliste (§3 Pkt. 2, textuell-deterministisch); (5) wiki/index.md-V-1-Vorbedingung (fehlende Bundleroot → Run-FAIL, §3 Pkt. 3, Vertrag §2). Dieser Block ist der in deferred-work.md als P2 notierte Pre-Plan-Schritt und wird durch Story 3.1 als Teil des inkrementellen Runs ausgeführt. Zeitpunkt (Review-Loop-2-Präzisierung): der Block wird nach Reconcile (2) und vor Mutieren (4), am Anfang der Mutationsphase, einmal pro Run durchgeführt — die Kandidatenliste (Elemente 2/4) existiert zu diesem Zeitpunkt bereits; die Diff-Probe (Pkt. 5) läuft am Ende desselben Blocks, nach den Mutationen, vor dem Commit. Die Kandidatenliste, die hier festgehalten wird, ist die Kandidatenliste, gegen die der Diff-Selbsttest (Pkt. 5) prüft (keine zweite, davon abweichende Erhebung nach der Mutation).
7. Worked Example (an die reale Ist-Lage gebunden, re-executiert; Review-Loop-2-Korrektur): Ein Run mit neuer committeter Evidenz raw/epics/epics-2026-08-14.md#FR-12 (Zuwachs über die bisher verarbeitete Stelle hinaus; die Kennung FR-12 existiert real in der Datei) trifft über rg -l 'FR-12' -g '!log.md' wiki/ das bestehende Root-Concept wiki/knowledge-kompilation-inkrementell.md (Term-/Konzept-Überschneidung — re-executierter Befund: der Grep-Ausgabe-Pfad ist knowledge-kompilation-inkrementell, wiki/log.md exkludiert gemäß §3.2-Pkt.-2a; das Rev-2.4.1-Beispiel wissensarchitektur/source-material.md enthielt den Term nicht und ist damit korrigiert). Der Run aktualisiert diesen Pfad (Body-Erweiterung mit neuem §5.5-Inline-Beleg (raw/epics/epics-2026-08-14.md#FR-12), sources-Ergänzung um diesen resource — sofern nicht bereits deklariert, sonst No-Op gemäß Pkt. 2, generated.at = aktueller Run-Zeitstempel, log.md-Eintrag „Story 3.1-Update"). Die Diff-Probe (Pkt. 5, <Baseline-Commit>-Form) zeigt ausschließlich log und knowledge-kompilation-inkrementell (betroffen, normalisiert) — kein Ghost-Diff, keine index.md im Diff (der Index-Link bleibt unverändert).

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 sowie das inkrementelle Update bestehender Concepts gemäß §3 + §5.9 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).
• Synthese über mehrere Concepts (mehrere Sources → eine gemeinsame Wissensrepräsentation mit gemischter, claim-granularer Provenienz) → Epic 3, Story 3.4 (AD-4, FR-7). Die Verankerung des inkrementellen Datenflusses (Erweitern/Präzisieren/Korrigieren einzelner bestehender Concepts) bleibt §3 + §5.9 überlassen und ist dort bereits verankert (Story 3.1) — sie ist damit aus diesem Vorbehalt entlassen.
• Leasing / Dirty-Tree-Schutz für konkurrierende Producer → Story 3.5/3.6 (AD-17a..f, A0-12..A0-16); die bestehende Commit-Boundary = Mutations-Boundary-Regel (§0/§5.3, AD-17f) bleibt in v1 bestehender Schutz.
• Relevanzbestimmung (feinkörniger Relevanz-Findungsmechanismus der Kandidatenerhebung) — in §3.2 dieser Instruktion verankert (Story 3.2; Term-Ziehverfahren + Kanonisierungs-Resolver schema/canonical-terms.md, drei Erhebungs-Stufen grep/ripgrep + index.md-Traversal + Link-Following mit besuchter Menge, log.md-Exklusion, Candidate-Liste als relative OKF-Pfade ohne .md, Determinismus-Vertrag AD-17h/A0-19). Keine neue §7-Klasse, kein Schema-/Validator-Change; die Em-Dash-—-Varianten-Lücke ist als Determinismus-Frage an Story 3.8 übergeben.
• 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 9): §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; Punkt-11-Area-Lesart formalisiert).
• 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; Relevanzbestimmung textuell-deterministisch, §3.2), 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); A0-6 (inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update, §0/§3/§5.9), FR-6 (Aktualisierung statt neuer Dateien, §3/§5.9), FR-12 (unverändertes Wissen bleibt erhalten, §5.9), A0-18 (Deterministische Relevanzbestimmung — grep/ripgrep, index.md-Traversal, Link-Following, keine Embedding-/Vector-Infrastruktur; §3.2, AD-13, PRD OQ-3), A0-19 (Determinismus-Vertrag: gleicher Git-State + gleiche Eingabemenge → gleicher Bundle-State / gleiche Candidate-Liste in gleicher Reihenfolge; §3.2, AD-17h).
• PRD §4.3 (FR-11 — progressive Discovery, §5.7 Pkt. 5/§5.8) und §8.2/§8.3 (Canonical State; Separation of Concerns), PRD OQ-3 („Compilation Scope" — wie findet der Compiler relevante vorhandene Concepts; textuell-deterministische Relevanzbestimmung, §3.2; AD-13/A0-18; Muster raw/architecture-spine/…md §8.3).

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.
• Revision 2.4 (2026-08-18, Story 3.1): Neue Sektion §5.9 „Inkrementelles Update bestehender Concepts (Story 3.1)" eingefügt (nach §5.8, vor §6) — Update-Stimulus (Reconcile-Kandidatenliste), Mutationsmechanik (Erweitern/Präzisieren/Korrigieren; sources nur um echte neue Belege; generated.at = aktueller Run-Zeitstempel; verified unangetastet), Index-/Link-Form unverändert (§5.6-Pin), log.md-Eintragspflicht („Story 3.1-Update"-Markierung; Disagreement-Fälle bleiben dokumentiert, keine Korrektur-Klassifikation hier — Epic-4-Interface), Erhaltungs-Invariante + deterministischer Diff-Selbsttest (git diff --stat -- wiki/ ⊆ betroffene Concepts ∪ log.md ∪ Index; Ghost-Diff = textuell benannter Instruktions-Verstoß, FT-6/FR-12), Run-Vorphase-Bausteine (Defer R-1 Change-Detection via git diff auf raw/ + SHA-256-Record aus source.md; Defer P2 Pre-Run-Reconcile-Check-Block — Zielpfade, EC-1-Existenz, Kandidatenliste, V-1), Worked Example. §3 Reconcile: Pkt. 2 Kollision-Hold (bisheriger Epic-3-Abbruch bei bereits existierendem Concept) ersetzt durch Update-Routing (bestehende Wissenseinheit → Update-Kandidat im bestehenden Pfad; kein Duplikat, kein stummer Überschreib; AD-16-Default-Erhaltung) + textuell-deterministische Kandidatenliste (Konzept-/Term-Überschneidung via grep/ripgrep, index.md-Traversal, Link-Following — AD-13; feinkörniger Mechanismus Story 3.2). §0-Aufruf: sechs Phasen für Neu-Anlage- und Update-Variante präzisiert; Reconcile/Mutieren betreffen auch bestehende Concepts. §5.7 Pkt. 3 / §5.8 Pkt. 2/3: Top-Level-Referenz von „§3.2-Kollisions-Hold" auf das Update-Routing (§3 Pkt. 2, §5.9) nachgeführt (die bisherige Epic-3-Abbruch-Formulierung ist vollständig entfernt). §7: Update-Thema aus dem Epic-3-Vorbehalt entlassen (verbleibende 3.x-Themen benannt: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6, Relevanz-Verfeinerung → Story 3.2); Scope-Einleitung um die Update-Variante geöffnet. §8: Normreferenzen um A0-6/FR-6/FR-12 ergänzt. Abschlussklausel: Keine Änderung an schema/wiki-compiler.md/schema/validator.md/raw/ (AD-3); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
• Revision 2.4.1 (2026-08-18, Story 3.1, Step-04-Review-Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt): §5.9-Konsolidierung aus den drei Review-Layern — (1) Prüfgrundlage auf validator.md Revision 9 angehoben (§0-Header, §8-Link), §8-Verlusttext um die Punkt-11-Area-Lesart (Rev-9) ergänzt; (2) §5.9 Pkt. 5 Diff-Selbsttest operationalisiert (Probe git diff --name-only -- wiki/ statt --stat; Ergebnismenge ⊆ Kandidatenliste (explizit §3 Pkt. 2) ∪ log.md ∪ nachgeführte index.md; Rücksetzhilfe „ob der Ghost auf einem Kandidatenpfad liegt"); Klarstellung, dass schema/compiler.md/deferred-work.md außerhalb wiki/ liegen und daher nicht Teil der Diff-Probe sind — der Story-3.1-Nachweis ist wiki/log.md (Differenz zu den 4 volle git status --porcelain-Einträgen); Diff-Erwartung für das reine Body-Update in Pkt. 7 auf git diff --name-only umgestellt, Ergebnismenge wiki/log.md + wissensarchitektur/source-material.md (keine index.md); (3) §5.9 Pkt. 3-Widerspruch aufgelöst (Index-Regel unverändert, log.md-Eintragspflicht bleibt ausgeschlossen — Präzisierung „kein log.md-Zusatz" war falsch, korrekt „kein Index-Zusatz"); (4) §5.9 Pkt. 2 um Mehrfach-Treffer-Konsolidierung ergänzt (mehrere Einheiten → 1 Update/log.md-Eintrag/at; Verarbeitungsreihenfolge = Auftreten in der Zuwachs-Sicht); (5) §5.9 Pkt. 1/6-Anker §1.1/§1.4 → §1 Pkt. 1/Pkt. 4 (die tatsächlichen Label; §5.8-Pkt-2-Formel-Zeile bleibt historisch); (6) Ghost-Diff Konsequenz + Commit-Boundary-Umsetzung definiert (Rück-Rollen vor Run-Gültigkeit, log.md-Kopplung als Abbruch-Vorlauf „korrigierter Teil-Run"); (7) Defer-R-1-Baseline festgelegt (HEAD der vorherigen Mutations-Boundary); (8) §5.9 Pkt. 7-Worked Example auf den realen Ist-Baum gehoben (raw/epics/epics-2026-08-14.md#FR-12, rg -l 'FR-12'; das fiktive epics-2026-08-18.md/payload entfernt); (9) §5.8-Pkt-3-Revision-Feinschliff — die Rev-9-Lücke ist geschlossen; die Markierung ist Pkt. 3. Abschlussklausel der Patch-Runde: Keine Änderung an schema/wiki-compiler.md/schema/validator.md/raw/ (AD-3); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
• Revision 2.6 (2026-08-19, Story 3.2, Step-04-Review Loop 2, Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt): (1) §4-Überschrift wiederhergestellt — die §3.2-Einfügung (Rev 2.5) hatte die Überschrift ## 4. Synthetisieren (Provenienz & Trust) verdrängt (der §3.2-Sektionskopf ersetzte die §4-Überschrift; der gesamte Frontmatter-Body hing kopflos unter §3.2; alle §4-Referenzen wären dangling geblieben). Der §4-Kopf ist zwischen §3.2-Body und dem Frontmatter-Body wieder eingefügt; die §4-Referenzen zeigen wieder auf eine existierende Sektion; der §3.2-Body blieb unverändert erhalten. (2) rg-Flag-Defekt behoben (--exclude ist kein rg-Flag): die Stufe-a-Form in §3-Pkt.-2, §3.2-Pkt.-2a, §5.9-Worked Example (Pkt. 7) und §7 nutzten rg -l "<term>" --exclude=log.md wiki/ — nicht-existent (ripgrep 14.1.1: rg --exclude → unrecognized flag; GNU grep unterstützt --exclude, ripgrep nutzt -g "!log.md" / --glob "!log.md"). Die Instruktion nutzt jetzt tool-korrekte Formen: rg rg -l "<term>" -g "!log.md" wiki/ (native Glob-Exklusion) bzw. GNU grep grep -rl "<term>" --exclude=log.md wiki/; die §5.6-Formeln (bereits GNU-grep) und §5.9-Pkt.-7-Erhebung adoptieren die Exklusion. Verified: rg -l "A0-18" -g "!log.md" wiki/ → nur wiki/knowledge-kompilation-inkrementell.md; ohne Exklusion trifft rg -l "A0-18" wiki/ zusätzlich wiki/log.md (Selbstkontamination — der ausgeschlossene Fall, §3.2-Pkt.-2a). (3) §5.9-Worked Example (Pkt. 7) auf die Exklusions-Form gehoben (rg -l "FR-12" -g "!log.md" wiki/), Kommentar wiki/log.md exkludiert gemäß §3.2-Pkt.-2a. (4) Mini-Sandbox re-executierbar verankert (_bmad-output/implementation-artifacts/sandbox-3-2/run-sandbox.sh, Muster Story-3.1-Sandbox S1–S6): Tests T1–T4 (Membership-Pin — Term auf Concept-Bodies UND log.md verteilt, Candidate-Liste nur Concept-Pfade; Zwei-Run-Identität AD-17h; NO_MATCH → leere Candidate-Liste → UNTOUCHED_CONCEPT; Mehrfach-Treffer → Vereinigung + lexikografische Ordnung). (5) deferred-work.md-Em-Dash-Eintrag append-only ergänzt (Home: Story 3.8) — die §3.2-Pkt.-1b-Kollaps-Klasse deckt En-Dash/Bindestrich/Unterstrich/Leerzeichen, aber nicht den Em-Dash —; dieser Handoff wird nicht stillschweigend gelöst, sondern als offene Determinismus-Frage dokumentiert. (6) §3-Pkt.-2/§3.2-Präambel/§7-Nennungen der Exklusion auf die tool-korrekte Form angehoben. Abschlussklausel: Keine Änderung an schema/wiki-compiler.md/schema/validator.md/raw/ (AD-3); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. (Rev-2.5-Log-Eintrag bleibt unverändert — dokumentiert den Zustand bei Veröffentlichung der Revision 2.5, inkl. der damaligen --exclude-Form; historische Korrektheit des Logs.)
• Revision 2.5 (2026-08-19, Story 3.2): Neue Sektion §3.2 „Relevanzbestimmung (Story 3.2)" eingefügt (nach §3, vor §4) — die verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung („Erhebung nach §3.2"): (1) Term-Ziehverfahren deterministisch (bedeutungstragende Token-Folgen nach §2-Interpretation; Normalisierung lowercasing + [-–_ ]→--Kollaps; kanonischer Schreibweisen-Resolver schema/canonical-terms.md — committete, append-only Registry (canon. Form + erlaubte Varianten), damit Bestandteil des Git-States und deterministisch pinbar; genau eine canon. Form je Semantik A0-18; kein stiller Ausschluss nicht auflösbarer Varianten — Verwendung wie notiert; mehrere Terme je Einheit → Vereinigung), (2) dreistufige term-übergreifende Erhebung über wiki/ — (a) rg -l '<term>' --exclude=log.md wiki/ (grep-Äquivalent grep -rl … --exclude=log.md; log.md strukturell exkludiert, Candidate-Liste auf Concept-Pfade definiert), (b) index.md-Traversal (gewurzelte Erreichbarkeit Root → Area → Concept, §5.8; TRAVERSAL_REACH_ONLY; fehlende Bundleroot → Run-FAIL V-1), (c) Link-Following mit besuchter Menge (file-relativ auflösen, §5.7 Pkt. 4; Zyklen enden, LINK_FOLLOWING_ZYKLUS); (3) Candidate-Liste + Determinismus-Vertrag (AD-17h/A0-19): relative OKF-Pfade ohne .md (Strip wiki/-Präfix + .md-Suffix), Zuwachs-Sicht-Ordnung mit Reihenfolge auch für Stufe-b/c (nach Stufe-a; lexikografisch als deterministischer Tie-Break), keine Duplikate (besuchte Menge), NO_MATCH → leere Candidate-Liste → UNTOUCHED_CONCEPT (Story-3.1-Pfad); Determinismus-Selbsttest (Membership + Zwei-Run-Identität) in Spec-Verification und wiki/log.md belegt. §3 Pkt. 2: Story-3.2-Vorbehalt aufgelöst — Pkt. 2 bleibt Kern-Anker, die Erhebung zeigt auf die neue Sektion („Erhebung nach §3.2"), rg -l '<term>' --exclude=log.md wiki/ als Stufe-a-Form genannt. §7: Story-3.2-Vorbehalt aufgelöst (Relevanzbestimmung in §3.2 verankert; verbleibende 3.x-Themen: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6). §8: Normreferenzen um AD-13 (bereits gelistet, §3.2-angeankert), A0-18 (Deterministische Relevanzbestimmung, §3.2) und A0-19 (Determinismus-Vertrag, §3.2 — war im Ist-§8 noch nicht gelistet, wird als Determinismus-Referenz ergänzt) sowie PRD OQ-3 (Compilation Scope, §3.2) ergänzt; schema/canonical-terms.md als nebengeordnete committete Resolver-Registry referenziert (kein schema/-Root-Change; gleiche read-only-Hierarchie, append-only). Em-Dash-—-Varianten-Lücke als offene Determinismus-Frage an Story 3.8 übergeben (nicht stillschweigend ergänzt). Abschlussklausel: Keine Änderung an schema/wiki-compiler.md/schema/validator.md/raw/ (AD-3); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. sprint-status.yaml: Key 3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip backlog → in-progress. wiki/log.md-Eintrag (append-only, bestehende Bullets unverändert), deferred-work.md-epic-3-context-Eintrag → aufgegriffen (append-only), Determinismus-Selbsttest + Validator-Lauf (7/7 SUCCESS) siehe wiki/log.md-Nachweis.
• Revision 2.4.2 (2026-08-19, Story 3.1, bmad-code-review Loop 2, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4 = 1/1/1/1): (1) Diff-Selbsttest (Pkt. 5) operationalisiert + Blind-Spots geschlossen (D-1): Probe erweitert auf git diff --name-only <Baseline-Commit> -- wiki/ plus git status --porcelain -- wiki/ (erfasst ungetrackte neue Dateien ?? — die Duplikat-Kontrolle „keine neue Datei" braucht diese Sicht; git diff allein ist blind für Untracked); Probe-Zeitpunkt fixiert vor dem Commit (am Ende des P2-Blocks, nach den Mutationen) — nach dem Commit wäre die Probe vacuous (leere Ausgabe, AD-17f); erlaubte Teilmenge-Menge um Neu-Anlage-Zielpfade (§5.1/§5.7) ergänzt — Misch-Runs (Neu-Anlage + Update im selben Run) markieren neu angelegte Pfade nicht fälschlich als Ghost-Diff; Pfad-Normalisierung definiert (Strip wiki/-Präfix + .md-Suffix vor dem Teilmenge-Vergleich, da Kandidaten/Ziel-Pfade als relative OKF-Pfade ohne .md definiert sind); Rollback-Mechanik für den Ghost-Diff deterministisch benannt (modifizierte Pfade via git checkout -- <wiki/pfad>, ungetrackte neue Dateien gelöscht, Index via git checkout -- <index>; §5.3/§6.3-Teilzustand-Rollback greift daneben unverändert). (2) R-1-Baseline deterministisch + Abweichungsregel (D-2): <Baseline-Commit> (HEAD der vorherigen Mutations-Boundary, AD-17f) wird vom Producer im wiki/log.md-Run-Eintrag notiert (voller SHA) — deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14); Diskrepanz-Regel: widersprechen git diff-Befund und SHA-256-Record derselben Datei, gewinnt git diff (Commit-Boundary-Prinzip), SHA-256 bleibt Sekundär-Fingerprint; Fallback: ohne vorherige Mutations-Boundary gelten alle raw/-Dateien als Zuwachs; Rev-2.4.1-Claim „derselbe Baseline-Commit wie Pkt. 5" korrigiert (die Pkt.-5-Probe trägt das Baseline-Commit-Argument jetzt explizit). (3) INPUT_UNCOMMITTED-Abbruch (D-3) + Anker-Divergenz: neuer P2-Check-Block-Element (1) Input-Zustand — Working-Copy von raw//wiki/ gegen HEAD prüfen, bei Abweichung benannter Abbruch „published/committed Input erforderlich" vor Interpretation und vor jeder Mutation (AD-17a, I/O-Matrix-INPUT_UNCOMMITTED — zuvor nur Referenz auf §1 Pkt. 1, keine Zustandsprüfung/Abbruchmeldung); die Spec↔Anker-Divergenz (frozen Spec zitiert 3× „§1.1", §1 ist eine nummerierte Liste Pkt. 1–4 ohne §1.1-Label; Rev-2.4.1 korrigierte nur die Anker in compiler.md) wird hier als dokumentierte Fußnote gesichert — die Spec bleibt frozen (nur per menschlicher Renegotiation änderbar). (4) Sandbox-Edge-Test-Nachweis (D-4): die fünf I/O-Matrix-Szenarien (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) + die D-3-Abbruch-Kontrolle sind als re-executierbare Sandbox-Skripte mit konkreten deterministischen Ausgaben in der Spec-## Verification-Sektion (Sandbox-Beleg) verankert — die wiki/log.md- und deferred-work.md-Verweise („in der Spec-Verification enthalten") auflösbar. (5) Instruktions-Präzisierungen: P2-Block-Zeitpunkt (nach Reconcile, am Anfang der Mutationsphase; Diff-Probe am Block-Ende) — löst den Widerspruch „einmal an der Spitze erhoben" vs. „Kandidatenliste entsteht erst im Reconcile"; No-Op-Kandidat-Regel (Pkt. 2: Pfad, der die Evidenz bereits vollständig enthält → keine Mutation/kein at-Bump/kein log.md-Eintrag, byte-identisch — die engere Auslegung); Mehrfach-Treffer-Reihenfolge für alle Einheiten definiert (Zuwachs-Sicht-Ordnung; lexicografisch nur als Tie-Break bei identischem Ort — AD-17h); Update-Pfad-Rollback in §5.3 Pkt. 3 (modifizierte Pfade aus Baseline-Commit wiederherstellen); generated.at↔AD-17h-Gap explizit als offener Punkt mit Home Story 3.8 benannt (Wanduhr-at erzeugt bei gleichem Input unterschiedliche Bundle-States; Konvention bleibt bis dahin bindend, Wechsel = Ask-First); Term-Ableitung (Pkt. 2 (a)) als §2-Interpretation abgegrenzt — die Erhebung mit festem Term ist textuell-deterministisch, der Term-Mechanismus (Kanonisierung/Synonyme) Story 3.2; Link-Following mit besuchter Menge (keine Schleife bei zyklischen Links); Worked Example (Pkt. 7) auf den realen Ist-Baum korrigiert (rg -l 'FR-12' wiki/ trifft wiki/knowledge-kompilation-inkrementell.md, nicht wissensarchitektur/source-material.md — Rev-2.4.1-Beispiel enthielt den Term nicht); stale-Anker §3.2-Kollisionsprüfung (Pkt. 3-Zuordnung) und §3-Voraussetzungsprüfung (P2-Block) sowie §5.8-Pkt.-3-Zeiger („Pkt. 1" → „Pkt. 2") nachgeführt. Abschlussklausel: Keine Änderung an schema/wiki-compiler.md/schema/validator.md/raw/ (AD-3); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
• Revision 2.7 (2026-08-19, Story 3.2, Step-04-Review Loop 3, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4/D-5 = 1/1/1/1/1, jeweils empfohlene Option; + 2 Patches; D-3-Instruktions-Patch, kein neuer Inhalt): (1) §3.2-Pkt.-3b-Ordnung auf reine Lexikografie gehoben (D-4): Stufe-a-Treffer waren „in der Reihenfolge des ziehenden Terms, dann lexikografisch als deterministischer Tie-Break" — die Term-Ordnung selbst war für Mehrfach-Terme (Pkt. 1c) nirgends festgelegt, zwei rechtmäßige Term-Ordnungen erzeugten zwei unterschiedliche Listen (AD-17h-Lücke). Jetzt: innerhalb jeder Stufe rein lexikografisch aufsteigend (LC_ALL=C); die Term-Verarbeitungsreihenfolge dient nur der Interpretation/Erhebung, nicht der Listen-Ordnung — dieselbe Treffermenge → identische Liste. (2) schema/canonical-terms.md-Lookup-Semantik vervollständigt (D-5): Lookup-Verfahren deterministisch fixiert (lowercasing → [-–_ ]→--Kollaps → Lookup der normalisierten Form; Spalten tragen ausschließlich normalisierte Formen), Eindeutigkeits-Invariante (jede normalisierte Form in genau einem Eintrag — Canon oder Variante, nie beides/zweimal) + Konflikt-Verfahren (keine stille Anhängung; deferred-work.md-Handoff / Ask-First, analog zur Umbenennungs-Regel). (3) Statuskette in-progress → done dokumentiert (D-1): der Review-Loop-Abschluss-Flip in-progress → done (Sprint-Sync-Konvention, Story-3.1-Präzedenz) war in keinem wiki/log.md-Eintrag als eigener Schritt belegt — nachgeführt als neuer oberster wiki/log.md-Bullet (append-only; die gefrorene Always-Klausel → in-progress beschreibt den Implementierungsstand, der Review-Abschluss done ist der übliche Folgezustand). (4) Mini-Sandbox um T5/T6/T7 erweitert + T1/T4-Asssertionen + T2-Kommentar-Korrektur (D-2 + Patch P-1): T5 LINK_FOLLOWING_ZYKLUS (A→B→A-Links; besuchte Menge → endliche, doppelungsfreie Liste), T6 TRAVERSAL_REACH_ONLY (Term nur in Area-index.md → gewurzelte Concept-Pfade als Kandidaten; index.md selbst ist kein Concept-Kandidat), T7 TERM_ABLEITUNG_SYNONYM (Registry-Test-Doppel: Schreibvarianten → canonische Form via Lookup auf normalisierter Form; Negativ-Fall: nicht auflösbar → wie notiert, kein stiller Ausschluss); T1/T4 tragen jetzt harte Pass/Fail-Asssertionen (exit 1 bei Abweichung) — die exakte Candidate-Liste wird erzwungen, nicht nur ausgegeben; der T2-Kommentar zu index korrigiert (Stufe-a-Treffer auf wiki/index.md löst Stufe b aus; index.md ist kein Concept-Kandidat). (5) Selbsttest-Beleg (b) gegen den realen Sandbox-Ist-Baum re-executiert (D-3): der Rev-2.5-Log-Beleg (b) beschrieb einen nicht-committierten Baum (Term quanten-protocol, sub/beta.md, SHA-256 159092bb…) — Stale-Evidenz-Falle (B1-Präzedenz). Der Nachweis wird jetzt gegen die echte run-sandbox.sh-Ausgabe (Term deterministische-relevanz-bestimmung, root-level alpha/beta/gamma) neu belegt; der Rev-2.5-Eintrag bleibt historisch unverändert, die Korrektur steht als neuer wiki/log.md-Bullet (append-only). (6) Typos im normativen Text korrigiert (Patch P-2): Determinsmus → Determinismus (§8-Referenzen + Log-/Defer-Belege), §3.2-beankert → §3.2-angeankert, Membrum → Mitglied (Spec-Design-Notes), Konventionelle Determinismus-Lücke → Bekannte Determinismus-Lücke (Defer-Beleg; compiler.md:53 sagt „Bekannte"), Resovierung → Auflösung (Spec-Change-Log/-Verification). Abschlussklausel: Keine Änderung an schema/wiki-compiler.md/schema/validator.md/raw/ (AD-3); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. (Revisionslog-Reihenfolge-Anomalie 2.6/2.5 bleibt als dokumentierter Defer bestehen — nicht in dieser Runde umgeordnet.)