AP0.R1: Product Reset Dokumente ins Repository aufgenommen

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

docs/architecture/CLAUDE_Product_Direction_Addendum_v0.1.md

@@ -0,0 +1,94 @@
+# CLAUDE.md Addendum
+## Kairo Product Direction Reset v0.1
+
+Dieses Addendum ist in `CLAUDE.md` aufzunehmen oder dort zu referenzieren.
+
+---
+
+## Current Product Direction
+
+Kairo is not a task list.
+
+Kairo is the operational Program Director of the Jinkendo product family.
+
+The central question is:
+
+> Which next step moves an initiative forward most effectively now?
+
+---
+
+## Do not reduce Kairo to
+
+```text
+Initiative
+  → Action
+```
+
+This is only the first technical slice.
+
+The canonical operating model includes:
+
+- Initiative
+- Project optional
+- Milestone
+- BacklogItem
+- Action
+- Assignment to Actor
+- Blocker
+- Decision
+- Evidence
+- Review
+- RecurringElement
+- AttentionItem
+- NextActionCandidate
+
+---
+
+## Current implementation state
+
+Valid but incomplete:
+
+- Tenant
+- Actor
+- TenantContext
+- Capabilities
+- Entitlements
+- Initiative
+- Action
+- Assignment
+- Workspace UX
+
+Missing MVP-critical concepts:
+
+- Data Layer
+- Actor Directory
+- Tenant Invariants
+- Backlog
+- Blocker
+- Milestone
+- Evidence
+- Review
+- Recurrence
+- Attention / Next Action
+
+---
+
+## Implementation rule
+
+Do not continue foundation work unless it directly supports MVP usability or prevents a documented refactoring trap.
+
+Do not continue prompt/AI/workflow/MCP work until the operating model MVP is restored.
+
+---
+
+## Gate for new tasks
+
+Every new task must answer:
+
+1. Does it support the operational Program Director vision?
+2. Does it improve real initiative steering?
+3. Does it prevent a concrete refactoring trap?
+4. Is it a small verifiable slice?
+5. Are non-goals explicit?
+
+If not, do not implement.

docs/architecture/Kairo_Current_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md

