---
type: decisions-log
projekt: 3d.lehrstun.de
tags: [entscheidungen]
---

# Entscheidungs- und Änderungslog — 3d.lehrstun.de

> Anker-Format: `[[decisions#E-NNN]]` aus anderen Dateien verlinkt direkt
> auf den jeweiligen Entscheid.

Format: chronologisch, neueste oben. Pro Entscheidung: Kontext, Optionen, Entscheidung, Begründung.

---

## 2026-05-23 — Projekt-Skelett angelegt

### E-001: Bestehende Arduino-Kurs-Architektur als Vorlage nehmen
**Kontext:** Neuer Kurs für 3D-Druck-AG. `arduino.lehrstun.de` läuft erprobt seit Mai 2026.
**Optionen:** (a) Neue Architektur, (b) Arduino-Kurs als Basis übernehmen + anpassen, (c) Bestehende Site erweitern.
**Entscheidung:** (b) — Arduino-Stack (Flask/SQLite/Jinja2 + Tier-PIN-Login + Inline-Edit + PummelHummel) als Basis, eigenständige Site.
**Begründung:** Herb will einheitliches Design. Tier-PIN-Login + Migrations-System + Admin-Inline-Edit haben sich im Schultest 2026-05-11 bewährt. Eigenständige Site, weil andere Domain (`3d.lehrstun.de`) und Inhalte komplett anders.

