# SPEC-D — `program_delivery`
## 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  
**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
**Quellen:** Decision-Lock B2a, `SPEC_B2a_program_v0.1.md`, Fit-Analyse, Ist-Code `ProgramDeliveryStrategy` (⚠ Gap)  
**OM/UI:** Archetyp-Vollspec B2a

---

## D1 Identität

| Feld | Wert |
|------|------|
| `method_key` | `program_delivery` |
| Rolle | primary (**Meta** — Kernel §6; kein Ausführungs-Leading der Kinder) |
| Label (DE) | Programm-Lieferung / Programm-Controlling |
| Zweck | Steuert den **Schirm** über Kind-Kontexte: Lagebild, Kreuz-Abhängigkeiten, Roadblocker, Priorisierungsimpulse, Programm-Horizont/Closure. **Ersetzt nicht** die Next Action der Kinder. |

---

## D2 Geltung

| Feld | Wert |
|------|------|
| Default für | B2a `initiative.program` |
| kompatibel | `initiative.program` |
| nicht | als Default für A2-Einzelprojekt (dort `sequential_dependency`); nicht für dauerhaftes Product ohne Abschluss-Natur |

---

## D3 Horizon

| Ebene | Horizont |
|-------|----------|
| **Programm-Plan** | übergreifende Zielzustände / Phasen-Meilensteine des Programms |
| **Programm-Steuerung** | Menge der Kind-Kontexte + deren Blockade-/Fortschrittslage |
| **Nicht** | Sprint der Kinder als Programm-Horizon (Kinder behalten eigene Modifier) |

---

## D4 Leading Work Item

**Zielbild (Decision-Lock):** Leading Object auf Programmebene = **`ProgramImpulse`** (Priorisierungs-/Roadblocker-Empfehlung), **nicht** die konkrete Child-Action.

| Objekt | Ebene |
|--------|-------|
| `ProgramImpulse` | Parent — „Kind X zuerst entblocken / Priorität verschieben“ |
| Child Next Action (`Action` / …) | Kind-Methode — unverändert |

**Ist-Code (Abweichung):** Strategy liefert heute ready **Actions am Programm-Initiative** + Gate-Reviews — als wäre das Programm ein flaches A2/B2. Das unterläuft Nested-Entscheidung.

---

## D5 Lifecycle-Pfad

| Schritt | Status | Bedeutung Programm |
|---------|--------|-------------------|
| intake | active | Programmziel, Scope, Abschlussabsicht |
| method_selection | active | Default `program_delivery` |
| structure_setup | active | Programm-Meilensteine + **Kind-Kontexte** anbinden (Initiativen/Projects mit eigenem Archetyp/Methode) |
| planning | active | übergeordnete Priorisierung / Reihenfolge der Kinder-Horizonte — nicht AP-Feinplanung der Kinder |
| action_selection | **umgedeutet** | wählt **Impulse**, nicht Child-AP als „die“ Next Action des Programms |
| assignment | skip/optional | selten auf Meta-Ebene; Arbeit liegt in Kindern |
| waiting | active | auf Kind-Fortschritt / externe Programm-Lage |
| result_intake | active | Kind-Statusänderungen, Programm-Meilenstein-Evidence |
| validation | active | Programm-Gate/Meilenstein-Kriterien |
| review | active | Programm-Reviews, Go/No-Go zwischen Phasen |
| adaptation | active | Kinder umpriorisieren, Scope des Programms anpassen |
| closure | active | **erwartet** — Programm hat Ende (≠ Product) |

---

## D6 Next Action / Impulse — konkrete Regeln (Zielbild)

**Auf dem Programm-Kontext zeigt die Steuerung zwei getrennte Kanäle:**

| Kanal | Inhalt | UI/API-Semantik |
|-------|--------|-----------------|
| **A — Child Next Actions** | unverändert von Kind-Methode | Scope = Kind; Programm listet/aggregiert höchstens |
| **B — Program Impulse** | Empfehlung mit reason_code | Scope = Programm; **kein** Ersatz für A |

**Impulse-Ranking (Ziel):**

1. Kreuz-Abhängigkeit / Roadblocker, der ≥2 Kinder oder Programm-Meilenstein blockiert  
2. Kind auf kritischem Programm-Pfad ohne Fortschritt  
3. Priorisierungsempfehlung (Portfolio-/Programm-Rang zwischen Kindern)  
4. Programm-Meilenstein mit offenen Kriterien ohne zurechenbares Kind

**reason_codes (Ziel):** `program_roadblocker`, `program_cross_dependency`, `program_child_stalled`, `program_priority_shift`, `program_milestone_risk`

