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

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