Michael TamseandClaude
bb32acdf3f
Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» ist done: - spec-2-1: status review -> done + Change-Log-Eintrag - sprint-status.yaml: Story 2.1 -> done, last_updated 08-17 07:35 - wiki/log.md: done-Eintrag (Human-Review-Freigabe) - open bleibt: Action-Item code-review-2-1-item-2 (Validator-Rev 9, kein Blocker) Umsetzung der Unabhängig-Re-Run-Patches (4 Layer, 15/17): - schema/compiler.md -> Revision 1.4 (Pruefgrundlage Rev 8, §6.6-Labels §4.5/§4.2, §3.2 Kollision-Hold-Run-Fortsetzung, §5.3/§6.3 Rollback-Sequenz, Sprachkorrekturen) - wiki/index.md Baumdiagramm um Root-Concepts-Ebene - deferred-work Dedupe + n=21, review-input-dryrun Aufloesung, epic-2-context AD-4c tautologisch, validator-revision-8 status done/DoD, spec Verification Co-Authored-By: Claude <noreply@anthropic.com>
80 lines
7.1 KiB
Markdown
80 lines
7.1 KiB
Markdown
---
|
||
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: <datum>`, `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).
|