# 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](c5b5c664-9bf9-486a-acf9-f20bb005b32e)

---

## 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):

```text
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

```text
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.*