449 lines
9.6 KiB
Markdown
449 lines
9.6 KiB
Markdown
|
# Jinkendo Kairo
|
||
|
|
## Product Spec v0.2
|
||
|
|
|
||
|
|
Status: Arbeitsfassung
|
||
|
|
Stand: 2026-07-04
|
||
|
|
Zweck: Konsolidierte Produktspezifikation für den Start des neuen Kairo-Repositories.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 1. Produktidentität
|
||
|
|
|
||
|
|
**Jinkendo Kairo** ist der operative Program Director der Jinkendo-Produktfamilie.
|
||
|
|
|
||
|
|
Kairo steuert Vorhaben, Programme, Projekte, Meilensteine, Maßnahmen, Backlogs, Reviews, Nachweise und die Zusammenarbeit von Menschen, Arbeitsgruppen und KI-Agenten.
|
||
|
|
|
||
|
|
**Leitfrage:**
|
||
|
|
|
||
|
|
> Welcher nächste Schritt bringt ein Vorhaben aktuell am wirkungsvollsten voran?
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 2. Produktgrenze
|
||
|
|
|
||
|
|
Kairo ist kein klassischer Projektmanager, keine reine ToDo-App und kein reines Softwareentwicklungstool.
|
||
|
|
|
||
|
|
Kairo ist auch kein Lebenssinn-, Identitäts- oder Gesundheitsprodukt.
|
||
|
|
|
||
|
|
### Kairo verantwortet
|
||
|
|
|
||
|
|
- Vorhaben
|
||
|
|
- Programme
|
||
|
|
- Projekte
|
||
|
|
- Meilensteine
|
||
|
|
- Maßnahmen
|
||
|
|
- Backlog Items
|
||
|
|
- Nachweise
|
||
|
|
- Reviews
|
||
|
|
- Entscheidungen
|
||
|
|
- Blocker
|
||
|
|
- Actor-Zuweisungen
|
||
|
|
- Arbeitsgruppen
|
||
|
|
- KI-Agenten
|
||
|
|
- operative Priorisierung
|
||
|
|
- Umsetzungstransparenz
|
||
|
|
|
||
|
|
### Kairo verantwortet nicht
|
||
|
|
|
||
|
|
- persönliche Identität
|
||
|
|
- Lebensvisionen
|
||
|
|
- persönliche Entwicklungsmodelle
|
||
|
|
- Gesundheitsdaten
|
||
|
|
- Trainingsfachlogik
|
||
|
|
- Wissensmanagement
|
||
|
|
- Ernährungslogik
|
||
|
|
- Skill- oder Reifegradmodelle aus Shinkan
|
||
|
|
|
||
|
|
Diese Domänen gehören zu anderen Jinkendo-Produkten wie mindnet, Mitai, Shinkan und perspektivisch Seichō.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 3. Abgrenzung zu Seichō
|
||
|
|
|
||
|
|
**Seichō** verantwortet persönliche Entwicklung.
|
||
|
|
|
||
|
|
**Kairo** verantwortet operative Umsetzung.
|
||
|
|
|
||
|
|
Beispiel:
|
||
|
|
|
||
|
|
- Seichō: „Ich möchte als Vater präsenter werden.“
|
||
|
|
- Kairo: „Welche konkreten Vorhaben, Meilensteine und Maßnahmen setzen das um?“
|
||
|
|
|
||
|
|
Kairo darf persönliche Entwicklungsziele aus Seichō operativ unterstützen, aber nicht die persönliche Entwicklungslogik selbst übernehmen.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 4. Stable Core und Agile Edge
|
||
|
|
|
||
|
|
### Stable Core
|
||
|
|
|
||
|
|
Der Stable Core wird nur bewusst und selten geändert.
|
||
|
|
|
||
|
|
Er umfasst:
|
||
|
|
|
||
|
|
- Fachsprache
|
||
|
|
- Kernobjekte
|
||
|
|
- Produktgrenzen
|
||
|
|
- Actor-Modell
|
||
|
|
- Tenant-Modell
|
||
|
|
- Backlog-Modell
|
||
|
|
- Meilensteinmodell
|
||
|
|
- Rechte-/Capability-Grundmodell
|
||
|
|
- Prompt-/Registry-Grundmodell
|
||
|
|
- Änderungsregeln
|
||
|
|
- Agentenregeln
|
||
|
|
|
||
|
|
### Agile Edge
|
||
|
|
|
||
|
|
Der Agile Edge darf iterativ wachsen.
|
||
|
|
|
||
|
|
Er umfasst:
|
||
|
|
|
||
|
|
- UI
|
||
|
|
- Dashboards
|
||
|
|
- Reports
|
||
|
|
- MCP-Tools
|
||
|
|
- Integrationen
|
||
|
|
- Automationen
|
||
|
|
- Priorisierungsstrategien
|
||
|
|
- Visualisierungen
|
||
|
|
- Komfortfunktionen
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 5. Ubiquitous Language
|
||
|
|
|
||
|
|
| Begriff | Bedeutung |
|
||
|
|
|---|---|
|
||
|
|
| Vision | Langfristig gewünschter Zustand; primär außerhalb Kairo |
|
||
|
|
| Vorhaben | Aktiv verfolgte Veränderung oder angestrebtes Ergebnis |
|
||
|
|
| Programm | Bündel zusammengehöriger Projekte |
|
||
|
|
| Projekt | Zeitlich begrenzte Ergebniserzeugung |
|
||
|
|
| Meilenstein | Überprüfbarer Zielzustand, keine Aufgabe |
|
||
|
|
| Maßnahme | Kleinste operative Arbeitseinheit mit eindeutigem Ergebnis |
|
||
|
|
| Backlog Item | Noch nicht verbindlich priorisierter Handlungsbedarf |
|
||
|
|
| Review | Strukturierte Bewertung eines Scopes |
|
||
|
|
| Nachweis | Beleg für Fortschritt, Abschluss oder Entscheidung |
|
||
|
|
| Entscheidung | Festgehaltene Auswahl zwischen Optionen |
|
||
|
|
| Blocker | Hindernis, das Fortschritt verhindert oder stark erschwert |
|
||
|
|
| Actor | Mensch, KI-Agent, Arbeitsgruppe oder externes System |
|
||
|
|
| Assignment | Zuweisung einer Maßnahme an einen oder mehrere Actors |
|
||
|
|
| Tenant | Abgegrenzter Nutzungsraum, z. B. Person, Familie, Team, Organisation |
|
||
|
|
| TenantContext | Aufgelöster Request-Kontext mit User, Tenant, Actor, Rollen und Capabilities |
|
||
|
|
| Capability | Funktionale Erlaubnis: „Darf Actor X diese Funktion nutzen?“ |
|
||
|
|
| Feature | Registrierte Produktfunktion, optional später mit Limit/Kontingent |
|
||
|
|
| Governance | Objektbezogene Zugriffslogik: „Darf Actor X dieses Objekt sehen/ändern?“ |
|
||
|
|
|
||
|
|
Neue Begriffe werden nur eingeführt, wenn bestehende Begriffe fachlich nicht ausreichen.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 6. Grundstruktur
|
||
|
|
|
||
|
|
```text
|
||
|
|
Tenant
|
||
|
|
└── Actor
|
||
|
|
└── Vorhaben
|
||
|
|
├── Programm
|
||
|
|
│ └── Projekt
|
||
|
|
│ ├── Meilenstein
|
||
|
|
│ ├── Maßnahme
|
||
|
|
│ └── Backlog Item
|
||
|
|
├── Meilenstein
|
||
|
|
├── Maßnahme
|
||
|
|
├── Backlog Item
|
||
|
|
├── Nachweis
|
||
|
|
└── Review
|
||
|
|
```
|
||
|
|
|
||
|
|
Nicht jedes Vorhaben benötigt Programme oder Projekte.
|
||
|
|
|
||
|
|
Kleine Vorhaben können direkt Meilensteine, Maßnahmen und Backlog Items besitzen.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 7. Kernobjekte
|
||
|
|
|
||
|
|
### Tenant
|
||
|
|
|
||
|
|
Ein Tenant ist ein abgegrenzter Nutzungsraum.
|
||
|
|
|
||
|
|
Beispiele:
|
||
|
|
|
||
|
|
- persönlicher Arbeitsraum
|
||
|
|
- Familie
|
||
|
|
- Verein
|
||
|
|
- Team
|
||
|
|
- Organisation
|
||
|
|
- Projektverbund
|
||
|
|
|
||
|
|
### User
|
||
|
|
|
||
|
|
Ein User ist ein authentifizierter Account.
|
||
|
|
|
||
|
|
Ein User kann Mitglied mehrerer Tenants sein.
|
||
|
|
|
||
|
|
### Actor
|
||
|
|
|
||
|
|
Ein Actor ist die operative Zurechnungseinheit.
|
||
|
|
|
||
|
|
Actor Types:
|
||
|
|
|
||
|
|
- Human
|
||
|
|
- Agent
|
||
|
|
- WorkingGroup
|
||
|
|
- ExternalSystem
|
||
|
|
|
||
|
|
Alle Assignments erfolgen an Actors, nicht direkt an User.
|
||
|
|
|
||
|
|
### Vorhaben
|
||
|
|
|
||
|
|
Ein Vorhaben beschreibt eine aktiv verfolgte Veränderung oder ein angestrebtes Ergebnis.
|
||
|
|
|
||
|
|
Es besitzt mindestens:
|
||
|
|
|
||
|
|
- Titel
|
||
|
|
- Zielzustand
|
||
|
|
- Status
|
||
|
|
- Priorität
|
||
|
|
- verantwortliche Actors
|
||
|
|
- Bezug zu Maßnahmen, Meilensteinen, Backlog und Reviews
|
||
|
|
|
||
|
|
### Programm
|
||
|
|
|
||
|
|
Ein Programm bündelt zusammengehörige Projekte oder Vorhabenanteile.
|
||
|
|
|
||
|
|
Programme sind optional.
|
||
|
|
|
||
|
|
### Projekt
|
||
|
|
|
||
|
|
Ein Projekt erzeugt ein konkretes Ergebnis innerhalb eines Vorhabens oder Programms.
|
||
|
|
|
||
|
|
### Meilenstein
|
||
|
|
|
||
|
|
Ein Meilenstein beschreibt einen überprüfbaren Zielzustand.
|
||
|
|
|
||
|
|
Er ist keine Aufgabe.
|
||
|
|
|
||
|
|
Mögliche Status:
|
||
|
|
|
||
|
|
- geplant
|
||
|
|
- aktiv
|
||
|
|
- gefährdet
|
||
|
|
- erreicht
|
||
|
|
- verschoben
|
||
|
|
- verworfen
|
||
|
|
|
||
|
|
### Maßnahme
|
||
|
|
|
||
|
|
Eine Maßnahme ist die kleinste operative Arbeitseinheit.
|
||
|
|
|
||
|
|
Mögliche Status:
|
||
|
|
|
||
|
|
- offen
|
||
|
|
- bereit
|
||
|
|
- in Arbeit
|
||
|
|
- blockiert
|
||
|
|
- Review erforderlich
|
||
|
|
- erledigt
|
||
|
|
- verworfen
|
||
|
|
|
||
|
|
### Backlog Item
|
||
|
|
|
||
|
|
Backlog Items entstehen aus Ideen, Bugs, Risiken, Verbesserungen oder Agentenvorschlägen.
|
||
|
|
|
||
|
|
Sie verpflichten nicht automatisch zur Umsetzung.
|
||
|
|
|
||
|
|
### Nachweis
|
||
|
|
|
||
|
|
Nachweise belegen Fortschritt oder Abschluss.
|
||
|
|
|
||
|
|
Beispiele:
|
||
|
|
|
||
|
|
- Commit
|
||
|
|
- Dokument
|
||
|
|
- Link
|
||
|
|
- Datei
|
||
|
|
- Messwert
|
||
|
|
- Foto
|
||
|
|
- Review-Ergebnis
|
||
|
|
- externe Bestätigung
|
||
|
|
|
||
|
|
### Review
|
||
|
|
|
||
|
|
Ein Review bewertet einen Scope und erzeugt ggf. Entscheidungen, Maßnahmen oder Backlog Items.
|
||
|
|
|
||
|
|
### Blocker
|
||
|
|
|
||
|
|
Ein Blocker verhindert oder gefährdet Fortschritt.
|
||
|
|
|
||
|
|
Blocker müssen sichtbar, zugeordnet und reviewbar sein.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 8. Actor- und Assignment-Modell
|
||
|
|
|
||
|
|
Actors können Menschen, KI-Agenten, Arbeitsgruppen oder externe Systeme sein.
|
||
|
|
|
||
|
|
Unterstützte Assignment-Modi:
|
||
|
|
|
||
|
|
- Exclusive: genau ein verantwortlicher Actor
|
||
|
|
- Collaborative: mehrere Actors arbeiten gemeinsam
|
||
|
|
- Pool: eine Arbeitsgruppe oder ein Pool kann übernehmen
|
||
|
|
- Proposed: Zuweisungsvorschlag, noch nicht angenommen
|
||
|
|
- Auction: Actors bewerben sich oder übernehmen bewusst
|
||
|
|
|
||
|
|
Agenten sind keine Sonderfälle außerhalb des Modells.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 9. Multiuser und Mandantenfähigkeit
|
||
|
|
|
||
|
|
Multiuser ist Kernfunktion, keine spätere Erweiterung.
|
||
|
|
|
||
|
|
Kairo unterstützt:
|
||
|
|
|
||
|
|
- private Vorhaben
|
||
|
|
- Familienvorhaben
|
||
|
|
- Teamvorhaben
|
||
|
|
- Organisationsvorhaben
|
||
|
|
- Arbeitsgruppen
|
||
|
|
- KI-Agenten innerhalb eines Tenants
|
||
|
|
- objektbezogene Sichtbarkeit und Bearbeitbarkeit
|
||
|
|
|
||
|
|
Jede fachliche Entität ist tenantfähig zu modellieren.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 10. Rechte, Capabilities und Governance
|
||
|
|
|
||
|
|
Kairo trennt:
|
||
|
|
|
||
|
|
```text
|
||
|
|
Auth = Wer ist eingeloggt?
|
||
|
|
Capability = Darf Actor diese Funktion nutzen?
|
||
|
|
Feature = Welche Produktfunktion ist betroffen?
|
||
|
|
Governance = Darf Actor dieses konkrete Objekt sehen/ändern?
|
||
|
|
```
|
||
|
|
|
||
|
|
Feature-Limits, Usage-Zähler, Billing, Tiers und Pläne sind nicht Bestandteil von Sprint 0, werden aber im Modell nicht verbaut.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 11. Prompt- und AI-Grundmodell
|
||
|
|
|
||
|
|
Kairo nutzt intern keine hardcodierten Produktionsprompts.
|
||
|
|
|
||
|
|
Mindestmodell:
|
||
|
|
|
||
|
|
- Prompt Templates in DB oder konfigurierbarer Persistenz
|
||
|
|
- Prompt Versions
|
||
|
|
- typisierte Platzhalter
|
||
|
|
- Kontextarten
|
||
|
|
- Adminbarkeit
|
||
|
|
- Preview/Testmöglichkeit später
|
||
|
|
- zentrale Prompt-Ausführung als Fassade
|
||
|
|
|
||
|
|
Sprint 0 baut keine komplexe Workflow- oder Pipeline-Engine.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 12. Registry-Grundmodell
|
||
|
|
|
||
|
|
Neue Funktionen registrieren sich an zentralen Steuerungsschichten.
|
||
|
|
|
||
|
|
Mindestens vorgesehen:
|
||
|
|
|
||
|
|
- Rights / Capability Registry
|
||
|
|
- Feature Registry
|
||
|
|
- Prompt Registry
|
||
|
|
- Configuration Registry
|
||
|
|
- Audit Events
|
||
|
|
|
||
|
|
Ziel: keine verstreuten, unsichtbaren Sonderlogiken.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 13. Agentenregeln
|
||
|
|
|
||
|
|
Agenten dürfen:
|
||
|
|
|
||
|
|
- Kontext anfragen
|
||
|
|
- nächste Maßnahme abfragen
|
||
|
|
- Maßnahmen claimen
|
||
|
|
- Fortschritt melden
|
||
|
|
- Blocker melden
|
||
|
|
- Backlog Items vorschlagen
|
||
|
|
- Nachweise einreichen
|
||
|
|
- Reviews anfordern
|
||
|
|
|
||
|
|
Agenten dürfen nicht ohne Freigabe:
|
||
|
|
|
||
|
|
- strategische Ziele ändern
|
||
|
|
- Vorhaben löschen
|
||
|
|
- Meilensteine verschieben
|
||
|
|
- Rechte oder Rollen ändern
|
||
|
|
- Prompts produktiv ändern
|
||
|
|
- Admin-Konfiguration ändern
|
||
|
|
- private Daten anderer Actors auswerten
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 14. Änderungsregime
|
||
|
|
|
||
|
|
Änderungen werden klassifiziert als:
|
||
|
|
|
||
|
|
| Ebene | Bedeutung |
|
||
|
|
|---|---|
|
||
|
|
| Operativ | Maßnahmen, Status, Nachweise, Kommentare |
|
||
|
|
| Taktisch | Prioritäten, Meilensteinzuschnitt, Assignment-Modus |
|
||
|
|
| Strategisch | Produktgrenze, Stable Core, grundlegende Ziele oder Rechte |
|
||
|
|
|
||
|
|
Strategische Änderungen benötigen menschliche Freigabe.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 15. MVP-Zielbild
|
||
|
|
|
||
|
|
Der MVP umfasst nach Sprint 0 schrittweise:
|
||
|
|
|
||
|
|
- Tenant/User/Actor
|
||
|
|
- Vorhaben
|
||
|
|
- Projekte
|
||
|
|
- Meilensteine
|
||
|
|
- Maßnahmen
|
||
|
|
- Backlog
|
||
|
|
- Assignments
|
||
|
|
- Arbeitsgruppen
|
||
|
|
- Agentenstatus
|
||
|
|
- Reviews
|
||
|
|
- Nachweise
|
||
|
|
- Blocker
|
||
|
|
- Vorschlag der nächsten sinnvollen Maßnahme
|
||
|
|
- MCP-Minimalintegration für Coding-Agenten
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 16. Nicht-Ziele des MVP
|
||
|
|
|
||
|
|
Nicht Teil des MVP:
|
||
|
|
|
||
|
|
- vollständige Mitai-Integration
|
||
|
|
- vollständige Shinkan-Integration
|
||
|
|
- vollständige mindnet-Integration
|
||
|
|
- vollständige Seichō-Integration
|
||
|
|
- vollständiges Billing
|
||
|
|
- zentrales SSO
|
||
|
|
- komplexe Prompt-Workflows
|
||
|
|
- KI-Autopilot für strategische Entscheidungen
|
||
|
|
- vollständiger Lebensmanager
|
||
|
|
- Gesundheits- oder Trainingsdomänenlogik
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 17. Leitregel
|
||
|
|
|
||
|
|
Kairo steuert Umsetzung.
|
||
|
|
|
||
|
|
Sinn, Identität und persönliche Entwicklung verbleiben außerhalb seiner fachlichen Verantwortung.
|