Lars/Kairo-Jinkendo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(AP2.1): MVP Validation Assignment und Report v0.3
Some checks failed
Deploy Development / deploy (push) Successful in 48s
Details
Test Suite / pytest-backend (push) Failing after 4m39s
Details
Test Suite / k6 /api/health Baseline (push) Has been skipped
Details
Test Suite / playwright-smoke (push) Has been skipped
Details
Test Suite / lint-backend (push) Successful in 3s
Details
Test Suite / compose-smoke (push) Has been skipped
Details

Browse Source 
Bereitet PO-Abnahme Stufe A vor: Smoke-Checklisten fuer A1, A2, B2b+B3,
Go-Kriterien und Truth-Table/Execution-Plan auf Phase 5 aktualisiert.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Lars 2026-07-28 09:19:37 +02:00
parent 69c516dba4
commit be0090d513
4 changed files with 382 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/product/Kairo_Implementation_Truth_Table_v0.1.md
View File

@ -176,7 +176,7 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
| maturity / sequential / queue / recurring Strategien | ✓ | AP2.0d; pytest + Deploy | | maturity / sequential / queue / recurring Strategien | ✓ | AP2.0d; pytest + Deploy |
| Referenz-Ausprägungen (Kumite, Buch, Kairo) | ◐ | Code-Registry; Nutzer wählt bei Anlage | | Referenz-Ausprägungen (Kumite, Buch, Kairo) | ◐ | Code-Registry; Nutzer wählt bei Anlage |
| Archetyp Starter-Kits | ◐ | AP2.2a | | Archetyp Starter-Kits | ◐ | AP2.2a |
| MVP-Abnahfe Stufe A validiert | ✗ | AP2.1 nach AP2.2b–e | | MVP-Abnahfe Stufe A validiert | ◐ | AP2.1: Report v0.3 + Assignment — PO-Validation auf Dev ausstehend |
| Operational Actor API | ✓ | AP1.7: `/api/operational/` + Service Tokens | | Operational Actor API | ✓ | AP1.7: `/api/operational/` + Service Tokens |
| Actor Service Token | ✓ | AP1.7c; Tenant-scoped, capability-gebunden | | Actor Service Token | ✓ | AP1.7c; Tenant-scoped, capability-gebunden |
| MCP produktiv | ✗ | nach AP2.1 Go | | MCP produktiv | ✗ | nach AP2.1 Go |
@ -234,7 +234,7 @@ Details: `Kairo_Status_Review_and_Next_Steps_v0.1.md` §2.1
| AP2.2c | A1 Reifegrad E2E ✓ (2026-07-27) | | AP2.2c | A1 Reifegrad E2E ✓ (2026-07-27) |
| AP1.9d | Work-Composition + Drill-down ◐→✓ (2026-07-27) | | AP1.9d | Work-Composition + Drill-down ◐→✓ (2026-07-27) |
| AP2.2c–e | Referenz-Archetypen End-to-End ◐→✓ | | AP2.2c–e | Referenz-Archetypen End-to-End ◐→✓ |
| AP2.1 | MVP-Abnahfe ✗→✓ | | AP2.1 | MVP-Abnahfe ◐→✓ (Report v0.3 + Assignment 2026-07-28; PO-Smoke auf Dev) |
| AP1.7b | Op-API Parität ◐→✓ (2026-07-27) | | AP1.7b | Op-API Parität ◐→✓ (2026-07-27) |
--- ---

18
docs/product/Kairo_MVP_Execution_Plan_v0.2.md
View File

