Files
LehrerApp/TODO.md
T
2026-08-13 19:57:48 +02:00

52 KiB
Raw Blame History

LehrerApp — Entwicklungs-Roadmap

Strukturierte ToDo-Liste aller offenen Entwicklungsschritte. Jeder Punkt ist so formuliert, dass er einzeln an einen Agenten übergeben werden kann.

Stand: 2026-08-04 Legende: [ ] offen · [~] teilweise umgesetzt · [x] fertig


0. Konventionen für alle Aufgaben

Diese Regeln gelten für jede Aufgabe unten und müssen nicht wiederholt werden.

  • MVVM: Logik in ViewModels (CommunityToolkit.Mvvm, [ObservableProperty] / [RelayCommand]), Views enthalten nur Binding. Kein Code-Behind außer Dialog-Verdrahtung.
  • DI: Neue Repositories/Services/ViewModels in LehrerApp.Desktop/AppBootstrapper.cs registrieren. Repositories + Listen-VMs = Singleton, Detail-/Dialog-VMs = Transient.
  • Daten: Neue Collections in LehrerApp.Data/LiteDbContext.cs anlegen, Indexe in EnsureIndexes(). Interface nach LehrerApp.Core/Interfaces/IRepositories.cs, Implementierung nach LehrerApp.Data/Repositories/AllRepositories.cs.
  • Dialoge: Window mit Close(true/false), DataContext manuell gesetzt (Muster siehe AddGroupDialog.axaml.cs).
  • Sprache: Alle UI-Texte auf Deutsch. Datumsformat dd.MM.yyyy, Kultur de-DE.
  • Modelle: UpdatedAt bei jedem Speichern setzen (Grundlage für Sync-Konfliktauflösung).

1. Klausuren & Leistungsüberprüfungen

Modelle Exam, ExamTask, GradingKeyEntry, ExamResult existieren bereits in Exam.cs, Repositories ebenfalls. Die komplette UI fehlt.

Niveaudifferenzierung (E/G/Förder) ist bereits umgesetzt — nicht aus dieser Liste, sondern ein separater Bedarf (Nachteilsausgleich/Binnendifferenzierung): LearningGroup.IsDifferentiated (Checkbox in den Stammdaten) blendet eine Niveau-Zuordnung je Schüler ein (GroupMembership.Niveau, Schüler-Tab). Klausuren bekommen optional ein Niveau; Punkteeingabe und Auswertung filtern dann automatisch auf die passenden Schüler. Workflow: G-Klausur normal anlegen, per "Duplizieren" (1.1.4) die E-Variante mit eigenen Aufgaben/Punkten ableiten (Niveau wird beim Duplizieren bewusst zurückgesetzt). Vollständig individuelle Förderklausuren (nur für einen einzelnen Schüler) laufen pragmatisch über "Abwesend" bei den übrigen Schülern statt über eine eigene Schüler-Zuordnung.

1.1 Klausur anlegen und verwalten

  • 1.1.1 Dialog AddExamDialog — Titel, Datum, Fach, Klausurnummer, Notizen. Ersetzt den TODO-Stub AddExam() in GroupViewModels.cs. Umgesetzt als ExamDialog/ExamDialogViewModel.
  • 1.1.2 Klausur bearbeiten/löschen (Kontextmenü im Klausuren-Tab, Löschen mit Rückfrage).
  • 1.1.3 Statuswechsel Planned → Conducted → Graded → Returned per Button, inkl. Farbcodierung des Status im DataGrid.
  • 1.1.4 Klausur aus bestehender Klausur duplizieren (Aufgaben + Notenschlüssel übernehmen, neues Datum) — für Parallelkurse.

1.2 Aufgabenstruktur (ExamTask)

  • 1.2.1 Editor für die Aufgabenliste: Nr., Titel, Maximalpunkte, Gewichtung. Zeilen hinzufügen/entfernen/umsortieren. Umgesetzt im ExamDialog (Teil von 1.1.1).
  • 1.2.2 Automatische Anzeige der Gesamtpunktzahl, Warnung bei 0 Punkten.
  • 1.2.3 Optional: Teilaufgaben (a/b/c) — erfordert Modellerweiterung, vorher entscheiden.
  • 1.2.4 Zuordnung von Kompetenzen (CompetencyItem) zu einzelnen Aufgaben — Voraussetzung für die Kompetenzauswertung in 8.3.

1.3 Notenschlüssel

  • 1.3.1 Editor für GradingKey mit Vorbelegung aus GradingService.DefaultKey1To6() / DefaultKey0To15() je nach GradingSystem der Gruppe. Umgesetzt im ExamDialog (Teil von 1.1.1), analog zum Aufgaben-Editor.
  • 1.3.2 Notenschlüssel als wiederverwendbare Vorlage speichern (neues Modell GradingKeyTemplate + Repository) und in Einstellungen verwalten.
  • 1.3.3 Live-Vorschau: Punktegrenzen absolut anzeigen (z.B. "Note 2 ab 45 von 60 P.").
  • 1.3.4 Validierung: lückenlose, absteigende Prozentgrenzen, keine Dopplungen (GradingService.ValidateGradingKey).

1.4 Punkteeingabe & Korrektur

  • 1.4.1 Eingaberaster: Zeilen = Schüler, Spalten = Aufgaben, letzte Spalte Summe + Note. Note wird live über GradingService.CalculateGrade() berechnet. Umgesetzt als eigener Dialog ExamGradingDialog, erreichbar über "Punkte eingeben" im Klausuren-Tab (Button/Kontextmenü bei ausgewählter Klausur).
  • 1.4.2 Tastaturnavigation: Tab bewegt sich nativ zur nächsten Zelle, Enter/Pfeil-Hoch/ Pfeil-Runter springen zur gleichen Spalte in der Nachbarzeile, direkte Zifferneingabe und halbe Punkte (Komma oder Punkt) erlaubt.
  • 1.4.3 Kennzeichnung "Abwesend" (ExamResult.Absent) per Checkbox — Note zeigt "abwesend" statt einer berechneten Note. Ausschluss aus Statistiken über 1.5 umgesetzt.
  • 1.4.4 Kommentarfeld pro Schüler (ExamResult.Comment).
  • 1.4.5 Validierung: Punkte < 0 oder > Maximalpunkte der Aufgabe wird rot markiert und nicht gespeichert (PointsCell.TrySetValue).
  • 1.4.6 Autosave nach jeder Zelle (kein expliziter Speichern-Button nötig).

1.5 Klausurauswertung

  • 1.5.1 Notenspiegel (Häufigkeitsverteilung als Balken), Durchschnitt, Median, Anteil unter 4 / unter 5 Punkten. Umgesetzt als neuer Dialog ExamEvaluationDialog, erreichbar über "Auswertung" im Klausuren-Tab. Bei Notensystem 16 zeigt der Schwellenwert sinngemäß "Anteil nicht ausreichend (Note 5/6)" statt der Punktegrenzen. Abwesende werden aus allen Statistiken ausgeschlossen (löst damit auch den Hinweis aus 1.4.3 ein).
  • 1.5.2 Aufgabenanalyse: durchschnittlicher Erfüllungsgrad pro Aufgabe in Prozent, Kennzeichnung auffällig schwacher Aufgaben (Ø < 50 %, rot markiert).
  • 1.5.3 Notenschlüssel nachträglich verschieben und Auswirkung sofort im Notenspiegel sehen — Änderungen wirken sich live aus, erst "Übernehmen" schreibt sie in die Klausur zurück.
  • 1.5.4 Export der Auswertung — als eigenständiger CSV-Export direkt im Dialog umgesetzt (analog zum bestehenden JSON-Export der Kompetenzkataloge), nicht über eine gemeinsame Export-Infrastruktur, da Kapitel 11 ("Bisher nicht vorhanden — komplett neu") noch aussteht.

