first

03_Karten/README_karten.md

@@ -0,0 +1,83 @@
+# Karten & Chips
+
+Alle bedruckten Spielkarten und die Entscheidungs-Chips. Layout im
+Freiburg-digital-Look (rot/weiß, Wappen-Logo) analog zur bestehenden Action Card.
+
+## Kartenformate
+
+| Kartentyp | Format | Hinweis |
+|-----------|--------|---------|
+| Action Cards | 70 × 120 mm (Tarot) | passt in Action-Stein-Schlitz (74 mm) |
+| Störungskarten | 70 × 120 mm | gleiches Format, anderer Akzent |
+| Artefaktkarten | 63 × 88 mm (Bridge) | werden bei Aktivitäten mitgeführt |
+| Gate-Beschreibungskarten | 60 × 90 mm | stecken im Gate-Tor-Schlitz (65 mm) |
+| Entscheidungs-Chips | Ø 30 mm | Karte oder 3D-Münze |
+
+---
+
+## 1. Action Cards (Szenario-Deck)
+
+Triggern eine Lifecycle-Runde. Aufbau: **Banner „ACTION CARD" · Icon · Titel ·
+Szenariotext · Leitfrage · Logo**. Beispiel (vorhanden):
+
+> **Strategiewechsel** — „Das Ticketsystem muss kurzfristig an die neue
+> Servicestrategie der Stadt angepasst werden. Was passiert an welchen Stellen?"
+
+Weitere Szenario-Vorschläge:
+- **Neues Fachverfahren** — ein neuer Service soll von Grund auf entstehen (voller Build-Pfad).
+- **Standardsoftware-Rollout** — Konfiguration statt Entwicklung (Gate-1-Pfad „Konfiguration").
+- **Major Incident** — wiederkehrende Störung eskaliert (Support→Problem→Review).
+- **Außerbetriebnahme** — ein Altservice soll abgelöst werden (Pfad Richtung rv_06).
+- **Sicherheits-Update** — kurzfristige Änderung im Betrieb mit Re-Transition.
+
+## 2. Störungskarten (Ereignis-Deck)
+
+Gegenstück zu Action Cards: werfen den Service in die **Operation↔Support-Schleife**
+oder über ein Gate zurück. Beispiele:
+- **Incident-Welle** → Support-Schleife sp_03–sp_08.
+- **Strukturelles Problem** → sp_09/sp_10 + Problem Manager.
+- **Sicherheitsvorfall** → Re-Transition (zurück über Gate).
+- **Budgetkürzung** → Review-Entscheidung erzwungen.
+- **Lieferant fällt aus** → Build/Support verzögert.
+
+## 3. Artefaktkarten (Ergebnisse)
+
+Wird an einer Aktivität ein Artefakt erzeugt, kommt die Karte ins Spiel und wird
+mitgeführt. Mapping:
+
+| Artefakt | entsteht bei |
+|----------|--------------|
+| Projektauftrag | Eingang aus DPM → ds_01 |
+| Service-Definition / Steckbrief | ds_01 |
+| Betriebsdokumentation | tr_06 |
+| Test-Report | tr_07 |
+| Service-Qualitätsbericht | op_06 |
+| Incident Record | sp_05–sp_07 |
+| Problem Record | sp_09 / sp_10 |
+| Workaround | sp_11 |
+| Service-Review-Bericht | rv_02 / rv_03 |
+
+## 4. Gate-Beschreibungskarten
+
+Eine Karte je Gate, steckt im Tor-Schlitz: Gate-Nummer, Gate-Keeper,
+Pflicht-Rollen, Entscheidungspfade.
+
+| Gate | Keeper | Pfade |
+|------|--------|-------|
+| Gate 1 (tr_01) | SOR | Entwicklung (tr_02) / Konfiguration (tr_05) |
+| Gate 2 (tr_09) | SO | Go / Go mit Auflagen / Zurück / Ablehnung |
+| Gate 3 (tr_12) | SOR | Go-Live / mit Auflagen / Zurück / Ablehnung |
+
+## 5. Entscheidungs-Chips
+
+Vier Typen, an Gates gelegt: **Go · Go mit Auflagen · Zurück · Ablehnung**.
+Als Karte (Ø 30 mm Stanzung) oder als 3D-Münze (siehe Materialliste).
+
+---
+
+## Druck-Pipeline (Hinweis)
+
+Karteninhalte lassen sich aus den `service-lifecycle_*.yaml` und `spm_rollen.yaml`
+generieren (eine Quelle, kein Doppeln). Empfehlung: ein Template (HTML→PDF im
+Freiburg-Layout), das die YAML-Felder einsetzt — analog zur bestehenden
+Action-Card-Gestaltung. Umsetzung offen / späterer Schritt.