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

```text
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

- [x] Nordstern und Anti-Patterns akzeptiert
- [x] Referenz-Portfolio A1–D1 als Katalog akzeptiert
- [x] Vier-Schichten-Modell (ADP §2.0) akzeptiert
- [x] B2a/B2b + B3-Profil; Project-Spiegel-Modell akzeptiert
- [x] Abnahfe Stufe A = A1 + A2 + B2b + B3-minimal; Stufe B = A3, B1, D1
- [x] Sprint-Semantik (Product Backlog vs. Sprint-Backlog) akzeptiert
- [x] Implementierungsfolge §9 akzeptiert
- [x] 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`
- `docs/product/Kairo_Status_Review_and_Next_Steps_v0.1.md`
- `docs/product/Kairo_Dogfooding_Mirror_Steering_v0.1.md`