Kairo-Jinkendo/docs/product/Kairo_MVP_Definition_v0.3.md

Jinkendo Kairo

MVP Definition v0.3

Status: PO-freigegeben (bezogen auf ADP_Archetype_and_Method_Catalog_v0.2.md)
Stand: 2026-07-10
Auslöser: Programm-Director-Ziel vs. flache Vorhabenliste; private und professionelle Vorhaben gleichwertig; Steuerung vor Status-Monitoring; Agile vollständig (Backlog ✓, Sprint/Iteration ○)
Bezug: Kairo_Vision_and_Product_Direction_v0.2.md, Kairo_Canonical_Operating_Model_v0.2.md, ADP_Archetype_and_Method_Catalog_v0.2.md
Ersetzt als MVP-Nordstern: implizite Annahme „MVP = Software-Programm mit Gates + Tasks“ in Sprint-Delivery; nicht die technische Roadmap v0.2 (bleibt Referenz für AP-Reihenfolge)

---

1. Nordstern

Kairo ist der operative Program Director — nicht ein To-do-Tool.

Leitfrage (unverändert):

Welcher nächste Schritt bringt dieses Vorhaben jetzt am wirksamsten voran — und warum?

Der MVP ist erreicht, wenn ein Nutzer mehrere typische Vorhabenarten (privat und professionell) in Kairo erfassen, steuern und nachvollziehen kann — ohne dass die Oberfläche in unendliche To-do-Listen kollabiert.

---

2. Was der MVP ist und nicht ist

MVP ist

• Steuerung sichtbar: Methode, Lifecycle, Attention, Next Action (begründet) — nicht nur Status-Ampeln
• Schichtenmodell: Framework → Methode (Registry) → Archetyp (Baukasten) → Ausprägung (z. B. Buch, Kumite) — siehe ADP §2.0
• Archetyp-gesteuert: Vorhaben- und Projekt-Typ bestimmt Default-Methode, Felder, dominante Modus-Ansichten
• Plan vs. Ist getrennt: Eingang ≠ committete Arbeit; Recurring ≠ Backlog; Product Backlog ≠ Sprint-Backlog
• Agile zweigleisig: Release-Horizont (Gates, B2) und Iterations-Horizont (Sprint/work_cycle, B3) — komponierbar
• Referenz-Portfolio: mehrere Vorhaben unterschiedlicher Typen parallel im Tenant, davon 2–3 voll durchspielbar
• Historie: Journey als steuerungsrelevante Narrative (inkl. rückwirkender Erfassung wichtiger Ereignisse)

MVP ist nicht

• Vollständiger Import aus externen Tools
• Tenant-Admin-UI für Archetyp-Designer
• KI/Prompt/Workflow/MCP (bleibt eingefroren)
• Alle Archetypen gleichzeitig voll implementiert — Katalog ja, Vollimplementierung gestaffelt
• Kanban-Board, Velocity, Burndown als Kern
• Gantt-/Capacity-Planung
• Ersatz für Mitai/Shinkan oder Rechts-/Gesundheits-Spezialsoftware

---

3. Anti-Patterns (explizit verboten im MVP-Slice)

Verboten	Warum
Hauptbild = flache Liste aller offenen Actions/Tasks	Todo-Explosion; widerspricht Program Director
Archetyp nur als Formular-Label ohne Methode/Steuerung	Täuscht Vielfalt vor
Annahme „Vorhaben = Software-Release“	schließt private Vorhaben aus
Sprint-Backlog als BacklogItem-Liste	Sprint = committete Actions am work_cycle
Plan-Modus ausbauen ohne Kontrolle/Steuerung	Monitoring ohne Begleitung
Neue OM-Tabellen pro Archetyp (sprints, habits, …)	Scope Lock — Method Registry + EFS + OM
Steering-Logik in Routern oder Frontend hardcoden	nur backend/steering/ + Registry

---

4. Referenz-Portfolio (Archetyp-Katalog)

Vollständige Matrix: ADP_Archetype_and_Method_Catalog_v0.2.md §3.

