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
@@ -5,6 +5,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
||||
summary: Checksum-/Fingerprint (SHA-256) der evtl. Git-Revision der Herkunftsquelle in `source.md` aufnehmen, damit die Provenienz reproduzierbar ist.
|
||||
evidence: Blind-Hunter-Review (Finding 1/2): `source.md`-Provenienz ist ohne Fingerprint der Quelle in einem reinen Clone nicht verifizierbar; AD-3-basiertes „neue, datierte Datei"-Schema braucht einen Maschinen-Lesbaren Stand.
|
||||
status: umgesetzt (2026-08-16, Retrospective F-09/AI-4) — Commit-Hash `6cc667d` + SHA-256 der jeweiligen Herkunftsdatei in allen drei `raw/*/source.md` aufgenommen; Byte-Identität zur materialisierten Evidenz geprüft.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
||||
summary: Maschinen-lesbares, validierbares Metadaten-Schema (YAML-frontmatter) für `source.md` einführen.
|
||||
@@ -65,3 +66,35 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-1-4-schema-validierung-für-bundle-implementieren.md`
|
||||
summary: Genau-eine-erlaubte-Linkform für den Punkt-11-Index-Check festlegen (mit vs. ohne `.md`-Endung) — Story 2.3.
|
||||
evidence: Step-04-Review (Story 1.4, Loop 1): Der Validator-Punkt-11-Check akzeptiert beide Linkformen (relativer Bundle-Pfad mit oder ohne `.md`-Endung), weil die genau-eine-Form-Regel (A0-9/AD-7b) erst Story 2.3 definiert. Der Determinsmus-Anspruch des Validators bleibt gewahrt (beide Formen zählen als verlinkt); eine Endungs-Festlegung würde die abschließende §7-Liste erweitern und gehört in Story 2.3.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md`
|
||||
summary: F-03/AI-3 — gewählter Weg dokumentiert: §3.2-Voraussetzungsprüfungen als V-1/V-2-fachliche Prüfklasse (Revision 5). Die alternative Option „Vertrag §7 um Fall ‚fehlende Bundleroot' erweitern (mit Autorisierung)" wurde bewusst NICHT gewählt; sollte später ein Fall „fehlende Bundleroot" in den §7-Katalog selbst (statt als V-1) gefordert sein, ist dies nachzuholen (Vertrags-Änderung via Story-Verfahren).
|
||||
evidence: Retrospective F-03 Disposition „Fix-now (als fachliche Prüfungen V-1/V-2 labeln … oder Vertrag §7 erweitern)" — Entscheidung für Option 1 getroffen (2026-08-16, AI-3).
|
||||
|
||||
## Folge-Aufgaben aus Epic-1-Retrospective (Defer-Kontexte, AI-7; 2026-08-16)
|
||||
|
||||
> Diese Einträge sichern die von der Epic-1-Retrospective (2026-08-15) als Defer klassifizierten Befunde als konkrete Folge-Aufgaben. Sie sind **nicht** durch die Validator-Revisionen 3–6 behoben — nur als Kontext für Epic-2/3 bzw. die nächste Validator-Revision notiert.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-04)
|
||||
summary: Verschachtelte Duplikat-Keys in `sources`/`verified`-Einträgen behandeln — Punkt 13 zählt nur doppelte Keys auf oberster Frontmatter-Ebene; YAML erlaubt mehrdeutig doppelte `resource`-Keys innerhalb eines Eintrags (Parser-abhängiger Gewinner). Bei der nächsten Validator-Revision (Epic-2-Start) klären: Abdeckung der Innen-Ebenen oder bewusst dokumentierte Abgrenzung.
|
||||
evidence: Retrospective F-04.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-06)
|
||||
summary: `today`-Zeitzone für die `stale_after`-WARN (Validator §6.4) deterministisch festlegen — „heute in UTC abgeleitet" ist nicht hart definiert (Kalenderdatum des UTC-Zeitpunkts vs. lokaler Tag). Determinsmus-Anspruch (AD-17h) vor Epic-3 (Lifecycle-Konsequenz) sauber machen.
|
||||
evidence: Retrospective F-06.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-07)
|
||||
summary: Index-Regel bei verschachtelten Areas/Unter-Ebenen konkretisieren — „Area als eine `index.md` tiefer als `wiki/`" lässt für `wiki/a/b/concept.md` offen, was „Area mit Inhalt" ist. Epic-2-Story 2.5 (progressive Discovery) legt die Antwort fest; vorher gilt die heutige Definition.
|
||||
evidence: Retrospective F-07; Offene Frage 2 der Retro; spec-1-4 Story 2.3-Linkform.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-08)
|
||||
summary: Konvention für `.MD`-Großschreibung unter `wiki/` klären (Windows-Portabilität, NFR-1/NFR-5) — heute ist nur exakt `.md` (case-sensitive) ein Concept; auf win32 kann ein Tool `foo.MD` erzeugen. Vor Epic-2-Concepts entscheiden: Ablehnung/FAIL oder case-insensitive Behandlung.
|
||||
evidence: Retrospective F-08.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-11)
|
||||
summary: Normreferenz der OKF-0.2-Spezifikation verlinkbar machen (Vertrag §8, Validator §8) — das Prosa-Zitat „OKF-Spezifikation (Google Cloud, `knowledge-catalog`)" ohne URL/Version ist nicht auflösbar; `okf_version`-Regel und §7-Punkt-14 hängen daran. Kleine Korrektur bei nächster Autorisierung (Vertrag) ergänzen.
|
||||
evidence: Retrospective F-11.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-14)
|
||||
summary: Negativ-Fixture für `resource`-Pfade, die außerhalb `raw/` landen aber existieren (z. B. `README.md`) — §6.2 Schritt 5 deckt den Fall ab, aber das Durchstechen ist nur durch Beispiele belegt. Fixture bei nächster Validator-Revision ergänzen (analog §7.3).
|
||||
evidence: Retrospective F-14.
|
||||
|
||||
@@ -0,0 +1,180 @@
|
||||
---
|
||||
epic: 1
|
||||
date: 2026-08-15
|
||||
verdict: accepted-with-open-items
|
||||
criteria: profiled
|
||||
headless: false
|
||||
---
|
||||
|
||||
# Retrospective — Epic 1: Wissens-Workspace & Quellen-Aufnahme
|
||||
|
||||
## Epic-Zusammenfassung
|
||||
|
||||
- **Epic:** 1 — Wissens-Workspace & Quellen-Aufnahme
|
||||
- **Diff-Range:** `6a95d96..6cc667d` (8 Commits: 4 × `feat`, 4 × `chore` (je eine `done`-Setzung je Story))
|
||||
- **Stories:** 1.1 (Workspace-Stamm), 1.2 (Sources unter `raw/`), 1.3 (Schema-Vertrag autorisieren), 1.4 (Schema-Validierung) — alle `done`
|
||||
- **Pending-Stories:** keine (`detect-epic`: `story_count: 4`, `pending_stories: []`)
|
||||
- **Evidenz-Inventur:**
|
||||
- ✅ Epic-Spec: `epic-1-context.md`; Architecture-Spine, PRD, epics (Planung)
|
||||
- ✅ Story-Specs 1.1–1.4 (inkl. `baseline_commit` ab Story 1.3)
|
||||
- ✅ Diff-Range + per-Story-Zuordnung via `git_evidence.py`
|
||||
- ✅ Sprint-Status (`sprint-status.yaml`)
|
||||
- ✅ Keine frühere Retro, keine `action_items` im Sprint-Status
|
||||
- ⚠️ Session-Logs: **nicht vorhanden** → Prozess-Lektionen-Analyse eingeschränkt (nur aus Spec-Revisionslog & Commit-Struktur ableitbar)
|
||||
- ⚠️ Acceptance-Kriterien: nicht als eigene Liste deklariert → **profiled** aus Stories & Epic-Context
|
||||
|
||||
## Findings (Phase 2)
|
||||
|
||||
Konsolidiert aus drei Sichtlinien: Aggregat-Sichten (Diff 6a95d96..6cc667d), bmad-review-Linsen (adversarial, edge-case, verification-gap — ausgeführt als drei parallele Linsen-Agenten über den Diff/Validatoren) und der Behavior-Prüfung. Jeder Befund trägt eine Quellenreferenz; nicht belegbare Befunde wurden verworfen.
|
||||
|
||||
### F-01 (kritisch) — Validator weicht unautorisiert vom Vertrag ab: `at` als reines Datum akzeptiert, obwohl Vertrag „ISO-8601-Datetime" fordert
|
||||
|
||||
- **Befund:** `schema/validator.md` §4.3 (Z.105) und Fixture 14c (§7.2 Z.242) erklären `at: 2027-01-01` (reiner Datumswert) zu SUCCESS („normalisiert zu T00:00:00Z"). Der autorisierte Vertrag `schema/wiki-compiler.md` verlangt für `at` (§3.4 Z.76, §3.5 Z.91) „MUSS es ein ISO-8601-**Datetime** sein" und erklärt §7 Punkt 14 (Z.186) „`at` ungleich ISO-8601-Datetime" zur strukturellen Invalidität. Ein reines Datum ist kein Datetime.
|
||||
- **Quelle:** `schema/wiki-compiler.md:76,91,186` (Vertrag, autorisiert Story 1.3) vs. `schema/validator.md:105,242` (Validator, Story 1.4).
|
||||
- **Auswirkung:** Genau der vom frozen-intent verbotene Konformitätsbruch (spec-1-3: „Keine Änderung am autorisierten Vertrag"/„keine unautorisierte Verschärfung"; spec-1-4 Boundaries: „Der Validator darf keinen Eintrag hinzufügen"). Ein Validator-konformer Producer kann `at`-Datumsangaben erzeugen, die ein strikter Vertrags-Leser als strukturell invalide verwirft — die Validierung bildet die Norm nicht 1:1 ab.
|
||||
- **Disposition:** Fix-now (Re-Konsistenz: Entweder Fixture streichen/FAIL oder Vertrag neu autorisieren — Story-Verfahren).
|
||||
|
||||
### F-02 (kritisch) — §6-Fachliche-Zusatzprüfungen (EC-1, EC-3, stale_after-WARN) haben KEINE Referenz-Fixtures, obwohl sie Run-FAIL-gate sind; Validator-Zertifizierung deckt sie nicht ab
|
||||
|
||||
- **Befund:** `schema/validator.md` definiert die fachlichen Prüfungen §6 (EC-1 Existenzprüfung, EC-3 Kalender-Validität, §6.4 stale_after-WARN, §6.5 non-md) — davon sind EC-1/EC-3 **Run-FAIL-gate** (§6.1 Z.155 „fachlich invalide → Run-FAIL"). Die §7-Fixture-Tabellen (§7.1/§7.2, Z.196–243) enthalten **keine einzige** Fixture-Zeile zu diesen Checks. Der Zertifizierungs-Eintrag `wiki/log.md:4` behauptet „alle Negativ-Fixtures … alle Positiv-Fixtures" geprüft zu haben — die belegen aber nur die 14 §7-Punkte + §3.2-Voraussetzungen, nicht die §6-Checks.
|
||||
- **Quelle:** `schema/validator.md:§7.1/§7.2` (Z.196–243, keine §6-Zeilen) vs. §6.1/§6.3 (Z.153–181); `wiki/log.md:3–4` (Zertifizierungs-Claim).
|
||||
- **Auswirkung:** Ein Ausführer (Epic-2-Producer) kann EC-1/EC-3 überspringen oder falsch ausführen („Phantom-`raw/`-Pfad", falsche Kalenderdaten) und bekäme trotzdem grün — das entscheidende Gate gegen Mutation mit fehlender Evidenz ist unbelegt. AD-17h („reproduzierbar prüfbar") gilt für §6 nicht.
|
||||
- **Disposition:** Fix-now (Fixtures für §6 ergänzen; Zertifizierung neu ausführen).
|
||||
|
||||
### F-03 (kritisch) — §3.2 Voraussetzungsprüfungen sind de-facto eigenständige FAIL-Klassen, die weder in §7 noch im §5-Verdikt-Grammatik stehen
|
||||
|
||||
- **Befund:** `schema/validator.md:§3.2` (Z.77–83) führt zwei Run-FAIL-Bedingungen ein (fehlende Bundleroot, `log.md` an Nicht-Root-Position) mit Verdikt `FAIL (Struktur) …` — ohne §7-Punkt-Nr. und ohne „Fachliche Prüfung EC-x"-Label. `§5.1` (Z.141–147) und §3.1 (Z.71–75) behaupten dagegen „abschließende Liste, keine eigene Invaliditätsklasse". Der fehlende Bundleroot ist zudem **nicht** in §7 (Punkt 8 setzt eine existierende `wiki/index.md` voraus, deckt aber „fehlt ganz" nicht ab).
|
||||
- **Quelle:** `schema/validator.md:77–83,141–147`; `schema/wiki-compiler.md:§7` (kein Fall für fehlende Bundleroot).
|
||||
- **Auswirkung:** Selbstwiderspruch des „keine neue Klasse"-Selbstzeugnisses; ein mechanischer Audit („alle 14 abgebildet") schlägt fehl oder (Struktur)-Verdikte werden nicht als Run-FAIL gelesen.
|
||||
- **Disposition:** Fix-now (als fachliche Prüfungen V-1/V-2 labeln und Fixture-Label ergänzen, oder Vertrag um Fall 15 erweitern mit Autorisierung).
|
||||
|
||||
### F-04 — Duplikat-Keys nur auf oberster Frontmatter-Ebene gezählt; verschachtelte Duplikate in `sources`/`verified`-Einträgen nicht behandelt
|
||||
|
||||
- **Befund:** `schema/validator.md` §3 Punkt 13 (Z.68) und Präambel (Z.52) zählen doppelte Keys „auf oberster Frontmatter-Ebene". Doppelte `resource`-Keys innerhalb eines `sources`-Eintrags (YAML erlaubt sie mehrdeutig) sind nicht abgedeckt — mit Parser-abhängigem Gewinner und doppeldeutiger Provenienz.
|
||||
- **Quelle:** `schema/validator.md:52,68` (§3 Punkt 13, nur oberste Ebene).
|
||||
- **Disposition:** Defer (mit Kontext) — in Nachfolge-Story/Verzahnung mit Validator-Revision.
|
||||
|
||||
### F-05 — BOM-/Leerzeilen-Stripping gilt nur bei Punkt 10 (Area-index/log); Punkte 2/8 (Concept-/Bundleroot-Frontmatter-Erkennung) nicht
|
||||
|
||||
- **Befund:** Punkt 10 (Z.65) strippt BOM `U+FEFF` + führende Leerzeilen vor `---`; Punkt 2 (Z.57) und Punkt 8 (Z.63) erkennen `---` ohne Stripping — ein BOM/Leerzeile vor Concept- oder Bundleroot-Frontmatter erzeugt ein falsches Punkt-2/8-FAIL.
|
||||
- **Quelle:** `schema/validator.md:57,63,65`.
|
||||
- **Disposition:** Fix-now (Stripping-Vorgabe auf Punkte 2/8 erweitern) ODER Defer mit Kontext.
|
||||
|
||||
### F-06 — `today`-Zeitzone für stale_after-WARN nicht definiert
|
||||
|
||||
- **Befund:** §6.4 (Z.180) vergleicht `today >= stale_after` „in UTC", definiert aber nicht, wie „today" abgeleitet wird (Kalenderdatum des UTC-Zeitpunkts? lokaler Tag?). Gleicher lokaler Tag ≠ gleicher UTC-Tag nach Zeitzone.
|
||||
- **Quelle:** `schema/validator.md:180`; Vertrag §3.7 (Z.114) sagt nur „Tagesdatum `today`", ohne Zeitzonenquelle.
|
||||
- **Disposition:** Defer (mit Kontext) — Determinsmus-Anspruch ist hier nicht hart garantiert.
|
||||
|
||||
### F-07 — Punkt 11 (Index-Regel): untere Verzeichnisebenen / Areas ohne `.md`-Inhalt uneindeutig definiert
|
||||
|
||||
- **Befund:** Area wird in §2/§3 als „eine `index.md` tiefer als `wiki/`" definiert. Der Vertrag §6 verlangt „Jede Area … MUSS eine `index.md` enthalten". Bei verschachtelten Unter-Ebenen (`wiki/a/b/concept.md`) oder Verzeichnissen ohne Concept-`.md` ist unklar, was „Area mit Inhalt" ist — Punkt-11-Verletzung agent-abhängig.
|
||||
- **Quelle:** `schema/validator.md:42,66`; `schema/wiki-compiler.md:139–146`.
|
||||
- **Disposition:** Defer (Story-2.5 Voraussetzung — progressive Discovery; als offene Frage notieren).
|
||||
|
||||
### F-08 — Konvention `.MD` (Großschreibung) unter `wiki/` unbestimmt; Windows-Portabilität
|
||||
|
||||
- **Befund:** §1 Punkt 3 (Z.33) behandelt non-`.md` als Nicht-Bundle-Element, „case-sensitive kleingeschrieben". Bei Windows (Projekt läuft auf win32) kann ein Tool `foo.MD` erzeugen; wird es als Concept `.md` gewertet, failt es wegen fehlendem `type`. Konvention für Großschreibung fehlt.
|
||||
- **Quelle:** `schema/validator.md:33`; NFR-1/NFR-5 (Portabilität).
|
||||
- **Disposition:** Defer (mit Kontext) — vor Epic-2-Concepts klären.
|
||||
|
||||
### F-09 — Provenienz-Sidecars (`source.md`) behaupten fälschlich, `_bmad-output/` sei „im Repo nicht versioniert"
|
||||
|
||||
- **Befund:** `raw/prd/source.md:14`, `raw/architecture-spine/source.md:13`, `raw/epics/source.md:13` behaupten, Herkunftspfade unter `_bmad-output/` seien „nicht versioniert". Tatsächlich sind die Herkunftsartefakte versioniert: `git ls-files _bmad-output` listet `planning-artifacts/prds/.../prd.md`, `planning-artifacts/epics.md`, `ARCHITECTURE-SPINE.md`. `.gitignore` enthält keinen `_bmad-output/`-Eintrag.
|
||||
- **Quelle:** `raw/*/source.md:13–14`; `git ls-files _bmad-output` (23 Dateien); `.gitignore`.
|
||||
- **Auswirkung:** Provenienz-Aussage ist faktisch falsch; ein Nachvollzieher kann die Herkunft nicht als feste Referenz nutzen, und ein späterer Verifikationsschritt (Deferred-Work Finding 1/2, Checksumme) widerspricht der Dokumentation.
|
||||
- **Disposition:** Fix-now (Zeile korrigieren — Quellen sind versioniert; Reproduktionshinweis auf Commit-Hash stützen) + Deferred-Work-Checksumme als Konsequenz.
|
||||
|
||||
### F-10 — Verifikation des Validators ist dokumentarisch, nicht ausführbar: keine Testdatei, kein CI, kein Haken
|
||||
|
||||
- **Befund:** Kein Testfile unter `schema/`/`wiki/`, kein `.github/`, keine Haken (nur `.sample`), kein Makefile/CI. Die Spec-Verification-Greps (spec-1-4:111–119) sind Existenz-/Mentions-Greps, die einen semantischen Drift nicht fangen (z. B. `grep -cE '\bFAIL\b|\bSUCCESS\b'` zählt auch Prosa-Labels). `baseline_commit` (spec-1-3:7, spec-1-4:6) wirkt nur review-zeitlich, nicht als Re-Run-Guard.
|
||||
- **Quelle:** `git ls-files | grep -i test` (keine Tests); `ls .github` (fehlt); `git log --oneline -- schema/wiki-compiler.md schema/validator.md` (Validator nur in c5f97c3, Vertrag in 2625e1d+9e163ad); `_bmad-output/implementation-artifacts/spec-1-4-...md:107–119`.
|
||||
- **Auswirkung:** F-01/F-02 konnten unentdeckt durch die „Zertifizierung" kommen (PASS-Claim in `wiki/log.md:4`); eine Vertragsänderung würde stillen Drift unentdeckt lassen.
|
||||
- **Disposition:** Fix-now (Prozess-/Verifikations-Lektion: ausführbares Fixture-Orakel oder zumindest Abgleich-Schritt Vertrag↔Validator je Autorisation).
|
||||
|
||||
### F-11 — Vertrags-Referenz auf OKF-0.2-Spezifikation nicht verlinkbar (Prosa-Zitat), Normquelle nicht reproduzierbar
|
||||
|
||||
- **Befund:** `schema/wiki-compiler.md:§8` (Z.195) und `schema/validator.md:251` zitieren „OKF-Spezifikation (Google Cloud, `knowledge-catalog`)" ohne URL/Version — die `okf_version`-Regel und §7 Punkt 14 hängen an dieser Quelle, die nicht auflösbar ist.
|
||||
- **Quelle:** `schema/wiki-compiler.md:195`; `schema/validator.md:251`.
|
||||
- **Disposition:** Defer (Normreferenz ergänzen) — kleine Korrektur.
|
||||
|
||||
### F-12 — Adapter-Konformität (AD-10) wird vom Validator nicht geprüft, obwohl Vertrag sie als MUSS normiert
|
||||
|
||||
- **Befund:** Der Vertrag verlangt `adapters/` MÜSSEN mit dem Vertrag konform sein (AD-10, Z.18); der Validator (§1 Z.30–33) erklärt `adapters/` als „nicht validiert". Kein Prüfschritt deckt die Adapter-Semantik ab.
|
||||
- **Quelle:** `schema/wiki-compiler.md:18`; `schema/validator.md:30–33`.
|
||||
- **Disposition:** Accept-as-is (dokumentierte Abgrenzung des Validators auf Bundles; Adapter-Konformität ist Chef-/Review-Verantwortung) — als akzeptierte Abweichung festhalten, damit spätere Retros nicht re-flaggen.
|
||||
|
||||
### F-13 — `sources`-Eintrag ohne `resource` ist als „Punkt 12"-FAIL klassifiziert, obwohl Vertrag-Punkt 12 primär Formverstöße listet
|
||||
|
||||
- **Befund:** `schema/wiki-compiler.md` §7 Punkt 12 (Z.184) nennt Formverstöße (Liste/Map/Skalar); ein Eintrag ohne `resource` ist eine valide Map ohne Pflichtangabe. Der Validator ordnet ihm Punkt 12 zu (Fixture 12a, Z.212). Die Zuordnung ist vertretbar („in nicht erlaubter Form"), aber nicht ausdrücklich im Vertrags-Wortlaut verankert.
|
||||
- **Quelle:** `schema/wiki-compiler.md:184`; `schema/validator.md:67,212`.
|
||||
- **Disposition:** Accept-as-is (interpretationsgetragen, dokumentiert in validators §3 Punkt 12 mit Vertrags-Verweis §3.3) — kein Fix-now, aber als Beobachtung für die Re-Konsistenz bei F-01 mitnehmen.
|
||||
|
||||
### F-14 — `resource`-Pfade, die außerhalb `raw/` landen aber existieren (z. B. `README.md`), haben kein Negativ-Fixture
|
||||
|
||||
- **Befund:** §6.2 Schritt 5 (Z.168) deckt „nicht unter `raw/`" ab, aber es fehlt ein Negativ-Fixture für diesen Fall; Determinsmus ist nur durch Beispiele belegt.
|
||||
- **Quelle:** `schema/validator.md:168` vs. §7.1 (Z.196–216, kein Fall außerhalb raw ohne Traversal).
|
||||
- **Disposition:** Defer (mit Kontext) — Fixture-Ergänzung bei nächster Validator-Revision.
|
||||
|
||||
### F-15 — `stale_after`-Lebenszyklus-Konsequenz (Epic 3) hat keine Verankerung im Deferred-Work-Zeitplan
|
||||
|
||||
- **Befund:** §6.4 (Z.181) verweist auf „Epic 3" für die Konsequenz der Veraltung; `deferred-work.md` listet die BH-8-Ableitung (Z.29–31), ohne konkrete Story-Zuordnung.
|
||||
- **Quelle:** `schema/validator.md:181`; `_bmad-output/implementation-artifacts/deferred-work.md:29–31`.
|
||||
- **Disposition:** Accept-as-is (Epic-3-Gate mit Story-Autorisierung ist vorgesehen; reichen als Verankerung) — als Beobachtung notieren.
|
||||
|
||||
## Behavior-Verifikation (Phase 2)
|
||||
|
||||
**Methodik:** Das Bundle wurde gegen die Validator-Instruktion (Story 1.4) deterministisch ausgeführt (jede §7-/§6-Bedingung als mechanische Prüfung). Ergebnis:
|
||||
|
||||
- **Punkt 8 (Bundleroot):** `wiki/index.md` trägt exakt `type: bundle` + `okf_version: "0.2"`, kein weiteres Feld → PASS.
|
||||
- **Punkt 9 (Exklusivität):** `grep -rn "okf_version\|type: bundle" wiki/` → nur `wiki/index.md` → PASS.
|
||||
- **Punkt 10 (Frontmatter-Exklusivität):** keine Area-`index.md`/`log.md` beginnt mit `---` → PASS.
|
||||
- **Punkt 11 (Index-Regel):** keine Areas vorhanden → nicht auslösbar → PASS (leeres Bundle).
|
||||
- **Concept-Prädikat:** keine Concepts im Bundle → keine Punkt-1/2-Auslöser.
|
||||
- **§3.2-Voraussetzungen:** `wiki/index.md` existiert; kein `log.md` an Nicht-Root-Position → PASS.
|
||||
- **§6.1 EC-1 Existenz:** alle drei `raw/`-Evidenz-Dateien existieren (verifiziert) → PASS (keine Concepts, keine `resource`-Referenzen zu prüfen).
|
||||
- **§6.5 non-md:** keine non-.md-Dateien unter `wiki/` → keine Verletzung.
|
||||
|
||||
**Geprüft-als-sauber:** Die 14 Strukturpunkte und §3.2 sind am realen Bundle zufriedenstellend. Der Lauf deckt aber nur das **leere** Bundle (keine Areas/Concepts) — die eigentliche Validator-Abbildung (F-01 bis F-08) ist anhand der Fixtures statisch geprüft, nicht durch dynamische Fixture-Ausführung. Die §6-Fixtures fehlen (F-02), daher ist die Run-FAIL-Gate-Fähigkeit des Validators für die fachlichen Checks am echten Bundle **nicht** dynamisch bestätigt.
|
||||
|
||||
## Previous-Retro-Follow-through
|
||||
|
||||
Keine frühere Retrospektive vorhanden; Sprint-Status enthält keine `action_items` → nichts nachzuverfolgen.
|
||||
|
||||
## Action Items (Phase 4)
|
||||
|
||||
Vorschläge — werden **nicht** automatisch angewendet; der Mensch entscheidet, was ausgeführt wird.
|
||||
|
||||
| ID | Aktion | Eigentümer | Quelle |
|
||||
|----|--------|-----------|--------|
|
||||
| AI-1 | Validator `schema/validator.md` mit autorisiertem Vertrag re-konsistieren: Fixture 14c/§4.3 (`at` als reines Datum = SUCCESS) beseitigen oder als bewusste Toleranz via Story-Verfahren neu autorisieren (Änderung §3.4/§3.5/§7-Punkt-14 des Vertrags) — damit die 1:1-Abbildung wieder gilt | Story-Verfahren (Dev+Review) | F-01 |
|
||||
| AI-2 | $6-Fixtures ergänzen: EC-1 (Negativ: fehlende `raw/`-Datei; Positiv: vorhandene), EC-3 (Kalender-Validität), stale_after-WARN-Kanal, EC-11 non-md — und Validator-Zertifizierung in `wiki/log.md` gegen erweiterte Fixtures neu ausführen | Dev (Story 1.4-Follow-up) / Review | F-02 |
|
||||
| AI-3 | §3.2-Voraussetzungspflejesten als „Fachliche Prüfung V-1/V-2" labeln (statt „FAIL (Struktur)" außerhalb §5-Grammatik) oder Vertrag §7 um Fall „fehlende Bundleroot" erweitern (mit Autorisierung) | Dev (Validator-Revision) | F-03 |
|
||||
| AI-4 | `source.md`-Provenienz korrigieren: `_bmad-output/` IST versioniert (Herkunft auf Commit-Hash stützen) — Fix in `raw/<quelle>/source.md:13–14`; Deferred-Work-Checksumme (SHA-256) als Konsequenz voranbringen | Dev (Story-1.2-Follow-up) | F-09 |
|
||||
| AI-5 | BOM-/Leerzeilen-Stripping von Punkt 10 auf Punkte 2/8 erweitern (einheitliche Frontmatter-Erkennung) | Dev (Validator-Revision) | F-05 |
|
||||
| AI-6 | Ausführbare/mechanische Verifikation des Validators einführen (Fixture-Orakel-Skript oder zumindest Vertrag↔Validator-Abgleich je Autorisation) — minimiert Wiederauftreten von F-01/F-02 | Prozess (BMAD-Dev-Schleife) | F-10 |
|
||||
| AI-7 | Defer-Kontexte sichern: F-04 (verschachtelte Duplikat-Keys), F-06 (`today`-Zeitzone), F-07 (Index-Regel bei verschachtelten Areas), F-08 (`.MD`-Großschreibung), F-11 (OKF-Referenz-URL), F-14 (`raw/`-extern-Fixture) — als Folge-Aufgaben für Epic-2/3 oder Validator-Revision notieren | Epic-2/3-Planung | F-04…F-15 |
|
||||
|
||||
Keine Zeitangaben — bewusst.
|
||||
|
||||
## Acceptance-Verdict (Phase 4)
|
||||
|
||||
**Verdikt: `accepted-with-open-items`**
|
||||
**Kriterien:** profiled (keine deklarative Akzeptanzliste; aus Story-Intent + Epic-Context + Vertrag §7/§8 abgeleitet).
|
||||
|
||||
**Begründung:**
|
||||
- Alle 4 Stories sind `done`; `pending_stories` leer → kein Rejected-Zwang.
|
||||
- Die deklarierten Ziele sind im Wesentlichen erreicht: Workspace-Stamm (Stories 1.1/1.2) korrekt etabliert, `raw/`-Evidenz byte-identisch materialisiert und immutable (verifiziert), Vertrag autorisiert (1.3), Validator-Instruktion liegt vor und bildet die 14 Punkte 1:1 ab (1.4).
|
||||
- **Aber:** Drei Befunde (F-01, F-02, F-03) betreffen die Kern-Fähigkeit „Deterministische Validierung bildet die Norm 1:1 ab und ist reproduzierbar prüfbar" (AD-17h, F-2/AD-1b). F-01 ist ein unautorisierter Bruch mit dem Vertrag, F-02/F-03 sind Verifikations-/Klassenlücken. Die ist ein dokumentierter, nicht-blokkierender Rest, der als offene Items (AI-1…AI-3) adressiert wird.
|
||||
- Kein Blocker für nachfolgende Epics: Epic 2 kann mit dem heutigen Validator Concepts validieren (die 14 Strukturpunkte sind abgedeckt). Die F-Items sind Follow-ups, kein Stop.
|
||||
- Menschliche Bestätigung: Keine — Verdikt ist eine Maschinen-/Analysten-Entscheidung. Ein Mensch darf es überstimmen.
|
||||
|
||||
## Offene Fragen
|
||||
|
||||
1. **F-01 entgegen dem frozen-intent:** Ist die `at`-als-Datum-Toleranz als bewusste Vertragserweiterung gewollt (dann Story-Autorisierung) oder ein Review-Schlupf? Die Antwort ändert, ob der Vertrag oder der Validator zu ändern ist.
|
||||
2. **F-07 (Index-Regel):** Wie tief sollen Areas/Unterordner gehen? Epic-2 legt die Antwort fest (Story 2.5 progressive Discovery).
|
||||
3. **Verifikations-Tiefe:** Soll das Projekt zu einem ausführbaren Fixture-Orakel wechseln (D-3 erlaubt nur Instruktionen — ein Orakel würde die D-3-Grenze berühren)? Oder bleibt es beim dokumentarischen Abgleich?
|
||||
|
||||
## Assumptions
|
||||
|
||||
Interaktiver Lauf: keine headless-Annahmen. Der Epic wurde aus `detect-epic` bestätigt (höchstes Epic mit `done`-Story); der Nutzer wurde eingangs um Going-in-Themen gebeten (keine Rückmeldung — Analyse lief ohne Zusatzgewicht).
|
||||
+40
-1
@@ -112,15 +112,54 @@ Wichtige Normalform-Entscheidungen (aus Deferred-Work):
|
||||
- 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.
|
||||
- **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
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
|
||||
# - Retrospective appends its action items to action_items; the status view surfaces open ones
|
||||
generated: 08-14-2026 00:00
|
||||
last_updated: 08-15-2026
|
||||
last_updated: 08-16-2026 10:30
|
||||
project: wow20
|
||||
project_key: NOKEY
|
||||
tracking_system: file-system
|
||||
@@ -40,7 +40,7 @@ development_status:
|
||||
1-2-sources-lokal-unter-raw-bereitstellen: done
|
||||
1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren: done
|
||||
1-4-schema-validierung-für-bundle-implementieren: done
|
||||
epic-1-retrospective: optional
|
||||
epic-1-retrospective: done
|
||||
|
||||
epic-2: backlog
|
||||
2-1-concepts-aus-source-material-erzeugen-okf-konform: backlog
|
||||
@@ -73,3 +73,79 @@ development_status:
|
||||
5-2-tool-unabhängigen-zugriff-und-agent-lesbarkeit-gewährleisten: backlog
|
||||
5-3-agent-unabhängige-compiler-regeln-dünne-adapter: backlog
|
||||
epic-5-retrospective: optional
|
||||
action_items:
|
||||
- id: "epic-1-retro-item-1-validator-schema-validator-md-mit-autori"
|
||||
epic: 1
|
||||
action: "Validator schema/validator.md mit autorisiertem Vertrag re-konsistieren:
|
||||
at-als-reines-Datum-Toleranz (§4.3/Fixture 14c) beseitigen oder via Story-Verfahren
|
||||
als Vertrags-Aenderung neu autorisieren"
|
||||
owner: "dev+review"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
resolution: "Option A (Nutzer): Toleranz rueckgaengig — at MUSS volles ISO-8601-Datetime
|
||||
sein; reines Datum => FAIL Punkt 14. schema/validator.md Revision 3; Vertrag unveraendert."
|
||||
ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-01"
|
||||
- id: "epic-1-retro-item-2-6-fixtures-ergaenzen-ec-1-existenz-ec-3"
|
||||
epic: 1
|
||||
action: "§6-Fixtures ergaenzen (EC-1 Existenz, EC-3 Kalender, stale_after-WARN-Kanal,
|
||||
EC-11 non-md) und Validator-Zertifizierung in wiki/log.md gegen erweiterte Fixtures
|
||||
neu ausfuehren"
|
||||
owner: "dev"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
resolution: "Neue Fixture-Tabelle schema/validator.md §7.3 (EC-1, EC-3, WARN, EC-11);
|
||||
Validator auf Revision 4; Zertifizierung in wiki/log.md nachgefuehrt."
|
||||
ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-02"
|
||||
- id: "epic-1-retro-item-3-3-2-voraussetzungspruefungen-als-fachlic"
|
||||
epic: 1
|
||||
action: "§3.2-Voraussetzungspruefungen als Fachliche Pruefung V-1/V-2 labeln oder
|
||||
Vertrag §7 um Fall fehlende Bundleroot erweitern (mit Autorisierung)"
|
||||
owner: "dev"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
resolution: "Label-Ansatz gewaehlt: §3.2 als V-1/V-2 fachliche voraussetzungspruefung;
|
||||
FAIL (Voraussetzung) ... (V-1|V-2); Fixtures in §7.1/§7.3; Vertrag unveraendert."
|
||||
ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-03"
|
||||
- id: "epic-1-retro-item-4-source-md-provenienz-korrigieren-_bmad-o"
|
||||
epic: 1
|
||||
action: "source.md-Provenienz korrigieren: _bmad-output/ ist versioniert; Herkunft
|
||||
auf Commit-Hash stuetzen und Deferred-Work-Checksumme (SHA-256) voranbringen"
|
||||
owner: "dev"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
resolution: "raw/*/source.md korrigiert; Herkunft auf Commit 6cc667d + SHA-256 gestuetzt
|
||||
(byte-identisch zur Evidenz); Deferred-Work-Checksumme damit vorangebracht/umgesetzt."
|
||||
ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-09"
|
||||
- id: "epic-1-retro-item-5-bom-leerzeilen-stripping-von-punkt-10-au"
|
||||
epic: 1
|
||||
action: "BOM-/Leerzeilen-Stripping von Punkt 10 auf Punkte 2/8 der Validator-Instruktion
|
||||
erweitern (einheitliche Frontmatter-Erkennung)"
|
||||
owner: "dev"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
resolution: "Gemeinsame gestrippte Frontmatter-Erkennung in §3-Praaembel; Punkte 2/8/10
|
||||
nutzen sie; Positiv-Fixtures 2a/8b ergaenzt; Revision 6; Vertrag unveraendert."
|
||||
ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-05"
|
||||
- id: "epic-1-retro-item-6-ausfuehrbare-mechanische-verifikation-de"
|
||||
epic: 1
|
||||
action: "Ausfuehrbare/mechanische Verifikation des Validators einfuehren (Fixture-Orakel
|
||||
oder Vertrag↔Validator-Abgleich je Autorisation)"
|
||||
owner: "process"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
resolution: "Konsistenz-Abgleich (Nutzer): strenger Vertrag↔Validator↔Fixtures-Abgleich
|
||||
(14 Punkte/keine Punkt 15) als Pflicht-Re-Check in spec-1-4-Verification; bleibt in
|
||||
D-3 (kein Standalone). Verifikations-Beleg-Tabelle ergaenzt."
|
||||
ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-10"
|
||||
- id: "epic-1-retro-item-7-folge-aufgaben-fuer-epic-2-3-sichern-ver"
|
||||
epic: 1
|
||||
action: "Folge-Aufgaben fuer Epic-2/3 sichern: verschachtelte Duplikat-Keys, today-Zeitzone,
|
||||
Index-Regel bei verschachtelten Areas, .MD-Grossschreibung, OKF-Referenz-URL,
|
||||
raw/-extern-Fixture"
|
||||
owner: "epic-2/3-planung"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
resolution: "F-04/F-06/F-07/F-08/F-11/F-14 als Defer-Kontexte in deferred-work.md (append-only)
|
||||
mit Epic-/Validator-Zuordnung notiert; F-06/F-08 zusaetzlich im Validator Rev. 6 als
|
||||
'Offene Punkte' verankert."
|
||||
ref: "_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md#F-04"
|
||||
|
||||
@@ -10,5 +10,6 @@ Materialisiert als Quelle unter `raw/` (Story 1.2, AD-12).
|
||||
## Provenienz-Hinweis
|
||||
|
||||
- Diese `source.md` ist ein Artefakt, **keine Evidenz** (vgl. `raw/README.md`).
|
||||
- Herkunftspfade unter `_bmad-output/` sind generierte Planungs-Artefakte und im Repo nicht versioniert — Reproduktionshinweis, keine feste Referenz.
|
||||
- Die Herkunftsquelle unter `_bmad-output/planning-artifacts/` ist **versioniert** (Git-Repo, `git ls-files` bestätigt die Datei) und damit als feste Referenz nachvollziehbar. Reproduzierbarer Stand: Commit `6cc667d` (`6cc667dd55aad54cb53b77e862732a66e1382000`).
|
||||
- **SHA-256 der Herkunftsdatei** (byte-identisch zur materialisierten Evidenz, geprüft 2026-08-16): `4f4625954e64a11bd158675ff23be5a2c33a8a4b4d981c4777ae1040752e3c4e`
|
||||
- Ändert sich die Herkunftsquelle, wird eine **neue, datierte Datei** angelegt (AD-3); diese Datei bleibt unverändert.
|
||||
|
||||
+2
-1
@@ -10,5 +10,6 @@ Materialisiert als Quelle unter `raw/` (Story 1.2, AD-12).
|
||||
## Provenienz-Hinweis
|
||||
|
||||
- Diese `source.md` ist ein Artefakt, **keine Evidenz** (vgl. `raw/README.md`).
|
||||
- Herkunftspfade unter `_bmad-output/` sind generierte Planungs-Artefakte und im Repo nicht versioniert — Reproduktionshinweis, keine feste Referenz.
|
||||
- Die Herkunftsquelle unter `_bmad-output/planning-artifacts/` ist **versioniert** (Git-Repo, `git ls-files` bestätigt die Datei) und damit als feste Referenz nachvollziehbar. Reproduzierbarer Stand: Commit `6cc667d` (`6cc667dd55aad54cb53b77e862732a66e1382000`).
|
||||
- **SHA-256 der Herkunftsdatei** (byte-identisch zur materialisierten Evidenz, geprüft 2026-08-16): `3b8e0da47a7db0d92e78972747b8efcb230400eb37cfd607554e7eaeb57d04fa`
|
||||
- Ändert sich die Herkunftsquelle, wird eine **neue, datierte Datei** angelegt (AD-3); diese Datei bleibt unverändert.
|
||||
|
||||
+2
-1
@@ -11,5 +11,6 @@ Materialisiert als Quelle unter `raw/` (Story 1.2, AD-12).
|
||||
## Provenienz-Hinweis
|
||||
|
||||
- Diese `source.md` ist ein Artefakt, **keine Evidenz** (vgl. `raw/README.md`).
|
||||
- Herkunftspfade unter `_bmad-output/` sind generierte Planungs-Artefakte und im Repo nicht versioniert — Reproduktionshinweis, keine feste Referenz.
|
||||
- Die Herkunftsquelle unter `_bmad-output/planning-artifacts/` ist **versioniert** (Git-Repo, `git ls-files` bestätigt die Datei) und damit als feste Referenz nachvollziehbar. Reproduzierbarer Stand: Commit `6cc667d` (`6cc667dd55aad54cb53b77e862732a66e1382000`).
|
||||
- **SHA-256 der Herkunftsdatei** (byte-identisch zur materialisierten Evidenz, geprüft 2026-08-16): `68e711759e405d3274b77b829db69cc432fd078652a6042e0fcd1889cab0897d`
|
||||
- Ändert sich die Herkunftsquelle, wird eine **neue, datierte Datei** angelegt (AD-3); diese Datei bleibt unverändert.
|
||||
|
||||
+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.
|
||||
|
||||
@@ -1,4 +1,13 @@
|
||||
# Log
|
||||
|
||||
## 2026-08-16
|
||||
- Retrospective-Follow-up (AI-1/F-01): `schema/validator.md` auf Revision 3 — `at`-Nur-Datum-Toleranz zurückgenommen. `at: 2027-01-01` ist jetzt FAIL nach Punkt 14 (reine Datumsangabe ≠ ISO-8601-Datetime); Positiv-Fixture 14c neu mit `±HHMM`-Form (`+0200`) belegt. Vertrag `schema/wiki-compiler.md` unverändert (autorisiert). Validator-Zertifizierung zugehörig geprüft: Fixture 14c (Negativ) erzeugt FAIL.
|
||||
- Retrospective-Follow-up (AI-2/F-02): `schema/validator.md` auf Revision 4 — neue Fixture-Tabelle §7.3 für die §6-Fachprüfungen (EC-1 Existenz, EC-3 Kalender, stale_after-WARN, EC-11 non-md). Zertifizierung gegen erweiterte Fixtures selbstgeprüft — Ergebnis: PASS (je §6-Fixture isoliert geprüft, genau die angesprochene Prüfung löst aus; EC-1/EC-3-FAILs sind Run-FAIL, WARN ist Berichtskanal, non-md wird ignoriert ohne Verdikt).
|
||||
- Retrospective-Follow-up (AI-3/F-03): `schema/validator.md` auf Revision 5 — §3.2-Voraussetzungsprüfungen als fachliche Prüfklasse V-1/V-2 gelabelt (Verdikt `FAIL (Voraussetzung) … (V-1|V-2)` statt `FAIL (Struktur)`), §5-Grammatik/Selbstbegrenzung sowie §7.1/§7.3-Fixtures angeglichen. Zertifizierung: V-1/V-2-Fixtures selbstgeprüft — PASS (isolierte Auslösung; kein §7-Punkt-Nr.-Konflikt).
|
||||
- Retrospective-Follow-up (AI-4/F-09): `raw/*/source.md`-Provenienz korrigiert — `_bmad-output/` IST versioniert; Herkunft auf Commit `6cc667d` gestützt und SHA-256 der Herkunftsdatein aufgenommen (byte-identisch zur materialisierten Evidenz, geprüft).
|
||||
- Retrospective-Follow-up (AI-5/F-05): `schema/validator.md` auf Revision 6 — BOM-/Leerzeilen-Stripping der Frontmatter-Erkennung von Punkt 10 auf Punkte 2/8 ausgedehnt (einheitliche §3-Präambel). Zertifizierung: neue Positiv-Fixtures 2a/8b (BOM + Leerzeile vor `---`) → SUCCESS; geprüft gegen isolierte Samples — PASS.
|
||||
- Retrospective-Follow-up (AI-7): Defer-Kontexte gesichert — F-04, F-06, F-07, F-08, F-11, F-14 als Folge-Aufgaben in `deferred-work.md` notiert (mit Epic-2/3/Validator-Zuordnung); F-06/F-08 zusätzlich als „Offene Punkte" direkt im Validator (Rev. 6) verankert.
|
||||
- Retrospective-Follow-up (AI-6/F-10): Mechanische Validator-Verifikation nachgeschärft — spec-1-4-Verification enthält jetzt einen strengen, deterministischen Vertrag↔Validator↔Fixtures-Abgleich (14 Punkte, keine Punkt 15, Verifikations-Beleg-Tabelle) als Pflicht-Re-Check bei jeder Autorisierung. Bleibt innerhalb der D-3-Grenze (kein Standalone-Programm); dokumentarisch-mechanisch statt Existenz-Grep.
|
||||
|
||||
## 2026-08-15
|
||||
- Validator-Zertifizierung: `schema/validator.md` (Revision 2) gegen die Referenz-Fixtures (§7) selbstgeprüft — Ergebnis: PASS (alle Negativ-Fixtures erzeugen FAIL, alle Positiv-Fixtures SUCCESS; maschinenlesbares Verdikt gemäß §5 bestätigt). Jede Negativ-Fixture wird je Fixture isoliert gegen ein sonst-valides Sample geprüft, sodass genau ihr zugehöriger Punkt auslöst (kein Vorab-FAIL durch andere Punkte).
|
||||
|
||||
Reference in New Issue
Block a user