Kairo-Jinkendo/docs/product/Kairo_Plan_Mode_Design_v0.1.md

# Kairo — Plan-Modus Design v0.1

**Status:** PO-Arbeitsentwurf (Entscheidung ausstehend)  
**Stand:** 2026-07-09  
**Bezug:** `Kairo_PM_Frontend_UI_Concept_v0.1.md` §4.3, `ADP_AP1_10_Initiative_Archetypes_and_Entity_Field_System_v0.1.md`  
**Auslöser:** Planen soll von Tab-Fragmenten zu durchgängiger Programmgestaltung werden — bis Struktur, Gates, Eingang, Arbeitspakete und Tasks

---

## 1. Leitfrage

**Wie soll das Programm aufgebaut sein — von der Vorhabens-Identität bis zur ausführbaren Granularität?**

Planen beantwortet **Struktur- und Zielfragen**. Es committet **keine Tagesausführung** (das ist Ausführen) und **kein Lagebild** (das ist Kontrolle).

---

## 2. Grundsatz: Vorhaben als Wurzel

```text
/plan?initiative={id}&project={optional}

Initiative (Wurzel — immer im Scope)
├── Profil          — Archetyp, Standard- + dynamische Felder
├── Struktur        — Project-Baum (rekursiv)
├── Zielzustände    — Gates / RoadmapItems (Liste + Graph)
├── Eingang         — Backlog (triage → convert)
└── Arbeit          — Actions (+ Tasks ab AP1.5d) im Plan-Kontext
```

**Flache Vorhaben:** Actions ohne `project_id` erscheinen als direkte Kinder der Initiative im Plan-Baum.

**Commit-Grenze Plan → Ist:**

| Objekt | In Plan | Commit-Aktion |
|--------|---------|---------------|
| BacklogItem | Ja | Convert → Action |
| Project / Gate | Ja | sofort „Struktur“ (kein separater Commit) |
| Action | Sichtbar | Anlage = committet |
| Task | Sichtbar (AP1.5d) | Anlage unter Action |

---

## 3. IA: Von Tabs zur Plan-Outline

### 3.1 Heute (AP1.9a)

```text
/plan/structure | /plan/gates | /plan/inbox   — drei lose Untertabs
```

### 3.2 Ziel (AP1.12)

**Eine Planungsseite** mit linker **Outline** (Baum) und rechtem **Kontextbereich** (Desktop) bzw. **Drill-down** (Mobile).

```text
┌──────────────────────────────────────────────────────────────┐
│ Modus: Planen    Scope: Portfolio › Vorhaben X › [Projekt Y] │
├──────────────────┬───────────────────────────────────────────┤
│ OUTLINE          │ KONTEXT                                   │
│ ▼ Vorhaben X     │  [Profil-Karte / Mini-Snapshot]           │
│   ▼ Struktur     │  oder                                     │
│     Phase 1      │  [Liste der Kinder des gewählten Knotens] │
│     Phase 2      │  oder                                     │
│   Zielzustände   │  [Graph-Ansicht Gates]                    │
│   Eingang (3)    │                                           │
│   Arbeit (12)    │                                           │
└──────────────────┴───────────────────────────────────────────┘
```

**Routen (evolutionär):**

| Route | Bedeutung |
|-------|-----------|
| `/plan` | Portfolio: „Vorhaben ohne Struktur“, „Gates ohne Kriterien“ (Einstieg) |
| `/plan?initiative=` | Outline für ein Vorhaben |
| `/plan?initiative=&node=structure\|gates\|inbox\|work` | Outline-Fokus (Query, kein Pflicht-Split) |
| `/gates/:id`, `/projects/:id` | Objekt-Modal / Deep Link (bestehend AP1.9) |

Untertabs `/plan/structure` etc. bleiben als **Deep-Link-Aliase** mit Redirect auf `/plan?initiative=&node=…` bis Entfernung in AP1.12.

---

## 4. Interaktion

### 4.1 Bearbeiten — Modal (verbindlich)

| Objekt | Trigger | Modal-Inhalt |
|--------|---------|----------------|
| Initiative | Outline „Profil“ / Stift-Icon | Standardfelder + EFS (AP1.10) |
| Project | Klick / Stift | Titel, Status, container_kind, Gate-Link, Parent |
| Gate | Klick / Stift | RoadmapItem + Kriterien (bestehend, polish) |
| Backlog | Klick | Triage-Felder, Gate-Link, Convert-Button |
| Action | Klick | ActionForm (bestehend) — oder Link zu `/actions/:id` |
| Task | Klick (AP1.5d) | TaskForm |

**Regel (UI Concept P4):** Kein dauerhaftes Inline-Formular in der Outline.

### 4.2 Reihenfolge

| Plattform | Mechanismus | Gilt für |
|-----------|-------------|----------|
| Desktop (≥1024px) | Drag & Drop innerhalb gleicher Elternebene | Projects, Backlog (sort_order), Gates (optional Phase 2) |
| Mobile / Touch | ↑ / ↓ Buttons pro Zeile | gleich |

**API:** `PATCH` mit `sort_order` oder dediziertes `POST …/reorder` — idempotent, tenant-scoped.

### 4.3 Anlegen

„+“ am **elterlichen Knoten** in der Outline (nicht globaler FAB ohne Kontext).

---

## 5. Zielzustände — Graph-Editor

### 5.1 Zwei Ansichten

| Ansicht | Wann | UI |
|---------|------|-----|
| **Liste** | Flache Vorhaben, wenige Gates | `RoadmapPlanSection` (evolviert) |
| **Graph** | Komplexe Abhängigkeiten, Parallel-Gates | **GateMapEditor** (neu) |

