docs: Welle 2 — Roadmap v0.2, ADPs, AP1.2c Assignment

Corrected MVP Roadmap v0.2, Recovery Plan v0.2, Gap Analysis v0.2, Target State Implementation Map. ADPs für RoadmapItem/Quality Gates und Operational Actor Interface (Vibe-Coder). Handover v0.2 und Sprint-Auftrag AP1.2c IA-Skeleton.
2026-07-05 18:17:25 +02:00 · 2026-07-05 18:17:25 +02:00 · 2796965aed
commit 2796965aed
parent 8c31802662
13 changed files with 1189 additions and 15 deletions
--- a/CLAUDE.md
+++ b/CLAUDE.md
@ -42,11 +42,12 @@ Lies bei Projektstart in dieser Reihenfolge:
 2. `docs/product/Kairo_Canonical_Operating_Model_v0.2.md`
 3. `docs/product/Kairo_Implementation_Truth_Table_v0.1.md`
 4. `docs/product/DOCUMENTATION_REVISION_PROGRAM_v0.2.md`
-5. `docs/architecture/Kairo_System_Target_State_v0.1.md`
-6. `docs/architecture/ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`
-7. `docs/architecture/Kairo_Tenant_Invariants_v0.1.md`
-8. `docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md`
-9. `.cursor/rules/kairo-architecture.mdc`
+5. `docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md`
+6. `docs/architecture/Kairo_System_Target_State_v0.1.md`
+7. `docs/architecture/ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`
+8. `docs/architecture/Kairo_Tenant_Invariants_v0.1.md`
+9. `docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md`
+10. `.cursor/rules/kairo-architecture.mdc`

 Historisch / Referenz (nicht führend bei Konflikt):

@ -165,6 +166,6 @@ Bei notwendiger Abweichung erstelle ein Architecture Decision Proposal.

 ## 8. Nächste Entwicklungsschritte

-Siehe `docs/product/DOCUMENTATION_REVISION_PROGRAM_v0.2.md` und Vision v0.2.
+Siehe `docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md` und `Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md`.

 Foundation AP0.1–AP1.1b technisch weit. **Produkt:** IA + RoadmapItem/Gates vor weiterem UI-Polish. Scope Lock: `ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`.
