Docs: Zielzustands-Graph ist kein Workflow; Plan vs. Ist.

Plan-Mode-Design und ADP praezisieren Graph-Semantik, MVP-Zwischenstand und vorgeschlagene Pakete AP1.14/15 fuer Plan-Ist-Parallelitaet und Modellierungswerkzeug.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/architecture/ADP_Roadmap_Graph_and_Gate_Checklist_v0.1.md

@@ -1,7 +1,7 @@
 # ADP — Roadmap-Graph, Gate-Checkliste & Methodenprofile v0.1
 
 **Status:** PO-Freigabe AP1.4b (2026-07-05); **Priorität UI/Graph** siehe `ADP_PO_Product_Layering_and_IA_Reset_v0.1.md` (2026-07-06)  
-**Stand:** 2026-07-06  
+**Stand:** 2026-07-10  
 **Bezug:** `ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md`, Vision v0.2 §9.1  
 **Ersetzt nicht:** AP1.4-Minimal (Schema 010/011) — **korrikt und erweitert** Zielbild
 
@@ -18,6 +18,27 @@ Ein Meilenstein / Gate ist mehr als Status + Verify-Klick:
 5. **Baum-/Graphlogik** — sequenziell / parallel / optional **nicht am Item**, sondern in **Beziehungen** zu anderen Items  
 6. Daraus: **Roadblocker**, Attention, „ready vs. blocked“ — erstmals **Graph Engine** nötig
 
+**Abgrenzung (PO 2026-07-10):** Der Roadmap-Graph ist ein **Zielzustands-Modell (Plan)** — **kein Workflow**, keine Ausführungs-Engine, keine Mitai-Prompt-Graph-Semantik. Mitai-Workflow-Editor nur als **UI-Pattern** für ein späteres Modellierungswerkzeug.
+
+---
+
+## Plan-Graph vs. Ist (Nachvollziehbarkeit)
+
+**Erfahrung aus Kairo-Entwicklung:** Plan und Ist mehrfach vermischt (mutable Gate + Status-Dropdown + Freitext-DoD) → Review und Historie nicht rekonstruierbar.
+
+**Ziel:**
+
+| Aspekt | Plan (Soll) | Ist |
+|--------|-------------|-----|
+| Graph-Topologie | Knoten, Kanten, Parallelgruppen, Joins | welche Äste „genommen“, optional übersprungen |
+| Kriterien | Definition (Checkliste) | Status pro Kriterium (satisfied/waived/deferred) |
+| Gate | `planned`/`active` als Plan-Intent | `reached`/`moved`/`discarded` + Journey |
+| Änderung | **Plan-Revision** (Audit, ggf. Decision) | Verify, Reopen, Evidence, Decision |
+
+**Review:** Plan-Graph und Ist-Overlay **parallel** betrachten → Abweichung erkennen → Plan **bewusst** anpassen (Zielzustand revidieren), nicht Ist stillschweigend als neuen Plan speichern.
+
+**Paketierung (vorgeschlagen):** AP1.14 Plan-Snapshot / Ist-Overlay / Diff in Kontrolle; AP1.15 Zielzustands-Modellierungswerkzeug (Designer).
+
 ---
 
 ## Korrektur am AP1.4-Minimal (technische Schuld)
@@ -196,6 +217,11 @@ Plan-UI: **Detail-Modal/Route** `/initiatives/:id/plan/items/:itemId` — Checkl
 
 **Nicht in AP1.4b:** volle Graph-Visualisierung, KI-Verify.
 
+**Nicht in AP1.13 (geliefert):** grafischer Designer, Joint-Knoten, Plan/Ist-Parallelität — nur read-only Map + Kanten auf Detail.
+
+| **AP1.14** (vorgeschlagen) | Plan-Snapshot, Ist-Overlay, Diff, Plan-Revision mit Audit |
+| **AP1.15** (vorgeschlagen) | Zielzustands-Modellierungswerkzeug (Canvas-Designer) |
+
 ---
 
 ## Risiko

docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md

@@ -29,10 +29,10 @@
 | Entscheidung | |
 |--------------|--|
 | AP1.4b Backend | ✓ behalten (Kriterien, Verify, Reopen) |
