# 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:** 6 (Revisionslog in §8)
> **Ableitungsdatum:** 2026-08-15
> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 6 — Retrospective F-01/AI-1, F-02/AI-2, F-03/AI-3, F-05/AI-5)

## 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):**

```text
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|leer|nicht-String)` |
| 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|absolut|URL|Backslash|file://)` |
| 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 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=<area> | Concept nicht verlinkt=<concept>)` |
| 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).

<details>
<summary>Warum V-1/V-2 (Retrospective F-03, AI-3)?</summary>

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.

</details>

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

```text
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|leer|nicht-String)` |
| 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 (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.

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