## 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