Kairo-Jinkendo/docs/architecture/Kairo_System_Target_State_v0.1.md

Kairo – System Target State

v0.1 – Zielzustand des angedachten Gesamtsystems

Hinweis (2026-07-05): Beschreibt das Zielbild, nicht den Implementierungsstand. Ist-Stand: Kairo_Implementation_Truth_Table_v0.1.md. v0.2 wird explizite Implementierungs-Marker pro Kapitel ergänzen.

Status: konsolidiertes Zielbild / Nordstern-Dokument
Stand: 2026-07-05
Zweck: Beschreibung des angedachten späteren Zielzustands von Kairo als System, unabhängig von konkreten Implementierungsschnitten.

---

1. Executive Summary

Kairo ist langfristig keine einfache Aufgabenliste, keine reine Projektmanagement-App, kein Roadmap-Tool und keine freie Workflow-Automatisierungsplattform.

Kairo ist eine:

adaptive, methodengeführte Entwicklungs- und Steuerungsplattform

Der Kern ist ein:

Method-driven Adaptive Steering Core

Kairo soll unterschiedliche Entwicklungs- und Steuerungskontexte führen können:

- Software- und Produktentwicklung
- Buch- und Content-Entwicklung
- Programmsteuerung
- Projekt- und Initiativensteuerung
- persönliche Entwicklung
- Reifegradentwicklung
- Lernpfade
- Routinen / Betrieb
- Review- und Auditkontexte
- Agentenläufe
- KI-/Tool-gestützte Steuerung

Die zentrale Leitfrage lautet:

Welcher nächste Schritt bringt diesen steuerbaren Kontext jetzt am wirksamsten voran?

---

2. Grundverständnis

Kairo steuert nicht nur Aufgaben.

Kairo steuert Entwicklungen.

Eine Entwicklung kann sein:

- ein Produkt
- ein Programm
- ein Projekt
- eine Initiative
- ein Buch
- eine Fähigkeit
- ein Reifegradziel
- eine Routine
- ein Review
- ein Audit
- ein Agentenauftrag

Kairo hält dabei fest:

- Was soll entwickelt werden?
- Warum ist es relevant?
- Welche Methode gilt?
- Welche Struktur braucht diese Methode?
- Wo steht der Kontext aktuell?
- Was fehlt?
- Was blockiert?
- Was braucht Aufmerksamkeit?
- Was ist der nächste wirksame Schritt?
- Wer oder welcher Agent soll handeln?
- Worauf wartet Kairo?
- Welche Nachweise, Reviews oder Entscheidungen sind nötig?
- Wann wird angepasst, eskaliert oder abgeschlossen?

---

3. Produktidentität

Kairo ist:

System of Record
Steering Authority
Actor-/Tenant-sicherer Kontextgeber
methodengeführter Steuerungskern
Roadmap- und Entwicklungsstrukturmodell
Signal- und NextAction-System
später Workflow-/Agenten-/Tool-orchestrierend

Kairo ist nicht:

freie Workflow-Plattform
beliebiger Automatisierungsbaukasten
reines Projektmanagementsystem
reine To-do-Liste
reines Roadmap-Tool
reine KI-Agentenplattform
reines Prompt-System

---

4. Kernmodell

Das Zielmodell:

Steerable Object
  → Steering Context
    → Steering Method
      → Standard Lifecycle / Method Lifecycle
        → Hook Slugs
          → Structure Builder
          → Signal Rules
          → NextAction Strategy
          → Assignment Strategy
          → Waiting / Reminder / Escalation Strategy
          → Result Intake
          → Evidence / Review / Decision
          → Adaptation / Closure
            → optionale Workflow-Fragmente
              → optionale Human / Agent / LLM / Tool Steps

---

5. Method-driven Adaptive Steering Core

Der Adaptive Steering Core ist der fachliche und technische Kern von Kairo.

Er führt steuerbare Kontexte durch methodengeführte Steuerungsabläufe.

Typischer Ablauf:

