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