mita/wow20
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
story-3-6
wow20/_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md
T
Michael TamseandClaude bb32acdf3f feat: Story 2.1 auf done setzen (Human-Review-Freigabe) + Re-Run-Patches Rev 1.4 
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>
2026-08-17 07:37:55 +02:00

7.1 KiB
Raw Permalink Blame History

title, type, created, status, based_on_commit, related
title type created status based_on_commit related
Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren (Option-A-Heilung Story 2.1) authorization-round 2026-08-16 done f91ef89078
_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:

| 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):

- **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)

  • 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).
  • Zertifizierung 1–3 dokumentiert (Fixture 4a FAIL, Innen-Ebenen Punkt 6 FAIL, reales Bundle SUCCESS).
  • schema/wiki-compiler.md, schema/compiler.md, raw/, adapters/, wiki/-Concepts unverändert (außer wiki/log.md-Einträge).
  • Sprint-Tracking aktualisiert (Action-Item done, Story 2.1 done nach Human-Review).
Reference in New Issue View Git Blame Copy Permalink