1. Ziel / Entwicklungsabsicht erfassen
2. Name, Scope und Kontext definieren
3. passende Basismethode wählen oder vorschlagen
4. gemäß Methode eine Steuerungsstruktur erzeugen
   - Roadmap
   - Backlog
   - WBS
   - Reifegradpfad
   - Kapitelstruktur
   - Feature Landscape
   - WorkCycles
   - Review Gates
5. Next Best Action ableiten
6. Actor zuweisen
7. auf Ergebnis, Rückmeldung, Termin oder Ereignis warten
8. erinnern, eskalieren oder nachsteuern
9. Ergebnis zurückführen
10. prüfen, reviewen, adaptieren oder abschließen

Dieser Ablauf ist der methodengeführte Steuerungsworkflow.

Er ist nicht gleichbedeutend mit einer freien technischen Workflow Engine.

---

6. Standard Lifecycle

Kairo besitzt einen minimalen Standard Lifecycle als gemeinsame Basis.

intake
method_selection
structure_setup
planning
action_selection
assignment
waiting
result_intake
validation
review
adaptation
closure

Methoden können diesen Lifecycle:

- verwenden
- teilweise überspringen
- spezialisieren
- erweitern
- eigene Hooks ergänzen

Der Standard Lifecycle ist kein starrer Projektprozess, sondern ein gemeinsames Steuerungsraster.

---

7. Steering Methods

Eine Methode ist kein Label, sondern ein registriertes Steuerungspaket.

Eine Methode definiert:

- supported_domains
- supported_scope_types
- default_lifecycle
- required_structures
- allowed_structures
- hook_slugs
- structure_builders
- attention_rule_providers
- next_action_strategy
- assignment_strategy
- waiting_strategy
- reminder_strategy
- escalation_strategy
- result_intake_strategy
- review_strategy
- evidence_policy
- closure_policy
- allowed_workflow_fragments
- allowed_node_types
- default_configuration

Methoden werden zunächst built-in und code-first angelegt, später versioniert und begrenzt konfigurierbar.

Langfristig können Method Profiles entstehen.

---

8. Method Registry

Kairo benötigt eine Method Registry.

Sie funktioniert ähnlich einem Widget-System:

Eine Methode meldet sich mit Slug, Version, unterstützten Domains,
Lifecycle, Hooks, Structure Builders, Strategies und Policies an.

Ziel:

Neue Methoden sollen ergänzt werden können,
ohne den Core jedes Mal umzubauen.

Beispiele für Methoden:

simple_action_driven
product_milestone_driven
backlog_driven
wbs_driven
cycle_based
content_chapter_based
maturity_progression
routine_control
review_driven
audit_driven
agent_controlled

---

9. Steering Domains

Kairo unterstützt unterschiedliche Steuerungsdomänen.

Beispiele:

program
project
product_development
content_development
personal_development
maturity_development
routine_operations
audit_review
agent_execution
custom

Jede Domain kann eigene typische Lifecycles, Roadmap-Strukturen, Methoden, Hooks und Signals haben.

---

10. Steerable Objects

Steuerbar sind nicht nur Initiativen.

Mögliche steuerbare Objekte:

program
initiative
project
roadmap
roadmap_item
backlog_item
action
blocker
review
evidence
decision
recurring_element
work_cycle
agent_run
custom

Diese Objekte werden über Steering Contexts an Methoden und Domains gebunden.

---

11. Steering Context

Ein Steering Context beschreibt:

Für welches steuerbare Objekt gilt welche Methode, Domain und Lifecycle-Logik?

Konzeptuell:

SteeringContext
  - tenant_id
  - scope_type
  - scope_id
  - steering_domain
  - lifecycle_model
  - steering_method
  - method_profile_id optional
  - method_version
  - configuration_json
  - inherits_from_parent
  - is_active

Untergeordnete Objekte können den Steering Context ihres Parents erben oder überschreiben.

---

12. Roadmap / Development Model

Roadmap ist ein Kernmodell, nicht nur eine UI-Ansicht.

Kairo braucht Roadmaps, um Entwicklungsrichtung und Entwicklungsstruktur abzubilden.

Roadmap-Struktur:

Roadmap
  → Roadmap Lane
    → Roadmap Item

