SLC_Game/04_Tablet-Quiz/README.md

Tablet-Quiz — Begleit-App (Teilprojekt)

Status: App lauffähig (PWA) · Deploy vorbereitet · Typ: eigenständiges Software-Teilprojekt des SLC-Workshops

Umsetzungsstand: Die App liegt unter app/ als statische PWA (offline-/kioskfähig). Flow: Karten-Raster (Action Card ziehen) → Change-Art bestimmen (mit Legende, „nochmal versuchen" bis richtig) → Phasen-Einstieg (Lebenszyklus-Phase anklicken) → Stationen (Handeln am Brett → Auflösung; Gates als Entscheidung) → Debrief mit Markdown-/JSON-Export. Inhalte (Stationen, Quizfragen, Use-Cases) sind derzeit in app/index.html eingebettet. Die finalen Action-Card-Grafiken (Freiburg-digital-Layout) liegen in app/cards/ (s<service>-c<change>.png, 24 = 6 Services × 4 Change-Arten; Major/Normal/Standard/Emergency). Deployment: statisch, siehe app/DEPLOY.md. Lokal testen: python -m http.server 8099 --directory 04_Tablet-Quiz/app (oder Preview-Config .claude/launch.json).

Das Tablet-Quiz ist der digitale Begleiter des Tabletops — kein Ersatz fürs Brett. Es ist der erklärende Gegenpart zu den Pucks: Die Pucks tragen nur die Kurzbezeichnung (Etikett), die ausführliche Erklärung liefert die App. Sie führt die Stationsreihenfolge (linearer Lifecycle), stellt pro Station ein vermittelndes Quiz, gibt danach die ausführliche Auflösung und protokolliert Verständnislücken fürs Debrief.

---

1. Ziel & Rolle im Spiel

• Stationsführung: schaltet Station für Station automatisch weiter („Nächste Station") — die Pucks brauchen keinen Code.
• Active Recall verstärken: erst Diskussion am Board, dann vermittelndes Quiz, dann Auflösung — Gruppe rät, App bestätigt/korrigiert.
• Vollständige Erklärung: liefert nach dem Quiz die ausführliche Auflösung (die nicht auf dem Puck steht) aus dem Blueprint (Single Source of Truth).
• Dokumentation: erfasst automatisch, welche Aktivitäten unklar waren (→ ../05_Workshop-Dokumentation/).

Bewusst nicht das Ziel: das Spiel digital ersetzen, Echtzeit-Multiplayer, Accounts/Login, Cloud-Pflicht.

2. Datengrundlage (keine Doppelpflege)

Die App liest ausschließlich die bestehenden Blueprint-Dateien und leitet Fragen daraus ab:

Quelle	liefert
service-lifecycle_*.yaml	Aktivitäten, Beschreibungen, Reihenfolge, Gates
spm_rollen.yaml	Rollen, RACI, Gate-Keeper

Ein Build-Schritt konvertiert die YAMLs in ein statisches questions.json. Damit bleibt der Blueprint die einzige Wahrheit; Inhalte werden nie im App-Code dupliziert.

3. Fragetypen

1. Reihenfolge: „Was kommt nach tr_08?"
2. Rolle / RACI: „Wer ist Accountable für op_06?"
3. Artefakt: „Welches Artefakt entsteht bei tr_07?"
4. Gate-Logik: „Wer muss an Gate 1 zustimmen?" / „Welche Pfade gibt es?"
5. Zuordnung: „In welcher Phase liegt sp_09?"

Jede Frage: Gruppentipp → Auflösen-Button → Modellantwort. Im Anschluss an das Quiz folgt die ausführliche Auflösung der Station (vollständige Beschreibung + Rollen/RACI + Artefakt aus der YAML) — der Inhalt, der bewusst nicht auf dem Puck steht, sondern in der App liegt.

4. Ablauf (UI-Flow)

[1] Action Card ziehen  → Raster aller Karten-Grafiken, eine antippen
[2] Change-Art bestimmen → 5 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?)
       → Entscheidung wählen (Go/Auflagen/Zurück/Ablehnung bzw. Entwicklung/Konfiguration)
       → Konsequenz + Verzweigung (z.B. Konfiguration überspringt den Build;
         reicht die SOR-Hoheit nicht → Demand via DPM ans Mission Board)
   → [Ende] → Debrief-Export (bearbeitete Stationen, unklare, Pfad)

5. Funktionsumfang (MVP)

• Stationsführung: linearer Durchlauf mit „Nächste Station" + Fortschritt/Phasen-Farben.
• Fragetypen 1–3 (vermittelndes Quiz).
• „Auflösen"-Mechanik (Antwort erst auf Klick) + ausführliche Stationsauflösung (Erklärung/RACI/Artefakt) nach dem Quiz.
• „Unklar"-Markierung je Aktivität.
• Debrief-Export (Markdown und JSON, lokaler Download).
• PWA / offline lauffähig (Manifest + Service Worker).
• questions.json + Stations-Inhalte aus YAMLs generieren (Build-Skript) — Inhalte aktuell in app/index.html eingebettet (braucht Blueprint-Repo-Zugriff).

Später (Ausbau)

• Gate-Fragen mit Rollen-Check (Typ 4–5).
• Mehrere Szenarien mit unterschiedlichen Fragesets.
• Punktestand / Team-Modus.
• Mehrsprachigkeit.

6. Technik-Empfehlung

• Single-Page-Web-App, offline lauffähig (PWA), passt zum bestehenden HTML-first-Stil im Repo (vgl. MB-Retro-HTMLs).
• Kein Backend nötig: statisches questions.json + LocalStorage für das Logbuch.
• Tablet im Kiosk-/Vollbildmodus; keine Konten, keine Cloud.
• Stack-Vorschlag: Vanilla JS oder leichtes Framework, ein Build-Skript (Node/Python) für die YAML→JSON-Konvertierung.

7. Schnittstellen zum restlichen Spiel

• Eingang: Szenarioauswahl = gezogene Action Card (../03_Karten/).
• Inhalt: Aktivitäten/Gates/Rollen = Brett-Elemente (../00_Konzept/).
• Ausgang: Debrief-Daten → Workshop-Dokumentation (../05_Workshop-Dokumentation/).

8. Companion-Chatbot (optional · Nachschlage-Begleiter)

Idee: Teilnehmende stellen spontane Verständnisfragen, die das feste Quiz nicht abdeckt — z. B. „Was ist das Service Design Document?" oder „Wer ist an Gate 2 accountable?". Der Bot beantwortet sie aus dem Blueprint.

Rolle & Grenzen (didaktisch)

• Nachschlagen, nicht führen. Der Bot ersetzt nicht die Stationsführung. Das Lernprinzip (erst Gruppendiskussion → Tipp → App-Auflösung) bleibt das Rückgrat; ein frei führender Bot würde das „produktive Ringen" aushebeln.
• Freischaltung gated: pro Station erst nach dem „Auflösen" verfügbar (oder als klar getrennter „Frag nach"-Knopf), damit er das Diskutieren-zuerst nicht kurzschließt.
• Scope-begrenzt: antwortet nur aus dem Blueprint, keine freie Beratung; bei Unklarheit Verweis auf den „Unklar"-Marker → Debrief.