--- a/docs/architecture/ADP_Operational_Actor_Interface_Vibe_Coder_v0.1.md
+++ b/docs/architecture/ADP_Operational_Actor_Interface_Vibe_Coder_v0.1.md
@ -0,0 +1,201 @@
+# ADP — Operational Actor Interface (Vibe-Coder) v0.1
+
+**Status:** Entwurf zur Freigabe  
+**Stand:** 2026-07-05  
+**Autor:** Product/Architecture (DOC Welle 2)  
+**Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md` §7.5  
+**Paket:** AP1.7
+
+---
+
+## Problem
+
+Vibe-Coder und andere Agenten-Actors sollen Status melden, Next Action anfragen und Entscheidungsunterlagen ablegen — **ohne** UI und **ohne** Ad-hoc-Prompts.
+
+Heute: Actors existieren (`actor_type=agent`), aber keine **definierte, auditierte API** für operative Arbeit. Gefahr: parallele Agent-Sonderlogik außerhalb `backend/steering/`.
+
+---
+
+## Betroffene Regel
+
+- Canonical OM v0.2 §13 (Agenten-Regel)  
+- Scope Lock AP1.0 — Agent-Runtime eingefroren; **API-Oberfläche** ist erlaubt nach IA  
+- Tenant Invariants — Actor-first, Capability-gated
+
+---
+
+## Optionen
+
+| Option | Kurzbeschreibung | Pro | Contra |
+|--------|------------------|-----|--------|
+| **A** | Bestehende REST-Endpoints + API-Keys pro Agent | Schnell | Uneinheitlich; fehlende Agent-Semantik |
+| **B** | **`/api/operational/`** Namespace — dünne Fassade über Services + Steering | Klar, dokumentiert, auditierbar | Neues Router-Paket |
+| **C** | MCP-only | Modern | Scope Lock; vorzeitig |
+
+## Empfehlung
+
+**Option B** — Operational API als **stabile Fassade** (AP1.7), intern ruft bestehende Services + `backend/steering/` auf.
+
+Auth: Session oder **Actor Service Token** (Tenant-scoped, Capability-gebunden) — Detail in AP1.7 Implementierung.
+
+---
+
+## Endpoints (v0.1 Spec)
+
+Basis: `/api/operational` — alle Requests mit Actor-Identität (nicht User impersonation ohne Audit).
+
+### Kontext
+
+```http
+GET /api/operational/initiatives/{id}/context
+```
+
+→ Steering Snapshot + Lifecycle + Method (subset für Agenten).
+
+### Next Action
+
+```http
+GET /api/operational/next-action?initiative_id=&limit=
+```
+
+→ `NextActionCandidate[]` für **aufrufenden Actor** via `backend/steering/strategies/next_action/`.
+
+### Arbeitspaket (Action)
+
+```http
+GET    /api/operational/actions/{id}
+PATCH  /api/operational/actions/{id}/status
+       { "status": "in_progress", "note": "..." }
+POST   /api/operational/actions/{id}/assignments
+       { "actor_ids": ["..."] }
+```
+
+Capabilities: `kairo.action.read`, `kairo.action.manage`.
+
+### Blocker
+
+```http
+POST /api/operational/blockers
+     { "initiative_id", "action_id?", "title", "description?" }
+PATCH /api/operational/blockers/{id}
+      { "status": "resolved" }
+```
+
+Capability: `kairo.blocker.manage`.
+
+### Evidence
+
+```http
+POST /api/operational/evidence
+     { "initiative_id", "action_id?", "roadmap_item_id?", "title", "body?" }
+```
+
+Capability: `kairo.evidence.manage`.
+
+### Decision-Unterlage
+
+```http
+POST /api/operational/decisions/proposals
+     {
+       "initiative_id",
+       "title",
+       "rationale",
+       "evidence_ids": [],
+       "proposed_status": "proposed"
+     }
+```
+
+Erzeugt Decision `proposed` + verknüpfte Evidence — **kein** auto-`decided`.
+
+Capability: `kairo.decision.manage`.
+
+### Backlog-Vorschlag
+
+```http
+POST /api/operational/backlog/proposals
+     { "initiative_id", "title", "description?", "roadmap_item_id?" }
+```
+
+Status `new` — kein Auto-Convert zu Action.
+
+Capability: `kairo.backlog.manage`.
+
+### Explizit nicht in v0.1
+
+- Gate `reached` setzen  
+- Initiative Lifecycle ändern  
+- Method wechseln  
+- Portfolio-Priorität  
+
+---
+
+## Response-Konvention
+
+```json
+{
+  "ok": true,
+  "data": { },
+  "actor_id": "uuid",
+  "audit_ref": "uuid optional"
+}
+```
+
+Fehler: HTTP 403 Capability, 404 Tenant-Isolation, 422 Validation.
+
+---
+
+## Audit
+
+Jeder mutierende Call:
+
+- `audit_log`: actor_id, action, resource_type, resource_id, payload_hash  
+- Agent-Runs später korrelierbar (`agent_run_id` optional header)
+
+---
+
+## UI-Äquivalenz
+
+| API | UI-Ort |
+|-----|--------|
+| context | Initiative-Übersicht |
+| next-action | Next-Action-Widget |
+| action status | Ausführung / Action-Detail |
+| blockers/evidence | Action-Detail / Unterseiten |
+| decision proposals | Entscheidungen-Unterseite |
+
+---
+
+## Implementierungsreihenfolge
+
+1. AP1.2c — IA steht  
+2. AP1.7a — Read-only: context, next-action, get action  
+3. AP1.7b — Mutations: status, blockers, evidence, proposals  
+4. AP1.7c — Actor Service Token Auth (wenn Session nicht reicht)
+
+---
+
+## Risiko
+
+| Risiko | Mitigation |
+|--------|------------|
+| Agent umgeht Gate-Verify | Endpoint-Whitelist; kein gate reached |
+| Token-Leak | Tenant-scoped, rotierbar, minimal capabilities |
+| Duplikat-Logik | Fassade nur — Services/steering unverändert |
+
+---
+
+## Rückbaubarkeit
+
+Router `/api/operational` entfernbar ohne Domänenänderung.
+
+---
+
+## Freigabe-Checkliste PO
+
+- [ ] Endpoint-Liste ausreichend für Vibe-Coder-Handover  
+- [ ] Proposals statt Auto-Commit akzeptiert  
+- [ ] AP1.7 nach AP1.2c  
+
+---
+
+*Handover: `Sprint0_Vibe_Coder_Handover_v0.2.md`*
--- a/docs/architecture/ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md
+++ b/docs/architecture/ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md
@ -0,0 +1,165 @@
+# ADP — RoadmapItem & Quality Gate Model v0.1
+
+**Status:** Entwurf zur Freigabe  
+**Stand:** 2026-07-05  
+**Autor:** Product/Architecture (DOC Welle 2)  
+**Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md` §6  
+**Paket:** AP1.4
+
+---
+
+## Problem
+
+Die Tabelle `milestones` ist eine **MVP-Brücke** mit Titel, optionalem Text, Status-Dropdown — **kein Quality Gate**:
+
+- kein prüfbares DoD-Modell
+- keine Abhängigkeiten (sequenziell / parallel)
+- kein Verify vor `reached`
+- keine Plan-Ist-Verknüpfung zu Actions/Backlog
+- irreführend in UI und Docs als „Meilenstein fertig“
+
+Gleichzeitig verbietet Scope Lock (ADP AP1.0) neue OM-Tabellen **bis ADP** — dieses ADP ist die Freigabe für AP1.4.
+
+---
+
+## Betroffene Regel
+
+- `Kairo_Canonical_Operating_Model_v0.2.md` §6–7  
+- `Kairo_System_Target_State_v0.1.md` §12–13  
+- `ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md` — Ausnahme AP1.4  
+- AD-TA-08 (Milestone-Brücke → RoadmapItem Konsolidierung)
+
+---
+
+## Optionen
+
+| Option | Kurzbeschreibung | Pro | Contra |
+|--------|------------------|-----|--------|
+| **A** | `milestones` erweitern (DoD JSON, deps) | Weniger Migration | Doppelmodell bleibt; widerspricht Target State |
+| **B** | **Roadmap + RoadmapItem** neu; `milestones` migrieren | Kanonisches Modell; Gates; Dependencies | Migration; größerer Scope |
+| **C** | Nur UI/DoD auf `milestones` | Schnell | Kein Roadmap; Plan/Ist unmöglich |
+
+## Empfehlung
+
+**Option B** — schmale erste Migration:
+
+```text
+roadmaps (1 pro Initiative initial)
+roadmap_items
+roadmap_item_dependencies
+roadmap_item_criteria (DoD-Zeilen, optional Phase 1 nur JSONB)
+```
+
+`item_type` initial: `milestone`, `review_gate`, `maturity_stage`.
+
+Bestehende `milestones` → `roadmap_items` mit `legacy_milestone_id` oder One-shot-Migration.
+
+---
+
+## Fachmodell (Minimal AP1.4)
+
+### RoadmapItem
+
+| Feld | Typ | Pflicht |
+|------|-----|---------|
+| id | uuid | ✓ |
+| tenant_id, initiative_id, roadmap_id | uuid | ✓ |
+| item_type | enum | ✓ |
+| title | text | ✓ |
+| goal_description | text | |
+| definition_of_done | jsonb / criteria table | ◐ Phase 1: jsonb Liste |
+| target_date | date | |
+| status | planned/active/at_risk/reached/moved/discarded | ✓ |
+| sequencing_mode | sequential / parallel / optional | ✓ default sequential |
+| sort_order | int | |
+
+### Dependencies
+
+| Feld | Typ |
+|------|-----|
+| from_item_id | uuid |
+| to_item_id | uuid |
+| dependency_type | requires / blocks / related |
+
+### Verknüpfung Ist → Plan
+
+| Relation | Beschreibung |
+|----------|--------------|
+| `backlog_items.roadmap_item_id` | optional FK |
+| `actions.roadmap_item_id` | optional FK |
+
+### Gate-Verify
+
+- Übergang `→ reached`: mindestens eine **Evidence** `accepted` ODER **Review** `completed` ODER explizite **Decision** `decided` mit Typ `gate_override`
+- Übergang `→ moved/discarded`: **Decision** Pflicht
+
+---
+
+## API (Minimal)
+
+```text
+GET  /api/initiatives/:id/roadmap
+GET  /api/initiatives/:id/roadmap/items
+POST /api/initiatives/:id/roadmap/items
+PATCH /api/roadmap-items/:id
+POST /api/roadmap-items/:id/verify-reached
+GET  /api/roadmap-items/:id/dependencies
+POST /api/roadmap-items/:id/dependencies
+```
+
+Steering Snapshot: `upcoming_milestones` liest aus `roadmap_items` statt `milestones`.
+
+---
+
+## UI (Minimal)
+
+- Unterseite **Plan** (`/initiatives/:id/plan`) — Liste + Gate-Detail-Route
+- Initiative-**Übersicht**: Horizont aus RoadmapItems (read)
+- Gate-Detail: DoD, Dependencies, Verify-Aktionen
+
+**Nicht AP1.4:** Gantt, Drag-Drop-Graph (Tabelle reicht).
+
+---
+
+## Migration
+
+1. Migration `010_roadmap_items.sql`  
+2. Datenmigration `milestones` → `roadmap_items` (type=milestone)  
+3. Deprecate `milestones` Router (410 + Link) oder View-Compat one release  
+4. Drop `milestones` in `011` nach Compat-Periode  
+
+---
+
+## Risiko
+
+| Risiko | Mitigation |
+|--------|------------|
+| Scope Creep | AP1.4 nur Minimal; kein Structure Builder |
+| Breaking API | Compat-Layer one release |
+| UI vor Schema | AP1.2c Plan-Shell vor AP1.4 Daten |
+
+---
+
+## Rückbaubarkeit
+
+- `roadmap_items` isoliert; Rollback Migration 010  
+- Milestone-Compat-View aus roadmap_items möglich  
+
+---
+
+## Auswirkung auf Sprint 0 / Scope Lock
+
+**Erweitert Scope Lock** explizit für AP1.4. Keine anderen Tabellen ohne neues ADP.
+
+---
+
+## Freigabe-Checkliste PO
+
+- [ ] Gate-Verify-Regel akzeptiert  
+- [ ] item_type initial: milestone, review_gate, maturity_stage  
+- [ ] milestones-Tabelle darf deprecated werden  
+- [ ] AP1.4 nach AP1.2c  
+
+---
+
+*Implementierung: `Kairo_Corrected_MVP_Roadmap_v0.2.md` AP1.4*
--- a/docs/architecture/Kairo_Current_State_Gap_Analysis_v0.2.md
+++ b/docs/architecture/Kairo_Current_State_Gap_Analysis_v0.2.md
@ -0,0 +1,96 @@
+# Jinkendo Kairo
+## Current State & Gap Analysis v0.2
+
+**Status:** Gap-Analyse (living document)  
+**Stand:** 2026-07-05 (nach AP1.1b + DOC Welle 1)  
+**Ersetzt für Ist-Stand:** `Kairo_Current_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md`  
+**Detail-Tabelle:** `Kairo_Implementation_Truth_Table_v0.1.md`
+
+---
+
+## 1. Zweck
+
+Ordnet **Implementierungsstand** gegen **Vision v0.2** ein — nicht gegen veraltetes „Milestone minimal = fertig“.
+
+---
+
+## 2. Was seit v0.1 dazugekommen ist
+
+| Paket | Geliefert | Produktwert |
+|-------|-----------|-------------|
+| AP0.7 | Tenant-Invarianten, Actor Directory, Data Layer | ✓ tragfähig |
+| AP0.8–0.9 | OM-Tabellen + CRUD-APIs + Workspace Attention | ◐ Inventar |
+| AP0.10b | NextAction/Heute-Widgets, Snapshot v2 | ◐ Workspace |
+| AP1.0 | steering_contexts, Lifecycle, Signals | ◐ Backend |
+| AP1.1 | Method Registry, product_milestone_driven | ◐ |
+| AP1.1b | InitiativeDetail Action-Hub | ◐ falsches IA-Pattern |
+| DOC W1 | Vision v0.2, Canonical OM v0.2, Truth Table | ✓ Richtung |
+
+---
+
+## 3. Gap-Matrix (Vision v0.2)
+
+| Konzept | Technisch | Produkt (Alltag) | Nächstes Paket |
+|---------|-----------|------------------|----------------|
+| Tenant / Actor / Capabilities | ✓ | ✓ | — |
+| Initiative | ✓ | ◐ | AP1.2c Übersicht |
+| Action (Arbeitspaket) | ✓ | ◐ | AP1.2c Detail-Route |
+| Backlog / Blocker / Evidence / Decision / Review | ✓ API | ◐ CRUD-Wand | AP1.2c Unterseiten |
+| Milestone | ◐ Tabelle | ✗ kein Gate | AP1.4 |
+| RoadmapItem | ✗ | ✗ | AP1.4 |
+| Plan vs. Ist | ✗ | ✗ | AP1.4–AP1.6 |
+| Steering / Lifecycle | ◐ | ◐ Snapshot | AP1.2 |
+| NextAction | ◐ API | ◐ Widget | AP1.2c konfigurierbar |
+| Portfolio-Priorität | ✗ | ✗ | AP1.8 |
+| Situativer Kontext | ✗ | ✗ | AP1.8 |
+| IA Workspace Portfolio | ✗ | ✗ | AP1.2c |
+| IA Initiative-Übersicht | ✗ | ✗ | AP1.2c |
+| IA Unterseiten | ✗ | ✗ | AP1.2c |
+| Modal/Detail-Bearbeitung | ✗ | ✗ | AP1.2c |
+| Operational Actor API | ✗ | ✗ | AP1.7 |
+| Project / Task | ○ / ✗ | ✗ | AP1.5 |
+| Journey | ✗ | ✗ | AP1.6 |
+
+---
+
+## 4. Dokumenten-Gap (behoben / offen)
+
+| Gap | Status |
+|-----|--------|
+| Zielbild vs. Ist vermischt | ◐ Welle 1 ✓, Welle 2 ◐ |
+| Roadmap suggerierte falsche Nähe zum Ziel | ◐ Roadmap v0.2 ✓ |
+| Kein Gate-ADP | ◐ Welle 2 |
+| Kein Agent-Interface-ADP | ◐ Welle 2 |
+| Target State ohne Implementierungs-Marker | ◐ Implementation Map v0.2 |
+
+---
+
+## 5. Zwingende nächste Schritte
+
+1. **DOC Welle 2 abschließen** (ADPs, Handover)  
+2. **AP1.2** — `operating_phase` entfernen  
+3. **AP1.2c** — IA-Skeleton (größter Produkt-Hebel)  
+4. **AP0.10d** — Validation mit neuen Fragen  
+5. **AP1.4** — nur nach PO-Go  
+
+---
+
+## 6. Risiko bei Verzögerung von IA
+
+Ohne AP1.2c:
+
+- weitere Features landen auf Omnibus-Seite  
+- Vibe-Coder bekommen keine klare API-Oberfläche  
+- Gate-Migration (AP1.4) baut auf falscher Navigation auf  
+
+---
+
+## 7. Empfehlung
+
+**Kein** AP1.1c, kein weiteres InitiativeDetail-Layout.
+
+**Ja:** Welle 2 Docs → AP1.2 → AP1.2c in einem Sprint-Fokus.
+
+---
+
+*v0.1 Gap-Matrix (AP0.6b) historisch — viele „fehlt“-Zeilen sind inzwischen API-erledigt, aber produktlich unzureichend.*
--- a/docs/architecture/Kairo_System_Target_State_Implementation_Map_v0.2.md
+++ b/docs/architecture/Kairo_System_Target_State_Implementation_Map_v0.2.md
@ -0,0 +1,73 @@
+# Kairo System Target State — Implementation Map v0.2
+
+**Status:** Ergänzung zu Target State v0.1  
+**Stand:** 2026-07-05  
+**Zielbild-Inhalt:** unverändert in `Kairo_System_Target_State_v0.1.md`  
+**Ist-Detail:** `Kairo_Implementation_Truth_Table_v0.1.md`
+
+---
+
+## Legende
+
+| Status | Bedeutung |
+|--------|-----------|
+| **target** | Nur dokumentiert — Zielbild |
+| **partial** | Anfang implementiert, Vision nicht erfüllt |
+| **done** | Für MVP-Ausschnitt ausreichend |
+| **n/a** | Bewusst später (Phase C+) |
+
+---
+
+## Kapitel-Mapping (Target State v0.1)
+
+| § | Thema | Status | Anmerkung |
+|---|-------|--------|-----------|
+| 1 | Executive Summary | target | Leitfrage ✓ in Steering |
+| 2 | Grundverständnis | target | — |
+| 3 | Produktidentität | partial | Program Director dokumentiert, UI To-do-artig |
+| 4 | Kernmodell | partial | Initiative/Action ✓; Roadmap ✗ |
+| 5 | Steering Core | partial | AP1.0 Skeleton |
+| 6 | Standard Lifecycle | partial | steering_contexts ✓; Hooks stub |
+| 7 | Steering Methods | partial | 2 Methoden registriert |
+| 8 | Method Registry | partial | Registry ✓; kein Designer |
+| 9 | Steering Domains | target | — |
+| 10 | Steerable Objects | partial | OM-Tabellen, nicht RoadmapItem |
+| 11 | Steering Context | done | Migration 009 |
+| 12 | Roadmap / Development Model | target | Milestone-Brücke only |
+| 13 | Roadmap vs Backlog vs Action | target | Konzept ✗ in UI |
+| 14 | Structure Builder | n/a | Phase C+ |
+| 15 | Hooks | partial | Stub AP1.0 |
+| 16 | Strategies | partial | next_action strategies minimal |
+| 17 | Signals | partial | AP1.0; AP1.2 konsolidieren |
+| 18 | Assignment / Waiting / Reminder | partial | Assignment ✓; Rest n/a |
+| 19 | Evidence / Review / Decision | partial | CRUD ✓; Gate-Verify ✗ |
+| 20 | Workflow-Fragmente | n/a | eingefroren |
+| 21 | Agenten / LLMs / Tools | partial | Actors ✓; AP1.7 API ✗ |
+| 22 | Security / Governance / Audit | partial | Auth/Cap ✓ |
+| 23 | UI-Zielbild | target | Vision §7; AP1.2c |
+| 24 | Architektur-Evolutionslinie | target | Roadmap v0.2 |
+| 25 | Zielzustand Satz | target | — |
+
+---
+
+## UI-Zielbild (§23) — Detail-Mapping Vision §7
+
+| Vision-Element | Target State | Implementierung |
+|----------------|--------------|-----------------|
+| Workspace Portfolio | §23 | ✗ → AP1.2c |
+| Initiative-Übersicht | §23 | ✗ → AP1.2c |
+| Unterseiten Plan/Ausführung/… | §23 | ✗ → AP1.2c |
+| Next-Action-Widget konfigurierbar | §16–17 | ◐ → AP1.2c |
+| Roadmap/Gates UI | §12–13 | ✗ → AP1.4 |
+| Journey | §19 | ✗ → AP1.6 |
+| Agent Interface | §21 | ✗ → AP1.7 |
+
+---
+
+## Nächste Status-Updates
+
+Nach jedem AP diese Map + Truth Table aktualisieren.
+
+---
+
+*Vollständiges Zielbild weiterhin: `Kairo_System_Target_State_v0.1.md`*
--- a/docs/product/DOCUMENTATION_REVISION_PROGRAM_v0.2.md
+++ b/docs/product/DOCUMENTATION_REVISION_PROGRAM_v0.2.md
@ -136,12 +136,14 @@ Schicht G — Reference / Design Principles  ← Nicht automatisch Scope

 ### Welle 2 — Zielbild präzisieren