ID	Typ	Beispiel	Default-Methode	Agile-Bezug
A1	Reifegrad	Spagat können	maturity_progression	—
A2	Linear / Wasserfall	Neue Küche	sequential_dependency	—
A3	Dauerprogramm / Rhythmus	Haus in Ordnung	recurring_control	—
B1	Queue / Supportdesk	Tickets	queue_pull	Pull statt Board
B2a	Programm (begrenzt)	Release-Programm	program_delivery	Release + Abschluss
B2b	Produkt (kontinuierlich)	Kairo, Betrieb	continuous_product	Dauerbetrieb + Issues
B3	Sprint-Zeitbox (Profil, kein Archetyp)	PO + Vibe-Coder	agile_iteration	Zeitbox auf B2b
C1	Verfahren / Konflikt	Miterstreit	dispute_procedure	reaktiv, Katalog
D1	Inhalt / Kapitel	Buch, Konzept	chapter_based_progression	Stufe B

B2a vs B2b vs B3 (PO 2026-07-10)

• Programm: Ziel, Phasen, Abschluss — z. B. Release-Programm
• Product: Kein fixes Ende — Wartung, Issues, Weiterentwicklung; Kairo selbst = Product
• Sprint: Kein eigener Vorhaben-Typ — work_cycle auf Product/Programm; nahe an Arbeitspaket-Zeitbox

MVP-Abnahfe-Priorität

Stufe	Archetypen	Bedeutung
Abnahfe A	A1, A2, B2b (+ B3 minimal auf Kairo-Product)	Reifegrad, Linear, Kairo Product + optional Sprint
Abnahfe B	A3, B1, D1, B3 ausgebaut	Haushalt-Score (AP2.0g), Inbox/Queue, Buch
Katalog C	C1	Miterstreit — Spezifikation, nicht MVP

---

5. MVP-Nutzbarkeits-Bar (v0.3)

Kairo ist MVP-nah, wenn ein Nutzer pro Archetyp der Stufe A:

1. Ein Vorhaben anlegt (Initiative-Archetyp, Default-Methode, Profil/EFS)
2. Die passende Struktur modelliert (Reifegrad-Stufen / Gate-Kette / Sprint-Zyklen — methodenabhängig)
3. Ist committet (Actions, Tasks, Recurring — nicht alles gleichzeitig sichtbar)
4. In Kontrolle den Lagebild-Steuerungskern sieht: Lifecycle, Methode, 1–3 Next Actions, Attention — mit Begründung
5. In Journey Entwicklung und Abweichungen nachvollzieht (min. 5 steuerungsrelevante Events, auch rückwirkend)
6. Ohne CRUD-Wand in ≤2 Minuten die Leitfrage für dieses Vorhaben beantworten kann

Portfolio-Ebene (zusätzlich):

7. Auf Cockpit sieht, welches Vorhaben welche Art von Attention braucht — nicht Details aller offenen Tasks

---

6. Steuerung vs. Monitoring

Monitoring (reicht nicht)	Steuerung (MVP-Pflicht)
„12 offen“	„Nächster Schritt: X, weil Gate Y blockiert / Stufe Z / Sprint endet Freitag“
Status-Dropdown	Lifecycle-Übergang + Methode
Alle Tasks listen	Recurring: heute fällig; Queue: nächster Pull; Reifegrad: aktuelle Übung; Sprint: 1–3 Items im aktiven Zyklus
Journey als Archiv	Journey + Decision als Plan-Abweichung
Product Backlog als Hauptliste	Sprint-Modus: nur Sprint-Backlog als Default

Technische Anker: steering_context.method_key, backend/steering/, NextActionCandidate, AttentionItem, Method Registry, actions.work_cycle_id (AP2.0f).

---

7. Todo-Explosion verhindern (verbindliche UI-Regeln)

1. Default-Ansicht pro Methode zeigt Next Action (1–3), nicht Gesamtbestand
2. Recurring erscheint in Rhythmus-Ansicht, nicht im Action-Backlog
3. Backlog/Eingang (Product Backlog) getrennt von committeter Arbeit und von Sprint-Backlog
4. Plan (Gates, Graph, Stufen, Sprints) = Orientierung; Ist = Ausführung
5. Drill-down zu vollen Listen nur auf explizite Nutzeraktion („Alle anzeigen“)
6. Scope: Portfolio → Vorhaben → Projekt filtert sichtbare Operative
7. Aktiver Sprint: Ausführen-Modus default = Sprint-Backlog, nicht Product Backlog

---

8. Abnahme-Szenarien (konkret)

A1 — Spagat (Reifegrad)

