Doku: AP0.8 Implementierungsauftrag v0.2 (Überarbeitung und Feedback integriert)

docs/architecture/KAIRO-ARCH-01_Completion_Report_v0.1.md

@@ -0,0 +1,166 @@
+# KAIRO-ARCH-01 – Abschlussbericht
+
+**Status:** abgeschlossen  
+**Stand:** 2026-07-05  
+**Auftrag:** `docs/architecture/Kairo_Target_Architecture_Assignment_Method_Driven_Adaptive_Steering_Core_v0.2.md`  
+**Ergebnis:** Zielarchitektur v0.1 (Nordstern, keine Implementierung)
+
+---
+
+## 1. Erstellte Dateien
+
+| Datei | Zweck |
+|-------|-------|
+| `docs/architecture/Kairo_Target_Architecture_Method_Driven_Adaptive_Steering_Core_v0.1.md` | Technische Zielarchitektur (20 Kapitel) |
+| `docs/architecture/KAIRO-ARCH-01_Completion_Report_v0.1.md` | Dieser Abschlussbericht |
+
+**Gelesene Grundlagen (alle vorhanden):**
+
+- `docs/architecture/Kairo_Core_Model_Decision_v0.2.md`
+- `docs/architecture/Kairo_Method_Design_Principles_v0.1.md`
+- `docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md`
+- `docs/product/Kairo_Canonical_Operating_Model_v0.1.md`
+- `docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md`
+- `docs/architecture/Kairo_Tenant_Invariants_v0.1.md`
+- `docs/sprints/Sprint0_AP0_7_Completion_Report_v0.2.md`
+
+**Fehlende Dokumente:** keine — alle im Auftrag genannten Grundlagen waren im Repo vorhanden.
+
+---
+
+## 2. Wichtigste Architekturentscheidungen
+
+| # | Entscheidung |
+|---|--------------|
+| 1 | **Kairo ist methodengeführter Steuerungskern**, keine freie Workflow Engine |
+| 2 | **Drei Ebenen:** Steering Method → Steering Workflow (Lifecycle/Hooks) → Workflow Runtime (später) |
+| 3 | **Method Registry** als zentraler Erweiterungspunkt — analog zu bestehendem Capability/Feature-Registry-Muster |
+| 4 | **Hook Slugs** als stabile Einhängepunkte zwischen Core, Methoden und späteren Workflow-Fragmenten |
+| 5 | **Standard Lifecycle** (12 Schritte) als gemeinsame Basis; Methoden aktivieren/spezialisieren |
+| 6 | **Gemeinsame Kernstrukturen** — RoadmapItem als generisches Strukturelement (Milestone, Feature, Kapitel, Reifegradstufe) |
+| 7 | **Attention/NextAction** als erklärbare Read Models im Data Layer; Signal Rule Providers methodenregistrierbar |
+| 8 | **Kairo bleibt Steering Authority** — Agenten sind Actors/Provider, nicht eigenständige Steuerungsinstanzen |
+| 9 | **Prompt/Workflow-Runtime bleibt eingefroren** bis Operating-Model-MVP (AP0.8–0.10) trägt |
+| 10 | **Neue Schicht `backend/steering/`** — schrittweise nach AP0.8, ohne Foundation-Umbau |
+
+---
+
+## 3. Kritische Bewertung der fachlichen Annahmen
+
+### 3.1 Bestätigt
+
+Die fachliche Präferenz **„methodengeführter Steuerungskern statt freier Workflow-Baukasten“** ist aus Sicht der Codebase **tragfähig**:
+
+- Registry-Muster (Capabilities, Features, Prompts) ist etabliert und erprobt
+- Tenant/Actor/Capability-Foundation ist produktionsreif (AP0.7)
+- Data Layer als Read-Schicht passt zur Attention-/Signal-Architektur
+- Product Reset und Principle Gate verbieten vorzeitige Workflow/KI-Ausbauten — konsistent mit Zielarchitektur
+
+### 3.2 Präzisiert
+
+| Annahme | Bewertung |
+|---------|-----------|
+| Standard Lifecycle (12 Schritte) | Tragfähig als **generische Steuerungslogik**; UI muss fachliche Labels zeigen, nicht technische States |
+| Hook Registry | Sinnvoll; Versionierung über `since_version` + Deprecation, nicht über Slug-Änderung |
+| Structure Builder | Korrekt als methodenspezifische Erweiterung; **muss Domain Services nutzen**, nicht Router/SQL |
+| Milestone als eigenes Objekt (AP0.8) | MVP-pragmatisch; Zielarchitektur empfiehlt **Konsolidierung zu RoadmapItem** in Phase C |
+| Methoden sofort im MVP | **Nein** — erst Operating-Model-Entitäten, dann SteeringContext + erste Built-in Method |
+
+### 3.3 Abweichung von Method Design Principles
+
+Keine inhaltliche Abweichung. Technische Präzisierung: AP0.8 Attention startet als **globaler Rule Provider** in `data_layer/attention.py` und wird später in die Signal Engine refactored — bewusste Brücke, kein Widerspruch.
+
+---
+
+## 4. Empfohlene Zielarchitektur
+
+**Kurzfassung:**
+
+```text
+Foundation (bestehend)
+  + Domain Operating Model (AP0.8 → AP0.9)
+  + Steering Core (Method/Hooks/Lifecycle/Signals)
+  + Method Packages (Built-in)
+  + später: Workflow Fragments + Runtime + Agent/LLM Nodes
+```
+
+**Kernmodell:**
+
+```text
+Initiative
+  → SteeringContext (method_key, version, lifecycle_state)
+    → Method Registry → Structure Builders + Strategies + Signal Rules
+      → gemeinsame Strukturen (Roadmap, Backlog, Action, Blocker, Evidence, Review, …)
+        → Attention / NextAction (Read Models)
+          → Assignment → Waiting → Result Intake → Review → Adaptation
+```
+
+Das vollständige Dokument: `Kairo_Target_Architecture_Method_Driven_Adaptive_Steering_Core_v0.1.md`.
+
+---
+
+## 5. Was gegenüber der bisherigen Architektur geändert werden sollte
+
+| Bereich | Bisher | Soll (Ziel) |
+|---------|--------|-------------|
+| Produktkern | Initiative → Action (flach) | Methodengeführter SteeringContext + Operating Model |
+| Steuerungslogik | verstreut in Services/Data Layer | `backend/steering/` mit Registry, Lifecycle, Hooks, Signals |
+| Blocker | nur Action-Status | eigenes Objekt (AP0.8) |
+| Struktur | keine Roadmap/Backlog/Milestone | Operating Model + RoadmapItem-Generik |
+| Attention | fehlt | Data Layer + später Signal Engine |
+| Methoden | nicht modelliert | Method Registry + Built-in Methods |
+| Workflow/Prompt | technisch vorhanden, eingefroren | später hook-gebundene Fragmente, nicht Produktkern |
+| Milestone (AP0.8) | — | eigene Tabelle als Brücke → RoadmapItem konsolidieren |
+
+**Was bleibt unverändert:**
+
+- TenantContext, Actor-Modell, Capabilities, Audit-Grundlage
+- Router dünn / Services Write / Data Layer Read
+- Frontend Widget/View Registry
+- Nummerierte Migrationen, Registry-first Capabilities
+
+---
+
+## 6. Risiken
+
+| Risiko | Schwere | Hinweis |
+|--------|---------|---------|
+| Vorzeitige Workflow-Runtime | hoch | Operating Model MVP zuerst |
+| Over-Engineering Steering-Schicht | mittel | Skeleton erst nach AP0.8 |
+| Doppelmodell Milestone/RoadmapItem | mittel | ADP vor Konsolidierung |
+| Lifecycle zu abstrakt für Nutzer | mittel | Fachliche UI-Labels |
+| Methoden-Explosion | mittel | Built-in only, Review-Gate |
+| Agenten ohne klare Authority-Grenze | hoch | Canonical Model §11 durchsetzen |
+
+---
+
+## 7. Offene Entscheidungen
+
+1. **SteeringContext-Einführung** — mit AP0.9 oder als AP1.0?
+2. **Milestone → RoadmapItem Migration** — Zeitpunkt und Strategie
+3. **Generisches Assignment** — über Actions hinaus, wann?
+4. **Scheduler für Waiting/Reminder** — Infrastruktur-Wahl
+5. **Audit `actor_id`-Spalte** — Nachzug vor Agent-Integration
+6. **Erste Built-in Method** — `generic_operating` vs. direkt `product_milestone_driven`?
+
+Diese Punkte sollten als Architecture Decision Proposals vor der Steering-Core-Implementierung geklärt werden.
+
+---
+
+## 8. Empfehlung für den nächsten Schritt
+
+**Nicht** sofort `backend/steering/` implementieren.
+
+**Empfohlene Reihenfolge:**
+
+1. **AP0.8 freigeben und umsetzen** (`Sprint0_AP0_8_Assignment_v0.1.md`) — Attention, Blocker, BacklogItem, Milestone
+2. **AP0.9** — Evidence, Decision, Review, RecurringElement
+3. **AP0.10** — Validierung mit realem Testvorhaben
+4. **ADP:** SteeringContext-Einführung + Milestone/RoadmapItem-Strategie
+5. **Danach:** `backend/steering/` Skeleton + erste Built-in Method
+
+Die Zielarchitektur dient als **Nordstern** für AP0.8–AP0.10 und verhindert Rückfall auf reines Initiative→Action sowie vorzeitige Workflow-Engine-Arbeit.
+
+---
+
+*KAIRO-ARCH-01 abgeschlossen — reine Architekturarbeit, keine Code-Änderungen.*