RoadmapItems können sein:

milestone
maturity_stage
feature
capability
phase
release
chapter
research_topic
work_cycle
learning_step
review_gate
decision_gate
architecture_step
dependency
risk_reduction
custom

Entscheidung:

Milestone = RoadmapItem(type = milestone)

---

13. Roadmap vs. Backlog vs. Action

Zentrale Unterscheidung:

RoadmapItem = Entwicklungsziel / Orientierung / geplanter Entwicklungsschritt
BacklogItem = konkreter möglicher Handlungsbedarf
Action = freigegebene operative Maßnahme

Beispiel Softwareentwicklung:

RoadmapItem:
Attention Engine regelbasiert

BacklogItems:
- Attention DTO definieren
- Blockierte Maßnahmen auswerten
- Widget bauen

Actions:
- Endpoint implementieren
- Tests schreiben

Beispiel Buchentwicklung:

RoadmapItem:
Kapitel 3 – Argumentation ausarbeiten

BacklogItems:
- Recherche zur These prüfen
- Beispiel suchen
- Rohfassung schreiben

Actions:
- Heute Abschnitt 3.1 entwerfen

Beispiel Reifegradentwicklung:

RoadmapItem:
Reifegrad: stabile Seitkick-Beweglichkeit

BacklogItems:
- Hüftmobilität prüfen
- Dehnroutine auswählen
- Technikvideo aufnehmen

Actions:
- 10 Minuten Mobility durchführen

---

14. Structure Builder

Structure Builder erzeugen methodenspezifische Steuerungsstrukturen.

Beispiele:

roadmap_builder
milestone_plan_builder
feature_landscape_builder
wbs_builder
backlog_builder
maturity_path_builder
chapter_structure_builder
cycle_structure_builder
review_gate_builder
routine_structure_builder

Sie sind zentrale Erweiterungspunkte für Methoden.

Ein Structure Builder legt z. B. an:

- Roadmap
- Roadmap Lanes
- Roadmap Items
- initiale BacklogItems
- Review Gates
- WorkCycles

---

15. Hooks

Hooks sind stabile Einhängepunkte in Steuerungsabläufen.

Beispiele:

on_goal_captured
on_scope_named
on_method_selection_required
on_method_selected
on_structure_required
on_roadmap_required
on_backlog_required
on_wbs_required
on_maturity_path_required
on_content_structure_required
on_plan_required
on_dependency_analysis_required
on_dod_definition_required
on_next_action_requested
on_assignment_required
on_wait_started
on_due_date_reached
on_result_overdue
on_reminder_required
on_escalation_required
on_result_received
on_evidence_required
on_review_due
on_reassessment_required
on_replan_required
on_closure_requested

An Hooks können später kleine Workflow-Fragmente, Rules, Prompts, Agent Steps oder Tool Steps gebunden werden.

Hooks sind nicht beliebige technische Events, sondern fachlich stabile Steuerungspunkte.

---

16. Strategies

Methoden bringen oder referenzieren Strategies.

Zentrale Strategy-Typen:

NextActionStrategy
AttentionRuleProvider
AssignmentStrategy
WaitingStrategy
ReminderStrategy
EscalationStrategy
ResultIntakeStrategy
EvidencePolicy
ReviewStrategy
ClosurePolicy

Diese verhindern, dass methodenspezifische Logik monolithisch im Core wächst.

---

17. Signals

Signals sind sichtbare Ausgaben des Steuerungskerns.

Signal Types:

attention
next_action
review_due
evidence_required
escalation
blocker_signal
progress_signal
risk_signal
decision_required
dependency_signal
dod_signal
workflow_trigger

Attention

Beantwortet:

Was braucht Aufmerksamkeit?

NextActionCandidate

Beantwortet:

Was ist der nächste wirksame Schritt?

Signals müssen erklärbar sein:

- warum erzeugt?
- durch welche Methode?
- durch welchen Hook?
- auf welchen Scope bezogen?
- welche Datenquelle?
- welche empfohlene Handlung?

---

18. Assignment / Waiting / Reminder / Escalation

