chore: Epic-1-Retrospective Action Items AI-1..AI-7 umsetzen
Re-Konsistenz des Validators mit dem autorisierten Vertrag (schema/validator.md 3->6):
- F-01/AI-1: at-Nur-Datum-Toleranz zurueckgenommen (reines Datum => FAIL Punkt 14), Fixture 14c umgebaut, +HHMM-Positiv; Vertrag unveraendert
- F-02/AI-2: neue Fixture-Tabelle 7.3 (EC-1 Existenz, EC-3 Kalender, stale_after-WARN, EC-11 non-md); Zertifizierung in wiki/log.md nachgefuehrt
- F-03/AI-3: 3.2-Voraussetzungen als fachliche Pruefklasse V-1/V-2 gelabelt (FAIL (Voraussetzung)); 5-Grammatik + Fixtures angeglichen
- F-05/AI-5: BOM-/Leerzeilen-Stripping der Frontmatter-Erkennung auf Punkte 2/8/10 vereinheitlicht (3-Praaembel); Positiv-Fixtures 2a/8b
- F-06/F-08 (AI-7): offene Punkte (today-Zeitzone, .MD-Grossschreibung) im Validator verankert
Weitere Retro-Follow-ups:
- F-09/AI-4: source.md-Provenienz korrigiert (_bmad-output/ ist versioniert, Commit 6cc667d + SHA-256 byte-identisch)
- F-10/AI-6: strenger Vertrag<->Validator<->Fixtures-Abgleich (14 Punkte, keine Punkt 15) als Pflicht-Re-Check in spec-1-4; bleibt in D-3
- F-04/F-06/F-07/F-08/F-11/F-14 (AI-7): Defer-Kontexte in deferred-work.md gesichert
- Action Items AI-1..AI-7 auf done gesetzt (sprint-status.yaml)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Michael Tamse
+68
-26
@@ -2,8 +2,9 @@
|
||||
|
||||
> **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)
|
||||
> **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
|
||||
|
||||
@@ -31,6 +32,7 @@ Ausführung: deterministisch von einem Agent/Prozess befolgt (kein L
|
||||
- `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/`
|
||||
|
||||
@@ -51,18 +53,20 @@ Die folgende Liste bildet die **abschließende** 14-Punkte-Invaliditätsliste de
|
||||
|
||||
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 `---` ODER ist das Frontmatter nicht als YAML parsbar ODER fehlt `type` (bzw. ist leer)? | `Punkt 2: nicht-reservierte .md-Datei ohne Frontmatter/ohne type` |
|
||||
| 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 `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` |
|
||||
| 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 (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>)` |
|
||||
| 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>)` |
|
||||
@@ -70,17 +74,24 @@ Wert-Semantik des YAML-Checks: Frontmatter ist als YAML zu parsen. Wiederholte F
|
||||
|
||||
### 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.
|
||||
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 (Vertrag §2/§5)
|
||||
### 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 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.
|
||||
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**.
|
||||
|
||||
- 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).
|
||||
- **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)
|
||||
|
||||
@@ -102,8 +113,8 @@ Diese Abschnitte legen die von Deferred-Work an Story 1.4 verwiesenen Entscheidu
|
||||
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).
|
||||
- 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)
|
||||
@@ -111,7 +122,7 @@ Für `at` (in `generated`/`verified`) gilt die folgende ISO-8601-Normalform (det
|
||||
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).
|
||||
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.
|
||||
|
||||
@@ -136,14 +147,14 @@ 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).
|
||||
- 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.
|
||||
- Es werden **keine neuen Invaliditätsklassen** eingeführt (abschließende 14-Punkte-Liste, §3.1).
|
||||
- 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)
|
||||
@@ -152,7 +163,7 @@ Die folgenden Prüfungen sind **fachliche** Prüfungen (keine §7-Invaliditäts-
|
||||
|
||||
### 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).
|
||||
- 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).
|
||||
@@ -173,21 +184,22 @@ Die folgenden Prüfungen sind **fachliche** Prüfungen (keine §7-Invaliditäts-
|
||||
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).
|
||||
- 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.
|
||||
- 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).
|
||||
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 und machen jede mechanische Bedingung reproduzierbar nachprüfbar (AD-17h). „⇒" gibt das erwartete Verdikt an; die Fehlerursache ist exakt die aus §3.
|
||||
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)
|
||||
|
||||
@@ -203,17 +215,18 @@ Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte und machen jede m
|
||||
| 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)` |
|
||||
| 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 (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)` |
|
||||
| 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)
|
||||
|
||||
@@ -223,25 +236,50 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
|
||||
|---|-----------------|--------------------|
|
||||
| 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` |
|
||||
| 8a | Bundleroot `wiki/index.md` ist vorhanden | `SUCCESS` (Voraussetzung §3.2 nicht verletzt) |
|
||||
| 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 §3.2 nicht verletzt) |
|
||||
| 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: 2027-01-01` (reiner Datumswert) | `SUCCESS wiki/x.md` (normalisiert zu `T00:00:00Z`, §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):**
|
||||
@@ -261,3 +299,7 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
|
||||
|
||||
- **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.
|
||||
|
||||
Reference in New Issue
Block a user