- [ ] `Kairo_System_Target_State_v0.2.md` — pro Kapitel: Status `target | partial | not_started`
- [ ] `Kairo_Corrected_MVP_Roadmap_v0.2.md`
- [ ] `Kairo_MVP_Usability_Recovery_Plan_v0.2.md`
- [ ] ADP: `RoadmapItem_and_Quality_Gate_Model_v0.1.md` (neu)
- [ ] ADP: `Operational_Actor_Interface_Vibe_Coder_v0.1.md` (neu — API-Spec)
- [ ] `Sprint0_Vibe_Coder_Handover_v0.2.md` — IA + Operational Interface
+- [x] `Kairo_System_Target_State_Implementation_Map_v0.2.md` — pro Kapitel: Status target | partial | done
+- [x] `Kairo_Corrected_MVP_Roadmap_v0.2.md`
+- [x] `Kairo_MVP_Usability_Recovery_Plan_v0.2.md`
+- [x] `Kairo_Current_State_Gap_Analysis_v0.2.md`
+- [x] ADP: `ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md`
+- [x] ADP: `ADP_Operational_Actor_Interface_Vibe_Coder_v0.1.md`
+- [x] `Sprint0_Vibe_Coder_Handover_v0.2.md`
+- [x] `Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md`

 ### Welle 3 — Architektur-Konsolidierung