docs/architecture/Kairo_Core_Model_Decision_v0.2.md

@@ -0,0 +1,642 @@
+# Kairo – Core Model Decision
+## v0.2 – Adaptive Steering Core mit methodengeführten Steuerungsworkflows
+
+**Status:** fachliche Architekturentscheidung  
+**Stand:** 2026-07-05  
+**Ersetzt / präzisiert:** `Kairo_Universal_Steering_Engine_Decision_v0.1.md` und `Kairo_Steering_Engine_Roadmap_Discussion_v0.1.md` in Bezug auf den fachlichen Produktkern  
+**Zweck:** Präzisierung des Kairo-Kerns vor der technischen Zielarchitektur
+
+---
+
+## 1. Anlass der Präzisierung
+
+In der bisherigen Diskussion wurde Kairo teilweise als universelle Steuerungs- und Workflow-Engine beschrieben.
+
+Diese Beschreibung war in der Tendenz richtig, aber noch missverständlich.
+
+Der Begriff „Workflow Engine“ kann technisch verstanden werden als:
+
+```text
+Trigger → Nodes → Transitions → Runs → Step Results
+```
+
+Das wäre für Kairo als Produktkern zu eng und zugleich zu technisch.
+
+Der Nutzer meint mit „Workflow“ jedoch nicht primär eine technische Automatisierungsruntime, sondern den **fachlichen Steuerungsablauf**, nach dem ein steuerbarer Kontext aufgebaut, geführt, überprüft und weiterentwickelt wird.
+
+Beispielhafter Steuerungsablauf:
+
+```text
+Ziel erfassen
+→ Name / Scope definieren
+→ Basismethode wählen
+→ Steuerungsstruktur gemäß Methode anlegen
+→ Roadmap / Backlog / WBS / Reifegradpfad / Kapitelstruktur erzeugen
+→ Next Best Action ableiten
+→ Actor zuweisen
+→ auf Ergebnis warten
+→ erinnern / eskalieren / prüfen
+→ Ergebnis zurückführen
+→ nächste Steuerungsentscheidung treffen
+```
+
+Dieser Ablauf ist tatsächlich fachlicher Kern von Kairo.
+
+---
+
+## 2. Zentrale Entscheidung
+
+Kairo ist im Kern **keine freie Workflow-Plattform**.
+
+Kairo ist im Kern eine:
+
+```text
+Adaptive Development Steering Platform
+```
+
+mit einem:
+
+```text
+Method-driven Adaptive Steering Core
+```
+
+Deutsch:
+
+```text
+methodengeführter adaptiver Steuerungskern
+```
+
+Dieser Kern führt steuerbare Kontexte über methodenspezifische Steuerungsabläufe.
+
+---
+
+## 3. Was ist der Adaptive Steering Core?
+
+Der Adaptive Steering Core beantwortet dauerhaft:
+
+```text
+Was wird gesteuert?
+Was ist das Ziel?
+Welche Methode gilt?
+Welche Steuerungsstruktur braucht diese Methode?
+Welche Roadmap / WBS / Backlog / Reifegradstruktur / Kapitelstruktur ist anzulegen?
+Was ist der aktuelle Zustand?
+Was fehlt?
+Was blockiert?
+Was braucht Aufmerksamkeit?
+Was ist die nächste wirksame Aktion?
+Wer oder welcher Agent soll handeln?
+Worauf wartet Kairo?
+Wann muss erinnert, eskaliert, geprüft oder neu geplant werden?
+Welche Ergebnisse, Nachweise, Entscheidungen oder Reviews müssen zurückgeführt werden?
+```
+
+---
+
+## 4. Abgrenzung zur technischen Workflow Runtime
+
+Es gibt drei Ebenen:
+
+```text
+1. Steering Method
+   = fachliche Logik, wie ein Kontext geführt wird
+
+2. Steering Workflow
+   = methodenspezifischer Steuerungsablauf über definierte Lifecycle- und Hook-Schritte
+
+3. Workflow Runtime
+   = technische Maschine, die später Schritte, Zustände, Trigger, Wait States, Agentenaufrufe und Ergebnisse ausführt
+```
+
+Die technische Workflow Runtime ist wichtig, aber nicht identisch mit dem Produktkern.
+
+Der Produktkern ist der methodengeführte Steuerungsablauf.
+
+---
+
+## 5. Zielmodell
+
+```text
+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
+          → Review / Adaptation
+            → optionale Workflow-Fragmente
+              → optionale Human / Agent / LLM / Tool Steps
+```
+
+---
+
+## 6. Minimaler Standard Lifecycle
+
+Kairo benötigt einen minimalen Standard Lifecycle, der von Methoden genutzt, erweitert oder spezialisiert werden kann.
+
+Dieser Standard Lifecycle ist nicht als starrer Projektprozess zu verstehen, sondern als generische Steuerungslogik.
+
+```text
+intake
+method_selection
+structure_setup
+planning
+action_selection
+assignment
+waiting
+result_intake
+validation
+review
+adaptation
+closure
+```
+
+### 6.1 Intake
+
+Ziel, Name, Kontext und initialer Scope werden erfasst.
+
+Typische Hooks:
+
+```text
+on_goal_captured
+on_scope_named
+on_initial_context_created
+```
+
+### 6.2 Method Selection
+
+Eine Basismethode wird gewählt oder vorgeschlagen.
+
+Typische Hooks:
+
+```text
+on_method_selection_required
+on_method_selected
+on_method_profile_required
+```
+
+### 6.3 Structure Setup
+
+Gemäß Methode wird die Steuerungsstruktur angelegt.
+
+Beispiele:
+
+```text
+Backlog
+WBS
+Roadmap / Meilensteinplan
+Reifegradpfad
+Kapitelstruktur
+Feature Landscape
+WorkCycles
+Review Gates
+```
+
+Typische Hooks:
+
+```text
+on_structure_required
+on_roadmap_required
+on_backlog_required
+on_wbs_required
+on_maturity_path_required
+on_content_structure_required
+on_cycle_structure_required
+```
+
+### 6.4 Planning
+
+Die nächste steuerbare Planungsebene wird konkretisiert.
+
+Typische Hooks:
+
+```text
+on_plan_required
+on_dependency_analysis_required
+on_dod_definition_required
+on_evidence_policy_required
+```
+
+### 6.5 Action Selection
+
+Kairo leitet Next Best Actions oder NextActionCandidates ab.
+
+Typische Hooks:
+
+```text
+on_next_action_requested
+on_attention_scan_requested
+```
+
+### 6.6 Assignment
+
+Ein Actor wird zugewiesen.
+
+Actors können sein:
+
+```text
+human
+agent
+working_group
+external_system
+```
+
+Typische Hooks:
+
+```text
+on_assignment_required
+on_actor_selection_required
+```
+
+### 6.7 Waiting
+
+Kairo wartet auf Ergebnis, Termin, Rückmeldung, externes Ereignis oder Statusänderung.
+
+Typische Hooks:
+
+```text
+on_wait_started
+on_due_date_reached
+on_result_overdue
+on_reminder_required
+on_escalation_required
+```
+
+### 6.8 Result Intake
+
+Ein Ergebnis wird zurückgeführt.
+
+Typische Hooks:
+
+```text
+on_result_received
+on_actor_update_received
+on_agent_result_received
+```
+
+### 6.9 Validation
+
+Ergebnis, DoD, Evidence oder Qualität werden geprüft.
+
+Typische Hooks:
+
+```text
+on_dod_check_required
+on_evidence_required
+on_quality_gate_required
+```
+
+### 6.10 Review
+
+Ein Review, Assessment oder eine Reflexion wird ausgelöst.
+
+Typische Hooks:
+
+```text
+on_review_due
+on_reassessment_required
+on_reflection_required
+```
+
+### 6.11 Adaptation
+
+Kairo entscheidet über Nachsteuerung.
+
+Typische Hooks:
+
+```text
+on_replan_required
+on_structure_update_required
+on_method_adjustment_required
+```
+
+### 6.12 Closure
+
+Ein Kontext, RoadmapItem, WorkCycle, Review oder Action wird abgeschlossen.
+
+Typische Hooks:
+
+```text
+on_closure_requested
+on_close_allowed
+on_archive_required
+```
+
+---
+
+## 7. Methodengeführte Steuerungsworkflows
+
+Jede Methode definiert, wie der Standard Lifecycle genutzt wird.
+
+Eine Methode kann:
+
+```text
+- Lifecycle-Schritte aktivieren/deaktivieren
+- eigene Hook Slugs ergänzen
+- bestimmte Steuerungsstrukturen verlangen
+- bestimmte Structure Builder bereitstellen
+- NextAction-Strategien definieren
+- Review-/Evidence-Policies definieren
+- Assignment-/Waiting-Strategien definieren
+- erlaubte Workflow-Fragmente an Hooks registrieren
+```
+
+Beispiel:
+
+```text
+Methode: maturity_progression
+
+nutzt:
+- intake
+- method_selection
+- structure_setup
+- action_selection
+- assignment
+- waiting
+- result_intake
+- validation
+- review
+- adaptation
+
+Structure Builder:
+- Roadmap Lane: Reifegradstufen
+- Roadmap Lane: Fähigkeiten
+- Roadmap Lane: Praxis
+- Roadmap Lane: Evidence
+- Roadmap Lane: Reflexion
+
+NextAction Strategy:
+- aktuellen Reifegrad bewerten
+- Zielreifegrad definieren
+- Gap identifizieren
+- Praxisaufgabe auswählen
+- Evidence sammeln
+- Review durchführen
+```
+
+---
+
+## 8. Keine beliebige freie Workflow-Konfiguration als Startpunkt
+
+Kairo soll langfristig konfigurierbar sein, aber nicht durch beliebige Nutzer-Workflows beliebig werden.
+
+Entscheidung:
+
+```text
+Initial keine frei modellierbaren Methoden durch Nutzer.
+```
+
+Stattdessen:
+
+```text
+- Built-in Methods mit method_key / slug
+- definierte Hook Slugs
+- definierte Structure Builder
+- definierte Rule Provider
+- definierte Signal Generatoren
+- definierte NextAction Strategies
+- definierte erlaubte Workflow-Fragmente
+- später Method Profiles und konfigurierbare Bindings
+```
+
+---
+
+## 9. Rollen der technischen Komponenten
+
+### 9.1 Method Registry
+
+Zentrales Register, in dem Methoden angemeldet werden.
+
+Ähnlich einem Widget-System.
+
+Eine Methode muss sich registrieren mit:
+
+```text
+method_key
+version
+supported_domains
+supported_scope_types
+default_lifecycle
+required_structures
+allowed_structures
+hook_slugs
+structure_builders
+signal_rules
+next_action_strategy
+assignment_strategy
+waiting_strategy
+review_strategy
+evidence_policy
+allowed_workflow_fragments
+allowed_node_types
+```
+
+### 9.2 Hook Registry
+
+Register bekannter Hook Slugs.
+
+Sie dient zur Stabilisierung der Einhängepunkte.
+
+### 9.3 Structure Builder
+
+Ein Structure Builder legt methodenspezifische Steuerungsstrukturen an.
+
+Beispiele:
+
+```text
+Roadmap Builder
+Backlog Builder
+WBS Builder
+Maturity Path Builder
+Chapter Structure Builder
+Cycle Builder
+Review Gate Builder
+```
+
+### 9.4 Signal Engine
+
+Erzeugt Attention, NextActionCandidate und später weitere Signals.
+
+### 9.5 Strategy Interfaces
+
+Methoden liefern oder referenzieren Strategien:
+
+```text
+NextActionStrategy
+AssignmentStrategy
+WaitingStrategy
+ReminderStrategy
+EscalationStrategy
+ReviewStrategy
+EvidencePolicy
+ClosurePolicy
+```
+
+### 9.6 Workflow Fragment Layer
+
+An Hooks können später kleinere Workflow-Fragmente eingehängt werden.
+
+Diese sind nicht beliebig global, sondern methoden- und hookgebunden.
+
+---
+
+## 10. Beispiele für Methoden
+
+### 10.1 Produktentwicklung / Softwareentwicklung
+
+```text
+method_key: product_milestone_driven
+domain: product_development
+default_lifecycle: standard_development_lifecycle
+
+Structures:
+- Roadmap
+- Feature Landscape
+- Architecture Lane
+- Release Lane
+- Backlog
+- Actions
+- Blockers
+
+NextAction Strategy:
+- wenn Roadmap fehlt → Roadmap anlegen
+- wenn Feature ohne Backlog → BacklogItem erzeugen
+- wenn accepted BacklogItem ohne Action → Action erstellen
+- wenn Action blockiert → Blocker klären
+- wenn Release at_risk → Review / Replan
+```
+
+### 10.2 Buchentwicklung
+
+```text
+method_key: content_chapter_based
+domain: content_development
+
+Structures:
+- Roadmap Lane: Buchstruktur
+- Roadmap Lane: Kapitel
+- Roadmap Lane: Recherche
+- Roadmap Lane: Review
+- Backlog für Themen / Lücken / Recherchefragen
+- Actions für Schreib- und Reviewaufgaben
+
+NextAction Strategy:
+- Konzept klären
+- Kapitelstruktur anlegen
+- nächstes Kapitel auswählen
+- Recherchebedarf erzeugen
+- Draft schreiben
+- Review durchführen
+```
+
+### 10.3 Persönliche Reifegradentwicklung
+
+```text
+method_key: maturity_progression
+domain: maturity_development
+
+Structures:
+- Roadmap Lane: Reifegradstufen
+- Roadmap Lane: Fähigkeiten
+- Roadmap Lane: Praxis
+- Roadmap Lane: Evidence
+- Roadmap Lane: Reflexion
+
+NextAction Strategy:
+- aktuellen Reifegrad bewerten
+- Zielreifegrad definieren
+- Gap identifizieren
+- Übung/Praxis auswählen
+- Evidence sammeln
+- Review/Reassessment durchführen
+```
+
+### 10.4 Routine Control
+
+```text
+method_key: recurring_control
+domain: routine_operations
+
+Structures:
+- Routine Definition
+- Run Schedule
+- Checklist
+- Exceptions
+- Review
+
+NextAction Strategy:
+- nächster Run fällig
+- Run verpasst
+- Exception klären
+- Routine anpassen
+```
+
+---
+
+## 11. Konsequenz für die Zielarchitektur
+
+Die technische Zielarchitektur soll nicht als freie Workflow Engine beginnen.
+
+Sie soll den folgenden Kern entwerfen:
+
+```text
+Target Architecture for Method-driven Adaptive Steering Core
+```
+
+Darin enthalten:
+
+```text
+- Standard Lifecycle
+- Method Registry
+- Hook Registry
+- Structure Builder Layer
+- Strategy Interfaces
+- Signal Engine
+- NextAction Engine
+- Assignment / Waiting / Reminder / Escalation Layer
+- Result Intake
+- Review / Adaptation Layer
+- Workflow Fragment Model
+- Agent / LLM / Tool Provider Integration
+```
+
+---
+
+## 12. Kernaussage
+
+Kairo ist nicht einfach:
+
+```text
+Roadmap Tool
+Projektmanagement Tool
+Workflow Engine
+Agentenplattform
+```
+
+Kairo ist:
+
+```text
+eine adaptive, methodengeführte Entwicklungs- und Steuerungsplattform.
+```
+
+Der Kern ist:
+
+```text
+Adaptive Steering Core
+```
+
+mit:
+
+```text
+methodengeführten Steuerungsworkflows
+definierten Hook Slugs
+registrierbaren Methoden
+zentralen gemeinsamen Strukturen
+später konfigurierbaren Method Profiles
+```
+

