Kairo-Jinkendo/docs/product/Kairo_Session_Handover_2026-07-12.md

Jinkendo Kairo

Session-Handover — 2026-07-12

Status: Übergabe an neuen Chat / nächsten Agenten
Stand: 2026-07-12 (Abend)
Branch: develop @ 82a5b9a (gepusht auf Remote)
Version (Deploy): 0.20.2-ap2.2d
Vorgänger-Chat: MVP-Plan AP2.2 Session

---

1. Wichtigste Klarstellung

Es gibt keinen neuen „Plan v0.3“-Bedarf. Zu Beginn dieser Session wurde der Kurs bereits in Kairo_MVP_Execution_Plan_v0.2.md festgezogen (PO-Kurskorrektur: Referenz-Archetypen statt Dogfooding-Seed).

Was in der Session schief lief: Implementierung lief schneller als das Zielbild — AP2.2b/c/d wurden als Code-Pakete abgearbeitet, während End-to-End-Flows und methodengebundene Default-UI (AP1.9d) fehlen. Der Agent schlug am Ende fälschlich vor, den Plan noch einmal neu aufzustellen. Das lehnt der PO ab.

Für den nächsten Chat gilt:

1. Kairo_MVP_Execution_Plan_v0.2.md bleibt führend — nicht ersetzen, nicht parallel neu erfinden.
2. Dieses Handover präzisiert Interpretation, PO-Feedback und Stop-Regeln für Implementierung.
3. Nächste Arbeit = Zielbild-Flows schließen, nicht weitere Nav-/Hint-Patches.

---

2. Session-Verlauf (Kurz)

Phase	Inhalt
Start	MVP-Plan fortsetzen; Kurskorrektur: mehrere Referenz-Archetypen anleg- und pflegbar (nicht Dogfooding spiegeln)
AP2.2a	Gepusht (2b0d5dd): Starter-Kits, geführte Anlage, seed_004 deprecated
AP2.2b/c	Committed + gepusht (0b57e2e): A1-Stufenwechsel, Team-Fix, Agent-POST, Steuerungs-Hinweise
AP2.2d	Committed + gepusht (82a5b9a): Sprint-UI, work_cycle-API im Frontend, Backlog→Sprint-Autoassign
PO-Test	UX-Probleme: zu viele Archetypen, UUIDs im Team, fehlende Actor-Anlage, Reifegrad schwer findbar
PO-Agile	Zeitbox nicht als Scrum-Kern; Sprint-Planung aus Backlog fehlt; Begriff „Zeitbox“ verwirrend
Abschluss	Session dokumentieren, sauberer Handover — kein weiterer Plan-Reset

---

3. Was auf develop liegt (Commits)

82a5b9a  AP2.2d: B2b Product-Backlog und B3 Sprint-Backlog in UI.
0b57e2e  AP2.2b/c: A1-Stufenwechsel, Team-Fix, Agent-Anlage, Steuerungs-Hinweise.
2b0d5dd  AP2.2a: Archetyp-Starter-Kits und MVP Execution Plan v0.2.

AP2.2a (Infrastruktur + Anlage)

• backend/services/archetype_starter_kit.py — Kits A1, A2, B2b, B2a
• GET /api/entity-archetypes/{key}/starter-preview
• POST /api/initiatives mit apply_starter_kit
• Frontend: Vorschau in InitiativeForm.jsx

AP2.2b/c (Teil-UI, Backend teils fertig)

• AP2.0e: maturity_stage_transition.py — Recurring rotiert bei Stufen-Verify
• Team: display_name, POST /api/actors, Agent-Formular
• ArchetypeSteeringHints.jsx, Optgroups „MVP Stufe A“

AP2.2d (Teil-UI — PO: unzureichend für Scrum-Zielbild)

