4 Commits

Include renames

Author	SHA1	Message	Date
adminandClaude Sonnet 5	bfe214ecf2	feat: Untis-Hub-Kadenzkopplung, anpassbarer Statusvorschlag + KI-/MCP-Unterstuetzung beim Fehlzeitenabgleich (Nutzer-Feedback) ... - UntisHubService.RecordRun: ein abgeschlossener Langzeit-Fehlzeitenabgleich schliesst die kurzfristige Kadenz derselben Gruppe automatisch mit ab (nicht umgekehrt). - Fehlzeitenabgleich-Dialog: neue "Uebernahme als"-ComboBox statt starrem Zielstatus, vorbelegt mit dem berechneten Vorschlag, aber frei aenderbar. - Neuer ai-backend-Endpunkt untis-status.php + AiPlanningService.RequestUntisStatusSuggestionsAsync: gebuendelter, anonymisierter KI-Statusvorschlag (nur Positions-Id + Rohsignale, nie Name/Klasse/ Datum), mit hartem Id-Mengen-Abgleich gegen Verwechslung. - Neue MCP-Tools (UntisComparisonTools): get_untis_hub_status, get_untis_absence_rows/ apply_untis_absence_status (anonymer Weg ueber ENr-Zuordnung) sowie get_named_untis_absence_pattern als bewusste, eng begrenzte Ausnahme (Name+Fehlzeiten fuer explizit angegebene Schueler-IDs, mit Bestaetigung ohne Sitzungsfreigabe - dafuer IMcpConfirmationService.ConfirmAsync um allowSessionTrust erweitert). - MapStatus/ENr-Zuordnung aus dem ViewModel in das neue, geteilte UntisLessonAbsenceHelper gezogen, damit Dialog und MCP-Tool nie unterschiedliche Statusvorschlaege berechnen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 22:55:33 +02:00
adminandClaude Sonnet 5	19aa302487	feat: Sitzungsfreigabe für MCP-Bestätigungen + LessonStatus.Cancelled ... Sitzungsfreigabe: McpConfirmDialog bietet zwei Checkboxen ("diese Art von Aktion" / "alle KI-Aktionen für den Rest der Sitzung nicht mehr nachfragen"), nur beim Bestätigen wirksam. IMcpConfirmationService. ConfirmAsync bekommt einen per [CallerMemberName] automatisch befüllten operationKey - kein bestehender Aufruf musste geändert werden. Freigaben leben als In-Memory-Bookkeeping auf der Confirmation-Service-Instanz, gelten bis App-Ende, werden aber trotzdem geloggt, damit stillschweigende Bestätigungen nicht spurlos bleiben. Grund: 17 identische Bestätigungen in Folge für eine neu generierte Unterrichtseinheit sind unzumutbar. LessonStatus.Cancelled ("Ausgefallen") als Alternative zu delete_lesson für Stunden, die nur ausgefallen sind (Exkursion, Feiertag), aber als Ereignis dokumentiert bleiben sollen. Als Cancelled=4 angehängt (bestehende LiteDB-Werte 0/1 sind fix). Konsistent wie "bereits durchgeführt" behandelt an allen Stellen, die bisher nur auf Conducted prüften: Terminverschiebung, Fortschrittsanzeige, Hausaufgabe-kontrollieren-Erinnerung, "nächste Stunde"-Vorschlag. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 02:25:45 +02:00
adminandClaude Sonnet 5	a4733c156b	feat: prominenterer Bestätigungsdialog + move_lesson/delete_lesson (Nutzer-Feedback) ... Nach dem ersten Live-Test mit echtem Bridge-Prozess: der bisherige ConfirmDialog fiel zu wenig auf, wenn LehrerApp im Hintergrund lief (Normalfall, da der Anstoß vom KI-Client in einem anderen Fenster kommt). Neuer, eigenständiger McpConfirmDialog statt Änderung am geteilten ConfirmDialog (hätte alle anderen Aufrufer mitbetroffen): breiter, auffälliger Kopfbereich, Topmost. AvaloniaMcpConfirmationService holt das Hauptfenster zusätzlich aus einer möglichen Minimierung und aktiviert es vor dem Anzeigen. move_lesson kapselt die bereits vorhandene LessonSchedulingService.Move (shiftFollowingLessons öffnet eine Lücke für eine neue Stunde, indem spätere Stunden derselben Einheit mitverschoben werden) - keine neue Terminlogik, nur Wiederverwendung. delete_lesson ist eine bewusste, gezielte Ausnahme von "v1 ohne Lösch-Tools" auf expliziten Nutzerwunsch: eigene AllowedDestructiveWriteTools-Liste, Destructive=true-Annotation, Bestätigungstext betont ausdrücklich die fehlende Papierkorb-Deckung für Lessons. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-12 00:43:59 +02:00
adminandClaude Sonnet 5	9567d8d616	feat: lokaler MCP-Server, Phase 2 (Write-Tools + Bestätigungsdialog + Lesson-Plans) ... Neue Write-Tools create_time_entry, create_grade_entry und update_student_group_assignment schreiben nie direkt: jeder Aufruf zeigt zuerst einen menschenlesbaren Bestätigungsdialog (bestehender ConfirmDialog, über Dispatcher.UIThread aus dem Pipe-Session-Thread angezeigt) und schreibt erst nach Bestätigung, mit 2-Minuten-Timeout gegen eine hängende Session. Zusätzliches Read-Tool get_lesson_plans. create_note bewusst nicht umgesetzt (kollidiert mit dem bestehenden Dokumentations-Ausschluss aus Phase 1), create_lesson_plan/ update_lesson_plan wegen der Modellkomplexität von Lesson zurückgestellt (siehe TODO.md 4.5.26). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-11 20:14:51 +02:00