ahmido
beffbfca4c
Ziel: MVP-Spezifikation für “Automatisierte Backups per Zeitplan (pro Tenant)” als Grundlage für die Implementierung (Spec-first). Scope (MVP): Tenant-scoped backup_schedules + backup_schedule_runs Dispatcher erstellt idempotente Runs (Unique Slot) + Queue-Job führt Run aus “Run now” / “Retry”, Run-History, Retention (keep last N) No catch-up für verpasste Slots Wichtige Klarstellungen (aus Constitution abgeleitet): Jede Operation ist tenant-scoped und schreibt Audit Logs (Dispatcher/Run/Retention; keine Secrets/Tokens) Graph-Aufrufe laufen über die bestehende Abstraktion (keine Hardcodings) Retry/Backoff: Throttling → Backoff; 401/403 → kein Retry Authorization (MVP): TenantRole-Matrix (readonly/operator/manager/owner) statt neuer Permission-Registry Nicht im MVP: Kein Restore-Scheduling Kein Cross-Tenant Bulk Scheduling / Templates Kein Catch-up von missed runs Review-Fokus: Semantik “1 Run = 1 BackupSet” Concurrency/Lock-Verhalten (bei laufendem Run → skipped) DST/Timezone-Regeln + Slot-Minutenpräzision Artefakte: spec.md plan.md tasks.md requirements.md Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #33
771 B
771 B
Requirements Checklist (032)
- Tenant-scoped tables use
tenant_idconsistently. - 1 Run = 1 BackupSet (no rolling reuse in MVP).
- Dispatcher is idempotent (unique schedule_id + scheduled_for).
- Concurrency lock prevents parallel runs per schedule.
- Run stores status + summary + error_code/error_message.
- UI shows schedule list + run history + link to backup set.
- Run now + Retry are permission-gated and write DB notifications.
- Audit logs are written for dispatcher, runs, and retention (tenant-scoped; no secrets).
- Retry/backoff policy implemented (no retry for 401/403).
- Retention keeps last N and soft-deletes older backup sets.
- Tests cover due-calculation, idempotency, job success/failure, retention.