• frontend/src/api/workCycles.js, WorkCyclesPanel.jsx
• Plan → Sprint, Ausführen → Sprint
• Backlog-Convert setzt work_cycle_id der aktiven Zeitbox
• agile_iteration-Strategie bei aktivem Sprint + continuous_product
• Fehlt: Sprint-Planung (Backlog auswählen → in Sprint legen), Sprint-Abschluss, optionaler Sprint ohne Zeit-Druck

---

4. PO-Feedback (verbindlich für nächste Implementierung)

4.1 Allgemein

• Keine Shortcuts: Keine Hints/Nav/Redirects als Ersatz für echte methodengebundene Flows.
• Keine Seeds/Vorbefüllung als Produkt-Erfahrung; Starter-Kits nur optional beim Anlegen, sonst leeres Vorhaben.
• GUI muss Prozess zeigen: Archetyp → Methode → Plan vs. Ist → Kontrolle — nicht sechs lose Plan-Tabs.
• Abhängigkeiten (Gate-Graph, kritischer Pfad) bleiben Pflicht (A2, auch unabhängig von Agile).

4.2 Agile / Scrum

• Agile ist Methode (agile_iteration), kein Archetyp. Basis: initiative.product + continuous_product.
• Sprint ist Planungs-Container, kein Kalender-Zwang. work_cycle im Modell, in UI: „Sprint“ (nicht „Zeitbox“).
• Gewünschter Flow:
  1. Priorisierbares Product Backlog (Eingang)
  2. Sprint-Planung anstoßen
  3. Items aus Backlog in Sprint legen (Commit)
  4. Sprint ausführen
  5. Sprint abschließen → Review/Carryover → nächste Planung
• Aktueller Ist-Stand: nur „In Maßnahme umwandeln“ ohne Sprint-Auswahl; Ausführen→Sprint leer ohne aktiven Sprint.

4.3 Verwirrung in der GUI (Ist)

• Zu viele gleichwertige Plan-Unterpunkte ohne Prozessleiste
• Begriffe: Zeitbox, Maßnahme, Arbeit, Sprint, Eingang — nicht konsistent mit Vision §4 Product Language
• AP1.9d (Methoden-Default-UI) offen — überall Listen statt Next Action / methodenspezifischer Default

---

5. Execution Plan v0.2 — Interpretations-Korrektur

Plan bleibt gültig. Folgende Zeilen sind überzogen als „✓“ markiert und sollten im nächsten Chat so gelesen werden:

Paket	Plan-Status	Tatsächlicher Stand
AP2.2a	✓	Anlage + Starter-Kit — OK als Basis
AP2.2b	◐	Graph/Strategie da; Kontrolle A2 End-to-End fehlt
AP2.2c	◐	AP2.0e Backend; Journey/Recurring-UX unvollständig
AP2.2d	✓ (Plan)	Nur Infrastruktur + Teil-UI — Sprint-Planungs-Flow fehlt (ADP § Sprint Planning = ○)
AP1.9d	offen	Blocker für verständliche GUI — vor weiteren AP2.2-Patches priorisieren

Nächste Priorität laut Plan (unverändert): AP1.9d → AP2.2b/c/d Flows schließen → AP1.7b → AP2.1 Validation.

Nicht tun: Execution Plan v0.3 schreiben, es sei denn PO fordert es explizit.

---

6. Zielbild — ein Bild für alle Archetypen

Drei Schichten (aus Vision v0.2 + MVP v0.3):

Archetyp (Was?)  →  Methode (Wie steuern?)  →  Plan vs. Ist (Was ist wann?)

Archetyp	Methode	Plan	Ist	Kontrolle
A2 Linear	sequential_dependency	Gate-Graph, Abhängigkeiten	APs an Gates	Nächster ready Schritt am kritischen Pfad
A1 Reifegrad	maturity_progression	Stufen + Graph	Recurring + APs	Aktive Stufe + heutige Übung
B2b Product	continuous_product	Eingang (Product Backlog)	Committete APs	Wirkungsvollster Schritt
+ Agile (Profil)	agile_iteration	Sprint-Planung	Sprint-Backlog	Nächster Schritt im Sprint

