gott/PLAN-Cronjob.md

Cronjobs – Planungsentwurf

Konzept: Eigener Worker/Service in der App

Warum nicht Linux-Cron?

• App ist self-contained, soll ohne externe Abhängigkeiten laufen
• Cronjobs brauchen Zugriff auf DB, Agents, Sessions, Anthropic API
• Verwaltung über das Frontend (Dashboard) wäre mit Linux-Cron extrem umständlich
• Multi-User: Jeder User hat eigene Cronjobs

Architektur

Backend:

1. CronjobRecord (Model) – DB-Tabelle cronjobs:

   • cronjob_id (TEXT, GUID)
   • user_id (TEXT)
   • session_id (TEXT) – in welcher Session soll der Prompt gesendet werden
   • name (TEXT) – z.B. "Täglicher Standup-Report"
   • cron_expression (TEXT) – Standard Cron-Format: 0 9 * * * (jeden Tag um 9:00)
   • prompt (TEXT) – die Nachricht die an Claude gesendet wird
   • is_enabled (BOOL) – aktiv/inaktiv
   • last_run_at (TEXT) – wann zuletzt ausgeführt
   • next_run_at (TEXT) – nächste geplante Ausführung (vorberechnet)
   • last_run_status (TEXT) – "success" / "error"
   • last_run_error (TEXT) – Fehlermeldung falls error
   • created_at, updated_at

2. CronjobService (IHostedService / BackgroundService):

   • Startet mit der App als AddHostedService<CronjobService>()
   • Timer prüft jede Minute: "Gibt es Cronjobs deren next_run_at <= jetzt?"
   • Wenn ja: Prompt an die Session senden (wie ein normaler Chat-Request, aber ohne SSE – fire & forget, Result in DB speichern)
   • Nach Ausführung: last_run_at updaten, next_run_at neu berechnen

3. CronjobEndpoint (REST API):

   • GET /api/cronjobs – alle Cronjobs des Users
   • POST /api/cronjobs – neuen Cronjob anlegen
   • PUT /api/cronjobs/{id} – bearbeiten
   • DELETE /api/cronjobs/{id} – löschen
   • POST /api/cronjobs/{id}/toggle – aktivieren/deaktivieren
   • POST /api/cronjobs/{id}/run – manuell sofort ausführen (zum Testen)

4. Cron-Expression Parser: Nutzen wir Cronos NuGet-Package (leichtgewichtig, kein Overhead) oder schreiben wir einen eigenen einfachen Parser?

Frontend:

5. Dashboard: Neue Section "Cronjobs" mit Cards (ähnlich Sessions/Agents)
6. Cronjob-Formular (neue Page tpl-cronjob):
   • Name
   • Session (Dropdown)
   • Cron-Expression (Input + Vorschau "Nächste Ausführung: ...")
   • Prompt (Textarea)
   • Aktiv/Inaktiv Toggle
7. Cronjob-Card: Name, Session-Name, Cron-Expression human-readable, Status (aktiv/inaktiv), letzte Ausführung

Offene Fragen an dich:

1. Cron-Expression oder vereinfacht? Soll der User echte Cron-Expressions eingeben (0 9 * * 1-5) oder lieber ein vereinfachtes UI (Dropdown: "Täglich um X", "Wöchentlich am Y um Z", etc.)?

2. Ausführung: Soll der Cronjob die Antwort von Claude still in die Session-History schreiben (so als hätte der User die Nachricht geschrieben)? Oder soll es einen separaten "Cronjob-Log" geben?

3. NuGet Cronos für Cron-Parsing verwenden? (Ist der De-facto-Standard in .NET, ~50KB, keine Abhängigkeiten)

4. Benachrichtigung: Soll der User benachrichtigt werden wenn ein Cronjob ausgeführt wurde? (z.B. über die StatusBar, oder Telegram?)

--

Antworten auf die offenen Fragen:

1. Cron-Expression
2. Einfach direkt in die Session-History schreiben (als hätte der User die Nachricht geschrieben)
3. Cronos NuGet passt
4. Telegram, falls in der Session, in der der Cronjob läuft, Telegram eingerichtet und verbunden ist