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

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)

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.