Lars
1bbc5dbfce
Keine feste Bug-zuerst-Policy: heuristic_v0 als Fallback, agent_v1-Slot vorbereitet, parent_action-Abhaengigkeiten und factors[] fuer spaetere KI-Steuerung. Co-authored-by: Cursor <cursoragent@cursor.com>
5.2 KiB
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_v0ist expliziter Fallback; Produktentscheidung später viaagent_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 |