Michael TamseandClaude
a67ba65910
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>
216 lines
22 KiB
Markdown
216 lines
22 KiB
Markdown
---
|
||
title: 'Schema-Validierung für Bundle implementieren (Story 1.4)'
|
||
type: 'feature'
|
||
created: '2026-08-15'
|
||
status: 'done'
|
||
baseline_commit: 33d21cb0ad390a921c817342b4c21f11f3694516
|
||
review_loop_iteration: 0
|
||
context:
|
||
- _bmad-output/implementation-artifacts/epic-1-context.md
|
||
---
|
||
|
||
<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
|
||
|
||
## Intent
|
||
|
||
**Problem:** Der autorisierte Schema-Vertrag (§7) definiert eine abschließende 14-Punkte-Liste struktureller Invalidität und verweist mehrere Prüf-Verhalten (Existenzprüfung `raw/`-Resource, Kalender-Validität, ISO-8601-Normalform, Listen-Normalisierung) an Story 1.4 — aber es existiert noch keine ausführbare, deterministische Validierung. Ohne sie könnte ein Producer vor der Mutation nicht nachweisen, dass sein Bundle gültig ist, und ein OKF-invalides Bundle würde einen Run nicht zuverlässig scheitern lassen (F-2/AD-1b, A0-2, FR-9).
|
||
|
||
**Approach:** Eine agent-unabhängige, deterministische Validator-Instruktion `schema/validator.md` erstellen, die die abschließende 14-Punkte-Invaliditätsliste (Vertrag §7) 1:1 als mechanische Prüfschritte abbildet, die von Deferred-Work an Story 1.4 verwiesenen Validator-Entscheidungen (ISO-8601-Normalform, Kalender-Validität, Existenzprüfung, Listen-/Absenz-Normalisierung, non-md-Konvention, `stale_after`-Warning) deterministisch festlegt und ein maschinenlesbares PASS/FAIL-Verdikt mit textueller Fehlerursache ausgibt — ohne LLM-Urteil und ohne Standalone-Anwendung (D-3, Q-6: Agent-Instruktions-Validator, mechanisch zu bestätigen).
|
||
|
||
## Boundaries & Constraints
|
||
|
||
**Always:**
|
||
- `schema/validator.md` ist der einzige Ort der Validierungs-Instruktion; er ist rein textuell (kein ausführbarer Code) und agent-unabhängig, liegt außerhalb des Bundles neben dem Vertrag (AD-1, D-3, Q-6).
|
||
- Die Validierung bildet die **abschließende** 14-Punkte-Liste (Vertrag §7) 1:1 ab; sie darf keinen Eintrag hinzufügen oder streichen (Vertrag §7 „abschließende Liste"). Erweiterungen nur über das Story-/Autorisierungs-Verfahren.
|
||
- Fehlende optionale Felder (kein `sources`/`generated`/`verified`/`status`/`stale_after`) sind niemals invalide (A0-2/AD-1b); `sources: []`/`verified: []` sind zulässig und gleichbedeutend mit Absenz.
|
||
- Die Validierung ist deterministisch und ohne LLM-Urteil aufrufbar (AD-13/AD-17h); sie erzeugt pro geprüfter Datei ein PASS/FAIL-Verdikt mit textuell identifizierbarer Fehlerursache (NFR-4).
|
||
- Prüfumfang (Vertrag §1): ausschließlich Markdown innerhalb `wiki/` (Bundleroot, Area-`index.md`, Concepts, `log.md`) plus die `raw/`-Ziellinien aus `sources`-`resource`. `raw/`, `schema/`, `adapters/` selbst werden nicht als Bundle validiert.
|
||
- Existenzprüfung: ein `sources`-`resource` unter `raw/` MUSS zum Validierungszeitpunkt als Datei existieren (fachliche Validierung, Deferred-Work EC-1).
|
||
- Kalender-Validität: Datumsfelder müssen reale Kalenderdaten sein (`2026-02-31` ist invalide); der Veraltungsvergleich `today >= stale_after` erfolgt in UTC (Vertrag §7).
|
||
- Valid-Pfad-Auflösung (Vertrag §3.3): `resource` ist ein `/`-getrennter relativer Pfad zur Workspace-Root, darf kein `..`-Segment, keinen führenden `/`, kein `file://` und keine Backslash-/Windows-Trenner enthalten und muss bei Auflösung innerhalb `raw/` landen.
|
||
- Dateien unter `wiki/`, die keine `.md`-Dateien sind (z. B. `wiki/<area>/logo.png`), werden als nicht-Bundle-Elemente behandelt und nicht validiert (Deferred-Work EC-11).
|
||
- Dokument in Deutsch; das Verdikt-Format ist maschinenlesbar (ein SUCCESS/FAIL-Verb per Datei, gefolgt von textueller Begründung).
|
||
|
||
**Ask First:**
|
||
- Eine bewusste Verschärfung gegenüber dem Vertrag (z. B. Absicht, `resource`-Existenz als strukturell statt fachlich zu werten) — nur mit menschlicher Zustimmung, da sie die Abschluss-Position von §7 berührt.
|
||
- Die Einführung eines Standalone-Skripts/-Programms (Python/TS/etc.) als eigentliche Validator-Implementierung — der Epic-Context (D-3, Q-6) widerspricht dem; ein späterer Wechsel auf eine konkrete Anwendung ist separat zu autopisieren.
|
||
|
||
**Never:**
|
||
- Kein eigenes Schema neben `schema/wiki-compiler.md`; keine Änderung am autorisierten Vertrag (Story 1.3) und keine Änderung an `raw/` (immutable, AD-3).
|
||
- Kein Standalone-/Executable-Anwendungs-Code, der die Validierung ersetzt (D-3); die Validierungs-Regel bleibt eine Instruktion, kein Programm.
|
||
- Keine neue Invaliditätsklasse oder neue Pflichtfelder außerhalb des Vertrags; keine Validierung der Inhalte von `raw/`-, `schema/`- oder `adapters/`-Dateien als Bundle.
|
||
- Kein LLM-Urteil in der Prüfung; der Validator ist kein Modell-Aufruf, sondern eine mechanisch befolgte Anweisung.
|
||
- Keine Validierung schreibender Art: der Validator mutiert nichts, protokolliert aber (siehe Verification) ein Ausführungs-Protokoll.
|
||
</frozen-after-approval>
|
||
|
||
## Code Map
|
||
|
||
- `schema/validator.md` — **Zieldatei** (neu): deterministische Validator-Instruktion; bildet Vertrag §7 ab und legt die von Deferred-Work an Story 1.4 verwiesenen Entscheidungen fest.
|
||
- `schema/wiki-compiler.md` — normative Grundlage (read-only, Story 1.3-Ergebnis): §1 Geltungsbereich, §2 Bundleroot/Frontmatter, §3 Feldsubset (inkl. §3.3 `sources`/`resource`-Auflösung, §3.4 `generated`, §3.5 `verified`, §3.6 `status`, §3.7 `stale_after`), §5 `log.md`-Typ, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
|
||
- `wiki/index.md` — Referenz Bundleroot (read-only): `type: bundle` + `okf_version: "0.2"`, Frontmatter exklusiv; POSITIV-Beispiel für Prüfschritt 8/9.
|
||
- `wiki/log.md` — Referenz leerer `log.md`: Kein Frontmatter, reservierte Root-Datei; in dieser Story wird ausschließlich der Zertifizierungs-Ausführungs-Protokolleintrag angehängt (keine inhaltliche Bundle-Änderung, Vertrag §5-konform).
|
||
- `adapters/claude/README.md`, `adapters/README.md` — Referenz für den Adapter-/Agenten-Kontext (read-only); der Validator ist von Adaptern unabhängig (AD-10).
|
||
- `_bmad-output/implementation-artifacts/deferred-work.md` — **Pflicht-Input**: die 8 an Story 1.4 verwiesenen Validator-Entscheidungen (EC-1, EC-3, BH-14, F2-Listen, BH-8, EC-11, F17-`log.md`, F18-`stale_after`) — werden in der Instruktion deterministisch festgelegt.
|
||
- `_bmad-output/implementation-artifacts/epic-1-context.md` — primärer Planungskontext (read-only).
|
||
|
||
## Tasks & Acceptance
|
||
|
||
**Execution:**
|
||
- [x] `schema/validator.md` — Validator-Instruktion anlegen: Zweck & Aufruf (Agent/Prozess führt die Schritte deterministisch aus), Prüfumfang nach Vertrag §1, die 14 Invaliditäts-Punkte 1:1 als mechanische Prüfschritte (inkl. Welcher YAML-/Text-Check je Punkt, welches Artefakt), die fachlichen Zusatzprüfungen (Existenzprüfung `raw/`-Resource, Kalender-/Datum-Validität in UTC, `stale_after`-Veraltungs-Warning als Warnung, non-md-Dateien ignoriert), die Normalisierungs-/Toleranz-Vorgaben (Map→1-Element-Liste bei `verified`, leere Listen = Absenz, semantische Gleichwertigkeit), das maschinenlesbare Verdikt-Format (SUCCESS / FAIL + Datei + Ursache), und die Selbstbegrenzung (abschließende Liste, keine Erweiterung) — F-2/AD-1b, A0-2, FR-9, NFR-4.
|
||
- [x] `schema/validator.md` — die 8 Deferred-Work-Entscheidungen deterministisch festlegen (EC-1 Existenzprüfung, EC-3 Kalender-Validität, BH-14 ISO-8601-Normalform, F2-Listen-Normalisierung, BH-8/F18 `stale_after`-semantische Warnung statt Invalidität, EC-11 non-md-Konvention, F17 `log.md`-Feingranularität: leeres Log gültig) — abgeleitet aus dem Vertrag und dem Epic-Context.
|
||
- [x] `schema/validator.md` — Negativ-/Positiv-Fixtures als Referenztabellen dokumentieren: je Invaliditäts-Punkt ein konkretes Fehlerbeispiel (Input → erwartetes FAIL mit Ursache) und je Punkt das gültige Gegenstück (PASS) — belegt die 1:1-Abbildung und macht die mechanische Bedingung reproduzierbar prüfbar (AD-17h).
|
||
- [x] `schema/validator.md` — Verdikt-Format & Selbstbegrenzung normieren: SUCCESS/FAIL-Report-Struktur, keine Validierung von `raw/`/`schema/`/`adapters/`-Inhalten als Bundle, keine neuen Invaliditätsklassen; textuelle Fehlerursache (NFR-4).
|
||
- [x] `wiki/log.md` — Ausführungs-Protokoll der Validator-Zertifizierung anhängen: Datum, Validator-Revision, Ergebnis der Selbstprüfung gegen die Referenz-Fixtures (PASS/FAIL) — dokumentiert die mechanische Bestätigung (Q-6: „confirmed mechanical"), keine inhaltliche Änderung des Bundles.
|
||
- [x] `_bmad-output/implementation-artifacts/sprint-status.yaml` — Story 1.4 von `backlog` auf `in-progress` setzen (nach Start der Implementierung).
|
||
|
||
**Acceptance Criteria:**
|
||
- Given ein Bundle mit struktureller OKF-Invalidität (z. B. fehlender `type`), when die Validierung ausgeführt wird, then schlägt der Run fehl (FAIL) mit textuell identifizierbarer Ursache — kein erfolgreicher Run (F-2/AD-1b).
|
||
- Given ein Bundle mit fehlenden optionalen Feldern (kein `sources`/`verified`), when die Validierung ausgeführt wird, then gilt es als gültig (PASS) — fehlende optionale Felder sind keine Invalidität (A0-2/AD-1b).
|
||
- Given ein invalides Bundle, when der Run fehlschlägt, then bleibt `raw/` unverändert und die Fehlerursache ist im Verdikt textuell identifizierbar (AD-3, NFR-4).
|
||
- Given die Validierung, when ausgeführt, then ist sie eine eigenständige, deterministische Prüfung ohne LLM-Urteil — als Instruktion mechanisch befolgbar (AD-13/AD-17h-konform), nicht Standalone-Code (D-3).
|
||
- Given ein `sources`-`resource`, when es auf einen `wiki/`-Concept-Pfad oder außerhalb `raw/` zeigt (nicht-existente Datei, `..`-Traversal), then ist das Bundle FAIL (Provenienz-Ziellinie, §3.3) bzw. fachliche Invalidität (Existenzprüfung).
|
||
- Given die abschließende Invaliditätsliste (§7), when die Instruktion fertig ist, then bildet sie alle 14 Punkte 1:1 ab und führt keine eigene Invaliditätsklasse ein.
|
||
- Given ein `stale_after` in der Vergangenheit, when validiert wird, then ist es kein struktureller Fehler; eine Warnung dokumentiert die Veraltung (F18/BH-8, ohne Invalidität).
|
||
- Given `verified` als einzelne Map, when validiert wird, then wird es als 1-Element-Liste gelesen und nicht abgelehnt (Vertrag §3.5).
|
||
- Given eine nicht-`.md`-Datei unter `wiki/`, when validiert wird, then wird sie ignoriert (nicht Bundle-Element) (EC-11).
|
||
|
||
## Spec Change Log
|
||
|
||
- **2026-08-15, Loop 1 (Step-04-Review: Blind-Hunter + Edge-Case-Hunter + Verification-Gap):** Kein `bad_spec`/`intent_gap` — alle Befunde sind als `patch` direkt in `schema/validator.md` lösbar oder `defer`. Amendments (non-frozen; Code Map + Tasks + Design Notes + Spec Change Log):
|
||
- **Bundleroot-/Reserviert-Pflichten dokumentieren:** Code Map/Aufruf weisen auf die neuen Bundleroot- und Reserviert-Namen-Voraussetzungen (fehlende `wiki/index.md`; `log.md` an Nicht-Root-Position) als strukturelle Norm-Pflichten des Validators hin — keine neue §7-Invaliditätsklasse, sondern Voraussetzungs-Checks (BH-7/EC-2/EC-4).
|
||
- **ISO-8601-Maß relativiert:** Die Normalform akzeptiert beide Offset-Formen (`±HHMM` und `±HH:MM`, beide gültiges ISO-8601/RFC 3339); nur Nicht-ISO-8601-Formen sind Punkt-14-FAIL (BH-2). Vertrag §7 Punkt 14 bleibt unangetastet („abschließende Liste" nicht verschärft).
|
||
- **F15 + Story 2.3 als Deferred/Normreferenz:** `generated.by: human:<id>`-Trust-Semantik wird an Epic 4 verschoben (Deferred-Work F15); der Punkt-11-Link-Check verengt die Linkform nicht (genau-eine-Form bleibt Story 2.3) — als Normreferenz dokumentiert, nicht als Validator-Entscheidung (BH-6, EC-7).
|
||
- **KEEP (muss bei Re-Derivation überleben):** die 14-Punkte-1:1-Abbildung als tabellarische mechanische Prüfschritte mit deterministischer Fehlerursache; die 8 Deferred-Work-Entscheidungen (EC-1, EC-3, BH-14, F2, BH-8, EC-11, F17, F18); Verdikt-Format SUCCESS/FAIL mit textueller Ursache (NFR-4); Abbruch-Regel (erste verletzte Bedingung); Selbstbegrenzung (abschließende Liste, keine eigene Invaliditätsklasse, kein Schreibzugriff); Positiv-/Negativ-Fixtures als Referenztabellen (AD-17h).
|
||
|
||
|
||
|
||
## Design Notes
|
||
|
||
Die Story 1.4 ist das erste ausführbare Artefakt des Projekts: Die Validierung ist keine Standalone-Anwendung (D-3 verbietet Python/TS/etc.), sondern eine deterministische Instruktion, die ein Agent/Prozess mechanisch befolgt (Q-6, AD-17h) und die vor Erzeugung der ersten Concepts (Epic 2) stehen muss.
|
||
|
||
Die Validierung wird damit in zwei Ebenen modelliert:
|
||
|
||
```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)
|
||
```
|
||
|
||
Wichtige Normalform-Entscheidungen (aus Deferred-Work):
|
||
- `verified` als Map → 1-Element-Liste (Vertrag §3.5); `sources: []`/`verified: []` = Absenz (semantisch identisch) — die Ausgabe-/Diff-Basis nutzt eine feste Reihenfolge.
|
||
- ISO-8601-Normalform für `at` (Vertrag §3.4/3.5): akzeptiert `YYYY-MM-DDTHH:MM:SS` mit den Offset-Suffixen `Z`, `±HHMM` und `±HH:MM` (alle gültiges ISO-8601/RFC 3339); ein reiner Datumswert wird als `T00:00:00Z` normalisiert — nicht „Abweichung vom Format"; Punkt-14-FAIL sind nur Nicht-ISO-8601-Formen (Loop-1-Amendment BH-2).
|
||
- Datumsfelder müssen reale Kalenderdaten sein (EC-3); Veraltungsvergleich `today >= stale_after` in UTC (Vertrag §7).
|
||
- Existenzprüfung fachlich (EC-1): ein `resource` unter `raw/`, das nicht existiert, ist fachlich invalide → FAIL, wird aber nicht als §7-Punkt gezählt (der Validator protokolliert den Punkt separat).
|
||
- `stale_after` in der Vergangenheit: Warnung, kein struktureller Fehler (F18/BH-8).
|
||
- Nicht-`.md`-Dateien unter `wiki/` werden ignoriert (EC-11) — keine Ablehnung, keine Konvention-Erfindung über den Vertrag hinaus.
|
||
|
||
## Verification
|
||
|
||
**Commands:**
|
||
- `git status --short && git diff --stat` — expected: neue Datei `schema/validator.md` + `wiki/log.md`-Protokolleintrag + `sprint-status.yaml`-Wired-Up (Story 1.4 in-progress, epic-1 in-progress); keine `raw/`-Mutationen.
|
||
- Manuelle Abbildungsprüfung: `grep -nE 'Punkt 1[0-4]|Invalid' schema/validator.md` — expected: alle 14 Punkte adressiert; `grep -n 'abschließend' schema/validator.md` — expected: Selbstbegrenzung vorhanden.
|
||
- Konformitäts-Smoke an den Referenzfixtures: `grep -nE '\bFAIL\b|\bSUCCESS\b' schema/validator.md` — expected: je Punkt mindestens ein Beispiel mit klar bezeichneter Erwartung.
|
||
- Verdikt-Format: `grep -nE '\b(SUCCESS|FAIL)\b' schema/validator.md` — expected: ein Verdikt-Verb pro Datei-Syntax dokumentiert.
|
||
|
||
**Strenger Vertrag↔Validator-Abgleich (Retrospective F-10/AI-6, 2026-08-16):** Die dokumentarischen Greps oben sind Existenz-/Mentions-Checks und fangen semantischen Drift nicht (F-01 kam dadurch durch). Als Nachschärfung gilt ab jetzt bei jeder Autorisierung/Re-Derivation des Validators die folgende deterministische Abgleich-Liste (§7 des Vertrags ↔ exakte Validator-Prüfschritt-Zelle): Jeder der 14 Punkte MUSS in `schema/validator.md` als eigene Prüfschritt-Zeile der §3-Tabelle vorhanden sein, und **kein** zusätzlicher §7-Punkt darf existieren. Mechanisch:
|
||
|
||
```text
|
||
Equivalent-Check: die Menge der Punkt-Nummern in der §3-Tabelle = {1..14}
|
||
(mechanisch: `grep -oE '^\| ([0-9]+) \|' schema/validator.md`
|
||
→ sort -u → {1,2,…,14}; keine Punkt-Nummer >14, keine Lücke)
|
||
Konsistenz: `grep -nE 'Punkt [0-9]+' schema/validator.md` — expected:
|
||
jede Punkt-Nummer in der §3-Tabelle ist ein §7-Punkt des Vertrags
|
||
Abgleich-Tabelle: §7-Punkt-Nr. ↔ §3-Prüfschritt-Zeile ↔ Fixture-Nr. (§7.1/§7.2/§7.3)
|
||
(siehe Tabelle unten im Abschnitt „Verifikations-Beleg“)
|
||
```
|
||
|
||
Diese Abgleich-Tabelle ist als „Verifikations-Beleg“ geführt (2026-08-16, Stand Validator Revision 6, Vertrag autorisiert Revision 1) und wird bei jeder künftigen Vertrags-/Validator-Änderung revalidiert.
|
||
|
||
**Manual checks (if no CLI):**
|
||
- `schema/validator.md` ist rein textuell (kein Programmcode/Executable-Abschnitt) und beginnt mit Zweck & Aufruf.
|
||
- Alle 14 Punkte aus Vertrag §7 sind als eigene Prüfschritte vorhanden; keine darüber hinausgehende Invaliditätsklasse.
|
||
- Die 8 Deferred-Work-Direktiven sind deterministisch beantwortet und in der Instruktion auffindbar.
|
||
- `wiki/log.md` enthält (nach Zertifizierung) einen datierten Eintrag „Validator-Selbstprüfung gegen Fixtures: PASS".
|
||
|
||
### Verifikations-Beleg — Vertrag↔Validator↔Fixtures-Abgleich (Stand 2026-08-16)
|
||
|
||
Revalidierung bei jeder Vertrags-/Validator-Änderung: konsistente eine-Zuordnung, keine Punkt-15, keine Lücke.
|
||
|
||
| Vertrag §7-Punkt | Validator §3-Zeile (Prüfschritt) | Fixture-Negativ (§7.1) | Fixture-Positiv (§7.2) | Anmerkung |
|
||
|---|---|---|---|---|
|
||
| 1 (Concept ohne `type`) | Z. „Punkt 1: concept ohne type…“ | Fixture 1 | Fixture 1 | |
|
||
| 2 (nicht-reservierte `.md` ohne Frontmatter/`type`) | Z. „Punkt 2: …“ | Fixture 2 | Fixtures 2, 2a | 2a: BOM/Leerzeile (AI-5) |
|
||
| 3 (`sources`→`wiki/`-Pfad) | Z. „Punkt 3: …“ | Fixture 3 | Fixture 3 | |
|
||
| 4 (`source` außerhalb `raw/`, Grammatik) | Z. „Punkt 4: …“ | Fixture 4 | Fixture 4 | |
|
||
| 5 (`status`-Wert) | Z. „Punkt 5: …“ | Fixture 5 | Fixture 5 | |
|
||
| 6 (unautorisiertes Feld / Subset) | Z. „Punkt 6: …“ | Fixture 6 | Fixture 6 | |
|
||
| 7 (leere `by`) | Z. „Punkt 7: …“ | Fixture 7 | Fixture 7 | |
|
||
| 8 (Bundleroot-Deklaration) | Z. „Punkt 8: …“ | Fixtures 8, 8a | Fixtures 8, 8b | 8a/8b: V-1/BOM |
|
||
| 9 (`okf_version`/`type:bundle` außerhalb) | Z. „Punkt 9: …“ | Fixture 9 | Fixture 9 | |
|
||
| 10 (Frontmatter in Area/`log.md`) | Z. „Punkt 10: …“ | Fixtures 10, 10a | Fixture 10 | 10a: V-2 |
|
||
| 11 (Index-Regel) | Z. „Punkt 11: …“ | Fixture 11 | Fixture 11 | Struktur-Klasse separate V/w/o §7 |
|
||
| 12 (`sources`/`verified`/`generated`-Form) | Z. „Punkt 12: …“ | Fixtures 12, 12a | Fixtures 12, 12a | |
|
||
| 13 (doppelter Key) | Z. „Punkt 13: …“ | Fixture 13 | Fixture 13 | |
|
||
| 14 (Wert-Formate) | Z. „Punkt 14: …“ | Fixtures 14, 14a, 14b, 14c | Fixtures 14, 14b, 14c, 14d | 14c/BOM-14c AI-1 |
|
||
|
||
**§6-/V-Fixtures (fachliche Prüfklassen, keine §7-Punkte):** §7.3 deckt EC-1 (Existenz), EC-3 (Kalender), stale_after-WARN (§6.4), EC-11 (non-md), V-1 (fehlende Bundleroot) und V-2 (`log.md`-Position) ab — siehe `schema/validator.md` §7.3 (Revision 6). Diese Zeilen belegen, dass die fachlichen Prüfungen nicht aus dem §7-Katalog fallen (F-02 belegt).
|
||
|
||
**Verdikt-Grammatik (F-10-Härtung):** Der Abgleich ist maschinenlesbar (Grep-Rezept oben); eine `Punkt 15`-Zeile oder ein fehlender Punkt 1–14 schlägt den Re-Check fehl (kein LLM-Urteil). Wird bei jeder Autorisierungsschleife als Pflicht-Schritt geführt (KEEP bei Re-Derivation).
|
||
|
||
- **2026-08-15, Loop 2 (Review: Blind-Hunter + Edge-Case-Hunter + Verification-Gap, kein bad_spec):** Die drei Review-Layer fanden keinen norm-beherrschenden Defekt — kein neuer Loopback. Alle Befunde waren als `patch` direkt in `schema/validator.md` lösbar (17 Patches, Revision 1→2): §3.2 Bundleroot-/Reserviert-Voraussetzungen als Nicht-§7-Pflichten, Punkt 6/9-Exemption, Punkt 9 auf Dateiinhalt, Punkt 10 BOM-Stripping, Punkt 11 deterministische Link-Prüfung (ohne Story-2.3-Vorwegnahme), Punkt 12 fehlende/leere `resource`, Punkt 14 `usage_count`-Integer-Typ, §4.3 akzeptiert `±HH:MM`, §4.4-Ausführungs-Reihenfolge mit EC-1-Aggregation, §5-WARN als Berichtskanal, §6.2 Punkt-4-vor-3-Priorität, Fixture-Ergänzungen. Drei Befunde als Deferred/Normreferenz dokumentiert (F15→Epic 4; genau-eine-Linkform→Story 2.3 mit `deferred-work.md`-Eintrag; `stale_after`-Konsequenz→Epic 3, bereits BH-8-adressiert). Abschluss: `schema/validator.md` (Revision 2) final; all 14 Punkte 1:1 abgebildet, no eigene Invaliditätsklasse.
|
||
|
||
- **KEEP (muss bei Re-Derivation überleben):** die 14-Punkte-1:1-Abbildung als mechanische Prüfschritte mit deterministischer Fehlerursache; die 8 Deferred-Work-Entscheidungen (EC-1, EC-3, BH-14, F2, BH-8, EC-11, F17, F18); Verdikt-Format SUCCESS/FAIL mit textueller Ursache (NFR-4); Abbruch-Regel (erste verletzte Bedingung); Selbstbegrenzung (abschließende Liste, keine eigene Invaliditätsklasse, kein Schreibzugriff); Positiv-/Negativ-Fixtures (AD-17h); §3.2-Voraussetzungsprüfungen ausdrücklich als Nicht-§7-Pflichten; **der strenge Vertrag↔Validator↔Fixtures-Abgleich (F-10/AI-6, Verifikations-Beleg-Tabelle) als Pflicht-Re-Check bei jeder Autorisierung**.
|
||
|
||
## Suggested Review Order
|
||
|
||
**Einstiegspunkt: Validator-Instruktion**
|
||
|
||
- Einstieg — Zweck, Aufruf-Ablauf und Ableitung vom Vertrag ¶7; höchste Hebelwirkung für das Gesamtdesign
|
||
[`validator.md:8`](../../schema/validator.md#L8)
|
||
|
||
**Normative 1:1-Abbildung (abschließende Liste §7→§3)**
|
||
|
||
- Die 14 Punkte als tabellarische mechanische Prüfschritte; Kernfrage des Reviews: keine Erweiterung/kein Streichen
|
||
[`validator.md:48`](../../schema/validator.md#L48)
|
||
|
||
- Erweiterungs-/Abschluss-Regel plus Punkt-6/9-Exemption (kein Punkt-6-vor-9-Feuer)
|
||
[`validator.md:71`](../../schema/validator.md#L71)
|
||
|
||
- Bundleroot-/Reserviert-Voraussetzungen — ausdrücklich keine neue ¶7-Klasse
|
||
[`validator.md:77`](../../schema/validator.md#L77)
|
||
|
||
**Deterministische Normalform & Toleranz**
|
||
|
||
- Listen-vs.-Absenz, fehlende optionale Felder, feste Key-Reihenfolge (F2)
|
||
[`validator.md:85`](../../schema/validator.md#L85)
|
||
|
||
- ISO-8601-Normalform inkl. `±HH:MM`-Akzeptanz (keine unautorisierte Verschärfung); Kalender-Validität
|
||
[`validator.md:100`](../../schema/validator.md#L100)
|
||
|
||
- Deterministische Rangfolge & Abbruch-Regel (erste verletzte Bedingung), EC-1-Aggregation
|
||
[`validator.md:109`](../../schema/validator.md#L109)
|
||
|
||
- `log.md`-Feingranularität (leeres Log gültig), Verdikt-Format inkl. WARN als Berichtskanal
|
||
[`validator.md:122`](../../schema/validator.md#L122)
|
||
|
||
**Fachliche Zusatzprüfungen (Deferred-Work)**
|
||
|
||
- EC-1-Existenz als Datei, EC-3-Kalender, EC-4-`stale_after`-Warnung, EC-11-non-md; Pfad-Auflösung mit Punkt-4-vor-3-Priorität
|
||
[`validator.md:149`](../../schema/validator.md#L149)
|
||
|
||
**Referenz-Fixtures & Selbstbegrenzung**
|
||
|
||
- Negativ-/Positiv-Fixtures incl. Isolations-Notiz; per AD-17h reproduzierbar prüfbar
|
||
[`validator.md:188`](../../schema/validator.md#L188)
|
||
|
||
- Normreferenzen inkl. F15/Story-2.3-Defer, Revisionslog
|
||
[`validator.md:245`](../../schema/validator.md#L245)
|
||
|
||
**Protokollierung & Status**
|
||
|
||
- Zertifizierungs-Eintrag im Bundle-Log (Vertrag §5-konform; PASS gegen Fixtures)
|
||
[`log.md:3`](../../wiki/log.md#L3)
|
||
|
||
- Story 1.4 auf `review` gesetzt (separierte `/review`-Pfad-Transition)
|
||
[`sprint-status.yaml:42`](../../_bmad-output/implementation-artifacts/sprint-status.yaml#L42)
|