patrick/SLC_Game
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

v11

Browse source
This commit is contained in:
breitenbach76 2026-06-07 15:02:35 +02:00
parent 7d474a054e
commit 0eddf2b322
11 changed files with 118 additions and 342 deletions
Download patch file Download diff file Expand all files Collapse all files

10
00_Konzept/README_konzept.md
View file

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