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, **ADP Steering Kernel Extension Model v0.1**, 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)

> **Architekturrahmen:** Alle Phasen nutzen die **Extension Registry** des Kernels (Read Models, Proposals, Agent-Slots) — siehe `ADP_Steering_Kernel_Extension_Model_v0.1.md`. Agile liefert **Provider-Implementierungen**, nicht Kernel-Forks.

| Phase | Inhalt | Kernel-Extension | Plugin / OM |
|-------|--------|---------|--------------|
| **P5** | Agent-Task-Baum unter Action | — | Ist / Recursive Tasks (AP1.5d) |
| **P6** | Sprint-Vorschlag (ranked Backlog → Sprint) | `ProposalProvider` `sprint_commit` | ✓ AP2.2i (Kernel v0.3) |
| **P7** | Tech-/Architekturschuld führen & abbauen | `ReadModelProvider` + `AttentionContributor` | Vokabular + Review/Evidence |
| **P8** | Automatisierte Reviews (Guardrails, Ziele) | `AgentSlotProvider` + Recurring-Attention | Review + Actor (KI nach Gate) |

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_commit` (kein Pflicht-Commit):

- Input: committable Backlog-Items, Sprint-Horizont, Action-Ist, **Abhängigkeiten** (`parent_action_id`, Epic-Roll-up)
- Output: ranked Liste mit `ranker_key`, `factors[]`, `dependency_refs`, `dependency_blocked`
- **Keine feste Bug-Policy** — Default-Ranker `heuristic_v0` ist expliziter Fallback; Produktentscheidung später via `agent_v1` (Actor/KI, Principle Gate)

**Ranker-Auswahl** (Operating Context / Governance, nicht Page-If):

| Ranker | Status | Verhalten |
|--------|--------|-----------|
| `heuristic_v0` | ✓ Fallback | Priorität + Eingang + leichte kind_bias + Abhängigkeiten |
| `agent_v1` | Stub | Agent-Slot — wählt Subset/Begründung; bis Freigabe Fallback |

**UI:** Plan → Sprint — Vorschläge Accept/Adjust; blockierte Abhängigkeiten nicht committierbar.

**Steuerung:** `ProposalProvider` + austauschbarer Ranker — **nicht** `evaluate_next_work`, **keine** hardcodierte Sortierung in UI.

---

## 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 |
|----------|------|
| **Kernel Extension Model** | `docs/architecture/ADP_Steering_Kernel_Extension_Model_v0.1.md` |
| 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` |