Kairo-Jinkendo/docs/sprints/Sprint1_AP1_16_Execution_Plan_v0.1.md

AP1.16 — Durchführungsplan & Work-Package-Abhängigkeiten

Stand: 2026-07-12
PO-Freigabe: ADP_Execution_Plan_and_Work_Package_Dependencies_v0.1.md (2026-07-12)
Version (Ziel): 0.19.0-ap1.16
Voraussetzung: AP1.5 (Actions), AP1.6 (Gate-Link), AP1.12d (Outline „Arbeit“)

---

Ziel

Ausführungsreihenfolge von Arbeitspaketen modellieren — getrennt vom Gate-Graph. Rollende Planung: unter aktivem Gate-Horizont APs mit Vorgängern, ready/blocked Read Models, optional Planning Debt.

---

PO-Regeln (verbindlich)

Abgrenzung

	Gate-Graph (AP1.4d/15)	Execution-Graph (AP1.16)
Knoten	RoadmapItem	Action
UI	Zielzustands-Designer	Plan-Outline „Arbeit“
Verify	Kriterien + Evidence	Action done
Granularität	grob (5–15)	fein (10–100+)

Kanten-Semantik (action_dependencies)

dependency_kind	Bedeutung
requires	successor startet erst, wenn predecessor done
blocks	predecessor offen → successor blocked
relates	nur Anzeige, kein Block

Kanten-Richtung in DB: predecessor_action_id → successor_action_id (Vorgänger muss erfüllt sein, damit Nachfolger ready).

Scope

• Beide Actions gleiche Initiative
• Zyklen verboten (API lehnt ab)
• Execution Engine steuert keinen Lifecycle automatisch — nur Read Models

Planning Actions

• action_kind: delivery (Default), planning, review
• Meta-APs für explizite Planungsschritte (Archetyp planning_mode=explicit)

---

Lieferungen

AP1.16a — Schema

#	Inhalt
1	Migration 023_action_execution_plan.sql
2	actions.sort_order INT NOT NULL DEFAULT 0
3	actions.action_kind CHECK (delivery, planning, review)
4	Tabelle action_dependencies + Indizes
5	Action-Service: Felder in CRUD/SELECT

AP1.16b — Engine & API

#	Inhalt
6	backend/steering/graph/execution_engine.py
7	services/execution_plan.py — Deps CRUD, Cycle-Check
8	GET /api/initiatives/{id}/execution/graph-state
9	GET/POST/DELETE …/execution/dependencies
10	pytest: Engine + Cycle-Detection (Unit)

AP1.16c — Frontend ✓

#	Inhalt
11	Plan-Outline „Arbeit“: blocked/ready Badges
12	Action-Detail: Vorgänger-Verwaltung
13	Planning Debt Banner auf Plan → Arbeit

AP1.16d + AP1.9c — Attention & Cockpit ◐

#	Inhalt
14	Attention: planning_debt, execution_waiting
15	Cockpit Portfolio-Kacheln: Attention-Chips (AP1.9c)
16	Method Profile planning_levels
17	AP2.0d: Next-Action nutzt ready_actions

---

Explizit nicht in AP1.16a–b

• Gate-Designer-Änderungen
• project_dependencies (Struktur-Ebene B)
• RoadmapItem(type=feature) als WP-Knoten (Post-MVP)
• Lifecycle-Automatik aus Graph
• Gantt / Kalender

---

Abnahme

16a–b (Backend)

• Migration 023 auf Pi angewendet
• Zwei Actions, requires-Kante: Nachfolger blocked bis Vorgänger done
• Zyklus A→B→A wird abgelehnt
• sort_order-Fallback ohne Kanten (sequenziell wie Gate-Graph)
• graph-state liefert ready_actions, blocked_actions, critical_path
• planning_debt wenn aktives Gate ohne verknüpfte Actions
• pytest grün (Pi)

16c–d (später)

• Outline zeigt blocked/ready
• Planning Debt sichtbar in Attention

---

Reihenfolge

16a (Schema) → 16b (Engine + API) → 16c (UI) → 16d (Profile + Attention)
                     ↓
                 AP2.0d (Strategien)

---

Siehe: ADP_Execution_Plan_and_Work_Package_Dependencies_v0.1.md, Kairo_Plan_Mode_Design_v0.1.md §6