Kairo-Jinkendo/docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md

# SPEC-D — `agile_iteration`
## Steuerungsmethode — Spec-Tiefe D v0.1 (Kompositions-Methode)

**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
**Stand:** 2026-07-25  
**Rolle:** **Kompositions- / Horizont-Methode** (technisch AP2.4: `method_role=modifier`)  
**Komponiert mit:** `continuous_product`, `sequential_dependency`, `recurring_control`  
**Nicht:** eigene Vorhaben-Natur / kein Archetyp

---

## D1 Identität — PO ✓

| Feld | Wert |
|------|------|
| `method_key` | `agile_iteration` |
| Fachliche Rolle | **Komposition** (Kernel §6) mit eigener Plan-/Lifecycle-Logik für den Iterations-Horizont |
| Technische Rolle | `modifier` (ersetzt Primary nicht; nicht mit `program_delivery`) |
| Label (DE) | Agile Iteration / Sprint |
| Zweck | Taktet Arbeit in `work_cycle` (Sprint): Planung, Sprint-Backlog, Ausführung, Abschluss/Carryover. Ändert nicht, ob das Vorhaben Projekt (Ende) oder Product (Dauer) ist. |

**Klarstellung PO:** „Modifier“ ≠ schwache Logik. Agile hat volle Steuerungslogik für den Sprint — braucht aber eine **Primary** für Vorhaben-Natur (Closure, Gates-Rolle, Dauerbetrieb vs. Ende).

---

## D2 Geltung

| Feld | Wert |
|------|------|
| Komponiert mit | B2b + `continuous_product`; A2 + `sequential_dependency`; A3 + `recurring_control` |
| Nicht allein | ohne Primary keine Aussage über Vorhaben-Natur |
| Nicht Archetyp | Decision-Lock |

---

## D3 Horizon

| Schicht | Owner |
|---------|--------|
| **Vorhaben- / Plan-Horizont** | Primary (Gate, Orientierung, …) |
| **Iterations-Horizont (Ist)** | diese Methode: aktiver `work_cycle` |

Beide gleichzeitig gültig; Ist-Default bei aktivem Sprint = Sprint-Backlog.

---

## D4 Leading Work Item

**Im Sprint-Slice:** **Action**, gefiltert auf `work_cycle_id` des aktiven Sprints (Primary-Ready ∩ Sprint).

**Mit Primary `recurring_control` (A3):** Sprint taktet Actions (Verbesserung/Sonderarbeit). **CadenceInstances** bleiben Leading der Primary und liegen **nicht** als Sprint-Backlog-Todos; Ranking: Cadence overdue/due vor Sprint-Actions (siehe Spec-D `recurring_control` D6).

---

## D5 Lifecycle — eigener Slice (nicht „Flag“)

| Sprint-Phase | Steuerung |
|--------------|-----------|
| Sprint anlegen / geplant | Plan-Container |
| Sprint-Planung | Items aus Eingang/Backlog in Sprint legen (Commit/`work_cycle_id`) |
| Sprint aktiv | action_selection nur Sprint-Scope; Work-Default Sprint |
| Sprint abschließen | Review/Carryover/Unplan; Status `reached`/`closed` |
| Reaktivierung | optional laut bestehendem Flow |
| Kein aktiver Sprint | Komposition wirkungslos → **nur Primary** (kein leerer Sprint-Sackgasse) |

Primary-Lifecycle (intake … closure des Vorhabens) bleibt; dieser Slice **hängt sich** in planning / action_selection / waiting / result_intake / adaptation ein.

---

## D6–D8

Next: ready Actions im aktiven Sprint (Primary-Ready-Regeln ∩ work_cycle).  
Codes: `sprint_ready`, `sprint_empty`, `sprint_ending`.  
Attention: leerer aktiver Sprint; Überhang vor Abschluss.  
Events: activate, complete, carryover, reactivate, unplan.

---

## D9 Nested

Kann auf Kind unter B2a liegen, wenn Kind A2/B2b + Agile nutzt. Programm-Meta bleibt `program_delivery`.

---

## D10–D11

OM: `RoadmapItem(work_cycle)` + `actions.work_cycle_id`.  
Elements: `work_cycle_scope`.  
`composes_with`: `continuous_product`, `sequential_dependency`, `recurring_control`.

---

## D10b Backlog-Hierarchie & Jira-Abbildung (Agile-Vollmodell)

**Verbindlich:** [`ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md`](../ADP_Backlog_Hierarchy_and_Dual_Commit_Path_v0.1.md)

Diese Methode **aktiviert** das Scrum/Jira-Vokabular im Eingang — ersetzt nicht die Primary-Methode.

| Jira / Scrum | Kairo (Plan) | Kairo (Ist nach Commit) |
|--------------|--------------|---------------------------|
| Product Backlog | `BacklogItem` (Eingang) | — |
| Epic | `BacklogItem` `item_kind=epic`, Container | Roll-up über Stories/Actions |
| Story | `BacklogItem` `item_kind=story`, `parent_backlog_id` → Epic | `Action` `delivery` |
| Bug | `BacklogItem` `item_kind=bug` | `Action` `bug` (+ Feature-Ref) |
| Issue | `BacklogItem` `item_kind=issue` | `Action` `issue` (+ Feature-Ref) |
| Sprint | `RoadmapItem` `work_cycle` | Filter: `Action.work_cycle_id` |
| Sprint Backlog | — | committete Actions im Sprint (**keine** BacklogItems) |

**Regeln:**

- Epic ist **nicht** `RoadmapItem` / Meilenstein.
- Epic wird **nicht** direkt convertiert — nur Stories/Bugs/Issues darunter.
- Stories können **mehreren Epics** nicht zugeordnet sein (MVP: genau ein `parent_backlog_id`; n:m post-MVP).
- Ohne aktiven Sprint: Backlog-Hierarchie bleibt Plan; Leading = Primary Continuous/Sequential.

**MVP-Ist:** `story`/`bug`/`issue` ohne Epic/`parent_backlog_id` (AP2.2e). Volllogik = ADP Phase P2–P3.

---

## D10c Dual Commit Path (Primary + Agile)

| Pfad | Agile-Profil | Primary Continuous |
|------|--------------|-------------------|
| A Intake → Commit | Epic/Story → Sprint optional | Idee → Action |
| B Direct AP | erlaubt (Spike, Agent) | **Pflicht-Option** Plan → Arbeit |

`agile_iteration` verschärft Sprint-Scope; sie **erzwingt** nicht Pfad A für jedes AP.

---

## D12

| Punkt | PO ✓ |
|-------|------|
| Eigene Steuerungslogik | ja — Planen + Sprint-Lifecycle |
| Primary nötig | ja — Vorhaben-Natur |
| Bezeichnung | fachlich Kompositions-/Horizont-Methode; technisch modifier |
| Ein aktiver Sprint | ja (Decision-Lock) |