Umschalter: „Liste | Graph“ im Knoten Zielzustände — Default **Liste** wenn ≤5 Gates, sonst letzter User-Choice (localStorage pro Initiative).

### 5.2 Graph-Editor (AP1.13) — Mitai-Pattern, Kairo-Semantik

**Referenz (Pattern only):** Mitai `WorkflowEditorPage` — Canvas, Zoom, Pan, Snap-to-grid.

**Kairo-Scope (kein Workflow):**

| Element | Semantik |
|---------|----------|
| Knoten | RoadmapItem (Gate, Meilenstein, Reifegrad) |
| Kanten | `roadmap_item_dependencies` (sequential / parallel / optional) |
| Kein | Lifecycle-Workflow, keine Prompt-Knoten, keine Mitai-Domäne |

**Phase 1:** Gates + Kanten CRUD im Graph  
**Phase 2:** Project→Gate-Bezug als Badge am Knoten oder Filter-Layer  
**Verify / Kriterien:** Weiterhin Detail-Modal / `/gates/:id` — nicht im Graph inline CRUD-Wand

### 5.3 Backend

Baut auf AP1.4d (Graph Engine read models) auf — UI AP1.13 **nach** 4d oder parallel wenn read APIs vorhanden.

---

## 6. Ebenen bis Workpackage & Task

| Ebene | Typ | Plan-Outline-Knoten | Tiefe |
|-------|-----|---------------------|-------|
| 0 | Initiative | Wurzel | 1 |
| 1 | Project | rekursiv | max. 5 (bestehend) |
| 2 | RoadmapItem | Zielzustände (Graph/Liste) | parallel zur Struktur |
| 3 | BacklogItem | Eingang | flach unter Initiative |
| 4 | Action | Arbeit | unter Project **oder** Initiative |
| 5 | Task | (AP1.5d) | unter Action, UI max. ~3 |

**Plan-Baum „Arbeit“:** Zeigt committete Actions + Tasks (read-heavy); Anlage öffnet Modal. Filter: optional nur „ohne Project“ / „unter gewähltem Project“ (Scope `?project=`).

---

## 7. Scope-Breadcrumb (AP1.9b — Zuverlässigkeit)

**Problem:** Klick auf Vorhaben im Breadcrumb führt immer nach `/control/status` — in Planen falsch.

**Regel:** Mittlerer Breadcrumb-Klick ist **modus-sensitiv**:

| Aktiver Modus | Klick „Vorhaben X“ |
|---------------|-------------------|
| `/plan/*` | `/plan?initiative=X` |
| `/control/*` | `/control/status?initiative=X` |
| `/work/*` | `/work/today?initiative=X` |
| Objekt-Route | passender Modus aus Objekttyp (`/projects/` → Plan, `/actions/` → Work) |

Portfolio-Klick: Scope leeren, Modus beibehalten.

**Technik:** `ProgramScopeBar` liest `useLocation` + Modus-Registry; kein hardcoded `/control/status`.

---

## 8. Implementierungspakete

```text
AP1.9b   Scope-Breadcrumb modus-sensitiv; Scope-Sync bei Deep Links härten
AP1.12a  Plan-Outline Shell (Desktop Split / Mobile Drill-down)
AP1.12b  Modal-Edit für Project, Backlog, Initiative-Profil (Standardfelder)
AP1.12c  Reorder: sort_order API + DnD (Desktop) + ↑↓ (Mobile)
AP1.12d  Outline-Knoten „Arbeit“ (Actions listen, Link zu Detail)
AP1.13a  GateMapEditor read-only (Layout aus Dependencies)
AP1.13b  GateMapEditor edit (Knoten/Kanten CRUD)
AP1.5d   Tasks in Outline-Knoten „Arbeit“
AP1.10   Archetyp + EFS für Initiative-Profil-Modal (parallel ab 10a)
```

**Empfohlene Reihenfolge:**

```text
9b → 12a → 12b → 10a/10c (Profil) → 12c → 12d → 5d → 13a → 13b
```

---

## 9. Nicht-Ziele (Scope Lock)

- Kein Sprint-/Capacity-Planning in Planen (später Team-Modus-Erweiterung)
- Kein Inline-CRUD aller Gates in der Outline-Liste
- Kein Mitai-Workflow-Clone
- Kein Steering pro Project-Ebene (ADP Recursive Containers)

---

## 10. Erfolgskriterien (PO)

1. PO kann ein Vorhaben wählen und **in einer Ansicht** Struktur, Gates, Eingang und Arbeit sehen.  
2. Bearbeitung läuft **nur im Modal** — Outline bleibt übersichtlich.  
3. Project-Reihenfolge per DnD (Desktop) änderbar.  
4. Gates mit Abhängigkeiten im **Graph** darstellbar (AP1.13).  
5. Breadcrumb-Klick auf Vorhaben bleibt im Modus Planen.

---

## 11. PO-Freigabe

- [ ] Outline statt drei Tabs (AP1.12) angenommen  
- [ ] Modal-Edit + DnD/↑↓ OK  
- [ ] GateMapEditor (Mitai-Pattern) Scope OK  
- [ ] AP1.9b Breadcrumb-Regel OK  

---

## Referenzen

- `docs/architecture/ADP_AP1_10_Initiative_Archetypes_and_Entity_Field_System_v0.1.md`  
- `docs/architecture/ADP_AP1_9_PM_Work_Modes_Frontend_IA_v0.1.md`  
- `docs/reference/design-principles/mitai/PROMPT_ENGINE_DESIGN_PRINCIPLES.md` (WorkflowEditor-Referenz)