Archetyp-Profile und Seitenlogik auf Operating Context migriert; methodUiDefaults nur noch Fallback. Co-authored-by: Cursor <cursoragent@cursor.com>
7.3 KiB
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)
Spezifikationsphase (ab 2026-07-24): Kairo_Archetype_Specification_Program_v0.1.md + docs/product/archetypes/ — Spec vor neuem Archetyp-Code (Welle 2+); ersetzt diesen Plan nicht
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 ✓
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:
Kairo_MVP_Definition_v0.3.md- Dieses Dokument (Execution Plan v0.2)
ADP_Archetype_and_Method_Catalog_v0.2.mdKairo_Corrected_MVP_Roadmap_v0.2.md(AP-Historie)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)