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:

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)

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)

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:

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.