2. Noten & Zeugnisnoten

Modell Grade existiert in Planning.cs, GradeRepository ebenfalls. Der Tab "Noten" in GroupDetailView.axaml ist jetzt vollständig umgesetzt (siehe unten), ebenso der gleichnamige Tab im Schülerdetail (2.5).

2.1 Notenübersicht der Gruppe

  • 2.1.1 Matrix: Zeilen = Schüler, Spalten = alle Leistungen (Klausuren, Mitarbeit je Halbjahr, sonstige Noten). Zelle zeigt Note/Punkte.
  • 2.1.2 Spalte "Gesamt" mit gewichtetem Durchschnitt über GradingService.WeightedAverage().
  • 2.1.3 Sortierung nach Name / Gesamtnote, Umschalten Noten ↔ Punkte.
  • 2.1.4 Halbjahresfilter (H1 / H2 / Gesamtjahr), berücksichtigt GroupMembership.Period.

2.2 Einzelnoten pflegen

  • 2.2.1 Dialog "Note hinzufügen": Kategorie (GradeCategory), Wert, Datum, Gewichtung, Notiz.
  • 2.2.2 Note bearbeiten / löschen mit Historie (wer/wann geändert) — mindestens CreatedAt sichtbar.
  • 2.2.3 Sammelerfassung: eine Note (z.B. Hausaufgabenkontrolle) für die ganze Gruppe auf einmal.

2.3 Gewichtungsschema

  • 2.3.1 Neues Modell GradingScheme je Gruppe: prozentuale Anteile von Klausuren / Mitarbeit / sonstige Leistungen (z.B. 50/40/10).
  • 2.3.2 UI zur Bearbeitung, Validierung auf Summe 100 %.
  • 2.3.3 Voreinstellung je Gruppentyp (Class vs. Course) in den Einstellungen.

2.4 Zeugnisnote

  • 2.4.1 Berechnung der Zeugnisnote aus Schema (2.3) + allen Teilnoten, Rundungsregel konfigurierbar (kaufmännisch / pädagogisch abweichbar).
  • 2.4.2 Manuelles Übersteuern mit Pflicht-Begründung (pädagogischer Spielraum).
  • 2.4.3 Zeugnisnoten-Ansicht mit Sperren/Festschreiben zum Konferenztermin.
  • 2.4.4 Export der Zeugnisnotenliste (siehe 11.2).

2.5 Notenentwicklung

  • 2.5.1 Verlaufsdiagramm pro Schüler über das Schuljahr (im Schülerdetail).
  • 2.5.2 Auffälligkeiten markieren: Abfall um ≥ 1 Note, Versetzungsgefährdung (Note 5/6).

Umgesetzt über GradeOverviewViewModels.cs (Matrix-Tab, Einzelnoten-Dialoge), ReportGradeViewModels.cs (Zeugnisnoten-Dialog) und die neuen Modelle GradingScheme/ReportGrade in Planning.cs. Das Gewichtungsschema wird pro Gruppe gesucht, sonst die Voreinstellung des Gruppentyps (Einstellungen → Notenschema), sonst ein Fallback 50/40/10 verwendet; Bereiche ohne Werte werden bei der Berechnung ausgelassen und die verbleibenden Prozentanteile neu normiert (GradingService.CalculateReportGrade()). Notenentwicklung im Schülerdetail zeigt ein einfaches Balken-Sparkline je Lerngruppe über alle Klausur- und Einzelnoten-Einträge chronologisch — jeder Balken ist ein einzelner Grade- bzw. Klausurergebnis-Eintrag, keine Mitarbeit-"Sitzung". Die Herkunft (Kategorie wie "Mündlich"/"Mitarbeit" oder Klausurtitel) stand ursprünglich nur im Tooltip und nicht sichtbar auf der Kachel — das führte zu Verwirrung, welche Zahl wofür steht, und wurde ergänzt (GradeHistoryPoint.Label jetzt auch unter dem Balken sichtbar, nicht nur im Tooltip), siehe StudentDetailView.axaml.


3. Mündliche Mitarbeit — offene Punkte

Grundfunktion ist umgesetzt (Sitzungen, Raster, Schnelleingabe-Dialog). Siehe ParticipationViewModels.cs.

3.1 Aspekte konfigurieren

  • 3.1.1 UI zum Anlegen/Bearbeiten/Löschen von ParticipationAspect pro Gruppe (Fach Chemie: z.B. "Experiment", "Protokoll") — GroupId = null bleibt global.
  • 3.1.2 Reihenfolge der Aspekte per Drag & Drop oder Hoch/Runter-Buttons festlegen (bestimmt auch die Q/W/E/R/T-Belegung im Schnelleingabe-Dialog).
  • 3.1.3 Aspekt-Typen Scale3, Binary, Points in Raster und Dialog vollständig unterstützen (bisher primär Scale5).
  • 3.1.4 Aspekt deaktivieren statt löschen, damit alte Einträge gültig bleiben.

3.2 Aggregation zur Mitarbeitsnote

  • 3.2.1 Gewichtung je Aspekt konfigurierbar (z.B. Qualität 50 %, Quantität 30 %, Experiment 20 %).
  • 3.2.2 Berechnung einer Mitarbeitsnote je Halbjahr aus allen Sitzungen, Ausgabe als Note bzw. Punkte je nach GradingSystem der Gruppe.
  • 3.2.3 Umgang mit fehlenden Werten festlegen (nicht bewertet ≠ schlecht bewertet).
  • 3.2.4 Übernahme der berechneten Mitarbeitsnote als Grade mit Category = Participation (Anbindung an 2.1).
  • 3.2.5 Trendanzeige pro Schüler (Entwicklung über die Sitzungen hinweg).

Umgesetzt über den neuen Dialog "Ø Mitarbeitsnote" im Mitarbeit-Tab (ParticipationGradeViewModels.cs, ParticipationGradeDialog.axaml): Zeitraum wählbar (Gesamtjahr/H1/H2), Aspekt-Gewichtung live editierbar (ParticipationAspect.Weight, da die eigentliche Aspekt-Verwaltung aus 3.1 noch fehlt), Mapping der Bewertungsskala (-2..+2) auf Note/Punkte über GradingService.ParticipationGrade(), einfache Trendanzeige (↑/↓/→) durch Vergleich der ersten mit der zweiten Hälfte der Sitzungen. "Übernehmen" aktualisiert eine bestehende Mitarbeit-Note für denselben Zeitraum statt sie zu duplizieren (erkannt über den Grade.Note-Tag).

