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