Kairo-Jinkendo/docs/architecture/ADP_Agile_Steering_Program_v0.1.md

ADP — Agile Steering Program (jenseits P4) v0.1

Status: PO-Freigabe (Planung — nicht implementiert)
Stand: 2026-07-27
Bezug: ADP Backlog/Epic P1–P4, SPEC-D agile_iteration, Steering Kernel Spine, Vision v0.2 (Program Director)

---

1. Ausgangslage

Mit P4 (Epic Roll-up) ist der Backlog/Epic-Track des Agile-Intake abgeschlossen:

• Dual Commit Path (Direct AP + Intake)
• Epic-Baum, Profil-Vokabular, Roll-up + Attention

Das reicht für Dokumentation und Nachverfolgung, aber noch nicht für vorausschauendes Dirigieren im Sinne der Product Vision: Kairo soll priorisieren, planen und steuern — nicht nur CRUD und Status anzeigen.

---

2. Lücke — „Dirigieren“ vs. „Dokumentieren“

Fähigkeit	Ist (nach P4)	Ziel (Program Director)
Epic-Fortschritt	Roll-up aus committeten Actions	✓
Sprint-Commit	Manuell aus Eingang	Vorschlag nächster Sprint-Inhalt
Priorisierung	Manuell (Priority-Feld)	Kernel-Vorschlag (Stories, Bugs, Debt)
Architekturschuld	Nicht modelliert	Führen, abbauen, Attention
Guardrail-/Architektur-Reviews	Review-Entität vorhanden	Regelmäßig, automatisiert, KI-unterstützt
Agent-Steuerung	Leading = Action	Task-Baum + Operating Context (P5)

Fazit: Agile Intake/Hierarchie ist fertig; Agile Steuerungsprogramm (Planung, Debt, Reviews) ist ein eigenes Programm — nicht in P4 mischen.

---

3. Entscheidung — Phasen P5–P8 (Agile Steering Program)

Phase	Inhalt	Schicht	Abhängigkeit
P5	Agent-Task-Baum unter Action	Ist / Recursive Tasks	ADP Recursive (AP1.5d)
P6	Sprint-Vorschlag — Read Model: committbare Items + Prioritätsranking	Kernel + Snapshot	P4, work_cycles
P7	Tech-/Architekturschuld — Backlog-Typ oder Tag + Attention-Regeln + Abbau-Ziele	Plan + Kernel	Evidence, Review
P8	Automatisierte Reviews — Guardrails, Architektur, Zielerreichung (Actor + optional KI)	Recurring + Review + Agent-Slot	Principle Gate, MCP-Freigabe

Kein Phase-Sprung. KI/Prompt/MCP für P8 erst nach Principle Gate und stabilem Read-Model-Kern (vgl. Architecture Rules — eingefroren bis OM trägt).

---

4. P6 — Sprint-Vorschlag (Skizze)

Read Model sprint_planning_proposal (kein Pflicht-Commit):

• Input: offene Backlog-Items (Epic-Subbaum optional), aktiver/geplanter Sprint, Action-Ist, Blocker
• Output: ranked Liste { backlog_item_id, reason_code, score_hint }
• Attention wenn: Sprint startet in N Tagen und Commit leer; Bugs ohne Owner; Epic intake_only trotz aktivem Sprint

UI: Plan → Sprint — „Vorgeschlagene Items“ (Accept/Adjust), nicht Auto-Commit.

Steuerung: evaluate_next_work / eigene Strategy-Hook — keine Page-Ifs.

---

5. P7 — Architekturschuld (Skizze)

Option	Beschreibung	Empfehlung
A	item_kind=tech_debt im Backlog	Profilgebunden, Commit wie Story
B	action_kind=tech_debt Direct AP	Continuous-Pfad
C	Review + Evidence verknüpft mit Gate	Für Guardrail-Reviews

Empfehlung: A + B (Dual Path analog Features/Bugs) + Attention architecture_debt_stale wenn Debt älter als Schwellwert ohne Commit.

Abbau: nicht als Gate — als committete Actions mit Review-Evidence (Guardrail-Checkliste).

---

6. P8 — Automatisierte Reviews (Skizze)

• RecurringElement pro Initiative: „Architektur-Guardrail-Review“, „Sprint-Retro“, „Ziel-Check“
• Review-Entität mit Checkliste (config, nicht hardcoded in UI)
• Actor-Slot: Agent führt Review aus → Evidence + Decision-Vorschlag
• KI: nur über auditierten Agent-Actor; Kontext aus Snapshot/Operating Context — nicht Prompt-Drift

---

7. Abgrenzung zu P4

P4 liefert Ist-Fortschritt auf Epic-Ebene. P6–P8 liefern Vorausschau und Korrektur — eigenes ADP-Implementierungsprogramm, gleicher Kernel-Einstieg (evaluate_steering).

---

8. Referenzen

Dokument	Pfad
ADP Backlog/Epic	docs/architecture/ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md
SPEC agile_iteration	docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md
Recursive Tasks	AP1.5d / ADP Recursive Containers
Implementation Truth Table	docs/product/Kairo_Implementation_Truth_Table_v0.1.md