3.3 Sitzungen

  • 3.3.1 Sitzung automatisch aus einer geplanten Lesson erzeugen (Datum + Thema übernehmen) — Abhängigkeit zu 4.2.
  • 3.3.2 Anwesenheit in der Sitzung erfassen — als ParticipationEntry.Attendance (krank: Entschuldigung offen/entschuldigt/unentschuldigt), nicht als "verspätet"; siehe unten. Vorgriff auf 5.2, ersetzt dessen 5.2.1/5.2.4 aber nicht vollständig (kein Fehlzeitenmodul über alle Stundentypen hinweg, nur innerhalb von Mitarbeit-Sitzungen).
  • 3.3.3 Sitzung bearbeiten/löschen inkl. Rückfrage bei vorhandenen Bewertungen.
  • 3.3.4 Sitzungen mehrerer Gruppen im Kalenderüberblick.

Abschnittsnoten & Mitarbeits-Assistent (nicht aus dieser Liste, eigener Workflow-Bedarf)

Ergänzt den Workflow "regelmäßig (alle 47 Wochen) mündliche Noten zu einer Abschnittsnote zusammenziehen, daraus die Halbjahresnote bilden":

  • ParticipationEntry.HomeworkMissing (bool) und .Attendance (AttendanceStatus?: ExcusePending/Excused/Unexcused) — editierbar direkt im Bewertungsraster (ParticipationTabView.axaml, Spalten "HA"/"Anwesenheit") und im neuen Mitarbeits-Assistenten. ExcusePending ist bewusst ein Zwischenzustand, da die Entschuldigung meist erst später eintrifft.
  • Neues Modell ParticipationSection (Abschnitt: Start/Ende/Bezeichnung je Gruppe) — nur abgeschlossene Abschnitte werden gespeichert, der laufende Zeitraum ergibt sich aus dem Ende des letzten Abschnitts bis heute.
  • Neues Fenster Mitarbeits-Assistent (ParticipationWizardViewModels.cs, ParticipationWizardDialog.axaml): Zeitleiste je Schüler (Sitzungen als Bewertungs-Badges, Klausurtermine, Symbole für Hausaufgaben/ Bemerkung/Anwesenheit), gruppiert nach Abschnitten. "Abschnitt abschließen" berechnet für alle Schüler einen Notenvorschlag aus den Sitzungen im Zeitraum und speichert ihn als Grade (Category = Participation, Note = "Abschnitt: <Bezeichnung>"), individuell nachjustierbar. "Halbjahresnote aus Abschnitten übernehmen" mittelt die Abschnittsnoten eines Zeitraums und speichert sie über denselben Grade.Note-Tag wie der bestehende "Ø Mitarbeitsnote"-Dialog (3.2) — beide Wege sind kompatibel, der Assistent baut auf 3.2 auf statt es zu ersetzen.
  • Dashboard-Kachel "Offene Entschuldigungen": listet alle ExcusePending-Einträge der letzten 21 Tage gruppenübergreifend mit Direktauflösung; ältere Einträge werden ausgeblendet statt automatisch entschieden (pädagogische Entscheidung bleibt bei der Lehrkraft).

4. Unterrichtsplanung

Modelle Unit und Lesson existieren, UnitRepository/LessonRepository ebenfalls. Navigationspunkt "Unterrichtsplanung" ist ein PlaceholderViewModel (MainWindowViewModel.cs:41).

4.1 Unterrichtseinheiten (Unit)

  • 4.1.1 Listenansicht der Einheiten je Gruppe mit Status und Zeitraum (ersetzt den Platzhalter im Tab "Planung").
  • 4.1.2 Dialog Einheit anlegen/bearbeiten: Titel, Fach, Zeitraum, Status, Notizen.
  • 4.1.3 Kompetenzen aus dem Katalog (siehe 8) einer Einheit zuordnen — Mehrfachauswahl.
  • 4.1.4 Einheit als Vorlage speichern und in eine andere Gruppe kopieren (inkl. Stunden, ohne Datumsbezug).
  • 4.1.5 Fortschrittsanzeige: gehaltene / geplante Stunden der Einheit.

4.2 Einzelstunden (Lesson)

  • 4.2.1 Stundenliste innerhalb einer Einheit, sortiert nach Datum/Stundennummer.
  • 4.2.2 Stundeneditor: Thema, Phase, Methoden, Materialien, Hausaufgabe. Methoden/Materialien als Chips mit Autovervollständigung aus bisherigen Einträgen.
  • 4.2.3 Status Planned → Conducted setzen, Reflexionsfeld nach der Stunde.
  • 4.2.4 Stunden verschieben (z.B. bei Ausfall) — Folgestunden automatisch nachrücken.
  • 4.2.5 Stunden serienweise aus dem Stundenplan (4.3) erzeugen.

4.3 Stundenplan

  • 4.3.1 Neues Modell TimetableSlot (Gruppe, Wochentag, Stunde, Raum) + Repository.
  • 4.3.2 Wochenstundenplan-Ansicht als Raster mit Farbcodierung je Gruppe.
  • 4.3.3 Bearbeitung per Klick/Drag im Raster.
  • 4.3.4 Abgleich mit LearningGroup.HoursPerWeek (Warnung bei Abweichung).
  • 4.3.5 Schulferien und Feiertage hinterlegen (Bundesland wählbar) und aus der Planung ausnehmen.

4.4 Wochen-/Tagesansicht

  • 4.4.1 Kalenderansicht über alle Gruppen: Woche und Tag.
  • 4.4.2 Sprung von einer Stunde direkt in die Mitarbeitserfassung dieser Gruppe.
  • 4.4.3 Anzeige anstehender Klausurtermine und Abgabefristen im Kalender.

5. Schülerdokumentation

Wichtige Abweichung von der ursprünglichen Planung (5.2): Vor der Umsetzung zeigte sich, dass 5.2 wie ursprünglich beschrieben eine zweite, parallele Fehlzeiten-Erfassung neben dem bereits bestehenden Anwesenheits-Tracking aus Kapitel 3 (ParticipationEntry.Attendance, AttendanceStatus) ergeben hätte — zwei potenziell widersprüchliche Datenquellen für dieselbe Frage ("war der Schüler da?"). Auf Rückfrage entschieden: 5.2 wird als Auswertung der bestehenden Anwesenheitsdaten umgesetzt, keine zweite Erfassung. 5.2.1 und 5.2.4 existierten dadurch faktisch schon (Quick-Input-Dialog bzw. "Offene Entschuldigungen" im Dashboard).

