chore: Sandbox-Dryrun (PDF/RADIUM) als Review-Input sichern + Folge-Eintraege

Review-Input fuer Story 2.1: Probelauf in D:\mita\wow-2nd-sandbox mit
Compiler Rev 1.3 gegen raw/MetaModel.pdf (11 radium-Concepts OKF-konform,
R-2 praktisch belegt). review-input-dryrun-2-1-pdf-radium.md: belegte
Fakten, korrigierter Punkt-11-Befund (Identity-Match in index.md des
naechsten Vorfahren statt absoluter Pfadaufloesung - Tooling-Defekt,
kein Instruktions-Defekt), Zuordnung der Optimierungs-Massnahmen (P1/P2/P3).

deferred-work.md: Folge-Eintraege aus dem Sandbox-Dryrun (P1: Validator-
Fixture-Selbsttest, .compile-run/-Konvention, einmaliges at pro Run; P2:
Pre-Run-Reconcile-Vorphase, Provenienz-Checksumme -> Story 2.2/Epic 3).
Arbeitsauftrag Option-A (F-14/innen-Ebenen/OBS-1) als umgesetzt markiert
(Validator-Revision 8, 2026-08-17).

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Michael Tamse
2026-08-17 06:10:36 +02:00
co-authored by Claude
parent e6c36fc6d9
commit ae5e0aa71f
2 changed files with 116 additions and 0 deletions
@@ -143,3 +143,28 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
- summary: **2. Innen-Ebenen-Key-Subset-Klarstellung formal tragen** — die heute als unautorisierte Rev-7-Notiz in `validator.md` §7.3 (Punkt 6: unautorisierte Keys innerhalb `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) liegende Klarstellung wird Teil der autorisierten Revision; damit verliert sie ihren Status als unautorisierte Mutation und Story 2.1 ist `done`-fähig. (Kann mit F-14 in einer gemeinsamen Revision laufen.)
- summary: **3. Validator-Header-Revisionszahl anheben (OBS-1)**`schema/validator.md` §0-Header trägt weiter „Validator-Revision: 6", während der Revisionslog (§8) als letzten Eintrag „Revision 7" führt (pre-existing Selbst-Inkonsistenz). In derselben autorisierten Revision den Header auf die dann aktuelle Revisionszahl anheben — damit schließt sich die von compiler.md §0/§8 auf „Revision 7" referenzierte Kette header-seitig. (Korrektur jetzt nicht möglich, da `validator.md` friert.)
evidence: Re-Review (Code Review Story 2.1), 2026-08-16 — Option-A-Home-Story; Epic-1-Retrospective F-14/AI-7 (Defer-Kontexte, deferred-work.md).
status: umgesetzt (2026-08-17) — siehe autorisierte Validator-Revision 8 (`validator-revision-8-autorisationsrunde-f14-innen-ebenen.md`): F-14-Fixture 4a, Innen-Ebenen-Klarstellung formal getragen, Header auf „Revision 8" angehoben (OBS-1 behoben); Story 2.1 damit `done`-fähig.
## Folge-Einträge aus dem Sandbox-Dryrun (PDF/RADIUM, Prozess-Optimierungs-Bericht; 2026-08-17)
> **Herkunft:** Nutzer-Probelauf in `D:\mita\wow-2nd-sandbox` (Compiler Rev 1.3 gegen `raw/MetaModel.pdf`, 11 radium-Concepts OKF-konform als positivem R-2-Beleg ausgeführt) — siehe `review-input-dryrun-2-1-pdf-radium.md` im selben Verzeichnis. Der Bericht (vom Nutzer erstellt) enthält Tooling-/Prozess-Optimierungs-Maßnahmen (P1/P2/P3) **auf Ausführungs-/Werkzeug-Ebene**, keine Norm-Änderungen (D-3). Diese Einträge sichern die Folge-Aufgaben; die detaillierte Zuordnung (inkl. Konformitäts-Bewertung) steht im Review-Input-Dokument.
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
summary: Fixture-Selbsttest des Validator-Prüfwerkzeugs vor jedem Bundle-Lauf etablieren (P1) — jede Negativ-Fixture (`validator.md` §7.1, n=17) muss ein deterministisches FAIL mit Ursache erzeugen, jede Positiv-Fixture (§7.2/§7.3, ~20) SUCCESS; optional die „Skript-Fallen" (PyYAML-`datetime`-Parsing statt Textform §4.3, relative Link-Auflösung Punkt 11, `usage_count`-Float) als eigene Negativ-Fixtures ergänzen. Nutzen: Fehler des Prüfwerkzeugs werden vor Berührung des Bundles sichtbar (im Probelauf 2 Diagnose-Zyklen durch Falsch-FAILs des Prüfskripts vermeidbar). D-3-tauglich (rein textueller Check-Block, kein Standalone).
evidence: Prozess-Optimierungs-Bericht §3.1/§4.1 (Tooling-Diagnose-Zyklen, Punkt-11-Identity-Match; korrigiert: kein Instruktions-Defekt); Review-Input §2/§4 (Konformität: D-3/AD-17h).
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
summary: Feste `.compile-run/`-Arbeitskonvention einführen (P1) — vom Workspace getragene, per Konvention (.gitignore) ausgeschlossene Fläche für deterministische Textextraktion der Quelle (z. B. `sources-<quelle>-<datum>.txt`), Prüfskripte (inkl. Fixture-Selbsttest) und `run-protokoll.md` (Prüfsummen, Verlinkungs-Check, Verdikte je Run). Nutzen: Reproduzierbarkeit/Auditierbarkeit (AD-17h) ohne `raw/` zu berühren (AD-3), agent-übergreifend gleiche Konvention (AD-10). Kein Verstoß gegen D-3 (textuelle Artefakte, kein Standalone-Programm).
evidence: Prozess-Optimierungs-Bericht §3.4/§4.2; Review-Input §4 (Konformität: AD-3/AD-10/AD-17h/D-3).
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
summary: Einmalige `at`-Festlegung pro Compilation Run deterministisch identisch in alle erzeugten `generated.at` schreiben (P1) — der Run bestimmt **einen** Ablauf-Zeitstempel (UTC) für alle Dateien; optional als textuelle Konvention in `compiler.md` §4.3 ergänzen (Kanonisierung auf `Z`-Form, da der Validator §4.3 sowohl `±HHMM` als auch `Z` akzeptiert — keine Vertrags-Änderung nötig). Nutzen: keine Timing-Drift/Inkonsistenz über Dateien, einfachere Diff-/Nachvollziehbarkeit. Deckt sich mit dem Defer zur Determinismus-Selbsttest-Schärfung (Kriterium 2 „`at`-Normalform").
evidence: Prozess-Optimierungs-Bericht §3.3/§4.3; Review-Input §4 (Validator-neutral: §4.3 akzeptiert `Z` und `±HHMM`).
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
summary: Pre-Run-Reconcile-Vorphase als deterministischen Pre-Plan-Schritt bündeln und dokumentieren (P2) — die textuellen Reconcile-Prüfungen (Ziel-Pfad-Kollision, Quellen-Existenz, AD-5-Relevanz der Quelle auf bestehende Concepts, `index.md`-Vorbedingung V-1) zu einem wiederverwendbaren Check-Block zusammenfassen (statt manueller Mehrfach-Checks, Bericht §3.2). Kein neuer Standalone-Prozess — nur ein reproduzierbarer Check-Block innerhalb der Instruktions-Ausführung; als Compiler-Instruktions-Schärfung (Story 2.1-Follow-up) oder Epic-3-Home (AD-5) einzuarbeiten.
evidence: Prozess-Optimierungs-Bericht §3.2/§4.4; Review-Input §4 (D-3-konform).
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
summary: Provenienz-Checksumme bei mehrfacher Verwendung einer Quelle im Blick behalten (P2, Vorbereitung Epic 3/Story 2.2) — bei 11 Concepts aus einer Quelle (`raw/MetaModel.pdf`) ist eine wie auch immer geartete SHA-256/`last_modified`-Angabe Kandidat für `sources`-Metadaten; erst ab der zulässigen Schema-Erweiterung (Story 2.2 Claim-provenienz / Epic 3) in der Instruktion verankern. NICHT jetzt implementieren — `sources`-Subset (Vertrag §3.3, Punkt 6/§7) bleibt unverändert.
evidence: Prozess-Optimierungs-Bericht §4.5; Review-Input §4 (vertragskonform: Schema-Subset unangetastet); verknüpft mit Defer zum „`sources`-`id`-Eindeutigkeit" (BH-13).
@@ -0,0 +1,91 @@
---
title: 'Review-Input: Prozess-Optimierungs-Bericht Compilation Run Story 2.1 (PDF/RADIUM-Probelauf in D:\mita\wow-2nd-sandbox)'
type: review-input
created: '2026-08-17'
status: incorporated
scope: review-context
---
# Review-Input: Sandbox-Dryrun (PDF/RADIUM) zu Story 2.1
> **Herkunft:** Nutzer-Durchlauf in `D:\mita\wow-2nd-sandbox` (Probelauf des
> Compilers `schema/compiler.md` Rev 1.3 gegen die Quelle `raw/MetaModel.pdf`),
> dokumentiert in `PROZESS-OPTIMIERUNGS-BERICHT.md` (2026-08-16).
> **Zweck:** Zusätzlicher Review-Kontext für Story 2.1 — R-2 wird praktisch
> belegt (PDF `sources[].resource` wird endungsneutral verarbeitet), zusätzlich
> empirische Befunde zur Ausführungs-/Tooling-Ebene.
> **Charakter:** Prozess-Optimierungs-Bericht. Keine Änderung an `raw/`,
> `schema/`, `adapters/`, `wiki/spring/` in der Sandbox; Bericht deklariert
> bewusste Selbstbegrenzung (D-3, keine Norm-Änderung).
## 1. Belegte Fakten (empirisch)
- **Run konform:** 11 neue Root-Concepts aus `raw/MetaModel.pdf`
(28 Seiten, 11 Wissenseinheiten, AD-5: fachfremde Quelle betrifft keine
bestehenden Concepts → kein Update/keine Kollision). Verlinkung in
`wiki/index.md` (11 Link-Zeilen mit `(aus raw/MetaModel.pdf)`), 11
`- neu:`-Einträge in `wiki/log.md` (§5-Format, `sources: raw/MetaModel.pdf`).
- **Quelle unverändert:** SHA-256 von `raw/MetaModel.pdf` konstant vor/nach
Run (`4fe7aaa0…eea5ec`). EC-11 bestätigt: `raw/report/report-2026-08-16.pdf`
bleibt unberührt (kein `.md`, kein Verdikt).
- **Validator-Run-Ergebnis (Sandbox-Selbstauskunft, Anhang A):** SUCCESS für
alle 18 Sandbox-Bundle-Dateien (0 FAIL): 13 Root- + 5 `spring/`-Dateien.
Darunter die 5 realen Bundle-Dateien zuzüglich 11 radium- + 2 spring-Dateien.
- **`at`-Konsistenz:** Alle 11 `at`-Stempel der neuen Concepts einheitlich
(`2026-08-16T09:23:33Z`), `verified` ungesetzt (v1-Default AD-15), Innen-Ebenen-
Key-Subset eingehalten (Punkt 6), kanonische Reihenfolge (§6.6).
## 2. Korrigierter technischer Befund zum Validator-Tooling (§3 Punkt 11)
Der Bericht (3.1 #2) wertet `wiki/spring/testing.md` → „Punkt 11 FAIL
(Index-Regel)" als inkonsistenten Schema-Fehlalarm. **Korrektur laut
`validator.md` §3 Punkt 11:** 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 Bundleroot `wiki/index.md`)
als relativer Bundle-Pfad referenziert ist — **mit oder ohne `.md`-Endung**
(normative Zelle, Rev 7/8 unterscheiden sich hier nicht).
Konsequenz: Für `wiki/spring/testing.md` ist die zuständige `index.md`
`wiki/spring/index.md`, erwartetes Token `spring/testing`. Ein „nackte"
Identitäts-Suche ohne relative Auflösung ist ein **Implementierungs-Defekt des
Prüfwerkzeugs** — kein Instruktions-Defekt. Da diese Zeile des Validators eine
buchstabenidentische Aussage des Prüfpfads verlangt (keine Dateisystem-Pfad-
Auflösung mit Absoluthalten), steht der Befund **nicht** als Findings-Item für
`validator.md`; er ist als Tooling-Lernfall (Fixture-Selbsttest, Abschnitt 4
des Berichts) zu führen.
## 3. Bestätigte Instruktions-Aussagen (R-1/R-2-Bezug)
- **R-2 bestätigt (praktisch belegt):** `compiler.md` §1.2/§1.4 verarbeitet
die PDF-Quelle endungsneutral (PDF als Datei unter `raw/`); `sources[].
resource: raw/MetaModel.pdf` ist Vertrag-§3.3-konform (Dateipfad unter
`raw/`, kein `wiki/`-Pfad, AD-4b); Validator EC-1 prüft nur Existenz.
Der Befund 3.1 #1 (PyYAML-Timestamp-Parsing als Tooling-Falle) ist
§4.3-konform vermeidbar — der Validator verlangt **Textform**-Prüfung des
ISO-8601-Datetime (§4.3 Normalform), nicht Parsing zum `datetime`-Objekt.
- **R-1 unverändert (Set-Interface):** `compiler.md` §1.2 definiert die Source-
Eingabe als Menge beliebiger `raw/`-Dateien; der Sandbox-Lauf (1 Quelle) ist
als Teilmenge des Sets operiert, nicht als Einzelpfad-Interface.
## 4. Review-Zuordnung der Optimierungs-Maßnahmen (Bericht §4)
| Maßnahme | Prio | Review-Zuordnung | Konformität |
|---|---|---|---|
| Fixture-Selbsttest des Validator-Tools vor Bundle-Lauf | P1 | Tooling-Schärfung; Folge-Eintrag `deferred-work.md` (Zuordnung Story 2.1/Epic 3) | D-3-tauglich (rein textueller Check-Block), kein neuer Standalone |
| Feste `.compile-run/`-Arbeitskonvention (außerhalb `raw/`) | P1 | Tooling-Konvention; Folge-Eintrag `deferred-work.md` | AD-3-konform (nichts unter `schema/`/`raw/`), AD-17h-relevant |
| Einmaliges `at` pro Run (UTC, `Z`-Form) | P1 | Klarstellung `compiler.md` §4.3 als Konvention; kein Vertrags-Bruch (Validator akzeptiert ±HHMM wie Z) | Validator-neutral |
| Pre-Run-Reconcile-Vorphase deterministisch bündeln | P2 | Folge-Eintrag `deferred-work.md` (Zuordnung Epic 3, AD-5) | D-3-konform |
| Provenienz-Checksumme in `sources` (Vorbereitung Epic 3) | P2 | Eintrag `deferred-work.md` (Zuordnung Story 2.2/Epic 3) — NICHT jetzt implementieren (Schema-Subset §3.3 unverändert) | vertragskonform |
| Area-Reife für längere fremde Quellen | P3 | Zuordnung Story 2.4 (deterministische Area-Zuordnung) — bis dahin Root-Ebene normativ korrekt (Rev-1.3-Konvention) | Story-2.4-Kontext |
| Deterministik offener Punkte (`.MD`, `today`-Zeitzone) | P3 | Verweist auf bestehende „Offene Punkte" (F-06/F-08, Validator Rev. 6, §1 Punkt 3/§6.4) — aktuell kein Sonderfall im Bundle | keine neue Festlegung nötig |
## 5. Fazit für den Review
- Der Probelauf ist ein **Positiv-Beleg** für Story 2.1 (R-2 praktisch
bestätigt); keine neuen AC- oder Vertrags-Verstöße erkennbar.
- Die gemeldeten Tooling-Falsch-FAILs sind **Prüfwerkzeug-Lernfälle** (kein
Instruktions-/Validator-Defekt) — als Folge-Einträge (`deferred-work.md`),
nicht als Findings gegen `schema/*`.
- Die „Optimierungs-Maßnahmen" sind **Tooling-/Konventions-Ebene** und
berühren keine autorisierten Schemata; P1-Punkte sind als dokumentierte
Konventionen direkt umsetzbar, P2/P3-Einträge der Story-Zuordnung folgen.