wow20/schema/validator.md

Validator-Instruktion — OKF-Schema-Validierung für das Knowledge Bundle (Story 1.4)

Status: abgeleitet (Story 1.4) — deterministische, agent-unabhängige Validierungs-Instruktion auf Basis des autorisierten Schema-Vertrags. Normative Grundlage: schema/wiki-compiler.md (autorisiert, Story 1.3) — insbesondere §1 Geltungsbereich, §2 Bundleroot/Frontmatter, §3 Feldsubset (§3.3–§3.7), §5 log.md-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste struktureller Invalidität, §8 Normreferenzen. Validator-Revision: 2 (Revisionslog in §8) Ableitungsdatum: 2026-08-15

0. Zweck & Aufruf

Diese Datei ist der einzige Ort der Validierungs-Instruktion des Projekts. Sie ist rein textuell — kein ausführbarer Code, kein Standalone-Programm (D-3). Sie wird von einem Agent/Prozess mechanisch, deterministisch und ohne LLM-Urteil befolgt (AD-13, AD-17h, Q-6). Sie bildet die abschließende 14-Punkte-Invaliditätsliste des Vertrags (§7) 1:1 als mechanische Prüfschritte ab und legt die von Deferred-Work an Story 1.4 verwiesenen Validator-Entscheidungen deterministisch fest.

Aufruf: Vor jeder Mutation des Bundles führt der Producer/Validator den Run in der folgenden festen Ablaufstruktur aus (deterministische Reihenfolge, §4.4): (1) Prüfumfang bestimmen (§1), (2) Dateien klassifizieren (§2), (3) Voraussetzungen prüfen (§3.2), (4) je Datei die 14 Punkte in Reihenfolge prüfen (§3, Abbruch bei erstem FAIL, §4.4), (5) nach PASS der 14 Punkte die fachlichen Zusatzprüfungen ausführen (§6), (6) Verdikt je Datei ausgeben (§5). Das Ergebnis je geprüfter Datei ist ein maschinenlesbares Verdikt (SUCCESS/FAIL, §5). Bei mindestens einem FAIL gilt der gesamte Run als gescheitert; das Bundle wird nicht mutiert und raw/ bleibt unangetastet (AD-3, NFR-4).

Entscheidungsebenen (kein LLM-Urteil):

Behauptung (Normativ):  schema/wiki-compiler.md  (§7: abschließende 14-Punkte-Liste)
Ableitung (Story 1.4):  schema/validator.md      (Prüfschritte je Punkt + Verdikt-Format)
Ausführung:             deterministisch von einem Agent/Prozess befolgt (kein LLM-Urteil)

1. Prüfumfang (Vertrag §1)

1. Erfasst werden ausschließlich Markdown-Dateien (.md) innerhalb der Bundleroot wiki/:
   • die Bundleroot wiki/index.md,
   • Area-index.md-Dateien (jede index.md unterhalb eines Area-Verzeichnisses),
   • Concept-Dateien (alle übrigen .md-Dateien unter wiki/),
   • wiki/log.md (reserviertes Protokoll).
2. Zusätzlich werden die raw/-Ziellinien geprüft, auf die sources-resource-Einträge von Concepts verweisen (Pfad-Ziellinie: §3 Punkt 3/4; Existenzprüfung: §6.1).
3. Nicht validiert werden als Bundle:
   • raw/, schema/, adapters/ (außerhalb des Bundles, keine Concept-Dateien; Vertrag §1),
   • der Inhalt von Dateien unter raw/, schema/ oder adapters/ — kein fachlicher oder struktureller Check auf diese Dateien als Bundle-Elemente (nur die raw/-Ziellinien-Existenz aus Punkt 2).
   • Nicht-.md-Dateien unter wiki/ (z. B. wiki/<area>/logo.png) — sie sind keine Bundle-Elemente und werden ignoriert, weder abgelehnt noch validiert (EC-11). Deterministische Abgrenzung: Prüfumfang ist jede Datei unter wiki/, deren Dateiendung exakt .md ist (case-sensitive kleingeschrieben).

2. Klassifikation der .md-Dateien unter wiki/

Bevor die Prüfschritte laufen, wird jede erfasste .md-Datei deterministisch klassifiziert:

Rolle	Bedingung	Frontmatter-Status
Bundleroot	wiki/index.md	ausschließlich type: bundle + okf_version: "0.2"
Area-index.md	eine index.md tiefer als wiki/ (in einem Area-Verzeichnis)	kein Frontmatter
log.md	wiki/log.md (reservierter Root-Name)	kein Frontmatter
Concept	jede übrige .md-Datei unter wiki/ (nicht index.md, nicht log.md)	muss type enthalten (§3/§6.1)

Reservierte Namen: ausschließlich index.md und log.md (Vertrag §2, §5, §6). Jede andere .md-Datei im Bundle ist ein Concept und unterliegt dem Concept-Prädikat; eine solche Datei ohne Frontmatter bzw. ohne type ist nicht „kein Concept", sondern strukturell invalide (Vertrag §3.1, §7 Punkt 2).

3. Die 14 strukturellen Invaliditäts-Punkte (Vertrag §7) als mechanische Prüfschritte

