v11

00_Konzept/README_konzept.md

@@ -135,7 +135,7 @@ Alle Standfelder sind Ø 22 (gleich wie die Puck-Mulden — dieselben Ø-20-Figu
 Details & Designvarianten: [`../02_Spielfiguren/`](../02_Spielfiguren/).
 
 ### 5.4 Weitere Karten
-- **Artefaktkarten + Service-Akte:** Was an einer Aktivität entsteht (15 konsolidierte Artefakte A1–A15). Erzeugte Artefakte kommen als Karte in die **Service-Akte** (Tableau neben der aktuellen Station); „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden über einen **Status-Marker** mehrfach befüllt. **Gate-Kopplung:** Ein Gate öffnet nur, wenn die geforderten Artefakte in der Akte liegen (Gate 1: SDD + Implementation Blueprint usw.). Details: [`../03_Karten/`](../03_Karten/).
+- **Artefakte A1–A15 + Service-Akte (App):** Was an einer Aktivität entsteht (15 konsolidierte Artefakte). Erzeugte Artefakte werden **in der App** bestimmt (Choice) und in der digitalen **Service-Akte** gesammelt; „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden mehrfach befüllt. **Harte Gate-Kopplung:** Ein Gate gibt die Entscheidung erst frei, wenn die geforderten Artefakte gesammelt sind (Gate 1: A2·A3·A4 usw.). Details: [`../03_Karten/`](../03_Karten/).
 - **Störungskarten:** Gegenstück zu Action Cards (Incident-Welle, Sicherheitsvorfall, Budgetkürzung, Eskalation) — zwingen in die Operation↔Support-Schleife oder über ein Gate zurück.
 - **DPM-Rücklauf-Karte:** markiert am Review-Ende, wenn der Service als Redesign/Retirement zurück in den Demand-Lifecycle geht.
 - **„Unklar"-Marker:** rote Punkte für Verständnislücken (→ Dokumentation).
@@ -168,13 +168,13 @@ Schwach beantwortete Stationen werden protokolliert (→ Abschnitt 8). MVP-Scope
    1. Was passiert hier konkret für dieses Szenario?
    2. Wer macht es (Rolle, RACI)? → die genannten **Figuren an den Puck stellen** und
       zusätzlich ins **Aktiv-Feld** in die passende R/A/C/I-Zone.
-   3. Welches Artefakt entsteht? → erzeugte **Artefaktkarte in die Service-Akte**
-      legen (bzw. Status-Marker eines bestehenden Artefakts weiterschieben).
+   3. Welches Artefakt entsteht? → in der **App auswählen** (Artefakt-Schritt); es
+      wandert in die digitale **Service-Akte**.
    Dann **App-Quiz** zur Station → **Auflösung in der App** → Gruppe reflektiert /
    gleicht ab. Danach Aktiv-Feld leeren und zur **nächsten Station** weiterziehen
    (App schaltet weiter, Action Card mitnehmen).
-5. **Gates:** Diskussion, Pflicht-Figuren an den Gate-Puck stellen, **geforderte
-   Artefakte in der Service-Akte prüfen** (sonst öffnet das Gate nicht),
+5. **Gates:** Diskussion, Pflicht-Figuren an den Gate-Puck stellen; die **App prüft die
+   geforderten Artefakte** (fehlen sie, bleibt die Entscheidung gesperrt),
    Entscheidung in der App treffen, weiterziehen.
 6. **Schleife:** Störungskarten und Support-Phase durchspielen, bis Review erreicht ist.
 7. **Review-Entscheidung:** Improvement / Redesign (rv_05) / Retirement (rv_06) — Redesign & Retirement geben den Service über die DPM-Rücklauf-Karte ab.

01_3D-Druck/openscad/artefakt-token.scad

@@ -1,56 +0,0 @@
-// Artefakt-Token (Service-Akte) — gedruckte "Karte" statt Pappkarte
-// SLC-Workshop Tabletop · Einheiten: mm
-// Kleine Tile mit gravierter A-Nummer; wird in einen Slot des Artefakt-Trays
-// (artefakt-tray.scad) gelegt. Eingefaerbt in der PHASENFARBE der erzeugenden
-// Phase (Design/Transition/Operation/Support/Review) -> Farbe via Filament.
-//
-// "Lebende" Artefakte (A2 Service-Definition, A11 Problem Record,
-// A13 Wissensdatenbank) wachsen sichtbar: Basis-Token + je Aktualisierung
-// eine duenne Status-Platte oben drauf (Entwurf -> Final -> Aktualisiert).
-//
-// part = "token"  -> ein Artefakt-Token (Nummer via tok_label)
-//        "plate"  -> eine Status-Platte zum Aufstapeln (lebende Artefakte)
-
-part      = "token";     // "token" | "plate"
-
-/* [Token] */
-tok_w     = 30;          // Breite
-tok_d     = 20;          // Tiefe
-tok_h     = 4;           // Hoehe (Basis-Token)
-tok_r     = 2.5;         // Eckenradius
-tok_label = "A2";        // gravierte A-Nummer
-lab_size  = 11;          // Schriftgroesse A-Nummer
-lab_depth = 0.8;         // Gravurtiefe
-
-/* [Status-Platte] (lebende Artefakte) */
-plate_h   = 2.5;         // Hoehe je Aktualisierungs-Platte
-
-$fn = 48;
-
-module rrect(l, w, h, r) {
-    linear_extrude(h) offset(r) offset(-r) square([l, w], center = true);
-}
-
-module token(label) {
-    difference() {
-        rrect(tok_w, tok_d, tok_h, tok_r);
-        translate([0, 0, tok_h - lab_depth])
-            linear_extrude(lab_depth + 0.1)
-                text(label, size = lab_size, halign = "center", valign = "center");
-    }
-}
-
-// duenne Platte zum Aufstapeln; kleine Mittenrille als Status-Markierung
-module status_plate() {
-    difference() {
-        rrect(tok_w, tok_d, plate_h, tok_r);
-        translate([0, 0, plate_h - 0.5])
-            linear_extrude(0.6)
-                square([tok_w - 10, 1.2], center = true);
-    }
-}
-
-if (part == "plate") status_plate();
-else                 token(tok_label);
-
-echo(part = part, tok = [tok_w, tok_d, tok_h], plate_h = plate_h);

01_3D-Druck/openscad/artefakt-tray.scad

@@ -1,107 +0,0 @@
-// Artefakt-Tray (Service-Akte) — 3D-Aufnahme fuer die 15 Artefakt-Token
-// SLC-Workshop Tabletop · Einheiten: mm
-// Flaches Tableau mit 15 beschrifteten Steck-Slots (A1-A15), in 5 PHASEN-Reihen
-// gruppiert (Design -> Transition -> Operation -> Support -> Review). Liegt neben
-// der aktuellen Station und wandert mit. Die Token (artefakt-token.scad) tragen
-// die Phasenfarbe; der Tray selbst ist EINFARBIG (Beschriftung via Gravur).
-//
-// Mechanik:
-//  - Artefakt erzeugt -> Token in seinen Slot legen.
-//  - "Lebende" Artefakte (A2/A11/A13, hier mit eingraviertem Zusatz-Rahmen
-//    markiert): Status-Platten oben aufstapeln -> Stapel waechst sichtbar.
-//  - Gate-Kopplung bleibt REGEL: ein Gate "oeffnet" nur, wenn die geforderten
-//    Token im Tray liegen (keine Mechanik am Gate-Puck).
-
-/* [Platte] */
-plate_thick = 6;     // Dicke
-margin      = 8;     // Aussenrand
-corner_r    = 5;
-
-/* [Slots] (Token Ø 30x20 wird REINGELEGT) */
-slot_w      = 31;    // Slot-Innenbreite (Token 30 + Spiel)
-slot_d      = 21;    // Slot-Innentiefe  (Token 20 + Spiel)
-pocket_dep  = 3.0;   // Vertiefung (Token 4 hoch -> steht ~1 mm vor = greifbar)
-pocket_r    = 2.5;
-gap_x       = 7;     // Abstand zwischen Slots in einer Reihe
-row_gap     = 8;     // Abstand zwischen den Phasen-Reihen
-header_h    = 9;     // Hoehe der Phasen-Kopfzeile ueber den Slots
-finger_r    = 6;     // Greifkerbe an der Slot-Unterkante
-
-/* [Gravur] */
-num_size    = 7;     // A-Nummer im Slot-Boden
-num_depth   = 0.8;
-hdr_size    = 6;     // Phasen-Name
-hdr_depth   = 0.8;
-lf_inset    = 3;     // "lebend"-Rahmen: Abstand zum Slot-Rand
-lf_w        = 1.2;   // Strichstaerke
-lf_depth    = 0.6;
-
-$fn = 48;
-
-// [Phasen-Reihe, [[A-Nummer, lebend?], ...]] — Reihenfolge = Lebenszyklus
-ROWS = [
-    ["DESIGN",     [["A1", false], ["A2", true],  ["A3", false], ["A4", false]]],
-    ["TRANSITION", [["A5", false], ["A6", false], ["A7", false], ["A8", false]]],
-    ["OPERATION",  [["A9", false]]],
-    ["SUPPORT",    [["A10", false], ["A11", true], ["A12", false], ["A13", true]]],
-    ["REVIEW",     [["A14", false], ["A15", false]]]
-];
-cols_max = 4;
-n_rows   = len(ROWS);
-
-// abgeleitete Maße
-content_w = cols_max * slot_w + (cols_max - 1) * gap_x;     // 145
-plate_w   = content_w + 2 * margin;                          // 161
-block_h   = header_h + slot_d;                               // 30
-content_h = n_rows * block_h + (n_rows - 1) * row_gap;       // 182
-plate_h   = content_h + 2 * margin;                          // 198
-
-// Platz von Ecke (0,0) aus; y oben = plate_h
-function blockTopY(r)   = plate_h - margin - r * (block_h + row_gap);
-function slotCenterY(r) = blockTopY(r) - header_h - slot_d/2;
-function slotCenterX(c) = margin + slot_w/2 + c * (slot_w + gap_x);
-
-module rrect(l, w, h, r) {
-    linear_extrude(h) offset(r) offset(-r) square([l, w], center = true);
-}
-
-module pocket(cx, cy, label, live) {
-    // Vertiefung
-    translate([cx, cy, plate_thick - pocket_dep])
-        rrect(slot_w, slot_d, pocket_dep + 0.1, pocket_r);
-    // Greifkerbe an der Unterkante
-    translate([cx, cy - slot_d/2, plate_thick - pocket_dep])
-        cylinder(r = finger_r, h = pocket_dep + 0.1);
-    // A-Nummer im Boden (sichtbar bei leerem Slot)
-    translate([cx, cy, plate_thick - pocket_dep - num_depth])
-        linear_extrude(num_depth + 0.1)
-            text(label, size = num_size, halign = "center", valign = "center");
-    // "lebendes" Artefakt: zusaetzlicher Rahmen als Hinweis (stapeln/aktualisieren)
-    if (live)
-        translate([cx, cy, plate_thick - pocket_dep - lf_depth])
-            linear_extrude(lf_depth + 0.1)
-                difference() {
-                    square([slot_w - 2*lf_inset, slot_d - 2*lf_inset], center = true);
-                    square([slot_w - 2*lf_inset - 2*lf_w, slot_d - 2*lf_inset - 2*lf_w], center = true);
-                }
-}
-
-module tray() {
-    difference() {
-        translate([plate_w/2, plate_h/2, 0]) rrect(plate_w, plate_h, plate_thick, corner_r);
-        for (r = [0 : n_rows - 1]) {
-            hdr   = ROWS[r][0];
-            slots = ROWS[r][1];
-            // Phasen-Kopfzeile (links ueber der Reihe)
-            translate([margin + 1, blockTopY(r) - header_h/2, plate_thick - hdr_depth])
-                linear_extrude(hdr_depth + 0.1)
-                    text(hdr, size = hdr_size, halign = "left", valign = "center");
-            for (c = [0 : len(slots) - 1])
-                pocket(slotCenterX(c), slotCenterY(r), slots[c][0], slots[c][1]);
-        }
-    }
-}
-
-tray();
-
-echo(plate_w = plate_w, plate_h = plate_h, plate_thick = plate_thick, slots = 15);

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

03_Karten/service-akte.svg

@@ -1,70 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="1000" height="540" viewBox="0 0 1000 540" font-family="system-ui, Arial, sans-serif">
-  <style>
-    .slot  { fill:#f7f9fb; stroke:#c8d2dd; stroke-width:1.2; }
-    .hdr   { fill:#ffffff; font-size:13px; font-weight:700; text-anchor:middle; }
-    .anum  { fill:#1d2430; font-size:13px; font-weight:700; }
-    .aname { fill:#33404f; font-size:10px; }
-    .stat  { fill:#6b7686; font-size:9px; }
-    .gate  { fill:#ffffff; font-size:9px; font-weight:700; text-anchor:middle; }
-    .h1    { fill:#1d2430; font-size:18px; font-weight:700; }
-    .sub   { fill:#444; font-size:12px; }
-    .lgd   { fill:#444; font-size:11px; }
-  </style>
-  <rect x="0" y="0" width="1000" height="540" fill="#ffffff"/>
-  <text x="20" y="30" class="h1">Service-Akte — Artefakte A1–A15</text>
-  <text x="20" y="50" class="sub">Erzeugte Artefaktkarten in den Slot legen · „lebende" Artefakte per Status-Marker weiterschieben (E→F→A) · Gxx = von Gate gefordert</text>
-
-  <!-- Spalten-Header -->
-  <rect x="20"  y="70" width="150" height="30" rx="4" fill="#6b7686"/><text x="95"  y="90" class="hdr">Eingang (DPM)</text>
-  <rect x="178" y="70" width="150" height="30" rx="4" fill="#2f80c9"/><text x="253" y="90" class="hdr">Design</text>
-  <rect x="336" y="70" width="150" height="30" rx="4" fill="#e8862b"/><text x="411" y="90" class="hdr">Transition</text>
-  <rect x="494" y="70" width="150" height="30" rx="4" fill="#2f9e57"/><text x="569" y="90" class="hdr">Operation</text>
-  <rect x="652" y="70" width="150" height="30" rx="4" fill="#18a9a0"/><text x="727" y="90" class="hdr">Support</text>
-  <rect x="810" y="70" width="150" height="30" rx="4" fill="#8358c6"/><text x="885" y="90" class="hdr">Review</text>
-
-  <!-- ===== Eingang ===== -->
-  <g transform="translate(20,110)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#6b7686"/><text x="12" y="20" class="anum">A1</text><text x="12" y="36" class="aname">Projektauftrag</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-
-  <!-- ===== Design ===== -->
-  <g transform="translate(178,110)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#2f80c9"/><text x="12" y="20" class="anum">A2 Service-Definition</text>
-    <text x="12" y="36" class="aname">lebt (Review aktualisiert)</text>
-    <circle cx="14" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="22" y="55" class="stat">E</text>
-    <circle cx="46" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="54" y="55" class="stat">F</text>
-    <circle cx="78" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="86" y="55" class="stat">A</text>
-    <rect x="110" y="6" width="32" height="14" rx="3" fill="#1d2430"/><text x="126" y="16" class="gate">G1·G3</text></g>
-  <g transform="translate(178,186)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#2f80c9"/><text x="12" y="20" class="anum">A3 Service Design Doc</text><text x="12" y="36" class="aname">Architektur / WIE</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text><rect x="120" y="6" width="22" height="14" rx="3" fill="#1d2430"/><text x="131" y="16" class="gate">G1</text></g>
-  <g transform="translate(178,262)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#2f80c9"/><text x="12" y="20" class="anum">A4 Impl. Blueprint</text><text x="12" y="36" class="aname">Einführungsplan</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text><rect x="120" y="6" width="22" height="14" rx="3" fill="#1d2430"/><text x="131" y="16" class="gate">G1</text></g>
-
-  <!-- ===== Transition ===== -->
-  <g transform="translate(336,110)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#e8862b"/><text x="12" y="20" class="anum">A5 Gate-/SOR-Vorlage</text><text x="12" y="36" class="aname">Gate-Anträge</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-  <g transform="translate(336,186)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#e8862b"/><text x="12" y="20" class="anum">A6 Betriebsdoku</text><text x="12" y="36" class="aname">Manual/Handbuch</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text><rect x="110" y="6" width="32" height="14" rx="3" fill="#1d2430"/><text x="126" y="16" class="gate">G2·G3</text></g>
-  <g transform="translate(336,262)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#e8862b"/><text x="12" y="20" class="anum">A7 Test-Report</text><text x="12" y="36" class="aname">Testprotokolle</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text><rect x="110" y="6" width="32" height="14" rx="3" fill="#1d2430"/><text x="126" y="16" class="gate">G2·G3</text></g>
-  <g transform="translate(336,338)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#e8862b"/><text x="12" y="20" class="anum">A8 Aktivierter Service</text><text x="12" y="36" class="aname">Ergebnis Gate 3</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-
-  <!-- ===== Operation ===== -->
-  <g transform="translate(494,110)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#2f9e57"/><text x="12" y="20" class="anum">A9 Qualitätsbericht</text><text x="12" y="36" class="aname">SLA/KPIs (+Monitoring)</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-
-  <!-- ===== Support ===== -->
-  <g transform="translate(652,110)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#18a9a0"/><text x="12" y="20" class="anum">A10 Incident Record</text><text x="12" y="36" class="aname">inkl. Request Record</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-  <g transform="translate(652,186)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#18a9a0"/><text x="12" y="20" class="anum">A11 Problem Record</text><text x="12" y="36" class="aname">lebt (sp_09→sp_11)</text>
-    <circle cx="14" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="22" y="55" class="stat">E</text>
-    <circle cx="46" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="54" y="55" class="stat">F</text>
-    <circle cx="78" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="86" y="55" class="stat">A</text></g>
-  <g transform="translate(652,262)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#18a9a0"/><text x="12" y="20" class="anum">A12 Workaround</text><text x="12" y="36" class="aname">→ Wissensdatenbank</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-  <g transform="translate(652,338)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#18a9a0"/><text x="12" y="20" class="anum">A13 Wissensdatenbank</text><text x="12" y="36" class="aname">lebt (sp_02 ← sp_11)</text>
-    <circle cx="14" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="22" y="55" class="stat">E</text>
-    <circle cx="46" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="54" y="55" class="stat">F</text>
-    <circle cx="78" cy="52" r="4" fill="none" stroke="#6b7686"/><text x="86" y="55" class="stat">A</text></g>
-
-  <!-- ===== Review ===== -->
-  <g transform="translate(810,110)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#8358c6"/><text x="12" y="20" class="anum">A14 Review-Bericht</text><text x="12" y="36" class="aname">4-Dim.-Ampel</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-  <g transform="translate(810,186)"><rect class="slot" width="150" height="64" rx="6"/><rect width="5" height="64" rx="2" fill="#8358c6"/><text x="12" y="20" class="anum">A15 DPM-Rücklauf</text><text x="12" y="36" class="aname">Demand / Retirement</text><circle cx="14" cy="52" r="4" fill="#2f9e57"/><text x="24" y="55" class="stat">Final</text></g>
-
-  <!-- Legende -->
-  <g transform="translate(20,440)">
-    <text x="0" y="0" class="h1" style="font-size:13px">Legende</text>
-    <text x="0" y="22" class="lgd">Status-Marker: <tspan font-weight="700">E</tspan> Entwurf → <tspan font-weight="700">F</tspan> Final → <tspan font-weight="700">A</tspan> Aktualisiert (nur „lebende" Artefakte: A2, A11, A13)</text>
-    <rect x="0" y="34" width="32" height="14" rx="3" fill="#1d2430"/><text x="16" y="44" class="gate">G1</text>
-    <text x="40" y="45" class="lgd">= Gate fordert dieses Artefakt (Gate öffnet nur, wenn es in der Akte liegt). G1: A2·A3·A4 · G2: A6·A7 · G3: A6·A7·A2 → A8</text>
-  </g>
-</svg>

04_Tablet-Quiz/README.md

@@ -63,19 +63,19 @@ steht, sondern in der App liegt.
 
 ```
 [1] Action Card ziehen  → Raster aller Karten-Grafiken, eine antippen
-[2] Change-Art bestimmen → 5 Change-Arten + Legende; falsch = "nochmal", richtig = weiter
+[2] Change-Art bestimmen → 4 Change-Arten + Legende; falsch = "nochmal", richtig = weiter
 [3] Erfolgreiche Kategorisierung → kurze Bestätigung + Warum
 [4] Einstieg finden     → Lebenszyklus groß: Phase anklicken (falsch = "nochmal")
 [5] Los geht's          → App nennt Start-Station + Begründung
    → App führt ab Start-Station durch die Stationen (Fortschritt sichtbar)
-   → Aktivitäts-Station (2 Takte):
-       → Handeln am Brett: Figuren ins RACI-Feld, Artefaktkarte in die Service-Akte
-         (App fragt; "Zeig mir" als Hilfe, wenn die Gruppe nicht weiterkommt)
-       → Auflösung & Abgleich: App zeigt RACI/Artefakt → Brett korrigieren, "unklar" markieren
-       → "Nächste Station"
-   → Gate-Station: Kriterien prüfen (Artefakte in der Akte? Pflicht-Figuren?)
+   → Aktivitäts-Station (schrittweiser Mikro-Ablauf, 4 Fragen je einzeln + Auflösung):
+       → (1) Was steckt hinter der Überschrift? (2) Beteiligte Rollen → Figuren auf die Puck-Mulden
+       → (3) RACI → Figuren ins Aktiv-Feld (R/A/C/I), mit RACI-Legende
+       → (4) Artefakt als Choice → kommt in die digitale Service-Akte (Panel "📁 Akte")
+       → Abschluss-Screen ("✓ Aktivität abgeschlossen"; an Phasengrenzen 🎉-Feedback) → "Nächste Station"
+   → Gate-Station: App prüft die geforderten Artefakte (fehlen sie → Entscheidung gesperrt) + Pflicht-Figuren
        → Entscheidung wählen (Go/Auflagen/Zurück/Ablehnung bzw. Entwicklung/Konfiguration)
-       → Konsequenz + Verzweigung (z.B. Konfiguration überspringt den Build;
+       → Konsequenz + Verzweigung (Konfiguration überspringt den Build; echte Rückschleifen;
          reicht die SOR-Hoheit nicht → Demand via DPM ans Mission Board)
    → [Ende] → Debrief-Export (bearbeitete Stationen, unklare, Pfad)
 ```

04_Tablet-Quiz/app/index.html

@@ -912,21 +912,51 @@ const STATIONEN = [
    Die Akte ist rein digital: erzeugte Artefakte werden per Choice bestimmt und
    gesammelt; Gates sind hart gekoppelt (oeffnen nur mit den geforderten Artefakten). */
 const ARTEFAKTE = {
-  A1:{name:"Projektauftrag", phase:"design"},
-  A2:{name:"Service-Definition", phase:"design", live:true},
-  A3:{name:"Service Design Document", phase:"design"},
-  A4:{name:"Implementation Blueprint", phase:"design"},
-  A5:{name:"Gate-/SOR-Vorlage", phase:"transition"},
-  A6:{name:"Betriebsdokumentation", phase:"transition"},
-  A7:{name:"Test-Report", phase:"transition"},
-  A8:{name:"Aktivierter Service", phase:"transition"},
-  A9:{name:"Service-Qualitätsbericht", phase:"operation"},
-  A10:{name:"Incident Record", phase:"support"},
-  A11:{name:"Problem Record", phase:"support", live:true},
-  A12:{name:"Workaround", phase:"support"},
-  A13:{name:"Wissensdatenbank-Eintrag", phase:"support", live:true},
-  A14:{name:"Service-Review-Bericht", phase:"review"},
-  A15:{name:"DPM-Rücklauf", phase:"review"}
+  A1:{name:"Projektauftrag", phase:"design",
+    was:"Der freigegebene Auftrag aus dem Demand-Lifecycle: Ziel, Rahmen, benannte Projektleitung sowie zugesagtes Budget und Ressourcen (nach DSR/MB-Freigabe).",
+    warum:"Er ist das Startsignal und Mandat für die Design-Phase — ohne ihn gibt es weder einen legitimierten Start noch zugewiesene Ressourcen."},
+  A2:{name:"Service-Definition", phase:"design", live:true,
+    was:"Zweck, Nutzen und Zielgruppen des Services, Utility & Warranty, die SLA-/SLO-Anforderungen sowie Abhängigkeiten zu anderen Services.",
+    warum:"Sie legt fachlich fest, WAS der Service leisten soll — der Bezugspunkt für Design, Betrieb und das spätere Review."},
+  A3:{name:"Service Design Document", phase:"design",
+    was:"Servicearchitektur (Komponenten, Schnittstellen), Design der Betriebs- und Supportprozesse, Security/Datenschutz/Compliance, Monitoring/Reporting und das Rollenmodell.",
+    warum:"Es übersetzt das „Was“ der Service-Definition in das WIE — der technische und organisatorische Bauplan und Voraussetzung für Gate 1."},
+  A4:{name:"Implementation Blueprint", phase:"design",
+    was:"Plan zur organisatorischen Einführung: Integration, Rollenübergaben, Anpassung von Prozessen/Tools, Trainings & Kommunikation, Bewertung der Time-to-Operate.",
+    warum:"Er stellt sicher, dass der Service nicht nur gebaut, sondern auch wirklich in die Organisation eingeführt und übernommen werden kann."},
+  A5:{name:"Gate-/SOR-Vorlage", phase:"transition",
+    was:"Die Entscheidungsvorlage für ein Gate: Aufwand/Risiken/Budget, Empfehlung und die zu prüfenden Dimensionen. An Gate 2 als „Transition-Steckbrief“.",
+    warum:"Sie macht Gate-Entscheidungen nachvollziehbar und legitimiert — ohne Vorlage keine SOR-/SO-Freigabe."},
+  A6:{name:"Betriebsdokumentation", phase:"transition",
+    was:"Service Operation Manual, Betriebshandbuch, Arbeitsanweisungen, Eskalationswege, Standard Changes, Known Errors und Konfigurations-/Betriebsrichtlinien.",
+    warum:"Sie macht den Service betreib- und supportbar — ohne sie kein stabiler Regelbetrieb und keine schnelle, einheitliche Störungsbehebung."},
+  A7:{name:"Test-Report", phase:"transition",
+    was:"Ergebnisse von Funktions-, Integrations- und Abnahmetests, der Nachweis der Betriebsreife sowie Testprotokolle und Freigaben.",
+    warum:"Er belegt, dass der Service funktioniert, BEVOR er live geht — Grundlage für die Freigabe an Gate 2."},
+  A8:{name:"Aktivierter Service", phase:"transition",
+    was:"Der freigegebene, produktive Service inklusive Aufnahme ins Portfolio und aktiviertem Katalog-Eintrag (ggf. mit Support-Dokumentation).",
+    warum:"Es markiert den offiziellen Go-Live — ab hier ist der Service in Betrieb und im Portfolio sichtbar und steuerbar."},
+  A9:{name:"Service-Qualitätsbericht", phase:"operation",
+    was:"SLA-/SLO-Auswertung, technische KPIs (Verfügbarkeit, Response Time), Abgleich gegen Qualitätsziele und Verbesserungspotenziale — inkl. Monitoring-/Betriebsdaten.",
+    warum:"Er zeigt objektiv, ob der Service seine Versprechen hält, und ist die Zuarbeit fürs Review."},
+  A10:{name:"Incident Record", phase:"support",
+    was:"Aufnahme, Bearbeitung, Lösung und Abschluss einer Störung oder eines Service Requests — inklusive Klassifizierung für Auswertungen. (Trägt auch den Request Record.)",
+    warum:"Es dokumentiert Störungen/Anfragen nachvollziehbar, sichert SLA-Konformität und liefert Daten für Trendanalysen."},
+  A11:{name:"Problem Record", phase:"support", live:true,
+    was:"Beschreibung, Symptome und Diagnosewege, bekannte Workarounds, die Ursache (Root Cause, wenn gefunden), Change-Bedarf sowie Status und Priorität.",
+    warum:"Es bündelt die strukturelle Ursachenarbeit hinter wiederkehrenden oder ungelösten Incidents — das einzige im Blueprint formal definierte Artefakt."},
+  A12:{name:"Workaround", phase:"support",
+    was:"Eine vorläufige Umgehungslösung, die den Betrieb stabil hält, bis die eigentliche Ursache behoben ist — mit Eintrag in die Wissensdatenbank.",
+    warum:"Es hält den Service nutzbar, obwohl die Ursache noch offen ist, und reduziert den Druck auf den Support."},
+  A13:{name:"Wissensdatenbank-Eintrag", phase:"support", live:true,
+    was:"Standardlösungen, Known Errors, Workarounds, FAQ und Anleitungen — das zentrale Arbeitsmittel für 1st und 2nd Level Support.",
+    warum:"Es beschleunigt den Support, sichert konsistente Antworten und entlastet die höheren Support-Level."},
+  A14:{name:"Service-Review-Bericht", phase:"review",
+    was:"Das „Service Performance & Improvement Review“: Bewertung über 4 Dimensionen (Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit) per Ampel und eine Handlungsempfehlung (CONTINUE / IMPROVEMENT / REDESIGN / RETIRE).",
+    warum:"Es liefert die strukturierte Grundlage für die SOR-Entscheidung über die Zukunft des Service."},
+  A15:{name:"DPM-Rücklauf", phase:"review",
+    was:"Die Übergabe an den Demand-Lifecycle — Variante A: Neuer Demand (Redesign/Erweiterung) oder Variante B: Retirement-Plan / Decommissioning-Auftrag (Stilllegung).",
+    warum:"Es schließt den Lebenszyklus: größere Änderungen oder das Ende eines Service laufen kontrolliert über den Demand-Lifecycle, nicht „nebenbei“."}
 };
 // Welche Station erzeugt welches A-Artefakt (Choice-Schritt -> Aufnahme in die Akte).
 const STATION_ARTEFAKT = {
@@ -1291,7 +1321,7 @@ function activitySteps(st){
       legend: raciLegendHtml(),
       auf:`<h4 class="aufH">RACI</h4>${raciTable(st)}` },
     { label:"Artefakt", artefakt:true,
-      frage:`Welche <b>Artefaktkarte</b> entsteht hier und gehört in die <b>Service-Akte</b>?`,
+      frage:`Welches <b>Artefakt</b> entsteht hier und kommt in die <b>Service-Akte</b>?`,
       auf:`<h4 class="aufH">Artefakt</h4><p style="margin:0"><b>${st.artefakt}</b></p>` }
   ];
 }
@@ -1353,11 +1383,17 @@ function renderActivity(st){
     html += `<div class="choiceGrid">${opts}</div>`;
     if(S.arteWrong) html += `<div class="hint bad">Nicht ganz — überlegt nochmal, welches Ergebnis diese Station liefert.</div>`;
   } else if(S.actReveal){
-    if(isArteChoice)
-      html += `<div class="aufBox"><h4 class="aufH">Artefakt</h4><p style="margin:0">✓ <b>${arteId} — ${ARTEFAKTE[arteId].name}</b> in die Service-Akte gelegt.</p></div>`;
-    else
+    if(isArteChoice){
+      const A = ARTEFAKTE[arteId];
+      html += `<div class="aufBox">
+        <p style="margin:0 0 12px">✓ <b>${arteId} — ${A.name}</b> in die Service-Akte gelegt.</p>
+        <h4 class="aufH">Was umfasst es?</h4><p style="margin:0 0 10px">${A.was}</p>
+        <h4 class="aufH">Warum brauchen wir es?</h4><p style="margin:0">${A.warum}</p>
+      </div>`;
+    } else {
       html += `<div class="aufBox">${step.auf}</div>`;
     }
+  }
 
   let actions = `<div class="actions">`;
   if(S.actReveal || i>0) actions += `<button class="ghost" id="actBack">← zurück</button>`;
@@ -1395,7 +1431,7 @@ function renderGate(st){
       <div>
         <p>${st.beschreibung}</p>
         <ul class="crit">${pruef}</ul>
-        <p class="muted">Artefaktkarten in der Akte? Pflicht-Figuren am Gate-Puck?</p>
+        <p class="muted">Geforderte Artefakte in der Akte (siehe oben)? Pflicht-Figuren am Gate-Puck?</p>
       </div>
     </details>`;
 }

04_Tablet-Quiz/app/sw.js

@@ -1,5 +1,5 @@
 /* Service Worker — SLC-Workshop Companion (App-Shell, offline-first) */
-const CACHE = "slc-companion-v9";
+const CACHE = "slc-companion-v11";
 const SHELL = ["./", "index.html", "manifest.webmanifest", "icon.svg"];
 // Action-Card-Grafiken (cards/s<service>-c<change>.png) fuer Offline vorab cachen (alle 30).
 const CARDS = [];

PROJEKTSTAND.md

@@ -21,7 +21,7 @@ Operations/Service-Owner/Support. Mix aus **Vermittlung** (Lifecycle + Stationen
 | `00_Konzept/` | Gesamtkonzept (`README_konzept.md`, v0.5) + Arbeitsstand-Notizen |
 | `01_3D-Druck/` | Materialliste, OpenSCAD-Modelle, Board-Layout-Generator, Visual-Prompts |
 | `02_Spielfiguren/` | Rollen-Figuren (38), Farbcodierung, Gate-Besetzung |
-| `03_Karten/` | Action/Störungs/Artefaktkarten, Service-Akte |
+| `03_Karten/` | Action/Störungskarten + Artefakt-Katalog A1–A15 (Service-Akte = App-Element) |
 | `04_Tablet-Quiz/` | **Companion-App** (`app/` = deploybare PWA) + Konzept |
 | `05_Workshop-Dokumentation/` | Logbuch, Reflexion, Debrief |
 
@@ -43,7 +43,9 @@ Operations/Service-Owner/Support. Mix aus **Vermittlung** (Lifecycle + Stationen
 ### Karten (`03_Karten/`)
 - **Action Cards:** 24 finale Grafiken (Freiburg-digital-Layout) liegen in
   `04_Tablet-Quiz/app/cards/s<service>-c<change>.png` (6 Services × 4 Change-Arten).
-- **Artefaktkarten A1–A15 + Service-Akte** (Tableau, liegt **neben der aktuellen Station**).
+- **Service-Akte = App-Element:** Artefakte **A1–A15** werden in der App per **Choice**
+  gesammelt; **harte Gate-Kopplung** (Gate öffnet nur mit den geforderten Artefakten,
+  Akte beim Einstieg vorbefüllt). Keine physischen Artefaktkarten / kein Tableau / kein 3D-Teil.
 - **Gate-Entscheidung** (Go / Auflagen / Zurück / Ablehnung) trifft die zuständige Rolle
   **in der App**; die entscheidende Rolle bleibt als Marker am Gate-Puck. **Keine Chips,
   keine Gate-Karte mehr**.
@@ -52,10 +54,12 @@ Operations/Service-Owner/Support. Mix aus **Vermittlung** (Lifecycle + Stationen
 **Flow:** Karten-Raster (Action Card ziehen) → **Change-Art klassifizieren** (Legende,
 „nochmal" bis richtig) → **Phasen-Einstieg** (Lebenszyklus-Phase anklicken, retry) →
 **Stationen** → **Abschluss-Screen** („abgeschlossen" oder „abgelehnt").
-- **Aktivitäts-Station, 2 Takte:** „Handeln am Brett" → „Auflösung & Abgleich".
-  **Figuren-Regel (zweistufig):** (1) beteiligte Rollen auf die **Mulden des
-  Station-Pucks** stellen, (2) dieselben Figuren ins **Aktiv-Feld (R·A·C·I)**
-  einsortieren = RACI-Antwort. Artefaktkarte in die Akte; „Zeig mir"-Hilfe.
+- **Aktivitäts-Station, schrittweiser Mikro-Ablauf** (4 Fragen, je einzeln + Auflösung):
+  (1) Was steckt hinter der Überschrift? (2) Beteiligte Rollen → Figuren auf die
+  **Puck-Mulden**; (3) **RACI** → Figuren ins **Aktiv-Feld (R·A·C·I)** (mit RACI-Legende);
+  (4) **Artefakt als Choice** → in die App-Akte. Danach eigener **Abschluss-Screen**
+  („✓ Aktivität abgeschlossen", an Phasengrenzen zusätzlich 🎉-Phasen-Feedback).
+  Aufgaben jeweils im farbigen Aufgaben-Kasten.
 - **Gate-Station interaktiv:** Kriterien prüfen → Entscheidung → Konsequenz +
   **Verzweigung**. **Echte Rückschleifen:** „Zurück an Build/Transition" springt
   zurück, blendet einen Nacharbeits-Banner ein und legt das Gate danach **erneut**

README.md

@@ -25,7 +25,7 @@ richtigen Rollen-Figuren physisch zusammenkommen müssen.
 2. **Szenario / Action Card** — die gezogene Karte liegt flach an der aktuellen Station und wandert mit; die App führt die Reihenfolge, gestellte Figuren markieren „wir sind hier" (kein Spielstein).
 3. **RACI-Aktiv-Feld** — quadratisches Board (2×2: R|A / C|I) neben der aktuellen Station; beteiligte Rollen werden je Aktivität in die Zonen R/A/C/I gestellt. Gates sind rote Pucks mit Pflicht-Versammlung.
 4. **Phasen-Ring** — 5 farbige Segmente: zusammengesteckt die SLC-Übersicht, auseinandergenommen die Phasen-Köpfe der Bahn (Design = Start).
-5. **Artefakt- & Störungskarten** — machen Ergebnisse (Service-Akte) und die Operation↔Support-Schleife greifbar.
+5. **Störungskarten** — machen die Operation↔Support-Schleife greifbar. Die **Service-Akte** (Artefakte A1–A15) läuft in der App: Artefakte werden per Choice gesammelt, Gates sind hart gekoppelt.
 6. **Companion-App (Lernschleife)** — führt die Stationsreihenfolge, stellt pro Station ein vermittelndes Quiz, liefert die Auflösung und protokolliert Verständnislücken.
 
 ## Ordnerübersicht
@@ -35,7 +35,7 @@ richtigen Rollen-Figuren physisch zusammenkommen müssen.
 | [`00_Konzept/`](00_Konzept/) | Gesamtkonzept: Board, Phasen, Gates, Mechaniken, Spielablauf, Didaktik |
 | [`01_3D-Druck/`](01_3D-Druck/) | Materialliste mit Maßen, OpenSCAD-Modelle, Visual-Prompts für den 3D-Druck-Producer |
 | [`02_Spielfiguren/`](02_Spielfiguren/) | Rollen-Figuren, Farbcodierung, Gate-Zuordnung |
-| [`03_Karten/`](03_Karten/) | Action Cards, Störungs-, Artefakt- und Entscheidungskarten + Druckmaße |
+| [`03_Karten/`](03_Karten/) | Action Cards, Störungskarten + Artefakt-Katalog A1–A15 (Service-Akte = App) |
 | [`04_Tablet-Quiz/`](04_Tablet-Quiz/) | Eigenständiges Teilprojekt: Begleit-App (Konzept & Architektur) |
 | [`05_Workshop-Dokumentation/`](05_Workshop-Dokumentation/) | Logbuch-Vorlage, Reflexionskarten, Debrief |
 
@@ -50,6 +50,5 @@ richtigen Rollen-Figuren physisch zusammenkommen müssen.
 | Rollen-Figuren | ✅ | — | — |
 | Rundetiketten Ø37 (Station-/Gate-ID) | — | ✅ | — |
 | Action Cards / Störungskarten | — | ✅ | — |
-| Artefaktkarten / Service-Akte | — | ✅ | — |
 | Logbuch / Reflexionskarten | — | ✅ | — |
-| Companion-App (Quiz + Auflösung) | — | — | ✅ |
+| Companion-App (Quiz, Auflösung, Service-Akte A1–A15) | — | — | ✅ |

visual-prompts_nano-banana.md

@@ -33,8 +33,7 @@ board with four outlined fields in a 2x2 grid labelled R, A (top) and C, I (bott
 with several chunky 50mm miniature figures standing in the fields and in the puck
 wells. A flat "Action Card" lies next to the current puck. At the start of the track,
 five colour segments form a "phase ring" header (DESIGN/TRANSITION/OPERATION/SUPPORT/
-REVIEW). A small printed dossier sheet ("Service-Akte") with little artefact cards lies
-to the side, plus a few round decision coins. Miniatures colour-coded by role category
+REVIEW). Miniatures colour-coded by role category
 (gold, deep bordeaux, blue, grey, white, and green team figures). Wide composition,
 cohesive matte PLA set, soft studio light, premium look.
 ```
@@ -99,18 +98,7 @@ background, soft light, emphasis on the red colour and the "committee gathers to
 decide" idea.
 ```
 
-## 7. Service-Akte (Artefakt-Tableau)
-
-```
-Top-down render of a printed A4 landscape dossier sheet labelled "Service-Akte",
-organised into columns by phase colour, with 15 labelled card slots. Several small
-playing cards (bridge size) are placed into slots, each showing an artefact name; a
-few slots show a small status track (Entwurf - Final - Aktualisiert) with a marker.
-Some slots carry a small "Gate required" badge. Clean infographic-meets-board-game
-look, neutral background, soft even light, crisp legible layout.
-```
-
-## 8. Phasen-Ring (Übersicht ↔ Köpfe)
+## 7. Phasen-Ring (Übersicht ↔ Köpfe)
 
 ```
 Product render of a colour-coded "phase ring": a flat donut (about 180mm outer, 84mm