Scheduled Workflows

Stand: 2026-05-26

Ziel

Scheduled Workflows standardisieren wiederkehrende Read-only-Betriebsprüfungen der Lanstyle AI Suite. Sie erzeugen Reports, Trends und Audit-Referenzen, führen aber keine Infrastrukturänderungen aus.

Nicht im Scope:

• automatische Restores
• automatische Remediation
• Creates oder Deletes
• Proxmox-/NetBox-/DNS-/NPM-/Firewall-/AD-/Exchange-/Intune-Writes

Framework

Das Framework besteht aus:

• scheduled_workflows
• workflow_schedules
• execution_history
• execution_retention
• schedule_policy
• maintenance_window_awareness
• optionalem Jitter
• last_run
• next_run

Operationaler Speicher:

/var/lib/lanstyle-agent/controlled-execution/scheduled-workflows/

Dateien:

Datei	Zweck
execution-history.jsonl	append-only Laufhistorie
trends.json	aggregierte Trend-Sicht

Aktivierte Workflows

Workflow	Kategorie	Schedule	Writes
runtime_backup_validation_v1	Backup-/Restore-Readiness	täglich	nein
healthcheck_validation_v1	Service Health	stündlich	nein
drift_visibility_v1	State/Drift	täglich	nein
lock_consistency_validation_v1	Dependency Locks	stündlich	nein

Scheduling Governance

Jeder Workflow unterstützt:

• enabled
• manual_pause
• emergency_pause
• maintenance_window_block
• execution_timeout
• retry_policy
• stale_detection
• approval_required=false

Read-only Workflows benötigen keine Approval-ID und kein Dependency Lock. Bei Fehlern wird nur ein Report erzeugt.

Execution Artifacts

Jeder Lauf erzeugt:

• execution_summary
• risk_summary
• drift_summary
• component_matrix
• artifact_reference
• timeline
• audit_reference

Artefakte werden als Changeplan-Artefakte geschrieben und enthalten keine Secrets.

Failure Handling

Fehlerzustände:

• degraded
• warning
• failed

Bei Fehlern:

• keine automatische Reparatur
• keine Remediation
• keine Restore-Aktion
• Operator-Empfehlung über recommended_operator_action
• optional escalation_recommended in späteren Versionen

Trends

Gespeichert werden:

• Backup-Readiness-Verlauf
• Healthcheck-Verlauf
• Drift-Häufigkeit
• Lock-Anomalien
• Restore-Readiness-Verlauf

OpenCode soll daraus anzeigen:

• letzter erfolgreicher Lauf
• nächster Lauf
• verschlechterte Trends
• neue Risiken
• neue gelbe/rote Komponenten
• stale scheduled workflow

API

Endpoint	Zweck	Writes
GET /scheduled-workflows	Katalog und Schedule-Status	nein
GET /scheduled-workflows/history	Laufhistorie	nein
GET /scheduled-workflows/<workflow_id>	Workflow-Details	nein
POST /scheduled-workflows/run-now-readonly	manueller Read-only-Lauf	nur Artefakte/History
GET /scheduled-workflows/trends	Trendübersicht	nein

Beispiel:

{
  "workflow_id": "runtime_backup_validation_v1"
}

Ohne workflow_id führt run-now-readonly alle aktivierten Read-only Workflows aus.

Die History wird absteigend nach finished_at bzw. started_at sortiert. Die API liefert zusätzlich:

• latest_run
• latest_status
• last_failure
• historical_failures
• trend

Alte Fehler werden damit nicht versteckt, erscheinen aber getrennt von der neuesten Bewertung.

Produktiver Trigger

Der produktive Trigger läuft im Agent-Runtime-LXC über systemd:

Einheit	Zweck
lanstyle-scheduled-workflows-readonly.service	führt alle vier Read-only Workflows einmalig aus
lanstyle-scheduled-workflows-readonly.timer	startet den Service stündlich mit RandomizedDelaySec=10m

Der Service ruft nur /opt/agent-runtime/scripts/run-scheduled-workflows-readonly.sh auf. Das Skript führt im Tools-API-Container run_now_readonly({}) aus und erzeugt ausschließlich History-, Trend- und Artefaktdateien. Es gibt keine Auto-Remediation, keinen Restore und keine Infrastrukturänderung.

Prüfung:

systemctl list-timers lanstyle-scheduled-workflows-readonly.timer
systemctl status lanstyle-scheduled-workflows-readonly.service
journalctl -u lanstyle-scheduled-workflows-readonly.service -n 100 --no-pager

Rollback:

systemctl disable --now lanstyle-scheduled-workflows-readonly.timer

Sicherheitsgrenzen

• live_write_performed=false
• keine Approval nötig
• keine Locks nötig
• keine Backup-Inhalte lesen
• keine Secrets ausgeben
• keine automatische Reparatur
• keine Restore-Ausführung

Nächste Ausbaustufe

Optional kann der systemd-Trigger später zusätzlich durch n8n visualisiert werden. n8n darf dabei nur Status/History lesen oder run-now-readonly auslösen und keine Remediation triggern.