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)

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