patrick/SLC_Game
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
SLC_Game/PROJEKTSTAND.md
breitenbach76 0eddf2b322 v11
2026-06-07 15:02:35 +02:00

8.3 KiB
Raw Blame History

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-06 · Branch: feat/redesign-und-companion-app · HEAD: 3647129 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.scad fü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 Einzeldateien phasen-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: Karten-Raster (Action Card ziehen) → Change-Art klassifizieren (Legende, „nochmal" bis richtig) → Phasen-Einstieg (Lebenszyklus-Phase anklicken, retry) → Stationen → Abschluss-Screen („abgeschlossen" oder „abgelehnt").

  • 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 App-Debrief mehr: Der Export-Dialog (Markdown/JSON) wurde entfernt; das Workshop-Debriefing am Tisch bleibt (im Done-Screen erwähnt).
  • 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.html eingebettet (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

  • Figuren-Regel festgezurrt (zweistufig: Puck = beteiligte Rollen, Aktiv-Feld = RACI). In der App umgesetzt. Offen: in materialliste.md / board-layout / README_konzept.md nachziehen.
  • 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-prompts final 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).

6. Workflow & Betrieb

Git / Deploy

  • Arbeit auf Branch feat/redesign-und-companion-app (direktes Pushen auf main ist 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 Ordners 04_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.js CACHE-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.html wurden per kleinen Python-Splice-Skripten gemacht (wegen vieler Sonderzeichen) — Muster im Chatverlauf.
  • Commit-Stil: prägnante deutsche Messages; Footer Co-Authored-By: Claude ….