Kairo-Jinkendo/docs/product/Kairo_MVP_Execution_Plan_v0.2.md

177 lines
8.2 KiB
Markdown
Raw Permalink Normal View History

# Jinkendo Kairo
## MVP Execution Plan v0.2
**Status:** PO-Kurskorrektur — **führend für Implementierung ab 2026-07-12**
**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)
**Spezifikationsphase (ab 2026-07-24/25):**
- Decision-Lock: `Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`
- **Jetzt:** Methoden-Normierung `docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md` (auf AP2.3/AP2.4)
- Danach: Archetyp-Vollspecs — ersetzt diesen Plan nicht
---
## 1. Nordstern (unverändert)
Kairo ist MVP-nah, wenn ein Nutzer **mehrere typische Vorhabenarten** (Referenz-Portfolio) **erfassen, steuern und nachvollziehen** kann — archetyp- und methodengebunden, ohne Todo-Explosion.
**Nicht MVP-Ziel:** Kairo-Entwicklungsstand in Kairo spiegeln (Dogfooding-Seed). Das war nur Dev-Visualisierung.
---
## 2. Referenz-Portfolio — Checkliste pro Archetyp
Legende: **Anlage** · **Struktur** · **Ist** · **Kontrolle** · **UI-Default** · **Op-API**
| ID | Archetyp | Beispiel | Methode | Stufe | Anlage | Struktur | Ist | Kontrolle | UI-Default | Op-API |
|----|----------|----------|---------|-------|--------|----------|-----|-----------|------------|--------|
| A1 | `initiative.maturity_journey` | Spagat / Kumite | `maturity_progression` | **A** | ◐ | ◐ | ◐ | ◐ | ✗ | ◐ |
| A2 | `initiative.linear_project` | Neue Küche | `sequential_dependency` | **A** | ◐ | ◐ | ◐ | ◐ | ✗ | ◐ |
| A3 | `initiative.recurring_program` | Haus in Ordnung | `recurring_control` | B | ◐ | ✗ | ◐ | ◐ | ✗ | ◐ |
| B1 | `initiative.support_queue` | Tickets | `queue_pull` | B | ◐ | ✗ | ◐ | ◐ | ✗ | ◐ |
| B2a | `initiative.program` | Release-Programm | `program_delivery` | A* | ◐ | ◐ | ◐ | ◐ | ✗ | ◐ |
| B2b | `initiative.product` | Product-Betrieb | `continuous_product` | **A** | ◐ | ◐ | ◐ | ◐ | ✗ | ◐ |
| B3 | *(Profil auf B2)* | Sprint-Zeitbox | `agile_iteration` | **A min** | ◐ | ◐ | ◐ | ◐ | ✗ | ◐ |
| D1 | `initiative.content_project` | Buch schreiben | `chapter_based_progression` | B | ◐ | ✗ | ◐ | ◐ | ✗ | ◐ |
| C1 | `initiative.dispute_case` | Miterstreit | `dispute_procedure` | C | Katalog | — | — | — | — | — |
\* B2a in ADP Stufe A; MVP v0.3 §4 nennt explizit A1, A2, B2b + B3 — B2a im Validation-Slice mitdenken.
**Ausprägungen (Code-Seeds):** `maturity.karate_kumite`, `content.book_writing`, `product.kairo_dev` — Vorlagen, **kein** Ersatz für Nutzer-Anlage.
---
## 3. Was technisch da ist vs. was fehlt
### 3.1 Vorhanden (Infrastruktur — nicht wiederholen)
- OM, Gates, Graph Engine, Plan-Outline, Journey, Plan/Ist-Diff
- Archetyp-Registry, EFS, Profil-Modal (AP1.10c)
- PM Work Modes Shell (AP1.9a), Cockpit-Signale (AP1.9c)
- Next-Action-Strategien registriert (AP2.0d)
- Execution-Graph / `ready_actions` (AP1.16)
- `work_cycle` + `actions.work_cycle_id` (AP2.0f)
- Operational Actor API + Service Tokens (AP1.7)
- **Plugin-Architektur AP2.3/AP2.4:** Operating Context, Slice-Loader, Route Gating, Steuerungselement-Registry, Methoden-Vertrag
### 3.2 Produkt-Lücken (MVP-kritisch)
| Lücke | Bedeutung | Paket |
|-------|-----------|-------|
| Archetyp-geführte Anlage | Nutzer wählt Typ → sinnvolle Startstruktur + Guidance | **AP2.2a** |
| Methoden-Default-UI | Ausführen/Kontrolle zeigt Next Action, nicht Gesamtliste | **AP1.9d** |
| A1 Stufenwechsel + Recurring | AP2.0e: Routine wechselt bei `maturity_stage` reached | **AP2.0e** |
| A2 kritischer Pfad | Kontrolle aus sequential + Graph Read Model | **AP2.2b** |
| B2b Eingang → Commit | Product Backlog vs. Sprint-Backlog sichtbar getrennt | **AP2.2d** |
| B3 Sprint-Default | Aktiver `work_cycle`; Ausführen = Sprint-Items | **AP2.2d** |
| `chapter` RoadmapItem | D1 Plan-Schicht | **AP2.2f** (Stufe B) |
| Structure Builder (voll) | Automatische Tiefenplanung | **deferred** — Starter-Kits stattdessen |
| Op-API Parität | Agent pflegt dasselbe wie UI | **AP1.7b** |
| Referenz-Validation | AP2.1 über A1, A2, B2b (+ B3), D1 | **AP2.1** |
---
## 4. Implementierungsfolge (korrigiert)
```text
Phase 0 DOC + Kurskorrektur (dieses Dokument) ✓
Phase 0b AP2.3/AP2.4 Plugin-Architektur (Archetyp ↔ Methode) ✓
Phase 1 AP2.2a Archetyp-geführte Anlage + Starter-Kits ✓
Phase 1b Specs Welle 1 finalisieren (A1,A2,B2a,B2b,B3) ◐
Phase 2 AP1.9d Methoden-Default-Ansichten (Anti-Todo-Wand) ◐→✓ (Work-Composition + Drill-down)
Phase 3 AP2.2b A2 Linear End-to-End ✓
AP2.2c A1 Reifegrad + AP2.0e ✓
AP2.2d B2b Product + B3 Sprint ✓
AP2.2e B2a Programm (optional vor AP2.1)
Phase 4 AP1.7b Operational API — Pflege-Parität ✓
Phase 5 AP2.1 Validation Report v0.3 (alle Stufe-A-Szenarien) ◐ PO
Phase 6 AP2.2f Stufe B: A3, B1, D1
Phase 7 Schicht 4: Gitea-Webhook, MCP (nach AP2.1 Go)
```
**Eingefroren / deprecated:**
- `seed_004_dogfooding_*` — nur Dev-Visualisierung, **kein** Produkt-AP
- Dogfooding als „nächster strategischer Hebel“ in Roadmaps
---
## 5. AP2.2 — Referenz-Vorhaben (Paketübersicht)
| Paket | Ziel | DoD-Kern |
|-------|------|----------|
| **AP2.2a** | Geführte Anlage | Archetyp-Wahl → Starter-Kit + 1-Satz-Guidance; Ausprägung wählbar |
| **AP2.2b** | A2 Küche | Gate-Kette/Graph anlegbar; Kontrolle: nächster ready Schritt + Begründung |
| **AP2.2c** | A1 Spagat/Kumite | `maturity_stage` + Recurring; AP2.0e bei Stufenübergang |
| **AP2.2d** | B2b + B3 | Eingang, Gates, optional aktive Zeitbox; Sprint-Backlog in Ausführen |
| **AP2.2e** | B2a Programm | `program_delivery`, Abschluss-Lifecycle, Gate-Horizont |
| **AP2.2f** | D1 Buch (B) | `chapter` item_type; nächstes Kapitel in Kontrolle |
Assignment AP2.2a: `docs/sprints/Sprint1_AP2_2a_Archetype_Guided_Creation_Assignment_v0.1.md`
---
## 6. Operational API (Vibe-Coder) — Scope
AP1.7 liefert Kern-Endpoints. **AP1.7b** ergänzt Parität:
| Fähigkeit | UI | Op-API heute | AP1.7b |
|-----------|-----|--------------|--------|
| Context / Next Action | ✓ | ✓ | — |
| Action Status | ✓ | ✓ | — |
| Evidence anlegen | ✓ | ✓ | — |
| Blocker melden | ✓ | ◐ | ✓ |
| Backlog → Action committen | ✓ | ✗ | ✓ |
| Recurring status | ✓ | ✗ | ✓ |
| work_cycle zuweisen | ✓ | ◐ | ✓ |
Auth: Actor Service Token (Tenant-scoped). Kein Gate-Verify, kein Lifecycle-Override über Op-API.
---
## 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.
**Sondern:** PO füllt Report mit **echten, in der UI angelegten** Referenz-Vorhaben:
- A1 (Reifegrad)
- A2 (Linear)
- B2b (+ B3 Sprint minimal)
- D1 optional (Stufe B)
| 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; Portfolio Cockpit-Attention (Kriterium 7).
**Findings-Register (PO-Smoke + Architektur-Review):** `docs/sprints/Sprint1_AP2_1_Validation_Findings_Register_v0.1.md`
---
## 8. Dokumentenpriorität
Bei Konflikten:
1. `Kairo_MVP_Definition_v0.3.md`
2. **Dieses Dokument** (Execution Plan v0.2)
3. `ADP_Archetype_and_Method_Catalog_v0.2.md`
4. `Kairo_Corrected_MVP_Roadmap_v0.2.md` (AP-Historie)
5. `Kairo_Dogfooding_Mirror_Steering_v0.1.md` (optional, Dev-only)
---
## 9. PO-Freigabe (offen)
- [ ] Execution Plan v0.2 als führende Priorisierung
- [ ] Dogfooding-Seed deprecated
- [ ] AP2.2a als nächstes Code-Paket
---
*Siehe auch: `Kairo_Implementation_Truth_Table_v0.1.md` § Referenz-Archetypen, `Kairo_Status_Review_and_Next_Steps_v0.2.md`, **`Kairo_Session_Handover_2026-07-12.md`** (Session-Feedback & Stop-Regeln)*