wow20/_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md

---
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.