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

Kairo – Universal Steering Engine Decision

v0.1 – Fachliche Entscheidung zu Steuerungsengine, Roadmap, Methoden, Workflow-Nodes und Agenten-Einbindung

Status: Entscheidungs- und Spezifikationsentwurf
Stand: 2026-07-05
Kontext: Nach AP0.7, nach Product Reset, vor Überarbeitung von AP0.8
Ziel: Verbindliche fachliche Grundlage für die spätere universelle Steuerungsengine von Kairo, ohne AP0.8 technisch zu überladen.

---

1. Zweck dieses Dokuments

Dieses Dokument verdichtet die bisherige fachliche Diskussion zu einer entscheidungsfähigen Spezifikation.

Es beantwortet insbesondere:

1. Welche Verantwortung hat Kairo selbst?
2. Welche Verantwortung kann an externe Agentensysteme ausgelagert werden?
3. Wie werden unterschiedliche Entwicklungs- und Umsetzungsmethoden fachlich modelliert?
4. Wie hängen Steering Domains, Lifecycle Models, Methoden, Profile, Roadmaps, Hooks, Workflows, Nodes und Signals zusammen?
5. Wie bleibt Kairo universell erweiterbar, ohne sofort zu komplex zu werden?
6. Was muss AP0.8 vorbereiten?
7. Was darf AP0.8 ausdrücklich noch nicht bauen?

---

2. Ausgangslage

AP0.7 hat wesentliche technische Grundlagen geschaffen:

• Tenant Hardening
• Tenant-Invarianten
• Cross-Tenant-Tests
• Actor Directory
• echter ActorSelect
• Data Layer Minimum
• Workspace Summary
• zentrale Workspace-Read-Endpunkte
• AP0.6b UX/PWA bleibt erhalten

Gleichzeitig ist fachlich klar geworden:

Initiative / Vorhaben
  → Action / Maßnahme

ist als technischer Startpunkt akzeptabel, aber als Produktmodell für Kairo zu flach.

Kairo soll kein Aufgabenmanager sein, sondern ein operativer Program Director und langfristig eine universell erweiterbare Steuerungsplattform für Entwicklungen.

---

3. Leitentscheidung

Kairo baut langfristig eine fachliche Steuerungsengine.

Diese Engine muss unterschiedliche Entwicklungs- und Umsetzungskontexte tragen können:

• Software- und Produktentwicklung
• Buchentwicklung
• Programmarbeit
• Projektarbeit
• persönliche Entwicklung
• Reifegradentwicklung
• Lernpfade
• Routinen
• Reviews / Audits
• Betrieb / Wartung
• Agentenläufe

Die Engine darf jedoch nicht sofort als beliebige freie Workflow-Plattform gebaut werden.

Leitentscheidung:

Kairo bleibt System of Record und Steering Authority.
Externe oder integrierte Agentensysteme können ausführende Step Provider sein.
Die fachliche Steuerung, der Kontext, die Signale, die Roadmap, die Nachvollziehbarkeit und die Verantwortungslogik bleiben in Kairo.

---

4. Was Kairo selbst verantwortet

Kairo verantwortet dauerhaft:

- steuerbare Objekte und ihre Beziehungen
- Roadmaps und Entwicklungsziele
- Backlog, Actions, Blocker, Reviews, Evidence und Decisions
- Steering Contexts
- Method Definitions und Method Profiles
- Lifecycle Models und Hook Points
- Signale wie Attention, NextAction, EvidenceRequired, DecisionRequired
- Auditierbarkeit und Nachvollziehbarkeit
- Tenant- und Actor-Sicherheit
- Auswahl und Beauftragung von Human-/Agent-/Tool-Steps
- Rückführung von Ergebnissen in das Kairo-Modell

Kairo muss also immer wissen:

• Was wird gesteuert?
• Warum wird etwas vorgeschlagen?
• Wer oder was ist verantwortlich?
• Welche Methode gilt?
• Welche Roadmap- oder Entwicklungslogik liegt zugrunde?
• Welcher Workflow oder Hook hat ein Signal erzeugt?
• Welches Ergebnis wurde zurückgeführt?

---

5. Was externe Agentensysteme übernehmen dürfen

Externe oder integrierte Agentensysteme dürfen später einzelne Schritte ausführen, z. B.:

- Text analysieren
- Vorschläge generieren
- WBS-Vorschläge erzeugen
- Abhängigkeiten identifizieren
- Backlog Items vorschlagen
- NextActionCandidates vorschlagen
- DoD prüfen
- Evidence auswerten
- Dokumente zusammenfassen
- Recherche durchführen
- Tool Calls ausführen

Sie dürfen aber nicht ohne Kairo-Kontrolle:

- führendes Steuerungssystem werden
- Tenant-/Actor-Kontext umgehen
- Roadmap oder Methode eigenständig überschreiben
- strategische Prioritäten ändern
- Daten ohne Audit verändern
- Rechte oder Capabilities ändern
- produktive Änderungen ohne vorgesehenes Gate ausführen

Agentensysteme sind aus Sicht von Kairo:

ausführende Provider

nicht:

führende Steuerungsinstanz

---

6. Komplexitätsbremse

Die Architektur wird in drei Ebenen geschnitten.

Ebene 1 – Signals und Read Models

Kurzfristig und MVP-nah.

- Attention
- NextActionCandidate
- EvidenceRequired
- DecisionRequired
- BlockerSignal
- ReviewDue

Diese Ebene liefert Produktnutzen ohne vollständige Workflow Runtime.

Ebene 2 – Hook-basierte Workflows

Mittelfristig.

- feste Hook Points
- definierte Node-Typen
- Workflow Definitions
- Workflow Bindings
- einfache Workflow Runtime

Diese Ebene erlaubt methodenspezifische Abläufe, aber noch keine beliebige offene Plattform.

Ebene 3 – konfigurierbare Methoden und Agenten

Langfristig.

- Method Profiles
- tenant-konfigurierbare Regeln
- LLM-/Tool-/Agent-Steps
- externe Agentensysteme
- Method Designer
- Workflow Designer

AP0.8 darf maximal Ebene 1 aktiv implementieren und Ebene 2/3 fachlich vorbereiten.

---

7. Kernmodell der universellen Steuerung

Das fachliche Zielmodell lautet:

Steerable Object
  → Steering Context
    → Steering Domain
      → Lifecycle Model
        → Steering Method
          → Method Profile
            → Hook Points
              → Rules / Workflow Bindings
                → Workflow Nodes
                  → Signals / Results
                    → Roadmap / Backlog / Action / Evidence / Review

Dieses Modell ist bewusst mehrschichtig.

Es verhindert, dass alles auf eine einzige Projektlogik oder eine einzige Aufgabenlogik reduziert wird.

---

8. Steerable Object

Ein Steerable Object ist jedes Objekt, für das Kairo Steuerungslogik anwenden kann.

Mögliche Scope Types:

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

Nicht alle Scope Types müssen in AP0.8 aktiv unterstützt werden.

AP0.8 sollte mindestens vorbereiten:

initiative
roadmap_item
backlog_item
action
blocker

---

9. Steering Domain

Eine Steering Domain beschreibt die fachliche Domäne der Steuerung.

Initiale Domains:

program
project
product_development
content_development
personal_development
maturity_development
routine_operations
audit_review
agent_execution
custom

9.1 Beispiele

Software-/Produktentwicklung

Domain: product_development
typische Roadmap-Lanes:
- Feature Landscape
- Architecture Evolution
- Releases
- Technical Debt
- Validation

Buchentwicklung

Domain: content_development
typische Roadmap-Lanes:
- Buchstruktur
- Kapitel
- Recherche
- Drafts
- Review
- Veröffentlichung