@ -151,7 +153,7 @@ Schicht G — Reference / Design Principles  ← Nicht automatisch Scope

 ### Welle 4 — Sprint & Handover

- [ ] `Sprint0_Vibe_Coder_Handover_v0.2.md`
+- [x] `Sprint0_Vibe_Coder_Handover_v0.2.md` (→ Welle 2)
 - [ ] Completion Reports: archiv-Banner
 - [ ] README.md — ehrlicher Produktstand

--- a/docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md
+++ b/docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md
@ -1,7 +1,7 @@
 # Jinkendo Kairo
 ## Corrected MVP Roadmap v0.1

-> **⚠ Superseded (2026-07-05):** Roadmap wird in Welle 2 als v0.2 überarbeitet. Bis dahin: [`Kairo_Vision_and_Product_Direction_v0.2.md`](Kairo_Vision_and_Product_Direction_v0.2.md) §11 und [`DOCUMENTATION_REVISION_PROGRAM_v0.2.md`](DOCUMENTATION_REVISION_PROGRAM_v0.2.md).
+> **⚠ Superseded (2026-07-05):** Verwende [`Kairo_Corrected_MVP_Roadmap_v0.2.md`](Kairo_Corrected_MVP_Roadmap_v0.2.md).

 Status: korrigierte Roadmap nach Product Reset  
 Stand: 2026-07-05