-| Gate-UI-Politur (Modal, Graph-Workflow) | ⏸ **eingefroren** bis AP1.6 |
+| Gate-UI-Politur (Modal, Checkliste, Zielzustands-Designer) | ⏸ **eingefroren** bis AP1.6 |
 | Nächstes Code-Paket | **AP1.5c** rekursive Projects |
 | Tab „Plan“ | fachlich **Gates / Zielzustände** — Umbenennung AP1.5b |
-| Graph Engine AP1.4d | Gate-Kanten only — **kein** Lifecycle-Workflow |
+| Graph Engine AP1.4d | Zielzustands-Kanten only — **kein** Workflow, **kein** Lifecycle aus Graph |
 
 Siehe `ADP_PO_Product_Layering_and_IA_Reset_v0.1.md`.
 
@@ -238,7 +238,7 @@ Backlog/Action/Project/Task → RoadmapItem; Decision-Spur; Journey-Timeline.
 
 ### AP1.13 — Gate Map Editor
 
-Graph-UI für Gate-Dependencies (Mitai-Pattern). **Nach AP1.4d + AP1.12.**
+Graph-UI für Gate-Abhängigkeiten (Mitai-**Pattern**, Kairo Zielzustands-Semantik). **Nach AP1.4d + AP1.12.** Designer + Plan/Ist-Overlay → AP1.14/15.
 
 ---
 
@@ -348,7 +348,7 @@ Criteria, Waive/Defer, Reopen, Detail-Route. Version `0.13.1-ap1.4b`
 
 | Thema | Bis wann |
 |-------|----------|
-| Gate-UI-Politur (Modal, Graph-Workflow) | **Nach AP1.6** (PO 2026-07-06) |
+| Gate-UI-Politur (Modal, Checkliste, Designer) | **Nach AP1.6** (PO 2026-07-06) |
 | Prompt/KI/MCP produktiv | Ist-Hierarchie + Plan/Ist |
 | Method Designer UI | AP1.3+ |
 | Gantt / Kalender | nach Plan/Ist |

docs/product/Kairo_Implementation_Truth_Table_v0.1.md

@@ -1,7 +1,7 @@
 # Kairo — Implementation Truth Table v0.1
 
 **Status:** living document — bei jedem AP aktualisieren  
-**Stand:** 2026-07-06 (nach AP1.6)  
+**Stand:** 2026-07-10 (nach AP1.13)  
 **Zweck:** Ehrliche Trennung von **implementiert**, **teilweise**, **nur API/Schema**, **nur Dokumentiert**
 
 Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
@@ -104,6 +104,9 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
 | Zieltermin | ◐ | `target_date` |
 | Abhängigkeiten | ◐ | API; Graph Engine AP1.4d |
 | parallel vs. sequenziell | ◐ | `sequencing_mode` (deprecated); Graph AP1.4d |
+| Plan-Graph vs. Ist-Overlay | ✗ | AP1.13: ein Graph + Status am Knoten — Plan/Ist vermischt |
+| Zielzustands-Designer (Joint/Parallel) | ✗ | AP1.4d + AP1.15; AP1.13 nur Auto-Layout |
+| Plan-Revision / Graph-Historie | ✗ | AP1.14 vorgeschlagen |
 | Verify vor `reached` | ◐ | Kriterienplan + gate_override |
 | Reopen nach `reached` | ◐ | `active`, Kriterien bleiben AP1.4b |
 | Decision bei `moved` | ✗ | |

docs/product/Kairo_Plan_Mode_Design_v0.1.md

@@ -1,7 +1,7 @@
 # Kairo — Plan-Modus Design v0.1
 
 **Status:** PO-Arbeitsentwurf (Entscheidung ausstehend)  
-**Stand:** 2026-07-09  
+**Stand:** 2026-07-10  
 **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
 
@@ -111,34 +111,86 @@ Untertabs `/plan/structure` etc. bleiben als **Deep-Link-Aliase** mit Redirect a
 
 ---
 
-## 5. Zielzustände — Graph-Editor
+## 5. Zielzustände — Graph (Plan-Modell, kein Workflow)
 
