From 5043e9ac7b83da81d067fb1bad7be2be2bcd3a53 Mon Sep 17 00:00:00 2001
From: breitenbach76 <patrick@1789innovations.com>
Date: Sat, 30 May 2026 16:02:13 +0200
Subject: [PATCH]  m

---
 04_Tablet-Quiz/README.md            |  46 ++++++-
 04_Tablet-Quiz/prototype/index.html | 181 +++++++++++++++++++++++++---
 2 files changed, 207 insertions(+), 20 deletions(-)

diff --git a/04_Tablet-Quiz/README.md b/04_Tablet-Quiz/README.md
index cc9f491..6d80563 100644
--- a/04_Tablet-Quiz/README.md
+++ b/04_Tablet-Quiz/README.md
@@ -93,9 +93,53 @@ Plättchenrückseite stand.
 - **Inhalt:** Aktivitäten/Gates/Rollen = Brett-Elemente (`../00_Konzept/`).
 - **Ausgang:** Debrief-Daten → Workshop-Dokumentation (`../05_Workshop-Dokumentation/`).
 
-## 8. Offene Punkte
+## 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).
diff --git a/04_Tablet-Quiz/prototype/index.html b/04_Tablet-Quiz/prototype/index.html
index 382dab7..537780c 100644
--- a/04_Tablet-Quiz/prototype/index.html
+++ b/04_Tablet-Quiz/prototype/index.html
@@ -145,6 +145,16 @@
   .pickerItem .dot { width:10px; height:10px; border-radius:50%; flex:none; }
   .pickerItem .id { color:var(--muted); font-size:12px; font-variant-numeric:tabular-nums; }
   .pickerItem .gate { margin-left:auto; font-size:11px; font-weight:700; color:#fff; background:var(--ink); padding:1px 8px; border-radius:999px; }
+  .pickerItem.correct { border-color:var(--ok); background:#f1faf4; }
+  .pickerItem.wrongPick { border-color:var(--bad); background:#fdf3f3; }
+  .recBox { border:1px solid var(--line); border-left:4px solid var(--ok); border-radius:10px; padding:14px 16px; margin:14px 0; }
+  .recBox h4 { margin:0 0 6px; font-size:13px; text-transform:uppercase; letter-spacing:.5px; color:var(--muted); }
+  /* Geführte Tour */
+  .tourBanner { background:#fff7f7; border:1px solid var(--line); border-left:4px solid var(--accent); border-radius:10px; padding:10px 14px; margin-bottom:16px; font-size:13px; line-height:1.45; }
+  .tourBanner b { color:var(--ink); }
+  .tourProg { font-size:12px; color:var(--muted); margin-bottom:8px; font-variant-numeric:tabular-nums; }
+  .tourNarr { background:#eef4fb; border-radius:12px; padding:16px 18px; margin:14px 0; font-size:16px; line-height:1.55; }
+  .tourNarr h4 { margin:0 0 8px; font-size:12px; text-transform:uppercase; letter-spacing:.6px; color:var(--design); }
 </style>
 </head>
 <body>
@@ -178,6 +188,65 @@
 </dialog>
 
 <script>
+/* Empfohlener Einstiegspunkt je Change-Typ (didaktische Auflösung in Schritt 2).
+   Reihenfolge entspricht CHANGE_TYPES. */
+const START_EMPFEHLUNG = [
+  { id:"ds_01", grund:"Ein Major Change auf Top-Level ist strategisch getrieben und betrifft den Service grundlegend – er durchläuft den vollen Lebenszyklus ab dem Design (Service-Definition)." },
+  { id:"ds_01", grund:"Auch ein Major Change auf Low-Level bringt neue Komponenten/Funktionen und braucht ein echtes Design – Einstieg im Design. Unterschied zum Top-Level ist v.a. Tragweite und Freigabe-Ebene, nicht der Einstiegspunkt." },
+  { id:"tr_01", grund:"Ein Normal Change ist geplant und dokumentiert, aber nicht strategisch. Er steigt an Gate 1 ein, wo Build-oder-Konfiguration entschieden wird – meist der Konfigurationspfad (tr_05)." },
+  { id:"op_03", grund:"Ein Standard Change ist vorab genehmigt und im Katalog hinterlegt. Er braucht keine Gates und kein Design, sondern wird im laufenden Betrieb umgesetzt (op_03: Umsetzung freigegebener Standard-Changes)." },
+  { id:"tr_10", grund:"Ein Emergency Change muss die Störung sofort beheben. Der Fix wird beschleunigt ausgerollt (tr_10); die formale Freigabe (Gate 3) erfolgt nachgelagert. Ausgelöst wird er typischerweise durch einen Incident aus Operation/Support." }
+];
+
+/* Geführtes Beispiel ("for dummies"-Tour): EIN konkreter Fall durch den ganzen
+   Lifecycle. Online-Bürgerportal · Major Change Top-Level (neues Landesgesetz zur
+   digitalen Bürgerbeteiligung → Erweiterung um Beteiligungs-Module). */
+const TOUR = {
+  service: 2, change: 0,
+  text: {
+    ds_01: "Das neue Landesgesetz verlangt Online-Beteiligung. Zuerst klären Fachamt und (designierter) Service Owner, was das Beteiligungs-Modul leisten muss: Wer nutzt es (Bürger:innen, Planungsamt)? Welchen Nutzen bringt es? Welche Fristen und Verfügbarkeiten sind gesetzlich nötig? Ergebnis ist ein erster Entwurf der Service-Definition.",
+    ds_02: "Jetzt entsteht das Lösungsdesign: welche Module (Online-Konsultation, Kommentar-Workflows, Veröffentlichung von Plänen), welche Schnittstellen zum bestehenden Portal und zum DMS, welche Datenschutz- und Barrierefreiheits-Vorgaben. Das ist das Service Design Document.",
+    ds_03: "Hier wird geplant, WIE das Modul organisatorisch eingeführt wird – noch nicht technisch: Wer schult die Sachbearbeiter:innen im Planungsamt? Welche Prozesse und Rollen ändern sich? Wann kann der Betrieb übernehmen? Ergebnis: Implementation Blueprint.",
+    ds_04: "Letzte Vorbereitung vor der Transition: Betrieb und Support werden abgestimmt, Tools und Strukturen vorbereitet, ein Early-Life-Support-Konzept skizziert, und der Service wird vollständig im Portfolio erfasst.",
+    tr_01: "Erstes Tor – die SOR entscheidet: bauen oder nur konfigurieren? Da völlig neue Beteiligungs-Module gebraucht werden, fällt die Entscheidung auf ENTWICKLUNG → weiter zu tr_02. (Bei einer reinen Einstellung wäre es Konfiguration, und tr_02–tr_04 würden übersprungen.)",
+    tr_02: "Die Projektleitung steuert die Umsetzung: Abstimmung mit dem Dienstleister, der die Module baut, dazu Termine, Budget und Arbeitspakete.",
+    tr_03: "Projektteam bzw. Dienstleister entwickeln die Beteiligungs-Module: Formulare, Kommentar-Workflows, Veröffentlichungsfunktion und die Schnittstellen.",
+    tr_04: "Die fertigen Komponenten werden geprüft und angenommen (Vollständigkeit, Qualität, Dokumentation) und ans Testmanagement übergeben.",
+    tr_05: "Parameter, Rollen, Zugänge und die Anbindung an Portal und Service-Katalog werden eingerichtet. (Genau hier wäre der Einstieg gewesen, hätte Gate 1 'Konfiguration' entschieden.)",
+    tr_06: "Die Betriebs- und Supportunterlagen entstehen: Betriebshandbuch, Supportanleitungen, Monitoring-Vorgaben und Eskalationswege für das neue Modul.",
+    tr_07: "Das Testmanagement prüft Funktion, Integration und Abnahme – etwa ob eine Online-Konsultation fristgerecht startet und endet und Eingaben korrekt gespeichert werden.",
+    tr_08: "Der Build ist fertig. Alle Unterlagen und Testprotokolle werden für die Prüfung an Gate 2 zusammengestellt.",
+    tr_09: "Zweites Tor – der Service Owner entscheidet allein: Ist alles übergabefähig? Doku vollständig, Abnahme liegt vor, Betrieb und Support vorbereitet → FREIGABE → weiter zu tr_10.",
+    tr_10: "Das Betriebsteam rollt die Module in die produktive Umgebung aus: Systeme konfigurieren, Daten migrieren, Monitoring aktivieren, Zugänge schalten.",
+    tr_11: "Letzter Check vor dem Go-Live: Betriebsdoku, Überwachung und Eskalationswege werden geprüft, die Go-Live-Kommunikation an die Ämter vorbereitet und der Gate-3-Antrag erstellt.",
+    tr_12: "Drittes Tor – die SOR entscheidet im Konsent: Go-Live? Portfolio passt, Betrieb und Support sind bereit, SLAs vereinbart → GO-LIVE. Der Service wird formal ins Portfolio aufgenommen und geht in die Operation.",
+    op_01: "Direkt nach dem Start läuft das Modul unter erhöhter Aufmerksamkeit (Early Life Support): enge Beobachtung, schnelle Hilfe, erste Bürger-Rückmeldungen werden aufgearbeitet. Der Service Owner entscheidet, wann der Normalbetrieb beginnt.",
+    op_02: "Betriebshandbuch und Betriebsprozesse sind bereitgestellt – klare Regeln und Zuständigkeiten für den täglichen Betrieb des Beteiligungs-Moduls.",
+    op_03: "Tagesgeschäft: Benutzer und Berechtigungen, Backups, Routinepflege und die Umsetzung freigegebener Standard-Changes (z. B. ein neues Beteiligungsverfahren anlegen).",
+    op_04: "Es wird sichergestellt, dass genug Personal, Technik und Budget vorhanden sind – inklusive Steuerung des Dienstleisters.",
+    op_05: "Verfügbarkeit und Performance werden überwacht – besonders wichtig, wenn zum Ende einer Beteiligungsfrist viele Bürger:innen gleichzeitig zugreifen.",
+    op_06: "Regelmäßiger Qualitätsbericht: Wurden SLAs/SLOs eingehalten? Wie war die Verfügbarkeit während der Konsultationen? Das ist die Grundlage fürs Review.",
+    op_07: "Über das reine Monitoring hinaus: Trends erkennen – etwa wiederkehrende Lastspitzen oder ein Formular, das auffällig oft abgebrochen wird.",
+    sp_01: "Der Support bekommt seinen Rahmen: Incident- und Request-Prozesse, Reaktionszeiten und Ticketkategorien für das Beteiligungs-Modul.",
+    sp_02: "Lösungen, Workarounds und FAQ werden gepflegt – damit der 1st Level häufige Bürgerfragen schnell beantworten kann.",
+    sp_03: "Eingehende Tickets von Bürger:innen und Ämtern werden gesichtet, priorisiert und an die richtige Stelle geroutet.",
+    sp_04: "Standardanfragen werden erledigt – z. B. ein Zugang für eine neue Sachbearbeiterin im Planungsamt.",
+    sp_05: "Typische Störungen löst der 1st Level direkt – etwa wenn ein Nutzer den Kommentar-Button nicht findet (Anleitung aus der Wissensdatenbank).",
+    sp_06: "Knifflige Fälle gehen an den 2nd Level – z. B. Kommentare werden unter hoher Last nicht gespeichert. Bleibt es ungelöst, entsteht daraus ein Problem Record.",
+    sp_07: "Der Fall wird sauber abgeschlossen: Lösung validiert, Nutzer informiert, Dokumentation und FAQ aktualisiert.",
+    sp_08: "Endgültiges Schließen inklusive Klassifizierung für die Statistik und Erkennen wiederkehrender Fälle.",
+    sp_09: "Ein Incident bleibt ungelöst – eine strukturelle Ursache wird vermutet. Der Problem Manager legt einen Problem Record an.",
+    sp_10: "Mehrere ähnliche Speicher-Fehler häufen sich → sie werden geclustert und gebündelt als Problem Record erfasst.",
+    sp_11: "Ursachensuche: Das Speicherproblem entsteht durch einen Timeout unter Last. Es gibt einen Workaround (Eintrag in die Wissensdatenbank) und die Entscheidung, dass ein Change nötig ist.",
+    rv_01: "Im Review werden Support-KPIs und wiederkehrende Fälle ausgewertet – die Speicher-Probleme tauchen klar als Muster auf.",
+    rv_02: "Der Service wird über vier Dimensionen per Ampel bewertet (Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit). Empfehlung in unserem Fall: IMPROVEMENT.",
+    rv_03: "Die SOR sichtet das Review und entscheidet. In unserem Beispiel: VERBESSERUNG NÖTIG (klein) → rv_04. (Alternativen wären: weiter wie bisher, Redesign rv_05 oder Außerbetriebnahme rv_06.)",
+    rv_04: "Die kleine Verbesserung wird geplant und umgesetzt – z. B. die Last- und Timeout-Optimierung beim Speichern. Sie fließt zurück in den laufenden Betrieb (Operation). Damit schließt sich der Kreis.",
+    rv_05: "In unserem Beispiel NICHT gewählt. Wäre die Änderung grundlegend (z. B. eine komplett neue Beteiligungsplattform), würde sie hier als neuer Demand an den Demand-Lifecycle übergeben – der Service liefe quasi neu durch Design und Transition.",
+    rv_06: "Ebenfalls NICHT gewählt. Würde das Modul z. B. wegen eines Nachfolgesystems abgeschaltet, plant die SOR hier die kontrollierte Stilllegung (Retirement-Plan)."
+  }
+};
+
 /* =========================================================================
    STATIONEN — vollständiger Lifecycle, abgeleitet aus den Blueprint-YAMLs
    (service-lifecycle_design/transition/operation/support/review.yaml v3.2 +
@@ -763,8 +832,8 @@ const STATIONEN = [
 /* ====================== STATE ====================== */
 const LS_KEY = "slc-companion-proto";
 function defaultState(){
-  return { view:"card", service:0, change:0, startIndex:null,
-           index:0, stage:"discuss", quizIndex:0,
+  return { view:"card", service:0, change:0, startIndex:null, startRevealed:false,
+           tourIndex:0, index:0, stage:"discuss", quizIndex:0,
            picks:{}, done:{}, unclear:{} };
 }
 let S = load();
@@ -808,13 +877,14 @@ function draw(){
   document.body.classList.toggle("runMode", S.view==="run");
   renderCardBadge();
   if(S.view==="card") return renderCardScreen();
+  if(S.view==="tour") return renderTour();
   if(S.view==="start") return renderStartScreen();
   renderRun();
 }
 
 function renderCardBadge(){
   const el = $("#cardBadge");
-  if(S.view==="card"){ el.style.display="none"; el.innerHTML=""; return; }
+  if(S.view==="card" || S.view==="tour"){ el.style.display="none"; el.innerHTML=""; return; }
   el.style.display="flex";
   el.innerHTML = `<span class="cb-svc">${USE_CASES[S.service].service}</span><span class="ctChip">${CHANGE_TYPES[S.change]}</span>`;
 }
@@ -832,9 +902,11 @@ function renderCardScreen(){
     <div class="ctText" id="cardTrigger">${USE_CASES[S.service].changes[S.change]}</div>
     <div class="actions">
       <button class="ghost" id="randomCard">🎲 Zufällig ziehen</button>
+      <button class="ghost" id="tourBtn">📘 Geführtes Beispiel</button>
       <div class="spacer"></div>
       <button class="primary" id="toStart">Weiter → Startpunkt wählen</button>
-    </div>`;
+    </div>
+    <p class="note" style="text-align:left">Neu hier? Das „Geführte Beispiel" spielt einen kompletten Fall (Bürgerportal) Station für Station durch – zum Verstehen, ohne Quiz.</p>`;
   const svc=$("#serviceSel"), ch=$("#changeSel");
   svc.innerHTML = USE_CASES.map((u,i)=>`<option value="${i}">${u.service}</option>`).join("");
   ch.innerHTML = CHANGE_TYPES.map((c,i)=>`<option value="${i}">${c}</option>`).join("");
@@ -843,11 +915,58 @@ function renderCardScreen(){
   svc.onchange=()=>{ S.service=+svc.value; save(); refresh(); };
   ch.onchange=()=>{ S.change=+ch.value; save(); refresh(); };
   $("#randomCard").onclick=()=>{ S.service=Math.floor(Math.random()*USE_CASES.length); S.change=Math.floor(Math.random()*CHANGE_TYPES.length); save(); draw(); };
-  $("#toStart").onclick=()=>{ S.view="start"; save(); draw(); };
+  $("#tourBtn").onclick=()=>{ S.view="tour"; S.tourIndex=0; save(); draw(); };
+  $("#toStart").onclick=()=>{ S.view="start"; S.startRevealed=false; save(); draw(); };
 }
 
-/* ---------- Screen 2: Startpunkt bestimmen ---------- */
+/* ---------- Geführte Tour (ein Beispiel durch alle Stationen) ---------- */
+function renderTour(){
+  const st = STATIONEN[S.tourIndex];
+  const ph = PHASEN[st.phase];
+  const chip = st.typ==="gate"
+    ? `<span class="phaseChip gateChip">⛩ Gate ${st.gateNr}</span>`
+    : `<span class="phaseChip" style="background:${ph.color}">${ph.label}</span>`;
+  const raci = st.raci.map(([r,c])=>`<tr><td>${roleLabel(r)}</td><td><span class="raciBadge raci-${c}">${c}</span></td></tr>`).join("");
+  let extra="";
+  if(st.pfade){
+    extra += `<h4>Entscheidungspfade</h4><div class="pfade">` +
+      st.pfade.map(([n,d])=>`<div class="pfad"><b>${n}</b><span style="color:var(--muted)">${d}</span></div>`).join("") + `</div>`;
+  }
+  const narr = TOUR.text[st.id] || "—";
+  const last = S.tourIndex === STATIONEN.length-1;
+  $("#panel").innerHTML = `
+    <div class="tourBanner">📘 Geführtes Beispiel · <b>${USE_CASES[TOUR.service].service}</b> — ${CHANGE_TYPES[TOUR.change]}<br>
+      <span style="color:var(--muted)">${USE_CASES[TOUR.service].changes[TOUR.change]}</span></div>
+    <div class="tourProg">Station ${S.tourIndex+1} von ${STATIONEN.length}</div>
+    ${chip}
+    <div class="stationName">${st.name}</div>
+    <div class="stationId">${st.id}</div>
+    <div class="tourNarr"><h4>In diesem Beispiel</h4>${narr}</div>
+    <div class="reveal">
+      <h4>Fachlich (aus dem Blueprint)</h4>
+      <p>${st.beschreibung}</p>
+      <h4>Umfasst</h4><ul>${st.umfasst.map(u=>`<li>${u}</li>`).join("")}</ul>
+      <h4>Rollen / RACI</h4>
+      <table class="raci"><thead><tr><th>Rolle</th><th>RACI</th></tr></thead><tbody>${raci}</tbody></table>
+      <h4>Artefakt</h4><p>${st.artefakt}</p>
+      ${extra}
+    </div>
+    <div class="actions">
+      <button class="ghost" id="tourExit">Tour beenden</button>
+      <button class="ghost" id="tourBack" ${S.tourIndex===0?'disabled':''}>← Zurück</button>
+      <div class="spacer"></div>
+      <button class="primary" id="tourNext">${last?'Fertig — zur Startseite':'Weiter →'}</button>
+    </div>`;
+  $("#tourExit").onclick=()=>{ S.view="card"; save(); draw(); };
+  $("#tourBack").onclick=()=>{ if(S.tourIndex>0){ S.tourIndex--; save(); renderTour(); } };
+  $("#tourNext").onclick=()=>{ if(last){ S.view="card"; save(); draw(); } else { S.tourIndex++; save(); renderTour(); } };
+}
+
+/* ---------- Screen 2: Startpunkt bestimmen (Tipp → Auflösen) ---------- */
 function renderStartScreen(){
+  const rec = START_EMPFEHLUNG[S.change];
+  const recIndex = STATIONEN.findIndex(s=>s.id===rec.id);
+  const revealed = S.startRevealed;
   const groups={};
   STATIONEN.forEach((st,i)=>{ (groups[st.phase]=groups[st.phase]||[]).push({st,i}); });
   let list="";
@@ -855,7 +974,12 @@ function renderStartScreen(){
     if(!groups[ph]) continue;
     list += `<div class="pickerPhase">${PHASEN[ph].label}</div>`;
     groups[ph].forEach(({st,i})=>{
-      list += `<div class="pickerItem ${i===S.startIndex?'sel':''}" data-i="${i}">
+      let cls="pickerItem";
+      if(revealed){
+        if(i===recIndex) cls+=" correct";
+        else if(i===S.startIndex) cls+=" wrongPick";
+      } else if(i===S.startIndex) cls+=" sel";
+      list += `<div class="${cls}" data-i="${i}">
         <span class="dot" style="background:${PHASEN[ph].color}"></span>
         <span class="id">${st.id}</span>
         <span class="nm">${st.name}</span>
@@ -863,22 +987,41 @@ function renderStartScreen(){
       </div>`;
     });
   }
+  let head, actions;
+  if(!revealed){
+    head = `<p class="muted">Welches Tile ist der sinnvolle Einstieg für diese Action Card? Diskutiert in der Gruppe, wählt ein Tile und löst dann auf.</p>`;
+    actions = `<button class="ghost" id="backToCard">← Action Card</button>
+      <div class="spacer"></div>
+      <button class="primary" id="revealStart" ${S.startIndex==null?'disabled':''}>Auflösen</button>`;
+  } else {
+    const tip = S.startIndex==null ? `` :
+      (S.startIndex===recIndex
+        ? `<p style="color:var(--ok);font-weight:600;margin:0 0 8px">Euer Tipp ${STATIONEN[S.startIndex].id} passt zum empfohlenen Einstieg. ✓</p>`
+        : `<p style="color:var(--bad);font-weight:600;margin:0 0 8px">Euer Tipp war ${STATIONEN[S.startIndex].id} — nicht der empfohlene Einstieg.</p>`);
+    head = `${tip}<div class="recBox"><h4>Empfohlener Einstieg · ${CHANGE_TYPES[S.change]}</h4>
+      <p style="margin:0 0 6px"><b>${rec.id} — ${STATIONEN[recIndex].name}</b></p>
+      <p style="margin:0;color:var(--muted)">${rec.grund}</p></div>`;
+    const ownDiff = (S.startIndex!=null && S.startIndex!==recIndex);
+    actions = `<button class="ghost" id="backToCard">← Action Card</button>
+      <div class="spacer"></div>
+      ${ownDiff?`<button class="ghost" id="startOwn">Auf eigener Wahl starten</button>`:``}
+      <button class="primary" id="startRec">Auf ${rec.id} starten →</button>`;
+  }
   $("#panel").innerHTML = `
     <div class="setupHead">Schritt 2 · Startpunkt</div>
     <h2 class="setupTitle">Wo startet ihr sinnvollerweise?</h2>
-    <p class="muted">Das hängt vom Change-Typ ab – ein großer (Major) Change beginnt eher im Design, ein Standard- oder Emergency-Change steigt oft später ein. Diskutiert in der Gruppe und wählt das Tile, auf das der Action-Stein zuerst gestellt wird. Es gibt nicht die eine richtige Antwort.</p>
+    ${head}
     <div class="pickerList">${list}</div>
-    <div class="actions">
-      <button class="ghost" id="backToCard">← Action Card</button>
-      <div class="spacer"></div>
-      <button class="primary" id="confirmStart" ${S.startIndex==null?'disabled':''}>Hier starten →</button>
-    </div>`;
-  $("#panel").querySelectorAll(".pickerItem").forEach(el=>{
-    el.onclick=()=>{ S.startIndex=+el.dataset.i; save(); renderStartScreen(); };
-  });
-  $("#backToCard").onclick=()=>{ S.view="card"; save(); draw(); };
-  const cs=$("#confirmStart");
-  if(cs) cs.onclick=()=>{ if(S.startIndex==null) return; S.index=S.startIndex; S.view="run"; S.stage="discuss"; S.quizIndex=0; save(); draw(); };
+    <div class="actions">${actions}</div>`;
+  if(!revealed){
+    $("#panel").querySelectorAll(".pickerItem").forEach(el=>{
+      el.onclick=()=>{ S.startIndex=+el.dataset.i; save(); renderStartScreen(); };
+    });
+  }
+  $("#backToCard").onclick=()=>{ S.view="card"; S.startRevealed=false; save(); draw(); };
+  if($("#revealStart")) $("#revealStart").onclick=()=>{ if(S.startIndex==null) return; S.startRevealed=true; save(); renderStartScreen(); };
+  if($("#startRec")) $("#startRec").onclick=()=>{ S.index=recIndex; S.view="run"; S.stage="discuss"; S.quizIndex=0; save(); draw(); };
+  if($("#startOwn")) $("#startOwn").onclick=()=>{ S.index=S.startIndex; S.view="run"; S.stage="discuss"; S.quizIndex=0; save(); draw(); };
 }
 
 /* ====================== RENDER: RUN (Station) ====================== */