@@ -0,0 +1,210 @@
+# Jinkendo Kairo
+## Current State & Gap Analysis AP0.1–AP0.6b v0.1
+
+Status: Arbeitsstand / Reset-Grundlage  
+Stand: 2026-07-05
+
+---
+
+## 1. Zweck
+
+Dieses Dokument ordnet den aktuellen Implementierungsstand gegen das kanonische Kairo Operating Model ein.
+
+---
+
+## 2. Aktueller Stand
+
+### AP0.1 / AP0.1b
+
+Technische Runtime:
+
+- Deployment
+- Docker
+- FastAPI
+- PostgreSQL
+- Migration Runner
+- Health
+- Tests
+
+Bewertung: gültig.
+
+### AP0.2
+
+Auth, Identity, Tenant und Actor:
+
+- User
+- Sessions
+- Login/Logout
+- Tenant
+- Membership
+- Actor
+- TenantContext
+- Bootstrap
+- Audit bei Auth
+
+Bewertung: gültig und zentral.
+
+### AP0.3
+
+Capability / Rights Registry:
+
+- Capabilities
+- Grants
+- TenantContext.capabilities
+- require_capability
+- Entitlements Snapshot
+
+Bewertung: gültig und zentral.
+
+### AP0.4
+
+Prompt / Feature / Config Registry:
+
+- Feature Registry
+- PromptDefinition/Version/Step
+- Placeholder
+- Config
+- Single Render
+
+Bewertung: technisch brauchbar, aber aktuell eingefroren. Nicht weiter ausbauen, bis MVP-Fachkern trägt.
+
+### AP0.5
+
+Minimaler Vorhaben-/Maßnahmen-Slice:
+
+- Initiatives
+- Actions
+- Assignments
+- Status
+- Priority
+- Meine offenen Maßnahmen
+- Audit
+- Tests
+
+Bewertung: gültiger technischer Start, aber zu flach als Kairo-MVP.
+
+### AP0.6 / AP0.6b
+
+Workspace UX / PWA Remediation:
+
+- Jinkendo Look & Feel
+- App Shell
+- PWA-Grundlagen
+- responsive Desktop/Mobile
+- Widget/View Registry
+- Workspace/Vorhaben/Meine Maßnahmen
+
+Bewertung: gültig und notwendig für Produktprüfung.
+
+---
+
+## 3. Gap-Matrix
+
+| Konzept | Status | Bewertung |
+|---|---:|---|
+| Tenant | implementiert | gültig |
+| Actor | implementiert | Directory fehlt |
+| TenantContext | implementiert | gültig |
+| Capabilities | implementiert | gültig |
+| Initiative | implementiert | Status ggf. um draft ergänzen |
+| Action | implementiert | Status ggf. um ready/review_required ergänzen |
+| ActionAssignment | implementiert | ActorSelect braucht echtes Directory |
+| Project | fehlt | optional, aber Modell muss vorbereitet werden |
+| Milestone | fehlt | MVP-relevant minimal |
+| BacklogItem | fehlt | MVP-relevant |
+| Blocker | fehlt | MVP-relevant |
+| Evidence | fehlt | MVP-relevant minimal |
+| Decision | fehlt | MVP-relevant minimal |
+| Review | fehlt | MVP-relevant minimal |
+| RecurringElement | fehlt | MVP-relevant vorbereiten |
+| NextActionCandidate | fehlt | MVP-kritisches Read Model |
+| AttentionItem | fehlt | MVP-kritisches Read Model |
+| Data Layer | fehlt | Umbaufalle |
+| Tenant Invariants Doc | fehlt | Umbaufalle |
+| Actor Directory | fehlt | Actor-first nicht vollständig |
+| Prompt Workflow | vorbereitet | nicht MVP-kritisch |
+| MCP | fehlt | später |
+| KI-Priorisierung | fehlt | später |
+
+---
+
+## 4. Was bleibt gültig?
+
+Gültig bleiben:
+
+- technische Runtime
+- Auth
+- Tenant
+- Actor
+- Capability Registry
+- Entitlements
+- Prompt Kernel als eingefrorene Vorleistung
+- Initiative/Action als erster Slice
+- Jinkendo Workspace UX
+- Widget/View Registry
+
+---
+
+## 5. Was muss korrigiert werden?
+
+Korrigiert werden muss die implizite Produktlinie.
+
+Die aktuelle UI und API dürfen nicht den Eindruck erzeugen:
+
+```text
+Kairo = Vorhaben + Aufgaben
+```
+
+Kairo muss sichtbar werden als:
+
+```text
+Kairo = operative Steuerung von Vorhaben
+```
+
+---
+
+## 6. Zwingende nächste Grundlagen
+
+Vor weiterem Fachausbau:
+
+1. Tenant Invariants
+2. Actor Directory
+3. Data Layer Minimum
+4. Attention/Next-Action Read Model
+5. Operating Model Extension I
+
+---
+
+## 7. Nächste Implementierungsvorschläge
+
+### AP0.7 — Tenant Hardening, Actor Directory & Data Layer Minimum
+
+Klein halten, aber zwingend.
+
+### AP0.8 — Operating Model Extension I
+
+BacklogItem, Blocker, Milestone minimal, Attention Items.
+
+### AP0.9 — Operating Model Extension II
+
+Evidence, Decision, Review, RecurringElement minimal.
+
+---
+
+## 8. Risiko, wenn wir nicht korrigieren
+
+Ohne Korrektur wird Kairo:
+
+- eine bessere To-do-Liste
+- ein generischer Workspace
+- technisch überfundiert
+- fachlich zu flach
+- später schwer auf Program Director umzubauen
+
+---
+
+## 9. Empfehlung
+
+Keine weitere Prompt-/Foundation-/Admin-Arbeit starten.
+
+Erst kanonisches Operating Model und Data Layer wieder in die Implementierungsroadmap bringen.

docs/product/Kairo_Canonical_Operating_Model_v0.1.md