-### 5.1 Zwei Ansichten
+### 5.0 Abgrenzung (verbindlich)
+
+Der **Zielzustands-Graph** modelliert **Soll-Struktur** — welche überprüfbaren Zielpunkte es gibt und wie sie **logisch zusammenhängen** (sequenziell, parallel, optional, blockierend).
+
+Er ist **kein Workflow**:
+
+| Zielzustands-Graph (Kairo) | Workflow (Mitai Prompt Engine — **nicht** Kairo-Scope) |
+|----------------------------|--------------------------------------------------------|
+| RoadmapItem = Quality Gate / Meilenstein / Reifegrad | Prompt-/Pipeline-Knoten |
+| Kanten = Plan-Abhängigkeiten zwischen Gates | Ausführungs-/Verzweigungslogik |
+| Verify = Kriterien + Evidence/Review | LLM-Aufruf, Aggregation, Join |
+| Lesbar in **Planen** und **Kontrolle** (Plan vs. Ist) | Admin-Konfiguration für KI |
+| Änderung am Plan = bewusste **Planungsentscheidung** (+ Audit) | Laufzeit-Orchestrierung |
+
+**Mitai `WorkflowEditorPage`:** nur **UI-Pattern-Referenz** (Canvas, Zoom, Pan, Snap) für ein künftiges **Zielzustands-Modellierungswerkzeug** — **keine** Übernahme von Workflow-Semantik, Prompt-Knoten oder Runtime.
+
+**Guardrail:** In Docs, UI und Code nicht „Workflow-Graph“, „Gate-Workflow“ oder „Graph-Workflow“ sagen — korrekt: **Zielzustands-Graph**, **Gate-Map**, **Plan-Graph**.
+
+### 5.1 Zwei Ansichten (Liste | Graph)
 
 | Ansicht | Wann | UI |
 |---------|------|-----|
 | **Liste** | Flache Vorhaben, wenige Gates | `RoadmapPlanSection` (evolviert) |
-| **Graph** | Komplexe Abhängigkeiten, Parallel-Gates | **GateMapEditor** (neu) |
+| **Graph** | Komplexe Abhängigkeiten, Parallel-Gates | **GateMapView** / später **Zielzustands-Designer** |
 
 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
+### 5.2 Graph-UI — Mitai-Pattern, Kairo-Semantik
 
-**Referenz (Pattern only):** Mitai `WorkflowEditorPage` — Canvas, Zoom, Pan, Snap-to-grid.
+**Referenz (Pattern only):** Mitai Workflow-Editor — Canvas, Zoom, Pan, Snap-to-grid.
 
-**Kairo-Scope (kein Workflow):**
+**Kairo-Scope (Zielzustands-Modell, kein Workflow):**
 
 | Element | Semantik |
 |---------|----------|
 | Knoten | RoadmapItem (Gate, Meilenstein, Reifegrad) |
-| Kanten | `roadmap_item_dependencies` (sequential / parallel / optional) |
+| Kanten | `roadmap_item_dependencies` → später `edge_kind` + `parallel_group` (AP1.4d) |
-| Kein | Lifecycle-Workflow, keine Prompt-Knoten, keine Mitai-Domäne |
+| Joint / Split (später) | **Plan-Topologie** — parallele Stränge, Join-Gates, optionale Äste — **nicht** Runtime-Verzweigung |
+| Kein | Lifecycle-Workflow, Prompt-Knoten, Mitai-Domäne, Ausführungs-Engine |
 
