# 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 ✓ Phase 2 AP1.9d Methoden-Default-Ansichten (Anti-Todo-Wand) ◐ (Hints + Recurring) Phase 3 AP2.2b A2 Linear End-to-End ◐ AP2.2c A1 Reifegrad + AP2.0e ◐ Code 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`, **`Kairo_Session_Handover_2026-07-12.md`** (Session-Feedback & Stop-Regeln)*