Persönliche Fähigkeitsentwicklung

Domain: maturity_development
typische Roadmap-Lanes:
- Reifegradstufen
- Fähigkeiten
- Praxis / Übungen
- Evidence
- Reflexion
- Assessments

Programmsteuerung

Domain: program
typische Roadmap-Lanes:
- strategische Ziele
- Initiativen
- Abhängigkeiten
- Ressourcen
- Risiken
- Benefits

---

10. Lifecycle Model

Ein Lifecycle Model beschreibt die typischen Phasen einer Domain.

10.1 Project / Initiative Lifecycle

intake
clarify
structure
plan
execute
monitor
review
adapt
close

10.2 Program Lifecycle

define_intent
establish_structure
prioritize_initiatives
coordinate_dependencies
allocate_capacity
monitor_benefits
resolve_conflicts
review_outcomes
rebalance
close

10.3 Maturity Development Lifecycle

assess_current_level
define_target_maturity
identify_gaps
select_intervention
practice
collect_evidence
reflect
adjust_challenge
reassess

10.4 Content Development Lifecycle

define_concept
structure_content
research
draft
review
revise
prepare_publication
publish
maintain

10.5 Routine Operations Lifecycle

define_routine
schedule_next_run
execute_run
capture_exception
verify_completion
review_quality
adjust_routine
repeat

AP0.8 muss diese Lifecycles noch nicht technisch als vollständige State Machines implementieren.

Aber die Begriffe und Hook Points müssen fachlich vorbereitet sein.

---

11. Steering Context

Ein Steering Context verbindet ein Steerable Object mit Domain, Lifecycle und Methode.

Konzeptionell:

Steering Context
  - 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

Mögliche Tabelle:

steering_contexts (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,

  scope_type VARCHAR(64) NOT NULL,
  scope_id UUID NOT NULL,

  steering_domain VARCHAR(64) NOT NULL,
  lifecycle_model VARCHAR(64) NOT NULL,
  steering_method VARCHAR(128) NOT NULL,
  method_profile_id UUID NULL,
  method_version VARCHAR(32) NOT NULL DEFAULT 'v1',

  configuration_json JSONB NOT NULL DEFAULT '{}'::jsonb,

  inherits_from_parent BOOLEAN NOT NULL DEFAULT TRUE,
  is_active BOOLEAN NOT NULL DEFAULT TRUE,

  created_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL
)

11.1 Vererbung

Standardregel:

Untergeordnete Objekte erben den Steering Context ihres Parents, sofern sie keinen eigenen Context besitzen.

Beispiele:

Produktentwicklung Kairo
  Initiative: product_development / milestone_driven
    RoadmapItem "Feature Landscape": geerbt
    BacklogItem "Attention DTO definieren": geerbt
    Action "Endpoint bauen": simple task

Buchentwicklung
  Initiative: content_development / chapter_based
    RoadmapItem "Kapitel 3": content_draft
    Action "Rohfassung schreiben": writing_task

Persönliche Entwicklung
  Initiative: maturity_development / maturity_progression
    RoadmapItem "Reifegrad Beweglichkeit 2": maturity_stage
    Action "Dehnroutine durchführen": routine_task

---

12. Steering Method

Eine Steering Method beschreibt, nach welcher Logik gesteuert wird.

Beispiele:

simple
milestone_driven
kanban
cycle_based
chapter_based
maturity_progression
habit_based
review_driven
audit_driven
recurring_control
agent_controlled
hybrid

Eine Methode definiert fachlich:

- unterstützte Domains
- unterstützte Scope Types
- typische Roadmap-Lanes
- typische RoadmapItem-Typen
- relevante Hook Points
- erlaubte oder empfohlene Node-Typen
- relevante Signals
- Fortschrittslogik
- Reviewlogik
- Evidence-Anforderungen
- NextAction-Logik

---

13. Method Definition

