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: 8 (Revisionslog in §8) Ableitungsdatum: 2026-08-15 Letzte Re-Konsistenz: 2026-08-16 (Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisiert; Option-A-Heilung Story 2.1)

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).
   • Offener Punkt (Defer, Retro F-08): Die Konvention für Großschreibung (.MD) unter wiki/ ist unbestimmt (Windows-Portabilität, NFR-1/NFR-5). Auf win32 kann ein Tool foo.MD erzeugen — würde es als Concept gewertet, fehlte ihm type. Vor Epic-2-Concepts entscheiden. Bis dahin gilt die obige case-sensitive Abgrenzung.

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.

Gemeinsame Frontmatter-Erkennung (stripped, Retr. F-05/AI-5): Alle Checks, die einen Frontmatter-Block --- am Dateianfang erkennen (Punkte 2, 8, 10), laufen auf dem gestrippten Dateianfang: ein eventueller UTF-8-BOM (U+FEFF) am Dateianfang sowie etwaige führende Leerzeilen (nur Whitespace-Zeilen) werden vor der Erkennung entfernt. Ein BOM oder führende Leerzeilen vor dem Frontmatter ändern den Status nicht (sonst würde ein Frontmatter der Erkennung entkommen und ein falsches Punkt-2/Punkt-8-FAIL entstehen). Das Stripping dient ausschließlich der Frontmatter-Erkennung — es entfernt keinen Inhalt und ändert nichts an YAML-Werten.

#	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 --- (Erkennung auf dem gestrippten Dateianfang, §3-Präambel) 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). Innen-Ebenen: siehe §7.3-Isolations-Notiz (autorisiert, Revision 8).	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 der Frontmatter-Block --- (Erkennung auf dem gestrippten Dateianfang, §3-Präambel) ODER 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 — auf dem gestrippten Dateianfang (BOM U+FEFF + führende Leerzeilen, gemeinsame Definition §3-Präambel) — mit einem YAML-Frontmatter-Block ---? Ein BOM bzw. führende Leerzeilen vor dem Frontmatter ändern den Status nicht (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 neue §7-Invaliditätsklasse ein; die fachlichen Voraussetzungs- (§3.2, V-1/V-2) und Zusatzprüfungen (§6, EC-*) sind separat geführte, ebenfalls deterministische Prüfklassen und verlassen die Abschluss-Eigenschaft des §7-Katalogs nicht. 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 (V-1/V-2; Vertrag §2/§5)

Diese Voraussetzungen sind strukturelle Norm-Pflichten, die der Validator vor den 14 Einzel-Punkten prüft. Sie werden als fachliche Voraussetzungs-Prüfungen V-1/V-2 geführt (Namensraum konsistent zu den §6-Fachprüfungen EC-/V-). 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. Ein FAIL hier ist — wie bei den §6-Fachprüfungen — ein Run-FAIL, trägt aber keine §7-Punkt-Nummer.

• V-1 (fehlende Bundleroot): Existiert wiki/index.md nicht, ist der Run strukturell FAIL (Vorausbedingung zu Punkt 8): FAIL (Voraussetzung) Bundleroot fehlt: wiki/index.md existiert nicht (V-1, Vertrag §2, Vorausbedingung zu Punkt 8).
• V-2 (reservierter Name außerhalb der Bundleroot): 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 (V-2, 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). Fixtures: §7.1 (8a, 10a) bzw. §7.3 (V-1/V-2).

Warum V-1/V-2 (Retrospective F-03, AI-3)?