--- a/docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md
+++ b/docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md
@ -0,0 +1,214 @@
+# Jinkendo Kairo
+## Corrected MVP Roadmap v0.2
+
+**Status:** führende Produkt-Roadmap  
+**Stand:** 2026-07-05  
+**Ersetzt:** `Kairo_Corrected_MVP_Roadmap_v0.1.md`  
+**Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md`  
+**Ist-Stand:** `Kairo_Implementation_Truth_Table_v0.1.md`
+
+---
+
+## 1. Leitprinzipien
+
+1. **Vision vor UI-Patches** — keine Omnibus-CRUD-Seiten ausbauen  
+2. **IA vor Gate-Schema** — Routing/Shell vor RoadmapItem-Migration  
+3. **Steering in `backend/steering/`** — keine parallelen Heuristiken  
+4. **Plan vs. Ist** — RoadmapItem (Plan) getrennt von Action (Ist)  
+5. **Agenten = Actors** — Operational Interface, keine Sonderdomäne  
+
+---
+
+## 2. Phasenübersicht
+
+```text
+Phase 0  Foundation AP0.1–AP0.7, AP0.R1          ✓
+Phase A  OM-Inventar AP0.8–AP0.10                ✓ (technisch)
+Phase B  Steering Skeleton AP1.0–AP1.1b          ✓ (technisch)
+Phase C  Dokumentation Welle 1–2                 ◐ (Welle 2 jetzt)
+Phase D  IA-Skeleton AP1.2 + AP1.2c              ← NÄCHSTES CODE
+Phase E  Steering Härtung AP1.2, AP1.3           geplant
+Phase F  Gate-Modell AP1.4 + ADP                 geplant
+Phase G  Hierarchie & Plan/Ist AP1.5–AP1.6       geplant
+Phase H  Portfolio & Kontext AP1.8                 geplant
+Phase I  Agent Interface AP1.7                   geplant
+Phase J  Validation AP0.10d (laufend PO)           parallel
+```
+
+---
+
+## 3. Erledigt (Referenz)
+
+| Paket | Version | Kurz |
+|-------|---------|------|
+| AP0.1–AP0.7 | — | Runtime, Auth, Tenant, Actor, Capabilities, Data Layer |
+| AP0.8 | — | Backlog, Blocker, Milestone-Brücke, Attention/NextAction read |
+| AP0.9 | — | Evidence, Decision, Review, Recurring |
+| AP0.10b | 0.10.1 | NextAction/Heute-Widgets, Snapshot v2 |
+| AP1.0 | 0.11.0 | steering_contexts, backend/steering/, Lifecycle |
+| AP1.1 | 0.11.1 | Method Registry, product_milestone_driven |
+| AP1.1b | 0.11.2 | InitiativeDetail UX-Patch (**kein Zielbild** — Übergang) |
+| DOC Welle 1 | — | Vision v0.2, Canonical OM v0.2, Truth Table |
+
+---
+
+## 4. Nächste Pakete (verbindliche Reihenfolge)
+
+### DOC Welle 2 — Zielbild präzisieren ◐
+
+| # | Lieferung |
+|---|-----------|
+| 1 | Roadmap v0.2 (dieses Dokument) |
+| 2 | Recovery Plan v0.2 |
+| 3 | Gap Analysis v0.2 |
+| 4 | ADP RoadmapItem & Quality Gate |
+| 5 | ADP Operational Actor Interface |
+| 6 | Target State Implementation Map v0.2 |
+| 7 | Vibe-Coder Handover v0.2 |
+
+**Gate:** PO bestätigt Begriffe, IA, Reihenfolge → dann AP1.2c.
+
+---
+
+### AP1.2 — Signals konsolidieren
+
+**Ziel:** `operating_phase` entfernen; Snapshot nur Lifecycle + Signals.
+
+| Scope | |
+|-------|--|
+| ✓ | `operating_phase` aus Snapshot/API deprecate → entfernen |
+| ✓ | Signals in `backend/steering/signals/` konsolidieren |
+| ✓ | Tests, Truth Table aktualisieren |
+
+**Nicht:** neue UI, neue Tabellen.
+
+**Version:** `0.11.3-ap1.2`
+
+---
+
+### AP1.2c — IA-Skeleton (nächstes sichtbares Produktpaket)
+
+**Ziel:** Navigation und Shell gemäß Vision §7 — **ohne** neues Schema.
+
+| # | Lieferung |
+|---|-----------|
+| 1 | **Workspace** — Portfolio-Kacheln aller Initiativen + Attention |
+| 2 | **Initiative-Übersicht** — read-only Steuerung (Snapshot, Next Action, Blocker-Hinweis) |
+| 3 | **Routing** — `/initiatives/:id`, `/plan`, `/execution`, `/inbox`, `/journey` (Shell) |
+| 4 | **Next-Action-Widget** — konfigurierbar auf Workspace + Initiative-Übersicht |
+| 5 | **Modal/Detail-Pattern** — erste Objekt-Route z. B. `/actions/:id` |
+| 6 | Omnibus `InitiativeDetailPage` → Redirect auf neue Struktur |
+
+**Nicht:** RoadmapItem, Gate-Verify, Portfolio-Priorität-Feld, Agent-API.
+
+**Version:** `0.12.0-ap1.2c`
+
+---
+
+### AP0.10d — MVP Validation (parallel, PO)
+
+Testvorhaben: Kairo, Gewaltschutzkurs, Karate, Familienorganisation, Server/Mindnet.
+
+Vorlage: `Sprint0_AP0_10_Validation_Report_v0.1.md`
+
+**Go/No-Go** für Gate-Modell (AP1.4) — nicht für weiteres CRUD.
+
+---
+
+### AP1.3 — Hook Orchestrator
+
+**Ziel:** `operating_transitions` → Hook-Ausführung (stub → minimal).
+
+**Nach AP1.2.** Keine Workflow-Runtime.
+
+---
+
+### AP1.4 — RoadmapItem & Quality Gate (+ ADP)
+
+**Ziel:** Milestone-Brücke → RoadmapItem; Gate mit DoD, Dependencies, Verify.
+
+| Scope | |
+|-------|--|
+| Migration Roadmap + RoadmapItem (+ dependencies) |
+| Gate-Status `reached` nur via Evidence/Review |
+| Plan-Unterseite mit echten Gates |
+| Migration bestehender `milestones` |
+
+**ADP:** `ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md`
+
+**Version:** `0.13.0-ap1.4`
+
+---
+
+### AP1.5 — Hierarchie (Project, Task)
+
+Project GUI; Task unter Action (methodenabhängig minimal).
+
+---
+
+### AP1.6 — Plan/Ist & Journey
+
+Plan-Ist-Delta; Decision-Spur; Journey-Timeline auf Initiative.
+
+---
+
+### AP1.7 — Operational Actor Interface (Vibe-Coder)
+
+REST-API für Agent-Actors: Snapshot, Next Action, Status, Evidence, Blocker, Decision-Unterlagen.
+
+**ADP:** `ADP_Operational_Actor_Interface_Vibe_Coder_v0.1.md`
+
+**Nach AP1.2c + Capability für Agent-Auth.**
+
+---
+
+### AP1.8 — Portfolio-Priorität & situativer Kontext
+
+- `portfolio_priority` auf Initiative (oder Steuerungsobjekt)
+- Next-Action-Strategie: Portfolio-Prio × Dringlichkeit × **Situationskontext** (Actor)
+- Konfigurierbare Widget-Filter
+
+**Nicht:** Urlaubsplanung — situative Eignung von Arbeit (Vision §7.6).
+
+---
+
+## 5. Eingefroren / Nicht-Scope
+
+| Thema | Bis wann |
+|-------|----------|
+| Prompt/KI/MCP produktiv | Gate-Modell + IA |
+| Method Designer UI | AP1.3+ |
+| Gantt / Kalender | nach Plan/Ist |
+| Admin-Konsole | später |
+| Weitere InitiativeDetail-Refactors | **Stop** — nur Redirect zu IA |
+
+---
+
+## 6. MVP-Nutzbarkeit (neu, aus Vision)
+
+MVP-nah wenn:
+
+1. Workspace: Portfolio + Next Action (konfigurierbar) in ≤30s  
+2. Initiative-Übersicht: operative Steuerung ohne CRUD-Wand  
+3. Unterseiten: Pflege getrennt  
+4. Gate durchspielbar (nach AP1.4)  
+5. Validation ≥3/5 Vorhaben „hilft bei Steuerung“  
+
+---
+
+## 7. Versionslinie (Ausblick)
+
+```text
+0.11.2-ap1.1b  ✓ InitiativeDetail Patch
+0.11.3-ap1.2     Signals, operating_phase weg
+0.12.0-ap1.2c    IA-Skeleton
+0.13.0-ap1.4     RoadmapItem / Gates
+0.14.0-ap1.5     Hierarchie
+0.15.0-ap1.6     Journey / Plan-Ist
+0.16.0-ap1.7     Agent Interface
+0.17.0-ap1.8     Portfolio + Kontext
+```
+
+---
+
+*Siehe auch: `Kairo_MVP_Usability_Recovery_Plan_v0.2.md`, `Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md`*
--- a/docs/product/Kairo_MVP_Usability_Recovery_Plan_v0.1.md
+++ b/docs/product/Kairo_MVP_Usability_Recovery_Plan_v0.1.md
@ -1,6 +1,6 @@
 # Kairo — MVP Usability Recovery Plan

-> **⚠ Teilweise superseded (2026-07-05):** Strategie InitiativeDetail-Patching und AP-Reihenfolge → [`Kairo_Vision_and_Product_Direction_v0.2.md`](Kairo_Vision_and_Product_Direction_v0.2.md) und [`DOCUMENTATION_REVISION_PROGRAM_v0.2.md`](DOCUMENTATION_REVISION_PROGRAM_v0.2.md). Welle 2 liefert Recovery Plan v0.2.
+> **⚠ Superseded (2026-07-05):** Verwende [`Kairo_MVP_Usability_Recovery_Plan_v0.2.md`](Kairo_MVP_Usability_Recovery_Plan_v0.2.md).

 **Status:** Planungsdokument (Product Direction)  
 **Stand:** 2026-07-05  
--- a/docs/product/Kairo_MVP_Usability_Recovery_Plan_v0.2.md
+++ b/docs/product/Kairo_MVP_Usability_Recovery_Plan_v0.2.md
@ -0,0 +1,132 @@
+# Kairo — MVP Usability Recovery Plan v0.2
+
+**Status:** führende Produkt-Recovery-Strategie  
+**Stand:** 2026-07-05  
+**Ersetzt:** `Kairo_MVP_Usability_Recovery_Plan_v0.1.md` (Strategie InitiativeDetail-Patching)  
+**Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md`
+
+---
+
+## 1. Diagnose (aktualisiert nach AP1.1b)
+
+| Was Nutzer erwarten | Was Kairo heute liefert |
+|---------------------|-------------------------|
+| Portfolio-Überblick aller Vorhaben | Workspace-Widgets, **keine** Initiative-Portfolio-Kacheln |
+| Operative Steuerung pro Vorhaben auf **einer** Übersicht | AP1.1b verbessert Omnibus — **falsches Pattern** |
+| Plan/Pflege auf Unterseiten | Alles auf InitiativeDetail (teils „Erweitert“) |
+| Meilenstein = Quality Gate | CRUD mit Titel/Status |
+| Next Action quer + fokussiert | Feste Widgets, nicht konfigurierbar auf beiden Ebenen |
+| Portfolio-Priorität | ✗ |
+| Kontextpassende Next Action („unterwegs“) | ✗ |
+
+**Technisch:** Foundation + OM + Steering Skeleton ✓  
+**Produkt:** Vision-Distanz groß — Dokumentation Welle 1 korrigiert; **Implementierung folgt IA-Skeleton**.
+
+---
+
+## 2. MVP-Nutzbarkeits-Bar (v0.2)
+
+Kairo ist **minimal täglich nutzbar**, wenn ein Nutzer ohne Erklärung:
+
+1. Auf dem **Workspace** in ≤30s sieht: welches Vorhaben Aufmerksamkeit braucht + **nächste Schritte** (Widget, konfigurierbar).
+2. Auf der **Initiative-Übersicht** die Leitfrage beantwortet bekommt — **ohne** CRUD-Listen scrollen.
+3. Für Pflege/Anlage auf **Unterseiten** navigiert (Plan, Ausführung, Eingang).
+4. Backlog vs. Arbeitspaket unterscheidet und umwandeln kann (Unterseite Eingang).
+5. Blocker am **Objekt** sieht (Ausführung/Detail) — nicht nur lose Liste.
+
+**Nach AP1.4 zusätzlich:**
+
+6. Ein Gate mit DoD und Verifikation durchspielen kann.
+
+---
+
+## 3. Strategische Korrektur (gültig ab Welle 1)
+
+**Stop:** InitiativeDetail als Omnibus weiter ausbauen.
+
+**Start:** Drei-Ebenen-IA (Vision §7):
+
+```text
+Workspace (Portfolio)
+  → Initiative-Übersicht (Steuerung, Alltag)
+        → Unterseiten (Pflege, Planung)
+```
+
+**Recovery-Reihenfolge:**
+
+```text
+DOC Welle 2     Roadmap, ADPs, Handover           ◐ jetzt
+AP1.2           operating_phase weg, Signals       code
+AP1.2c          IA-Skeleton + Widgets              code ← größter UX-Hebel
+AP0.10d         Validation (PO)                    parallel
+AP1.4           Gates / RoadmapItem                nach IA
+AP1.7–AP1.8     Agent Interface, Portfolio/Kontext später
+```
+
+AP1.1b gilt als **technischer Übergang**, nicht als Recovery-Ziel.
+
+---
+
+## 4. Paket-Details (nächste Schritte)
+
+### AP1.2c — IA-Skeleton ★ Priorität 1 (Code)
+
+Siehe `Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md`.
+
+| Hebel | Nutzen |
+|-------|--------|
+| Workspace Portfolio | Endlich Querschnitt aller Initiativen |
+| Initiative-Übersicht read-only | Operative Steuerung ohne CRUD |
+| Next-Action-Widget ×2 | Workspace + Initiative, konfigurierbar |
+| Unterseiten-Routing | Pflege entkoppelt |
+| Redirect Omnibus | Kein Rückfall altes Pattern |
+
+---
+
+### AP1.2 — Signals ★ Priorität 2 (Code, parallel/kurz vor 2c)
+
+Kein UI — technische Schuld `operating_phase` beseitigen.
+
+---
+
+### AP0.10d — Validation ★ PO
+
+Mindestens Vorhaben „Kairo“ ausfüllen. Fragen anpassen:
+
+- Reicht Initiative-**Übersicht** für Steuerung?
+- Fehlt Plan/Gates oder nur Navigation?
+
+---
+
+## 5. Was bewusst warten muss
+
+| Thema | Warum |
+|-------|-------|
+| RoadmapItem / Gates | ADP + AP1.4 nach IA |
+| Portfolio-Priorität | AP1.8 |
+| Situativer Kontext | AP1.8 |
+| Vibe-Coder API | AP1.7 nach IA |
+| KI-Ranking | Regelbasiert + Kontext zuerst |
+| UI-Redesign | IA first |
+
+---
+
+## 6. Erfolgskriterien Go AP1.4
+
+1. AP1.2c deployed; Omnibus redirect aktiv  
+2. PO: Initiative-Übersicht reicht für **Steuerung** (nicht Pflege)  
+3. ≥2/5 Validation: „Workspace hilft bei Orientierung“ = ja  
+4. ADP RoadmapItem freigegeben  
+
+---
+
+## 7. Anti-Patterns (explizit)
+
+- ❌ Weitere Sektionen auf InitiativeDetail  
+- ❌ Inline-Formulare auf Übersichtsseiten  
+- ❌ Meilenstein-CRUD als Gate verkaufen  
+- ❌ Completion Report „grün“ = Vision erreicht  
+
+---
+
+*Roadmap: `Kairo_Corrected_MVP_Roadmap_v0.2.md`*
--- a/docs/sprints/Sprint0_Vibe_Coder_Handover_v0.1.md
+++ b/docs/sprints/Sprint0_Vibe_Coder_Handover_v0.1.md
@ -1,6 +1,8 @@
 # Jinkendo Kairo
 ## Sprint 0 – Vibe-Coder Handover v0.1