Eine Method Definition ist die systemische Beschreibung einer Methode.

Kurzfristig kann sie code-first sein.

Langfristig kann sie als DB-Definition oder konfigurierbares Profil existieren.

Mögliche Struktur:

{
  "method_key": "maturity_progression",
  "version": "v1",
  "label": "Reifegradentwicklung",
  "supported_domains": ["maturity_development", "personal_development"],
  "supported_scope_types": ["initiative", "roadmap_item", "action"],
  "default_lifecycle_model": "maturity_lifecycle",
  "roadmap_lane_types": ["maturity_stages", "capabilities", "practice", "evidence", "reflection"],
  "roadmap_item_types": ["maturity_stage", "capability", "learning_step", "review_gate"],
  "hook_points": ["on_evidence_required", "on_review_due", "on_next_action_requested"],
  "signal_types": ["attention", "next_action", "evidence_required", "review_due"],
  "node_types": ["human_task", "evidence_check", "review", "llm_prompt"],
  "maturity": "basic"
}

---

14. Method Profile

Ein Method Profile ist eine konkrete konfigurierte Ausprägung einer Methode.

Beispiele:

cycle_based:
  Zwei-Wochen-Zyklus mit Reviewpflicht

maturity_progression:
  Vierstufiges Reifegradmodell mit Evidence und Reflexion

content_development:
  Buchentwicklung mit Kapitelstruktur, Recherche, Review und Revision

recurring_control:
  Monatliche Wartungsroutine mit Eskalation bei verpasstem Durchlauf

Method Profiles brauchen langfristig:

- tenant_id optional
- method_key
- version
- name
- configuration_json
- allowed_node_types
- enabled_hooks
- default_workflows
- evidence_policy
- review_policy
- approval_policy

AP0.8 muss Method Profiles noch nicht vollständig implementieren.

Aber die Architektur muss sie vorsehen.

---

15. Development Roadmap

Jede größere Entwicklung braucht eine grobe Roadmap.

Die Roadmap ist nicht gleich Backlog und nicht gleich Maßnahmenliste.

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

15.1 Roadmap-Struktur

Steerable Object
  → Roadmap
    → Roadmap Lane
      → Roadmap Item
        → BacklogItem
          → Action

15.2 Warum Roadmap universell sein muss

Eine Softwareentwicklung braucht z. B.:

- Feature Landscape
- Architekturentwicklung
- Releases
- technische Schulden
- Validierung

Eine Buchentwicklung braucht:

- Buchstruktur
- Kapitel
- Recherche
- Drafts
- Review
- Veröffentlichung

Eine persönliche Entwicklung braucht:

- Reifegradstufen
- Fähigkeiten
- Übungs-/Praxislinien
- Evidence
- Reflexion
- Assessments

Deshalb darf Roadmap nicht nur aus Milestones bestehen.

---

16. Roadmap-Datenmodell

16.1 roadmaps

roadmaps (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,
  scope_type VARCHAR(64) NOT NULL,
  scope_id UUID NOT NULL,
  title VARCHAR(255) NOT NULL,
  roadmap_type VARCHAR(64) NOT NULL,
  status VARCHAR(32) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL
)

roadmap_type:

product
program
project
content
personal_development
maturity
operations
learning
custom

16.2 roadmap_lanes

roadmap_lanes (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,
  roadmap_id UUID NOT NULL,
  title VARCHAR(255) NOT NULL,
  lane_type VARCHAR(64) NOT NULL,
  sort_order INTEGER NOT NULL DEFAULT 0,
  created_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL
)

lane_type:

milestones
features
maturity_stages
capabilities
chapters
research
cycles
releases
learning_path
architecture
risks
dependencies
custom

16.3 roadmap_items

