diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000..824b8f2 Binary files /dev/null and b/.DS_Store differ diff --git a/.gitignore b/.gitignore deleted file mode 100644 index 648a11e..0000000 --- a/.gitignore +++ /dev/null @@ -1,6 +0,0 @@ -.DS_Store -# OpenSCAD Render-/Export-Artefakte (Vorschau + STL) -_*.png -*.stl -*.bak -*.tmp diff --git a/00_Konzept/README_konzept.md b/00_Konzept/README_konzept.md index d083342..0d3e239 100644 --- a/00_Konzept/README_konzept.md +++ b/00_Konzept/README_konzept.md @@ -1,20 +1,17 @@ # Gesamtkonzept — SLC-Workshop Tabletop -**Version:** 0.5 (Konzept · lineare Puck-Bahn · Phasen-Ring · quadratisches RACI-Aktiv-Feld · App-gekoppelte Lernschleife) -**Stand:** 2026-06-05 +**Version:** 0.4 (Konzept · lineares Board · RACI-Aktiv-Feld · App-gekoppelte Lernschleife) +**Stand:** 2026-05-27 **Quelle:** Service-Lifecycle-Blueprint v3.2 (`#02_service-portfolio-management/.../02_spm_service-lifecycle-blueprint/`) -> **Änderung ggü. v0.4 (Hardware-Redesign):** -> - Eckige Steck-Tiles + separate Plättchen/Scheiben **ersetzt durch runde Ø100-Pucks** -> (ein Bauteil je Station; 7 Figurenmulden + Mittenetikett). Pucks liegen **lose** -> (keine Steckverbindung, keine Magnete, keine Verankerung). -> - **Action-Stein entfällt** — die Action Card liegt flach an der aktuellen Station; -> die App führt die Reihenfolge, die gestellten Figuren markieren „wir sind hier". -> - **Gate-Tore + Gate-Karten entfallen** — ein Gate ist ein **roter Puck**; Keeper, -> Artefakte und Auflösung laufen über App + Entscheidungs-Chips. -> - **Aktiv-Feld** ist jetzt **quadratisch (2×2: R|A / C|I)**. -> - Neu: **Phasen-Ring** — zusammengesteckt die SLC-Übersicht, auseinandergenommen -> die farbigen Phasen-Köpfe der Bahn (Design-Segment = Start). +> Änderung ggü. v0.1: Board ist **linear** (durchgehende Bahn), kein geschlossener +> Ring. Der DPM-Rücklauf wird als Ausgang am Review-Ende dargestellt, nicht als +> Brückensegment. +> +> Änderung ggü. v0.3: Die **Erklärung** wandert von der Plättchen-Rückseite in die +> **Companion-App**. Plättchen tragen nur noch die **Kurzbezeichnung** (einseitig). +> Pro Station gilt die Schleife **Diskussion → App-Quiz → Auflösung → Reflexion**; +> die App führt die Stationsreihenfolge automatisch. --- @@ -30,12 +27,12 @@ Lernziele: - Begreifen, **wer** an **welchem Gate** entscheidet (Governance / RACI). - Die Operation↔Support-Schleife und die Rückkopplung in den Demand-Lifecycle nachvollziehen. -## 2. Das Spielbrett — lineare Puck-Bahn +## 2. Das Spielbrett — lineare Bahn -Der Service-Lifecycle ist eine **durchgehende Bahn** von Design bis Review. Die -Gruppe wandert mit dem Szenario von links nach rechts; Operation und Support bilden -eine sichtbare Hin-und-zurück-Schleife. Am Review-Ende führen zwei Ausgänge zurück -in den Demand-Lifecycle (Redesign / Retirement) — bewusst **kein** kurzgeschlossener +Der Service-Lifecycle ist eine **durchgehende Bahn** von Design bis Review. Ein +Service-Token wandert von links nach rechts; Operation und Support bilden eine +sichtbare Hin-und-zurück-Schleife. Am Review-Ende führen zwei Ausgänge zurück in +den Demand-Lifecycle (Redesign / Retirement) — bewusst **kein** kurzgeschlossener Pfeil zu Design. ``` @@ -51,19 +48,12 @@ Loop-Ebene: **Operation ⇄ Support** ist der innere Sub-Loop (laufender Betrieb dreht sich häufig); der DPM-Rücklauf ist die langlebige „Wiedergeburt" eines Services und verlässt das Board am Review-Ende. -### Aufbau aus runden Pucks -Die Bahn ist eine Reihe **runder Pucks** (Ø 100 mm): **eine je Aktivität** (37) plus -**3 Gate-Pucks** (gleiche Form, rote Farbe) = 40 Positionen. Die Pucks werden -**lose** aneinandergelegt (keine Steck-/Magnetverbindung); bei Platzmangel -mäandrierend. Als optische Linie dient eine flache Unterlage/Matte. Jeder Puck -trägt seine Phasenfarbe (Filament) und in der Mitte ein **Rundetikett** mit -ID + Kurzbezeichnung. Maße & Modelle: [`../01_3D-Druck/`](../01_3D-Druck/). - -### Phasen-Ring (Übersicht ↔ Bahn-Köpfe) -Fünf farbige 72°-Segmente bilden **zusammengesteckt** den SLC-Übersichts-Donut -(Gesamtbild des Lifecycles) und **auseinandergenommen** die **Phasen-Köpfe** der -Bahn — das **Design-Segment ist der Start** vor dem ersten Puck. Jedes Segment -trägt Icon + Phasenname in der Phasenfarbe. +### Aufbau aus modularen Tiles +Das Board ist ein **Tile-System**: kleine, untereinander steckbare Basistiles +(je eine Aktivität/Gate pro Tile), die zu einer Bahn aneinandergereiht werden. +Bei Platzmangel kann die Bahn **mäandrierend** (Zeilen-Umbruch) gelegt werden. +Das hält die 3D-Druckteile klein genug für übliche Druckbetten. Maße & Mechanik: +[`../01_3D-Druck/`](../01_3D-Druck/). ## 3. Phasen & Aktivitäten @@ -78,20 +68,18 @@ Präfixe: `ds_` Design · `tr_` Transition · `op_` Operation · `sp_` Support | **Review** | lila | rv_01–rv_06 (6) | Vollständige Aktivitätsliste mit Namen: siehe Blueprint-README (Quelle oben). -Die **Etikett-Kurzbezeichnung** (ID + Name) und die **App-Auflösung** werden beide -1:1 aus den `service-lifecycle_*.yaml` gezogen — keine Doppelpflege. +Die **Plättchen-Kurzbezeichnung** (ID + Name) und die **App-Auflösung** werden +beide 1:1 aus den `service-lifecycle_*.yaml` gezogen — keine Doppelpflege. ## 4. Die Gates -| Gate | ID | Position | Gate-Keeper | Pflicht-Figuren am Gate-Puck | -|------|----|----------|-------------|------------------------------| +| Gate | ID | Position | Gate-Keeper | Pflicht-Figuren am Tor | +|------|----|----------|-------------|------------------------| | Gate 1 | tr_01 | Entry Transition | **SOR** | SPM + SO + AL B&C + AL App | | Gate 2 | tr_09 | nach Build | **SO** (allein) | SO | | Gate 3 | tr_12 | Exit Transition → Operation | **SOR** | SPM + SO + AL B&C + AL App | -Ein Gate ist ein **roter Puck** (Etikett `G1`/`G2`/`G3` + Entscheidungs-Icon). Die -Pflicht-Figuren werden in seine Figurenmulden gestellt; sonst „öffnet" das Gate -nicht. Entscheidungspfade als Chips: **Go / Go mit Auflagen / Zurück / Ablehnung** +Entscheidungspfade als Chips: **Go / Go mit Auflagen / Zurück / Ablehnung** (exakt die im Blueprint dokumentierten Pfade). Gate 1 verzweigt zusätzlich **Entwicklung (tr_02)** vs. **Konfiguration (tr_05)**. @@ -101,40 +89,40 @@ nicht. Entscheidungspfade als Chips: **Go / Go mit Auflagen / Zurück / Ablehnun ## 5. Spielelemente (Mechaniken) -### 5.1 Szenario / Action Card (kein Spielstein) -Eine gezogene **Action Card** (z. B. „Strategiewechsel") gibt das Szenario vor. Sie -liegt **flach an der aktuellen Station** und wandert mit der Gruppe die Bahn entlang. -Einen aufrechten Träger-Stein gibt es nicht mehr; die **App führt** die -Stationsreihenfolge, die aktuelle Station ist zusätzlich daran erkennbar, dass dort -die **Rollen-Figuren** stehen. +### 5.1 Action-Stein (Szenario-Träger) +Ein Spielstein mit aufrechtem Kartenschlitz. Die gezogene **Action Card** (z.B. +„Strategiewechsel") steckt sichtbar im Stein und wandert mit ihm durch die +Phasen. Footprint des Steins = Footprint der Aktivitäts-Verankerung. -### 5.2 Station-Puck + App-Auflösung (Kern-Mechanik) -- **Ein Puck je Station** (Ø 100 mm): außen ein Ring aus **7 Figurenmulden**, in der - Mitte ein **Rundetikett** mit **ID + Kurzbezeichnung** (`op_05 — Überwachen der - Services`). **Keine Erklärung am Puck** — die liegt in der App. -- **Spielzug:** Die Gruppe erreicht den nächsten Puck → **diskutiert anhand der - Kurzbezeichnung**, was hier passiert (noch **nichts** aufdecken) → beteiligte - **Figuren an den Puck stellen** → **App-Quiz** zur Station → **Auflösung in der - App** → kurze Reflexion → weiter zur nächsten Station. -- Die Erklärung wird **erarbeitet, nicht vorgelesen**: erst Diskussion, dann Quiz - (vermittelnd), dann die ausführliche App-Auflösung. +### 5.2 Aktivitätsplättchen + App-Auflösung (Kern-Mechanik) +- **Plättchen ist einseitig:** nur **ID + Kurzbezeichnung** (`op_05 — Überwachen + der Services`). **Keine Erklärung auf der Rückseite** — die liegt in der App. +- Sitzt in der **Verankerung** (Vertiefung) des Tiles und ist **entnehmbar**. +- **Spielzug:** Action-Stein erreicht das Plättchen → Gruppe **diskutiert anhand der + Kurzbezeichnung**, was hier passiert (noch **nichts** aufdecken) → Plättchen + herausnehmen, Action-Stein in die freie Verankerung stellen (markiert „wir sind + hier") → **App-Quiz** zur Station → **Auflösung in der App** → kurze Reflexion. +- Die Erklärung wird also **erarbeitet, nicht vorgelesen**: erst Diskussion, dann + Quiz (vermittelnd), dann die ausführliche App-Auflösung. ### 5.3 Rollen-Figuren & Platzierung Pöppel je Rolle (Höhe ~50 mm, flacher Standfuß Ø 20 mm ohne Pin), farb- und -formcodiert. Figuren werden **gestellt, nicht gesteckt**; es gibt **zwei** Orte: -- **Am Station-Puck (wer ist beteiligt):** die **7 Figurenmulden** (Ø 22) nehmen die - je Aktivität beteiligten Rollen auf — sichtbar wird, *wer* an dieser Station mitwirkt. -- **Aktiv-Feld (RACI pro Schritt):** ein **quadratisches** Board (130 × 130 mm), das - neben der aktuellen Station liegt und mitwandert. Es hat vier Zonen im 2×2-Raster - **R | A** (oben) und **C | I** (unten). Die beteiligten Rollen werden zusätzlich in - die passende RACI-Zone gestellt — sichtbar wird nicht nur *wer*, sondern *in welcher - Verantwortung*. **A** hat genau einen Platz (genau eine Rolle accountable). +formcodiert. Figuren werden **gestellt, nicht gesteckt**; markierte **Standfelder** +gibt es an zwei Orten: +- **Aktiv-Feld (RACI pro Schritt):** Eine mobile Leiste steht **neben dem + Action-Stein** und wandert mit ihm. Sie hat vier beschriftete Zonen + **R · A · C · I**. Beim Bearbeiten einer Aktivität werden die beteiligten Rollen + in die passende RACI-Zone gestellt — sichtbar wird nicht nur *wer*, sondern *in + welcher Verantwortung*. **A** hat genau einen Platz (genau eine Rolle accountable). +- **Gate-Versammlung:** An den Gates müssen die **Pflicht-Figuren** auf die + Tor-Standfelder gestellt werden, sonst „öffnet" das Gate nicht. -Alle Standfelder sind Ø 22 (gleich wie die Puck-Mulden — dieselben Ø-20-Figuren). -Details & Designvarianten: [`../02_Spielfiguren/`](../02_Spielfiguren/). +Die Tiles bleiben dadurch clean; die Figuren stehen mit Ø-20-mm-Sockel auf den +Standfeldern (Aktiv-Feld-Pitch 24 mm). Details & Designvarianten: +[`../02_Spielfiguren/`](../02_Spielfiguren/). ### 5.4 Weitere Karten & Chips -- **Artefaktkarten + Service-Akte:** Was an einer Aktivität entsteht (15 konsolidierte Artefakte A1–A15). Erzeugte Artefakte kommen als Karte in die **Service-Akte** (Tableau neben der aktuellen Station); „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden über einen **Status-Marker** mehrfach befüllt. **Gate-Kopplung:** Ein Gate öffnet nur, wenn die geforderten Artefakte in der Akte liegen (Gate 1: SDD + Implementation Blueprint usw.). Details: [`../03_Karten/`](../03_Karten/). +- **Artefaktkarten + Service-Akte:** Was an einer Aktivität entsteht (15 konsolidierte Artefakte A1–A15). Erzeugte Artefakte kommen als Karte in die **Service-Akte** (Tableau neben dem Action-Stein); „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden über einen **Status-Marker** mehrfach befüllt. **Gate-Kopplung:** Ein Gate öffnet nur, wenn die geforderten Artefakte in der Akte liegen (Gate 1: SDD + Implementation Blueprint usw.). Details: [`../03_Karten/`](../03_Karten/). - **Störungskarten:** Gegenstück zu Action Cards (Incident-Welle, Sicherheitsvorfall, Budgetkürzung, Eskalation) — zwingen in die Operation↔Support-Schleife oder über ein Gate zurück. - **Entscheidungs-Chips:** Go / Go mit Auflagen / Zurück / Ablehnung. - **DPM-Rücklauf-Karte:** markiert am Review-Ende, wenn der Service als Redesign/Retirement zurück in den Demand-Lifecycle geht. @@ -143,9 +131,9 @@ Details & Designvarianten: [`../02_Spielfiguren/`](../02_Spielfiguren/). Details: [`../03_Karten/`](../03_Karten/). ### 5.5 Companion-App (Lernschleife & Auflösung) -Die App ist der **erklärende Gegenpart** zum Board. Sie **führt die -Stationsreihenfolge automatisch** (linearer Lifecycle, „Nächste Station") — die Pucks -brauchen daher keinen Code; ihre ID steht nur auf dem Etikett. +Die App ist der **erklärende Gegenpart** zum Board und ersetzt die frühere +Plättchen-Rückseite. Sie **führt die Stationsreihenfolge automatisch** (linearer +Lifecycle, „Nächste Station") — die Plättchen brauchen daher keinen Code. Pro Station liefert die App die Schrittigkeit: 1. **Diskussion zuerst (am Board):** Gruppe deutet die Kurzbezeichnung; App noch zu. @@ -161,21 +149,22 @@ Schwach beantwortete Stationen werden protokolliert (→ Abschnitt 8). MVP-Scope ## 6. Spielablauf -1. **Setup:** Puck-Bahn auslegen (Phasen-Ring auseinandernehmen, Design-Segment als Start, dann die Station-Pucks je Phase, Gate-Pucks an Gate 1/2/3), Rollen-Figuren am Spielfeldrand, Aktiv-Feld bereit, Action/Störungs-Decks bereit, Tablet aktiviert. +1. **Setup:** Bahn legen, Plättchen in Verankerungen, Rollen-Figuren am Spielfeldrand, Action/Störungs-Decks bereit, Tablet aktiviert. 2. **Rollen verteilen:** Jede Person hält 1–2 Rollen-Figuren und spricht, wenn ihre Rolle dran ist. -3. **Szenario ziehen:** Action Card ziehen, an die erste Station (`ds_01`) legen. +3. **Szenario ziehen:** Action Card in den Stein, Stein auf `ds_01` (erste Station). 4. **Station bearbeiten (Lernschleife, App noch zu):** Pro Aktivität die drei Leitfragen diskutieren — 1. Was passiert hier konkret für dieses Szenario? - 2. Wer macht es (Rolle, RACI)? → die genannten **Figuren an den Puck stellen** und - zusätzlich ins **Aktiv-Feld** in die passende R/A/C/I-Zone. + 2. Wer macht es (Rolle, RACI)? → die genannten **Rollen-Figuren ins Aktiv-Feld + in die passende R/A/C/I-Zone stellen** 3. Welches Artefakt entsteht? → erzeugte **Artefaktkarte in die Service-Akte** legen (bzw. Status-Marker eines bestehenden Artefakts weiterschieben). + Plättchen herausnehmen, **Action-Stein in die Verankerung** („wir sind hier"). Dann **App-Quiz** zur Station → **Auflösung in der App** → Gruppe reflektiert / - gleicht ab. Danach Aktiv-Feld leeren und zur **nächsten Station** weiterziehen - (App schaltet weiter, Action Card mitnehmen). -5. **Gates:** Diskussion, Pflicht-Figuren an den Gate-Puck stellen, **geforderte - Artefakte in der Service-Akte prüfen** (sonst öffnet das Gate nicht), - Entscheidungs-Chip wählen, weiterziehen. + gleicht ab. Danach Aktiv-Feld leeren und mit dem Action-Stein zur **nächsten + Station** weiterziehen (App schaltet weiter). +5. **Gates:** Diskussion, Pflicht-Figuren setzen, **geforderte Artefakte in der + Service-Akte prüfen** (sonst öffnet das Gate nicht), Entscheidungs-Chip wählen, + Token durch das Tor schieben. 6. **Schleife:** Störungskarten und Support-Phase durchspielen, bis Review erreicht ist. 7. **Review-Entscheidung:** Improvement / Redesign (rv_05) / Retirement (rv_06) — Redesign & Retirement geben den Service über die DPM-Rücklauf-Karte ab. 8. **Debrief:** Logbuch & Reflexion (→ [`../05_Workshop-Dokumentation/`](../05_Workshop-Dokumentation/)). @@ -183,7 +172,7 @@ Schwach beantwortete Stationen werden protokolliert (→ Abschnitt 8). MVP-Scope ## 7. Didaktische Hebel - **Active Recall:** erst diskutieren/raten anhand der Kurzbezeichnung, dann App-Quiz, dann Auflösung — statt passivem Vorlesen. -- **Embodiment:** Rollen-Figuren in der Hand erzwingen Beteiligung und vermitteln Verantwortlichkeiten körperlich (am Puck *wer*, im Aktiv-Feld *welche RACI-Rolle*). +- **Embodiment:** Rollen-Figuren in der Hand erzwingen Beteiligung und vermitteln Verantwortlichkeiten körperlich (RACI im Aktiv-Feld). - **Forcierte Konsens-Entscheidung an Gates:** trainiert Governance statt reiner Stoffvermittlung. - **Produktives Ringen:** Die App löst erst *nach* dem Gruppentipp auf. - **Low-stakes:** Punkte optional, Diskussion vor Wettbewerb. @@ -199,7 +188,7 @@ Diese Daten fließen zurück in die Weiterentwicklung des Blueprints. ## 9. Offene Punkte / nächste Schritte -- [ ] Print-Test der 3D-Maße (Passung Figur ↔ Puck-Mulde, Etikett ↔ Mulde, Stabilität Phasen-Ring-Segmente). -- [ ] Etiketten-Bogen (Ø 37) aus den YAMLs generieren (Layout). +- [ ] Print-Test der 3D-Maße (Stein-Stabilität mit aufrechter Karte validieren). +- [ ] Plättchen-Texte aus den YAMLs final generieren (Layout). - [ ] Tablet-Quiz: MVP-Scope festlegen (siehe `04_Tablet-Quiz/`). - [ ] Pilot-Workshop terminieren und Logbuch testen. diff --git a/00_Konzept/raci-aktiv-feld.svg b/00_Konzept/raci-aktiv-feld.svg new file mode 100644 index 0000000..5766857 --- /dev/null +++ b/00_Konzept/raci-aktiv-feld.svg @@ -0,0 +1,114 @@ + diff --git a/00_Konzept/raci-tile-variante.svg b/00_Konzept/raci-tile-variante.svg new file mode 100644 index 0000000..8e4b054 --- /dev/null +++ b/00_Konzept/raci-tile-variante.svg @@ -0,0 +1,76 @@ + diff --git a/01_3D-Druck/README_3d-druck.md b/01_3D-Druck/README_3d-druck.md index 4e9503b..2a0b8c5 100644 --- a/01_3D-Druck/README_3d-druck.md +++ b/01_3D-Druck/README_3d-druck.md @@ -11,8 +11,9 @@ Verankerung und Steckmechanik. |-------|-------| | [`materialliste.md`](materialliste.md) | Alle Bauteile mit Maßen, Mengen, Material- und Druckempfehlung | | [`visual-prompts_3d-producer.md`](visual-prompts_3d-producer.md) | Bild-Prompts als Orientierungs-Renderings für den Producer | -| [`board-layout.svg`](board-layout.svg) | Maßstäbliche Layout-Skizze des gesamten Boards (40 Pucks: 37 + 3 Gate-Pucks, Sequenz, Loop) — im Browser/Editor ansehen | -| [`gen_board_layout.py`](gen_board_layout.py) | Generator-Skript für die Layout-Skizze (bei Änderungen erneut ausführen → `board-layout.svg`) | +| [`board-layout.svg`](board-layout.svg) | Maßstäbliche Layout-Skizze des gesamten Boards (exakt 40 Tiles, Sequenz, Loop) | +| `board-layout.png` | PNG-Vorschau der Layout-Skizze | +| [`gen_board_layout.py`](gen_board_layout.py) | Generator-Skript für die Layout-Skizze (bei Änderungen erneut ausführen) | | [`openscad/`](openscad/) | Parametrische Modelle (OpenSCAD) der Schlüsselteile zum direkten Slicen | ## Grundsätzliche Design-Entscheidungen diff --git a/01_3D-Druck/bauteile-masse.svg b/01_3D-Druck/bauteile-masse.svg new file mode 100644 index 0000000..1b4b147 --- /dev/null +++ b/01_3D-Druck/bauteile-masse.svg @@ -0,0 +1,164 @@ + diff --git a/01_3D-Druck/board-layout.png b/01_3D-Druck/board-layout.png new file mode 100644 index 0000000..639d011 Binary files /dev/null and b/01_3D-Druck/board-layout.png differ diff --git a/01_3D-Druck/board-layout.svg b/01_3D-Druck/board-layout.svg index 5e565d3..f26877f 100644 --- a/01_3D-Druck/board-layout.svg +++ b/01_3D-Druck/board-layout.svg @@ -1,513 +1,310 @@ -') @@ -203,4 +199,4 @@ with open(out, "w", encoding="utf-8") as f: total = sum(len(t) for _, _, t in PHASES) gates = sum(1 for _, _, t in PHASES for _, _, g in t if g) print(f"geschrieben: {out}") -print(f"Pucks gesamt: {total} (Aktivitaeten: {total-gates}, Gate-Pucks: {gates})") +print(f"Tiles gesamt: {total} (Aktivitaeten: {total-gates}, Gates: {gates})") diff --git a/01_3D-Druck/materialliste.md b/01_3D-Druck/materialliste.md index ebea60e..fa67c49 100644 --- a/01_3D-Druck/materialliste.md +++ b/01_3D-Druck/materialliste.md @@ -134,7 +134,7 @@ linearen Puck-Bahn — das **Design-Segment ist der Start** vor dem ersten Puck. | Merkmal | Wert | |---------|------| | Form | Ringsegment 72°, **Ø 180 außen / Ø 84 innen × 6 mm** | -| Beschriftung | **graviert**: Icon (oben) + Phasenname (darunter, Größe 8, Tiefe 1,0); keine Sublabels. Icons: Design=Plan+Stift · Transition=Rakete · Operation=Zahnräder · Support=Headset · Review=Lupe+Haken | +| Beschriftung | **graviert**: nur Phasenname, mittig im Band (Größe 9, Tiefe 1,0); keine Sublabels/Icons | | Farbe | je Phase (blau/orange/grün/teal/lila) — wie die Pucks | | Verbindung | **keine** — Segmente werden lose aneinandergelegt (Ring oder Phasen-Köpfe) | | Menge | **5** (1 je Phase) | diff --git a/01_3D-Druck/openscad/_design.png b/01_3D-Druck/openscad/_design.png new file mode 100644 index 0000000..0ca427f Binary files /dev/null and b/01_3D-Druck/openscad/_design.png differ diff --git a/01_3D-Druck/openscad/_operation.png b/01_3D-Druck/openscad/_operation.png new file mode 100644 index 0000000..8dbe4ca Binary files /dev/null and b/01_3D-Druck/openscad/_operation.png differ diff --git a/01_3D-Druck/openscad/_review.png b/01_3D-Druck/openscad/_review.png new file mode 100644 index 0000000..a9087e9 Binary files /dev/null and b/01_3D-Druck/openscad/_review.png differ diff --git a/01_3D-Druck/openscad/_support.png b/01_3D-Druck/openscad/_support.png new file mode 100644 index 0000000..ba07c8b Binary files /dev/null and b/01_3D-Druck/openscad/_support.png differ diff --git a/01_3D-Druck/openscad/_transition.png b/01_3D-Druck/openscad/_transition.png new file mode 100644 index 0000000..81f4d0b Binary files /dev/null and b/01_3D-Druck/openscad/_transition.png differ diff --git a/01_3D-Druck/visual-prompts_3d-producer.md b/01_3D-Druck/visual-prompts_3d-producer.md index a321c6e..20c73ba 100644 --- a/01_3D-Druck/visual-prompts_3d-producer.md +++ b/01_3D-Druck/visual-prompts_3d-producer.md @@ -1,96 +1,126 @@ # Visual-Prompts für den 3D-Druck-Producer -Diese Prompts erzeugen **Orientierungs-Renderings** (kein Marketing-Bild), die dem -Producer Form, Proportion und Funktion der Bauteile zeigen. Empfohlen für Bildmodelle -wie Nano Banana / Imagen. Englisch erzielt meist die sauberste Geometrie; -Beschriftungen bewusst sparsam halten. +Diese Prompts erzeugen **Orientierungs-Renderings** (kein Marketing-Bild), +die dem Producer Form, Proportion und Steckmechanik der Bauteile zeigen. +Empfohlen für Bildmodelle wie Nano Banana / Imagen. Englisch erzielt meist die +sauberste Geometrie; Beschriftungen bewusst sparsam halten. -> **Aktueller Stand (v0.5-Hardware):** Bahn = **runde Ø100-Pucks** (lose aneinander, -> keine Steckverbindung, keine Magnete). Je Puck **7 Figurenmulden** im Ring + ein -> **Rundetikett (Ø37)** in der Mitte. **Kein** Action-Stein, **keine** Plättchen/ -> Scheiben, **kein** Gate-Tor: ein Gate ist ein **roter Puck**. Aktiv-Feld ist -> **quadratisch (2×2)**. Neu: **Phasen-Ring** (5 Segmente). +> **Board-Layout:** linear (durchgehende Bahn), **kein Kreis**. +> **Wichtig:** die **einseitigen, entnehmbaren Aktivitätsplättchen** müssen +> sichtbar sein — einige liegen flach in der Verankerung (Code-Seite oben), +> einige sind herausgenommen und liegen daneben (Rückseite leer), sodass die +> **freie Verankerung** erkennbar ist (dort steht dann der Action-Stein). +> *(Stand v0.2-Renderings — Erklärung liegt inzwischen in der App, nicht auf der +> Rückseite; RACI-Aktiv-Feld + verschlankte Figuren sind hier noch nicht abgebildet.)* --- ## Prompt A — Bauteil-Übersicht (Exploded-Style) ``` -Clean technical product render, neutral light-grey studio background, exploded view -of a set of 3D-printed tabletop game components in matte PLA. Show: a round 100mm -puck (~6mm thick) with a slightly recessed top face, a ring of seven shallow round -figure wells near the rim and a flat round label area in the centre; a second -identical puck in red (a "gate"); one 72-degree ring segment of a colour-coded -"phase ring"; a square ~130mm RACI board with four outlined fields (R, A, C, I) in a -2x2 grid; a meeple figure with a flat round 20mm base. Parts floating slightly apart. -Soft shadows, isometric angle, high detail, dimension-focused, minimal text. +Clean technical product render, neutral light-grey studio background, exploded +view of a set of 3D-printed tabletop game components in matte PLA. Show: a square +modular base tile (100x100mm) with puzzle-tab edges and a round centered recess; +a round blank insert disc (~60mm) that fits the recess, its flat top carrying a +round printed label sticker; a cylindrical game token +with a wide weighted base and a vertical card slot on top; a small upright +arch-shaped "gate" with marked stand spots at its base; a meeple figure with a +flat round base. Parts floating slightly apart to show how they relate. Soft shadows, +isometric angle, high detail, dimension-focused, minimal text. ``` -## Prompt B — Station-Puck im Detail +## Prompt B — Aktivitätsplättchen: einseitig & entnehmbar ``` -Close-up technical render of a single round game puck in matte PLA, 100mm diameter, -about 6mm thick, with a chamfered top edge and a slightly recessed top face. Near the -rim, a ring of seven shallow round wells (~22mm) sized to let a 20mm-based figure -stand in each. In the centre a flat shallow round recess holding a printed round -label (~37mm) with a short activity code and title. The puck is one solid phase -colour. Neutral grey background, soft studio light, shallow depth of field, emphasis -on the figure wells and the central label recess, minimal text. +Close-up technical render of round blank game discs in matte PLA, each about 60mm +diameter and 4mm thick with a chamfered edge for easy gripping, the flat top face +carrying a round printed label sticker with a short activity code. Three discs +shown: one sitting flush inside a square tile's round recess, one lifted out by +fingers, and one blank disc with the round sticker beside it. The empty recess of +one tile is clearly visible (this is where the upright action token will stand). +Emphasis on the removable fit and the re-stickerable blank top. Neutral grey +background, soft studio light, shallow depth of field, premium board-game +component photography. ``` -## Prompt C — Gate-Puck (rot) +## Prompt C — Action-Stein im Detail ``` -Close-up technical render of a round game puck identical in shape to the activity -pucks (100mm, seven figure wells, central label recess) but moulded in RED matte PLA -to mark it as a decision gate. The central round label reads "G1" with a small -decision icon (three arrows + question mark). A few chunky 50mm miniature figures -stand in the wells as a committee gathering. Neutral grey background, soft light, -emphasis on the red colour and the "committee gathers to decide" idea, minimal text. +Close-up technical render of a single 3D-printed game token, matte white PLA. +Cylindrical body on a wide round base, with a vertical slot on top holding an +upright rectangular card. The base diameter is clearly wider than the body for +stability. The token stands inside a square tile's round recess (the same recess +that normally holds an activity disc). Quarter-section cutaway shows a hexagonal +cavity in the base for a metal weight. Neutral grey background, soft studio +lighting, isometric, emphasis on proportions and the card slot fit, no decorative +text. ``` -## Prompt D — Aktiv-Feld (RACI, 2×2) +## Prompt D — Gate-Tor mit Rollen-Standfeldern ``` -Top-down technical render of a square flat PLA board, about 130x130mm, divided into -a 2x2 grid of four clearly outlined fields, each engraved with a single big letter: -top row R and A, bottom row C and I. The R, C and I fields each show four shallow -round stand-markings (2x2); the A field shows exactly ONE stand-marking. Several -chunky 50mm figures stand on the markings (e.g. two in R, exactly one in A). Clean, -instructional, neutral grey background, soft even light, minimal text. +Technical product render of a small upright arch-shaped game piece in matte PLA, +like a doorway about 100mm tall with 90mm clear opening, 8mm thick. Two flat feet +at the base spanning two tiles of a straight track. A row of four small shallow +engraved circular stand spots along the front base edge where figures are placed. +A thin horizontal slot across the top of the arch holding a small reference card. +A flat-based meeple figure stands on one of the marked spots. Neutral background, +isometric, soft shadows, focus on the stand-spot markings, minimal text. ``` -## Prompt E — Phasen-Ring (Übersicht ↔ Segmente) +## Prompt E — Tile-Steckmechanik (gerade Bahn) ``` -Technical render of a colour-coded "phase ring": a flat ring/donut (about 180mm -outer, 84mm inner, 6mm thick) split into five 72-degree segments, each a different -phase colour (blue, orange, green, teal, purple) and each engraved with a simple icon -above a phase name (DESIGN, TRANSITION, OPERATION, SUPPORT, REVIEW). Show the ring -once assembled as a closed donut, and once with the segments separated and laid in a -row as headers. Neutral grey background, soft light, isometric, minimal text. +Top-down and slight-angle technical render of four square modular game tiles +(matte PLA, different solid colors: blue, orange, green, teal) connected via +puzzle-tab edges into a STRAIGHT row / track. Each tile has a round recessed socket +in its center: two sockets hold flat round single-sided discs (engraved code on +top), one socket is empty showing the recess, one holds a small upright arch gate. Clean grey background, soft light, isometric, emphasis on how +tiles interlock into a straight line, minimal text. ``` ## Prompt F — Komplettaufbau (Referenz für Proportionen) ``` Wide isometric technical render of a fully assembled LINEAR tabletop game on a -neutral surface: a long left-to-right track made of round 100mm pucks laid loosely in -a line through five colour zones (blue, orange, green, teal, purple); two zones -(green and teal) sit side by side with two curved arrows forming a small loop between -them; three of the pucks are RED (gates); each puck has a ring of seven figure wells -and a central round label. Small meeple figures stand in the wells of a few pucks and -on a square 2x2 RACI board beside the current puck. A flat "Action Card" lies next to -the current puck. At the left start, five colour segments form a "phase ring" header. -Matte PLA materials, soft studio lighting, clean and diagrammatic, proportion-accurate, -minimal text. +neutral surface: square color-coded tiles connected into a long straight track +left to right through five color zones (blue, orange, green, teal, purple); two of +the zones (green and teal) sit side by side with two curved arrows forming a small +loop between them; three upright arch gates stand on the track; small meeple figures +placed at the gates; round single-sided activity discs sit in the tile sockets with +a couple lifted out leaving empty sockets; one cylindrical token with an +upright card stands in a socket; at the right end two exit arrows lead off the board. +Matte PLA materials, soft studio lighting, clean and diagrammatic, +proportion-accurate, minimal text. +``` + +## Prompt G — Gesamtaufbau, 40 Einzeltiles (Tisch-Optik) + +> Hinweis: Bild-KIs zählen nicht zuverlässig — die exakte Tile-Zahl ist über +> [`board-layout.svg`](board-layout.svg) garantiert. Dieser Prompt liefert die +> **Optik/Stimmung**, nicht die exakte Anzahl. Raster explizit vorgeben erhöht +> die Trefferquote. + +``` +Isometric high-angle photograph of a complete modular tabletop board on a large +wooden meeting table, spanning about 1.2 meters. The board is assembled from many +small individual square puzzle tiles interlocking via tab-and-slot edges; each tile +is one lifecycle step. Tiles are color-grouped into five phases laid out as fixed +grids: DESIGN (blue) 4 tiles, TRANSITION (orange) 12 tiles with three of them marked +by a small upright arch gate, OPERATION (green) 7 tiles, SUPPORT (teal) 11 tiles, +REVIEW (purple) 6 tiles. Each tile has a round recessed socket holding a flat +single-sided disc; a few discs are lifted out leaving empty sockets. Between the green and teal phases two curved arrows form a +small loop; two exit arrows leave the purple phase at the right. A cylindrical token +with an upright card stands in a socket at the start. A coffee mug and notebook give +scale. Soft daylight, matte PLA surfaces, clean modern design, large phase labels +only, minimal small text. ``` --- ### Hinweise zum Einsatz -- Prompts A–E sind **Bauteil-Referenzen** (für Fertigung), Prompt F zeigt den **Gesamtaufbau** (lineare Puck-Bahn). +- Prompts A–D sind **Bauteil-Referenzen** (für Fertigung), Prompt E zeigt die **Steckmechanik**, Prompt F den **Gesamtaufbau** (lineare Bahn). +- **Prompt B** zeigt die einseitigen, entnehmbaren Plättchen und die freigelegte Verankerung (dort steht der Action-Stein). - Verbindliche Maße stehen in [`materialliste.md`](materialliste.md) und in den OpenSCAD-Modellen — die Bilder dienen nur der Orientierung, nicht als Maßvorlage. -- **Keine Pins/Löcher** an Figuren — sie *stehen* in den Mulden bzw. auf den Markierungen. - Bei unsauberer Geometrie: Anzahl beschriebener Teile pro Prompt reduzieren. diff --git a/02_Spielfiguren/README_spielfiguren.md b/02_Spielfiguren/README_spielfiguren.md index 293176f..2ad4aa4 100644 --- a/02_Spielfiguren/README_spielfiguren.md +++ b/02_Spielfiguren/README_spielfiguren.md @@ -1,13 +1,13 @@ # Spielfiguren — Rollen -Die Figuren bilden die Rollen des SLC-Workshops ab. **Finaler Satz:** +Die Figuren bilden die Rollen des SLC-Workshops ab. **Finaler Satz (v0.6):** **16 Einzelrollen** + **3 Team-Sonderfiguren**. Die **SOR ist keine Figur**, sondern -ein **Gremium**, das an den **Gate-Pucks** zusammenkommt -([`../01_3D-Druck/openscad/puck.scad`](../01_3D-Druck/openscad/puck.scad), rot). +ein **Gremium**, das an den **Gate-Tiles** zusammenkommt +([`../01_3D-Druck/openscad/gate-tile.scad`](../01_3D-Druck/openscad/gate-tile.scad)). Jede Figur ist **~50 mm hoch** mit **flachem Standfuß (Sockel Ø 20 mm, kein Pin)** -und wird in die **Puck-Mulden** und ins **Aktiv-Feld gestellt** (kein Stecksystem). -Codierung über **Farbe** (Kategorie) und optional Formvariante. +und wird in Aktiv-Feld und Gate-Tile **gestellt** (kein Stecksystem). Codierung über +**Farbe** (Kategorie) und optional Formvariante. > **Hinweis Blueprint:** Dieser Figurensatz ist die finale Spiel-Definition. Die > 4 neuen Rollen (AML, SHM, DPM, ISB) und die Zusammenführung zu **OP** stehen so @@ -71,23 +71,23 @@ Einzelfiguren), damit sofort klar ist: das ist ein **Team**, keine Einzelrolle. ## Gates & SOR-Besetzung -Die 3 Gates sind **rote Gate-Pucks** (gleiche Form wie die Station-Pucks, Etikett -`G1/G2/G3` + Entscheidungs-Icon, 7 Figurenmulden). Die **SOR** ist ein **Gremium**, -das am Gate-Puck zusammenkommt. +Die 3 Gates sind **Gate-Tiles** (eigene Farbe, Entscheidungs-Icon in der Mitte, +8 generische Standfelder, das Gate-Tor steckt ein). Die **SOR** ist ein **Gremium**, +das an den Gremiums-Gates auf dem Gate-Tile zusammenkommt. **SOR-Besetzung** (laut Geschäftsordnung `…/01_spm_governance/spm_sor_go.yaml`): ständige Mitglieder **SPM (Vorsitz) · Betrieb (OP, = AL B&C + AL App) · SSM · SHM** + **variabel der Service Owner** des betroffenen Service. -| Gate | ID | Entscheidet | Figuren am Gate-Puck | -|------|----|-------------|----------------------| +| Gate | ID | Entscheidet | Figuren auf dem Gate-Tile | +|------|----|-------------|----------------------------| | Gate 1 | tr_01 | **SOR** (Gremium) | SPM + OP + SSM + SHM + SO ≈ **5** | | Gate 2 | tr_09 | **SO** (allein) | SO (**1**) | | Gate 3 | tr_12 | **SOR** (Gremium) | SPM + OP + SSM + SHM + SO ≈ **5** | -**Regel:** Eine Gremiumsentscheidung „öffnet" erst, wenn die geforderten Figuren in -den Mulden des Gate-Pucks stehen — das macht die Governance körperlich erfahrbar. -*(Die 7 Mulden decken die Besetzung mit Puffer ab.)* +**Regel:** Eine Gremiumsentscheidung „öffnet" erst, wenn die geforderten Figuren auf +den Standfeldern des Gate-Tiles stehen — das macht die Governance körperlich erfahrbar. +*(Die 8 Standfelder decken die Besetzung mit Puffer ab.)* ## Mengen (ein Set) @@ -99,6 +99,6 @@ den Mulden des Gate-Pucks stehen — das macht die Governance körperlich erfahr | Einzelrollen-Figuren | ×2 | 16 | **32** | | Team-Sonderfiguren | ×2 | 3 | **6** | | **Σ Figuren** | | | **38** | -| Gate-Puck | – | – | 3 | +| Gate-Tile | – | – | 3 | Für größere Gruppen die Kern-Governance/SOR-Figuren (SPM, SO, OP, SSM, SHM) ggf. zusätzlich doppeln. diff --git a/02_Spielfiguren/figuren-set-b_minifiguren.md b/02_Spielfiguren/figuren-set-b_minifiguren.md index 8ff0457..9d1869c 100644 --- a/02_Spielfiguren/figuren-set-b_minifiguren.md +++ b/02_Spielfiguren/figuren-set-b_minifiguren.md @@ -3,7 +3,7 @@ Finaler Satz (v0.5): **16 Einzelrollen** + **3 Team-Sonderfiguren**. Alle auf dem **gleichen schlanken runden Sockel**, damit sie als geschlossenes Set wirken und gleichmäßig auf den Standfeldern stehen. **Die SOR ist keine Figur**, sondern ein -Gremium an den Gate-Pucks (siehe `README_spielfiguren.md` / `../01_3D-Druck/openscad/puck.scad`). +Gremium an den Gate-Tiles (siehe `README_spielfiguren.md` / `../01_3D-Druck/openscad/gate-tile.scad`). > **Wichtig (v0.6):** Figuren werden **gestellt, nicht gesteckt** (flacher Boden, > kein Pin). **Sockel Ø 20 mm, Figurenhöhe ~50 mm.** Standfelder/Raster sind darauf diff --git a/03_Karten/README_karten.md b/03_Karten/README_karten.md index 2b7570c..e8b2b56 100644 --- a/03_Karten/README_karten.md +++ b/03_Karten/README_karten.md @@ -7,16 +7,13 @@ Freiburg-digital-Look (rot/weiß, Wappen-Logo) analog zur bestehenden Action Car | Kartentyp | Format | Hinweis | |-----------|--------|---------| -| Action Cards | 60 × 90 mm | liegen flach an der aktuellen Station; werden separat selbst produziert | +| Action Cards | 60 × 90 mm | zum Draufstecken auf den Action-Stein (Schlitz 64 mm); werden separat selbst produziert | | Störungskarten | 60 × 90 mm | gleiches Format, anderer Akzent | | Artefaktkarten | 63 × 88 mm (Bridge) | werden in der Service-Akte gesammelt | | Service-Akte (Tableau) | A4 quer / A5 | 15 Slots (A1–A15), Artefakt-Sammler (§3a) | +| Gate-Beschreibungskarten | 60 × 90 mm | stecken im Gate-Tor-Schlitz (65 mm); Layout selbst produziert | | Entscheidungs-Chips | Ø 30 mm | Karte oder 3D-Münze | -> **Keine Gate-Beschreibungskarten mehr:** Gate-Nr/Keeper/Pfade/Artefakte führen -> **App + Gate-Puck-Etikett** (`G1/G2/G3`), siehe §4. Auch der frühere Action-Stein -> ist entfallen — die Action Card liegt einfach flach an der aktuellen Station. - --- ## 1. Action Cards (Szenario-Deck) @@ -89,7 +86,7 @@ Kartendeck nötig) oder den **DPM-Rücklauf** (A15). ## 3a. Service-Akte (Artefakt-Tableau) — Spielelement -Ein **gedrucktes Tableau (A4/A5)**, das **neben der aktuellen Station** liegt und +Ein **gedrucktes Tableau (A4/A5)**, das **neben dem Action-Stein** liegt und mitwandert. Es hat **15 beschriftete Slots** (A1–A15, nach Phase gruppiert) und macht die wachsende Service-Dokumentation sichtbar. Layout: `service-akte.svg`. @@ -125,13 +122,11 @@ der Service über seinen Lebenszyklus an Dokumentation/Artefakten produziert." | Karten | Artefaktkarten 63 × 88 mm (Bridge) | | Menge | 1 (ggf. 2 bei parallelen Tischen) | -## 4. Gate-Anforderungen (App-geführt, keine physische Karte) +## 4. Gate-Beschreibungskarten -Es gibt **keine Gate-Beschreibungskarte** mehr. Gate-Nummer, Gate-Keeper, -Pflicht-Rollen, Entscheidungspfade — **und die erforderlichen Artefakte** — führt die -**App**; am Tisch markiert der **rote Gate-Puck** (Etikett `G1/G2/G3` + Icon) die -Position. Das Gate „öffnet" nur, wenn die erforderlichen Artefaktkarten in der -Service-Akte liegen (vgl. §3a) und die Pflicht-Figuren am Gate-Puck stehen. +Eine Karte je Gate, steckt im Tor-Schlitz: Gate-Nummer, Gate-Keeper, +Pflicht-Rollen, Entscheidungspfade — **und die erforderlichen Artefakte** +(das Gate „öffnet" nur, wenn diese Karten in der Service-Akte liegen, vgl. §3a). | Gate | Keeper | Erforderliche Artefakte | Pfade | |------|--------|-------------------------|-------| diff --git a/04_Tablet-Quiz/README.md b/04_Tablet-Quiz/README.md index 71b3a81..6d80563 100644 --- a/04_Tablet-Quiz/README.md +++ b/04_Tablet-Quiz/README.md @@ -3,9 +3,9 @@ **Status:** Konzept · **Typ:** eigenständiges Software-Teilprojekt des SLC-Workshops 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 +Brett. Es ist der **erklärende Gegenpart** zu den Plättchen und **ersetzt deren +Rückseite**: Die Plättchen tragen nur noch die Kurzbezeichnung, 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. @@ -13,9 +13,9 @@ Lifecycle), stellt pro Station ein **vermittelndes Quiz**, gibt danach die ## 1. Ziel & Rolle im Spiel -- **Stationsführung:** schaltet Station für Station automatisch weiter („Nächste Station") — die Pucks brauchen keinen Code. +- **Stationsführung:** schaltet Station für Station automatisch weiter („Nächste Station") — die Plättchen 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). +- **Vollständige Erklärung:** liefert nach dem Quiz die ausführliche Auflösung (ersetzt die Plättchenrückseite) 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, @@ -45,8 +45,8 @@ dupliziert. 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. +Rollen/RACI + Artefakt aus der YAML) — das ist der Inhalt, der früher auf der +Plättchenrückseite stand. ## 4. Ablauf (UI-Flow) diff --git a/04_Tablet-Quiz/prototype/index.html b/04_Tablet-Quiz/prototype/index.html index a7fca02..537780c 100644 --- a/04_Tablet-Quiz/prototype/index.html +++ b/04_Tablet-Quiz/prototype/index.html @@ -894,7 +894,7 @@ function renderCardScreen(){ $("#panel").innerHTML = `
Wählt Service und Change-Typ der gezogenen Action Card – oder zieht zufällig. Diese Karte liegt an der aktuellen Station und wandert mit durch alle Stationen.
+Wählt Service und Change-Typ der gezogenen Action Card – oder zieht zufällig. Diese Karte steckt im Action-Stein und wandert durch alle Stationen.