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

Jinkendo Kairo

Universeller Steuerungsmethoden-Kern v0.1

Status: PO-freigegeben (Freeze M1c) — 2026-07-25
Zweck: Fachlich universeller Kern für alle Steuerungsmethoden
Nicht: Archetyp-Katalog (→ Decision-Lock) · keine offene Workflow-Engine
Voraussetzung Technik: AP2.3/AP2.4 Plugin-Architektur
Abgeleitet aus: Spec-Tiefe D (docs/architecture/methods/SPEC_D_*.md), Fit-Analyse, Target Architecture Lifecycle

---

1. Was dieser Kern ist

Der Steuerungsmethoden-Kern ist die eine gemeinsame Maschine, mit der Kairo jedes Vorhaben steuert — unabhängig von der Methode.

Methoden sind Steuerungspakete: sie füllen feste Schlitze (Strategien, Policies, Skip-Regeln).
Sie bauen keine zweite Engine daneben.

SteeringContext (Vorhaben + gebundene primary-Methode [+ Komposition])
        │
        ▼
┌─────────────────────────────────────────────────────────┐
│         UNIVERSALER STEUERUNGSMETHODEN-KERN             │
│                                                         │
│   Auslöser:  Plan-Zug  und/oder  Event-Schub            │
│   Schlitze:  Intake … Closure (unten)                   │
│   Querschnitt: Horizont · Attention · Audit · Nested    │
└─────────────────────────────────────────────────────────┘
        │
        ▼
   Method Plugin (sequential_dependency, care_navigation, …)

Leitfrage (unverändert):
Welcher nächste Schritt bringt das Vorhaben jetzt am wirkungsvollsten voran — und warum?

---

2. Explizit nicht

Nicht	Stattdessen
Offene Workflow-/Plugin-Engine (beliebige Nodes)	Feste Schlitze + Method Registry
Eine Engine pro Vorhaben-Typ	Ein Kern, Methoden spezialisieren
Nur Plan-Pipeline ohne Events	Dualer Auslöser
Nur Action als „nächste Arbeit“	Polymorphes Work Item
Programm überschreibt Child-NA	Nested: Impulse ≠ Child-NA

PO ✓ 2026-07-25: Dual-Auslöser; keine offene Engine.

---

3. Duale Auslöser (PO ✓)

Auslöser	Bedeutung	Typisch
Plan-Zug	Horizont/Plan fragt: was ist ready?	A2, B2a, B2b, Checklisten (dünn), Agile-Slice
Event-Schub	Etwas passiert → Reaktion/Arbeit öffnen oder ändern	C1, Care-Reaktionen, Cadence-Zeitpunkte (A3/A1)

Beide münden in dieselben Schlitze (Next work, Result, DoD, Adaptation, Attention).

Jede Methode deklariert eine Dominanz:

Dominanz	Bedeutung
plan	Planung/Horizont führt
event	Ereignisse führen
hybrid	beides wesentlich (z. B. Care)

---

4. Universelle Schlitze (Lifecycle als Schleife)

Der Kern orchestriert immer dieselbe Schrittliste.
Methode setzt pro Schritt: active | skip | n/a (+ Lieferant für den Schlitz).

#	Schlitz	Kern tut immer	Methode liefert
1	Intake	Kontext/Ziel/Scope absichern	zusätzliche Aufnahme
2	Method bind	Methode binden, Kompatibilität zu Archetyp	Default/Wechselregeln
3	Structure setup	Builder/Struktur-Hooks aufrufen	welche Struktur
4	Planning	Planungsphase ermöglichen	was geplant wird — oder n/a
5	Next work	Strategie aufrufen, Kandidaten + Begründung	Ready-Logik, Ranking, Leading-Typ
6	Assignment	Actor-Zuweisung über Services	Assignment-Policy
7	Waiting	Wartezustand führen	Reminder/Eskalation
8	Result / Event	Rückmeldung und externe/situative Events annehmen	Interpretation
9	DoD / Validation	Prüfung gegen Kriterien/Evidence anstoßen	Criteria-/Evidence-Policy — oder n/a
10	Review	Review/Entscheidungspfad	wann Pflicht
11	Adaptation	Nachsteuern/Replan-Hooks	was sich ändert
12	Closure	Abschluss-Policy aufrufbar	ob Closure vorgesehen

Schleife: Nach Adaptation (und oft nach Result) wieder Next work / Planning — kein Zwang zum Closure.
Intake kann erneut feuern (dauerhafter Eingang).

---

5. Querschnittsfähigkeiten (Anker — Teil des Kerns)

Damit Plan- und Event-Methoden dieselbe Maschine nutzen:

#	Fähigkeit	Pflicht
Q1	Horizont auflösen („worauf schauen wir?“)	ja
Q2	Work-Item-Polymorphie (Action, CadenceInstance, ChecklistItem, Decision, ProgramImpulse, …)	ja
Q3	Event-Eingang gleichberechtigt zu Actor-Result	ja
Q4	Nested Contexts (Parent-Impulse ≠ Child-Next-Work)	ja wenn Kinder existieren
Q5	Attention-Orchestrierung	ja
Q6	Formale Schritt-Status active/skip/n/a	ja
Q7	Kompositions-Methoden (z. B. Agile): eigener Horizont-Slice, Primary bleibt Natur	ja