roadmap_items (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,
  roadmap_id UUID NOT NULL,
  lane_id UUID NULL,
  parent_item_id UUID NULL,
  title VARCHAR(255) NOT NULL,
  description TEXT DEFAULT '',
  item_type VARCHAR(64) NOT NULL,
  status VARCHAR(32) NOT NULL,
  target_date DATE NULL,
  sort_order INTEGER NOT NULL DEFAULT 0,
  metadata_json JSONB NOT NULL DEFAULT '{}'::jsonb,
  created_at TIMESTAMP NOT NULL,
  updated_at TIMESTAMP NOT NULL
)

item_type:

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

---

17. Milestone-Entscheidung

Milestone soll nicht als isoliertes Primärobjekt starten.

Entscheidung:

Milestone = RoadmapItem(type = milestone)

Begründung:

• Meilensteine sind nur eine RoadmapItem-Art.
• Reifegrade, Features, Kapitel, Releases und Lernschritte brauchen dieselbe Roadmap-Struktur.
• Eine separate Milestone-Tabelle würde später zu Parallelmodellen führen.
• RoadmapItems erlauben universellere Entwicklungspfade.

---

18. Backlog und Action

18.1 BacklogItem

Ein BacklogItem ist ein möglicher Handlungsbedarf.

Beispiele:

- Idee
- Risiko
- Vorschlag
- Research-Frage
- Feature-Slice
- Reifegrad-Lücke
- Kapitelbedarf
- Verbesserungsbedarf

Ein BacklogItem ist noch keine freigegebene Maßnahme.

18.2 Action

Eine Action ist eine freigegebene operative Maßnahme.

Sie ist konkret, statusfähig und zuweisbar.

18.3 Beziehungen

BacklogItems und Actions können auf RoadmapItems einzahlen.

Mögliche Felder:

backlog_items.roadmap_item_id NULL
actions.roadmap_item_id NULL

Langfristig kann ein generisches Relationsmodell folgen.

---

19. Blocker

Ein Blocker ist ein eigenes Steuerungsobjekt.

Er kann sich beziehen auf:

- Initiative
- RoadmapItem
- BacklogItem
- Action
- WorkCycle
- Review

AP0.8 sollte mindestens ermöglichen:

blockers.initiative_id
blockers.action_id NULL
blockers.roadmap_item_id NULL

Ein Blocker ist nicht nur action.status = blocked.

action.status = blocked bleibt ein kompatibler operativer Status, aber der Blocker als Objekt trägt Kontext, Ursache und Steuerungslogik.

---

20. Signals

Signals sind erste sichtbare Ergebnisse der Steuerungsengine.

20.1 Signal Types

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

AP0.8 soll aktiv liefern:

attention
next_action

Weitere Signal Types werden fachlich vorbereitet.

20.2 AttentionItem

Ein AttentionItem sagt:

Dieser Steuerungspunkt braucht Aufmerksamkeit.

Beispiele:

- offene Blocker
- blockierte Actions
- RoadmapItem at_risk
- BacklogItem accepted ohne Action
- RoadmapItem planned ohne BacklogItems
- Initiative ohne nächste Maßnahme

20.3 NextActionCandidate

Ein NextActionCandidate sagt:

Dies ist eine sinnvolle nächste Handlung.

Beispiele:

- BacklogItem in Action umwandeln
- Blocker klären
- RoadmapItem strukturieren
- WBS erstellen
- Evidence sammeln
- Review durchführen
- Dependency analysieren
- DoD definieren

---

21. Workflow Engine – Zielbild

Die spätere Workflow Engine sollte nicht als beliebige freie Automatisierungsplattform starten.

Sie sollte fachlich über Hooks und Nodes strukturiert werden.

Hook Point
  → Workflow Binding
    → Workflow Definition
      → Workflow Node
        → Signal / State Change / Task / Result

---

22. Hook Points

Hook Points sind fachlich stabile Einhängepunkte.

Initiale Hook-Kategorien:

intake
structure
planning
execution
monitoring
review
adaptation
closure

Beispiele:

