v11

03_Karten/README_karten.md

@@ -9,8 +9,6 @@ Freiburg-digital-Look (rot/weiß, Wappen-Logo) analog zur bestehenden Action Car
 |-----------|--------|---------|
 | Action Cards | 60 × 90 mm | liegen flach an der aktuellen Station; werden separat selbst produziert |
 | Störungskarten | 60 × 90 mm | gleiches Format, anderer Akzent |
-| Artefaktkarten | 63 × 88 mm (Bridge) | werden in der Service-Akte gesammelt |
-| Service-Akte (Tableau) | A4 quer / A5 | 15 Slots (A1–A15), Artefakt-Sammler (§3a) |
 
 > **Keine Gate-Beschreibungskarten mehr:** Gate-Nr/Keeper/Pfade/Artefakte führen
 > **App + Gate-Puck-Etikett** (`G1/G2/G3`), siehe §4. Auch der frühere Action-Stein
@@ -43,15 +41,16 @@ oder über ein Gate zurück. Beispiele:
 - **Budgetkürzung** → Review-Entscheidung erzwungen.
 - **Lieferant fällt aus** → Build/Support verzögert.
 
-## 3. Artefaktkarten (Ergebnisse)
+## 3. Artefakte A1–A15 (in der App gesammelt)
 