---

6. Methodentypen (verbindlich)

Jede Methode hat genau eine fachliche Rolle. Technik-Feld AP2.4: method_role.

Methodentyp	method_role	Bedeutung	Beispiele
Primary (Ausführung)	primary	Trägt Vorhaben-Natur: Horizon, Leading Work, Closure-Haltung, Ready/Ranking	sequential_dependency, continuous_product, recurring_control, maturity_progression, checklist_flow, care_navigation, dispute_procedure, generic_operating
Primary (Meta)	primary	Primary, aber kein Ausführungs-Leading der Kinder: Impulse, Nested, Lagebild	program_delivery (nur B2a)
Komposition	modifier	Horizont-/Takt-Slice; braucht Primary; ersetzt Natur nicht	agile_iteration

Regeln:

1. Pro Vorhaben genau eine Primary-Methode (Ausführung oder Meta).
2. Komposition nur wenn Primary in composes_with der Kompositions-Methode steht.
3. Meta-Primary (program_delivery) komponiert nicht mit Agile am Dach; Agile nur an Kind-Primaries.
4. „Kompatible Methoden“ eines Archetyps = erlaubte Primary plus erlaubte Kompositionen — kein wilder Primary-Wechsel ohne Archetyp-Passung.

---

7. Method Plugin — was jede Methode am Kern anmeldet

Mindestens:

Anmeldung	Inhalt
Methodentyp / method_role	primary | modifier (+ Meta nur fachlich bei program_delivery)
Dominanz	plan | event | hybrid
Lifecycle-Map	Status je Schlitz
Next-work-Strategie	Leading-Typ + Ready + Ranking + reason_codes
Attention-Regeln	Codes + Auslöser
Horizont-Definition	was Horizont ist
DoD-Policy	oder explizit n/a
compatible_archetype_keys + data_slices	AP2.4
steering_elements	UI-Bausteine
Komposition	bei Primary: ob komponierbar; bei modifier: composes_with

Details: jeweilige SPEC_D_<method>.md.

---

8. Komposition Agile (PO ✓)

agile_iteration = Kompositions-/Horizont-Methode mit eigener Sprint-Planungs- und Lifecycle-Logik.
Technisch modifier. Ersetzt Primary nicht. Genau ein aktiver Sprint. Ohne Sprint → nur Primary.
composes_with: sequential_dependency, continuous_product, recurring_control — nicht program_delivery.

---

9. Abbildung Dominanz (aus Spec-D)

Methode	Dominanz
sequential_dependency	plan
program_delivery	plan (+ Signale aus Kindern)
continuous_product	plan (hybrid-light bei Incidents)
checklist_flow	plan (sehr dünn)
maturity_progression	hybrid (Cadence-Zeit + Stufe)
recurring_control	event (Cadence)
care_navigation	hybrid
dispute_procedure	event
agile_iteration	plan-Slice (Komposition; mit sequential, continuous_product, recurring_control)
generic_operating	plan (dünn)

---

10. Beziehung zu Archetypen und Templates

Schicht	Rolle
Archetyp	Natur, Horizont-Erwartung, OM-Fähigkeiten, UI-Hülle, Default-Methode
Vorhaben-Template	konkrete Vorlage auf einem Archetyp (Zusatzfelder, Darstellung, Sortierung/Filter, ggf. Profil) — kein neuer Archetyp (PO 2026-07-25)
dieser Kern	universelle Steuerungs-Maschine
Methode	Plugin in den Kern
Operating Context	Laufzeit-Auflösung (AP2.3/AP2.4)

UI-Namen und Template-Darstellung sind nachrangig gegenüber Archetyp-Merkmalen + Methodensteuerung.

---

11. Freigabe-Log

Datum	Entscheidung
2026-07-25	Hybrid A1 Spec-D → Kern
2026-07-25	Dual-Auslöser; keine offene Workflow-Engine
2026-07-25	Schlitze 1–12 + Querschnitt Q1–Q7 = Methodenkern v0.1 Freeze
2026-07-25	Batch-Methoden Spec-D als Delta zum Kern akzeptiert (inhaltlich Decision-Lock; explizit mit Freeze)
2026-07-25	Methodentypen: Primary (Ausführung) / Primary (Meta) / Komposition; Agile + A3; nicht am Programm-Dach
2026-07-26	PO: Architektur beibehalten (schlank: Default-Primary + wenige Kompositionen); Vollspec-/Spec-D-Welle freigegeben

---

12. Nächste Arbeit (nach Freeze)

1. Spec-D Dominanz-Feld + Schlitz-Maps gegen dieses Dokument normalisieren (redaktionell)
2. Ist-Code-Lücken (v. a. program_delivery Nested/Impulse) als Implementierungs-Schuld listen
3. Archetyp-Vollspecs / Catalog v0.3 auf diesem Kern aufsetzen
4. Kein neuer Methoden-Code außerhalb Open/Closed Registry

---

Freeze-Dokument. Bei Änderung: Version v0.2 + PO-Entscheid.