Lars
1ce20d8bdb
Co-authored-by: Cursor <cursoragent@cursor.com>
9.6 KiB
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
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:
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.