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

# Jinkendo Kairo
## MVP Execution Plan v0.2

**Status:** PO-Kurskorrektur — **führend für Implementierung ab 2026-07-12**  
**Stand:** 2026-07-12  
**Ersetzt als Priorisierung:** Dogfooding-Seed als Implementierungs-Hebel; Status-Review §5 (Dogfooding-first)  
**Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–9, `ADP_Archetype_and_Method_Catalog_v0.2.md` §3, `Kairo_Corrected_MVP_Roadmap_v0.2.md` (AP-Historie)

---

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

### 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)                    ← jetzt
Phase 1   AP2.2a  Archetyp-geführte Anlage + Starter-Kits           ← NÄCHSTES CODE
Phase 2   AP1.9d  Methoden-Default-Ansichten (Anti-Todo-Wand)       parallel möglich
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)
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)

**Nicht:** ein Dogfooding-Vorhaben auf Pi.  
**Sondern:** PO füllt Report mit **echten, in der UI angelegten** Referenz-Vorhaben:

- A1 (Reifegrad)
- A2 (Linear)
- B2b (+ optional B3 Zeitbox)
- D1 wenn Stufe B bis dahin fertig

Vorlage: `docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` (neu bei AP2.1)

Go-Kriterium: MVP v0.3 §5 — pro Stufe-A-Archetyp Leitfrage ≤2 Min + Next Action begründet.

---

## 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`*