109 lines
4.1 KiB
Markdown
109 lines
4.1 KiB
Markdown
|
# 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
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
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`: Tabelle `schedules`; `schedule_id` auf `recurring_elements`, `actions`; `action_id` auf `recurring_elements`
|
|||
|
|
- Bestehende `interval_days` auf Recurring → Backfill `schedules` (kind=interval)
|
|||
|
|
- `interval_days` am Recurring **deprecated** (Lesefallback bis Entfernung)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 7. Implementierungsfolge
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
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.*
|