@ -2,7 +2,7 @@
## MVP Execution Plan v0.2 ## MVP Execution Plan v0.2
**Status:** PO-Kurskorrektur — **führend für Implementierung ab 2026-07-12** **Status:** PO-Kurskorrektur — **führend für Implementierung ab 2026-07-12**
**Stand:** 2026-07-25 (AP2.3/AP2.4 Plugin-Architektur ✓) **Stand:** 2026-07-28 (Phase 5 AP2.1 — Validation-Artefakte bereit)
**Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–9, `ADP_Archetype_and_Method_Catalog_v0.2.md` §3, `ADP_Archetype_Method_Plugin_Architecture_v0.1.md`, `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`, `Kairo_Corrected_MVP_Roadmap_v0.2.md` (AP-Historie) **Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–9, `ADP_Archetype_and_Method_Catalog_v0.2.md` §3, `ADP_Archetype_Method_Plugin_Architecture_v0.1.md`, `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`, `Kairo_Corrected_MVP_Roadmap_v0.2.md` (AP-Historie)
**Spezifikationsphase (ab 2026-07-24/25):** **Spezifikationsphase (ab 2026-07-24/25):**
- Decision-Lock: `Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md` - Decision-Lock: `Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`
@ -84,7 +84,7 @@ Phase 3 AP2.2b A2 Linear End-to-End ✓
AP2.2d B2b Product + B3 Sprint ✓ AP2.2d B2b Product + B3 Sprint ✓
AP2.2e B2a Programm (optional vor AP2.1) AP2.2e B2a Programm (optional vor AP2.1)
Phase 4 AP1.7b Operational API — Pflege-Parität ✓ Phase 4 AP1.7b Operational API — Pflege-Parität ✓
Phase 5 AP2.1 Validation Report v0.3 (alle Stufe-A-Szenarien) Phase 5 AP2.1 Validation Report v0.3 (alle Stufe-A-Szenarien) ◐ PO
Phase 6 AP2.2f Stufe B: A3, B1, D1 Phase 6 AP2.2f Stufe B: A3, B1, D1
Phase 7 Schicht 4: Gitea-Webhook, MCP (nach AP2.1 Go) Phase 7 Schicht 4: Gitea-Webhook, MCP (nach AP2.1 Go)
``` ```
@ -131,17 +131,23 @@ Auth: Actor Service Token (Tenant-scoped). Kein Gate-Verify, kein Lifecycle-Over
## 7. AP2.1 Validation (nach Stufe-A-Flows) ## 7. AP2.1 Validation (nach Stufe-A-Flows)
**Status:** Artefakte bereit (2026-07-28) — **PO-Smoke auf Dev ausstehend**
**Dev:** https://dev.kairo.jinkendo.de (`0.20.2-ap2.2d`, schema 025)
**Nicht:** ein Dogfooding-Vorhaben auf Pi. **Nicht:** ein Dogfooding-Vorhaben auf Pi.
**Sondern:** PO füllt Report mit **echten, in der UI angelegten** Referenz-Vorhaben: **Sondern:** PO füllt Report mit **echten, in der UI angelegten** Referenz-Vorhaben:
- A1 (Reifegrad) - A1 (Reifegrad)
- A2 (Linear) - A2 (Linear)
- B2b (+ optional B3 Zeitbox) - B2b (+ B3 Sprint minimal)
- D1 wenn Stufe B bis dahin fertig - D1 optional (Stufe B)
Vorlage: `docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` (neu bei AP2.1) | Artefakt | Pfad |
|----------|------|
| Auftrag (Ablauf, Go-Kriterien) | `docs/sprints/Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md` |
| Report (ausfüllen) | `docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` |
Go-Kriterium: MVP v0.3 §5 — pro Stufe-A-Archetyp Leitfrage ≤2 Min + Next Action begründet. Go-Kriterium: MVP v0.3 §5 — pro Stufe-A-Archetyp Leitfrage ≤2 Min + Next Action begründet; Portfolio Cockpit-Attention (Kriterium 7).
--- ---

125
docs/sprints/Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md Normal file
View File