### E-002: SuS-Profil als Primär-Objekt (statt Gruppe)
**Kontext:** AG hat 8-10 SuS, optional 2er-Gruppen.
**Optionen:** (a) Gruppe primär (wie Arduino), (b) Profil primär, Paarung sekundär.
**Entscheidung:** (b).
**Begründung:** Bei einer AG ändert sich die Sozialform — Einzelarbeit ist hier der Normalfall, Paarung ein Sonderfall. Das ist anders als beim Arduino-Pflichtkurs, wo 2er-Gruppen fest waren. Datenmodell muss das abbilden: `profil` + optional `paarung`.
**Wirkt sich aus auf:** [[datenmodell#profil]], [[datenmodell#paarung]]

### E-003: Login = Vorname + Tier-Icon + 4-stellige PIN
**Kontext:** SuS-Identifikation auf der Site.
**Optionen:** (a) Tier-PIN (wie Arduino), (b) Vorname + PIN, (c) TinkerCAD-Style (Klassencode + Spitzname), (d) Hybrid Vorname+Tier+PIN.
**Entscheidung:** (d) — Vorname (Klarname) + Tier-Icon (visuell) + 4-stellige PIN.
**Begründung:** Herb-Wunsch. Vorname für persönliche Ansprache, Tier-Icon für Differenzierung bei Namens-Duplikaten und als spielerisches Element, PIN als Auth.

### E-004: Sichtbarkeit zwischen SuS — nur Projekttitel
**Kontext:** SuS sollen sich gegenseitig inspirieren, aber kein Druck durch Stand-Vergleich.
**Optionen:** (a) Nur Lehrer sieht alles, (b) alle SuS sehen alles, (c) Lehrer voll + SuS sehen nur Projekttitel.
**Entscheidung:** (c).
**Begründung:** Inspiration ja (Projekttitel sind Anregung), Vergleich nein (Stand/Drucke/Probleme bleiben privat).

### E-005: Drucker-Status via Bambu Cloud-API (kein Pi-Bridge)
**Kontext:** Drucker stehen im Schul-LAN, Site auf Hetzner. Live-Status gewünscht.
**Optionen:** (a) Raspberry Pi in der Schule als MQTT-Bridge, (b) Cloud-API direkt vom Hetzner pollen, (c) manuell, (d) gar nicht.
**Entscheidung:** (b).
**Begründung:** Herb: "Alle SuS in der AG haben über Handy-App Cloud-Zugang zu den Druckern, bisher keine schlechten Erfahrungen." Cloud-API ist akzeptabel, kein Pi-Hardware-Aufwand. Risiko bekannt: Bambu ändert die API ab und zu → Fallback "manueller Status" eingeplant.
**Wirkt sich aus auf:** [[druckerapi]]

### E-006: Kein Druckjob-Upload von der Site zum Drucker
**Kontext:** Wäre nice-to-have, aber Bambu erlaubt das nur mit „Developer Mode" am Drucker.
**Optionen:** (a) Developer Mode aktivieren + Site darf Jobs senden, (b) SuS slicen weiterhin in Bambu Studio.
**Entscheidung:** (b).
**Begründung:** Developer Mode würde Bambu-Cloud-Konto-Funktionen am Drucker abschalten. Zu hoher Preis für einen Komfort-Gewinn. Site verwaltet nur Reservierungen + zeigt Status.
**Wirkt sich aus auf:** [[druckerapi#was-wir-nicht-machen]], [[slotsystem]]

### E-007: Drucker laufen auch über Nacht / Freistunden
**Kontext:** Druckzeit ≫ Schulstunde.
**Entscheidung:** Drucker dürfen 24/7 laufen, Slot-System bildet das ab.
**Begründung:** Druckraum mit Dauerlüftung, Bambu-Drucker mit Notabschaltung. Erlaubt komplexere Projekte.

### E-008: PLA + PLA+ als Default, PETG/ABS nur unter Aufsicht
**Entscheidung:** Material-Auswahl bei Druckauftrag standardmäßig auf PLA-Varianten beschränkt; PETG/ABS nur freischaltbar im Admin.
**Begründung:** Herb: "Für die grundlegenden Sachen erst mal alles mit PLA (weil ungefährlich)."
**Wirkt sich aus auf:** [[sicherheit]], [[datenmodell#druckauftrag]]

### E-009: Site-Inhalt bei Kursstart = Skelett + L1-L3 fertig
**Entscheidung:** Lektionen L4+ und Software-Detailseiten kommen später inline durch Herb + Markus.
**Begründung:** Herb hat 3D-Druck selbst noch nie unterrichtet — Inhalt entsteht im Doing. Admin-Inline-Edit muss daher von Anfang an stabil sein.

### E-010: Brand = "3D-Druck-AG"
**Begründung:** Herb-Entscheidung. Passt zum tatsächlichen Format (Wahl-AG, nicht Kurs).

### E-011: Obsidian-tauglich, aber kein Plugin-Zwang
**Kontext:** `D:\Claude-Projekte\` ist bereits Obsidian-Vault. Markdown + Wikilinks sollten überall funktionieren.
**Entscheidung:** Doku-Dateien als reines Markdown mit normalen Links (keine `[[wikilinks]]`-Pflicht), damit sie auch in jedem anderen Editor lesbar bleiben. Wikilinks dürfen ergänzt werden, sind aber optional.
**Begründung:** Markus arbeitet vielleicht nicht mit Obsidian — Doku muss universell lesbar bleiben.

---

## 2026-05-24 — Reality-Check + Selbstlern-Loop

Nach Analyse aus vier Perspektiven (neuer SuS / erfahrener SuS / Lehrer / technische Machbarkeit) plus Vergleich mit `arduino.lehrstun.de`. Vollständige Analyse: `~/.claude/plans/f-hre-noch-einmal-eina-cosmic-wind.md` (approved).

### E-012: AG ist offen, jahrelang, keine festen Termine
**Kontext:** Hatte ursprünglich „12 Termine à 60 Min" vom Arduino-Trimester unwissend übernommen.
**Entscheidung:** Die AG ist Nachmittags-Wahlangebot, läuft über Jahre, kein Lehrplan, freier Zugang.
**Begründung:** Herb-Korrektur. Bedeutet: Mitgliedschaften sind dauerhaft, Onboarding-Pfad für Neue, danach freie Bibliotheks-Nutzung.
**Wirkt sich aus auf:** [[kurskonzept]], [[etappen]]

### E-013: Onboarding-Pfad statt Pflicht-Lektionen
**Kontext:** „L1-L3 Pflicht für alle" passt nicht zu einer freien AG.
**Entscheidung:** L1-L3 werden zum **Onboarding-Pfad** — Pflicht nur für Neue. Erledigt → unsichtbar im Cockpit.
**Begründung:** Bei kontinuierlicher AG-Mitgliedschaft kommt nicht jeder gleichzeitig dazu. Onboarding ist Einstiegs-Werkzeug, kein Curriculum.
**Wirkt sich aus auf:** [[kurskonzept]], [[selbstlern-loop]], [[datenmodell#profil_lektion_status]]

### E-014: Selbstlern-Loop mit interner Projekt-Bibliothek
**Kontext:** Mentoring-Idee von Herb. Die Site wächst über die Jahre durch SuS-Projekte selbst.
**Entscheidung:** Vollständiger Projekt-Lebenszyklus: Stöbern → Auswählen → Arbeiten → Abschluss-Checkliste → Lehrer-Review → AG-öffentlich. Vernetzung über Stöbern (Variante 1), nicht Auto-Match.
**Begründung:** Macht die Site wertvoller als jeden externen Katalog. SuS sehen „bei uns hat das schonmal jemand gemacht". Lehrer-Review ist Qualitätsfilter.
**Wirkt sich aus auf:** [[selbstlern-loop]], [[datenmodell#projekt]], [[routen]]

### E-015: Feedback nach Abschluss = A-Variante (sachlich) + optionaler Freitext
**Entscheidung:** Drei Stufen: 🟢 zufrieden / 🟡 würde Sachen anders machen / 🔴 nicht geklappt, aber gelernt. Optionales Freitext-Feld „Was würdest du anderen mitgeben?".
**Begründung:** Sachliche Sprache schlägt Maker-Slang oder Sterne-Bewertung. Freitext optional, weil 8.-Klässler Pflicht-Freitext oft nicht ausfüllen.
**Wirkt sich aus auf:** [[selbstlern-loop]], [[datenmodell#projekt]]

### E-016: File-Storage als BLOB in SQLite, 30 MB pro Datei, abstrahiert
**Kontext:** Projekt-Dateien (STL, 3MF, Fotos) gehören zum Lebenszyklus.
**Entscheidung:** Files in SQLite-BLOBs, Limit 30 MB pro Datei. File-Handling über `services/datei.py` abstrahieren, damit später Migration auf Hetzner-Object-Storage / S3 möglich ist.
**Begründung:** SQLite hält 2-3 GB ohne Performance-Probleme; bei 8 SuS × 5 Projekte/Jahr × 5 Files × 10 MB → ~2 GB/Jahr. Reicht für die ersten 5 AG-Jahre.
**Wirkt sich aus auf:** [[datenmodell#projekt_datei]]

### E-017: Lehrer-Review mit drei Aktionen (Variante 3)
**Entscheidung:** Lehrer kann beim Review (a) freigeben (mit oder ohne eigene Bearbeitung), (b) Rückfrage stellen (Status zurück + Notiz im Cockpit), (c) hart löschen (für Penismodelle, Copyright-Probleme).
**Begründung:** Flexibilität. Hartes Löschen mit Audit-Log-Eintrag (Datum, Lehrer, SuS, optional Grund — aber Dateien sind weg).
**Wirkt sich aus auf:** [[lehrer-dashboard]], [[selbstlern-loop]]

### E-018: 3D-Vorschau mit Three.js — Cover-Foto aus 3D-Ansicht
**Kontext:** SuS vergisst manchmal Cover-Foto. Lehrer beim Review oder SuS selbst soll Screenshot aus STL-Vorschau machen können.
**Entscheidung:** Three.js + STLLoader im Browser einbinden (zwei JS-Dateien in `static/js/`, kein npm, kein Build).
**Begründung:** Herb-OK. Externe Frontend-Dependency, ca. 600 KB. Funktioniert offline auf jedem modernen Browser, inkl. iPad. Falls Browser-Test scheitert: Lehrer macht Screenshot in Bambu Studio manuell.
**Wirkt sich aus auf:** [[selbstlern-loop]], `static/js/three.min.js` + `STLLoader.js`

### E-019: Onboarding-Pfad = Selbst-Zertifizierung
**Kontext:** Wer markiert eine Onboarding-Lektion als „fertig"?
**Optionen:** (a) SuS klickt selbst „fertig", (b) Lehrer nickt ab.
**Entscheidung:** (a) — selbst-zertifiziert, analog zu `gruppe_lektion_status` im Arduino-Kurs.
**Begründung:** Lehrer sieht im Drill-Down-Dashboard ohnehin Fortschritts-Stände — Abnahme-Workflow wäre Overhead. Vertrauen geht vor Kontrolle.
**Wirkt sich aus auf:** [[datenmodell#profil_lektion_status]], [[selbstlern-loop]]

### E-020: 8 Empfehlungen aus Reality-Check angenommen (V1-V8)
- **V1 — Cockpit progressiv:** zeigt nur was zum Status passt (Onboarding nicht erledigt → nur Onboarding-Karte; nach Abschluss kommen Projekt-Karte, Slot-Buchung etc. dazu).
- **V2 — Slot-Buchung erst nach L1 (Sicherheits-Lektion).** Bis dahin Hinweis statt Button.
- **V3 — Stunden-Beginn-Abfrage radikal kurz.** Ein Radio, ein optionales Freitext-Feld. Default: „Ich arbeite an X weiter" als Ein-Klick-Option.
- **V4 — Abschluss-Checkliste auf 3 Pflicht-Felder runter** (Selbsteinschätzung + Cover-Foto **oder** STL + 1 Tag). Rest optional.
- **V5 — Drill-Down-Lehrer-Dashboard** mit „Wer ist heute hier / Wartet auf Review / Wer hängt fest".
- **V6 — Rückfrage-Mechanik via Cockpit-Banner**, keine E-Mail.
- **V7 — Persistenter Login-Lockout in DB-Tabelle** (statt In-Memory wie Arduino-Kurs).
- **V8 — Blueprint-Struktur von Anfang an** (`routes/oeffentlich.py`, `routes/profil.py`, `routes/admin.py`, `routes/api.py`, `services/bambu.py`).

### E-021: Herb-Zusatz „Ich arbeite weiter"-Knopf
**Kontext:** Zu V1/V3 ergänzt: bei laufenden Projekten soll das Stunden-Beginn-Modal mit einem Klick übersprungen werden können.
**Entscheidung:** Modal hat als allererste Option „Ich arbeite an meinem laufenden Projekt weiter" — bei Klick: kein Freitext nötig, direkt ins Cockpit. Erkennt das System, dass ein aktives Projekt da ist, ist diese Option vorausgewählt.
**Begründung:** Reibungsfreie Routine für erfahrene SuS, die wochenlang am gleichen Projekt arbeiten.
**Wirkt sich aus auf:** [[selbstlern-loop]], [[datenmodell#check_in]]

### E-022: ZSL-Material in 8-10 Projekten umarbeiten, Rest später
**Kontext:** ZSL Baden-Württemberg liefert 20+ CC-BY-4.0-Projekte. Zu viel auf einmal.
**Entscheidung:** Markus + Herb wählen 8-10 Projekte aus (gemischte Schwierigkeit), arbeiten Beschreibungen + Bilder in unser Design um (mit Urhebernachweis). Rest als Notiz „weitere verfügbar" — SuS-Projekte ergänzen die Bibliothek automatisch über die Zeit.
**Begründung:** Keep it small (Herb). Wachstum kommt aus SuS-Projekten + späterer Erweiterung durch Lehrer-Inline-Edit.
**Wirkt sich aus auf:** [[selbstlern-loop]], [[offene-fragen]]

---

## Vorlage für neue Einträge

```
## YYYY-MM-DD — Titel

### E-NNN: Kurz-Titel der Entscheidung
**Kontext:**
**Optionen:**
**Entscheidung:**
**Begründung:**
```