**Leerer Fall:** keine Impulse und Kinder ohne Attention → Programm-Lage „stabil“; trotzdem Child-NAs in Kindern sichtbar — Programm zeigt nicht „nichts zu tun“ indem es Child-APs als eigene NA ausgibt.

**Verboten (Zielbild):**

- Programm-`action_selection` gibt Child-Action als *die* Next Action des Programms aus und suggeriert, das Programm steuere die AP-Reihenfolge restriktiv wie A2

---

## D7 Attention

| Code (Ziel) | Wann |
|-------------|------|
| `program_roadblocker` | Blocker/Dep über Kinder hinweg |
| `program_milestone_at_risk` | Programm-Gate gefährdet |
| `program_child_stalled` | Kind ohne Fortschritt am kritischen Programm-Pfad |
| `program_orphan_work` | Arbeit ohne Zuordnung zu Kind/Meilenstein |
| `program_closure_ready` | alle Kinder/Meilensteine closure-fähig |

---

## D8 Events

| Event | Wirkung |
|-------|---------|
| Kind Next Action / Statusänderung | Programm-Lage + Impulse neu |
| Kreuz-Dep angelegt/gelöst | Impulse + Attention |
| Programm-Meilenstein verify | Horizont |
| Kind Archetyp/Methode gewechselt | Hybrid bleibt erlaubt; Impulse neu bewerten |
| Kind closure | Programm-Closure-Prüfung |

---

## D9 Nested — Kernanker (Härtetest)

```text
Program Context (method = program_delivery)
  ├── Impulse / Attention / Programm-Horizont / Closure
  └── Child Context 1 (eigene Methode, z. B. sequential_dependency)
  └── Child Context 2 (eigene Methode, z. B. continuous_product oder A2 Content)
        └── deren Next Action unverändert
```

**PO ✓ Decision-Lock:** konkrete Next Action auf Projektebene; Programm = übergeordnete Impulse.

**Kern-Konsequenz:** Kandidat-Anker **D Nested Steering** und **polymorphes Work Item (`ProgramImpulse`)** sind für diese Methode **nicht optional**.

---

## D10 OM-Voraussetzungen

| Minimal | Optional |
|---------|----------|
| Programm-Initiative + `program_delivery` | Programm-Backlog (Eingang) |
| ≥1 Programm-Meilenstein/Phase | work_cycle nur wenn Modifier auf Kind oder explizit am Programm gewünscht |
| ≥1 Kind-Kontext (Initiative oder Project mit eigenem Steering) | Kreuz-Deps als Graph-Kanten zwischen Kind-Horizonten / Programm-Items |
| Lagebild-Read-Model über Kinder | |

**Offen modellseitig:** Sind Kinder **eigene Initiativen** unter einem Programm-Portfolio-Link, oder **Projects** mit eigenem `method_key`-Override unter einer Programm-Initiative? Decision-Lock erlaubt hybrid inhaltlich — **Datenmodell muss in D12 entschieden werden**.

---

## D11 Extension Points

| Art | Ziel |
|-----|------|
| next_action_strategy | `program_delivery` → Impulse-Kanal; Aggregation Child-NA getrennt |
| steering_elements | `next_action_primary` (Impulse), `gate_fulfillment` (Programm), neu z. B. `program_child_lage` / `cross_dependency` |
| graph_profile | Programm-Meilensteine; Kreuz-Deps |
| ui_features | Programm-Lage vs. Child-Drilldown getrennt |
| hooks | `on_next_action_requested` (Impulse), `on_replan_required`, `on_closure_requested`, Kind-Status-Hooks |

---

## D12 Spannungen — Ist vs. Ziel · offene PO-Punkte

| Spannung | Detail |
|----------|--------|
| **Ist-Code ≠ Decision-Lock** | `ProgramDeliveryStrategy` ≈ Gate-ready Actions auf derselben Initiative — **kein** Nested/Impulse-Modell |
| **Katalog v0.2 veraltet** | „Next Action: nächstes Gate/AP am Programm-Horizont“ widerspricht Interview |
| **Kern** | Ohne Nested + ProgramImpulse bricht diese Methode den Kandidat-Kern |

**PO ✓ (2026-07-25):**

1. **Kind-Modell:** beides erlaubt; Logik adressiert Child SteeringContext; Primärbild Projects + `method_key`-Override, verlinkte Initiativen optional später.  
2. **Programm-Widget:** Impulse primär; Child-NAs als klar getrennter zweiter Block.  
3. **Programm-Büro-Actions:** erlaubt, sekundär — dürfen Impulse-NA nicht ersetzen/tarnen.

---

## Bezug sequential_dependency

Als Kind-Methode unverändert (`SPEC_D_sequential_dependency`). Programm darf Kind-NA nicht überschreiben.

## Nächste Methode

Härtetest Multi-Leading-Object: **`care_navigation`**.