@ -0,0 +1,125 @@
# AP2.1 — MVP Validation (Stufe A)
## Auftrag v0.1
**Status:** freigegeben
**Stand:** 2026-07-28
**Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–8, `Kairo_MVP_Execution_Plan_v0.2.md` §7
**Output:** ausgefüllter `Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` + Go/No-Go
---
## 1. Ziel
Kairo ist **MVP-abnahmefähig (Stufe A)**, wenn ein PO **vier Referenz-Szenarien** in der **UI auf Dev** durchspielt und dokumentiert — **ohne** Dogfooding-Seed, **ohne** vorbefüllte Demo-Daten.
**Leitfrage (pro Vorhaben, ≤2 Minuten):**
> Welcher nächste Schritt bringt dieses Vorhaben **jetzt** am wirksamsten voran — und **warum**?
---
## 2. Abnahfe-Umfang (Stufe A)
| ID | Szenario | Archetyp | Methode | Pflicht |
|----|----------|----------|---------|---------|
| **A1** | Spagat können | `initiative.maturity_journey` | `maturity_progression` | ✓ |
| **A2** | Neue Küche | `initiative.linear_project` | `sequential_dependency` | ✓ |
| **B2b** | Product-Betrieb (z. B. Kairo selbst) | `initiative.product` | `continuous_product` | ✓ |
| **B3** | Sprint-Zeitbox auf B2b | Profil `agile_iteration` | `work_cycle` | ✓ minimal |
| D1 | Buch schreiben | Stufe B | — | optional (nicht MVP-Blocker) |
**B3** wird im **selben** Product-Vorhaben wie B2b geprüft (kein eigener Archetyp).
---
## 3. Umgebung
| | |
|---|---|
| **Dev-Instanz** | [https://dev.kairo.jinkendo.de](https://dev.kairo.jinkendo.de) |
| **Health** | `GET /api/health` |
| **Branch** | `develop` (nach letztem Deploy) |
| **CI-Referenz** | Gitea Actions `test.yml` — E2E-Tests als technische Vorprüfung |
**Regeln:**
- Vorhaben **neu in der UI anlegen** (Starter-Kit optional aktivieren)
- **Kein** `seed_004` / Dogfooding als Abnahme-Shortcut
- Screenshots oder Initiative-IDs im Report notieren
---
## 4. Ablauf pro Szenario (~20–30 Min)
1. **Anlegen** — Archetyp wählen, Starter-Kit, Scope setzen
2. **Struktur** — Stufen / Gates / Sprint anlegen (methodenabhängig)
3. **Ist committen** — mindestens 1–2 Arbeitspakete; bei B2b: Backlog → Sprint
4. **Kontrolle** — Lagebild: Methode, Next Action (1–3), Begründung, keine Todo-Wand
5. **Ausführen** — Default-Route (Heute / Sprint) zeigt Steuerung, nicht Gesamtliste
6. **Journey** — min. ein steuerungsrelevantes Event sichtbar
7. **Leitfrage** — PO beantwortet schriftlich in ≤2 Min (Stopuhr)
8. **Anti-Patterns** — explizit prüfen (§7 MVP v0.3)
Detaillierte Schritte: Abschnitt 6 in `Sprint1_AP2_1_MVP_Validation_Report_v0.3.md`.
---
## 5. Go-Kriterien (verbindlich)
### Pro Archetyp (A1, A2, B2b+B3)
| # | Kriterium (MVP v0.3 §5) | Go |
|---|------------------------|-----|
| 1 | Anlage + Default-Methode + Profil | ☐ |
| 2 | Passende Struktur modellierbar | ☐ |
| 3 | Ist committet (nicht alles gleichzeitig sichtbar) | ☐ |
| 4 | Kontrolle: Next Action **begründet** | ☐ |
| 5 | Journey nachvollziehbar (≥1 Event) | ☐ |
| 6 | Leitfrage ≤2 Min **ohne CRUD-Wand** | ☐ |
### Portfolio
| # | Kriterium | Go |
|---|-----------|-----|
| 7 | Cockpit: Attention pro Vorhaben, nicht Task-Details | ☐ |
### Gesamt-Go
- **Go Stufe A:** alle Pflicht-Szenarien (A1, A2, B2b+B3) + Kriterium 7 = ja
- **Bedingt:** ≤1 Szenario mit dokumentierter Lücke + Workaround + Fix-AP
- **No-Go:** Leitfrage nicht beantwortbar oder Todo-Explosion als Hauptbild
---
## 6. Technische Vorprüfung (Agent/CI — kein PO-Ersatz)
| Paket | Test-Datei | Szenario |
|-------|------------|----------|
| AP2.2a | `test_ap22a_starter_kit.py` | Kits A1, A2, B2b |
| AP2.2b | `test_ap22b_linear_e2e.py` | A2 Küche Happy Path |
| AP2.2c | `test_ap22c_maturity_e2e.py` | A1 Spagat + Stufenwechsel |
| AP2.2d | `test_ap22d_sprint_backlog.py` | B2b Backlog → Sprint |
Grüne CI-Tests sind **notwendig**, aber **nicht hinreichend** für AP2.1 Go.
---
## 7. Deliverables
| Artefakt | Pfad |
|----------|------|
| Report (ausfüllen) | `docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` |
| Truth Table | `AP2.1` Zeile nach Go aktualisieren |
| Execution Plan | Phase 5 als ✓ markieren |
---
## 8. Nach Go
- Merge `develop` → `main` (Prod-Deploy) erst nach **PO Go Stufe A**
- Template/Blueprint-Konzeption (AP-BP-0) parallel, nicht MVP-Blocker
- Stufe B (A3, B1, D1) erst nach AP2.1 Go planen
---
*Vorlage Report: `Sprint1_AP2_1_MVP_Validation_Report_v0.3.md`*

243
docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md Normal file
View File

@ -0,0 +1,243 @@
# AP2.1 — MVP Validation Report
## v0.3 (Stufe A)
**Status:** Entwurf — vom Product Owner auszufüllen
**Stand:** 2026-07-28
**Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–8
**Assignment:** `Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md`
| Feld | Wert |
|------|------|
| **Kairo-Version / Deploy** | |
| **Dev-URL** | https://dev.kairo.jinkendo.de |
| **Branch / Commit** | `develop` @ |
| **Tester (PO)** | |
| **Testdatum** | |
---
## 1. Executive Summary
| Entscheidung | ☐ Go Stufe A · ☐ Bedingt · ☐ No-Go |
|--------------|-------------------------------------|
**Kurzfazit (3–5 Sätze):**
**Blocker (falls No-Go / Bedingt):**
---
## 2. Portfolio (Kriterium 7)
**Leitfrage Portfolio:** *Welches Vorhaben braucht jetzt welche Art von Attention?*
| Check | ja/nein | Notiz |
|-------|---------|-------|
| Cockpit zeigt Vorhaben mit Attention-Signal (nicht Task-Listen) | | |
| Unterschiedliche Vorhabenarten parallel erkennbar | | |
| Drill-down zu Details nur bewusst | | |
| Leitfrage Portfolio ≤2 Min | | |
---
## 3. Szenario A1 — Spagat können (Reifegrad)
**Initiative-ID / Titel:**
**Archetyp:** `initiative.maturity_journey` · **Methode:** `maturity_progression`
### 3.1 Smoke-Schritte (Dev)
| # | Schritt | Route | erledigt |
|---|---------|-------|----------|
| 1 | Vorhaben „Spagat können“ anlegen, Starter-Kit | Vorhaben → Neu | ☐ |
| 2 | Operating Context: `maturity_stage`, `recurring_rhythm` | API oder Kontrolle | ☐ |
| 3 | Kontrolle: Stufen-Panel + Rhythmen + Next Action | `/control/status` | ☐ |
| 4 | Ausführen: Next Action sichtbar, Liste eingeklappt | `/work/today` | ☐ |
| 5 | Evidence an Stufe 1, Verify → Stufe 2 aktiv | Plan → Stufen / Journey | ☐ |
| 6 | Recurring rotiert (alte Übung pausiert, neue aktiv) | Kontrolle / Rhythmen | ☐ |
| 7 | Journey zeigt Stufen-Event | `/control/journey` | ☐ |
**Technische Referenz:** `backend/tests/test_ap22c_maturity_e2e.py`
### 3.2 MVP-Nutzbarkeits-Bar (§5)
| # | Kriterium | ja/nein | Notiz |
|---|-----------|---------|-------|
| 1 | Anlage + Default-Methode | | |
| 2 | Stufen + Recurring strukturiert | | |
| 3 | Ist committet (Übung/Routine, nicht 200 Tasks) | | |
| 4 | Kontrolle: Next Action begründet (Rhythmus/Stufe) | | |
| 5 | Journey ≥1 Event | | |
| 6 | Leitfrage ≤2 Min ohne Listen-Wand | | |
### 3.3 Leitfrage-Antwort (PO, ≤2 Min)
**Nächster Schritt:**
**Warum:**
**Stopuhr (Min):**
### 3.4 Anti-Patterns (§7)
| Verboten | aufgetreten? | Notiz |
|----------|--------------|-------|
| Flache Liste aller Übungs-Tasks als Hauptbild | ☐ ja ☐ nein | |
| Recurring im Action-Backlog statt Rhythmus-Ansicht | ☐ ja ☐ nein | |
**Lücken / UX-Schmerz:**
---
## 4. Szenario A2 — Neue Küche (Linear)
**Initiative-ID / Titel:**
**Archetyp:** `initiative.linear_project` · **Methode:** `sequential_dependency`
### 4.1 Smoke-Schritte (Dev)
| # | Schritt | Route | erledigt |
|---|---------|-------|----------|
| 1 | Vorhaben „Neue Küche“ anlegen, Starter-Kit | Vorhaben → Neu | ☐ |
| 2 | Gate-Kette G1–G4, G1 aktiv | Plan → Zielzustände | ☐ |
| 3 | Projekte Hauptpfad + Begleitung vorhanden | Plan | ☐ |
| 4 | Kontrolle: Kritischer Pfad + Next Action | `/control/status` | ☐ |
| 5 | Ersten Schritt erledigen → nächster ready am Pfad | Ausführen / AP-Detail | ☐ |
| 6 | Gate-Verify / reached wo sinnvoll | Plan / Gates | ☐ |
| 7 | Ausführen: Steuerung, nicht alle Handwerker-Tasks | `/work/today` | ☐ |
**Technische Referenz:** `backend/tests/test_ap22b_linear_e2e.py`
### 4.2 MVP-Nutzbarkeits-Bar (§5)
| # | Kriterium | ja/nein | Notiz |
|---|-----------|---------|-------|
| 1 | Anlage + sequential_dependency | | |
| 2 | Gate-Kette + Abhängigkeiten | | |
| 3 | APs committet, nicht Backlog-Wand | | |
| 4 | Kontrolle: kritischer Pfad / ready Schritt begründet | | |
| 5 | Journey / Gate-Fortschritt sichtbar | | |
| 6 | Leitfrage ≤2 Min | | |
### 4.3 Leitfrage-Antwort (PO)
**Nächster Schritt:**
**Warum:**
**Stopuhr (Min):**
### 4.4 Anti-Patterns
| Verboten | aufgetreten? | Notiz |
|----------|--------------|-------|
| Alle Handwerker-Schritte als flache Todo-Liste | ☐ ja ☐ nein | |
| Gate nur Status-Dropdown ohne Steuerung | ☐ ja ☐ nein | |
**Lücken:**
---
## 5. Szenario B2b + B3 — Product + Sprint
**Initiative-ID / Titel:**
**Archetyp:** `initiative.product` · **Methode:** `continuous_product` (+ optional `agile_iteration`)
### 5.1 Smoke-Schritte B2b (Dev)
| # | Schritt | Route | erledigt |
|---|---------|-------|----------|
| 1 | Product-Vorhaben anlegen (Starter-Kit) | Vorhaben → Neu | ☐ |
| 2 | Eingang: Backlog-Item anlegen / triagieren | Plan → Eingang | ☐ |
| 3 | Gate/Meilenstein als Orientierung | Plan → Zielzustände | ☐ |
| 4 | Kontrolle: Next Action (Product-Horizont) | `/control/status` | ☐ |
| 5 | Prozessleiste: Eingang → Sprint planen → Ausführen | Scope-Navigation | ☐ |
### 5.2 Smoke-Schritte B3 (Sprint minimal)
| # | Schritt | Route | erledigt |
|---|---------|-------|----------|
| 6 | Sprint anlegen (geplant oder aktiv) | Plan → Sprint | ☐ |
| 7 | Backlog-Items in gewählten Sprint committen | Plan → Sprint (Checkbox / Vorschlag) | ☐ |
| 8 | Sprint-Backlog sichtbar getrennt vom Product Backlog | Plan → Sprint / Ausführen → Sprint | ☐ |
| 9 | Ausführen: Next Action im Sprint, Liste Drill-down | `/work/sprint` | ☐ |
| 10 | Optional: Sprint abschließen / Carryover | Sprint-Panel | ☐ |
**Technische Referenz:** `backend/tests/test_ap22d_sprint_backlog.py`, `test_ap22i_sprint_commit_proposal.py`
### 5.3 MVP-Nutzbarkeits-Bar (§5)
| # | Kriterium | ja/nein | Notiz |
|---|-----------|---------|-------|
| 1 | Anlage + continuous_product | | |
| 2 | Eingang + Gates + Sprint-Struktur | | |
| 3 | Product Backlog ≠ Sprint-Backlog ≠ committete APs | | |
| 4 | Kontrolle: Next Action Gate **oder** Sprint begründet | | |
| 5 | Journey / Sprint-Lifecycle Event | | |
| 6 | Leitfrage ≤2 Min | | |
### 5.4 Leitfrage-Antwort (PO)
**Nächster Schritt:**
**Warum:**
**Stopuhr (Min):**
### 5.5 Anti-Patterns
| Verboten | aufgetreten? | Notiz |
|----------|--------------|-------|
| Alle APs aller Gates gleichzeitig in Hauptliste | ☐ ja ☐ nein | |
| Sprint-Backlog = Product Backlog | ☐ ja ☐ nein | |
| Ausführen zeigt Gesamtliste statt Sprint-Default | ☐ ja ☐ nein | |
| Begriff „Zeitbox“ statt Sprint in UI | ☐ ja ☐ nein | |
**Lücken:**
---
## 6. Querschnitt — Composition & Product Language
| Check | ja/nein | Notiz |
|-------|---------|-------|
| MethodProcessBar zeigt Prozess (Product: Eingang→Sprint→Ausführen) | | |
| Work-Modus: Next Action vor voller AP-Liste | | |
| Begriffe konsistent (Sprint, Arbeitspaket, Eingang) | | |
| Keine Archetyp-Ifs spürbar (Steuerung methodengebunden) | | |
---
## 7. Op-API (AP1.7b — Stichprobe)
Optional: Agent/Service-Token gegen Dev.
| Endpoint | funktioniert | Notiz |
|----------|--------------|-------|
| `GET /api/operational/initiatives/{id}/context` | ☐ | |
| `GET /api/operational/next-action?initiative_id=` | ☐ | |
| `POST /api/operational/backlog/{id}/convert-to-action` | ☐ | |
---
## 8. Abgeleitete Prioritäten (nach Validation)
| Prio | Lücke | Fix-AP / Slice |
|------|-------|----------------|
| P0 | | |
| P1 | | |
| P2 | | |
---
## 9. Sign-off
| Rolle | Name | Datum | Go Stufe A |
|-------|------|-------|------------|
| Product Owner | | | ☐ ja ☐ nein ☐ bedingt |
**Bedingungen (falls bedingt):**
---
*Bei Go: Truth Table `AP2.1` → ✓, Execution Plan Phase 5 → ✓, dann Merge `develop` → `main` für Prod.*