-Wird an einer Aktivität ein Artefakt erzeugt, kommt die Karte ins Spiel und wird
-mitgeführt. Im Blueprint tauchen ~20 Artefakt-Bezeichnungen auf (Schnittstellen,
-`umfasst`-Listen); für das Spiel sind sie hier zu **15 Kern-Artefaktkarten**
-konsolidiert. Mehrere Dokument-Varianten werden bewusst auf eine Karte gelegt
-(Spalte „fasst zusammen").
+Erzeugt eine Aktivität ein Artefakt, wird es **in der App** bestimmt (Auswahl im
+Artefakt-Schritt, „nochmal" bis richtig) und in die digitale **Service-Akte**
+aufgenommen — **keine physischen Artefaktkarten** mehr. Im Blueprint tauchen ~20
+Artefakt-Bezeichnungen auf; für das Spiel sind sie zu **15 Kern-Artefakten (A1–A15)**
+konsolidiert (Spalte „fasst zusammen"). Diese Tabelle ist die Referenz/Datengrundlage
+der App; ausführliche Inhalte je Artefakt in `artefaktkarten_gamma.md`.
 
-| # | Artefaktkarte | Phase | entsteht bei | fasst zusammen / Notiz |
+| # | Artefakt | Phase | entsteht bei | fasst zusammen / Notiz |
 |----|---------------|-------|--------------|------------------------|
 | A1 | **Projektauftrag** | Eingang (DPM) | → ds_01 | „Freigegebener Demand" aus dem Demand-Lifecycle |
 | A2 | **Service-Definition** | Design | ds_01 | zentrales Artefakt; im Review fortgeschrieben (`service_review`) |
@@ -70,67 +69,50 @@ konsolidiert. Mehrere Dokument-Varianten werden bewusst auf eine Karte gelegt
 | A15 | **DPM-Rücklauf** | Review → DPM | rv_05 / rv_06 | Variante A: Neuer Demand (Redesign) · Variante B: Retirement-Plan / Decommissioning-Auftrag |
 
 **Ergebnis-Hinweis:** Die Review-Entscheidung erzeugt entweder eine
-**Verbesserungsmaßnahme** (rv_04, fließt zurück in die Operation — kein eigenes
-Kartendeck nötig) oder den **DPM-Rücklauf** (A15).
+**Verbesserungsmaßnahme** (rv_04, fließt zurück in die Operation — kein eigener
+Akte-Eintrag nötig) oder den **DPM-Rücklauf** (A15).
 
-**Konsolidierungs-Logik (für die Druckvorlage):**
+**Konsolidierungs-Logik (für die A1–A15-Datengrundlage):**
 - A6 bündelt die ganze „Betriebs-/Support-Doku"-Familie (Manual, Handbuch,
-  Richtlinien, Standard Changes, Known Errors) auf **eine** Karte.
+  Richtlinien, Standard Changes, Known Errors) auf **einen** Eintrag.
 - A9 deckt die laufenden Betriebsdaten (Monitoring/Alerts) mit ab — Live-Daten
-  sind keine eigene physische Karte.
+  sind kein eigener Eintrag.
 - A10 trägt Incident **und** Request Record (gleicher Abschluss-Workflow).
-- A15 ist **eine** Karte mit zwei Rückseiten/Varianten statt zwei Decks.
+- A15 ist **ein** Eintrag mit zwei Varianten (Redesign / Retirement).
 
 > Hinweis Datenqualität: Nur der **Problem Record** ist in den YAMLs als
-> `artefakte:`-Objekt mit Inhalten/Verantwortung spezifiziert. Für saubere,
-> generierbare Karten sollten A1–A15 analog als `artefakte:`-Block in den
+> `artefakte:`-Objekt mit Inhalten/Verantwortung spezifiziert. Für eine saubere,
+> generierbare App-Datengrundlage sollten A1–A15 analog als `artefakte:`-Block in den
 > `service-lifecycle_*.yaml` definiert werden (Single Source of Truth).
 
-## 3a. Service-Akte (Artefakt-Tableau) — Spielelement
+## 3a. Service-Akte (App-Element)
 
-Ein **gedrucktes Tableau (A4/A5)**, das **neben der aktuellen Station** liegt und
-mitwandert. Es hat **15 beschriftete Slots** (A1–A15, nach Phase gruppiert) und
-macht die wachsende Service-Dokumentation sichtbar. Layout: `service-akte.svg`.
+Die Service-Akte ist **vollständig digital in der Companion-App** abgebildet —
+**kein gedrucktes Tableau, keine Pappkarten**.
 
 **Mechanik**
-- **Erstellen:** Erzeugt eine Station ein Artefakt → die zugehörige **Artefaktkarte
-  (63×88)** kommt in ihren Slot der Service-Akte.
-- **Befüllen / Aktualisieren:** Wird ein bestehendes Artefakt erneut angefasst →
-  **Status-Marker weiterschieben** (`Entwurf → Final → Aktualisiert`). So „wächst"
-  ein Artefakt sichtbar über mehrere Stationen.
+- **Erzeugen:** Im Artefakt-Schritt einer Aktivität wählen die Teilnehmenden, welches
+  Artefakt entsteht (Choice, „nochmal" bis richtig) → es wandert in die Akte.
+- **Vorbefüllt:** Beim Einstieg mitten im Lebenszyklus (z. B. Normal Change an Gate 1)
+  liegen die zuvor entstandenen Artefakte bereits in der Akte.
+- **Sichtbar:** Das Panel **„📁 Akte"** zeigt A1–A15 nach Phase, gesammelt vs. offen.
+- **Lebende Artefakte** (A2 Service-Definition, A11 Problem Record, A13 Wissensdatenbank)
+  werden mehrfach befüllt/aktualisiert.
 
-**„Lebende" Artefakte (werden mehrfach befüllt):**
+**Harte Gate-Kopplung:** Ein Gate gibt die Entscheidung erst frei, wenn die geforderten
+Artefakte in der Akte liegen (siehe §4) — sonst Hinweis „🔒 Es fehlt: …". Das macht
+Artefakte zum echten Spielelement (analog zu den Pflicht-Figuren am Gate-Puck).
 
-| Artefakt | erstellt | aktualisiert/befüllt |
-|----------|----------|----------------------|
-| **A2** Service-Definition | ds_01 | im Review (rv_02 / rv_04, Improvement-Tracking) |
-| **A11** Problem Record | sp_09 / sp_10 | sp_11 (Root-Cause + Workaround) |
-| **A13** Wissensdatenbank | sp_02 (Pflege) | sp_11 (neue Workarounds) |
-
-Alle übrigen Artefakte werden **einmal erstellt** (Status `Final`).
-
-**Funktional an die Gates gekoppelt:** Ein Gate „öffnet" nur, wenn die geforderten
-Artefaktkarten in der Akte liegen (siehe §4). Das macht Artefakte zum echten
-Spielelement — analog zu den Pflicht-Figuren am Gate — und bildet die
-Prüf-Dimensionen des Blueprints physisch ab.
-
-**Debrief:** Am Ende ist die gefüllte Service-Akte das sichtbare Ergebnis: „Das hat
-der Service über seinen Lebenszyklus an Dokumentation/Artefakten produziert."
-
-| Merkmal | Wert |
-|---------|------|
-| Form | Bedrucktes Tableau A4 (quer) oder A5, laminierbar |
-| Slots | 15 (A1–A15), nach Phase gruppiert, je mit Mini-Status-Track |
-| Karten | Artefaktkarten 63 × 88 mm (Bridge) |
-| Menge | 1 (ggf. 2 bei parallelen Tischen) |
+**Debrief:** Am Ende ist die gefüllte Akte das sichtbare Ergebnis: „Das hat der Service
+über seinen Lebenszyklus an Dokumentation/Artefakten produziert."
 
 ## 4. Gate-Anforderungen (App-geführt, keine physische Karte)
 
 Es gibt **keine Gate-Beschreibungskarte** mehr. Gate-Nummer, Gate-Keeper,
 Pflicht-Rollen, Entscheidungspfade — **und die erforderlichen Artefakte** — führt die
 **App**; am Tisch markiert der **rote Gate-Puck** (Etikett `G1/G2/G3` + Icon) die
-Position. Das Gate „öffnet" nur, wenn die erforderlichen Artefaktkarten in der
-Service-Akte liegen (vgl. §3a) und die Pflicht-Figuren am Gate-Puck stehen.
+Position. Das Gate „öffnet" nur, wenn die erforderlichen Artefakte in der digitalen
+Akte gesammelt sind (App-Prüfung, vgl. §3a) und die Pflicht-Figuren am Gate-Puck stehen.
 
 | Gate | Keeper | Erforderliche Artefakte | Pfade |
 |------|--------|-------------------------|-------|