Die folgende Liste bildet die abschließende 14-Punkte-Invaliditätsliste des Vertrags (§7) 1:1 ab. Sie fügt keinen Eintrag hinzu und streicht keinen Eintrag. Jeder Punkt nennt das betroffene Artefakt, den konkreten YAML-/Text-Check und die deterministisch identifizierbare Fehlerursache (NFR-4). Ein Punkt ist verletzt, sobald die angegebene Bedingung auf mindestens eine erfasste Datei zutrifft → Verdikt FAIL (§5).

Wert-Semantik des YAML-Checks: Frontmatter ist als YAML zu parsen. Wiederholte Frontmatter-Keys (YAML-Duplikat-Keys) sind beim Parsen zu zählen (Punkt 13); die YAML-Spezifikation lässt sie mehrdeutig zu, der Vertrag erklärt sie zu struktureller Invalidität. Nicht als YAML parsbares Frontmatter ist ein FAIL — dieser Fall ist bereits über die Prüfschritt-Spalte von Punkt 2 abgedeckt („nicht als YAML parsbar"), ein separater Check ist nicht nötig.

#	Invaliditäts-Punkt (§7)	Artefakt	Mechanischer Check	Fehlerursache im Verdikt
1	Concept ohne type oder mit leerem type	Concept-Frontmatter	Ist type nicht vorhanden ODER kein non-empty String (leerer String, nur Whitespace, oder type: null / Zahl / Datumsobjekt)?	`Punkt 1: concept ohne type oder leerer type (NULL
2	nicht-reservierte .md-Datei im Bundle ohne Frontmatter bzw. ohne type	jede nicht-index.md/nicht-log.md .md-Datei unter wiki/	Fehlt der Frontmatter-Block --- ODER ist das Frontmatter nicht als YAML parsbar ODER fehlt type (bzw. ist leer)?	Punkt 2: nicht-reservierte .md-Datei ohne Frontmatter/ohne type
3	sources-resource löst auf einen wiki/-Concept-Pfad auf	Concept-Frontmatter, je sources[].resource	Löst der (bereinigte, §6.2) Pfad relativ zur Workspace-Root auf einen Pfad auf, der innerhalb wiki/ liegt?	Punkt 3: resource loest auf wiki/-Concept-Pfad (Pfad=<resource>)
4	sources-resource landet bei Auflösung außerhalb raw/ (inkl. ..-Traversal) oder ist URL-Form; zudem Verstöße der Pfad-Grammatik	Concept-Frontmatter, je sources[].resource	Enthält der resource-Wert ..-Path-Segment, führenden /, file://-Präfix, Backslash/Windows-Trenner, oder einen absoluten/URL-Form-Wert (http://, https://, etc.) ODER liegt der aufgelöste Pfad außerhalb raw/?	`Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal
5	verbotener status-Wert	Concept-Frontmatter	Ist status gesetzt und nicht ∈ {draft, stable, deprecated}?	Punkt 5: verbotener status-Wert (Wert=<status>)
6	nicht autorisiertes Frontmatter-Feld oder unautorisierter Key in sources/generated/verified-Eintrag	Concept- & Bundleroot-Frontmatter	Enthält das Frontmatter ein Feld außerhalb des erlaubten Subsets (Concept: type/sources/generated/verified/status/stale_after; Bundleroot: type+okf_version)? ODER enthält ein sources-Eintrag Keys außerhalb {resource,id,title,author,usage_count,last_modified}; ein generated Keys außerhalb {by,at}; ein verified-Eintrag Keys außerhalb {by,at}? Exemption: okf_version und type: bundle sind von der Punkt-6-Subset-Prüfung ausgenommen und werden ausschließlich über Punkt 8/9 geprüft (Entscheidungsnotiz unter dieser Tabelle).	Punkt 6: nicht autorisiertes Feld (Key=<key>) bzw. unautorisierter Key in sources/generated/verified
7	leere/fehlende by-Angabe in generated oder verified	Concept-Frontmatter	Ist generated.by nicht gesetzt ODER leer ODER reiner Whitespace? Gleiches je verified[].by?	Punkt 7: leere/fehlende by-Angabe in generated/verified
8	Bundleroot wiki/index.md ohne type: bundle/okf_version: "0.2" oder abweichender okf_version-Wert	Bundleroot wiki/index.md	Fehlt type: bundle (exakt dieser Wert) ODER fehlt okf_version: "0.2" (nur der Stringliteral 0.2 zulässig, z. B. NIE 0.3)?	Punkt 8: Bundleroot ohne type: bundle/okf_version \"0.2\" oder falscher okf_version-Wert
9	okf_version: "0.2" oder type: bundle außerhalb der Bundleroot	jede .md-Datei außer wiki/index.md im Bundle (Area-index.md, log.md, Concepts)	Kommt okf_version: "0.2" (§2-Wert) oder type: bundle irgendwo im Dateiinhalt einer dieser Dateien vor (nicht nur im Frontmatter)? Maßgeblich ist der Vertragswortlaut „darf … in irgendeiner anderen Bundle-Datei vorkommen" (§2/§7 Punkt 9). — Entscheidungsnotiz zu Punkt 6/9 siehe unter dieser Tabelle.	Punkt 9: okf_version/type: bundle ausserhalb der Bundleroot (Datei=<pfad>)
10	Frontmatter in einer Area-index.md oder log.md	Area-index.md, wiki/log.md	Beginnt die Datei (nach dem Strippen eines eventuellen UTF-8-BOM U+FEFF am Dateianfang sowie etwaiger führender Leerzeilen) mit einem YAML-Frontmatter-Block ---? Ein BOM bzw. führende Leerzeilen vor dem Frontmatter ändern den Status nicht — der Check läuft auf dem gestrippten Anfang (sonst würde ein Frontmatter der Erkennung entkommen).	Punkt 10: Frontmatter in Area-index.md/log.md (Datei=<pfad>)
11	Verletzung der Index-Regel	wiki/-Struktur	Hat ein Area-Verzeichnis (jedes Verzeichnis unter wiki/ mit Inhalt) keine index.md? ODER ist ein Concept nicht in der index.md seines nächsten Vorfahren verlinkt — ein Concept ist verlinkt, wenn seine Identität (relativer OKF-Dateipfad ohne .md) in der index.md des nächsten Vorfahren (Area-index.md; für Root-Concepts die Bundleroot wiki/index.md) als relativer Bundle-Pfad referenziert ist, mit oder ohne .md-Endung (eine genau-eine-Form-Festlegung ist Story 2.3 und wird hier nicht vorgegeben). „Neues Concept" ist deterministisch: jede im Bundle vorhandene Concept-Datei, deren Identität in ihrer zuständigen index.md fehlt — der Validator prüft den Zustand, nicht ein Git-Diff.	`Punkt 11: Index-Regel verletzt (Area ohne index.md=
12	sources/verified in nicht erlaubter Form; generated in Listen- statt Map-Form; sources-Eintrag ohne Pflichtangabe resource	Concept-Frontmatter	Ist sources gesetzt und nicht YAML-Liste? Ist ein sources-Eintrag keine Map (z. B. Skalar)? Ist ein sources-Eintrag eine Map ohne resource oder mit leerem resource (Vertrag §3.3: resource ist die einzige Pflichtangabe je Eintrag)? Ist verified gesetzt und weder Liste noch eine einzelne Map? Ist ein verified-Eintrag keine Map? Ist generated gesetzt und nicht eine Map (insbesondere Liste)?	Punkt 12: sources/verified/generated in nicht erlaubter Form
13	doppelter Frontmatter-Key	jede Datei mit Frontmatter (Concept, Bundleroot)	Kommt derselbe Key auf oberster Frontmatter-Ebene mehrfach vor (z. B. doppeltes type, doppeltes okf_version, doppeltes sources)?	Punkt 13: doppelter Frontmatter-Key (Key=<key>)
14	fehlerhafte Wert-Formate	Concept-Frontmatter	stale_after/last_modified ≠ YYYY-MM-DD (exakt 10 Zeichen, korrekte Struktur + reale Kalenderdaten, §6.3)? at (in generated/verified) ≠ ISO-8601-Datetime (Normalform, §4.3; Kalender-Validität §6.3)? usage_count kein YAML-Integer (Ganzzahl-Typ, nicht Zahl allgemein — usage_count: 3.0 als Float ist ein FAIL) und keine Ganzzahl ≥ 0? type kein nicht-leerer String (siehe auch Punkt 1)?	Punkt 14: fehlerhaftes Wert-Format (Feld=<feld>, Wert=<wert>)

3.1 Erweiterungs-/Abschluss-Regel

Diese 14 Punkte sind abschließend (Vertrag §7 „abschließende Liste"). Die Instruktion führt keine eigene Invaliditätsklasse ein. Nicht in der Liste genannte Auffälligkeiten sind entweder (a) zulässig und semantisch gleichbedeutend mit Absenz (fehlende optionale Felder, leere Listen, §4.1), (b) Warnungen ohne Invalidität (stale_after-Veraltung, §6.4; Existenzprüfung als separat protokollierte fachliche Prüfung, §6.1) oder (c) keine Bundle-Elemente (nicht-.md-Dateien, §1). Jede beabsichtigte Erweiterung der Invaliditätsdefinition erfordert die Autorisierung bzw. das Story-Verfahren — sie darf von keinem Producer oder Validator stillschweigend vorgenommen werden.

Entscheidungsnotiz zu Punkt 6/9: okf_version und type: bundle sind als Bundle-Root-Felder (§2) von der Punkt-6-Subset-Prüfung ausgenommen; ihr Vorkommen wird ausschließlich über Punkt 8 (Bundleroot-Bedingungen) und Punkt 9 (Verbot außerhalb der Bundleroot) geprüft. Damit feuert niemals Punkt 6 vor Punkt 9 — das Punkt-9-Fixture bleibt deterministisch (kein Vorab-FAIL durch die Subset-Prüfung).

3.2 Bundleroot- und Reserviert-Namen-Voraussetzungen (Vertrag §2/§5)

Diese Voraussetzungen sind strukturelle Norm-Pflichten, die der Validator vor den 14 Einzel-Punkten prüft. Sie sind ausdrücklich keine neue §7-Invaliditätsklasse: Sie bedingen die Anwendbarkeit der 14 Punkte (Fehlen der Bundleroot macht Punkt 8 gegenstandslos; ein log.md an falscher Position ist eine Reserviert-Namen-Verletzung nach §5) und sind als Voraussetzungsprüfungen dokumentiert.

• Existiert wiki/index.md nicht, ist der Run strukturell FAIL (Vorausbedingung zu Punkt 8): FAIL (Struktur) Bundleroot fehlt: wiki/index.md existiert nicht (Vertrag §2, Vorausbedingung zu Punkt 8).
• Existiert eine Datei log.md an einer anderen Stelle als der Bundleroot (z. B. wiki/<area>/log.md), ist sie strukturell invalide (reservierter Name, nur Bundleroot; Vertrag §5): FAIL <pfad> log.md an unzulässiger Position (reservierter Name, nur Bundleroot, Vertrag §5).
• Diese Voraussetzungsprüfungen laufen in der Ausführungsreihenfolge bei Schritt (3) — nach der Klassifikation (§2), vor den 14 Punkten je Datei (§3, Schritt (4); vgl. §4.4).

4. Normalisierung & Toleranz (deterministische Festlegungen)

Diese Abschnitte legen die von Deferred-Work an Story 1.4 verwiesenen Entscheidungen fest. Sie wirken vor den 14 Prüfschritten und sind Teil der deterministischen Ausführung (kein Interpretationsspielraum).

4.1 Listen- vs. Absenz-Normalisierung (F2)

• sources: [] und verified: [] sind zulässig und semantisch gleichbedeutend mit Absenz (Vertrag §3.2, §3.3, §3.5). Sie sind niemals invalide.
• Fehlende optionale Felder (sources/generated/verified/status/stale_after nicht vorhanden) sind niemals invalide (A0-2/AD-1b).
• Für die Ausgabe-/Diff-Basis gilt eine feste Reihenfolge (deterministische Normalform): Frontmatter-Keys werden in der Reihenfolge type, sources, generated, verified, status, stale_after betrachtet; innerhalb von sources/verified-Listen bleibt die dokumentierte Reihenfolge erhalten.

4.2 verified-Singleton-Coercing (Vertrag §3.5)

• Eine einzelne Map verified: { by: ..., at: ... } MUSS als 1-Element-Liste gelesen werden und wird nicht abgelehnt (Vertrag §3.5). Prüfschritt 12 berücksichtigt diese Toleranz: Die Map-Form eines einzelnen verified-Eintrags ist gültig.
• generated kennt diese Toleranz nicht: generated ist, falls gesetzt, ausschließlich als Map zulässig; eine Liste ist strukturell invalide (Punkt 12; Vertrag §3.4).

4.3 ISO-8601-Normalform für at (BH-14, Vertrag §3.4/§3.5)

Für at (in generated/verified) gilt die folgende ISO-8601-Normalform (deterministisch, ohne LLM-Urteil):

• Akzeptiert: YYYY-MM-DDTHH:MM:SS mit einer der Offset-Formen Z (UTC), ±HHMM (4-stellig ohne Doppelpunkt) oder ±HH:MM (mit Doppelpunkt). Beide Offset-Formen sind gültige ISO-8601-Darstellungen (RFC 3339) und werden akzeptiert (Vertrag §7 Punkt 14 fordert nur „ISO-8601-Datetime" — eine Ablehnung von ±HH:MM wäre eine unautorisierte Verschärfung). Für die Normalisierung gilt: Das Suffix wird normiert; die intern einheitliche Repräsentation ist die UTC-Form.
• Eine reine Datumsangabe YYYY-MM-DD wird als T00:00:00Z normalisiert (interne Repräsentation für Vergleich und Output) — das ist keine Abweichung vom Format, sondern die festgelegte Normalform.
• FAIL nach Punkt 14 sind ausschließlich Formen, die kein ISO-8601-Datetime sind (fehlende Trennzeichen, keine Zeit nach T, HH:MM ohne Sekunden, ungültiger Monat/Tag/Stunde/Minute/Sekunde, ungültiger Offset).
• Die Kalender-Validität von Datumsteilen folgt §6.3 (EC-3).

4.4 Rangfolge der Prüfschritte (deterministische Ausführungs-Reihenfolge)

Der Run folgt einer festen Ausführungs-Reihenfolge (vgl. §0 Aufruf):

1. Klassifikation — alle erfassten .md-Dateien werden gemäß §2 klassifiziert (Bundleroot / Area-index.md / log.md / Concept).
2. Voraussetzungsprüfungen — die Bundleroot- und Reserviert-Namen-Voraussetzungen aus §3.2 werden geprüft (fehlende Bundleroot, log.md an unzulässiger Position).
3. Je Datei die 14 Punkte in Reihenfolge (§3): Die Datei wird Punkt für Punkt geprüft. Sobald ein Punkt FAIL erzeugt, wird der FAIL für diese Datei einmal protokolliert (erste verletzte Bedingung in Punkt-Reihenfolge) und die übrigen Punkte werden für diese Datei nicht mehr ausgewertet (deterministische Abbruch-Regel — vermeidet mehrdeutige Mehrfach-Verdikte). Es wird stets die erste verletzte Bedingung als textuelle Fehlerursache im Verdikt genannt (NFR-4).
4. Nach PASS der 14 Punkte die §6-Prüfungen je Datei: EC-1-Existenz je resource, EC-3-Kalender-Validität der Datumsfelder, EC-4/6.4-stale_after-WARN.

Mehrere fehlende resource-Existenz-Fehler einer Datei (EC-1) werden zu einer FAIL-Zeile aggregiert — alle fehlenden Pfade in der im Frontmatter dokumentierten Reihenfolge (Beispiel: FAIL wiki/x.md Fachliche Prüfung EC-1: resource existiert nicht (Pfad=raw/a.md, raw/b.md)). Aggregation gilt nur innerhalb einer Datei: jede betroffene Datei erhält ihre eigene FAIL-Zeile.

Das Gesamtergebnis des Runs ist FAIL, sobald irgendeine Datei FAIL ist (§5).

4.5 log.md-Feingranularität (F17)

• Ein leeres wiki/log.md ist gültig (kein Frontmatter, keine Einträge) — keine Invalidität.
• log.md trägt kein Frontmatter (Punkt 10; Vertrag §5).
• log.md-Inhalt (Eintragsklassifikation, datumsgruppierte Liste) wird in v1 nicht validiert: §5 legt Format und Beispiel fest, aber keine strukturell prüfbare Eintrags-Grammatik; eine spätere Story (AD-16/Epic 4) kann eine Eintrags-Validierung ergänzen. Es ist keine neue Invaliditätsklasse („nicht in der Liste" gilt als nicht verletzt, §3.1).

5. Verdikt-Format (maschinenlesbar)

Pro geprüfte Datei wird genau ein Verdikt-Verb ausgegeben, gefolgt von Datei-Pfad und textueller Begründung. Das Format ist maschinenlesbar (deterministische Grammatik) und zugleich für Menschen lesbar (NFR-4). Ein Verdikt-Verb ist ausschließlich SUCCESS oder FAIL; WARN (§6.4) ist kein Verdikt-Verb, sondern ein ergänzender Berichtskanal und ersetzt das Verdikt nicht — eine Datei kann „SUCCESS + WARN" tragen.

SUCCESS <relative-pfad> <optionale Begründung>
FAIL     <relative-pfad> <Fehlerursache: Punkt-Nr. + Determinismus-Beschreibung>

• <relative-pfad>: Pfad relativ zur Workspace-Root (z. B. wiki/index.md, wiki/<area>/<concept>.md), /-getrennt.
• SUCCESS: alle zutreffenden Prüfschritte bestanden; keine Begründung erforderlich (kann aber eine Normalform-Notiz zu §4 enthalten, z. B. verified-Singleton-Coercing).
• FAIL: genau die textuelle Fehlerursache gemäß §3-Tabelle (Punkt-Nummer + deterministischer Grund + relevanter Wert/Pfad) oder — für fachliche Prüf-FAILs (§6; insbesondere EC-1-Existenz) — die Bezeichnung Fachliche Prüfung EC-1 statt einer Punkt-Nummer (§4.4). Fachliche Prüf-FAILs tragen keine §7-Punkt-Nummer, weil sie keine der 14 §7-Punkte sind (§6.1). Die Ursache ist darüber hinaus Ausdruck der abgeschlossenen Normalisierung (§4).
• Run-Ergebnis: Das Gesamtergebnis ist FAIL, sobald mindestens eine Datei FAIL ist; dann gilt der Run als gescheitert, es werden keine Mutationen durchgeführt und raw/ bleibt unangetastet (AD-3). Sind alle Dateien SUCCESS (inkl. keiner Existenz-Prüf-FAILs, §6.1), ist das Gesamtergebnis SUCCESS.
• Nicht-.md-Dateien unter wiki/ erzeugen kein Verdikt (sie werden nicht geprüft, §1).

5.1 Selbstbegrenzung

• Die Instruktion validiert ausschließlich Bundle-Elemente gemäß §1; die Inhalte von raw/, schema/ und adapters/ werden nicht als Bundle validiert.
• Es werden keine neuen Invaliditätsklassen eingeführt (abschließende 14-Punkte-Liste, §3.1).
• Es wird nichts geschrieben: der Validator mutiert weder Bundle noch raw/ noch sonstige Dateien; er protokolliert sein Ausführungs-Protokoll nur als Bericht (kein Schreibzugriff auf Dateien außerhalb des Berichtskanals).

6. Fachliche Zusatzprüfungen (Deferred-Work, separat protokolliert)

Die folgenden Prüfungen sind fachliche Prüfungen (keine §7-Invaliditäts-Punkte). Sie werden deterministisch ausgeführt und separat protokolliert — ein FAIL hier ist trotzdem ein Run-FAIL (das Bundle darf nicht mit fehlender Evidenz oder Phantom-Daten laufen), wird aber nicht als „Punkt 1–14"-Verstoß gezählt (§3.1; Vertrag §8 „Existenz-Prüfung als Validator-Verhalten der Story 1.4").

6.1 Existenzprüfung der raw/-Resource (EC-1)

• Für jeden sources-resource-Eintrag eines Concepts: Der gemäß §6.2 bereinigte und relativ zur Workspace-Root aufgelöste Pfad MUSS zum Validierungszeitpunkt als Datei existieren — ausdrücklich als Datei, nicht als Verzeichnis. Existiert er nicht oder löst er auf ein existierendes Verzeichnis auf, ist das Bundle fachlich invalide → Run-FAIL (ein Verzeichnis ist kein gültiger Evidenzpfad).
• Verdikt ohne Punkt-Nummer: FAIL <concept-pfad> Fachliche Prüfung EC-1: resource existiert nicht (Pfad=<resource>).
• Mehrere fehlende Resources einer Datei werden zu einer FAIL-Zeile aggregiert (alle fehlenden Pfade in der dokumentierten Reihenfolge; §4.4, Schritt 4).
• Diese Prüfung ist eine fachliche Invalidität: Sie ist keine der 14 §7-Punkte und lässt die abschließende Liste unberührt (der Punkt wird separat protokolliert, nicht als Punkt 1–14 gezählt).

6.2 Pfad-Auflösung & -Bereinigung

resource ist ein /-getrennter relativer Workspace-Pfad zur Workspace-Root (oberste Ebene des Git-Arbeitsverzeichnisses). Deterministische Bereinigung/Auflösung — Vorrangsregel: Die Punkt-4-Grammatikprüfung (Rejektion von .., führendem /, Backslash, file://, URL) läuft vor der Punkt-3-Auflösungsprüfung. Ein resource mit .., dessen bereinigtes Ziel zufällig in wiki/ läge, wird daher als Punkt 4 (Grammatik) abgelehnt, nicht als Punkt 3 — die Punktnummer ist je Input deterministisch (AD-13):

1. Der Wert wird als relativer Pfad interpretiert. Führendes / ist unzulässig (Punkt 4).
2. Der Pfad wird als /-Segmentfolge behandelt. Ein Segment .. ist unzulässig (Punkt 4) — unabhängig vom Auflösungsziel. Segment . wird normalisiert (entfernt).
3. Backslash \ und Windows-Trenner sind unzulässig (Punkt 4).
4. Ein file://-Präfix oder eine URL-Form (http://, https://, andere Scheme-Prefixe) sind unzulässig (Punkt 4).
5. Der bereinigte Pfad muss auf einen Pfad innerhalb raw/ auflösen (Präfix raw/ in der aufgelösten Form). Andernfalls Punkt 4.
6. Der aufgelöste Pfad darf nicht auf einen Pfad innerhalb wiki/ auflösen (Punkt 3).

6.3 Kalender-Validität der Datumsfelder (EC-3)

Für alle YYYY-MM-DD-Felder (stale_after, sources[].last_modified) gilt:

• Exakt 10 Zeichen, Struktur JJJJ-MM-TT, mit --Trennung.
• Die Kalenderdaten müssen real existieren: gültige Monate 01–12, gültige Tage je Monat (Schaltjahrregel: Februar 29 nur in durch 4 teilbaren Jahren, außer Jahrhundertjahre, die nicht durch 400 teilbar sind). 2026-02-31 ist invalide (Punkt 14).
• Für Datumsteile in at (zeitliche ISO-8601-Form) gilt dieselbe Kalender-Validität (Monat/Tag/Stunde/Minute/Sekunde real existierend).

6.4 Veraltungs-Prüfung stale_after (BH-8/F18) — Warnung, keine Invalidität

• Ist stale_after gesetzt und gilt today >= stale_after (Vergleich in UTC), so wird eine Warnung ausgegeben: WARN <concept-pfad> stale_after überschritten (Datum=<stale_after>, today=<today-UTC>). WARN ist ein ergänzender Berichtskanal, kein Verdikt-Verb (§5): Das Verdikt der Datei bleibt SUCCESS/FAIL unverändert.
• Ein veraltetes Concept ist kein struktureller Fehler und kein Run-FAIL (F18/BH-8; Vertrag §7 zählt die Veraltung nicht auf). Lebenszyklus-Konsequenzen der Veraltung (Nutzungssperre als sources-Ziel o. ä.) sind eine spätere Story (BH-8 → Epic 3) und werden hier nicht validiert.
• stale_after ohne Datumsproblem (nur Veraltung) lässt das Verdikt der Datei unverändert (SUCCESS bleibt SUCCESS; nur Warnung).

6.5 non-md-Konvention (EC-11)

Nicht-.md-Dateien unter wiki/ (z. B. wiki/<area>/logo.png) werden ignoriert — kein Verdikt, keine Ablehnung, keine Konvention-Erfindung über den Vertrag hinaus (§1 Punkt 3, §3.1c).

7. Referenz-Fixtures (Negativ-/Positiv-Beispiele)

Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte und machen jede mechanische Bedingung reproduzierbar nachprüfbar (AD-17h). „⇒" gibt das erwartete Verdikt an; die Fehlerursache ist exakt die aus §3.

7.1 Negativ-Fixtures — je Punkt genau ein FAIL-Beispiel (Input → erwartetes Verdikt)

Isolations-Notiz: Jede Negativ-Fixture wird gegen ein sonst-valides, isoliertes Sample geprüft (nur die eine Datei/Struktur, alle übrigen Punkte passieren). So ist gewährleistet, dass jede Fixture genau ihren Punkt auslöst und kein Vorab-FAIL durch andere Punkte entsteht (kein Nachbarschafts-Effekt).

#	Fixture (Input)	Erwartetes Verdikt (FAIL mit Ursache)
1	Concept x.md mit type: (leer)	`FAIL wiki/x.md Punkt 1: concept ohne type oder leerer type (NULL
2	.md unter wiki/ ohne ----Frontmatter	FAIL wiki/x.md Punkt 2: nicht-reservierte .md-Datei ohne Frontmatter/ohne type
3	sources: [{resource: wiki/foo.md}]	FAIL wiki/x.md Punkt 3: resource loest auf wiki/-Concept-Pfad (Pfad=wiki/foo.md)
4	sources: [{resource: ../outside.md}]	FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal|absolut|URL|Backslash|file://)
5	status: published	FAIL wiki/x.md Punkt 5: verbotener status-Wert (Wert=published)
6	Concept mit foo: bar (nicht autorisiert)	FAIL wiki/x.md Punkt 6: nicht autorisiertes Feld (Key=foo)
7	generated: {at: 2026-08-15T10:00:00Z} (ohne by)	FAIL wiki/x.md Punkt 7: leere/fehlende by-Angabe in generated/verified
8	wiki/index.md ohne okf_version	FAIL wiki/index.md Punkt 8: Bundleroot ohne type: bundle/okf_version \"0.2\" oder falscher okf_version-Wert
8a	wiki/index.md existiert nicht (Bundle ohne Bundleroot)	FAIL (Struktur) Bundleroot fehlt: wiki/index.md existiert nicht (Vertrag §2, Vorausbedingung zu Punkt 8)
9	Concept mit okf_version: "0.2"	FAIL wiki/x.md Punkt 9: okf_version/type: bundle ausserhalb der Bundleroot (Datei=wiki/x.md)
10	wiki/log.md beginnt mit ---	FAIL wiki/log.md Punkt 10: Frontmatter in Area-index.md/log.md (Datei=wiki/log.md)
10a	wiki/<area>/log.md existiert (reservierter Name außerhalb der Bundleroot)	FAIL wiki/<area>/log.md log.md an unzulässiger Position (reservierter Name, nur Bundleroot, Vertrag §5)
11	Area wiki/foo/ ohne index.md	FAIL (Struktur) Punkt 11: Index-Regel verletzt (Area ohne index.md=foo)
12	sources: {resource: raw/x.md} (Map statt Liste)	FAIL wiki/x.md Punkt 12: sources/verified/generated in nicht erlaubter Form
12a	sources: [{title: \"Ohne resource\"}] (Eintrag ohne Pflichtangabe resource)	FAIL wiki/x.md Punkt 12: sources/verified/generated in nicht erlaubter Form
13	Frontmatter mit zweimal type:	FAIL wiki/x.md Punkt 13: doppelter Frontmatter-Key (Key=type)
14	stale_after: 2026-02-31	FAIL wiki/x.md Punkt 14: fehlerhaftes Wert-Format (Feld=stale_after, Wert=2026-02-31)
14a	usage_count: 3.0 (Float statt Ganzzahl)	FAIL wiki/x.md Punkt 14: fehlerhaftes Wert-Format (Feld=usage_count, Wert=3.0)
14b	at: 2026-08-15T25:00:00Z (ungültige Stunde, kein ISO-8601-Datetime)	FAIL wiki/x.md Punkt 14: fehlerhaftes Wert-Format (Feld=at, Wert=2026-08-15T25:00:00Z)

7.2 Positiv-Fixtures — je Punkt das gültige Gegenstück (PASS / SUCCESS)

Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept mit ausschließlich type und ohne sources/generated/verified/status/stale_after (alle optionalen Felder fehlen) ist gültig → SUCCESS wiki/x.md. Fehlende optionale Felder sind keine Invalidität (A0-2/AD-1b).

#	Fixture (Input)	Erwartetes Verdikt
1	Concept x.md mit type: concept	SUCCESS wiki/x.md
2	Nicht-reservierte .md mit gültigem Frontmatter inkl. type	SUCCESS wiki/x.md
3	sources: [{resource: raw/prd/prd-wow20-2026-08-14.md}]	SUCCESS wiki/x.md
4	sources: [{resource: raw/prd/prd-wow20-2026-08-14.md}] (unter raw/)	SUCCESS wiki/x.md
5	status: stable	SUCCESS wiki/x.md
6	Concept mit ausschließlich type/sources/generated/verified/status/stale_after	SUCCESS wiki/x.md
7	generated: {by: wow-compiler/0.1.0, at: 2026-08-15T10:00:00Z}	SUCCESS wiki/x.md
8	wiki/index.md mit type: bundle + okf_version: "0.2"	SUCCESS wiki/index.md
8a	Bundleroot wiki/index.md ist vorhanden	SUCCESS (Voraussetzung §3.2 nicht verletzt)
9	Kein okf_version/type: bundle außerhalb wiki/index.md	SUCCESS (kein Punkt 9)
10	wiki/log.md und Area-index.md ohne Frontmatter	SUCCESS wiki/log.md / SUCCESS wiki/<area>/index.md
10a	Kein log.md außerhalb der Bundleroot (kein wiki/<area>/log.md)	SUCCESS (Voraussetzung §3.2 nicht verletzt)
11	Area wiki/foo/ mit index.md, das neue Concept verlinkt	SUCCESS (Punkt 11 nicht verletzt)
12	sources Liste von Maps, je Eintrag mit resource; verified: {by: human:x, at: ...} (Singleton-Map)	SUCCESS wiki/x.md (Singleton-Coercing, §4.2)
12a	sources: [{resource: raw/x.md, title: t}] (Eintrag mit Pflichtangabe resource)	SUCCESS wiki/x.md
13	Frontmatter ohne doppelte Keys	SUCCESS wiki/x.md
14	stale_after: 2026-12-31; last_modified: 2026-08-14; at: 2026-08-15T10:00:00Z; usage_count: 3	SUCCESS wiki/x.md
14b	at: 2026-08-15T10:00:00+02:00 (Offset mit Doppelpunkt, gültiges ISO-8601/RFC 3339)	SUCCESS wiki/x.md (Normalform §4.3)
14c	at: 2027-01-01 (reiner Datumswert)	SUCCESS wiki/x.md (normalisiert zu T00:00:00Z, §4.3)
14d	usage_count: 3 (YAML-Integer)	SUCCESS wiki/x.md

8. Normreferenzen & Revisionslog

Normreferenzen (ableitungsseitig, read-only):

• schema/wiki-compiler.md — autorisierter Vertrag (Story 1.3): §1 Geltungsbereich, §2 Bundleroot, §3.1–§3.7 Feldsubset & sources-Auflösung, §5 log.md-Typ, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste (inkl. Kalender-Validität & UTC-Vergleich), §8 Normreferenzen.
• PRD §13 — OKF-0.2 als normativer Format-Standard (FR-9, NFR-6); OKF-Spezifikation (Google Cloud, knowledge-catalog).
• AD-1b/F-2/A0-2 — strukturelle Invalidität schlägt den Run fehl; fehlende optionale Felder nicht invalide.
• AD-13/AD-17h/Q-6 — deterministische, ohne LLM-Urteil aufrufbare Agent-Instruktions-Validierung, mechanisch zu bestätigen.
• AD-3 — raw/ immutable; fehlgeschlagener Run lässt raw/ unangetastet (auch: keine Mutationen bei FAIL).
• AD-4b/A0-4 — Provenienz-Ziellinie: sources nie auf wiki/-Pfade.
• D-3 — kein Standalone-Programm als Validator; die Regel bleibt eine Instruktion.
• Deferred-Work _bmad-output/implementation-artifacts/deferred-work.md — EC-1, EC-3, BH-14, F2-Listen, BH-8, EC-11, F17-log.md, F18-stale_after (8 an Story 1.4 verwiesene Entscheidungen, in §4/§6 deterministisch festgelegt).
• F15 (Trust-Semantik von generated.by): generated.by: human:<id> ist formgültig — das Datenmodell erlaubt jeden non-empty by (Vertrag §3.4) —, begründet aber keine human-review-Klassifikation (die entsteht nur über verified mit human:-Präfix, §3.5). Die Trust-Semantik von generated.by mit human:-Präfix wird in Epic 4 geklärt (Deferred-Work F15).
• Story 2.3 (Link-Form): Der Punkt-11-Check akzeptiert die Concept-Identität in der zuständigen index.md mit oder ohne .md-Endung (§3 Punkt 11). Eine genau-eine-Form-Festlegung der Link-Schreibweise ist Story 2.3 und wird hier bewusst nicht vorweggenommen.

Revisionslog:

• Revision 1 (2026-08-15): Erstes abgeleitetes Artefakt — die 14 §7-Punkte als mechanische Prüfschritte (§3), Normalisierungs-/Toleranz-Regeln (§4), maschinenlesbares Verdikt-Format & Selbstbegrenzung (§5), fachliche Zusatzprüfungen (§6), Referenz-Fixtures (§7).
• Revision 2 (2026-08-15): Review-Patches — §3.2 Voraussetzungsprüfungen (Bundleroot/log.md-Position) als Nicht-§7-Pflichten; Punkt 6/9-Exemption-Notiz (kein Punkt-6-vor-9-Feuer); Punkt 9 auf Dateiinhalt ausgeweitet; Punkt 10 BOM-/Leerzeilen-Stripping; Punkt 11 deterministische Link-Prüfung ohne Story-2.3-Vorwegnahme; Punkt 12 fehlende/leere resource; Punkt 14 usage_count-YAML-Integer-Typ + korrekter at-Verweis (§4.3); §4.3 akzeptiert ±HH:MM (keine unautorisierte Verschärfung); §4.4-Ausführungs-Reihenfolge mit §3.2/§6-Phasen und EC-1-Aggregation; §5-WARN als Berichtskanal statt Verdikt-Verb; §6.1 „als Datei, nicht Verzeichnis" + Aggregation; §6.2 Punkt-4-vor-3-Priorität; Fixtures ergänzt/aktualisiert (§7); Normreferenzen F15/Story 2.3.