on_intake_created
on_scope_clarification_needed
on_structure_required
on_wbs_required
on_plan_commit_required
on_dependency_analysis_required
on_next_action_requested
on_execution_started
on_progress_updated
on_blocker_created
on_status_changed
on_dod_definition_required
on_dod_check_required
on_evidence_required
on_review_due
on_replan_required
on_closure_requested

AP0.8 muss Hooks noch nicht als ausführbare Workflows implementieren.

Aber Attention/NextAction sollte bereits hook_key oder reason_code nutzen, damit die spätere Einhängung möglich bleibt.

---

23. Workflow Node Types

Die spätere Workflow Engine braucht unterschiedliche Node-Typen.

Initiale fachliche Node-Taxonomie:

23.1 Signal Nodes

signal_listener
signal_emitter
attention_generator
next_action_generator

Zweck:

• Signale wahrnehmen
• Signale erzeugen
• Attention Items erzeugen
• NextActionCandidates erzeugen

23.2 Rule Nodes

rule_evaluator
condition_check
policy_check

Zweck:

• Regeln prüfen
• Bedingungen auswerten
• Policies anwenden

23.3 Human Nodes

human_task
approval
decision_gate
review
reflection

Zweck:

• menschliche Arbeit
• Freigabe
• Entscheidung
• Review
• Reflexion

23.4 AI / Agent Nodes

llm_prompt
agent_task
agent_review
agent_plan
agent_analysis

Zweck:

• LLM-Aufruf
• Agentenauftrag
• Agenten-Review
• Plan-/Analysevorschlag

23.5 Tool Nodes

tool_call
mcp_call
external_api_call
document_lookup
repository_lookup

Zweck:

• Werkzeuge ausführen
• externe Systeme anbinden
• Dokumente oder Repos durchsuchen

23.6 State Nodes

state_transition
status_update
assignment_update
roadmap_update
backlog_update

Zweck:

• Zustände ändern
• Objekte aktualisieren
• Assignments setzen
• Roadmap/Backlog fortschreiben

23.7 Validation Nodes

evidence_check
dod_check
dependency_analysis
risk_check
quality_gate

Zweck:

• Nachweise prüfen
• Definition of Done prüfen
• Abhängigkeiten analysieren
• Risiken prüfen
• Qualitätsgate durchführen

23.8 Notification Nodes

notification
reminder
escalation

Zweck:

• informieren
• erinnern
• eskalieren

---

24. Node-Kontrakt

Jeder Node-Typ braucht langfristig einen klaren Vertrag.

Mindestens:

- node_type
- purpose
- allowed_inputs
- outputs
- side_effects
- actor_responsibility
- tenant_context_required
- capability_required
- audit_required
- failure_behavior
- retry_policy optional
- human_approval_required optional

AP0.8 muss diesen Kontrakt nicht technisch vollständig bauen.

Aber die Node-Taxonomie muss fachlich dokumentiert sein.

---

25. Agentensysteme und KI-Steuerung

25.1 Grundentscheidung

Kairo sollte keine vollständige eigene Agentenplattform bauen.

Kairo sollte Agentensysteme als Provider anbinden können.

Kairo:
  - entscheidet Kontext
  - wählt Methode/Hook/Workflow
  - erzeugt Auftrag
  - prüft Rückgabe
  - speichert Ergebnis
  - erzeugt Signal / Action / Evidence

Agentensystem:
  - führt Analyse oder Task aus
  - erzeugt Vorschlag oder Ergebnis
  - liefert strukturierte Antwort zurück

25.2 Agenten sind Actors

Agenten bleiben im Kairo-Modell Actors.

Das ist wichtig für:

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

25.3 Agenten führen Steps aus, aber steuern nicht autonom Kairo

Agenten dürfen nicht ohne Gate:

• Roadmaps verändern
• Actions löschen
• strategische Priorität ändern
• Steering Method ändern
• Workflow Definitions ändern
• Rechte ändern

