196 lines
9.3 KiB
Markdown
196 lines
9.3 KiB
Markdown
|
# 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.*
|