5.1 Einträge erfassen

  • 5.1.1 Dialog "Dokumentation hinzufügen" mit Typwahl (Conversation, Incident, SupportPlan, Absence) und typabhängigen Feldern — DocumentationDialog.axaml, DocumentationViewModels.cs. Deutsche Anzeige über DocumentationTypeDisplay/SupportStatusDisplay, analog zum NiveauDisplay-Muster. Feldbezogene Validierung wie in 13.2.4.
  • 5.1.2 Teilnehmerliste (Participants) bei Gesprächen — Chip-Liste mit Hinzufügen/ Entfernen im Dialog, nur sichtbar bei Typ "Gespräch".
  • 5.1.3 Kennzeichen "vertraulich" — vertrauliche Einträge zeigen in der Übersicht nur Datum/Typ/Schloss-Symbol, Titel und Inhalt erst nach Klick auf "Anzeigen" (DocumentationItem.IsRevealed, session-lokal, keine erneute Passwortabfrage — dafür gibt es bereits die App-Sperre aus 13.3.5).
  • 5.1.4 Bearbeiten/Löschen mit Rückfrage (neuer generischer ConfirmDialog); Löschen markiert nur IsDeleted/DeletedAt statt hart zu entfernen — IDocumentationRepository.Delete. Ein echtes HardDelete existiert separat, nur für die Löschfristen-Bereinigung in 5.4.2.
  • 5.1.5 Zwei weitere Dokumentationstypen ergänzt (Nutzer-Feedback nach Erstauslieferung): - Elternanruf (DocumentationType.ParentCall): Gesprächspunkte werden im normalen Dialog vorab geplant (ParentCallData.Points); ein separater ParentCallSessionDialog ("Gespräch begleiten", Button an jedem Elternanruf-Eintrag) hakt sie während des Telefonats ab und hält Eindrücke/Ergänzungen als Protokoll fest (ParentCallData.Impressions, IsConducted, ConductedDate). Punkte mit unverändertem Text behalten beim erneuten Bearbeiten ihren Abhak-Status (Zuordnung über ParentCallPoint.Id, sonst über Textabgleich — ein umbenannter Punkt gilt als neu und startet offen; bewusste Vereinfachung). - Elternbrief (DocumentationType.ParentLetter): Entwurf/Inhalt, Absendedatum, Rückmeldung erhalten (ja/nein), Rückmeldedatum und -notiz (ParentLetterData). - Datei-Anhänge (an allen Dokumentationstypen, nicht nur Elternbrief): über LiteDBs eingebauten Dateispeicher (ILiteStorage<string>, per Skript verifiziert — funktioniert zuverlässig, im Gegensatz zum defekten Rebuild-mit-Passwort aus 13.3.4) — LiteAttachmentStorage.cs. Größe strikt auf 10 MB je Datei begrenzt (IAttachmentStorage.MaxSizeBytes), damit die Datenbankdatei (und jedes Backup, 13.3.1) nicht durch Anhänge aufgebläht wird. Neu hochgeladene, aber nie gespeicherte Anhänge werden beim Abbrechen des Dialogs wieder gelöscht, damit keine verwaisten Blobs zurückbleiben; beim endgültigen Löschen eines Eintrags (5.4.2) werden auch dessen Anhänge mit entfernt. Randnotiz: Beim Schreiben der Tests für den Datei-Speicher fiel eine bereits vorher latent vorhandene Testinfrastruktur-Schwäche auf: LiteDbContext nutzt LiteDBs statischen, geteilten BsonMapper.Global für die Index-Auflösung — bei paralleler Testausführung über mehrere Testklassen hinweg (xUnit-Standard) führte das sporadisch zu "Member X not found on BsonMapper"-Fehlern in völlig unbeteiligten Tests. Behoben durch [assembly: CollectionBehavior(DisableTestParallelization = true)] in AssemblyInfo.cs — Data-Tests laufen jetzt sequenziell (bei elementaren In-Memory-Tests kein spürbarer Zeitverlust).
  • 5.1.6 Labels zur Nachverfolgung (Nutzer-Feedback): freie Text-Labels an jedem Dokumentationseintrag (Documentation.Tags), mit AutoCompleteBox-Vorschlägen (DocumentationTagDisplay.Suggestions: Kritisch, Nacharbeiten, Mit JGL abklären, Erkundigung einholen, Elterngespräch nötig, Mit Schulleitung abklären, Klassenkonferenz, Frist beachten, Beobachten, Erledigt — eigene Labels bleiben trotzdem frei möglich). Farbcodierung nach Dringlichkeit statt nach Label-Identität (DocumentationTagDisplay.ColorHex): rot = Priorität, orange = Handlungsbedarf, blau = im Blick behalten, grün = abgeschlossen, grau = freies Label. Als farbige Chips in der Dokumentationsliste sichtbar (DocumentationItem.TagChips). Dabei außerdem behoben: die Farblegende der Notenentwicklung-Balken (2.5) fehlte sichtbar im UI (nur im Tooltip) — wirkte dadurch wie zufällige/abwechselnde Farbgebung statt wie das eigentliche Signal "Auffälligkeit". Jetzt als kleine Legende über dem Diagramm sichtbar, siehe StudentDetailView.axaml.

5.2 Fehlzeiten (als Auswertung des bestehenden Anwesenheits-Trackings, siehe oben)

  • 5.2.1 Schnelle Abwesenheitserfassung je Stunde — bereits vorhanden über AttendanceHomeworkQuickInputDialog und den Mitarbeits-Assistenten (Kapitel 3).
  • 5.2.2 Fehlzeitenbilanz je Schüler und laufendes Schuljahr — AttendanceBalanceService.cs, reine Auswertungslogik (kontrollierte Stunden, entschuldigt/unentschuldigt/offen, Fehlquote in %), angezeigt im Schülerdetail-Tab "Dokumentation". Schulisch veranlasste Abwesenheit (OtherSchoolEvent) zählt bewusst nicht als Fehlzeit des Schülers.
  • 5.2.3 Schwellenwert-Warnung (> 20 %) — AttendanceBalance.ExceedsThreshold im Schülerdetail sowie eine neue "Fehlzeiten-Warnung"-Karte im Dashboard (alle Schüler über dem Schwellenwert, sortiert nach Fehlquote).
  • 5.2.4 Nachträgliches Entschuldigen mit Frist-Hinweis — bereits vorhanden über die "Offene Entschuldigungen"-Karte im Dashboard (21-Tage-Grenze, aus Kapitel 3).

5.3 Förderpläne

  • 5.3.1 Förderplan anlegen (Maßnahmenliste, Überprüfungsdatum, Status) — über den 5.1-Dialog mit Typ "Förderplan" (SupportData: Measures, ReviewDate, Status).
  • 5.3.2 Wiedervorlage: fällige Überprüfungen (Status Aktiv, Überprüfungsdatum in den nächsten 14 Tagen oder überfällig) erscheinen als eigene Dashboard-Karte "Förderplan-Wiedervorlage", überfällige rot hervorgehoben.
  • 5.3.3 Verlaufsdokumentation — die Dokumentationsliste im Schülerdetail zeigt alle Förderplan-Einträge chronologisch; bewusst keine zusätzliche Gruppierung über eine Plan-ID, da das bestehende flache Documentation-Modell dafür ausreicht.

5.4 Datenschutz

  • 5.4.1 Vertrauliche Einträge nur nach zusätzlicher Bestätigung anzeigen — siehe 5.1.3 (zusammen umgesetzt, da es sich um dieselbe UI-Stelle handelt).
  • 5.4.2 Löschfristen — neuer Tab "Datenschutz" in den Einstellungen: konfigurierbare Aufbewahrungsfrist in Jahren (PrivacySettingsService.cs, Standard 3 Jahre), Liste abgelaufener Einträge zur manuellen Prüfung mit "Endgültig löschen" (IDocumentationRepository.HardDelete). Löscht nie automatisch.
  • 5.4.3 Export einzelner Schülerdaten für Auskunftsersuchen (Art. 15 DSGVO) — PersonalDataExportService.cs, JSON-Export mit Stammdaten, Gruppenzuordnungen, Noten, Klausurergebnissen, Mitarbeit und Dokumentation (auch als vertraulich markierte Einträge — das Vertraulich-Kennzeichen blendet nur die laufende Ansicht aus, ist aber keine pauschale rechtliche Ausnahme vom Auskunftsanspruch der betroffenen Person selbst). Hinweis: ob im Einzelfall eine Ausnahme greift (z.B. schutzwürdige Belange Dritter nach Landes-Schulrecht), muss die verantwortliche Lehrkraft/Schule selbst prüfen — das ist keine Rechtsberatung.

