3d.lehrstun.de/docs/decisions.md

type, projekt, tags

type	projekt	tags
decisions-log	3d.lehrstun.de	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 + Herr Rechmann. 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: Herr Rechmann 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-023: Port 5058 statt 5057 auf Hetzner

Kontext: Beim ersten Deploy-Versuch war 5057 von meta.lehrstun.de (uvicorn) belegt — gegen unsere Konvention im CLAUDE.md. Entscheidung: 3d-ag.service läuft auf Port 5058, app.py liest PORT aus ENV (Default lokal 5057). Begründung: Kollisionsfrei, klare ENV-Steuerung, lokal bleibt es bei 5057 für Konsistenz mit der bisherigen Doku. Wirkt sich aus auf: app.py, /etc/systemd/system/3d-ag.service auf Hetzner, ../CLAUDE Port-Notiz.

E-024: PummelHummel/Alph für Lektions-Feedback ab Initial-Deploy

Kontext: Markus testet als Alpha-Schüler die 14 Lektionen vor dem ersten echten AG-Termin. Entscheidung: Alph-Widget direkt mit dem Initial-Deploy aktivieren (einstellung.feedback_widget_aktiv='1'). Begründung: Ohne Widget kein strukturiertes Feedback → wäre nach dem Schultest mühsam zu reden. Mit Widget kommen kategorisierte Hinweise direkt in die DB, lassen sich mit der „Für KI kopieren"-Funktion ausgewertet werden. Wirkt sich aus auf: feedback_modul/ integriert in app.py, feedback-Tabelle via feedback_modul/schema.py DDL.

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: Herr Rechmann + 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:**