# 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). Flow: **Karten-Raster** (Action Card ziehen) → **Change-Art > bestimmen** (mit Legende, „nochmal versuchen" bis richtig) → **Phasen-Einstieg** > (Lebenszyklus-Phase anklicken) → **Stationen** (Diskussion/Quiz/Auflösung) → > **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-c.png`, **24** = 6 Services × 4 Change-Arten; Major/Normal/Standard/Emergency). > **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) ``` [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) → 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).