179 lines
13 KiB
Markdown
179 lines
13 KiB
Markdown
---
|
||
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 + 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`](../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`](../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:**
|
||
```
|