Der Steuerungskern endet nicht mit dem Erzeugen einer Action.

Kairo muss steuern:

- Actor auswählen
- Actor zuweisen
- auf Ergebnis warten
- Fälligkeit überwachen
- erinnern
- eskalieren
- externe Ereignisse aufnehmen
- Agentenergebnisse zurückführen

Actors können sein:

human
agent
working_group
external_system

---

19. Result Intake / Evidence / Review / Decision

Kairo führt Ergebnisse zurück und entscheidet, was daraus folgt.

Mögliche Rückführungen:

- Action erledigt
- Ergebnis unvollständig
- Evidence erforderlich
- Review erforderlich
- Decision erforderlich
- Blocker entstanden
- RoadmapItem erreicht
- Reifegrad plausibel erhöht
- neue NextAction nötig

Evidence, Reviews und Decisions sind zentrale Qualitätssicherungs- und Steuerungsobjekte.

---

20. Workflow-Fragmente und Runtime

Kairo soll langfristig Workflow-Fähigkeit haben.

Aber:

Workflows sind methodengeführte Steuerungsabläufe,
keine beliebige freie Automatisierungsplattform als Produktkern.

Zielmodell:

Hook
  → Workflow Fragment
    → Node / Step
      → Result
        → Rückführung in Kairo

Workflow-Fragmente können später enthalten:

human_task
approval
decision_gate
review
reflection
llm_prompt
agent_task
tool_call
state_transition
evidence_check
dod_check
dependency_analysis
notification
reminder
escalation

---

21. Agenten / LLMs / Tools

Kairo bleibt Steering Authority.

Agenten, LLMs und Tools sind Provider.

Sie können später an Hooks und Workflow-Fragmente angebunden werden.

Grundsatz:

Kairo entscheidet Kontext, Methode, Auftrag und Rückführung.
Agenten / LLMs / Tools führen einzelne Steps aus.

Agenten sind Actors.

Das ist wichtig für:

- Verantwortlichkeit
- Audit
- Assignments
- Sichtbarkeit
- Tenant-Kontext

---

22. Security / Governance / Audit

Kairo muss tenant- und actor-sicher bleiben.

Grundsätze:

- tenant_id immer aus TenantContext
- keine tenant_id aus Client Input vertrauen
- Actor-Bezüge tenant-intern validieren
- Capabilities prüfen
- Router dünn
- Services schreiben
- Data Layer liest
- Audit-by-design
- Signals und NextActions erklärbar
- Agentenaktionen nachvollziehbar

---

23. UI-Zielbild

Die UI dient als Steuerungs- und Interaktionsschicht.

Langfristige Views:

Workspace
Steering View
Roadmap View
Method View
Attention / NextAction View
Backlog View
Action View
Waiting / Reminder View
Evidence / Review / Decision View
Workflow Run View später
Method/Profile Admin später
Agent Run View später

Die UI darf nicht die Methode hart kodieren.

Sie muss methodenbewusst und strukturgetrieben sein.

---

24. Architektur-Evolutionslinie

Grobe Evolutionslinie:

1. Existing Foundation
2. Adaptive Steering Core Foundation
3. Method Registry / Hook Registry / Standard Lifecycle
4. Roadmap / Structure Builder Foundation
5. Signal / NextAction Engine
6. Assignment / Waiting / Reminder / Escalation
7. Evidence / Review / Decision
8. Workflow Fragments and Bindings
9. Workflow Runtime
10. Agent / LLM / Tool Providers
11. Method Profiles
12. Method Designer / Advanced Configuration
13. Advanced AI Steering / Next Best Action Ranking

Dies ist keine Sprintplanung, sondern ein Zielbild der technischen Entwicklung.

---

25. Zielzustand in einem Satz

Kairo soll ein methodengeführter adaptiver Steuerungskern werden, der Entwicklungen unterschiedlichster Art über registrierbare Methoden, gemeinsame Kernstrukturen, Roadmaps, Hooks, Signals, NextActions, Assignments, Waiting-/Reminder-/Escalation-Mechanismen und später Agent-/Workflow-Fragmente wirksam und nachvollziehbar steuert.