Change-Arten auf 4 zusammengefuehrt (Frank/ITIL/YASM) + MB = Mission Board

- 5 -> 4 Change-Arten: Major (Top-Level-Beispiel) / Normal / Standard / Emergency.
  Top/Low ist Routing/Freigabe-Ebene, kein Typ (ITIL: Major = Normal m. hoeherer
  Authority; YASM: lean). Klarere Klassifizierung in der App.
- App: CHANGE_TYPES/CHANGE_LEGEND/START_EMPFEHLUNG/USE_CASES auf 4; Action Cards
  24 (Major-Low entfernt, Rest auf c0-c3 umbenannt); sw.js cacht 24 (v4).
  Browser-getestet: 24 Karten, 4 Klassifizier-Optionen, Bilder laden.
- review-phase_arbeitsstand-frank.md: MB = Mission Board geklaert; SOR-Routing
  RUN/DPM/MB + Eskalations-Kriterium (Ressourcenhoheit -> Demand -> Mission Board);
  Change-Arten-Begruendung. README (24 Karten) nachgezogen.
- Workshop-Arbeitsstand; NICHT im YAML / kanonischen Konzept.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

00_Konzept/review-phase_arbeitsstand-frank.md

@@ -44,9 +44,22 @@ kanonisch ins Konzept übernommen (vor Übernahme mit **Michael** rückkoppeln).
 | rv_05 Redesign → DPM | 4./5. Starten/Implementieren (Routing) |
 | rv_06 Außerbetriebnahme | *— nicht explizit abgedeckt* |
 
+## Routing & Change-Arten (geklärt)
+
+- **MB = Mission Board** (offener Punkt gelöst). Das SOR-Routing am Change ist:
+  **RUN** (im Betrieb durch den SO) · **DPM** (über den Demand-Prozess) · **MB**
+  (Mission Board). **Eskalations-Kriterium:** Reicht die **Ressourcen-/
+  Entscheidungshoheit der SOR** nicht (z. B. zusätzliches Budget/Mittel), wird der
+  Change zum **Demand** → über **DPM** ans **Mission Board** (= der DPM-Rücklauf).
+- **Change-Arten auf 4 zusammengeführt** (Major · Normal · Standard · Emergency).
+  Franks frühere *Top-Level/Low-Level*-Unterscheidung ist **Routing/Freigabe-Ebene,
+  kein Change-Typ** (ITIL 4: „Major" = Normal-Change mit höherer Authority; YASM:
+  bewusst schlank). In der App umgesetzt: 4 Change-Arten, **24 Action Cards**
+  (6 Services × 4), klarere Klassifizierung. „Major" nutzt das Top-Level-Beispiel.
+  → Workshop-Arbeitsstand (App), **nicht** YAML/kanonisches Konzept.
+
 ## Offene Punkte (vor Konzept-/YAML-Übernahme klären)
 
-- **„MB"** als dritter Routing-Weg ist **nicht definiert** (RUN und DPM sind klar).
 - **Retirement / Außerbetriebnahme** (bisher rv_06) fehlt — bewusst entfallen oder
   unter „Service-Änderung" subsumiert?
 - **RACI + Quizfragen** wurden für die App **abgeleitet** (Franks Entwurf nennt nur