6. Arbeitszeit & Aufgaben

Modelle WorkTask und TimeEntry existieren, Repositories ebenfalls. Navigationspunkt "Arbeitszeit" ist ein PlaceholderViewModel.

6.1 Aufgabenverwaltung

  • 6.1.1 Aufgabenliste mit Filter nach Status, Kategorie, Gruppe und Fälligkeit.
  • 6.1.2 Aufgabe anlegen/bearbeiten: Titel, Kategorie, Gruppe, Fälligkeit, geschätzte Dauer, Notizen.
  • 6.1.3 Status per Klick wechseln (Open → InProgress → Done), erledigte ausblenden.
  • 6.1.4 Wiederkehrende Aufgaben (wöchentlich/monatlich).
  • 6.1.5 Automatische Aufgabe "Klausur korrigieren" beim Statuswechsel einer Klausur auf Conducted (Anbindung an 1.1.3).

6.2 Zeiterfassung

  • 6.2.1 Timer starten/stoppen mit Zuordnung zu Aufgabe oder Kategorie.
  • 6.2.2 Manuelle Nacherfassung eines Zeitblocks (Datum, VonBis oder Dauer).
  • 6.2.3 Wochenübersicht der erfassten Zeit, Summen je Kategorie.
  • 6.2.4 Schätzung vs. tatsächliche Dauer je Aufgabe vergleichen.

6.3 Auswertung

  • 6.3.1 Monats-/Jahresauswertung nach Kategorie und Gruppe (Diagramm + Tabelle).
  • 6.3.2 Abgleich mit der Pflichtstundenzahl (in Einstellungen hinterlegt).
  • 6.3.3 Export der Arbeitszeitauswertung (siehe 11.2).

7. Schüler & Gruppen — Verfeinerungen

Grundfunktionen sind vorhanden (StudentViewModels.cs, GroupViewModels.cs). Niveau-Zuordnung je Schüler (E/G/Förder, GroupMembership.Niveau) ist bereits umgesetzt, siehe Hinweis in Kapitel 1 — betrifft auch Kurse, nicht nur Klassen.

7.1 Schüler

  • 7.1.1 Schüler löschen / auf inaktiv setzen inkl. Hinweis auf verknüpfte Daten.
  • 7.1.2 Suche in der Schülerliste (Name, Gruppe) mit Sofortfilter.
  • 7.1.3 Foto/Avatar je Schüler (optional, lokal gespeichert) für schnellere Zuordnung.
  • 7.1.4 Serienbrieffelder aus Kontaktdaten (Anrede, Adresse) für Elternbriefe.
  • 7.1.5 Sitzplan je Gruppe (Raster mit Drag & Drop), Sprung von Sitzplatz zur Bewertung.

7.2 Gruppen

  • 7.2.1 Gruppe bearbeiten und löschen — bereits vorhanden (EditGroupCommand/DeleteGroupCommand/ ToggleArchiveCommand in GroupListViewModel), nicht Teil der aktuellen Klausuren-Arbeit, beim Review aber bestätigt. Die Löschung läuft transaktional und entfernt alle fachlich abhängigen Datensätze (inkl. Zeugnisnoten, gruppenspezifischem Notenschema und Mitarbeitsabschnitten). Dokumentation, Aufgaben und Zeiteinträge bleiben als historische Nachweise erhalten; ihr GroupId wird auf null gesetzt.
  • 7.2.2 Gruppe ins neue Schuljahr übernehmen: Kopie mit gleicher Schülerschaft, neues SchoolYear, neue GroupMembership-Einträge.
  • 7.2.3 Schüler aus einer Gruppe entfernen (GroupMembership.LeftAt setzen statt löschen).
  • 7.2.4 Umgang mit MembershipPeriod.Custom in allen Auswertungen prüfen (Schüler zählt nur im belegten Zeitraum).
  • 7.2.5 Archivansicht abgeschlossener Schuljahre (schreibgeschützt).

7.3 Import

  • 7.3.1 CSV-Import von Schülerlisten mit Spaltenzuordnung im Dialog.
  • 7.3.2 Dublettenerkennung beim Import (Name + Geburtsdatum), Zusammenführen anbieten.
  • 7.3.3 Import-Vorschau mit Fehlerliste vor dem endgültigen Übernehmen.

8. Kompetenzen

Katalogverwaltung und JSON-Import existieren in SettingsViewModel.cs, Format dokumentiert in Kompetenzkatalog-KI-Prompt.md.

8.1 Katalogverwaltung

  • 8.1.1 Kompetenzen innerhalb eines Bereichs umsortieren (SortOrder bearbeitbar machen).
  • 8.1.2 Katalog exportieren (JSON) — Gegenstück zum vorhandenen Import.
  • 8.1.3 Katalog von einer Jahrgangsstufe in eine andere kopieren.
  • 8.1.4 Import-Konflikte behandeln: Merge statt Ersetzen anbieten.

8.2 Verwendung im Unterricht

  • 8.2.1 Kompetenzen einer Unterrichtseinheit zuordnen (siehe 4.1.3).
  • 8.2.2 Kompetenzen einzelnen Klausuraufgaben zuordnen — umgesetzt mit 1.2.4.
  • 8.2.3 Abdeckungsübersicht: welche Kompetenzen wurden im Schuljahr behandelt/geprüft?

8.3 Kompetenzorientierte Auswertung

  • 8.3.1 Kompetenzprofil je Schüler aus Klausuraufgaben-Ergebnissen berechnen.
  • 8.3.2 Gruppenübersicht: durchschnittlicher Erfüllungsgrad je Kompetenz, Identifikation von Wiederholungsbedarf.
  • 8.3.3 Kompetenzbericht je Schüler als Ausdruck/Export.

9. Dashboard

Basis vorhanden in DashboardViewModel.cs. Kleiner Monatskalender ist bereits umgesetzt (Farbcodierung Unterricht/Klausur, Hervorhebung "eigene Klasse" über LearningGroup.IsOwnClass, feste Kartenbreite/-position).

  • 9.1 Heutige Stunden mit Uhrzeit und Raum anzeigen (Abhängigkeit zu 4.3).
  • 9.2 Direkter Absprung von einer Stunde in Mitarbeitserfassung bzw. Stundenplanung.
  • 9.3 Kachel "Anstehende Termine": Klausuren, Förderplan-Überprüfungen, Abgabefristen.
  • 9.4 Kachel "Offene Korrekturen" mit Fortschritt (x von y Klausuren bewertet).
  • 9.5 Kachel "Auffälligkeiten": Fehlzeitenüberschreitungen, Notenabfall, Versetzungsgefährdung.
  • 9.6 Dashboard-Kacheln ein-/ausblendbar und in der Reihenfolge konfigurierbar.
  • 9.7 Automatische Aktualisierung beim Zurücknavigieren (aktuell nur manueller Refresh).
  • 9.8 Kalender-Detailansicht: Tag im Monatskalender anklickbar/auswählbar, zeigt in einem angrenzenden Feld die Termine dieses Tages (Unterricht, Klausuren, perspektivisch Konferenzen/Sondertermine) mit Details und Sprungmöglichkeit in die jeweilige Ansicht. Sinnvoll erst, wenn weitere Terminarten existieren — Abhängigkeit zu Kapitel 4 (Unterrichtsplanung/Termine) sowie ggf. einem neuen Termine-Modell.