---

26. AP0.4 Prompt Registry

AP0.4 ist als Prompt-/Workflow-Vorleistung vorhanden.

Im neuen Zielbild wird AP0.4 eingeordnet als:

Prompt Registry
  → später verwendbar für Node-Typ `llm_prompt`

AP0.4 soll aktuell nicht weiter als Produktfeature ausgebaut werden.

Es bleibt eingefroren, bis die Method-/Workflow-Schicht fachlich und strukturell steht.

---

27. Welche Methoden sollen fachlich möglich sein?

27.1 Produktentwicklung

Domain: product_development
Lifecycle: product/project hybrid
Methoden:
- milestone_driven
- cycle_based
- kanban
- hybrid
Roadmap:
- features
- architecture
- releases
- validation
- risks

27.2 Buchentwicklung

Domain: content_development
Lifecycle: content_development_lifecycle
Methoden:
- chapter_based
- draft_review
- research_driven
Roadmap:
- chapters
- research topics
- drafts
- reviews
- publication steps

27.3 Persönliche Reifegradentwicklung

Domain: maturity_development
Lifecycle: maturity_lifecycle
Methoden:
- maturity_progression
- habit_based
- coaching_cycle
Roadmap:
- maturity stages
- capabilities
- practices
- evidence
- reflection

27.4 Programmsteuerung

Domain: program
Lifecycle: program_lifecycle
Methoden:
- portfolio_coordination
- dependency_management
- benefit_realization
Roadmap:
- strategic outcomes
- initiatives
- dependencies
- resources
- benefits

27.5 Routinen/Betrieb

Domain: routine_operations
Lifecycle: routine_lifecycle
Methoden:
- recurring_control
- checklist_based
- exception_driven
Roadmap:
- routines
- cycles
- checks
- exceptions

---

28. AP0.8 – Konsequenz

Der bestehende AP0.8-Entwurf muss vor Umsetzung überarbeitet werden.

Der bisherige Entwurf mit:

Attention
Blocker
BacklogItem
Milestone

ist fachlich nicht falsch, aber zu eng.

Neuer AP0.8-Titel:

AP0.8 – Steering & Development Roadmap Foundation

AP0.8 soll nicht die vollständige Engine bauen, aber die tragfähige Grundlage schaffen.

---

29. AP0.8 Soll-Scope

Teil 0 – Engine Decision dokumentieren

Dieses Dokument oder eine verdichtete Fassung ins Repo übernehmen.

Teil 1 – Steering Context Foundation

Implementieren oder zumindest als Migration vorbereiten:

steering_contexts

Minimal aktiv:

scope_type = initiative
scope_type = roadmap_item
scope_type = action optional

Teil 2 – Roadmap Foundation

Implementieren:

roadmaps
roadmap_lanes
roadmap_items

Milestone wird RoadmapItem.

Teil 3 – BacklogItem

Implementieren:

backlog_items

Mit optionalem Bezug:

roadmap_item_id

Teil 4 – Blocker

Implementieren:

blockers

Mit optionalem Bezug:

action_id
roadmap_item_id

Teil 5 – Signals

Implementieren:

AttentionItem als Read Model
NextActionCandidate als Read Model

Regelbasiert, ohne KI.

Teil 6 – UI minimal

Im Vorhaben-Detail:

Roadmap
Backlog
Blocker
Attention

Keine große Designer-UI.

---

30. AP0.8 Nicht-Scope

Nicht bauen:

- vollständige Workflow Runtime
- Workflow Designer
- Method Designer
- tenant-konfigurierbare Method Profiles
- vollständige Node Execution Engine
- LLM-Step-Ausführung
- Agentenlaufsteuerung
- MCP
- WBS-Generator
- Dependency Engine
- DoD Engine
- vollständige Evidence-/Review-Engine
- Kanban Board
- Sprint Board
- Burndown
- Velocity
- Gantt
- Kalenderintegration

