# Jinkendo Kairo
## Steuerungsmethoden-Normierungsprogramm v0.1

**Status:** aktiv — nächste fachliche Designphase nach Archetyp-Decision-Lock  
**Stand:** 2026-07-25  
**Voraussetzung (geliefert):** AP2.3 Plugin-Architektur, AP2.4 Method Contract & Steuerungselemente  
**Decision-Lock Archetypen:** `docs/product/Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`  
**Ersetzt nicht:** `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md` (technischer Vertrag)

---

## 1. Ziel

Ein **kanonisches, normalisiertes Steuerungsmethoden-Modell**, auf dem:

1. alle Methoden denselben **Verhaltensvertrag** erfüllen (nicht nur Registry-Felder),
2. Archetypen **kompatible** Methoden binden können, ohne Steuerungslogik zu duplizieren,
3. neue Methoden (**`checklist_flow`**, **`care_navigation`**, …) und bestehende Stubs auf **gemeinsamen Primitiven** aufsetzen,
4. Archetyp-Vollspecs (Felder, Basiserfassung, GUI) erst danach stabil geschrieben werden.

**Leitfrage:** Welche Voraussetzungen muss jede Methode an OM + Core stellen — und welche Signale liefert sie verlässlich zurück?

---

## 2. Ausgangslage

| Schicht | Stand |
|---------|--------|
| Plugin-Auflösung / Operating Context | ✓ AP2.3 |
| `MethodDefinition` + `steering_elements` + Kompatibilität | ✓ AP2.4 technisch |
| Fachliche Primitive (einheitliche Semantik) | ○ Lücke |
| Strategien teils Stub / inkonsistente Voraussetzungen | ◐ |
| Decision-Lock Archetypen (8 Typen) | ✓ Inventar |
| Archetyp-Vollspecs | ⏸ warten auf Normierung |

**These (PO):** Die größte Hürde liegt in den Methoden. Archetypen werden ggf. an den Methodenkern **angepasst**, nicht umgekehrt Feature-Specs vorgezogen.

---

## 3. Normierungsgegenstand

### 3.1 Method Contract — fachliche Ebene (über AP2.4 hinaus)

Jede **primary**-Methode muss spezifizieren:

| # | Vertragspunkt | Inhalt |
|---|---------------|--------|
| 1 | **Horizon** | Was ist der Steuerungs-Horizont? (Stufe, Gate, Sprint, Cadence, Checklisten-Scope, Fall, Fürsorge-Fokus) |
| 2 | **Leading object** | Worauf zeigt Next Action primär? |
| 3 | **OM-Voraussetzungen** | Minimale Slices/Objekte, ohne die die Methode nicht starten darf |
| 4 | **Next Action** | Eingaben, Ranking, `reason_codes`, leerer Fall |
| 5 | **Attention** | wann / welche Codes |
| 6 | **steering_elements** | Keys aus Element-Registry |
| 7 | **ui_features / graph_profile** | Verhaltensflags |
| 8 | **Lifecycle-Bezug** | Closure erwartet? Adaptation? |
| 9 | **compatible_archetype_keys** | explizit, konsistent zu Decision-Lock |
| 10 | **modifier-Komposition** | z. B. mit `agile_iteration` |

### 3.2 Gemeinsame Primitive (kanonisch zu definieren)

Arbeitsliste — im Interview/Spec zu schärfen:

| Primitive | Nutzen |
|-----------|--------|
| `ReadyWorkItem` | einheitliche „kann jetzt gearbeitet werden“-Sicht |
| `HorizonMarker` | Gate / Stage / Sprint / Milestone / Care-Checkpoint |
| `CadenceInstance` | eine offene Rhythmus-Instanz (Anti-Duplikat) |
| `ChecklistItem` | abhakbares Listenitem (B1) |
| `CrossDependencySignal` | Programm-Roadblocker über Kinder (B2a) |
| `CareFocus` | Person im Fürsorgefokus + offener Bedarf |
| `AttentionSignal` | portfoliotaugliches Attention-Objekt |

Primitive sind **Read-Model-/Vertragsbegriffe** — keine neuen OM-Tabellen ohne ADP.

### 3.3 Methoden-Inventar (Ziel nach Decision-Lock)

| `method_key` | Rolle | Status fachlich |
|--------------|-------|-----------------|
| `maturity_progression` | primary | ◐ vorhanden, normieren |
| `sequential_dependency` | primary | ◐ |
| `recurring_control` | primary | ◐ Stub → Norm |
| `checklist_flow` | primary | ✗ neu (ersetzt Label `queue_pull`) |
| `program_delivery` | primary | ◐ |
| `continuous_product` | primary | ◐ |
| `dispute_procedure` | primary | ◐ Stub |
| `care_navigation` | primary | ✗ neu |
| `agile_iteration` | **modifier** | ◐ Komposition härten |
| `generic_operating` | primary Fallback | ✓ |
| `chapter_based_progression` | Profil/Strategie unter A2 | kein eigener Archetyp mehr |
| `product_milestone_driven` | Legacy | migrieren / kompatibel halten |

---

## 4. Arbeitsmodus

```text
Phase M0  Guardrails lesen (AP2.3/AP2.4 + dieses Programm)     ✓
Phase M1  Hybrid A1 (PO 2026-07-25)                              ✓
          M1a–b Spec-D Methoden
          M1c Methodenkern Freeze                                 ✓
              → Kairo_Steering_Method_Kernel_v0.1.md
              Dual-Auslöser Plan|Event; keine offene Workflow-Engine
Phase M2  Kompatibilität + Code-Schuld                                 ✓
          → M2_Method_Compatibility_and_Code_Debt_v0.1.md
Phase M3  Archetyp-Vollspecs (implementierbar)
          → docs/product/archetypes/VOLLSPEC_PROGRAM_v0.1.md
Phase M4  Catalog v0.3
Phase M5  Code-APs nur Open/Closed gegen Registry + Kernel-Schlitze
```

**Stop-Regel:** Keine parallele Steuerungsengine. Neue Methoden nur als Plugin in Kernel-Schlitze.

---

## 5. Abgrenzung

| Tun | Nicht tun |
|-----|-----------|
| Primitive und Voraussetzungen normalisieren | Tenant-Methoden-Designer |
| `queue_pull` → `checklist_flow` fachlich | Beliebige Workflow-Engine |
| Care-Methode spezifizieren | Mitai/Shinkan-Gesundheitsdomäne |
| Kompatibilität Decision-Lock ↔ Registry | Page-Ifs / parallele Heuristiken |

---

## 6. Phase M1 — Einstieg (reframed)

**Nicht:** Spec-Formular zuerst.  
**Sondern:** Methodenkern aus Target Architecture + Method Design Principles verbindlich machen, AP2.4 als technische Abbildung.

Living Doc: `Kairo_Steering_Method_Contract_Fachlich_v0.1.md`

---

## 7. PO-Freigabe

- [x] Reihenfolge: Decision-Lock Archetypen → Methoden-Normierung → Archetyp-Vollspec  
- [x] AP2.3/AP2.4 als Voraussetzung anerkannt  
- [x] Phase M1 gestartet (2026-07-25)
- [x] Methodenkern v0.1 Freeze (2026-07-25)
- [x] M2 Kompatibilität + Code-Schuld (2026-07-25)
- [ ] Archetyp-Vollspecs (Welle A2 → …)
- [ ] Dominanz redaktionell in Spec-D-Dateien (P2)  

---

*Erstellt 2026-07-25 im Anschluss an das Archetyp-Interview und die Plugin-/Guardrail-Arbeit.*