# 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.