AP0.R1: Product Reset Dokumente ins Repository aufgenommen
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Test Suite / pytest-backend (push) Successful in 43s
Test Suite / lint-backend (push) Successful in 2s
Test Suite / compose-smoke (push) Has been skipped
Test Suite / k6 /api/health Baseline (push) Successful in 18s
Test Suite / playwright-smoke (push) Successful in 11s
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Test Suite / pytest-backend (push) Successful in 43s
Test Suite / lint-backend (push) Successful in 2s
Test Suite / compose-smoke (push) Has been skipped
Test Suite / k6 /api/health Baseline (push) Successful in 18s
Test Suite / playwright-smoke (push) Successful in 11s
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
parent
cc3129116a
commit
01b3c594a1
94
docs/architecture/CLAUDE_Product_Direction_Addendum_v0.1.md
Normal file
94
docs/architecture/CLAUDE_Product_Direction_Addendum_v0.1.md
Normal file
|
|
@ -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.
|
||||||
|
|
@ -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.
|
||||||
378
docs/product/Kairo_Canonical_Operating_Model_v0.1.md
Normal file
378
docs/product/Kairo_Canonical_Operating_Model_v0.1.md
Normal file
|
|
@ -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.
|
||||||
126
docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md
Normal file
126
docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md
Normal file
|
|
@ -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.
|
||||||
487
docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md
Normal file
487
docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md
Normal file
|
|
@ -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.
|
||||||
Loading…
Reference in New Issue
Block a user