+> **⚠ Superseded (2026-07-05):** Verwende [`Sprint0_Vibe_Coder_Handover_v0.2.md`](Sprint0_Vibe_Coder_Handover_v0.2.md).
+
 Status: Übergabedokument  
 Stand: 2026-07-04

--- a/docs/sprints/Sprint0_Vibe_Coder_Handover_v0.2.md
+++ b/docs/sprints/Sprint0_Vibe_Coder_Handover_v0.2.md
@ -0,0 +1,119 @@
+# Jinkendo Kairo
+## Vibe-Coder Handover v0.2
+
+**Status:** Übergabedokument für Coding-Agenten & Vibe-Coder  
+**Stand:** 2026-07-05  
+**Ersetzt:** `Sprint0_Vibe_Coder_Handover_v0.1.md` (Foundation-only)  
+**Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md`
+
+---
+
+## 1. Auftrag
+
+Baue **keinen** weiteren Omnibus-CRUD-Screen.
+
+Baue Kairo als **Program Director** mit:
+
+1. **Workspace** — Portfolio aller Initiativen  
+2. **Initiative-Übersicht** — operative Steuerung (Alltag)  
+3. **Unterseiten** — Pflege und Anlage  
+4. **Operational API** (später AP1.7) — dieselbe Logik für Agent-Actors  
+
+---
+
+## 2. Verbindliche Dokumente (Lesereihenfolge)
+
+1. `docs/product/Kairo_Vision_and_Product_Direction_v0.2.md`
+2. `docs/product/Kairo_Canonical_Operating_Model_v0.2.md`
+3. `docs/product/Kairo_Implementation_Truth_Table_v0.1.md`
+4. `docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md`
+5. `docs/sprints/Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md` ← **nächster Code-Auftrag**
+6. `docs/architecture/ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`
+7. `CLAUDE.md` + `.cursor/rules/kairo-architecture.mdc`
+
+---
+
+## 3. IA — drei Ebenen
+
+```text
+/workspace                          Portfolio aller Initiativen
+/initiatives/:id                    Initiative-Übersicht (Steuerung, read-heavy)
+/initiatives/:id/plan               Plan (Shell → AP1.4 Daten)
+/initiatives/:id/execution          Ausführung / Arbeitspakete
+/initiatives/:id/inbox              Backlog
+/initiatives/:id/journey           Journey (Shell → AP1.6)
+/initiatives/:id/actions/:actionId  Arbeitspaket-Detail
+```
+
+**Regel:** Übersicht = navigieren + steuern. CRUD = Unterseiten oder Modal.
+
+---
+
+## 4. Vibe-Coder als Actor
+
+- Agent = `actors.actor_type = 'agent'`
+- Keine Sonder-Endpoints ohne `/api/operational/` (AP1.7)
+- Bis AP1.7: bestehende REST-APIs mit Actor-Session **nur** wenn Capability passt — Spec in `ADP_Operational_Actor_Interface_Vibe_Coder_v0.1.md`
+
+### Typischer Agent-Loop (Ziel)
+
+```text
+1. GET  operational/context?initiative_id=
+2. GET  operational/next-action?initiative_id=
+3. … arbeiten …
+4. PATCH operational/actions/{id}/status
+5. POST  operational/evidence (optional)
+6. POST  operational/blockers (wenn nötig)
+```
+
+---
+
+## 5. Harte Guardrails
+
+Nicht erlaubt:
+
+- InitiativeDetail Omnibus erweitern  
+- Inline-Formulare auf Workspace oder Initiative-Übersicht  
+- Parallele Steuerungslogik außerhalb `backend/steering/`  
+- Neue OM-Tabellen ohne ADP (Scope Lock)  
+- Gate `reached` per API ohne Verify  
+- Prompt/KI/MCP produktiv  
+
+---
+
+## 6. Arbeitsweise pro Paket
+
+1. Assignment lesen  
+2. Kurzplan  
+3. Implementieren (minimaler Diff)  
+4. Tests (Pi-pytest wo DB)  
+5. Truth Table + Gap Analysis aktualisieren  
+6. Version bump  
+7. Abweichung → ADP  
+
+---
+
+## 7. Nächste Pakete
+
+| Reihenfolge | Paket |
+|-------------|-------|
+| 1 | AP1.2c IA-Skeleton |
+| 2 | AP1.2 Signals |
+| 3 | AP0.10d Validation (PO) |
+| 4 | AP1.4 RoadmapItem (nach ADP-Freigabe) |
+| 5 | AP1.7 Operational API |
+
+---
+
+## 8. Erfolg
+
+Du bist auf dem richtigen Weg wenn:
+
+- PO auf Initiative-**Übersicht** steuern kann ohne zu pflegen  
+- Workspace alle Vorhaben orientiert  
+- Vibe-Coder wissen welche API kommt  
+- Docs und Code dieselbe IA zeigen  
+
+---
+
+*v0.1 Handover bleibt historisch für Sprint-0-Foundation.*
--- a/docs/sprints/Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md
+++ b/docs/sprints/Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md
@ -0,0 +1,169 @@
+# AP1.2c — IA-Skeleton (Workspace, Initiative-Übersicht, Unterseiten)
+## Implementierungsauftrag v0.1
+
+**Status:** bereit zur Umsetzung (nach DOC Welle 2)  
+**Stand:** 2026-07-05  
+**Vision:** `Kairo_Vision_and_Product_Direction_v0.2.md` §7  
+**Recovery:** `Kairo_MVP_Usability_Recovery_Plan_v0.2.md`  
+**Vorgänger:** AP1.1b ✓ (Redirect-Ziel)  
+**Zielversion:** `0.12.0-ap1.2c` · **kein** Schema-Change
+
+---
+
+## Ziel
+
+**Informationsarchitektur umsetzen** — ohne neues Fachmodell:
+
+- Workspace = Portfolio aller Initiativen  
+- Initiative-Übersicht = operative Steuerung (read-heavy)  
+- Unterseiten = Pflege (bestehende Sektionen **verschieben**, nicht duplizieren)  
+- Next-Action-Widget konfigurierbar auf Workspace **und** Initiative-Übersicht  
+
+---
+
+## Scope Lock
+
+- **Keine** neuen Tabellen  
+- **Keine** RoadmapItem / Gate-Logik  
+- **Keine** Portfolio-Priorität (AP1.8)  
+- **Keine** `/api/operational/` (AP1.7)  
+- Steering nur bestehende APIs  
+
+---
+
+## Teil A — Routing (React Router)
+
+Neue Routen:
+
+```text
+/                                   Workspace (überarbeiten)
+/initiatives/:id                    InitiativeOverviewPage (neu)
+/initiatives/:id/plan               InitiativePlanPage (Shell + MilestonesSection verschoben)
+/initiatives/:id/execution          InitiativeExecutionPage (ActionsHub)
+/initiatives/:id/inbox              InitiativeInboxPage (BacklogSection)
+/initiatives/:id/journey            InitiativeJourneyPage (Shell: Decisions/Reviews read)
+/actions/:id                        ActionDetailPage (Modal-Alternative: volle Seite)
+```
+
+Redirect:
+
+```text
+/initiatives/:id/detail  →  /initiatives/:id   (falls alte Links)
+```
+
+Alte `InitiativeDetailPage` → deprecate; Inhalt auf neue Pages **verteilen**.
+
+---
+
+## Teil B — Workspace (Portfolio)
+
+### B1 — Initiative-Portfolio-Widget
+
+- Kacheln oder kompakte Liste **aller** Initiativen des Tenants  
+- Pro Karte: Titel, Lifecycle-Badge, Method-Label, Kurzsignal (blockiert count, attention)  
+- Klick → `/initiatives/:id`  
+- Daten: bestehende `listInitiatives` + optional Snapshot-Summary (light endpoint oder parallel fetch — **kein** neues Backend nötig wenn Client parallel 5 Snapshots vermeidet: nur Initiative-Felder + counts aus workspace summary erweitern wenn nötig)
+
+### B2 — Next-Action-Widget (Workspace-Instanz)
+
+- Wiederverwendbare Komponente `NextActionWidget`  
+- Props: `scope: 'portfolio' | 'initiative'`, `initiativeId?`, `limit`, `filters`  
+- Portfolio: `/api/workspace/next-actions`  
+- Initiative: Snapshot `next_actions` oder Initiative-scoped API  
+
+### B3 — Layout-Registry
+
+- Widget konfigurierbar in Workspace-Layout (bestehende View/Widget Registry AP0.6 erweitern — minimal: feste Slots wenn Registry zu schwer)
+
+---
+
+## Teil C — Initiative-Übersicht (read-heavy)
+
+Neue `InitiativeOverviewPage`:
+
+| Block | Quelle | Bearbeitung |
+|-------|--------|-------------|
+| Breadcrumb + Titel | initiative | — |
+| Steering Hero | SteeringSnapshotPanel (read) | Methode wählen ✓ |
+| Next-Action-Widget | scope=initiative | — |
+| Roadblocker-Zusammenfassung | snapshot counts | Link → execution |
+| Meilenstein-Horizont | snapshot | Link → plan |
+| Nav-Karten | — | Links zu Unterseiten |
+
+**Keine** Backlog/Blocker/Evidence-Listen inline. **Keine** Create-Formulare.
+
+---
+
+## Teil D — Unterseiten (Pflege verschieben)
+
+| Page | Inhalt (aus InitiativeDetailPage) |
+|------|-----------------------------------|
+| Plan | `MilestonesSection` (+ später Roadmap) |
+| Execution | `InitiativeActionsHub` |
+| Inbox | `BacklogSection` |
+| Journey | Shell + `DecisionsSection`, `ReviewsSection` read; Recurring optional |
+
+Blockers/Evidence: primär am **ActionDetailPage**; vorhabenweite Blocker in Execution oder Inbox Sub-Sektion.
+
+---
+
+## Teil E — Action Detail
+
+- Route `/actions/:id` oder `/initiatives/:id/actions/:actionId`  
+- ActionHubCard-Inhalt + volle Bearbeitung (ActionForm)  
+- Verknüpfte Blocker/Evidence/Reviews CRUD  
+
+---
+
+## Teil F — Shared Components
+
+- `NextActionWidget.jsx`  
+- `InitiativeNavTabs.jsx` oder Subnav  
+- `InitiativePortfolioGrid.jsx`  
+- CSS: bestehende steering/action-hub Styles  
+
+---
+
+## Teil G — Tests
+
+- Frontend: Smoke-Routes rendern (vitest optional minimal)  
+- Backend: keine Pflicht (kein Schema)  
+- Manuell: Navigation Workspace → Initiative → Plan → Execution  
+
+---
+
+## Akzeptanzkriterien
+
+- [ ] Workspace zeigt **alle** Initiativen als Portfolio  
+- [ ] Initiative-Übersicht ohne CRUD-Listen (nur Steuerung + Links)  
+- [ ] Next-Action-Widget auf Workspace **und** Initiative-Übersicht  
+- [ ] Unterseiten erreichbar; Pflege funktioniert dort  
+- [ ] Alte Omnibus-URL redirected oder ersetzt  
+- [ ] Version `0.12.0-ap1.2c`  
+- [ ] Truth Table aktualisiert  
+
+---
+
+## Nicht-Scope
+
+- RoadmapItem  
+- Portfolio-Priorität Feld  
+- Journey-Timeline visual  
+- Agent API  
+- operating_phase (→ AP1.2)  
+
+---
+
+## Empfohlene Reihenfolge Implementierung
+
+1. Routing + leere Shell-Pages  
+2. InitiativeOverviewPage (Snapshot + Next Action)  
+3. Execution/Inbox/Plan (Sektionen verschieben)  
+4. Workspace Portfolio  
+5. NextActionWidget extrahieren  
+6. ActionDetailPage  
+7. Redirect + alte Page entfernen  
+
+---
+
+*Parallel empfohlen: AP1.2 (operating_phase entfernen) — kleiner Backend-PR vor oder nach 2c.*