@@ -0,0 +1,378 @@
+# Jinkendo Kairo
+## Canonical Operating Model v0.1
+
+Status: kanonisches Produktmodell  
+Stand: 2026-07-05
+
+---
+
+## 1. Zweck
+
+Dieses Dokument definiert das kanonische Operating Model von Kairo.
+
+Es verhindert, dass Kairo auf eine einfache To-do- oder Projektliste reduziert wird.
+
+---
+
+## 2. Leitfrage
+
+> Welcher nächste Schritt bringt ein Vorhaben aktuell am wirkungsvollsten voran?
+
+Alle Objekte, Views und Datenmodelle müssen mittelbar auf diese Frage einzahlen.
+
+---
+
+## 3. Operating Cycle
+
+Kairo folgt einem wiederkehrenden Steuerungszyklus:
+
+```text
+Capture
+  → Triage
+    → Structure
+      → Commit
+        → Execute
+          → Verify
+            → Review
+              → Adapt
+                → Next Action
+```
+
+### Capture
+
+Ideen, Risiken, Aufgaben, Nachweise und Beobachtungen werden erfasst.
+
+### Triage
+
+Eingänge werden eingeordnet:
+
+- sofortige Maßnahme?
+- Backlog?
+- Blocker?
+- Entscheidung?
+- Nachweis?
+- Review-Thema?
+
+### Structure
+
+Arbeit wird an Vorhaben, Projekte, Meilensteine oder Maßnahmen angebunden.
+
+### Commit
+
+Eine Maßnahme wird konkret zugewiesen und erhält Status, Priorität und ggf. Fälligkeit.
+
+### Execute
+
+Actors arbeiten Maßnahmen ab.
+
+### Verify
+
+Fortschritt wird durch Nachweise oder Statusänderungen belegbar.
+
+### Review
+
+Der Zustand eines Vorhabens wird bewertet.
+
+### Adapt
+
+Backlog, Maßnahmen, Blocker oder Meilensteine werden angepasst.
+
+### Next Action
+
+Kairo zeigt, was jetzt Aufmerksamkeit oder Umsetzung braucht.
+
+---
+
+## 4. Objektmodell
+
+```text
+Tenant
+  └── Actor
+        └── Initiative
+              ├── Project optional
+              │     └── Milestone
+              ├── Milestone
+              ├── BacklogItem
+              ├── Action
+              │     ├── ActionAssignment
+              │     ├── Blocker
+              │     └── Evidence
+              ├── Decision
+              ├── Review
+              ├── RecurringElement
+              └── AttentionItem / NextActionCandidate
+```
+
+---
+
+## 5. Objektdefinitionen
+
+### Tenant
+
+Abgegrenzter Nutzungsraum.
+
+Alle fachlichen Objekte sind tenant-scoped, sofern nicht explizit global.
+
+### Actor
+
+Operative Verantwortungseinheit.
+
+Typen:
+
+- human
+- agent
+- working_group
+- external_system
+
+Zuweisungen erfolgen an Actors, nicht an Users.
+
+### Initiative
+
+Ein aktives Vorhaben mit Zielzustand.
+
+### Project
+
+Optionale Unterstruktur für größere Vorhaben.
+
+### Milestone
+
+Überprüfbarer Zielpunkt.
+
+Kein Task.
+
+### BacklogItem
+
+Noch nicht freigegebener Handlungsbedarf.
+
+### Action
+
+Konkrete operative Maßnahme.
+
+### ActionAssignment
+
+Zuweisung einer Maßnahme an einen oder mehrere Actors.
+
+### Blocker
+
+Hindernis, das Fortschritt verhindert oder gefährdet.
+
+### Evidence
+
+Nachweis für Fortschritt, Abschluss oder Entscheidung.
+
+### Decision
+
+Dokumentierte Auswahl zwischen Optionen.
+
+### Review
+
+Strukturierte Bewertung eines Scopes.
+
+### RecurringElement
+
+Regelmäßig wiederkehrender Arbeits- oder Review-Bedarf.
+
+### AttentionItem
+
+Read Model, das Aufmerksamkeit auf relevante Steuerungspunkte lenkt.
+
+### NextActionCandidate
+
+Read Model, das mögliche nächste sinnvolle Aktionen aus dem aktuellen Zustand ableitet.
+
+---
+
+## 6. Statusmodelle minimal
+
+### Initiative
+
+- draft
+- active
+- paused
+- completed
+- archived
+
+### Project
+
+- planned
+- active
+- paused
+- completed
+- archived
+
+### Milestone
+
+- planned
+- active
+- at_risk
+- reached
+- moved
+- discarded
+
+### BacklogItem
+
+- new
+- triaged
+- accepted
+- rejected
+- converted
+
+### Action
+
+- open
+- ready
+- in_progress
+- blocked
+- review_required
+- done
+- discarded
+
+### Blocker
+
+- open
+- in_progress
+- resolved
+- accepted_risk
+- dismissed
+
+### Review
+
+- planned
+- completed
+- skipped
+
+### RecurringElement
+
+- active
+- paused
+- ended
+
+---
+
+## 7. Next Action / Attention Logic
+
+Kairo muss eine regelbasierte erste Attention-Schicht bereitstellen, bevor KI eingesetzt wird.
+
+Minimalregeln:
+
+1. Blockierte Maßnahmen sichtbar machen
+2. High-Priority offene Maßnahmen sichtbar machen
+3. Maßnahmen ohne Assignment sichtbar machen
+4. Vorhaben ohne offene nächste Maßnahme sichtbar machen
+5. lange unveränderte Vorhaben sichtbar machen
+6. Meilensteine mit Status `at_risk` sichtbar machen
+7. überfällige Elemente sichtbar machen, sobald Due Dates existieren
+8. fällige Reviews sichtbar machen
+9. wiederkehrende Elemente mit `next_due_at` sichtbar machen
+
+---
+
+## 8. Data-Layer-Prinzip
+
+Kairo benötigt für Operating-Model-Sichten einen read-orientierten Data Layer.
+
+Router beantworten HTTP.
+
+Services schreiben Domänenobjekte.
+
+Data Layer bereitet Steuerungs- und Workspace-Sichten auf:
+
+```text
+data_layer.workspace
+data_layer.actions
+data_layer.initiatives
+data_layer.attention
+data_layer.actors
+```
+
+Data Layer ist nicht:
+
+- Analytics-Plattform
+- KI-System
+- Reporting-Engine
+- Ersatz für Services
+
+---
+
+## 9. UI-Prinzip
+
+Die UI soll nicht nur Tabellen zeigen.
+
+Sie muss Steuerungsfragen sichtbar machen:
+
+- Was ist aktiv?
+- Was ist blockiert?
+- Was braucht Aufmerksamkeit?
+- Was ist meine nächste Arbeit?
+- Wo fehlt Struktur?
+- Wo fehlt Nachweis?
+- Was wurde entschieden?
+- Was muss reviewt werden?
+
+---
+
+## 10. MVP-relevante Sichten
+
+MVP-Sichten:
+
+1. Workspace
+2. Meine Maßnahmen
+3. Vorhaben
+4. Vorhaben-Detail
+5. Backlog
+6. Attention / Next Action
+7. Blocker
+8. einfache Review-/Nachweis-Sicht
+
+Nicht-MVP-Sichten:
+
+- Gantt
+- Kalender
+- komplexe Portfolio-Reports
+- AI Chat
+- Workflow Designer
+- Admin-Konsole
+
+---
+
+## 11. Agenten-Regel
+
+Agenten dürfen später:
+
+- Status melden
+- Fortschritt melden
+- Backlog Items vorschlagen
+- Nachweise einreichen
+- Blocker melden
+- Reviews anfordern
+- Next Action Empfehlungen erzeugen
+
+Agenten dürfen nicht ohne menschliche Freigabe:
+
+- Ziele ändern
+- Meilensteine verschieben
+- strategische Priorität ändern
+- Rechte ändern
+- Prompts produktiv ändern
+- Vorhaben löschen
+
+---
+
+## 12. Minimaler MVP-Zustand
+
+Kairo ist MVP-nah, wenn ein Nutzer reale Vorhaben führen kann mit:
+
+- Vorhaben
+- Maßnahmen
+- Assignments
+- Backlog
+- Blocker
+- Meilenstein minimal
+- Nachweis minimal
+- Review minimal
+- wiederkehrender Check minimal
+- Attention-/Next-Action-Sicht
+- Jinkendo Workspace UX
+- Tenant/Actor/Data-Layer-Sicherheit
+
+Nicht vorher.

docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md

@@ -0,0 +1,126 @@
+# Jinkendo Kairo
+## Corrected MVP Roadmap v0.1
+
+Status: korrigierte Roadmap nach Product Reset  
+Stand: 2026-07-05
+
+---
+
+## AP0.R — Product & MVP Reset
+
+Status: dieses Paket.
+
+Artefakte:
+
+- `Kairo_Product_Definition_and_MVP_Reset_v0.1.md`
+- `Kairo_Canonical_Operating_Model_v0.1.md`
+- `Kairo_Current_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md`
+- `CLAUDE_Product_Direction_Addendum_v0.1.md`
+
+---
+
+## AP0.7 — Tenant Hardening, Actor Directory & Data Layer Minimum
+
+Ziel:
+
+- Mandantenfähigkeit absichern
+- Actor-first in der UI nutzbar machen
+- Data Layer als read-orientierte Grundlage einführen
+
+Scope:
+
+- Tenant-Invarianten
+- GET /api/actors
+- ActorSelect mit echter Actor-Liste
+- Data Layer: workspace, actions, initiatives, actors
+- Workspace Summary
+- blocked actions
+- active initiatives
+- actor workload basic
+- Tests gegen Cross-Tenant-Leaks
+
+Nicht-Scope:
+
+- neue Operating-Model-Objekte
+- Prompt/KI
+- Admin-Konsole
+- MCP
+
+---
+
+## AP0.8 — Operating Model Extension I
+
+Ziel:
+
+Kairo über To-do-Funktion hinausheben.
+
+Scope:
+
+- BacklogItem
+- Blocker
+- Milestone minimal
+- AttentionItem / NextActionCandidate read model
+- Workspace zeigt Attention Items
+
+Nicht-Scope:
+
+- vollständige Projektplanung
+- Reviews
+- Evidence
+- Recurrence Engine
+- KI-Priorisierung
+
+---
+
+## AP0.9 — Operating Model Extension II
+
+Ziel:
+
+Steuerung und Nachvollziehbarkeit ermöglichen.
+
+Scope:
+
+- Evidence minimal
+- Decision minimal
+- Review minimal
+- RecurringElement vorbereitet
+- Review erzeugt Backlog/Action optional noch nicht vollautomatisch
+
+Nicht-Scope:
+
+- komplexe Review-Workflows
+- Kalenderintegration
+- LLM
+- MCP
+
+---
+
+## AP0.10 — MVP Validation Slice
+
+Ziel:
+
+Kairo mit echten Vorhaben testen.
+
+Testvorhaben:
+
+- Kairo Entwicklung
+- Gewaltschutzkurs
+- Karate Training
+- Familienorganisation
+- Server/Mindnet Betrieb
+
+Prüffragen:
+
+- Hilft Kairo bei der täglichen Steuerung?
+- Ist die nächste sinnvolle Aktion sichtbar?
+- Werden Blocker früh erkannt?
+- Sind Backlog und Maßnahme sauber getrennt?
+- Sind Reviews/Nachweise verständlich?
+- Ist die UI praktisch?
+- Was fehlt wirklich als nächstes?
+
+---
+
+## Sprint 1 erst nach AP0.10
+
+Sprint 1 startet erst, wenn der MVP-Kern anhand realer Vorhaben geprüft wurde.

docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md

@@ -0,0 +1,487 @@
+# Jinkendo Kairo
+## Product Definition & MVP Reset v0.1
+
+Status: Steuerungsdokument / kanonischer Reset  
+Stand: 2026-07-05  
+Zweck: Wiederherstellung der ursprünglichen Kairo-Produktlinie nach AP0.1–AP0.6b
+
+---
+
+## 1. Warum dieses Dokument existiert
+
+Kairo ist in der Umsetzung zwischen zwei Polen gependelt:
+
+1. **zu viel Foundation ohne direkte Produktprüfbarkeit**
+2. **zu starke Reduktion auf Vorhaben → Maßnahme**
+3. **nachträgliches Erkennen wichtiger Basisprinzipien wie Mandantenfähigkeit, Actor Directory und Data Layer**
+
+Dadurch entstand das Risiko, dass Kairo technisch solide wird, aber die ursprüngliche Produktidee verliert.
+
+Dieses Dokument setzt die frühere Produktdefinition wieder als führende Quelle ein und leitet daraus einen korrigierten MVP-Pfad ab.
+
+---
+
+## 2. Führende Produktdefinition
+
+Führende Grundlage bleibt:
+
+```text
+docs/product/Jinkendo_Kairo_Product_Spec_v0.2.md
+```
+
+Diese Spezifikation ist nicht vollständig, aber sie enthält die wesentlichen Produktgrenzen:
+
+- Kairo ist kein To-do-Tool.
+- Kairo ist kein reines Projektmanagement-Tool.
+- Kairo ist kein Prompt-/AI-System.
+- Kairo ist kein Lebensentwicklungsprodukt.
+- Kairo ist der operative Program Director der Jinkendo-Produktfamilie.
+
+---
+
+## 3. Ursprüngliche Produktvision
+
+**Jinkendo Kairo** ist der operative Program Director für Vorhaben, Programme, Projekte, Meilensteine, Maßnahmen, Backlogs, Reviews, Nachweise und die Zusammenarbeit von Menschen, Teams und später KI-Agenten.
+
+Die zentrale Leitfrage lautet:
+
+> Welcher nächste Schritt bringt ein Vorhaben aktuell am wirkungsvollsten voran?
+
+Kairo soll nicht nur Aufgaben speichern, sondern operative Steuerung leisten.
+
+---
+
+## 4. Was Kairo nicht sein darf
+
+Kairo darf nicht auf folgende Formen reduziert werden:
+
+```text
+Tenant
+  → Initiative
+    → Action
+```
+
+Das ist als technischer Startpunkt akzeptabel, aber kein Kairo-MVP.
+
+Ein solches Modell wäre weniger als viele To-do-Listen können und verfehlt den Program-Director-Anspruch.
+
+Kairo darf außerdem nicht werden:
+
+- eine bloße CRUD-Anwendung
+- ein Aufgabenboard ohne Steuerungslogik
+- ein generisches Dashboard
+- eine Prompt-/AI-Workbench
+- ein Admin-Framework
+- ein Lebensmanager ohne operative Schärfe
+- eine Kopie von Mitai oder Shinkan
+
+---
+
+## 5. Kanonisches Operating Model
+
+Kairo benötigt ein Operating Model, das Struktur, Steuerung und Lernen verbindet.
+
+Kanonischer Zielzusammenhang:
+
+```text
+Vorhaben / Initiative
+  ├── Programm optional
+  ├── Projekt optional
+  ├── Meilenstein
+  ├── Backlog Item
+  ├── Maßnahme / Action
+  │     ├── Assignment an Actor
+  │     ├── Status
+  │     ├── Priorität
+  │     ├── Fälligkeit / Zieltermin optional
+  │     ├── Blocker optional
+  │     └── Nachweise optional
+  ├── Blocker
+  ├── Entscheidung
+  ├── Nachweis / Evidence
+  ├── Review
+  ├── Wiederkehrendes Element
+  └── Next Action / Attention Item
+```
+
+Nicht jedes Vorhaben braucht alle Ebenen.
+
+Aber das Modell muss diese Konzepte tragen können, ohne später grundlegend umgebaut zu werden.
+
+---
+
+## 6. Kernobjekte und Bedeutung
+
+### Initiative / Vorhaben
+
+Ein Vorhaben ist eine aktiv verfolgte Veränderung oder ein angestrebter Zielzustand.
+
+Es ist mehr als ein Container für Aufgaben.
+
+Es benötigt:
+
+- Ziel / Goal
+- Status
+- Priorität
+- Owner Actor
+- aktuelle Maßnahmen
+- offene Risiken / Blocker
+- Backlog
+- ggf. Meilensteine
+- Fortschritts- und Attention-Sicht
+
+### Project / Projekt
+
+Ein Projekt ist eine optionale Struktur innerhalb eines Vorhabens.
+
+Es ist sinnvoll, wenn ein Vorhaben mehrere Ergebnisstränge hat.
+
+Projekte sind für den MVP nicht zwingend voll auszubauen, aber das Modell muss sie zulassen.
+
+### Milestone / Meilenstein
+
+Ein Meilenstein ist ein überprüfbarer Zielpunkt.
+
+Er ist keine Aufgabe.
+
+Ein MVP-naher Meilenstein braucht mindestens:
+
+- Titel
+- Zielbeschreibung
+- Status
+- Zieltermin optional
+- Bezug zu Vorhaben oder Projekt
+
+### Action / Maßnahme
+
+Eine Maßnahme ist die kleinste operative Arbeitseinheit.
+
+Sie ist konkret, zuweisbar und statusfähig.
+
+Sie ist nicht identisch mit Backlog Item.
+
+### Backlog Item
+
+Ein Backlog Item ist ein möglicher Handlungsbedarf.
+
+Es kann sein:
+
+- Idee
+- Verbesserung
+- Risiko
+- Vorschlag
+- Bug
+- später zu prüfende Aufgabe
+
+Es ist noch nicht automatisch zur Umsetzung freigegeben.
+
+### Blocker
+
+Ein Blocker verhindert oder gefährdet Fortschritt.
+
+Blocker müssen sichtbar sein, weil sie eine andere Steuerungsreaktion brauchen als normale offene Aufgaben.
+
+### Decision / Entscheidung
+
+Eine Entscheidung dokumentiert eine Auswahl zwischen Optionen.
+
+Kairo braucht Entscheidungen, weil operative Steuerung sonst nicht nachvollziehbar bleibt.
+
+### Evidence / Nachweis
+
+Ein Nachweis belegt Fortschritt, Abschluss oder Entscheidung.
+
+Beispiele:
+
+- Link
+- Datei
+- Commit
+- Dokument
+- Review-Ergebnis
+- externe Bestätigung
+- kurzer Textnachweis
+
+### Review
+
+Ein Review ist ein strukturierter Reflexions- und Steuerungspunkt.
+
+Reviews erzeugen:
+
+- Entscheidungen
+- Maßnahmen
+- Backlog Items
+- Blocker
+- Nachweise
+- Anpassungen am Vorhaben
+
+### Recurring Element / Wiederkehrendes Element
+
+Kairo muss wiederkehrende operative Arbeit abbilden können.
+
+Beispiele:
+
+- wöchentlicher Statuscheck
+- monatliches Review
+- wiederkehrende Wartung
+- regelmäßige Familien-/Projektaufgabe
+- periodischer Agenten-Report
+
+### Next Action / Attention Item
+
+Das ist ein Kernkonzept.
+
+Kairo muss nicht sofort „intelligent“ sein, aber es muss erkennen können:
+
+- Was ist offen?
+- Was ist blockiert?
+- Was ist dringend?
+- Was ist ohne Zuweisung?
+- Welches Vorhaben hat keine nächste Maßnahme?
+- Wo fehlt ein Review?
+- Wo ist ein Meilenstein gefährdet?
+- Was braucht jetzt Aufmerksamkeit?
+
+---
+
+## 7. Der korrigierte MVP
+
+Der MVP darf nicht „vollständig“ sein.
+
+Aber er muss Kairo als operativen Program Director erkennbar machen.
+
+### MVP muss können
+
+1. Vorhaben strukturiert erfassen
+2. Maßnahmen zuweisen und verfolgen
+3. Backlog Items getrennt von Maßnahmen führen
+4. Blocker sichtbar machen
+5. einfache Meilensteine abbilden
+6. Nachweise einfach erfassen
+7. Reviews minimal dokumentieren
+8. wiederkehrende Elemente vorbereiten
+9. eine Attention-/Next-Action-Sicht erzeugen
+10. Mandanten- und Actor-Modell sauber einhalten
+11. Workspace nutzbar auf Desktop und Mobile darstellen
+
+### MVP muss noch nicht können
+
+- komplexe Projektplanung
+- Gantt
+- Kalenderintegration
+- KI-Priorisierung
+- MCP
+- LLM Workflows
+- vollständige Pipeline Engine
+- Billing
+- SSO
+- mandantenübergreifende Reports
+- komplexe Rechteverwaltung
+- vollständige Admin-Konsole
+- vollwertige Offline-PWA
+- umfassende Analytics
+
+---
+
+## 8. Aktueller Implementierungsstand AP0.1–AP0.6b
+
+### Bereits gültig und wertvoll
+
+AP0.1–AP0.6b haben wichtige Grundlage geschaffen:
+
+- Deployment Dev/Prod
+- FastAPI / PostgreSQL / Migrationen / Tests
+- Auth und Sessions
+- Tenant / Membership
+- Actor-Modell
+- TenantContext
+- Capability Registry
+- Entitlements
+- Feature Registry
+- Prompt-/Config Registry
+- Audit-Grundlage
+- Initiative
+- Action
+- Action Assignment
+- Status / Priorität
+- „Meine offenen Maßnahmen“
+- Workspace GUI
+- Jinkendo UX/PWA-Basis
+- Widget/View Registry
+
+Diese Arbeit wird nicht verworfen.
+
+### Zu flach oder unvollständig
+
+Der aktuelle fachliche Slice ist jedoch zu flach:
+
+```text
+Initiative
+  → Action
+```
+
+Es fehlen wichtige Kairo-Konzepte:
+
+- Backlog Item
+- Blocker
+- Milestone
+- Evidence
+- Review
+- Decision
+- Recurring Element
+- Next Action / Attention Layer
+- Data Layer für verdichtete Sichten
+- echtes Actor Directory
+- konsequent dokumentierte Tenant-Invarianten
+
+---
+
+## 9. Was jetzt nicht weiter ausgebaut werden soll
+
+Bis der MVP-Kern wieder ausgerichtet ist, werden folgende Themen eingefroren:
+
+- Prompt Engine Erweiterungen
+- Pipeline Engine
+- Workflow Engine
+- LLM Provider Routing
+- MCP
+- komplexe Admin UI
+- Billing
+- Feature Limits
+- SSO
+- zentrale Familien-Konvergenz
+- Mitai/Shinkan-Angleichung
+- Dashboard-Plattform
+- Drag & Drop Widgets
+- komplexe Analytics
+
+Diese Themen bleiben Architektur-Backlog.
+
+---
+
+## 10. Foundation, die noch zwingend fehlt
+
+Nicht jede Foundation fehlt.
+
+Aber drei Grundlagen müssen jetzt noch abgesichert werden, weil sie sonst spätere Umbaufallen erzeugen:
+
+### 10.1 Tenant Hardening
+
+Kairo muss verbindliche Tenant-Invarianten dokumentieren und testen.
+
+### 10.2 Actor Directory
+
+Actor-first funktioniert nur, wenn Actors sauber sichtbar und auswählbar sind.
+
+### 10.3 Data Layer Minimum
+
+Kairo braucht eine zentrale read-orientierte Schicht für Workspace, Attention und spätere Program-Director-Sichten.
+
+Diese drei Themen dürfen aber nicht als neues Foundation-Projekt ausufern.
+
+Sie müssen direkt auf die MVP-Steuerung einzahlen.
+
+---
+
+## 11. Korrigierte nächste Roadmap
+
+### AP0.R — Product & MVP Reset
+
+Status: dieses Dokument.
+
+Ziel: Produktlinie wiederherstellen.
+
+### AP0.7 — Tenant Hardening, Actor Directory & Data Layer Minimum
+
+Ziel:
+
+- Tenant-Invarianten
+- echte Actor-Liste
+- zentrale read-orientierte Workspace-/Attention-Daten
+- keine verstreuten Aggregationen
+
+### AP0.8 — Operating Model Extension I
+
+Ziel:
+
+- Backlog Item
+- Blocker
+- Milestone minimal
+- Workspace Attention Items
+
+### AP0.9 — Operating Model Extension II
+
+Ziel:
+
+- Evidence
+- Decision
+- Review minimal
+- Recurring Element vorbereiten
+
+### AP0.10 — MVP Usability Validation
+
+Ziel:
+
+- reale Vorhaben testen
+- Begriffe prüfen
+- UX prüfen
+- fehlende Kernfunktion auswählen
+- Sprint 1 bewusst starten
+
+---
+
+## 12. Entscheidungs-Gate für neue Arbeitspakete
+
+Jeder neue Coding-Auftrag muss vorab diese Fragen beantworten:
+
+1. Stützt er die ursprüngliche Kairo-Vision?
+2. Macht er Kairo als operativen Program Director nutzbarer?
+3. Verhindert er eine konkrete Umbaufalle?
+4. Ist er kleiner als ein klar prüfbarer Slice?
+5. Sind Nicht-Ziele ausdrücklich genannt?
+6. Werden Prompt/KI/Foundation-Themen nicht unnötig vorgezogen?
+7. Bleibt Tenant/Actor/Capability/Data-Layer sauber?
+
+Wenn diese Fragen nicht klar beantwortet werden können, wird der Auftrag nicht gestartet.
+
+---
+
+## 13. Aktualisierte Leitlinie für Coding-Agenten
+
+Coding-Agenten sollen nicht nur „das nächste kleine technische Ticket“ bearbeiten.
+
+Sie müssen gegen folgende Leitlinie arbeiten:
+
+```text
+Kairo is not a task list.
+Kairo is an operational program director.
+Every implementation step must preserve the operating model:
+initiative, structure, backlog, blocker, evidence, review, recurrence, next action, actor responsibility and tenant safety.
+```
+
+---
+
+## 14. Was ab jetzt als Drift gilt
+
+Drift liegt vor, wenn ein Auftrag:
+
+- Kairo weiter in Richtung To-do-Liste reduziert
+- neue Foundation ohne direkten MVP-Nutzen baut
+- Prompt/KI vorzieht
+- UI-Features ohne Operating-Model-Relevanz baut
+- Mitai/Shinkan-Domänenlogik übernimmt
+- Tenant/Actor/Data-Layer-Prinzipien ignoriert
+- Backlog, Blocker, Review, Evidence oder Next Action weiter verdrängt
+
+---
+
+## 15. Zusammenfassung
+
+Der bisherige Stand ist nicht wertlos.
+
+Aber er ist nicht ausreichend als Kairo-MVP.
+
+Die Korrektur lautet:
+
+> Nicht zurückbauen, sondern den kanonischen Operating Model Kern wieder sichtbar machen und die nächsten Implementierungen daran ausrichten.
+
+Kairo muss jetzt vom einfachen Vorhaben-/Maßnahmenwerkzeug zurück in Richtung operativer Program Director geführt werden.