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

SPEC-D — sequential_dependency

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
OM/UI: SPEC_A2_linear_project_v0.1.md
Prozess: M1_Hybrid_Path_and_Depth_D_v0.1.md (+ Kurskorrektur: konkrete Steuerungsregeln)
Quellen: Decision-Lock A2, ADP Execution Plan / AP1.16, Fit-Analyse, Code execution_ready / graph-state

---

D1 Identität — PO ✓

Feld	Wert
method_key	sequential_dependency
Rolle	primary (Ausführung — Kernel §6)
Label (DE)	Sequenzielle Abhängigkeit / kritischer Pfad
Zweck	Begrenztes Vorhaben über Gates/Abhängigkeiten; Next Action = nächster ready-Schritt am relevanten Pfad (typisch kritischer Pfad).

---

D2 Geltung — PO ✓

Feld	Wert
Default	A2 initiative.linear_project
kompatibel	A2; projektartige Kind-Projekte unter B2a
nicht Meta für	B2a-Programm (program_delivery); B2b Default (continuous_product)

---

D3 Horizon — PO ✓ (AA)

Horizont	Bedeutung
Plan	aktives / fokussiertes Gate (Zielzustand) + erreichbarer Teilgraph
Ist (ohne Agile)	Actions am Gate-/Pfad-Ausschnitt
Ist (mit agile_iteration)	zusätzlich aktiver work_cycle als Ausführungs-Takt; Gate bleibt Plan-Horizont

---

D4 Leading Work Item — PO ✓ (AA)

Action (Arbeitspaket). Ready über Abhängigkeiten. Task = unter Action, nicht Leading Object.

---

D5 Lifecycle-Pfad (konkret)

Schritt	Status	Konkrete Bedeutung in dieser Methode
intake	active	Ziel, Scope, Vorhaben anlegen
method_selection	active	Default A2; Wechsel auditiert
structure_setup	active	Projects/Stränge, Gates, Gate-Deps (requires), optional Action-Deps
planning	active	rollierend: nächster Gate-Horizont + APs; nicht „alles vorab“ Pflicht
action_selection	active	ready_actions ∩ Ranking kritischer Pfad
assignment	active	Actor an Action
waiting	active	auf Erledigung / Freigabe Deps
result_intake	active	Status done / Evidence / Blocker
validation	active	Gate-Kriterien / Verify vor reached
review	skip/optional	bei Meilenstein-Review; nicht jeder AP
adaptation	active	Replan Graph/APs bei Blocker oder Planänderung
closure	active	Vorhaben-/Gate-Abschluss möglich und erwartet

---

D6 Next Action — konkrete Regeln

Ready (Action):

1. Status ∈ offene Arbeitszustände (open / ready / in_progress … je OM)
2. Alle requires-Vorgänger (Action-Deps und ggf. Gate-Bindung laut Graph-Profil) erfüllt (done oder waived per Decision)
3. Nicht durch Blocker gesperrt (sonst Attention, nicht Next)
4. Im aktiven Horizont (Gate und/oder Sprint, wenn Modifier aktiv) — PO ✓: kritischer Pfad nur innerhalb des Horizonts; keine Next Action außerhalb des Gate-/Sprint-Filters nur weil „auf globalem critical path“

Ranking:

1. Actions auf dem critical_path vor anderen ready
2. dann sort_order / Titel
3. reason_codes: execution_critical_path, execution_ready

Leerer Fall:

• keine ready Action → Attention: blockiert / Planning Debt / „nächstes Gate ohne APs“ — keine Fake-Next-Action

Nicht Next Action:

• blockierte Nachfolger als ready verkaufen
• Programm-Impulse (das ist program_delivery)
• Recurring/Checklist als Leading Object

---

D7 Attention — konkrete Auslöser

Signal (Ziel-Code)	Wann
path_blocked	kritische Action/Gate durch Blocker oder offene requires
gate_at_risk	target_date / Kriterien gefährdet
planning_debt	aktiver Horizont ohne planbare/ready APs (AP1.16d-Semantik)
overdue_action	Action überfällig

---

D8 Events

Event	Wirkung
Action → done	Deps neu auswerten → neue ready-Menge
Blocker create/clear	Attention + ready neu
Gate verify / reopen	Horizont + Erfüllung
Plan-Graph-Änderung	critical_path / ready neu
(mit Agile) Sprint aktiv/complete	Ist-Horizont wechselt

Externe Gerichts-/Fürsorge-Events: nicht Kern dieser Methode.

---

D9 Nested

n/a als Programm-Meta.
Als Kind unter B2a: diese Methode steuert nur den Kind-Kontext; Parent nutzt program_delivery für Impulse.

---

D10 OM-Voraussetzungen

Minimal	Optional
Initiative + SteeringContext	Tasks unter Action
≥1 Gate/Milestone oder äquivalenter Zielzustand	Gate-Kriterien
Actions	work_cycle nur mit Agile-Modifier
Abhängigkeiten: Gate- und/oder Action-Deps (sonst degeneriert zu flacher Liste — Attention planning_debt / Hinweis)	Evidence, Blocker

---

D11 Extension Points

Art	Key / Verhalten
next_action_strategy	sequential_dependency → nutzt ready_actions + critical_path
steering_elements	next_action_primary, critical_path, gate_fulfillment
graph_profile	Gate-Blocking / Fulfillment betont (enforce_gate_blocking typisch true)
ui_features	criticalPathControl
modifier	agile_iteration komponierbar (Horizon Ist = Sprint)
hooks (Ziel)	on_next_action_requested, on_structure_required, on_dependency_analysis_required, on_evidence_required, on_replan_required

---

D12 Spannungen zum Kandidat-Kern / offene Punkte

Punkt	Bewertung
Lifecycle-Loop	passt; Closure expected
Horizon-Anker	nötig — ohne ihn Agile-Komposition unklar
Work-Item-Polymorphie	hier nur Action — stützt Anker, nutzt Union minimal
Nested	nur als Kind — stützt Trennung zu program_delivery
Zwei Graphen (Gate vs Action-Deps)	Besonderheit: beide erlaubt; Next Action primär Ist-Graph (Actions), Plan-Graph begrenzt Horizont — muss im Kern als „Horizon + ReadyWorkItem“ klar bleiben, nicht vermischt werden

PO ✓ (2026-07-25):

1. Next Action nicht außerhalb des aktiven Horizonts, auch wenn global auf critical path.
2. Gate-Graph allein reicht als Minimalstart; Action-Deps schärfen Ready/Critical Path. Ohne jegliche Deps → flache Liste + Attention planning_debt, Methode bleibt gültig.

---

Nächste Methode

Härtetest Nested: program_delivery.