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/`](app/) als statische **PWA**
> (offline-/kioskfähig). Sie führt den kompletten Flow durch (Action Card →
> Startpunkt → optionale Tour → Station: Diskussion/Quiz/Auflösung → Debrief mit
> **Markdown-/JSON-Export**). Inhalte (40 Stationen, 45 Quizfragen, 6 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`, 29/30 —
> `s0-c0` „Open Source von oben!" fehlt noch → Text-Fallback). **Deployment:** statisch, siehe
> [`app/DEPLOY.md`](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)

```
[Start] → Szenario wählen (= Action Card)
   → App führt zur aktuellen Station (linearer Lifecycle, Fortschritt sichtbar)
   → Station:
       → Gruppe diskutiert am Board anhand der Kurzbezeichnung (App noch zu)
       → Quiz (vermittelnd): Frage(n) → Gruppentipp → "Auflösen" → richtig/falsch
       → ausführliche Auflösung der Station (Erklärung + RACI + Artefakt)
       → Gruppe reflektiert; optional "war unklar" markieren
       → "Nächste Station"
   → an Gates: Gate-Frage + Rollen-Check
   → [Ende] → Debrief-Export (unklare Aktivitäten, Quote, Pfad)
```

## 5. Funktionsumfang (MVP)

- [x] Stationsführung: linearer Durchlauf mit „Nächste Station" + Fortschritt/Phasen-Farben.
- [x] Fragetypen 1–3 (vermittelndes Quiz).
- [x] „Auflösen"-Mechanik (Antwort erst auf Klick) **+ ausführliche Stationsauflösung** (Erklärung/RACI/Artefakt) nach dem Quiz.
- [x] „Unklar"-Markierung je Aktivität.
- [x] Debrief-Export (Markdown **und** JSON, lokaler Download).
- [x] 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).