Bestehende Recurring-Pfade bleiben kompatibel (interval_days-Fallback, Migration backfillt schedules), damit der aktuelle Betrieb nicht bricht und der Stand auf einem zweiten Rechner weitergebaut werden kann. Co-authored-by: Cursor <cursoragent@cursor.com>
4.1 KiB
ADP — Unified Schedule & Cadence Layer v0.1
Status: PO-Freigabe ausstehend (2026-08-04, Implementierung Slice 1 gestartet)
Stand: 2026-08-04
Auslöser: A1-Validation — RecurringElement als UI-Insel; Nutzer erwarten Rhythmus an AP/Task wie in Todo-Tools
Bezug: Kairo_Steering_Method_Kernel_v0.1 Q2, ADP_A1_Progression_Graph_Derived_Lanes_v0.1.md, Spec-D recurring_control, Spec-D maturity_progression
1. Leitentscheidung
Rhythmus/Wiederholung ist Kernfähigkeit, nicht Archetyp-Insel.
| Kern | Host (Bindung) | Methode (Regeln) |
|---|---|---|
Schedule — interval, Wochentage, Pause |
Action, RecurringElement (Gate-Übung), später Task |
maturity_progression, sequential_dependency, recurring_control, … |
CadenceInstance — eine offene Fälligkeit, „heute erledigt“ |
immer an RecurringElement (Bridge von Action optional) |
Ready/Ranking in Method-Strategie |
Nicht: separates Planungs-UI pro Archetyp. Eine Schedule-Semantik, ein Editor-Widget, Host-spezifische Bindung.
2. Schedule-Modell
schedules
schedule_kind 'interval' | 'weekdays'
interval_days int (nur interval; Default 1 = täglich nach Erledigen)
weekday_mask int (Mo=1, Di=2, Mi=4, Do=8, Fr=16, Sa=32, So=64)
pause_until date nullable — bis einschl. pausiert
| schedule_kind | Nutzer-Label | Semantik |
|---|---|---|
interval |
„Alle N Tage“ | Nach Erledigen: nächste Fälligkeit = heute + N Kalendertage |
weekdays |
„Bestimmte Wochentage“ | Fällig an gewählten Tagen; nach Erledigen: nächster passender Tag |
Anti-Duplikat (unverändert): pro Recurring genau eine offene CadenceInstance.
3. Hosts
| Host | Spalte | Use Case |
|---|---|---|
recurring_elements |
schedule_id, roadmap_item_id |
A1 Gate-Übung, A3 Ritual |
recurring_elements |
action_id (Bridge) |
AP mit Wiederholung — ein Recurring spiegelt AP |
actions |
schedule_id |
Steuerung / PMO-Review am AP |
Action + Schedule: beim Setzen wird RecurringElement mit action_id synchronisiert (Cadence-Pfad). AP-Status done schließt nicht die Serie — Cadence steuert Serie.
Gate-Übung: direkt RecurringElement + schedule_id + roadmap_item_id.
4. UI (Slice 1–2)
| Fläche | Widget |
|---|---|
| Gate-Detail | ScheduleEditor im Activity Set |
| AP-Detail | ActionScheduleSection — Toggle Wiederholung + gleicher Editor |
| Initiative (Slice 3) | „Rhythmen“ — Liste aller Schedules |
Labels (Pflicht): „Täglich“, „Alle 2 Tage“, „Wöchentlich“, Mo–So Checkboxen — kein nacktes „Rhythmus (Tage)“.
5. Methoden — unverändert getrennt
| Methode | Leading | Schedule-Host typisch |
|---|---|---|
maturity_progression |
Cadence an aktiven Gates | Recurring + Gate |
recurring_control |
Cadence initiative-weit | Recurring |
sequential_dependency |
Action; optional Schedule am AP | Action + Bridge |
agile_iteration |
Cadence vor Sprint-Actions | komponiert |
Archetyp ändert Auswertung, nicht das Schedule-Schema.
6. Migration & Kompatibilität
- Migration
033: Tabelleschedules;schedule_idaufrecurring_elements,actions;action_idaufrecurring_elements - Bestehende
interval_daysauf Recurring → Backfillschedules(kind=interval) interval_daysam Recurring deprecated (Lesefallback bis Entfernung)
7. Implementierungsfolge
Slice 1 Schedule + Cadence-Logik (weekdays, pause) + Gate-UI ← dieser Commit
Slice 2 Action-Schedule + Bridge-Recurring
Slice 3 Initiative „Rhythmen“ / Wochenblick (read-only)
Slice 4 Task-Host optional
8. Nicht in Scope
- Cron/Uhrzeit (nur Datum)
- Alternanz A/B (Spec §4.3 — eigener Slice)
- RecurringElement-Tabelle entfernen ( erst nach Action-Host stabil)
Bei Konflikt mit PO-Lock „Rhythmus am Recurring“: Schedule ersetzt nicht Cadence, vereinheitlicht nur Konfiguration.