Kairo-Jinkendo/docs/product/Kairo_Canonical_Operating_Model_v0.2.md

# Jinkendo Kairo
## Canonical Operating Model v0.2

**Status:** kanonisches Fachmodell  
**Stand:** 2026-07-05  
**Ersetzt:** `Kairo_Canonical_Operating_Model_v0.1.md` bei Konflikten  
**Führende Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md`

---

## 1. Zweck

Dieses Dokument definiert das **kanonische Operating Model** — inklusive Plan/Ist-Trennung, Quality Gates und Navigationsprinzipien.

Es verhindert:

- Reduktion auf `Initiative → Action`
- Meilensteine als Task-Listen
- CRUD-Omnibus-Seiten als Steuerungs-UI
- Verwechslung von **implementiertem** und **zielbildlichem** Stand

**Implementierungsstand:** `Kairo_Implementation_Truth_Table_v0.1.md`

---

## 2. Leitfrage

> Welcher nächste Schritt bringt diesen steuerbaren Kontext jetzt am wirksamsten voran?

Gilt auf **Ausführungs-Ebene** (Workspace, Next Action) und **Programm-Ebene** (Plan, Gates, Abweichungen).

---

## 3. Operating Cycle

Unverändert im Kern:

```text
Capture → Triage → Structure → Commit → Execute → Verify → Review → Adapt → Next Action
```

**Neu in v0.2 — klare Zuordnung:**

| Phase | Primäre Objekte | Primäre UI-Fläche |
|-------|-----------------|-------------------|
| Capture | BacklogItem, Blocker (Meldeeingang) | Eingang |
| Triage | BacklogItem | Eingang |
| Structure | RoadmapItem, Project | Plan |
| Commit | Action (+ Assignment) | Ausführung |
| Execute | Action, Task (später) | Ausführung / Workspace |
| Verify | Evidence | Objekt-Detail |
| Review | Review | Nachvollziehbarkeit |
| Adapt | Decision, RoadmapItem-Änderung | Plan + Nachvollziehbarkeit |
| Next Action | NextActionCandidate | Workspace + Steuerung |

---

## 4. Objektmodell (Ziel)

```text
Tenant
  └── Actor
        └── Initiative (Programm)
              ├── Project optional
              ├── Roadmap
              │     └── RoadmapItem (milestone | maturity_stage | feature | review_gate | …)
              │           └── Dependencies → andere RoadmapItems
              ├── BacklogItem ──zahlt ein auf──► RoadmapItem
              ├── Action (Arbeitspaket / committete operative Einheit)
              │     ├── Task optional (später)
              │     ├── ActionAssignment
              │     ├── Blocker
              │     └── Evidence
              ├── Decision (Plan-Abweichung, Scope, Priorität)
              ├── Review
              ├── RecurringElement
              └── AttentionItem / NextActionCandidate (Read Models)
```

### 4.1 MVP-Brücke (aktuell implementiert — nicht Ziel)

```text
Initiative
  ├── milestones (eigene Tabelle — ersetzbar durch RoadmapItem)
  ├── backlog_items, actions, blockers, evidence, decisions, reviews, recurring
  └── steering_context (Lifecycle, Method)
