chore(docs): füge ADRs 0025–0027 und Wizard-DSL-Referenz hinzu, aktualisiere Roadmap und ADR-Index

Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>

docs/01_Architecture/MASTER_ROADMAP.md

@@ -2,7 +2,7 @@
 type: Roadmap
 status: ACTIVE
 owner: Lead Architect
-last_update: 2026-04-20
+last_update: 2026-04-21
 ---
 
 # MASTER ROADMAP: Meldestelle
@@ -175,6 +175,58 @@ und über definierte Schnittstellen kommunizieren.
 
 ---
 
+## 3. Initiative: Wizard-Orchestrator & Offline-Drafts (Q2/Q3 2026)
+
+🏗️ Verantwortlich: Lead Architect · 🎨 Frontend · 🖌️ UI/UX · 👷 Backend · 🧐 QA · 🧹 Curator
+
+Ziel: Konsolidierung aller „Wizards“ auf ein deklaratives Orchestrierungs-Framework (Graph + Guards + Effects), vereinheitlichte Validierung und Offline-Draft-Fähigkeit inkl. Delta‑Sync. Desktop-first, tastaturbedienbar, testbar.
+
+### 3.1 Kernbausteine
+- Orchestrator Runtime & DSL: `StepId`, `WizardContext`, `WizardState`, `Guard`, `Transition`, `StepEffects`.
+- WizardScaffold: Breadcrumb, Kontext-Chips, Footer mit Hotkeys (Enter/Shift+Enter/Alt+S), Fehler-Summary.
+- DraftStore: Autosave pro Step (`onLeave`), Resume, `flowVersion`, Konfliktanzeige.
+- DevTools: strukturierte Transition-Logs, Graph-Export (DOT/PlantUML).
+
+Referenzen/Dokumente:
+- ADR‑0025: Wizard-Orchestrator (State‑Machine, DSL, Guards, Effects) → `docs/01_Architecture/adr/0025-wizard-orchestrator-de.md`
+- ADR‑0026: Step-Validation-Policy (sync vs. async, Fehlersichtbarkeit, Hotkeys) → `docs/01_Architecture/adr/0026-validation-policy-de.md`
+- ADR‑0027: Draft-Domain & Delta‑Sync (Versionierung, Konfliktlösung, Idempotenz) → `docs/01_Architecture/adr/0027-draft-domain-and-delta-sync-de.md`
+- Reference: Wizard‑DSL README (Beispiel-Flow Event) → `docs/01_Architecture/Reference/Wizard-DSL-README.md`
+
+### 3.2 Migrationsstrategie (Strangler)
+1) Parallelbetrieb: Neuer Orchestrator in `frontend/core/wizard`; bestehende VMs delegieren schrittweise.
+2) Inkrement 1: Event‑Flow – zunächst 2 Steps (ZNS_CHECK, VERANSTALTER_SELECTION), dann alle 6 Steps.
+3) Feature‑Flag `WizardRuntimeEnabled` für risikoarmen Rollout.
+
+### 3.3 Phasenplanung (Auszug)
+- Phase 1 (Core & Tooling, 2–3 Wochen): Runtime/DSL, DevLogs, Graph‑Export, Scaffold‑MVP, Unit‑Tests.
+- Phase 2 (Event‑Flow, 2–3 Wochen): `EventStep/Acc/Guards`, Flow‑DSL, VM‑Delegation, Validierung, Autosave/Resume.
+- Phase 3 (Backend, 2–4 Wochen): Draft-/Validate‑APIs, Offline‑Queue, Delta‑Sync für Turniere.
+- Phase 4 (Skalierung, 6–10 Wochen, parallel): Weitere Flows je Bounded Context.
+- Phase 5–7 (2–3 + 1–2 + 1–2 Wochen): UX‑Härtung, Observability/Rollout‑Gates, Stabilisierung & Abschaltung Altlogik.
+
+Grobe Gesamtdauer: 17–29 Wochen je nach Parallelisierung.
+
+### 3.4 Akzeptanzkriterien (DoD Initiative)
+- Alle priorisierten Flows laufen über Orchestrator; Next/Back/History deterministisch; Graph‑Export aktuell.
+- DraftStore produktiv; Resume deterministisch; Delta‑Sync idempotent; Konflikte nicht‑blockierend sichtbar.
+- Validierungs‑Policy konsistent; Tastatur‑Bedienung vollständig; Performance‑Gates eingehalten.
+- ADR‑0025/0026/0027 veröffentlicht; Wizard‑DSL‑Reference vorhanden; CI grün; Metriken/Alerts aktiv.
+
+### 3.5 10‑Tage‑Startplan
+- Tag 1–2: Runtime/DSL‑Skelett, Scaffold‑MVP, Feature‑Flag, README Skeleton.
+- Tag 3: EventStep/Acc/Guards, EventFlow (2 Steps), VM‑Delegation minimal.
+- Tag 4: Tests Runtime/Guards, Graph‑Export, Dev‑Logs.
+- Tag 5–6: META_DATA/ANSPRECHPERSON migrieren, Validierungs‑API, Fehler‑Summary.
+- Tag 7: DraftStore lokal (Autosave/Resume), Property‑Test Resume.
+- Tag 8: TURNIER_ANLAGE einbetten, Sync via `onComplete`.
+- Tag 9: SUMMARY + Finalisierung, Offload in Offline‑Queue (Stub).
+- Tag 10: ADR‑0025/0026/0027 Review+Merge; Journal‑Eintrag.
+
+Journal: `docs/99_Journal/2026-04-21_Wizard-Orchestrator_Roadmap_Anchoring.md`
+
+---
+
 ## 3. Aktuelle Phase
 
 ### PHASE 5: P2-Contexts & Integration ✅ ABGESCHLOSSEN