--- title: 'Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren (Option-A-Heilung Story 2.1)' type: 'authorization-round' created: '2026-08-16' status: 'done' based_on_commit: f91ef89078ee8e4c8a979cfb70f20ead1ffe854b related: - _bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md - _bmad-output/implementation-artifacts/deferred-work.md --- # Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren > **Zweck:** Heilt die offene Option-A-Voraussetzung von Story 2.1 (Review vom 2026-08-16) über den **autorisierungsfähigen** Kanal (Frieren-Prinzip wahren). `schema/validator.md` wird erst **in dieser Revision** verändert — die heute im Revisionslog als unautorisierte Notiz geführte Rev-7-Klarstellung wird damit formal getragen, die Revisionszahl im Header angehoben und die von Retrospective F-14 geforderte Negativ-Fixture ergänzt. ## Warum Revision 8 (nicht 7)? Der Revisionslog (§8) führt bereits einen Eintrag „Revision 7" (2026-08-16, Step-04-Review Story 2.1) — er ist inhaltlich korrekt, aber als **unautorisierte Mutation** in den Commit gelangt. Der Revisionslog ist append-only; die Rev-7-Notiz bleibt als Historie erhalten. Die **nächste autorisierte Revision** wird daher **Revision 8**: Ihr Logeintrag formalisiert die Rev-7-Klarstellung und die F-14-Fixture, der Header wird auf **8** angehoben (behebt damit zugleich OBS-1: Header „Revision 6" vs. Revisionslog „Revision 7"). ## Geltungsbereich **Genau eine Datei wird geändert:** `schema/validator.md`. **Unverändert (nicht anfassen):** `schema/wiki-compiler.md` (autorisiert, Story 1.3), `schema/compiler.md` (Rev 1.3, bereits committet), `raw/` (immutable, AD-3), `adapters/`, alle `wiki/`-Dateien. ## 1. F-14-Negativ-Fixture ergänzen (§7.1, Punkt 4) Retrospective F-14: Ein `resource`-Pfad, der **außerhalb `raw/` landet, aber existiert** (z. B. `README.md` an der Workspace-Root), hat kein Negativ-Fixture; §6.2 Schritt 5 deckt den Fall, §7.1-Fixtures belegen ihn nicht. **Patch:** In der §7.1-Fixture-Tabelle (nach Zeile Punkt 4, als `4a`) ergänzen: ```text | 4a | `sources: [{resource: README.md}]` (Datei `README.md` existiert an der Workspace-Root, ausserhalb `raw/`) | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)` | ``` **Isolations-Prinzip:** Sample ist sonst-valide (Punkt 3 passiert, da nicht `wiki/`; alle übrigen Punkte ok) → genau Punkt 4 löst aus. ## 2. Innen-Ebenen-Key-Subset formal tragen (§7.3 / Punkt 6) Die Rev-7-Notiz wird von „dokumentarische Klarstellung (keine Autorisierung nötig)" zur **formal getragenen Regel** dieser Revision aufgewertet: **Patch (redaktionell, §7.3-Einleitung als Teil der Revision):** Der bestehende Isolations-Hinweis zur Innen-Ebenen-Punkt-6-Abdeckung (bereits im Text vorhanden, unter der filigranen Notiz von Rev 7) wird als **ordentlicher, autorisierter Inhalt** der Revision 8 geführt — inhaltlich identisch, lediglich als legitimierter Bestandteil (nicht mehr „nur dokumentarisch"). Zusätzlich wird die Punkt-6-Prüfschritt-Zelle (§3-Tabelle, Zeile 6) um den expliziten Verweis „Innen-Ebenen: §7.3-Isolations-Notiz (autorisiert, Revision 8)" ergänzt, damit die mechanische Prüfung unzweideutig auf die Innen-Ebenen-Fälle verweist. ## 3. Validator-Header anheben (OBS-1) + Revisionslog nachführen **Patch §0-Header:** - `> **Validator-Revision:** 6` → `> **Validator-Revision:** 8` - `> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 6 — …)` → `2026-08-16 (Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisiert; Option-A-Heilung Story 2.1)` **Patch §8-Revisionslog (append-only, neuer Eintrag):** ```text - **Revision 8 (2026-08-16, Autorisations-Runde):** Option-A-Heilung Story 2.1 — drei Änderungen: (1) F-14-Negativ-Fixture 4a ergänzt (§7.1, Punkt 4: `resource` außerhalb `raw/`, aber existierend, z. B. `README.md`; Retrospective F-14); (2) Innen-Ebenen-Key-Subset-Klarstellung (Punkt 6 in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) als formal getragener Inhalt bestätigt — formalisiert die Rev-7-Notiz (die bislang als unautorisierte Mutation geführt war) und verankert den §7.3-Isolations-Hinweis als autorisierten Bestandteil; Punkt-6-Zelle um Innen-Ebenen-Verweis ergänzt; (3) Header-Revisionszahl von „Revision 6" auf „Revision 8" angehoben (behebt die pre-existing Header-Log-Diskrepanz, OBS-1). Vertrag `schema/wiki-compiler.md` unverändert (keine Vertrags-Autorisierung nötig — Punkt 6 deckt Innen-Ebenen bereits, §3.3–§3.5). ``` ## 4. Zertifizierung (Pflicht, wie bei Revisions 3–6) Gemäß Validator-Zertifizierungs-Kultur (F-02, wiki/log.md) ist die Revision **mechanisch zu belegen**: 1. **F-14-Fixture 4a isoliert:** Sample `sources: [{resource: README.md}]` mit existierender `README.md` an der Workspace-Root gegen den revidierten Validator ausführen → erwartet `FAIL … Punkt 4: resource ausserhalb raw/ …`, **kein** Vorab-FAIL durch andere Punkte. 2. **Punkt 6 Innen-Ebenen isoliert:** `sources:\n - resource: raw/prd/prd-wow20-2026-08-14.md\n role: x` gegen den revidierten Validator → erwartet `FAIL … Punkt 6: … unautorisierter Key in sources/generated/verified` (sonst-valides Sample). 3. **Regression auf das reale Bundle:** Validator-Run gegen alle 5 `wiki/`-Dateien → weiterhin **SUCCESS für alle** (keine neu ausgelösten FAILs durch die Fixture-/Hinweis-Änderung; die Revision fügt keine neue §7-Invaliditätsklasse hinzu → Abschluss-Eigenschaft gewahrt). 4. Ergebnis der Zertifizierung in `wiki/log.md` dokumentieren (datumsgruppiert, §5-Format). ## 5. Folge-Tracking nach Autorisierung Nach erfolgreicher Ausführung + Zertifizierung: 1. `sprint-status.yaml` — Action-Item `code-review-2-1-item-1-autorisierte-validator-revision-option` → `status: done`, `closed: `, `resolution:` mit Rev-8-Nummer + `ref` auf diese Datei. 2. **Story 2.1 freigeben** — in `spec-2-1-…okf-konform.md`: Re-Review-Verdikt-Absatz finalisieren („Option A erfüllt: next authorized revision = Rev 8, tragen F-14 + Innen-Ebenen + Header"), `status: in-progress → review` (Human-Review), danach `done`. 3. `sprint-status.yaml` — Story 2.1 `2-1-concepts-…`: `in-progress → review → done` (je nach Ablauf); `epic-2` bleibt `in-progress`. 4. `wiki/log.md` — Einträge für Validator-Rev-8-Zertifizierung und Story-2.1-Freigabe. 5. `deferred-work.md` — Defer/Sektion „Arbeitsauftrag" bleibt als Historie; kein Rückbau. ## Erfolgskriterien (Definition of Done dieser Runde) - [x] `schema/validator.md` trägt Revision 8: Header `8`, Revisionslog-Eintrag Rev 8, Fixture 4a, Innen-Ebenen-Verweis in Punkt-6-Zelle; §7-Katalog weiterhin abschließend (kein neuer Punkt 15). - [x] Zertifizierung 1–3 dokumentiert (Fixture 4a FAIL, Innen-Ebenen Punkt 6 FAIL, reales Bundle SUCCESS). - [x] `schema/wiki-compiler.md`, `schema/compiler.md`, `raw/`, `adapters/`, `wiki/`-Concepts unverändert (außer `wiki/log.md`-Einträge). - [x] Sprint-Tracking aktualisiert (Action-Item done, Story 2.1 `done` nach Human-Review).