```

Die Brücke ist **technisch nutzbar**, **fachlich unzureichend** für Gates und Plan/Ist.

---

## 5. Plan-Struktur vs. Ist-Struktur

### Plan (Roadmap)

- Entwicklungsrichtung und **überprüfbare Zielpunkte**
- RoadmapItems mit DoD, Abhängigkeiten, Terminen
- Kann sequenziell, parallel oder gemischt sein

### Ist (Operativ)

- Committete **Actions** mit Status, Assignments, Blockern, Evidence
- Entsteht durch **Commit** aus Backlog — nicht durch Roadmap-Deklaration allein

### Abweichung

- **Decision** dokumentiert: Plan ignoriert, verschoben, ersetzt
- Journey/Timeline zeigt Abweichungen über die Zeit

---

## 6. Objektdefinitionen (erweitert)

### Initiative

Aktives Vorhaben / Programm mit Zielzustand, Lifecycle, Steuerungsmethode.

### Project

Optionale Unterstruktur — z. B. Stream, Teilprojekt, Release-Track.

### RoadmapItem

**Geplanter** Entwicklungsschritt oder **Quality Gate**.

Typen (Auswahl): `milestone`, `maturity_stage`, `feature`, `review_gate`, `chapter`, `work_cycle`, …

**Pflicht im Zielbild (nicht heute):**

- prüfbare Kriterien (DoD)
- optional Abhängigkeiten
- Verifikation vor Status `reached`

### Milestone (Product-Begriff)

= RoadmapItem mit Gate-Charakter. **Kein Task.**

### BacklogItem

Noch **nicht committeter** Handlungsbedarf. Kann auf RoadmapItem einzahlen.

### Action (Product: Arbeitspaket)

**Freigegebene** operative Einheit. Im heutigen UI „Maßnahme“.

Im Zielbild oft **Projekt- oder Paket-Ebene**, nicht atomare Aufgabe.

### Task (geplant)

Kleinste ausführbare Einheit unter Action — methodenabhängig (WBS).

### Blocker / Evidence / Decision / Review

Wie v0.1; Evidence und Review sind **Gate-Verifikation** wesentlich.

### NextActionCandidate / AttentionItem

Read Models — keine parallele Steuerungslogik außerhalb `backend/steering/`.

---

## 7. Quality Gate — Mindestanforderungen

Ein Gate (Meilenstein) ist erst **modellgerecht**, wenn:

| # | Anforderung |
|---|-------------|
| 1 | DoD / prüfbare Kriterien definiert |
| 2 | Abhängigkeiten zu anderen Gates modelliert (sequenziell oder parallel) |
| 3 | `reached` nur mit Evidence und/oder Review — nicht per Dropdown |
| 4 | `moved` / `discarded` erzeugt Decision-Spur |
| 5 | Actions/BacklogItems können dem Gate zugeordnet werden |

**Heute:** nur (1) teilweise als Freitext `goal_description` — Rest fehlt.

---

## 8. UI-Prinzipien (verbindlich)

### 8.1 Drei Ebenen

| Ebene | Zweck | CRUD |
|-------|-------|------|
| **Workspace** | Alle Initiativen — Portfolio-Überblick | nein |
| **Initiative-Übersicht** | Operative Steuerung eines Vorhabens — **reicht im Alltag** | nein (nur Steuerung + Navigation) |
| **Unterseiten** | Plan, Ausführung, Eingang, Journey, Objekt-Details | ja (Anlage, Pflege, Bearbeitung) |

Heutige `InitiativeDetailPage` vermischt Übersicht und Pflege — **Anti-Pattern**.

### 8.2 Getrennte Hauptflächen (Unterseiten)

- **Plan** — Roadmap, Gates, Abhängigkeiten
- **Ausführung** — Arbeitspakete-Hub, Zuweisungen
- **Eingang** — Backlog, Triage
- **Nachvollziehbarkeit** — Decisions, Reviews, Journey

### 8.3 Bearbeitungs-Pattern

Anlegen/Bearbeiten in **Modal** oder **Objekt-Detail-Route** — nicht als Inline-Listenformular auf Übersichtsseiten (weder Workspace noch Initiative-Übersicht).

### 8.4 Steuerungsfragen pro Ebene

**Workspace:** Welches Vorhaben braucht Aufmerksamkeit? Wo stehe ich insgesamt?

**Initiative-Übersicht:** Wo steht dieses Programm — und was ist hier als Nächstes dran? Was blockiert?

**Unterseiten:** Wie pflege/plane ich Struktur und Inhalte?

### 8.5 Operational Actor Interface (Vibe-Coder)

Agenten-Actors nutzen dieselbe fachliche API wie die UI — Capability-gated, auditiert:

- Kontext/Snapshot lesen
- Next Action anfragen
- Status, Blocker, Evidence, Decision-Unterlagen ablegen
- Backlog/Gates **vorschlagen**, nicht heimlich committen oder schließen

Spec: Vision v0.2 §7.5; Implementierung AP1.7 nach IA-Skeleton.

---

## 9. Statusmodelle

Wie v0.1 für implementierte Objekte.

**RoadmapItem** (Ziel — aus Target State):

- planned, active, at_risk, reached, moved, discarded

Gate-Übergang `→ reached` nur über Verify-Pfad.

---

## 10. Next Action / Attention Logic

Regeln aus v0.1 bleiben; ergänzt:

10. Gates `at_risk` oder überfällig sichtbar machen  
11. Plan-Ist-Abweichung ohne Decision sichtbar machen (später)  
12. Unverknüpfte BacklogItems zu aktivem Gate sichtbar machen (später)

Implementierung: `backend/steering/` — keine parallelen Heuristiken.

---

## 11. Data Layer

Read-orientierte Steuerungs-Sichten:

```text
data_layer.workspace
data_layer.initiatives
data_layer.initiative_snapshot  (Graph: actions + linked context)
data_layer.attention
data_layer.actors
```

Geplant: `roadmap`, `journey`, `plan_ist_delta`

---

## 12. MVP-Nutzbarkeit (neu definiert)

Kairo ist **MVP-nah in der Vision**, wenn ein Nutzer **ohne CRUD-Wand**:

1. Auf dem **Workspace** in ≤30s die nächste Arbeit findet
2. Pro Vorhaben **Steuerung**, **Ausführung**, **Plan** getrennt navigiert
3. Ein **Gate** mit DoD und Verifikation durchspielt (Plan → Commit → Verify → reached)
4. Eine **Decision** als Plan-Abweichung dokumentiert und in der Journey sieht
5. Blocker und Next Actions **am richtigen Objekt** sieht

**Nicht MVP-nah:** Alle OM-Tabellen als parallele Listen auf einer Seite.

---

## 13. Agenten-Regel

Wie v0.1. Zusätzlich:

Agenten (inkl. **Vibe-Coder**) sind **Actors** mit definierter **Operational Actor Interface** (Vision §7.5):

- dürfen Kontext lesen, Next Action anfragen, Status/Evidence/Blocker/Decision-Unterlagen ablegen
- dürfen RoadmapItems und Backlog **vorschlagen**
- dürfen **nicht** heimlich committen, Gates ohne Verify schließen oder strategische Steuerung ändern

UI-Unterseiten und Agent-API müssen **fachlich äquivalent** bleiben.

---

## 14. Auslegungsreihenfolge

1. `Kairo_Vision_and_Product_Direction_v0.2.md`
2. Dieses Dokument (v0.2)
3. `Kairo_System_Target_State_v0.1.md` / v0.2
4. ADPs (Scope Lock, RoadmapItem)
5. Product Spec v0.2 (Referenz)

---

## 15. Methodische Flexibilität (verbindlich)

Kairo unterstützt **unterschiedliche Entwicklungs- und Steuerungsmethoden** — auf Portfolio-, Initiativ-, Plan- und Ausführungsebene.

- **Kernmodell generisch:** RoadmapItem-Typen, Lifecycle, Actions — nicht „nur Software-PM“
- **Methoden in Registry:** `steering_context.method_key` + Strategy/Hook-Pakete — keine Sonder-Tabellen pro Methode
- **Plan flexibel:** `sequencing_mode` sequenziell | parallel | optional; `item_type` (milestone, maturity_stage, chapter, …)
- **Verify flexibel:** Gate-`reached` über Evidence/Review/Decision — Policies methodenabhängig konfigurierbar (später)
- **UI methodenbewusst, nicht methodenfix:** Plan-Tab rendert RoadmapItems; Labels/Filter aus Method-Profil, nicht hardcodiert

Siehe Vision v0.2 §9.1.

---

*v0.1 bleibt als historische Referenz erhalten.*