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>
15 lines
819 B
C#
15 lines
819 B
C#
namespace LehrerApp.Desktop.Views.Mcp;
|
|
|
|
/// <summary>DataContext für <see cref="McpConfirmDialog"/> — bewusst ein eigener, auffälligerer
|
|
/// Dialog statt Wiederverwendung von <see cref="Views.Shared.ConfirmDialog"/>: Letzterer wird an
|
|
/// vielen Stellen der App für routinemäßige Bestätigungen verwendet, eine Änderung an dessen
|
|
/// Größe/Optik hätte all diese Stellen mitbetroffen. Ein von der KI vorgeschlagener Schreibzugriff
|
|
/// soll sich dagegen bewusst absetzen (Nutzer-Feedback: der ursprüngliche gemeinsame Dialog fiel zu
|
|
/// wenig auf, wenn LehrerApp gerade nicht im Vordergrund war).</summary>
|
|
public class McpConfirmDialogInfo
|
|
{
|
|
public string Title { get; init; } = "";
|
|
public string Message { get; init; } = "";
|
|
public string ConfirmText { get; init; } = "Übernehmen";
|
|
}
|