Kairo-Jinkendo/docs/architecture/methods/SPEC_D_recurring_control_v0.1.md

# SPEC-D — `recurring_control`
## Steuerungsmethode — Spec-Tiefe D v0.1

**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
**Stand:** 2026-07-26  
**Default für:** A3 `initiative.recurring_program`  
**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
**Quellen:** Decision-Lock A3, Archetyp-Vollspec A3, Kernel Freeze  
**OM-Struktur:** verbindlich in `SPEC_A3_recurring_program_v0.1.md`

---

## D1 Identität

| Feld | Wert |
|------|------|
| `method_key` | `recurring_control` |
| Rolle | primary |
| Label (DE) | Rhythmus-Steuerung |
| Zweck | Systemgesundheit über wiederkehrende Rituale steuern: Next = fällige/überfällige CadenceInstance; eine offene Instanz pro Rhythmus; Abweichung/Score sichtbar — kein Todo-Duplikat bei Verpassen. |

---

## D2 Geltung

| Feld | Wert |
|------|------|
| Default | A3 `initiative.recurring_program` |
| kompatibel als Primary | nur A3 / `project.recurring_program` |
| Komposition | `agile_iteration` (Sprint-Slice für Actions; Cadence bleibt Leading der Primary) |
| nicht | Care; A1; B1 als Primary-Ersatz |
| Dominanz | `event` — Cadence führt; bei Agile zusätzlich plan-Slice auf Actions |

---

## D3 Horizon

| Horizont | Bedeutung |
|----------|-----------|
| **Zeitfenster „heute / fällig / überfällig“** | über alle aktiven Rituale (optional gefiltert nach Domain-Project) |
| Domain-Filter | aktiver Domain-Ausschnitt (Project) — optional, nicht Pflicht für Next |
| Gates | nicht steuerungsführend (`n/a` / light) |

---

## D4 Leading Work Item

**`CadenceInstance`** am `RecurringElement`.

- Pro Ritual genau **eine** offene Instanz.  
- Verpassen → Instanz bleibt / eskaliert (Attention, Score) — **kein** zweites offenes Duplikat.  
- `Action` nur für Ausnahme/Eskalation (Reparatur, Sonderarbeit), nicht Leading für Normalzyklus.

---

## D5 Lifecycle-Pfad

| Schritt | Status | Bedeutung |
|---------|--------|-----------|
| intake | active | System/Domains/Rhythmen erfassen |
| method_bind | active | Default `recurring_control` |
| structure_setup | active | Domain-Projects, RecurringElements, Owner-Actors, Cadences |
| planning | n/a | keine Gate-/Lieferplanung als Kern |
| next_work / action_selection | active | fällige/überfällige Instanzen (D6) |
| assignment | active | Owner; optionale freiwillige Übernahme |
| waiting | active | auf Cadence-Zeitpunkt |
| result / event | active | erledigt → genau eine nächste Instanz planen |
| dod / validation | light | optional Qualitätscheck am Ritual — nicht Gate-DoD |
| review | light | periodischer System-Health-Blick |
| adaptation | active | Cadence/Owner/Score-Parameter anpassen |
| closure | skip | Dauerprogramm — Closure nicht erwartet |

---

## D6 Next Action — konkrete Regeln

### Ready

CadenceInstance ist ready, wenn:

1. Ritual aktiv, und  
2. Instanz offen, und  
3. Fälligkeit ≤ jetzt (fällig/heute) **oder** überfällig, und  
4. nicht durch Blocker gesperrt (sonst Attention)

### Ranking

1. überfällig (älter zuerst / höherer Abweichungs-Score zuerst)  
2. heute fällig  
3. als Nächstes geplant (nur Anzeige/Hinweis, nicht als Fake-Druck-Next)

**reason_codes:** `recurring_overdue`, `recurring_due`, `recurring_next_scheduled`

**Leerer Fall:** nichts fällig → „System im Takt“ / nächste Fälligkeit — Erfolg, nicht Planning Debt.

**Anti:** alle historischen Verfehlungen als Task-Wand; Gates als Leading Horizon.

### Komposition `agile_iteration`

Bei aktivem Sprint (siehe Spec-D Agile):

1. CadenceInstance overdue/due bleibt Ready und rankt **vor** Sprint-Actions.  
2. Sprint filtert **Actions** (Verbesserung/Sonderarbeit), nicht Ritual-Instanzen.  
3. reason_codes Primary unverändert; zusätzlich Agile-Codes für Sprint-Actions.  
4. Ohne aktiven Sprint: nur diese Primary.

---

## D7 Attention

| Code | Wann |
|------|------|
| `recurring_overdue` | Instanz überfällig |
| `recurring_deviation` | Abweichungs-Score über Schwellwert (verpasste Zyklen, Verspätung) |
| `recurring_unowned` | Ritual ohne Owner-Actor |
| `recurring_stale_definition` | Ritual lange ohne erfolgreichen Zyklus trotz aktiv |

---

## D8 Events

| Event | Wirkung |
|-------|---------|
| Cadence-Zeitpunkt | Event-Schub → Ready |
| Instanz erledigt | schließen; genau eine nächste Instanz; Score aktualisieren |
| Verpasst / überfällig | Score/Attention; **keine** zweite Instanz |
| Owner-Wechsel / Übernahme | Assignment; Audit |
| Cadence geändert | Adaptation; nächste Fälligkeit neu |

---

## D9 Nested

`n/a` primary. Kann Kind unter B2a sein — Parent-Impulse ≠ Child-Next.

---

## D10 OM-Voraussetzungen

| Minimal | Vollmodell |
|---------|------------|
| Initiative A3 + Methode | Domain-Projects |
| ≥1 RecurringElement mit Cadence + Owner | Multi-Actor / Übernahme |
| eine offene Instanz-Semantik | Abweichungs-Score je Ritual/Domain |
| | optionale Eskalations-Action |

---

## D11 Extension Points

| Art | Ziel |
|-----|------|
| next_work_strategy | `recurring_control` |
| attention_rules | Codes D7 |
| horizon_resolver | Zeitfenster + optional Domain |
| dod_policy | light / n/a |
| adaptation_hooks | Cadence, Score, Owner |
| steering_elements | `next_action_primary`, `recurring_rhythm` (+ `work_cycle_scope` bei Agile) |
| compatible_archetype_keys | `initiative.recurring_program` |
| composes_with | `agile_iteration` |
| data_slices | recurring, projects, actions, blockers, steering_methods (+ work_cycles bei Agile) |

---

## D12 Spannungen · PO

| Punkt | Lage |
|-------|------|
| Event-Dominanz | Kernel Dual-Auslöser — Plan-Zug dünn ok |
| Score | Teil des vollständigen Steuerungsmodells; Implementierungs-Schnitt in APs |
| ≠ Care / ≠ A1 | Gegenstand = Systemrhythmus, nicht Wohlergehen oder Können-Stufen |