From 01b3c594a1fcb24ac8a98b356a0267fc537edc74 Mon Sep 17 00:00:00 2001 From: Lars Date: Sun, 5 Jul 2026 08:18:13 +0200 Subject: [PATCH] AP0.R1: Product Reset Dokumente ins Repository aufgenommen Co-authored-by: Cursor --- .../CLAUDE_Product_Direction_Addendum_v0.1.md | 94 ++++ ...nt_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md | 210 ++++++++ .../Kairo_Canonical_Operating_Model_v0.1.md | 378 ++++++++++++++ .../Kairo_Corrected_MVP_Roadmap_v0.1.md | 126 +++++ ...o_Product_Definition_and_MVP_Reset_v0.1.md | 487 ++++++++++++++++++ 5 files changed, 1295 insertions(+) create mode 100644 docs/architecture/CLAUDE_Product_Direction_Addendum_v0.1.md create mode 100644 docs/architecture/Kairo_Current_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md create mode 100644 docs/product/Kairo_Canonical_Operating_Model_v0.1.md create mode 100644 docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md create mode 100644 docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md diff --git a/docs/architecture/CLAUDE_Product_Direction_Addendum_v0.1.md b/docs/architecture/CLAUDE_Product_Direction_Addendum_v0.1.md new file mode 100644 index 0000000..3802425 --- /dev/null +++ b/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. diff --git a/docs/architecture/Kairo_Current_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md b/docs/architecture/Kairo_Current_State_Gap_Analysis_AP0.1_AP0.6b_v0.1.md new file mode 100644 index 0000000..825c5a7 --- /dev/null +++ b/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. diff --git a/docs/product/Kairo_Canonical_Operating_Model_v0.1.md b/docs/product/Kairo_Canonical_Operating_Model_v0.1.md new file mode 100644 index 0000000..51db013 --- /dev/null +++ b/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. diff --git a/docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md b/docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md new file mode 100644 index 0000000..e84424e --- /dev/null +++ b/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. diff --git a/docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md b/docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md new file mode 100644 index 0000000..1424f35 --- /dev/null +++ b/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.