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:

```text
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:

```text
- 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
- 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:

```text
- 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:

```text
ausführende Provider
```

nicht:

```text
führende Steuerungsinstanz
```

---

## 6. Komplexitätsbremse

Die Architektur wird in drei Ebenen geschnitten.

### Ebene 1 – Signals und Read Models

Kurzfristig und MVP-nah.

```text
- Attention
- NextActionCandidate
- EvidenceRequired
- DecisionRequired
- BlockerSignal
- ReviewDue
```

Diese Ebene liefert Produktnutzen ohne vollständige Workflow Runtime.

### Ebene 2 – Hook-basierte Workflows

Mittelfristig.

```text
- 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.

```text
- 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:

```text
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:

```text
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:

```text
initiative
roadmap_item
backlog_item
action
blocker
```

---

## 9. Steering Domain

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

Initiale Domains:

```text
program
project
product_development
content_development
personal_development
maturity_development
routine_operations
audit_review
agent_execution
custom
```

### 9.1 Beispiele

#### Software-/Produktentwicklung

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

#### Buchentwicklung

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

#### Persönliche Fähigkeitsentwicklung

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

#### Programmsteuerung

```text
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

```text
intake
clarify
structure
plan
execute
monitor
review
adapt
close
```

### 10.2 Program Lifecycle

```text
define_intent
establish_structure
prioritize_initiatives
coordinate_dependencies
allocate_capacity
monitor_benefits
resolve_conflicts
review_outcomes
rebalance
close
```

### 10.3 Maturity Development Lifecycle

```text
assess_current_level
define_target_maturity
identify_gaps
select_intervention
practice
collect_evidence
reflect
adjust_challenge
reassess
```

### 10.4 Content Development Lifecycle

```text
define_concept
structure_content
research
draft
review
revise
prepare_publication
publish
maintain
```

### 10.5 Routine Operations Lifecycle

```text
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:

```text
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:

```sql
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:

```text
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:

```text
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:

```text
- 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:

```json
{
  "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:

```text
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:

```text
- 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.

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

### 15.1 Roadmap-Struktur

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

### 15.2 Warum Roadmap universell sein muss

Eine Softwareentwicklung braucht z. B.:

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

Eine Buchentwicklung braucht:

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

Eine persönliche Entwicklung braucht:

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

Deshalb darf Roadmap nicht nur aus Milestones bestehen.

---

## 16. Roadmap-Datenmodell

### 16.1 roadmaps

```sql
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`:

```text
product
program
project
content
personal_development
maturity
operations
learning
custom
```

### 16.2 roadmap_lanes

```sql
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`:

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

### 16.3 roadmap_items

```sql
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`:

```text
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:

```text
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:

```text
- 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:

```text
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:

```text
- Initiative
- RoadmapItem
- BacklogItem
- Action
- WorkCycle
- Review
```

AP0.8 sollte mindestens ermöglichen:

```text
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

```text
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:

```text
attention
next_action
```

Weitere Signal Types werden fachlich vorbereitet.

### 20.2 AttentionItem

Ein AttentionItem sagt:

> Dieser Steuerungspunkt braucht Aufmerksamkeit.

Beispiele:

```text
- 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:

```text
- 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.

```text
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:

```text
intake
structure
planning
execution
monitoring
review
adaptation
closure
```

Beispiele:

```text
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

```text
signal_listener
signal_emitter
attention_generator
next_action_generator
```

Zweck:

- Signale wahrnehmen
- Signale erzeugen
- Attention Items erzeugen
- NextActionCandidates erzeugen

### 23.2 Rule Nodes

```text
rule_evaluator
condition_check
policy_check
```

Zweck:

- Regeln prüfen
- Bedingungen auswerten
- Policies anwenden

### 23.3 Human Nodes

```text
human_task
approval
decision_gate
review
reflection
```

Zweck:

- menschliche Arbeit
- Freigabe
- Entscheidung
- Review
- Reflexion

### 23.4 AI / Agent Nodes

```text
llm_prompt
agent_task
agent_review
agent_plan
agent_analysis
```

Zweck:

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

### 23.5 Tool Nodes

```text
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

```text
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

```text
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

```text
notification
reminder
escalation
```

Zweck:

- informieren
- erinnern
- eskalieren

---

## 24. Node-Kontrakt

Jeder Node-Typ braucht langfristig einen klaren Vertrag.

Mindestens:

```text
- 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.

```text
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:

```text
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

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

### 27.2 Buchentwicklung

```text
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

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

### 27.4 Programmsteuerung

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

### 27.5 Routinen/Betrieb

```text
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:

```text
Attention
Blocker
BacklogItem
Milestone
```

ist fachlich nicht falsch, aber zu eng.

Neuer AP0.8-Titel:

```text
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:

```text
steering_contexts
```

Minimal aktiv:

```text
scope_type = initiative
scope_type = roadmap_item
scope_type = action optional
```

### Teil 2 – Roadmap Foundation

Implementieren:

```text
roadmaps
roadmap_lanes
roadmap_items
```

Milestone wird RoadmapItem.

### Teil 3 – BacklogItem

Implementieren:

```text
backlog_items
```

Mit optionalem Bezug:

```text
roadmap_item_id
```

### Teil 4 – Blocker

Implementieren:

```text
blockers
```

Mit optionalem Bezug:

```text
action_id
roadmap_item_id
```

### Teil 5 – Signals

Implementieren:

```text
AttentionItem als Read Model
NextActionCandidate als Read Model
```

Regelbasiert, ohne KI.

### Teil 6 – UI minimal

Im Vorhaben-Detail:

```text
Roadmap
Backlog
Blocker
Attention
```

Keine große Designer-UI.

---

## 30. AP0.8 Nicht-Scope

Nicht bauen:

```text
- 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:

```text
- 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:

```text
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

```text
planned
active
at_risk
completed
moved
discarded
```

### 34.2 roadmap_item.item_type

```text
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

```text
product
program
project
content
personal_development
maturity
operations
learning
custom
```

### 34.4 steering_domain

```text
program
project
product_development
content_development
personal_development
maturity_development
routine_operations
audit_review
agent_execution
custom
```

### 34.5 lifecycle_model

```text
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:

```text
- 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:

```text
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:

```text
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:

```text
Sprint0_AP0_8_Assignment_v0.2.md
```

Empfohlener Titel:

```text
AP0.8 – Steering & Development Roadmap Foundation
```