-**Phase 1:** Gates + Kanten CRUD im Graph  
+**Heute (AP1.13a/b — MVP-Zwischenstand):** read-only Auto-Layout + Kanten auf Gate-Detail; **kein** grafischer Designer, **keine** Joint-Knoten, **kein** Parallel-Join-Modell (→ AP1.4d + Modellierungswerkzeug).
-**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
+**Phase 2 — Zielzustands-Modellierungswerkzeug (PO):**
+
+- Drag-Drop-Designer für Gates, Kanten, Parallelgruppen, Joins  
+- Bearbeitung nur im **Plan**-Kontext (Modal/Designer — nicht Inline-CRUD-Wand in der Outline)  
+- Verify / Kriterien / Evidence weiterhin auf Gate-Detail — nicht im Graph als CRUD-Omnibus
+
+### 5.3 Plan-Graph vs. Ist — parallel betrachten (Zielbild)
+
+**Problem (mehrfach in Kairo erlebt):** Wenn Plan und Ist in **demselben mutable Objekt** verschmelzen (Status-Dropdown, Freitext-DoD, Graph = nur aktueller Stand), ist **nicht nachvollziehbar**, was geplant war, was tatsächlich passiert ist und wann der Plan angepasst wurde.
+
+**Regel:**
+
+| Schicht | Inhalt | Änderbarkeit |
+|---------|--------|--------------|
+| **Plan-Graph (Soll)** | Knoten, Kanten, Kriterien-**Definition**, Parallel-/Join-Topologie | Planung; Revision mit Audit/Decision |
+| **Ist-Overlay** | Gate-Status (`reached`/`moved`/…), Kriterien-**Status**, Evidence, Journey-Events | Ausführung, Review, Verify, Reopen |
+| **Historie** | Plan-Revisionen, Ist-Ereignisse, Abweichungen Plan↔Ist | append-only / audit |
+
+**Review-Ablauf (Kontrolle / Journey — Ziel):**
+
+```text
+1. Plan-Graph und Ist-Overlay **parallel** anzeigen (nicht eins collapsed)
+2. Abweichungen sichtbar: Gate erreicht aber Kriterium waived; optionaler Ast nicht genommen; Plan-Kante obsolet
+3. Entscheidung: Plan anpassen (Zielzustand revidieren) — mit Begründung — ODER Ist dokumentieren (Decision/moved/discarded)
+4. Plan-Graph **ordentlich** nachziehen — nicht stillschweigend den Ist-Stand als neuen Plan überschreiben
+```
+
+**Technische Folge (spätere Pakete):**
+
+- AP1.4d: Graph Engine Read Models (`blocked`, `ready`, `fulfillment_ratio`) aus **Plan-Kanten** + **Ist-Status**  
+- AP1.4e+: Methodenprofile (Erfüllungsgrad vs. hartes `reached`)  
+- **AP1.14 (vorgeschlagen):** Plan-Snapshot / Plan-Revision + Ist-Overlay in UI (Kontrolle: „Plan | Ist | Diff“); Graph-Designer Phase 2
+
+**Heute:** Ein Graph, Status am selben Knoten — **Ist vermischt mit Plan**. Truth Table: ◐. Das ist **bewusster MVP-Zwischenstand**, kein Zielbild.
+
+### 5.4 Backend
 
 Baut auf AP1.4d (Graph Engine read models) auf — UI AP1.13 **nach** 4d oder parallel wenn read APIs vorhanden.
 
@@ -186,8 +238,11 @@ 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.13a  GateMapView read-only (Layout aus Dependencies)
-AP1.13b  GateMapEditor edit (Knoten/Kanten CRUD)
+AP1.13b  Kanten-CRUD auf Gate-Detail (kein Designer)
+AP1.4d    Graph Engine: parallel_group, edge_kind, blocked/ready
+AP1.14    Plan-Snapshot / Ist-Overlay / Plan-Revision (vorgeschlagen)
+AP1.15    Zielzustands-Modellierungswerkzeug (Designer, Mitai-Pattern)
 AP1.5d   Tasks in Outline-Knoten „Arbeit“
 AP1.10   Archetyp + EFS für Initiative-Profil-Modal (parallel ab 10a)
 ```
@@ -204,7 +259,8 @@ AP1.10   Archetyp + EFS für Initiative-Profil-Modal (parallel ab 10a)
 
 - 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 Mitai-Workflow-Clone (**auch kein „Workflow-Graph“** — nur Zielzustands-Graph)
+- Kein Plan=Ist-Collapse (Status/Freitext ersetzt nicht Plan-Revision + Ist-Historie)
 - Kein Steering pro Project-Ebene (ADP Recursive Containers)
 
 ---
@@ -214,7 +270,7 @@ AP1.10   Archetyp + EFS für Initiative-Profil-Modal (parallel ab 10a)
 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).  
+4. Gates mit Abhängigkeiten im **Zielzustands-Graph** darstellbar (AP1.13); Designer + Plan/Ist-Parallelität folgen (AP1.4d, AP1.14+).  
 5. Breadcrumb-Klick auf Vorhaben bleibt im Modus Planen.
 
 ---
@@ -223,7 +279,8 @@ AP1.10   Archetyp + EFS für Initiative-Profil-Modal (parallel ab 10a)
 
 - [ ] Outline statt drei Tabs (AP1.12) angenommen  
 - [ ] Modal-Edit + DnD/↑↓ OK  
-- [ ] GateMapEditor (Mitai-Pattern) Scope OK  
+- [ ] GateMap / Zielzustands-Designer (Mitai-**Pattern** only) Scope OK  
+- [ ] Plan-Graph vs. Ist-Overlay parallel (AP1.14) OK  
 - [ ] AP1.9b Breadcrumb-Regel OK  
 
 ---