• Stufen als maturity_stage RoadmapItems
• Recurring-Übungen; bei Stufenübergang andere Routine
• Kontrolle: aktuelle Stufe + heutige Übung + Kriterium bis nächste Stufe
• Nicht: 200 Übungs-Tasks in der Hauptliste

A2 — Küche (Wasserfall)

• Primärstrang mit Abhängigkeiten (Graph oder sequenzielle Liste)
• Begleitprojekte parallel
• Kontrolle: kritischer Pfad / nächster blockierender Schritt
• Nicht: alle Handwerker-Schritte als flache Todo-Liste

B2b — Kairo (Product, kontinuierlich)

• Gates/Meilensteine als Orientierung; Backlog im Eingang; Issues/Betrieb als Dauer-Thema
• Optional: work_cycle (Sprint-Zeitbox) für PO + Vibe Coder
• Kontrolle: Next Action im aktiven Horizont (Gate oder Sprint) — begründet
• Nicht: alle APs aller Gates gleichzeitig in der Hauptliste

B3 — Sprint-Zeitbox (Profil auf Product, kein eigener Archetyp)

• Optional ein aktiver work_cycle; 1–3 Actions in der Zeitbox
• Kairo-Steuerung statt Scrum-Master-Rolle
• Nicht: Team-Board, Velocity

D1 — Buch / Konzept (Stufe B)

• Kapitel als chapter RoadmapItems; mindestens ein Schreib-AP committet
• Kontrolle: nächstes Kapitel / aktuelles Schreib-AP

---

9. Implementierungsfolge (nach PO-Freigabe dieses Dokuments)

Kein weiterer „Plan-Modus-Politur“-Slice ohne Steuerungs-Bezug.

1. ADP Archetype & Method Catalog v0.2 — ✓ PO-freigegeben 2026-07-10
2. AP2.0a  Method Registry: Stubs inkl. program_delivery, continuous_product, agile_iteration
3. AP2.0b  Archetyp-Seeds (Initiative + Project Spiegel); EFS; Referenz-Ausprägungen (Kumite, Buch, Kairo)
4. AP2.0c  Kontrolle/Lagebild: Methode + Next Action + Attention (Hauptfläche)
5. AP2.0d  Next-Action-Strategien: maturity, sequential, recurring, queue (minimal)
6. AP2.0f  work_cycle + actions.work_cycle_id; Sprint auf Product; agile_iteration Profil
7. AP2.0g  A3 Score + freiwillige Übernahme (Stufe B+)
8. AP2.1    Referenz-Abnahme A1, A2, B2b (+ B3 minimal), D1 (Validation v0.3)
9. Parallel wenn tragfähig: AP1.13 Gate-Graph für A2/B2 — nicht Default für alle

Bestehende APs (1.12, 1.10, 1.5d) bleiben Infrastruktur — werden im MVP v0.3 erst wertvoll, wenn 2.0c/2.0d/2.0f sie archetyp- und methodengebunden nutzen.

---

10. Dokumentenpriorität bei Konflikten

Bei MVP-Fragen gilt:

1. Dieses Dokument (v0.3) + ADP_Archetype_and_Method_Catalog_v0.2.md
2. Kairo_Vision_and_Product_Direction_v0.2.md
3. Kairo_Canonical_Operating_Model_v0.2.md
4. Kairo_Corrected_MVP_Roadmap_v0.2.md (AP-Reihenfolge, technisch)
5. Sprint Completion Reports (historisch)

---

11. PO-Freigabe

• Nordstern und Anti-Patterns akzeptiert
• Referenz-Portfolio A1–D1 als Katalog akzeptiert
• Vier-Schichten-Modell (ADP §2.0) akzeptiert
• B2a/B2b + B3-Profil; Project-Spiegel-Modell akzeptiert
• Abnahfe Stufe A = A1 + A2 + B2b + B3-minimal; Stufe B = A3, B1, D1
• Sprint-Semantik (Product Backlog vs. Sprint-Backlog) akzeptiert
• Implementierungsfolge §9 akzeptiert
• Kein MVP-Fortschritt mehr ohne sichtbare Steuerung pro Archetyp

---

Referenzen

• docs/architecture/ADP_Archetype_and_Method_Catalog_v0.2.md
• docs/architecture/Kairo_Method_Design_Principles_v0.1.md
• docs/architecture/Kairo_Target_Architecture_Method_Driven_Adaptive_Steering_Core_v0.1.md
• docs/product/Kairo_Implementation_Truth_Table_v0.1.md