10. Sync & Server

Grundgerüst existiert in LehrerApp.Sync und LehrerApp.Api, ist aber nur aktiv, wenn eine Server-URL konfiguriert ist.

10.1 Client

  • 10.1.1 Sync-Einrichtung in den Einstellungen: Server-URL, Login, Token speichern.
  • 10.1.2 Verbindungstest mit klarer Fehlermeldung (nicht erreichbar / Token ungültig).
  • 10.1.3 Konfliktanzeige in der UI — was ConflictResolver entscheidet, muss sichtbar sein.
  • 10.1.4 Manuelles Auslösen einer vollständigen Synchronisation.
  • 10.1.5 Statusanzeige erweitern: letzter Sync, Anzahl wartender Events, Fehlerzustand.
  • 10.1.6 Lokale Schreibvorgänge atomar an die Outbox (EventQueue) anbinden — aktuell ist das Sync-Grundgerüst registriert, die Repositories erzeugen aber noch keine Sync-Ereignisse.

10.2 Server

  • 10.2.1 Benutzerverwaltung/Registrierung prüfen und absichern (Endpoints.cs).
  • 10.2.2 Rate Limiting und Request-Größenbegrenzung.
  • 10.2.3 Serverseitiges Backup der Event-/Snapshot-Dateien.
  • 10.2.4 Docker-Setup in docker/ verifizieren und dokumentieren.

10.3 Verschlüsselung

  • 10.3.1 Schlüsselübertragung auf ein zweites Gerät (QR-Code oder Passphrase).
  • 10.3.2 Warnung und Wiederherstellungspfad bei verlorenem Schlüssel.
  • 10.3.3 Prüfen, welche Daten unverschlüsselt über PlainEventStore laufen — personenbezogene Daten dürfen das nicht.

11. Export, Druck & Berichte

Bisher nicht vorhanden — komplett neu.

  • 11.1 Basisinfrastruktur: Export-Service mit Formatwahl und Speicherdialog.
  • 11.2 CSV-Export für Notenlisten, Klausurauswertung, Arbeitszeit, Fehlzeiten.
  • 11.3 PDF-Erzeugung (Bibliothek auswählen — z.B. QuestPDF) mit einheitlichem Layout.
  • 11.4 Druckvorlagen: Notenliste, Klausur-Notenspiegel, Sitzplan, Kompetenzbericht, Schülerdokumentation.
  • 11.5 Serienbrief/Elternbrief aus Kontaktdaten (Abhängigkeit zu 7.1.4).
  • 11.6 Vollständiger Datenexport eines Schuljahres (Archivierung).

12. Einstellungen & Stammdaten

Fächer- und Kompetenzverwaltung existiert bereits in SettingsView.axaml.

  • 12.1 Lehrerprofil: Name, Kürzel, Schule, Pflichtstundenzahl.
  • 12.2 Schuljahr-Einstellungen: Beginn/Ende, Halbjahresgrenze, Ferien (SchoolYearService erweitern).
  • 12.3 Standard-Notenschlüssel und Standard-Gewichtungsschema hinterlegen (2.3.3, 1.3.2).
  • 12.4 Darstellung: Hell/Dunkel-Modus, Schriftgröße.
  • 12.5 Speicherort der Datenbank anzeigen und ändern.
  • 12.6 Backup-Verwaltung (siehe 13.3) in den Einstellungen zugänglich machen.

13. Technische Basis

13.1 Tests

  • 13.1.1 Testprojekt LehrerApp.Tests angelegt (referenziert LehrerApp.Core, analog zu LehrerApp.Data.Tests für die Datenschicht). Noch ohne Testfälle — folgt mit 13.1.2ff.
  • 13.1.2 Unit-Tests für GradingService (Notenschlüssel-Grenzfälle, gewichteter Schnitt) — 41 Tests in GradingServiceTests.cs, deckt CalculateGrade, ValidateGradingKey, WeightedAverage, RoundToGrade, ParticipationGrade, ValidateGradingScheme und CalculateReportGrade ab.
  • 13.1.3 Unit-Tests für SchoolYearService (Jahreswechsel, Schuljahresgrenze) — 13 Tests in SchoolYearServiceTests.cs. Dafür CurrentSchoolYear/RecentSchoolYears um ein optionales today-Parameter erweitert (Default weiterhin DateTime.Today), um den 1.-August-Wechsel deterministisch zu testen, ohne bestehende Aufrufer zu ändern.
  • 13.1.4 Repository-Tests gegen eine In-Memory-LiteDB — LiteDbContext um einen Stream-Konstruktor erweitert (new LiteDatabase(stream), kein Datei-I/O nötig), 19 Tests in RepositoryTests.cs: u.a. Kaskadenlöschung bei GroupRepository.Delete/ExamRepository.Delete/ ParticipationSessionRepository.Delete, Eindeutigkeitsprüfungen (GroupMembership, ParticipationEntry), Fach-Validierung (Trimmen, Duplikate, Löschsperre bei Verwendung), GradingScheme-Auflösung gruppenspezifisch vs. Voreinstellung.
  • 13.1.5 Tests für die Mitarbeits-Aggregation (3.2) und Zeugnisnotenberechnung (2.4) — neues Testprojekt LehrerApp.Desktop.Tests (referenziert LehrerApp.Desktop, damit ViewModel-Logik ohne echtes UI getestet werden kann), gemeinsame Fakes in Fakes.cs. 9 Tests für ParticipationGradeAggregationTests.cs (gewichtetes Mittel, "nicht bewertet" ≠ schlechte Note, Trend, Aspektgewicht 0, Halbjahresfilter, Übernehmen-Update-statt-Duplikat) und 9 für ReportGradeCalculationTests.cs (Schema-Auflösung gruppenspezifisch/Voreinstellung/Fallback, Pflicht-Begründung beim Übersteuern, Festschreiben friert den Stand ein, Rundungsregel).
  • 13.1.6 Tests für ConflictResolver — neues Testprojekt LehrerApp.Sync.Tests, 10 Tests in ConflictResolverTests.cs (Desktop schlägt Companion immer, Gleichstand nach Zeitstempel, kein Konflikt bei unterschiedlicher Entität/gleichem Gerät). Dabei zwei echte Fehler gefunden und behoben: (1) SyncEvent hatte keine [BsonId]-Markierung auf EventId — LiteDB vergab dadurch einen eigenen, unabhängigen _id, wodurch EventQueue.Acknowledge() nie etwas aus der Queue löschte (verlorene Konflikte blieben für immer offen). (2) ConflictResolver verglich local.Timestamp (aus LiteDB, Kind=Local mit verschobenen Ticks) direkt mit remote.Timestamp (Kind=Utc) — DateTime-Vergleiche ignorieren Kind und vergleichen nur rohe Ticks, wodurch die Gleichstand-Regel außerhalb von UTC+0 falsch entschied. Fix: .ToUniversalTime() auf beiden Seiten vor dem Vergleich.