docs/architecture/Kairo_Method_Design_Principles_v0.1.md

@@ -0,0 +1,590 @@
+# Kairo – Method Design Principles
+## v0.1 – Designprinzipien für registrierbare Steuerungsmethoden
+
+**Status:** verbindlicher Architektur- und Methodendesign-Entwurf  
+**Stand:** 2026-07-05  
+**Zweck:** Definition der Designprinzipien, nach denen Kairo-Methoden künftig entwickelt, registriert, erweitert und versioniert werden.
+
+---
+
+## 1. Ziel
+
+Kairo soll im Lauf der Zeit viele unterschiedliche Steuerungsmethoden unterstützen, ohne dass für jede Methode der komplette Codekern angepasst werden muss.
+
+Methoden sollen sich ähnlich wie Widgets an einem klaren Abstraktionslayer anmelden können.
+
+Die Architektur muss ermöglichen:
+
+```text
+- neue Methoden hinzufügen
+- bestehende Methoden versionieren
+- methodenspezifische Steuerungsstrukturen erzeugen
+- methodenspezifische NextAction-Logik einhängen
+- methodenspezifische Review-/Evidence-Logik einhängen
+- später Method Profiles konfigurieren
+- später Workflow-Fragmente an Hooks binden
+- später Agent/LLM/Tool-Steps pro Methode erlauben
+```
+
+Gleichzeitig darf die Methodenarchitektur nicht beliebig und untestbar werden.
+
+---
+
+## 2. Grundprinzip
+
+Eine Kairo-Methode ist kein Label.
+
+Eine Kairo-Methode ist ein registriertes Steuerungspaket.
+
+Sie beschreibt:
+
+```text
+- für welche Domains sie gilt
+- welche Scope Types sie steuern kann
+- welchen Standard Lifecycle sie nutzt oder erweitert
+- welche Steuerungsstrukturen sie benötigt
+- welche Hook Slugs sie unterstützt
+- welche Structure Builder sie bereitstellt
+- welche Signal Rules sie registriert
+- welche NextAction Strategy sie nutzt
+- welche Assignment / Waiting / Reminder / Escalation Strategy sie nutzt
+- welche Review- und Evidence-Policies gelten
+- welche Workflow-Fragmente später erlaubt sind
+- welche Node Types später erlaubt sind
+```
+
+---
+
+## 3. Method Registry als zentraler Erweiterungspunkt
+
+Alle Methoden registrieren sich in einer zentralen Method Registry.
+
+Zielbild:
+
+```text
+backend/steering/methods/registry.py
+```
+
+Beispielhafte Registrierung:
+
+```python
+register_method(
+    MethodDefinition(
+        method_key="maturity_progression",
+        version="v1",
+        label="Maturity Progression",
+        supported_domains=["maturity_development", "personal_development"],
+        supported_scope_types=["initiative", "roadmap_item", "action"],
+        default_lifecycle="standard_development_lifecycle",
+        required_structures=["roadmap", "roadmap_lanes", "roadmap_items", "backlog", "actions"],
+        hook_slugs=[
+            "on_goal_captured",
+            "on_structure_required",
+            "on_maturity_path_required",
+            "on_next_action_requested",
+            "on_evidence_required",
+            "on_review_due",
+            "on_reassessment_required",
+        ],
+        structure_builders=[
+            "maturity_path_builder",
+            "practice_backlog_builder",
+        ],
+        signal_rule_providers=[
+            "maturity_gap_attention_rules",
+            "evidence_required_rules",
+        ],
+        next_action_strategy="maturity_next_action_strategy",
+        assignment_strategy="default_actor_assignment_strategy",
+        waiting_strategy="default_waiting_strategy",
+        review_strategy="maturity_review_strategy",
+        evidence_policy="maturity_evidence_policy",
+        allowed_node_types=[
+            "human_task",
+            "evidence_check",
+            "review",
+            "reflection",
+            "llm_prompt",
+            "agent_task",
+        ],
+    )
+)
+```
+
+---
+
+## 4. Built-in zuerst, konfigurierbar später
+
+Die Methodenarchitektur folgt einem Stufenmodell.
+
+### Stufe 1 – Built-in Methods
+
+```text
+- Methoden code-seitig definiert
+- klare Slugs
+- testbar
+- keine freie Nutzerkonfiguration
+```
+
+### Stufe 2 – Built-in Method Profiles
+
+```text
+- vordefinierte Profile pro Methode
+- z. B. "einfach", "evidence_strict", "review_driven"
+```
+
+### Stufe 3 – Tenant Method Profiles
+
+```text
+- tenant-spezifische Konfiguration
+- begrenzte Parameter
+- keine freie Ausführungslogik
+```
+
+### Stufe 4 – Workflow Bindings an Hooks
+
+```text
+- kleine Workflow-Fragmente an definierte Hooks
+- nur erlaubte Node Types
+- nur innerhalb Method Governance
+```
+
+### Stufe 5 – Method Designer
+
+```text
+- spätere UI
+- nur für fortgeschrittene Nutzung
+- Governance, Tests und Freigaben erforderlich
+```
+
+---
+
+## 5. Zentrale gemeinsame Strukturen
+
+Alle Methoden müssen auf gemeinsamen Kairo-Strukturen aufbauen.
+
+Gemeinsame Kernstrukturen:
+
+```text
+SteeringContext
+Roadmap
+RoadmapLane
+RoadmapItem
+BacklogItem
+Action
+ActionAssignment
+Blocker
+Signal
+AttentionItem
+NextActionCandidate
+Evidence
+Review
+Decision
+Actor
+Capability
+AuditEvent
+```
+
+Eine Methode darf keine parallelen Kernmodelle erfinden.
+
+Beispiele:
+
+```text
+Meilenstein = RoadmapItem(type = milestone)
+Reifegrad = RoadmapItem(type = maturity_stage)
+Feature = RoadmapItem(type = feature)
+Kapitel = RoadmapItem(type = chapter)
+Sprint-Grobplanung = RoadmapItem(type = work_cycle)
+```
+
+---
+
+## 6. Minimaler Standard Lifecycle
+
+Alle Methoden basieren auf einem gemeinsamen minimalen Lifecycle.
+
+```text
+intake
+method_selection
+structure_setup
+planning
+action_selection
+assignment
+waiting
+result_intake
+validation
+review
+adaptation
+closure
+```
+
+Eine Methode darf:
+
+```text
+- Schritte auslassen
+- Schritte spezialisieren
+- zusätzliche Hook Slugs ergänzen
+- eigene Structure Builder an bestimmten Schritten registrieren
+```
+
+Eine Methode darf nicht:
+
+```text
+- Tenant-Sicherheit umgehen
+- eigene Actor-Logik außerhalb des Actor-Modells einführen
+- eigene Rechteprüfung außerhalb der Capability-Schicht einführen
+- persistente Kernobjekte ohne Service-/Audit-Schicht verändern
+```
+
+---
+
+## 7. Hook Slugs
+
+Hook Slugs sind stabile Einhängepunkte.
+
+Sie sind die Hauptabstraktion, über die Methoden erweitert werden.
+
+Beispiele:
+
+```text
+on_goal_captured
+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_dod_check_required
+on_evidence_required
+on_quality_gate_required
+on_review_due
+on_reassessment_required
+on_reflection_required
+on_replan_required
+on_structure_update_required
+on_closure_requested
+```
+
+Hook Slugs müssen:
+
+```text
+- eindeutig sein
+- versionierbar bleiben
+- fachlich benannt sein
+- in Method Definitions referenziert werden
+- in Signals als Ursache auftauchen können
+- später Workflow Bindings tragen können
+```
+
+---
+
+## 8. Structure Builder
+
+Structure Builder legen die methodenspezifische Steuerungsstruktur an.
+
+Beispiele:
+
+```text
+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
+```
+
+Ein Structure Builder darf:
+
+```text
+- Roadmaps anlegen
+- RoadmapLanes anlegen
+- RoadmapItems anlegen
+- initiale BacklogItems vorschlagen oder erzeugen
+- methodenspezifische Startstruktur erzeugen
+```
+
+Ein Structure Builder darf nicht:
+
+```text
+- ungeprüft produktive Actions erzeugen, wenn ein Gate vorgesehen ist
+- Actors ohne Assignment Strategy zuweisen
+- Tenant-Kontext aus Client Input übernehmen
+- Rechteprüfung umgehen
+```
+
+---
+
+## 9. Strategies
+
+Methoden nutzen austauschbare Strategies.
+
+Wichtige Strategy Interfaces:
+
+```text
+NextActionStrategy
+AttentionRuleProvider
+AssignmentStrategy
+WaitingStrategy
+ReminderStrategy
+EscalationStrategy
+ResultIntakeStrategy
+EvidencePolicy
+ReviewStrategy
+ClosurePolicy
+```
+
+Diese Strategies sind zentrale Erweiterungspunkte.
+
+Sie verhindern, dass methodenspezifische Logik monolithisch in Services oder Data Layer wächst.
+
+---
+
+## 10. Signal Rules
+
+Signal Rules erzeugen AttentionItems und NextActionCandidates.
+
+Sie müssen erklären können:
+
+```text
+- warum ein Signal erzeugt wurde
+- welcher Hook relevant ist
+- welche Methode/Domain beteiligt ist
+- welcher Scope betroffen ist
+- welche Datenquelle genutzt wurde
+- welche nächste Handlung empfohlen wird
+```
+
+Signal Rules müssen tenant-sicher sein und dürfen nicht quer über Tenants lesen.
+
+---
+
+## 11. Method Definition Contract
+
+Eine MethodDefinition sollte mindestens enthalten:
+
+```text
+method_key
+version
+label
+description
+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
+```
+
+---
+
+## 12. Method Versioning
+
+Methoden müssen versionierbar sein.
+
+Regeln:
+
+```text
+- method_key bleibt stabil
+- version beschreibt fachliche/technische Methode
+- bestehende SteeringContexts referenzieren method_key + version
+- neue Versionen dürfen bestehende Kontexte nicht stillschweigend verändern
+- Migration oder Upgrade muss explizit sein
+```
+
+---
+
+## 13. Method Profiles
+
+Method Profiles sind spätere konkrete Konfigurationen.
+
+Sie dürfen Parameter anpassen, aber nicht den Kairo-Kern umgehen.
+
+Beispiele:
+
+```text
+maturity_progression.basic
+maturity_progression.evidence_strict
+content_chapter_based.light_review
+product_milestone_driven.release_focused
+routine_control.escalation_strict
+```
+
+Ein Method Profile darf z. B. konfigurieren:
+
+```text
+- welche Hooks aktiv sind
+- welche Review-Frequenz gilt
+- ob Evidence erforderlich ist
+- welche Reminder-Strategie gilt
+- welche Node Types erlaubt sind
+- ob Agent Steps erlaubt sind
+```
+
+Ein Method Profile darf nicht:
+
+```text
+- beliebigen Code ausführen
+- Tenant-Sicherheit umgehen
+- Capabilities außer Kraft setzen
+- systemgeschützte Hooks überschreiben
+```
+
+---
+
+## 14. Methodenbeispiele
+
+### 14.1 product_milestone_driven
+
+```text
+Domain:
+- product_development
+- project
+
+Structures:
+- Roadmap
+- Feature Lane
+- Architecture Lane
+- Release Lane
+- Backlog
+- Actions
+- Blockers
+
+Primary Hooks:
+- on_goal_captured
+- on_roadmap_required
+- on_backlog_required
+- on_next_action_requested
+- on_review_due
+```
+
+### 14.2 content_chapter_based
+
+```text
+Domain:
+- content_development
+
+Structures:
+- Roadmap
+- Chapter Lane
+- Research Lane
+- Draft Lane
+- Review Lane
+- Backlog
+- Actions
+
+Primary Hooks:
+- on_content_structure_required
+- on_next_action_requested
+- on_review_due
+```
+
+### 14.3 maturity_progression
+
+```text
+Domain:
+- maturity_development
+- personal_development
+
+Structures:
+- Roadmap
+- Maturity Stage Lane
+- Capability Lane
+- Practice Lane
+- Evidence Lane
+- Reflection Lane
+
+Primary Hooks:
+- on_maturity_path_required
+- on_evidence_required
+- on_review_due
+- on_reassessment_required
+```
+
+### 14.4 wbs_driven
+
+```text
+Domain:
+- project
+- program
+
+Structures:
+- WBS Roadmap
+- Work Package Items
+- Dependencies
+- Backlog
+- Actions
+
+Primary Hooks:
+- on_wbs_required
+- on_dependency_analysis_required
+- on_next_action_requested
+```
+
+---
+
+## 15. Designprinzipien kurz
+
+```text
+1. Methoden sind registrierte Steuerungspakete, keine Labels.
+2. Neue Methoden melden sich an einer Registry an.
+3. Alle Methoden nutzen gemeinsame Kairo-Kernstrukturen.
+4. Der Standard Lifecycle ist die gemeinsame Basis.
+5. Erweiterung erfolgt über Hook Slugs, Structure Builder und Strategies.
+6. Built-in Methods kommen vor freier Konfiguration.
+7. Profiles konfigurieren, aber ersetzen nicht den Kern.
+8. Signals müssen erklärbar und tenant-sicher sein.
+9. Agenten und LLMs sind spätere Step Provider, nicht Methoden selbst.
+10. Keine Methode darf Capabilities, TenantContext oder Actor-Modell umgehen.
+```
+
+---
+
+## 16. Konsequenz für die technische Zielarchitektur
+
+Die technische Zielarchitektur muss diese Methodendesign-Prinzipien als verbindlich übernehmen.
+
+Insbesondere muss sie definieren:
+
+```text
+- Method Registry
+- Hook Registry
+- MethodDefinition Contract
+- Standard Lifecycle
+- Structure Builder Interfaces
+- Strategy Interfaces
+- Signal Rule Provider Interfaces
+- Method Versioning
+- Method Profiles als spätere Konfigurationsebene
+```
+

