Kairo-Jinkendo/docs/architecture/ADP_Agile_Steering_Program_v0.1.md
Lars ef5ee0d19b
Some checks failed
Test Suite / pytest-backend (push) Waiting to run
Test Suite / lint-backend (push) Waiting to run
Test Suite / compose-smoke (push) Waiting to run
Test Suite / k6 /api/health Baseline (push) Blocked by required conditions
Test Suite / playwright-smoke (push) Blocked by required conditions
Deploy Development / deploy (push) Has been cancelled
feat(steering): Epic Roll-up Read Model und Attention (ADP P4)
Schliesst den Backlog/Epic-Track mit kernel-basiertem Fortschritt pro Epic, Steuerungs-Attention und UI-Fortschrittsanzeige im Plan-Eingang ab.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-27 11:13:47 +02:00

99 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# ADP — Agile Steering Program (jenseits P4) v0.1
**Status:** PO-Freigabe (Planung — nicht implementiert)
**Stand:** 2026-07-27
**Bezug:** ADP Backlog/Epic P1P4, 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 P5P8 (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**. P6P8 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` |