Aufbauend auf "app update final" (b6500be), das den Großteil des Frank-Feedbacks v0.10 enthält (RACI-Betonung, SLC-Gesamtbild 6x, Feedback-System mit Server-Save, Review-Template, Gate-1 zweistufig):
- Gates: Freigabe-/Entscheidung ist jetzt ein EIGENER Screen NACH der
Kriterienpruefung (vorher auf einem Screen -> ueberladen). Gilt fuer
Gate 1/2/3: Pruef-Kriterien -> Button "Weiter -> Entscheidung" (erst
aktiv, wenn alle Kriterien geprueft) -> schlanker Entscheidungs-Screen
(Optionen + "<- zu den Kriterien"). Gate 1 danach wie gehabt Routing
Entwicklung/Konfiguration. Neuer State: gateCritDone.
- Tiefe-Badge "Bearbeitet" -> "Ausgearbeitet" (klarer; nur sichtbares
Label + Tooltip, interne Bezeichner/CSS-Klasse unveraendert).
- sw.js Cache hochgezaehlt; PROJEKTSTAND.md nachgezogen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
14 KiB
Projektstand — SLC-Workshop Tabletop (Übergabe / Wiedereinstieg)
Zweck dieses Dokuments: Schneller, nahtloser Wiedereinstieg (auch in einem neuen Chat). Hier steht, wo wir stehen, was entschieden wurde, was offen ist und wie man App lokal startet/deployt.
Stand: 2026-06-10 · Branch: feat/redesign-und-companion-app · App v0.10
Remote: https://git.1789.cloud/patrick/SLC_Game.git
1. Worum geht's
Haptisches Workshop-Format für Stadt Freiburg / DIGIT, das den Service-Lifecycle (Design → Transition → Operation ⇄ Support → Review) erlebbar macht. Zielgruppe: Operations/Service-Owner/Support. Mix aus Vermittlung (Lifecycle + Stationen) und Simulation echter Change-Fälle. Spielelemente: 3D-Teile, Figuren, Companion-App.
2. Repo-Überblick
| Ordner | Inhalt |
|---|---|
00_Konzept/ |
Gesamtkonzept (README_konzept.md, v0.5) + Arbeitsstand-Notizen |
01_3D-Druck/ |
Materialliste, OpenSCAD-Modelle, Board-Layout-Generator, Visual-Prompts |
02_Spielfiguren/ |
Rollen-Figuren (38), Farbcodierung, Gate-Besetzung |
03_Karten/ |
Action/Störungskarten + Artefakt-Katalog A1–A15 (Service-Akte = App-Element) |
04_Tablet-Quiz/ |
Companion-App (app/ = deploybare PWA) + Konzept |
05_Workshop-Dokumentation/ |
Logbuch, Reflexion, Debrief |
3. Aktueller Stand pro Bereich
3D / Hardware (01_3D-Druck/)
- Bahn = runde Pucks Ø100 × 6 mm, lose ausgelegt (keine Magnete, keine
Steckverbindung, keine Verankerung). Ein Modell
openscad/puck.scadfür Station (Phasenfarbe) und Gate (rot) — Unterschied nur Farbe + Etikett. Je Puck: 7 Figurenmulden Ø22 + Mittenmulde Ø37,5 für ein Rundetikett Ø37. - Phasen-Ring: 5 Segmente (Ø180/Ø84 × 6 mm), Bibliothek
phasen-ring.scad+ 5 druckfertige Einzeldateienphasen-ring-<design|transition|operation|support|review>.scad. Graviert: Icon (oben) + Phasenname. Zusammengesteckt = Übersicht, einzeln = Bahn-Köpfe. - Aktiv-Feld (RACI): quadratisch 2×2 (R|A / C|I), 130×130 mm, Standfelder Ø22.
- Entfernt (Git-Historie): Action-Stein, Gate-Tor, Gate-Tile, eckige Tiles, Ø60-Scheiben, Gate-Karte.
- Etikett-Hinweis: Ø37 ist kein Avery-Standard → Bezugsquelle vor Druck prüfen.
Karten (03_Karten/)
- Action Cards: 24 finale Grafiken (Freiburg-digital-Layout) liegen in
04_Tablet-Quiz/app/cards/s<service>-c<change>.png(6 Services × 4 Change-Arten). - Service-Akte = App-Element: Artefakte A1–A15 werden in der App per Choice gesammelt; harte Gate-Kopplung (Gate öffnet nur mit den geforderten Artefakten, Akte beim Einstieg vorbefüllt). Keine physischen Artefaktkarten / kein Tableau / kein 3D-Teil.
- Gate-Entscheidung (Go / Auflagen / Zurück / Ablehnung) trifft die zuständige Rolle in der App; die entscheidende Rolle bleibt als Marker am Gate-Puck. Keine Chips, keine Gate-Karte mehr.
Companion-App (04_Tablet-Quiz/app/) — statische PWA
Flow (v0.7 · Main/Bonus, nach Frank-Feedback): Das Deck zeigt nur die 6 Main-Karten (= Major je Service). Main ziehen → kurze Orientierung (Major, Service wird neu eingeführt, voller Lifecycle ab Design — kein Einordnungs-Quiz, der Typ ist bekannt) → voller Stationen-Durchlauf (Freigaben live an den Gates) → Abschluss → Bonus-Auswahl (die 3 Varianten dieses Service: Standard/Emergency/Normal). Bonus-Karte: 3 Aufgaben —
- Change-Art-Begründung (der Typ steht auf der Karte → kein Rate-Quiz, nur „warum ist es ein X?") · 2. Freigabe-Stelle (Quiz: SOR/DPM/MB · SO · keine[Standard] · keine[Emergency]) · 3. Einstieg-Phase (Quiz) → Kurz-Auflösung „welche Phasen sind noch relevant / fallen weg" (kein voller Walk, Service gilt als bereits eingeführt) → zurück zur Bonus-Auswahl → „Service abschließen" → nächster Service (gespielte Services im Deck als ✓ markiert).
Hintergrund: Nur der Major rechtfertigt den vollen SLC; die anderen Change-Arten werden nur eingeordnet. Die Main-Karte ist per Definition der Major → sie nochmal einzuordnen wäre unsinnig, daher startet sie direkt in den Durchlauf.
- Aktivitäts-Station, schrittweiser Mikro-Ablauf (4 Fragen, je einzeln + Auflösung): (1) Was steckt hinter der Überschrift? (2) Beteiligte Rollen → Figuren auf die Puck-Mulden; (3) RACI → Figuren ins Aktiv-Feld (R·A·C·I) (mit RACI-Legende); (4) Artefakt als Choice → in die App-Akte. Danach eigener Abschluss-Screen („✓ Aktivität abgeschlossen", an Phasengrenzen zusätzlich 🎉-Phasen-Feedback). Aufgaben jeweils im farbigen Aufgaben-Kasten.
- Gate-Station interaktiv: Kriterien prüfen → Entscheidung → Konsequenz +
Verzweigung. Echte Rückschleifen: „Zurück an Build/Transition" springt
zurück, blendet einen Nacharbeits-Banner ein und legt das Gate danach erneut
vor (Hinweis „Erneute Vorlage"). „Ablehnung" → eigener End-Screen (SOR-Eskalation).
(z. B. Gate 1 „Konfiguration" →
tr_05; SOR→DPM→Mission Board.) - Kein Lauf-Debrief mehr (Markdown/JSON-Export des Durchlaufs raus); Workshop-Debriefing am Tisch bleibt (im Done-Screen erwähnt).
- Strukturiertes Feedback (v0.10, Frank): Phasen-Feedback (2 Freitexte) an Phasenenden +
Dokument-Feedback (Skala 1–5 + 2 Freitexte) an Gate 1/2/3 + Service Review. Server-Save
via POST an
feedback.php(Retry-Queue + localStorage-Archiv + manueller „⇩ Feedback"-Export). - 4 Change-Arten (Major/Normal/Standard/Emergency), 24 Karten. Multiple-Choice
ist aus dem Hauptfluss raus (Daten liegen noch in
index.html, ungenutzt). - Inhalte sind in
index.htmleingebettet (noch keine YAML-Pipeline). - Deploy: statisch, siehe
04_Tablet-Quiz/app/DEPLOY.md.
Figuren (02_Spielfiguren/)
38 Figuren (16 Rollen × 2 + 3 Teams × 2). DPM ist in der App-Rollenliste ergänzt.
4. Wichtige Entscheidungen & Arbeitsstände
Kanonisch / stabil:
- Puck-System statt Tiles; ein STL für die Bahn; Beschriftung via Etikett.
- Aktiv-Feld 2×2; Phasen-Ring; keine Magnete; kein Action-Stein.
- Figuren-Regel (zweistufig): Station-Puck-Mulden = „welche Rollen sind beteiligt?", Aktiv-Feld (R·A·C·I) = „wie ist die RACI?". An Gates: Pflicht-Figuren am Gate-Puck.
Workshop-Arbeitsstand — bewusst NICHT im Blueprint-YAML und NICHT im kanonischen
Konzept (00_Konzept/README_konzept.md), bis Rückkopplung mit Michael:
- Review-Phase = Franks 5 Aktivitäten (Change-Enablement) statt bisher 6. Umgesetzt
in App +
materialliste.md+board-layout(→ 39 statt 40 Positionen, 36 Station-Pucks +1 Reserve). Konzept-README zeigt noch 6/40. - Change-Arten auf 4 zusammengeführt (Top/Low Major → ein „Major"); Begründung ITIL 4 (Major = Normal mit höherer Authority) + YASM (lean).
- MB = Mission Board. SOR-Routing am Change: RUN / DPM / MB. Eskalations- Kriterium: Reicht die Ressourcen-/Entscheidungshoheit der SOR nicht → Demand über DPM ans Mission Board (= DPM-Rücklauf).
- Details/Quelle:
00_Konzept/review-phase_arbeitsstand-frank.md.
5. Offene Punkte / nächste Schritte
Frank-Feedback 2026-06-10 (Workshop-/Spiel-Ebene, umgesetzt in App v0.10 — Entscheidungen Frank + Patrick):
- RACI-Betonung: Volle RACI bleibt; R + A sind als „Pflicht — unbedingt durchdenken"
hervorgehoben, C + I als „ergänzend / nice-to-have". Legende zweigeteilt, Schritt-3-Text
umformuliert (
activitySteps,raciLegendHtml). - GRAFIK SLC (Gesamtbild) 6× im Major-Walk: Start (Main-Intro), an den 4 Phasenübergängen
(
renderActivity/renderGateDone) und am Schluss (renderEnd) — jeweils mit Highlight der aktuellen/nächsten Phase (slcOverviewauf Basis vonphaseDonut). Bonus unberührt. - „Ausgearbeitet"/„Entwurf" sichtbar: Badge im Stations-Header (
stationTiefe/tiefeBadge; Label „Ausgearbeitet" — Franks „Bearbeitet", klarer benannt). Ausgearbeitet =ds_01, tr_01, tr_09, tr_12, rv_01; alles andere Entwurf. - Gate 1 zweistufig: erst Freigabe-Entscheidung (Freigabe / mit Auflagen / Zurück an
Design [Rückschleife] / Ablehnung [End-Screen]), dann Routing Entwicklung/Konfiguration.
Gate-Templates:
zielan Gate 1/2/3 ergänzt; Gate-1-Prüfdim. „Budget für die Implementierung". - Service-Review-Template (Frank): A14 + rv_01 auf 4 Dimensionen (Leistungserbringung, Betriebsstabilität, Nutzerzufriedenheit, Zukunftsfähigkeit) + Empfehlung Weiterbetrieb / Normal-Change / Major-Change umgestellt (ersetzt CONTINUE/IMPROVEMENT/REDESIGN/RETIRE).
- Feedback-Erfassung + Server-Save (re-aktiviert nach v0.7-Entfernung des Exports):
- Phasen-Feedback (2 Freitexte) an jedem Phasenende; Dokument-Feedback (Skala 1–5 +
2 Freitexte) an Gate 1/2/3 + Service Review (
FEEDBACK_DOCS). - POST an
<meta name="slc-feedback-endpoint">(Defaultfeedback.php), Retry-Queue + localStorage-Archiv (offline-fest, übersteht „Neu starten"), Header-Button „⇩ Feedback" für manuellen JSON-Export als Backup. - Server: Referenz-Collector
04_Tablet-Quiz/app/feedback.php(Flat-Filefeedback-data/feedback.jsonl, keine DB). DEPLOY.md angepasst (statisch + ein kleiner POST-Endpoint; PHP/Node/„ohne"-Varianten).
- Phasen-Feedback (2 Freitexte) an jedem Phasenende; Dokument-Feedback (Skala 1–5 +
2 Freitexte) an Gate 1/2/3 + Service Review (
- Offen / fachlich mit Frank zu bestätigen:
- Retirement/Außerbetriebnahme: in Franks Review-Empfehlung bewusst nicht mehr enthalten —
bestätigen, dass das so gewollt ist (vgl.
review-phase_arbeitsstand-frank.md). - Server-Endpoint provisionieren: PHP (php-fpm) am Webserver aktivieren oder Endpoint-URL im Meta-Tag umbiegen. Bis dahin greift Queue + Export (kein Datenverlust).
- Retirement/Außerbetriebnahme: in Franks Review-Empfehlung bewusst nicht mehr enthalten —
bestätigen, dass das so gewollt ist (vgl.
Frank-Feedback 2026-06-08 (Workshop-Ebene, entscheiden Frank + Patrick):
-
Main/Bonus-Flow umgesetzt (nur Major = voller Walk; Bonus = einordnen + Kurz-Auflösung).
-
Aufgabe „Freigabe-Stelle" ergänzt (SOR/DPM/MB · SO · keine[Standard/Emergency]).
-
Normal-Legende „strukturierter Bewertungs- und Freigabeprozess" (nicht „Gate-Prozess").
-
„Verräter"-Sätze aus 5 Standard-Karten raus (Quartalspflege, Monatsroutine, Patchday, GeoServer-Update, Patch-Quartal).
-
Einstiegs-Frage umformuliert: „Wo würde die Umsetzung starten (nach Freigabe)?".
-
3 „Normal"-Karten neu (aus Franks Word v2, ehemals fälschlich Standard):
s2-c1„Licht an!" (neue Mängel-Kategorie Beleuchtung/Strom) ·s4-c1„Grün dazu!" (Grünflächen-Datenquelle im Klimarisiko-Modul) ·s5-c1„Format-Wechsel" (neues Vertrags-Dateiformat → Schnittstellen anpassen). Texte inindex.htmlersetzt. -
Alle 24 Karten-Grafiken durch das finale Canva-Set ersetzt (
SLC Actioncards, 30 Karten → die 24 richtigen übernommen). Neue Normals (Licht an!/Grün dazu!/Format-Wechsel) und bereinigte Standards (ohne „Katalog"-Satz) sind jetzt auch grafisch korrekt. Bild = Text. Nicht verwendet: 6 „Major – Low Level"-Extras (Bauamt will mehr! · Schlüsselpflicht · Ratsbeschluss! · Akten-Zuwachs · Klimarisiko im Blick · Portal für Partner) — App nutzt nur einen Major (Top-Level) je Service. Liegen im Download-Ordner, falls später gewünscht. -
Wartet auf Frank: Service-Steckbrief-Beiblatt (6 Services: Was ist der Service, was der IT-Provider-Anteil) aus Franks Inhalten.
-
Klären (Frank + Patrick): Problem-Manager-Rolle — in App vorhanden (
sp_09/sp_10), war Frank neu. Gewollt oder YAML-Artefakt? -
Figuren-Regel festgezurrt (zweistufig: Puck = beteiligte Rollen, Aktiv-Feld = RACI). In der App umgesetzt. Offen: in
materialliste.md/board-layout/README_konzept.mdnachziehen. -
Echte Gate-Rückschleifen umgesetzt (Nacharbeits-Banner + erneute Gate-Vorlage; Ablehnung → End-Screen). Offen ggf.: Auflagen-Pfad sichtbar vom reinen „Freigabe" unterscheiden (verhält sich aktuell identisch = weiter).
-
App-Debrief entfernt (Punkt „Pfadlänge X/39" damit hinfällig).
-
MC-Quiz optional als „Wissens-Check" reaktivieren? (Daten sind noch da.)
-
YAML→Inhalts-Pipeline (Stationsdaten aus
service-lifecycle_*.yaml) — braucht Zugriff aufs Blueprint-Repo. -
Nach Michael-Freigabe: kanonisches Konzept (
README_konzept.md), YAML und ggf.bauteile-masse.svg/visual-promptsfinal nachziehen. -
Mit Frank/Michael klären: Retirement/Außerbetriebnahme (alt rv_06) in Franks Review, Vokabular-Abgleich, RACI/Quiz der Review-Phase fachlich prüfen (in App abgeleitet).
-
RACI-Lücke geschlossen (zu bestätigen): tr_02, rv_03, rv_04 hatten kein R. Die jeweils Accountable-Rolle (Projektleitung bzw. Service Owner) wurde auf A/R gesetzt (sie macht es selbst). Fachlich von Frank/Michael bestätigen lassen.
6. Workflow & Betrieb
Git / Deploy
- Arbeit auf Branch
feat/redesign-und-companion-app(direktes Pushen aufmainist per Policy gesperrt → Feature-Branch + Merge). - Push braucht deine Credentials (Git Credential Manager, interaktiv) — der Agent
kann nicht selbst pushen. Ablauf: Agent committet → du
git push→ mergen → Server-Claude deployt. - Deploy macht die Claude-Instanz auf dem Server anhand
04_Tablet-Quiz/app/DEPLOY.md(statisches Hosting des Ordners04_Tablet-Quiz/app/über HTTPS).
App lokal testen
python -m http.server 8099 --directory 04_Tablet-Quiz/app
# dann http://127.0.0.1:8099 (oder Preview-Config .claude/launch.json)
- Bei Updates: Service-Worker-Cache leeren bzw. in
app/sw.jsCACHE-Version hochzählen, sonst lädt der Browser die alte Version.
Hinweise für den (nächsten) Agenten
- OpenSCAD ist installiert → Modelle via CLI rendern/prüfen (
Simple: yes). - Preview-Renderer (MCP) kann in dieser Umgebung hängen → App-Änderungen sonst
per
node --check(Syntax) + kleinen Node-Datenchecks verifizieren. - Große Daten-/Funktionsänderungen in
app/index.htmlwurden per kleinen Python-Splice-Skripten gemacht (wegen vieler Sonderzeichen) — Muster im Chatverlauf. - Commit-Stil: prägnante deutsche Messages; Footer
Co-Authored-By: Claude ….