Kairo-Jinkendo/docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md
Lars 753f178b0c
Some checks failed
Deploy Development / deploy (push) Successful in 48s
Test Suite / pytest-backend (push) Failing after 3m23s
Test Suite / k6 /api/health Baseline (push) Has been skipped
Test Suite / playwright-smoke (push) Has been skipped
Test Suite / lint-backend (push) Successful in 3s
Test Suite / compose-smoke (push) Has been skipped
docs: Archetyp-Vollspecs und Methodenkern vorlaeufig freigeben.
Decision-Lock, Spec-D-Methoden und C1-Massstab-Vollspecs als Zielbild; Steering-Registry/Compat und Horizon-Tests an die Normierung anbinden. Implementierungsausreichendheit bleibt bewusst offen.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-26 15:02:04 +02:00

3.7 KiB
Raw Blame History

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.


D6D8

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.


D10D11

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


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)