docs/architecture/Kairo_Target_Architecture_Assignment_Method_Driven_Adaptive_Steering_Core_v0.2.md

@@ -0,0 +1,387 @@
+# KAIRO-ARCH-01 – Zielarchitektur für den methodengeführten adaptiven Steuerungskern
+## v0.2 – schlanker Architekturauftrag
+
+**Status:** Auftrag an Coding-/Architektur-Agent  
+**Ziel:** technische Zielarchitektur, keine Implementierung  
+**Wichtig:** Dieser Auftrag ersetzt die überdetaillierte Fassung `v0.1` als führenden Prompt.
+
+---
+
+## 1. Kontext
+
+Kairo soll langfristig keine einfache Aufgaben-, Projekt- oder Roadmap-App sein.
+
+Kairo soll eine adaptive, methodengeführte Entwicklungs- und Steuerungsplattform werden.
+
+Der bisherige Slice `Initiative → Action` ist als technischer Startpunkt gültig, aber als Zielarchitektur zu flach.
+
+Kairo soll unterschiedliche Arten von Entwicklungen steuern können, z. B.:
+
+- Software- und Produktentwicklung
+- Buchentwicklung
+- Programm- und Initiativensteuerung
+- persönliche Entwicklung
+- Reifegradentwicklung
+- Routinen / Betrieb
+- Review- und Auditkontexte
+- später auch KI-/Agenten-gestützte Steuerung
+
+---
+
+## 2. Verbindliche fachliche Grundlagen
+
+Lies zuerst:
+
+```text
+docs/architecture/Kairo_Core_Model_Decision_v0.2.md
+docs/architecture/Kairo_Method_Design_Principles_v0.1.md
+```
+
+Berücksichtige zusätzlich den bestehenden Produkt- und Architekturstand im Repo, insbesondere:
+
+```text
+docs/product/Kairo_Product_Definition_and_MVP_Reset_v0.1.md
+docs/product/Kairo_Canonical_Operating_Model_v0.1.md
+docs/product/Kairo_Corrected_MVP_Roadmap_v0.1.md
+docs/architecture/Kairo_Tenant_Invariants_v0.1.md
+docs/sprints/Sprint0_AP0_7_Completion_Report_v0.2.md
+```
+
+Falls Dokumente fehlen, liste sie im Abschlussbericht auf und arbeite mit den vorhandenen Grundlagen weiter.
+
+---
+
+## 3. Ziel dieses Auftrags
+
+Erarbeite eine technische Zielarchitektur für Kairo als:
+
+```text
+Method-driven Adaptive Steering Platform
+```
+
+Es geht ausdrücklich nicht um die nächste Implementierung, nicht um AP0.8 und nicht um MVP-Minimierung.
+
+Es geht um den technischen Nordstern:
+
+```text
+Wie muss Kairo grundsätzlich aufgebaut sein, damit unterschiedliche Steuerungsmethoden langfristig ergänzt, weiterentwickelt, konfiguriert und ausgeführt werden können, ohne den Core ständig umzubauen?
+```
+
+---
+
+## 4. Fachliche Kernanforderung
+
+Die Zielarchitektur muss erklären, wie Kairo diesen methodengeführten Steuerungsablauf unterstützt:
+
+```text
+1. Ziel / Entwicklungsabsicht erfassen
+2. Name, Scope und Kontext definieren
+3. passende Basismethode wählen oder vorschlagen
+4. gemäß Methode eine Steuerungsstruktur erzeugen
+   - z. B. Roadmap, Backlog, WBS, Reifegradpfad, Kapitelstruktur, WorkCycles
+5. Next Best Action ableiten
+6. Actor zuweisen
+   - human, agent, working_group oder external_system
+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 als methodengeführter Steuerungsworkflow zu verstehen, nicht als freie generische Automatisierungsplattform.
+
+---
+
+## 5. Kritische Leitfrage
+
+Prüfe und beantworte kritisch:
+
+```text
+Soll Kairo im Kern eine freie Workflow Engine sein,
+oder ein methodengeführter adaptiver Steuerungskern,
+an den später Workflow-Fragmente, Agenten, LLMs und Tools angebunden werden können?
+```
+
+Die fachliche Präferenz lautet:
+
+```text
+Kairo soll kein freier Workflow-Baukasten sein.
+Kairo soll einen methodengeführten Steuerungskern haben.
+Methoden sollen sich wie registrierbare Erweiterungen anmelden können.
+Hooks sind stabile Einhängepunkte.
+Workflow-Fragmente, Agenten, LLMs und Tools werden später an diese Hooks gebunden.
+```
+
+Bestätige diese Präferenz nur, wenn sie aus Sicht der bestehenden Codebase und Architektur tragfähig ist. Falls eine bessere Zielarchitektur naheliegt, beschreibe und begründe sie.
+
+---
+
+## 6. Erwartete Architekturfragen
+
+Entwickle eine Zielarchitektur zu folgenden Fragen.
+
+### 6.1 Core-Verantwortung
+
+Was ist der stabile Kairo-Core?
+
+Welche Verantwortung gehört in den Core, welche in Methoden, welche in spätere Workflow-/Agenten-/Provider-Schichten?
+
+### 6.2 Methoden-Erweiterbarkeit
+
+Wie können neue Methoden ergänzt werden, ohne den Core jedes Mal umzubauen?
+
+Berücksichtige fachlich:
+
+```text
+Method Registry
+Method Definition
+Method Versioning
+Method Profiles
+Hook Slugs
+Structure Builder
+Strategies
+Signal Rules
+```
+
+Du musst diese Begriffe nicht exakt übernehmen, wenn die bestehende Architektur eine bessere Lösung nahelegt. Wichtig ist die Fähigkeit: Methoden müssen registrierbar, versionierbar, testbar und später begrenzt konfigurierbar sein.
+
+### 6.3 Gemeinsame Kernstrukturen
+
+Welche zentralen Strukturen brauchen alle oder die meisten Methoden?
+
+Zu prüfen sind insbesondere:
+
+```text
+Steering Context
+Roadmap / Roadmap Items
+Backlog
+Actions / Assignments
+Blocker
+Signals / Attention / NextAction
+Evidence
+Reviews
+Decisions
+Waiting / Reminder / Escalation
+```
+
+Entscheide, welche davon Core-Strukturen sind und welche methodenspezifisch bleiben sollten.
+
+### 6.4 Minimaler Standard Lifecycle
+
+Prüfe, ob ein minimaler Standard Lifecycle als gemeinsame Basis sinnvoll ist.
+
+Fachlicher Vorschlag:
+
+```text
+intake
+method_selection
+structure_setup
+planning
+action_selection
+assignment
+waiting
+result_intake
+validation
+review
+adaptation
+closure
+```
+
+Bewerte:
+
+```text
+Ist dieser Lifecycle als Basismodell tragfähig?
+Welche Teile gehören in den Core?
+Welche Teile sollten Methoden überschreiben oder spezialisieren können?
+Wie lassen sich Softwareentwicklung, Buchentwicklung und Reifegradentwicklung damit abbilden?
+```
+
+### 6.5 Hooks und Steuerungsabläufe
+
+Wie sollten Hooks technisch modelliert werden?
+
+Hooks sollen stabile Einhängepunkte sein, z. B.:
+
+```text
+on_goal_captured
+on_method_selected
+on_structure_required
+on_next_action_requested
+on_assignment_required
+on_wait_started
+on_result_received
+on_evidence_required
+on_review_due
+on_replan_required
+on_closure_requested
+```
+
+Prüfe:
+
+```text
+Soll es eine Hook Registry geben?
+Wie werden Hooks versioniert?
+Wie registrieren Methoden Logik an Hooks?
+Wie werden spätere Workflow-Fragmente angebunden?
+Wie bleibt das testbar und erklärbar?
+```
+
+### 6.6 Structure Builder
+
+Methoden müssen unterschiedliche Steuerungsstrukturen erzeugen können:
+
+```text
+Roadmap / Meilensteinplan
+Backlog
+WBS
+Reifegradpfad
+Kapitelstruktur
+Feature Landscape
+WorkCycles
+Review Gates
+```
+
+Entwirf eine Architektur, wie solche Structure Builder methodenspezifisch, aber core-kompatibel eingebunden werden können.
+
+### 6.7 Signals und Next Best Action
+
+Kairo muss methodenspezifisch ableiten können:
+
+```text
+Was braucht Aufmerksamkeit?
+Was ist der nächste wirksame Schritt?
+```
+
+Beschreibe die Zielarchitektur für:
+
+```text
+Attention
+NextActionCandidates
+Signal Rules
+methodenspezifische Strategien
+Erklärbarkeit
+Ranking / Priorisierung später
+```
+
+### 6.8 Assignment, Waiting, Reminder und Escalation
+
+Der Steuerungskern darf nicht bei „Action erzeugt“ enden.
+
+Er muss abbilden können:
+
+```text
+Actor zuweisen
+auf Ergebnis warten
+Fälligkeit überwachen
+erinnern
+eskalieren
+externe Ereignisse oder Agentenergebnisse aufnehmen
+```
+
+Beschreibe, welche Architektur dafür langfristig nötig ist.
+
+### 6.9 Workflow-Fragmente und spätere Runtime
+
+Beschreibe die Rolle einer späteren technischen Workflow Runtime.
+
+Wichtig:
+
+```text
+Die Runtime soll methodengeführte Steuerungsabläufe unterstützen.
+Sie soll nicht als beliebiger freier Workflow-Baukasten den Kairo-Core ersetzen.
+```
+
+Kläre:
+
+```text
+Was ist Core-Logik?
+Was ist Methode?
+Was ist Hook?
+Was ist Workflow-Fragment?
+Was ist spätere Runtime?
+Wie werden LLM-/Agent-/Tool-Steps angebunden?
+```
+
+### 6.10 Agenten, LLMs und Tools
+
+Kairo soll später Agenten, LLMs und Tools nutzen können.
+
+Kläre:
+
+```text
+Bleibt Kairo Steering Authority?
+Sind Agenten Provider oder eigenständige Steuerungsinstanzen?
+Wie werden Agenten als Actors eingebunden?
+Wie werden Ergebnisse zurückgeführt?
+Wie werden Freigaben, Audit und Fehler behandelt?
+```
+
+---
+
+## 7. Erwartetes Ergebnis
+
+Erstelle ein Architektur-Dokument:
+
+```text
+docs/architecture/Kairo_Target_Architecture_Method_Driven_Adaptive_Steering_Core_v0.1.md
+```
+
+Das Dokument soll eine konsistente Zielarchitektur darstellen, keine bloße Checkliste.
+
+Es soll mindestens enthalten:
+
+```markdown
+# Kairo Target Architecture – Method-driven Adaptive Steering Core v0.1
+
+## 1. Executive Summary
+## 2. Fachliches Zielbild
+## 3. Bewertung: Workflow Engine vs. methodengeführter Steuerungskern
+## 4. Zielarchitektur im Überblick
+## 5. Core-Verantwortung und Abgrenzung
+## 6. Methodenarchitektur und Erweiterbarkeit
+## 7. Standard Lifecycle und Hooks
+## 8. Structure Builder
+## 9. Gemeinsame Kernstrukturen
+## 10. Roadmap, Backlog, Action und Blocker
+## 11. Signals, Attention und Next Best Action
+## 12. Assignment, Waiting, Reminder und Escalation
+## 13. Workflow-Fragmente und spätere Runtime
+## 14. Agenten-, LLM- und Tool-Integration
+## 15. Datenmodell-Zielbild
+## 16. Modul-/Schichten-Zielbild
+## 17. Security, Tenant, Actor, Governance und Audit
+## 18. Architekturentscheidungen
+## 19. Risiken und offene Fragen
+## 20. Empfohlene nächste Schritte
+```
+
+---
+
+## 8. Abschlussbericht
+
+Liefere zusätzlich einen Abschlussbericht:
+
+```markdown
+# KAIRO-ARCH-01 – Abschlussbericht
+
+## 1. Erstellte Dateien
+## 2. Wichtigste Architekturentscheidungen
+## 3. Kritische Bewertung der fachlichen Annahmen
+## 4. Empfohlene Zielarchitektur
+## 5. Was gegenüber der bisherigen Architektur geändert werden sollte
+## 6. Risiken
+## 7. Offene Entscheidungen
+## 8. Empfehlung für den nächsten Schritt
+```
+
+---
+
+## 9. Arbeitsregel
+
+Nicht vorschnell implementierungsnah werden.
+
+Nutze deine Kenntnis der bestehenden Codebase und Architektur.
+
+Wenn die fachlichen Vorgaben mit der bestehenden technischen Architektur kollidieren, benenne das ausdrücklich und schlage eine bessere Lösung vor.
+
+Es geht um eine tragfähige Zielarchitektur, nicht um das Abarbeiten einer überdetaillierten Vorgabenliste.