13.2 Fehlerbehandlung & Logging

  • 13.2.1 Zentrale Exception-Behandlung mit verständlicher Fehlermeldung statt Absturz — GlobalExceptionHandler.cs. Dispatcher.UIThread.UnhandledException protokolliert Fehler aus Befehlen/Ereignis-Handlern. Nur als wiederherstellbar eingestufte I/O-, Netzwerk-, Timeout- und Abbruchfehler werden mit Handled = true behandelt und als Toast angezeigt. Unbekannte Programmier-/Zustandsfehler dürfen die Anwendung kontrolliert beenden, statt mit möglicherweise beschädigtem Zustand weiterzulaufen. AppDomain.UnhandledException und TaskScheduler.UnobservedTaskException sind Sicherheitsnetze für Fehler außerhalb des UI-Threads — dort kann ein bereits "IsTerminating"-Fehler nicht mehr verhindert werden, wird aber vollständig protokolliert.
  • 13.2.2 Logging in Datei im App-Datenverzeichnis, mit Rotation — AppLogger.cs, tägliche Datei unter <AppData>/LehrerApp/logs/, Dateien älter als 14 Tage werden beim Start gelöscht. 6 Tests in AppLoggerTests.cs.
  • 13.2.3 Einheitliche Benachrichtigungen (Toast/Snackbar) für Erfolg und Fehler — NotificationService.cs, Overlay unten rechts in MainWindow.axaml, blendet sich nach 3 s (Erfolg) bzw. 6 s (Fehler) automatisch aus. Aktuell an den globalen Exception-Handler angebunden; bestehende Dialoge zeigen Erfolg/Fehler weiterhin über ihre eigenen Statuszeilen (StatusMessage/ValidationMessage) — eine Umstellung dieser bestehenden Stellen auf Toasts wäre ein eigener, größerer Umbau über viele Dateien hinweg und ist bewusst nicht Teil dieser Aufgabe.
  • 13.2.4 Validierungsmeldungen einheitlich an den Eingabefeldern statt in Sammel-Labels. Alle Dialoge mit Formularfeldern umgestellt: AddStudentDialog, ContactEditDialog, AddGroupDialog, StudentGradesDialog (GradeEditItem), CollectiveGradeDialog, ExamDialog, AddSessionDialog, ParticipationWizardDialog (Abschnitt-Formular), Einstellungen (Fach anlegen, Notenschlüssel-Vorlage anlegen, Notenschlüssel-Editor). Muster: pro Feld eine {Feld}Error-Property, Save() leert alle Fehler-Properties am Anfang, sammelt alle Verstöße über eine lokale valid-Variable statt beim ersten Fehler zurückzukehren, und bricht erst am Ende mit if (!valid) return; ab — so werden mehrere Fehler gleichzeitig angezeigt. Bewusst als Sammel-Meldung belassen, wo die Meldung sich auf eine Kombination mehrerer Felder bezieht statt auf ein einzelnes Feld: GradingKeyValidation (Notenschlüssel-Tabelle als Ganzes), GradingSchemeEditItem.ValidationMessage (Summe der drei Prozent-Felder muss 100 ergeben), ReportGradeRow.ValidationMessage (Override-Wert + Begründung gehören zusammen), CatalogValidation (Kompetenzkatalog-Panel: Fachauswahl, Bereichsname und JSON-Import teilen sich einen Status-Bereich), AddStudentToGroupDialogViewModel.ValidationMessage (einzige Prüfung "Schüler ausgewählt?", kein Textfeld zum Andocken vorhanden).

13.3 Datensicherheit

  • 13.3.1 Automatisches lokales Backup der LiteDB beim Start (rollierend, letzte 10) — BackupService.cs. Reine Dateikopie nach <AppData>/LehrerApp/backups/, läuft in AppBootstrapper.BuildServices() vor dem Öffnen der Datenbank (unabhängig von Verschlüsselung, kein LiteDB-Handle nötig). Behält standardmäßig die letzten 10 Backups, ältere werden entfernt. 6 Tests in BackupServiceTests.cs.
  • 13.3.2 Wiederherstellung aus einem Backup über die Einstellungen — neuer Tab "Sicherheit" in SettingsView.axaml listet vorhandene Backups mit Zeitstempel/Größe, "Wiederherstellen" fragt über einen neuen generischen ConfirmDialog nach, kopiert das Backup über die aktive Datenbankdatei und startet die App danach automatisch neu (AppBootstrapper.RestartApplication()) — ein laufender LiteDB-Verbindung kann nicht sicher "heiß" auf eine andere Datei umgehängt werden.
  • 13.3.3 Schema-Migration mit Versionsnummer — LiteDbContext schreibt die Schema-Version in eine meta-Collection und führt Migrationsschritte nur noch aus, wenn die gespeicherte Version dahinter liegt (RunVersionedMigrations), statt wie bisher bei jedem Start erneut über alle Daten zu laufen. Die bestehenden (bereits idempotenten) Migrationsschritte wurden als Version-1-Schritt gebündelt, für zukünftige Schema-Änderungen ergänzt man einen weiteren if (version < N)-Block. 2 Tests in LiteDbContextTests.cs.
  • 13.3.4 Optionale Verschlüsselung der lokalen Datenbank — DatabaseEncryptionService.cs. Passwort setzen/ändern/entfernen läuft über eine Kopie (neue Datei mit Zielpasswort anlegen, alle Collections umkopieren, Datei austauschen) statt über LiteDatabase.Rebuild(...) mit Passwort — das ist in LiteDB 5.0.21 nachweislich fehlerhaft (per Skript verifiziert: wirft "this data file is encrypted" beim Rebuild einer unverschlüsselten Datei). Ist die Datenbank verschlüsselt, fragt ein eigenes Fenster (DbPasswordPromptWindow) das Passwort ab, bevor AppBootstrapper.BuildServices() (und damit das Öffnen der Datenbank) läuft — siehe App.axaml.cs. Ändern/Entfernen des Passworts läuft über Einstellungen → Sicherheit, jeweils mit Neustart der App danach. 4 Tests in DatabaseEncryptionServiceTests.cs.
  • 13.3.5 App-Sperre nach Inaktivität — AppLockService.cs (eigenes, gesalzenes PBKDF2-Passwort, unabhängig von einer eventuellen Datenbank-Verschlüsselung) + AppLockViewModel.cs (Inaktivitäts-Timer, Sperrbildschirm-Logik). Maus-/Tastatureingaben im Hauptfenster setzen den Timer zurück (MainWindow.axaml.cs); läuft er ab, blendet ein Overlay in MainWindow.axaml die gesamte Oberfläche aus, bis das Passwort stimmt. Einstellbar (aktiv/inaktiv, Zeit, Passwort) über Einstellungen → Sicherheit, wirkt sofort ohne Neustart. 2 Tests in AppLockViewModelTests.cs (reine Unlock-Logik; der zeitbasierte Inaktivitäts-Timer selbst ist nicht automatisiert getestet). Hinweis: RestartApplication() startet den Prozess über Environment.ProcessPath neu — im veröffentlichten Programm korrekt, im Entwicklungsbetrieb über dotnet run zeigt ProcessPath auf den dotnet-Host statt auf die App, ein Neustart über die Einstellungen ist dort also nur in einer veröffentlichten Build (dotnet publish) sinnvoll zu testen.
  • 13.3.6 Sauberer Desktop-Lifecycle — beim Beenden wird ein LiteDB-Checkpoint ausgeführt und anschließend der DI-Container samt Singleton-Datenbankverbindung entsorgt. Das initiale Hauptfenster wird vom Avalonia-Desktop-Lifetime angezeigt; ein explizites Show() erfolgt nur beim späteren Wechsel vom Passwortfenster zur Hauptansicht.

