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

/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)

/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).

┌──────────────────────────────────────────────────────────────┐
│ 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

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:

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)