v9

00_Konzept/README_konzept.md

@@ -11,7 +11,8 @@
 > - **Action-Stein entfällt** — die Action Card liegt flach an der aktuellen Station;
 >   die App führt die Reihenfolge, die gestellten Figuren markieren „wir sind hier".
 > - **Gate-Tore + Gate-Karten entfallen** — ein Gate ist ein **roter Puck**; Keeper,
->   Artefakte und Auflösung laufen über App + Entscheidungs-Chips.
+>   Artefakte und Auflösung laufen über die App (die entscheidende Rolle bleibt als
+>   Marker am Gate-Puck stehen).
 > - **Aktiv-Feld** ist jetzt **quadratisch (2×2: R|A / C|I)**.
 > - Neu: **Phasen-Ring** — zusammengesteckt die SLC-Übersicht, auseinandergenommen
 >   die farbigen Phasen-Köpfe der Bahn (Design-Segment = Start).
@@ -91,7 +92,7 @@ Die **Etikett-Kurzbezeichnung** (ID + Name) und die **App-Auflösung** werden be
 
 Ein Gate ist ein **roter Puck** (Etikett `G1`/`G2`/`G3` + Entscheidungs-Icon). Die
 Pflicht-Figuren werden in seine Figurenmulden gestellt; sonst „öffnet" das Gate
-nicht. Entscheidungspfade als Chips: **Go / Go mit Auflagen / Zurück / Ablehnung**
+nicht. Entscheidungspfade (in der App): **Go / Go mit Auflagen / Zurück / Ablehnung**
 (exakt die im Blueprint dokumentierten Pfade). Gate 1 verzweigt zusätzlich
 **Entwicklung (tr_02)** vs. **Konfiguration (tr_05)**.
 
@@ -133,10 +134,9 @@ formcodiert. Figuren werden **gestellt, nicht gesteckt**; es gibt **zwei** Orte:
 Alle Standfelder sind Ø 22 (gleich wie die Puck-Mulden — dieselben Ø-20-Figuren).
 Details & Designvarianten: [`../02_Spielfiguren/`](../02_Spielfiguren/).
 
-### 5.4 Weitere Karten & Chips
+### 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/).
 - **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.
-- **Entscheidungs-Chips:** Go / Go mit Auflagen / Zurück / Ablehnung.
 - **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).
 
@@ -175,7 +175,7 @@ Schwach beantwortete Stationen werden protokolliert (→ Abschnitt 8). MVP-Scope
    (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),
-   Entscheidungs-Chip wählen, weiterziehen.
+   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.
 8. **Debrief:** Logbuch & Reflexion (→ [`../05_Workshop-Dokumentation/`](../05_Workshop-Dokumentation/)).