chore: Autorisierte Validator-Revision 9 — Punkt-11-Area-Lesart formalisieren + gehaltene Patches tragen
- Header auf Revision 9 + Revisionslog-Eintrag (append-only, fünf inhaltliche Änderungen, keine neue §7-Klasse / kein Punkt 15) - §3 Punkt-11-Area-Lesart: Pärchen (Area-Präfix + Link-Ziel) identitätsstiftend, file-relative Referenz genügt; Normalisierung (./-Strip, ..-Ausschluss, .md-Strip AD-7a) - §3 Punkt-4-Vorlage: resolved=<pfad>-Token + §6.2-Semantik (nur bei Ablehnung durch aufgelöste Lage außerhalb raw/), Fixture 4a ableitbar - §7.3 Innen-Ebenen-Punkt-6-Fixtures (Negativ role: x -> FAIL Punkt 6 / Positiv) - §7-Fixtures 11a (Negativ am realen Live-Area-Namen / Positiv file-relativ) - Vertrag schema/wiki-compiler.md + Instruktion schema/compiler.md + raw/ + adapters/ unverändert (AD-3/D-3-Freeze, git diff 0 Treffer) - Zertifizierung wiki/log.md (Isolierte Fixtures + reales Bundle 7/7 SUCCESS + Live-Invariant) - Sprint-Status: code-review-2-1-item-2 + epic-2-retro-item-14 -> done Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Michael Tamse
+15
-7
@@ -2,9 +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:** 8 (Revisionslog in §8)
|
||||
> **Validator-Revision:** 9 (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)
|
||||
> **Letzte Re-Konsistenz:** 2026-08-18 (Revision 9 — Punkt-11-Area-Lesart; Punkt-4-`resolved=`-Token; Innen-Ebenen-Punkt-6-Fixture-Zeile)
|
||||
|
||||
## 0. Zweck & Aufruf
|
||||
|
||||
@@ -60,14 +60,14 @@ Wert-Semantik des YAML-Checks: Frontmatter ist als YAML zu parsen. Wiederholte F
|
||||
| 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://)` |
|
||||
| 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://|resolved=<pfad>)` |
|
||||
| 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=<area> | Concept nicht verlinkt=<concept>)` |
|
||||
| 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). **Area-Lesart (autorisiert, Revision 9):** Für ein Area-Concept genügt die **file-relative** Referenz in der Area-`index.md` des nächsten Vorfahren — identitätsstiftend ist das Pärchen (Area-Präfix = **bundle-relativer Verzeichnispfad** der Area-`index.md` + Link-Ziel), eine textuelle Nennung der Bundle-Identität in der Area-`index.md` ist dafür nicht erforderlich. Der Area-Präfix ist der Verzeichnispfad der Area-`index.md` relativ zur Bundleroot (z. B. für `wiki/wissensarchitektur/index.md` → `wissensarchitektur/`), nicht nur der Leaf-Verzeichnisname — robust auch für Area-Tiefe ≥ 2 (die Zwei-Ebenen-Beschränkung ist Gegenstand der Compiler-Instruktion §5.8; der Validator delegiert die Struktur-Zulässigkeit dorthin und bildet die Identität rein aus Area-Präfix + Link-Ziel). **Normalisierung des Link-Ziels vor der Identitätsbildung:** Ein führendes `.`/`./`-Segment wird gestrippt; `..`-Segmente gehören nicht zur gepinnten Ein-Ebenen-Form (file-relative Referenzen in der Area-`index.md` sind Ein-Ebenen-Links auf Concepts desselben Verzeichnisses; `..`-Aufwärts-Ziele sind keine Area-Concept-Referenzen im Sinne dieser Regel). **Identität ohne `.md`-Endung (AD-7a):** Die `.md`-Endung des Link-Ziels wird für die Identitätsbildung **abgestreift** — das Beispiel `source-material` (aus `](source-material.md)`) ergibt mit dem Area-Präfix `wissensarchitektur/` eindeutig die Bundle-Identität `wissensarchitektur/source-material`. Root-Concepts bleiben wie bisher in der Bundleroot referenziert (mit oder ohne `.md`-Endung). „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>)` |
|
||||
@@ -179,6 +179,8 @@ Die folgenden Prüfungen sind **fachliche** Prüfungen (keine §7-Invaliditäts-
|
||||
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).
|
||||
|
||||
**Semantik des `resolved=<pfad>`-Tokens (Autorisations-Runde, Revision 9):** Das optionale `resolved=`-Suffix der Punkt-4-Fehlerursache (§3 Punkt 4, Vorlage `…|file://|resolved=<pfad>`) wird nur dann ergänzt, wenn die Ablehnung durch die **aufgelöste Lage** des Pfads erfolgt (Schritt 5: außerhalb `raw/`), **nicht** durch einen der Grammatik-Schritte 1–4 (`..`-Segment, führendes `/`, Backslash/Windows-Trenner, `file://`/URL). Der Wert ist der aufgelöste, workspace-relative Pfad des `resource`-Werts (Beispiel Fixture 4a: `resource: README.md` an der Workspace-Root → `resolved=README.md`). Erfolgt die Ablehnung über einen der Grammatik-Schritte 1–4, bleibt der Katalog auf die entsprechenden Token beschränkt und trägt **kein** `resolved=`-Suffix (die Punktnummer ist je Input deterministisch, §6.2 Vorrangsregel). Konsistenz mit §5-Verdikt-Grammatik: Das `resolved=`-Token ist Bestandteil der textuellen Fehlerursache („Punkt-Nummer + deterministischer Grund + relevanter Wert/Pfad", §5 FAIL) — es ersetzt weder Verdikt-Verb noch Pfad und erzeugt keine eigene Prüfklasse.
|
||||
|
||||
### 6.3 Kalender-Validität der Datumsfelder (EC-3)
|
||||
|
||||
Für alle `YYYY-MM-DD`-Felder (`stale_after`, `sources[].last_modified`) gilt:
|
||||
@@ -210,7 +212,7 @@ Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte (§7.1/§7.2) **s
|
||||
| 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://)` |
|
||||
| 4 | `sources: [{resource: ../outside.md}]` | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal\|absolut\|URL\|Backslash\|file://\|resolved=<pfad>)` |
|
||||
| 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)` |
|
||||
@@ -221,6 +223,7 @@ Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte (§7.1/§7.2) **s
|
||||
| 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)` |
|
||||
| 11a | Area `wiki/wissensarchitektur/` mit `index.md`, das Area-Concept `source-material.md` **nicht** verlinkt (file-relative Referenz fehlt; der Live-Area-Name wird bewusst genutzt, weil die Fixture den F-02-Defekt am realen Bundle belegt; die übrigen Links der Area werden als valide angenommen — restliche Konzepte verlinkt, Isolations-Prinzip §7.1) | `FAIL wiki/wissensarchitektur/source-material.md Punkt 11: Index-Regel verletzt (Concept nicht verlinkt=wissensarchitektur/source-material)` |
|
||||
| 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)` |
|
||||
@@ -250,6 +253,7 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
|
||||
| 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) |
|
||||
| 11a | Area `wiki/wissensarchitektur/` mit `index.md`, das Area-Concept `source-material.md` file-relativ verlinkt (`](source-material.md)`) | `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` |
|
||||
@@ -258,9 +262,9 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
|
||||
| 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)
|
||||
### 7.3 §6-Fachliche-Zusatzprüfungen-Fixtures (EC-1, EC-3, WARN, EC-11) & Innen-Ebenen-Punkt-6-Fixtures
|
||||
|
||||
> 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.
|
||||
> 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 die hier aufgeführten Punkt-6-Fälle auf Innen-Ebenen (`sources`/`generated`/`verified`-Einträge): Ein unautorisierter Key innerhalb eines Eintrags (Negativ-Zeile: `sources:\n - resource: …\n role: x` → genau Punkt 6 löst aus, losgelöst von der §6-Formprüfung; vertraglich §3.3–§3.5), ein Eintrag mit ausschließlich erlaubten Keys (Positiv-Zeile) passiert alle Punkte. Die Verdikt-Zellen tragen den reinen, maschinenlesbaren Fehlerursachen-String gemäß §3 (kein erklärender Zusatz in der Zelle).
|
||||
|
||||
| # | Fixture (Input) | Erwartetes Verdikt |
|
||||
|---|-----------------|--------------------|
|
||||
@@ -274,6 +278,8 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
|
||||
| §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) |
|
||||
| Innen-Ebenen Punkt 6 Negativ | `sources:\n - resource: raw/prd/prd-wow20-2026-08-14.md\n role: x` (existierende `raw/`-Datei, unautorisierter Key `role:` in `sources`-Eintrag) | `FAIL wiki/x.md Punkt 6: nicht autorisiertes Feld (Key=role) bzw. unautorisierter Key in sources/generated/verified` |
|
||||
| Innen-Ebenen Punkt 6 Positiv | `sources`-Eintrag mit `resource` und ausschließlich erlaubten Keys (kein `role`) | `SUCCESS wiki/x.md` (kein Punkt 6) |
|
||||
| §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)` |
|
||||
@@ -295,6 +301,7 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
|
||||
- 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.
|
||||
- **Revision 9 — Punkt-11-Area-Lesart (autorisiert, 2026-08-18):** Ergänzt die Story-2.3-Formklausel um die konsistente Nachführung der Pin-Form-Doktrin: Für ein **Area-Concept** genügt die file-relative Referenz in der Area-`index.md` des nächsten Vorfahren (Pärchen Area-Präfix + Link-Ziel identitätsstiftend); Root-Concepts bleiben wie bisher (mit oder ohne `.md`-Endung) in der Bundleroot referenziert. Dies ist die formale Vereinheitlichung der Story-2.3-Notiz mit der von Story 2.4/2.5 genutzten file-relativen Area-Linkform (`compiler.md` §5.6/§5.7) — no new §7-Klasse, die abschließende 14-Punkte-Liste bleibt unangetastet (Vertrag §7).
|
||||
|
||||
**Revisionslog:**
|
||||
|
||||
@@ -306,3 +313,4 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept
|
||||
- **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).
|
||||
- **Revision 9 (2026-08-18, Autorisations-Runde):** Epic-2-F-02/AI-2-R-5 (de-dupliziert mit `code-review-2-1-item-2`) — fünf inhaltliche Änderungen, keine neue §7-Klasse (kein Punkt 15; Abschluss-Eigenschaft des §7-Katalogs gewahrt), `schema/wiki-compiler.md` (Vertrag) und `schema/compiler.md` (Instruktion) unverändert (AD-3/D-3): (1) **Punkt-11-Area-Lesart formalisiert** (§3 Punkt-11-Zelle, Kern der Rev-9-Lesart, Retrospective F-02/Open question 3): Für ein Area-Concept genügt die **file-relative** Referenz in der `index.md` des nächsten Vorfahren (Area-`index.md`); identitätsstiftend ist das **Pärchen (Area-Präfix = bundle-relativer Verzeichnispfad der Area-`index.md` + Link-Ziel ohne `.md`-Endung, AD-7a)**, eine textuelle Nennung der Bundle-Identität in der Area-`index.md` ist nicht erforderlich (Live: `wiki/wissensarchitektur/source-material.md` → Identität `wissensarchitektur/source-material` über `](source-material.md)` in der Area-`index.md`); Normalisierung des Link-Ziels (`.`/`./`-Strip; `..` nicht Teil der gepinnten Ein-Ebenen-Form) und `.md`-Endungs-Strip für die Identitätsbildung explizit verankert. Root-Concepts bleiben wie bisher in der Bundleroot referenziert (mit oder ohne `.md`-Endung — eine genau-eine-Form-Festlegung liegt bei Story 2.3/§5.6 der Compiler-Instruktion, der Validator gibt sie nicht vor). (2) **Punkt-4-Fehlerursachen-Grammatik um `resolved=<pfad>`-Token ergänzt + Semantik verankert** (§3 Punkt-4-Zelle: `…|resolved=<pfad>`; §6.2: Token feuert nur bei Ablehnung durch aufgelöste Lage außerhalb `raw/`, Wert = aufgelöster workspace-relativer Pfad; Konsistenz mit §5-Verdikt-Grammatik) — Patch 16 (gehalten, deferred-work.md), macht Fixture 4a (§7.1: `resolved=README.md`) ableitbar. (3) **Innen-Ebenen-Punkt-6-Fixtures ergänzt** (§7.3: Negativ-Zeile `sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei → `FAIL … Punkt 6`; Positiv-Gegenzeile ausschließlich erlaubte Keys → SUCCESS) — Patch 17 (gehalten), belegt die Rev-8-Formalisierung der Innen-Ebenen-Regel re-runbar. (4) **§7-Fixtures 11a** (Negativ: Area-Concept nicht verlinkt → `FAIL … Concept nicht verlinkt=wissensarchitektur/source-material`; Positiv: file-relativ verlinkt → SUCCESS) ergänzt — prüfbare Negative der Area-Lesart am realen Live-Area-Namen. (5) **§8-Normreferenz-Notiz „Story 2.3 (Link-Form)" um die Rev-9-Area-Lesart ergänzt** (Konsistenz der Lesart mit der Pin-Form-Doktrin). Nachgeführt: Header-Revisionszahl auf „Revision 9" angehoben + Revisionslog-Eintrag (append-only, bestehende Einträge unangetastet). Zertifizierung in `wiki/log.md` (2026-08-18) nachgeführt: Fixture 4a isoliert → FAIL Punkt 4 (`resolved=README.md`); Innen-Ebenen-Sample → FAIL Punkt 6 (`Key=role`); Punkt-11-Area-Fixtures (11a Negativ/Positiv) → FAIL bzw. SUCCESS; reales Bundle (7 `wiki/`-Dateien) → weiterhin SUCCESS. Vertrag unverändert (Punkt 11 deckt die Area-Lesart bereits vertraglich, §7).
|
||||
|
||||
Reference in New Issue
Block a user