Referenz-UI-Konzept (noch PO-Entwurf): Kairo_PM_Frontend_UI_Concept_v0.1.md — Modi + Scope + Objekt; Prozessleiste pro Methode fehlt noch in Implementierung.

---

7. Stop-Regeln für nächsten Agenten

1. Kein neuer Execution Plan ohne PO-Freigabe.
2. Keine weiteren Subnav-Einträge ohne abgeschlossenen End-to-End-Flow.
3. Keine Seeds / Dogfooding / Demo-Vorhaben als Implementierungs-Hebel.
4. Kein „✓“ in Truth Table / Execution Plan ohne PO-Durchspielbarkeit (Leitfrage ≤2 Min).
5. Product Language in UI: Sprint (nicht Zeitbox), Arbeitspaket (nicht Maßnahme wo möglich), Eingang = Product Backlog.
6. Backend-Tests lokal oft ohne DB — Verifikation über Push auf develop → Pi-Deploy (siehe .cursor/rules/kairo-deployment-testing.mdc).
7. Nicht proaktiv committen/pushen ohne Nutzeranfrage.

---

8. Empfohlener nächster Arbeitsauftrag (für PO-Freigabe)

Ein zusammenhängendes Paket — nicht AP2.2x-Fragmente:

Option A (PO-Priorität GUI-Klarheit): AP1.9d + Product Language

• Methoden-Default pro Modus (Kontrolle/Ausführen/Plan)
• Umbenennung Zeitbox → Sprint in der GUI
• Prozessleiste im Scope bei Product-Vorhaben: Eingang → Sprint planen → Ausführen → Kontrolle

Option B (Agile-Lücke schließen): Sprint-Planung (Erweiterung AP2.2d, kein neuer Plan)

• Backlog-Items markieren → „In Sprint [R2] planen“
• Sprint-Status: geplant → aktiv → abgeschlossen
• Ausführen ohne aktiven Sprint: Fallback continuous_product, nicht leere Sprint-Seite

Option C (Abhängigkeiten): AP2.2b A2 End-to-End

• Kontrolle: kritischer Pfad + Begründung aus Execution Graph

PO sollte eine Option wählen — nicht alles parallel.

---

9. Dokumente — Lesereihenfolge nächster Chat

1. Dieses Handover
2. docs/product/Kairo_MVP_Execution_Plan_v0.2.md (führend, unverändert)
3. docs/product/Kairo_MVP_Definition_v0.3.md
4. docs/product/Kairo_Vision_and_Product_Direction_v0.2.md §4–5 (Product Language, Plan vs. Ist)
5. docs/architecture/ADP_Archetype_and_Method_Catalog_v0.2.md §2.3, § Sprint-Semantik
6. docs/product/Kairo_PM_Frontend_UI_Concept_v0.1.md (UI-Zielbild)
7. docs/product/Kairo_Implementation_Truth_Table_v0.1.md (Ist-Check, mit Skepsis gegenüber ✓)

---

10. Remote-Verifikation (Pi)

Nach Deploy auf develop:

• pytest: test_ap22a_starter_kit, test_ap20e_maturity_transition, test_ap22_actor_create, test_ap22d_sprint_backlog, test_ap20f_work_cycle
• Manuell: Product anlegen → Eingang → Sprint anlegen → Convert → Ausführen/Sprint

---

11. Prompt-Vorschlag für neuen Chat

Lies docs/product/Kairo_Session_Handover_2026-07-12.md und arbeite strikt nach
Kairo_MVP_Execution_Plan_v0.2.md. Kein neuer Plan, keine Seeds, keine Shortcuts.
PO-Priorität: [Option A / B / C aus Handover §8 eintragen].
Zuerst kurz bestätigen, welchen End-to-End-Flow du schließt, dann implementieren.

---

Erstellt am Abschluss der Session 2026-07-12. Execution Plan v0.2 bleibt maßgeblich; dieses Dokument ist Interpretations- und Feedback-Anhang.