wow20/schema/compiler.md

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

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

0. Zweck & Aufruf

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

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

Entscheidungsebenen (keine eigene Norm):

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

1. Input (was der Compiler konsumiert)

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

2. Interpretieren (Wissenseinheiten erkennen)

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

3. Reconcile (gegen das bestehende Bundle)

1. Vor der Anlage prüfen, ob die erkannte Wissenseinheit bereits als Concept im Bundle existiert (deterministisch: Dateikollision über den relativen OKF-Pfad, AD-7a).
2. Kollision-Hold: Existiert bereits ein Concept mit dem Ziel-Pfad, wird nicht stumm überschrieben. Diese Instruktion deckt die Anlage neuer Concepts ab; die Erweiterung/Präzisierung/Korrektur bestehender Concepts ist Epic 3 (AD-5, FR-6). Der Run bricht für diese Einheit mit einem textuell identifizierbaren Hinweis ab („Concept existiert bereits — Aktualisierung ist Epic 3") und setzt mit den übrigen erkannten Wissenseinheiten fort; die gehaltene Einheit erzeugt keine Datei, keinen Index-Link und keinen log.md-Eintrag. Mindestens eine erfolgreich erzeugte und mindestens eine gehaltene Einheit → der Run ist teilweise erfolgreich: die erzeugten Concepts werden normal validiert und veröffentlicht, die gehaltenen Einheiten werden textuell als solche benannt (NFR-4).
3. Der Run prüft zusätzlich, ob wiki/index.md als Bundleroot existiert (V-1-Vorbedingung des Validators); fehlt sie, darf kein Concept erzeugt werden (Run-FAIL, Vertrag §2).

4. Synthetisieren (Provenienz & Trust)

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

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

5. Mutieren (Dateien schreiben)

1. Ziel-Pfad: Das neue Concept ist eine Markdown-Datei unter wiki/. In dieser Story (keine deterministische Area-Zuordnung; Story 2.4) werden neue Concepts auf Root-Ebene angelegt: wiki/<concept-kebab-case>.md. Es wird kein wiki/<area>/-Verzeichnis angelegt; ein als Area gedachtes Ziel (Unterverzeichnis) wird bis Story 2.4 abgelehnt und führt zu einem textuell identifizierbaren Hinweis („Area-Zuordnung ist Story 2.4").
   • 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 (Root-)Concept in der Bundleroot wiki/index.md verlinkt werden — seine Identität (relativer OKF-Pfad ohne .md) als relativer Bundle-Pfad referenziert, mit oder ohne .md-Endung (eine genau-eine-Form-Festlegung ist Story 2.3). Ohne diese Verlinkung ist das Bundle strukturell invalide (§7 Punkt 11).
   • All dies (Anlage + Verlinkung + log.md) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f). Bei Validierungs-FAIL wird der Teilzustand explizit zurückgerollt: neue Concept-Datei(en) gelöscht, zugehörige Index-Verlinkung(en) aus wiki/index.md entfernt, log.md-Eintrag(e) wieder entfernt — das Bundle nimmt seinen Zustand vor dem Run wieder ein (keine partielle Mutation bleibt liegen).
4. Dokumentation (log.md, Vertrag §5): Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in wiki/log.md dokumentiert (neueste zuerst; Header = ISO-Datum YYYY-MM-DD), verknüpft mit dem neuen Concept-Pfad und den genutzten raw/-Quellen. log.md bleibt ohne Frontmatter (Punkt 10).

5.5 Claim-granulare Provenienz (Story 2.2)

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

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

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

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

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

   • Die Komma-Form wird verwendet, wenn die Stellen-Kennung im Rohdokument als Sektionstitel/Nummer ohne Bezeichner-id vorliegt (z. B. § 1 Vision, § 4.5 FR-16, § 0 Document Purpose) — ein #-Fragment wäre hier ein künstlicher Anker. Für Bezeichner-ids (FR-*, A0-*, AD-*) bleibt die #-Form die Default-Form. Bis Story 2.3 bleibt die Frage „Link-Form (<pfad>) ggü. [<text>](<pfad>)" formal offen — beide sind zulässig, 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).

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, 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: jeder neue Root-Concept-Pfad ist in wiki/index.md verlinkt.
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 Root-Pfad & Verlinkung (Punkt 11, §6)	wiki/<slug>.md + Link in wiki/index.md	Concept ohne Link in index.md → Punkt 11; wiki/<area>/<slug>.md → Bereichs-Hinweis (Story 2.4)
§5.4 log.md-Dokumentation (§5)	datumsgruppierter Eintrag mit Concept-Pfad + Quellen	fehlender Eintrag → kein Validator-FAIL, aber dokumentarische Pflicht verletzt
§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 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) → Story 2.4 (AD-7c, A0-10).
• Progressive Discovery über index.md (Navigation, Area-Indizes, Suche) → Story 2.5 (AD-9, FR-11).
• Eine genau-eine-Linkform (mit/ohne .md-Endung) → Story 2.3 (AD-7b, A0-9) — der Punkt-11-Check akzeptiert beide Schreibweisen.
• Aktualisierung bestehender Concepts (Erweitern/Präzisieren/Korrigieren) und Synthese über mehrere Concepts → Epic 3 (AD-5, FR-6/FR-7).
• Standalone-Compiler / eigene LLM-Runtime / MCP → verboten in v1 (D-3, D-4, AD-11).
• OKF-Dialekt / Schema-Erweiterung → niemals (AD-1a; Vertrag §7 „abschließende Liste").

8. Normreferenzen & Revisionslog

Normreferenzen (read-only):

• schema/wiki-compiler.md — autorisierter Vertrag (Story 1.3): §2 Bundleroot, §3.1–§3.7 Feldsubset & Formate, §5 log.md-Typ, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
• schema/validator.md — Prüfgrundlage (Story 1.4, Revision 8): §3 14 Punkte, §4 Normalform (Reihenfolge §4.1, ISO-8601 §4.3), §5 Verdikt, §6 Fachprüfungen (EC-1 Existenz, EC-3 Kalender, EC-11 non-md).
• Architektur-Spine (raw/architecture-spine): AD-2/AD-3 (raw immutable), AD-4a (claim-granulare Provenienz, §5.5), AD-5 (inkrementelle Kompilation), AD-6 (Reason/Mutate-Trennung), AD-7a (Identität = OKF-Pfad ohne .md), AD-9 (Progressive Discovery), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-13 (Retrieval gehört zu Consumers), 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-16 (Consumer-Unabhängigkeit), A-4 (nur lokale Sources).
• Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5; A0-3 (Kontext-Marker-Wortlaut, §5.5); FR-6/FR-12/FR-14, A0-6/A0-7/A0-11/A0-18 (Belege der nachkonformierten Concept-Bodies).

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.