13.4 Codepflege

  • 13.4.1 CLAUDE.md mit Projektkonventionen anlegen (/init) — CLAUDE.md.
  • 13.4.2 AllRepositories.cs und IRepositories.cs in Themendateien aufteilen, sobald weitere Repositories dazukommen. Aktuell (319 bzw. 154 Zeilen für ~20 Repositories) noch nicht unübersichtlich genug, um die Bedingung auszulösen — bewusst zurückgestellt.
  • 13.4.3 Wiederkehrende UI-Muster als wiederverwendbare Controls/Styles. Bestandsaufnahme vor der Umsetzung ergab drei echte Duplikate (Suchleiste dagegen nur 3× und jedes Mal eine simple TextBox ohne gemeinsames Chrome — Extraktion lohnt sich dort nicht): - Seiten-Kopfzeile (Titel 22px SemiBold + optionaler Untertitel) war identisch in GroupListView, StudentListView, GroupDetailView, StudentDetailView, SettingsView nachgebaut → neue PageHeader-Control, dort eingesetzt. - Dialog-Titel (FontSize="18" FontWeight="SemiBold" als erstes Element) kam in 16 Dialogen jeweils inline vor → globale Style-Klasse TextBlock.dialogtitle (App.axaml). - Leerlisten-Hinweis ("Noch keine …") kam an 10 Stellen vor, dabei war Opacity/FontSize bereits leicht auseinandergedriftet (0.35 vs. 0.4, 12 vs. 13) → globale Style-Klasse TextBlock.emptyhint, normalisiert alle Stellen auf einen Wert. Absichtlich nicht angefasst: die vier Views mit eigenen lokalen <Style Selector=>-Blöcken (MainWindow, DashboardView, StudentDetailView, ExamEvaluationDialog) sind jeweils einzigartige Spezial-Visualisierungen (Kalenderzellen, Sparkline, Balkendiagramm, Toast/Drawer) ohne Duplikate untereinander.
  • 13.4.4 Konverter und Styles zentralisieren. Bei der Bestandsaufnahme für 13.4.3 zeigte sich: es gibt keine einzige eigene IValueConverter-Implementierung im Projekt — überall werden bereits konsistent Avalonias eingebaute statische Konverter (StringConverters, BoolConverters, ObjectConverters) verwendet. Nichts zu zentralisieren; die Style-Duplikate wurden im Zuge von 13.4.3 behoben (siehe oben).

14. UX-Querschnitt

  • 14.1 Tastaturbedienung durchgängig: alle Hauptfunktionen ohne Maus erreichbar (Vorbild: Mitarbeit-Schnelleingabe).
  • 14.2 Globale Suche (Schüler, Gruppe, Klausur) über Tastenkürzel.
  • 14.3 Rückgängig-Funktion für Löschvorgänge (mindestens Bestätigungsdialog überall).
  • 14.4 Ladeanzeigen bei längeren Operationen (Import, Sync, Export).
  • 14.5 Leere Zustände mit Handlungsaufforderung statt leerer Tabellen.
  • 14.6 Fenstergröße und Spaltenbreiten über Sitzungen hinweg merken.
  • 14.7 Bedienung auf Touch-Geräten prüfen (Tablet im Unterricht).
  • 14.8 Responsive Layout und Windows-DPI prüfen (kleine Notebook-Auflösungen sowie 125/150/200 % Skalierung; starre Master-Detail-Spalten bei Bedarf stapeln). Der kompakte Drawer berücksichtigt bereits die schmalere verfügbare Breite mit reduziertem Außen-/ Innenabstand und einer eigenen Iconfläche, damit Windows-Emoji nicht abgeschnitten werden.
  • 14.9 Barrierefreiheit prüfen: Automation-Namen für Icon-Buttons, sichtbare Fokusrahmen, Kontraste und Status nicht ausschließlich über Farbe/Emoji vermitteln.
  • 14.10 Plattformübergreifend konsistentes SVG-/PathIcon-Set statt systemabhängiger Emoji-Darstellung einführen.
  • 14.11 Aktiven Navigationspunkt in der Seitenleiste sichtbar hervorheben; Zustand wird über MainWindowViewModel.ActiveNavItem gesteuert.

15. Auslieferung

  • 15.1 Release-Build und Signierung für macOS.
  • 15.2 Windows-Build prüfen (Zielplattform klären).
  • 15.3 Versionierung und Changelog-Pflege.
  • 15.4 Update-Mechanismus oder zumindest Versionsprüfung beim Start.
  • 15.5 Kurze Bedienanleitung für den Eigengebrauch.

16. Datenmodell- und Architekturqualität

  • 16.1 Referenzielle Integrität für alle Modellbeziehungen dokumentieren und je Beziehung explizit Cascade, Restrict, SetNull oder Archivierung festlegen; Löschpfade mit Transaktions- und Vollständigkeitstests absichern.
  • 16.2 Domain-Validierung aus den Dialog-ViewModels in gemeinsam nutzbare Regeln/Services überführen, damit Import, Sync und API dieselben Regeln durchsetzen.
  • 16.3 Prüfen, ob Punkte, Gewichtungen und Prozentgrenzen von double auf decimal oder skalierte Ganzzahlen migriert werden sollen; Rundungs- und Migrationsstrategie festlegen.
  • 16.4 Redundant gespeicherte Bewertungswerte (ExamResult.TotalPoints, berechnete Note) entweder ableiten oder zusammen mit einer unveränderlichen Version des verwendeten Notenschlüssels als historischen Snapshot speichern.
  • 16.5 Kompetenzzuordnungen auf stabile CompetencyItem.Id umstellen; Code/Beschreibung bei Bedarf zusätzlich als historischen Snapshot speichern, damit Umbenennungen keine alten Klausur- oder Sitzungsreferenzen brechen.
  • 16.6 Navigation und manuelle Callback-Verdrahtung in App.axaml.cs langfristig durch einen testbaren Navigationsdienst oder Messenger ersetzen; statischen Servicezugriff abbauen.

Empfohlene Reihenfolge

Die Abschnitte sind thematisch, nicht chronologisch nummeriert. Sinnvolle Bearbeitungsreihenfolge:

  1. Kapitel 1 (Klausuren) — erledigt.
  2. Kapitel 3.2 (Mitarbeit-Aggregation) — erledigt.
  3. Kapitel 2 (Noten & Zeugnisnoten) — erledigt.
  4. Kapitel 13 (Technische Basis: Tests, Fehlerbehandlung, Datensicherheit, Codepflege) — erledigt (13.113.4 vollständig; 13.4.2 bewusst zurückgestellt, siehe dort).
  5. Kapitel 5 (Schülerdokumentation) — erledigt (5.2 als Auswertung des bestehenden Anwesenheits-Trackings statt zweiter Erfassung, siehe dort). Kapitel 4 (Planung) war als parallelisierbar dazu vorgesehen und ist weiterhin offen. → nächster sinnvoller Schritt.
  6. Kapitel 6 (Arbeitszeit), 11 (Export), 10 (Sync) — danach.