Die Retrospective (F-03) bemängelte, dass §3.2 de-facto eigenständige FAIL-Klassen einführt, aber weder im §7-Fixture-Schema noch in der §5-Verdikt-Grammatik als solche erkennbar ist — sie trugen das Label FAIL (Struktur) … außerhalb der §5-Grammatik, während §3.1/§5.1 „abschließende Liste, keine eigene Invaliditätsklasse" behaupten. Das Label-Schema ist hiermit vereinheitlicht: Die Voraussetzungsprüfungen heißen V-1 (fehlende Bundleroot) und V-2 (log.md an falscher Position), tragen in der Verdikt-Zeile das Präfix FAIL (Voraussetzung) und sind in §7.3 als eigene Fixtures belegt. Damit ist §3.2 dokumentarisch als fachliche (nicht §7-)Prüfklasse geführt und mechanisch nachprüfbar.

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 (ohne Zeit- und Offset-Anteil) ist kein ISO-8601-Datetime und damit keine gültige at-Form — sie erzeugt FAIL nach Punkt 14 (Vertrag §3.4/§3.5: „at … MUSS ein ISO-8601-Datetime sein"; §7 Punkt 14: „at ungleich ISO-8601-Datetime"). Es gibt keine Normalform, die ein reines Datum in ein Datetime überführt — die Toleranz aus Revision 2 ist hiermit zurückgenommen.
• FAIL nach Punkt 14 sind ausschließlich Formen, die kein ISO-8601-Datetime sind (fehlende Trennzeichen, keine Zeit nach T, HH:MM ohne Sekunden, eine reine Datumsangabe YYYY-MM-DD ohne Zeit-/Offset-Anteil, 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 (V-1/V-2) — die Bundleroot- und Reserviert-Namen-Voraussetzungen aus §3.2 werden geprüft (V-1: fehlende Bundleroot; V-2: 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 (§3.2 V-1/V-2 und §6 EC-*) — das jeweilige Fachprüf-Präfix FAIL (Voraussetzung) (V-1/V-2) bzw. Fachliche Prüfung EC-1 o. ä. (§6) statt einer Punkt-Nummer (§4.4). Fachliche Prüf-FAILs tragen keine §7-Punkt-Nummer, weil sie keine der 14 §7-Punkte sind (§3.2, §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.
• Die abschließende 14-Punkte-Liste (§7) erhält durch die Instruktion keine neuen Einträge (§3.1). Die fachlichen Voraussetzungs-/Zusatzprüfungen (§3.2 V-1/V-2, §6 EC-1/EC-3/EC-11) sind keine §7-Punkte, sondern separat geführte fachliche Prüfklassen — ein FAIL dort ist ein Run-FAIL, ohne eine der 14 Punkte zu sein. Diese Abgrenzung ist dokumentarisch (V-1/V-2-Label, §7.3-Fixtures) und ändert nichts an der Abschluss-Eigenschaft des §7-Katalogs.
• 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). Fixtures: §7.3 (EC-1 Positiv/Negativ/Aggregation).
• 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). Fixtures: §7.3 (EC-3 Positiv/Negativ).

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. Fixtures: §7.3 (WARN-Muster).
• 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.
• Offener Punkt (Defer, Retro F-06): Die Ableitung von today für den Vergleich (§6.4/§3.7 „Tagesdatum today") ist noch nicht deterministisch hart (UTC-Kalendertag vs. lokaler Tag). Wird vor Epic 3 (Lifecycle-Konsequenz) entschieden; bis dahin gilt: today = Kalenderdatum des aktuellen UTC-Zeitpunkts.
• 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). Fixtures: §7.3 (EC-11).

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

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

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://)
4a	sources: [{resource: README.md}] (existiert an der Workspace-Root, ausserhalb raw/; Kein ../URL/Backslash — Punkt 4 durch aufgelöste Lage)	FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)
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 (Voraussetzung) Bundleroot fehlt: wiki/index.md existiert nicht (V-1, 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 (V-2, reservierter Name, nur Bundleroot, Vertrag §5)
11	Area wiki/foo/ ohne index.md	FAIL wiki/foo/ 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)
14c	at: 2027-01-01 (reine Datumsangabe ohne Zeit-/Offset-Anteil — kein ISO-8601-Datetime)	FAIL wiki/x.md Punkt 14: fehlerhaftes Wert-Format (Feld=at, Wert=2027-01-01)

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
2a	Concept x.md mit <BOM>⏎---⏎type: concept… (BOM + Leerzeile vor dem Frontmatter)	SUCCESS wiki/x.md (stripped Erkennung, §3-Präambel)
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
8b	wiki/index.md mit <BOM>⏎---⏎type: bundle⏎okf_version: "0.2"… (BOM + Leerzeile vor dem Frontmatter)	SUCCESS wiki/index.md (stripped Erkennung, §3-Präambel)
8a	Bundleroot wiki/index.md ist vorhanden	SUCCESS (Voraussetzung V-1 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 V-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: 2026-08-15T10:00:00+0200 (Offset 4-stellig ohne Doppelpunkt, gültiges ISO-8601/RFC 3339)	SUCCESS wiki/x.md (Normalform §4.3)
14d	usage_count: 3 (YAML-Integer)	SUCCESS wiki/x.md

7.3 §6-Fachliche-Zusatzprüfungen-Fixtures (EC-1, EC-3, WARN, EC-11)

Diese Prüfungen sind keine §7-Punkte (Fachliche Prüfungen, §6). Für Negativ-Fixtures gilt dasselbe Isolations-Prinzip wie in §7.1: jedes Sample ist sonst-valide (die 14 Punkte passieren), sodass genau die jeweilige §6-Prüfung auslöst. Das Isolations-Prinzip gilt entsprechend auch für Punkt-6-Fälle auf Innen-Ebenen (sources/generated/verified-Einträge): Ein unautorisierter Key innerhalb eines Eintrags (z. B. sources:\n - resource: …\n role: x) ist strukturell invalide und löst Punkt 6 aus (vertraglich §3.3–§3.5), losgelöst von der §6-Formprüfung.

#	Fixture (Input)	Erwartetes Verdikt
§6.1 EC-1 Positiv	Concept mit sources: [{resource: raw/prd/prd-wow20-2026-08-14.md}], Datei existiert	SUCCESS wiki/x.md
§6.1 EC-1 Negativ	sources: [{resource: raw/fehlt.md}], Datei existiert nicht	FAIL wiki/x.md Fachliche Prüfung EC-1: resource existiert nicht (Pfad=raw/fehlt.md)
§6.1 EC-1 Negativ (Verzeichnis)	sources: [{resource: raw/prd}] (existierendes Verzeichnis, keine Datei)	FAIL wiki/x.md Fachliche Prüfung EC-1: resource existiert nicht (Pfad=raw/prd)
§6.1 EC-1 Aggregation	sources: [{resource: raw/a.md}, {resource: raw/b.md}], beide fehlen	FAIL wiki/x.md Fachliche Prüfung EC-1: resource existiert nicht (Pfad=raw/a.md, raw/b.md)
§6.3 EC-3 Positiv	stale_after: 2026-12-31, last_modified: 2026-08-14, at: 2026-08-15T10:00:00Z (reale Kalenderdaten)	SUCCESS wiki/x.md
§6.3 EC-3 Negativ	nur at: 2026-02-31T10:00:00Z (Tag existiert nicht im Februar)	FAIL wiki/x.md Fachliche Prüfung EC-3: Kalender-Validität verletzt (Feld=at, Wert=2026-02-31T10:00:00Z)
§6.4 WARN Negativ	stale_after: 2026-01-01 mit today (UTC) = 2026-08-16 → veraltet	SUCCESS wiki/x.md + WARN wiki/x.md stale_after überschritten (Datum=2026-01-01, today=2026-08-16)
§6.4 WARN Positiv (nicht veraltet)	stale_after: 2026-12-31 mit today (UTC) = 2026-08-16 → nicht veraltet	SUCCESS wiki/x.md (keine WARN)
§6.5 EC-11 Positiv	wiki/<area>/logo.png (nicht-.md unter wiki/) vorhanden	kein Verdikt für logo.png (wird ignoriert, §1/§6.5); valide .md-Dateien unverändert SUCCESS
§6.5 EC-11 Konvention	Verzeichnis wiki/<area>/ enthält nur logo.png + index.md	SUCCESS wiki/<area>/index.md (logo.png ignoriert)
§3.2 V-1 Negativ	wiki/index.md existiert nicht (Bundle ohne Bundleroot)	FAIL (Voraussetzung) Bundleroot fehlt: wiki/index.md existiert nicht (V-1, Vertrag §2, Vorausbedingung zu Punkt 8)
§3.2 V-1 Positiv	wiki/index.md ist vorhanden	SUCCESS (Voraussetzung V-1 nicht verletzt)
§3.2 V-2 Negativ	wiki/<area>/log.md existiert (reservierter Name außerhalb der Bundleroot)	FAIL wiki/<area>/log.md log.md an unzulässiger Position (V-2, reservierter Name, nur Bundleroot, Vertrag §5)
§3.2 V-2 Positiv	kein log.md außerhalb der Bundleroot	SUCCESS (Voraussetzung V-2 nicht verletzt)

Zertifizierungs-Notiz (F-02): Die obigen §6-Fixtures ergänzen die bislang ausschließlich die 14 §7-Punkte belegende Fixture-Abdeckung. Der Eintrag in wiki/log.md (2026-08-15, Revision 2) behauptete „alle Negativ-/Positiv-Fixtures" geprüft zu haben — das bezog sich auf §7.1/§7.2. Die §6-Gates (EC-1/EC-3) sind damit erst jetzt explizit fixturiert und zertifizierbar.

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.
• Revision 3 (2026-08-16): Re-Konsistenz mit dem autorisierten Vertrag (Retrospective F-01, AI-1): Die in Revision 2 eingeführte Toleranz „reine Datumsangabe YYYY-MM-DD als at → SUCCESS (normalisiert zu T00:00:00Z)" ist zurückgenommen. at in generated/verified MUSS jetzt ein volles ISO-8601-Datetime sein; eine reine Datumsangabe erzeugt FAIL nach Punkt 14 (Vertrag §3.4/§3.5: „ISO-8601-Datetime", §7 Punkt 14). §4.3 entsprechend umformuliert; Fixture 14c als Negativ-Fixture (at: 2027-01-01 → FAIL) geführt, das freie Positiv-Slot mit der ±HHMM-Form (+0200) belegt. Der autorisierte Vertrag schema/wiki-compiler.md bleibt unverändert.
• Revision 4 (2026-08-16): §6-Fixtures ergänzt (Retrospective F-02, AI-2) — neue Tabelle §7.3 belegt die fachlichen Zusatzprüfungen §6: EC-1-Existenz (Positiv/Negativ/Verzeichnis/Aggregation), EC-3-Kalender-Validität (Positiv/Negativ), §6.4-stale_after-WARN (veraltet/nicht veraltet), EC-11-non-md (Ignoranz). §6.1/§6.3/§6.4/§6.5 tragen Verweise auf §7.3; §7-Einleitung nennt §6-Fixtures als eigene Sektion. Zertifizierung in wiki/log.md (2026-08-16) nachgeführt.
• Revision 5 (2026-08-16): §3.2-Voraussetzungsprüfungen als fachliche Prüfklasse V-1/V-2 gelabelt (Retrospective F-03, AI-3) — Verdikt-Präfix ändert sich von FAIL (Struktur) … auf FAIL (Voraussetzung) … (V-1|V-2, …); §5-Verdikt-Grammatik und §5.1-Selbstbegrenzung um die V-1/V-2-Abgrenzung ergänzt (fachliche Prüfklassen verlassen die Abschluss-Eigenschaft des §7-Katalogs nicht); §7.1-Fixtures 8a/10a an die V-1/V-2-Sprache angeglichen; §7.3 um V-1/V-2 (Positiv/Negativ, 4 Zeilen) erweitert; §3.2 erhält ein erklärendes <details> (Warum V-1/V-2, Verweis auf F-03/AI-3). Vertrag schema/wiki-compiler.md unverändert (keine Autorisierung nötig).
• Revision 6 (2026-08-16): BOM-/Leerzeilen-Stripping vereinheitlicht (Retrospective F-05, AI-5) — die gemeinsame Definition „gestrippte Frontmatter-Erkennung" (§3-Präambel: UTF-8-BOM U+FEFF + führende Leerzeilen vor dem --- entfernen) gilt jetzt für alle Frontmatter-erkennenden Punkte 2, 8 und 10 (zuvor nur Punkt 10). Punkt 2/8-Prüfschritt-Zellen verweisen auf §3-Präambel; Punkt 10 rückverweist darauf. Neue Positiv-Fixtures: 2a (Concept mit BOM/Leerzeile vor Frontmatter → SUCCESS) und 8b (Bundleroot mit BOM/Leerzeile vor Frontmatter → SUCCESS). Zusätzlich zwei Defer-Verweise als „offene Punkte" (§1 Punkt 3 zu .MD-Großschreibung, F-08; §6.4 zu today-Zeitzone, F-06) eingebettet — Defer-Kontexte aus AI-7. Vertrag unverändert.
• Revision 7 (2026-08-16, Step-04-Review Story 2.1): §7.3-Fixture-Isolations-Hinweis um Innen-Ebenen-Key-Subset-Fälle erweitert — die Punkt-6-Formprüfung gilt nicht nur für Top-Level-Frontmatter-Felder, sondern auch für unautorisierte Keys innerhalb von sources/generated/verified-Einträgen (Vertrag §3.3–§3.5); Konsequenz für Fixture-Isolation (sonst-valide und nur der Innen-Ebenen-Key sticht Punkt 6 hervor) dokumentiert (§7.3). Vertrag schema/wiki-compiler.md unverändert (keine Autorisierung nötig, nur dokumentarische Klarstellung der bestehenden Punkt-6-Regel).
• Revision 8 (2026-08-16, Autorisations-Runde): Option-A-Heilung Story 2.1 — drei Änderungen: (1) F-14-Negativ-Fixture 4a ergänzt (§7.1, Punkt 4: resource außerhalb raw/, aber existierend, z. B. README.md an der Workspace-Root; Retrospective F-14) — erwartet FAIL … Punkt 4, Isolations-Prinzip gewahrt; (2) Innen-Ebenen-Key-Subset formalisiert — die Rev-7-Klarstellung (Punkt 6 in sources/generated/verified-Einträgen, Vertrag §3.3–§3.5) wird als formal getragener Inhalt dieser autorisierten Revision bestätigt, und die Punkt-6-Zelle verweist explizit auf die §7.3-Isolations-Notiz (autorisiert, Revision 8); (3) Header-Revisionszahl von „Revision 6" auf „Revision 8" angehoben (behebt die pre-existing Header-Log-Diskrepanz, OBS-1). Vertrag schema/wiki-compiler.md unverändert (keine Vertrags-Autorisierung nötig — Punkt 6 deckt Innen-Ebenen bereits, §3.3–§3.5).