Datengrundlage

• Der Lifecycle-Blueprint ist klein (~2.000 Zeilen YAML). Kein RAG/Vektor-Setup nötig — alle service-lifecycle_*.yaml + spm_rollen.yaml passen in einen einzigen System-Prompt-Kontext.
• Single Source of Truth bleibt der Blueprint (keine Doppelpflege).

Wiederverwendung statt Neubau

• Im Repo existiert bereits ein Bot: #099_tools/digitom-bot/ mit Knowledge-Base (SPM_service-lifecycle_*.md) und Dify-Upload. Vor Neubau prüfen, ob dieser als Begleiter angedockt werden kann.

Offene Architektur-Entscheidung: Offline vs. Cloud

Ein Laufzeit-LLM braucht einen API-Aufruf → Internet/Endpoint/Key. Das steht im Konflikt zur Konzept-Bedingung (offline, Kiosk, keine Cloud, kein Login; vgl. Abschnitt 6). Optionen:

Variante	Pro	Contra
(a) Cloud-LLM (Dify / Anthropic / Azure-OpenAI)	geringster Aufwand, beste Qualität	Online-Pflicht, Datenschutz-/Beschaffungsfreigabe
(b) Lokales LLM (z. B. Ollama auf dem Gerät)	offline-konform	Hardware-/Setup-Aufwand, schwächere Qualität
(c) Statische FAQ (vorab generierte Q&A aus Blueprint)	voll offline, keine Kosten	keine Freitextfragen, begrenzte Abdeckung

Empfehlung für den Pilot: mit (a) als separater, optionaler Begleiter starten und im Pilot evaluieren, ob der Mehrwert die Online-Pflicht rechtfertigt.

9. Offene Punkte

• Format questions.json spezifizieren.
• Entscheidung Framework vs. Vanilla.
• Wer pflegt/baut? (intern DIGIT vs. extern)
• Datenschutz: rein lokal, keine personenbezogenen Daten — bestätigen.
• Companion-Chatbot: Entscheidung Offline vs. Cloud (Abschnitt 8).
• Prüfen, ob digitom-bot/Dify als Begleiter wiederverwendbar ist.
• Freischalt-Logik des Bots festlegen (nach „Auflösen" vs. jederzeit).