---

31. AP0.8 Muss aber vorbereiten

AP0.8 muss fachlich und strukturell vorbereiten:

- Hook Points
- Signal Types
- RoadmapItem-Typen
- Steering Domains
- Lifecycle Models
- Method Keys
- spätere Workflow Node Types
- spätere Agent Provider
- spätere LLM Prompt Steps
- spätere Tool/MCP Steps

---

32. Komplexitätsregel für Implementierung

Bei jeder Implementierungsentscheidung gilt:

Baue nur, was für AP0.8 sichtbar nutzbar oder strukturell notwendig ist.
Dokumentiere, was später kommt.
Verbaue spätere Workflow-/Method-/Agent-Fähigkeit nicht.

Das bedeutet:

• Roadmap Foundation ja
• Backlog/Blocker ja
• Attention/NextAction ja
• Workflow Runtime nein
• KI-Ausführung nein
• Method Designer nein

---

33. Offene AP0.8-Entscheidungen

Vor finalem AP0.8-Prompt zu entscheiden:

1. Wird steering_contexts in AP0.8 wirklich implementiert oder nur dokumentiert?
2. Wird actions.roadmap_item_id direkt ergänzt?
3. Wird backlog_items.roadmap_item_id direkt ergänzt?
4. Wird blockers.roadmap_item_id direkt ergänzt?
5. Welche roadmap_item.status-Werte gelten initial?
6. Welche roadmap_item.item_type-Werte gelten initial?
7. Welche roadmap_type-Werte gelten initial?
8. Welche minimalen UI-Elemente reichen?
9. Wird AP0.8 in einem großen Auftrag oder in AP0.8a/b/c umgesetzt?
10. Welche Capabilities werden eingeführt?

---

34. Empfohlene Initialwerte

34.1 roadmap_item.status

planned
active
at_risk
completed
moved
discarded

34.2 roadmap_item.item_type

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

34.3 roadmap_type

product
program
project
content
personal_development
maturity
operations
learning
custom

34.4 steering_domain

program
project
product_development
content_development
personal_development
maturity_development
routine_operations
audit_review
agent_execution
custom

34.5 lifecycle_model

project_lifecycle
program_lifecycle
product_development_lifecycle
content_development_lifecycle
maturity_lifecycle
routine_lifecycle
review_lifecycle
agent_run_lifecycle
custom_lifecycle

---

35. Zusammenfassung der Entscheidung

Kairo soll langfristig sehr unterschiedliche Entwicklungen steuern können:

- Softwareprodukt
- Buch
- persönliche Fähigkeit
- Reifegradziel
- Programm
- Routine
- Review/Audit
- Agentenarbeit

Dafür reicht weder eine einfache Aufgabenliste noch eine rein projektzentrierte Lifecycle-Logik.

Die zentrale Architekturentscheidung lautet:

Kairo baut eine universelle fachliche Steuerungsengine mit:
- Steerable Objects
- Steering Contexts
- Steering Domains
- Lifecycle Models
- Steering Methods
- Method Profiles
- Development Roadmaps
- Hook Points
- Signals
- später Workflow Nodes
- später Agent-/LLM-/Tool-Steps

Aber:

AP0.8 baut nur die erste tragfähige Foundation:
- Steering Context vorbereiten
- Roadmap Foundation
- Backlog
- Blocker
- Attention / NextAction als erste Signals

Damit bleibt Kairo universell erweiterbar, ohne sofort eine unbeherrschbare Workflow-/Agentenplattform zu werden.

---

36. Nächster Schritt

Auf Basis dieses Dokuments sollte der bestehende AP0.8-Entwurf ersetzt oder deutlich überarbeitet werden.

Empfohlenes Folgeartefakt:

Sprint0_AP0_8_Assignment_v0.2.md

Empfohlener Titel:

AP0.8 – Steering & Development Roadmap Foundation