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

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

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

• Reihenfolge: Decision-Lock Archetypen → Methoden-Normierung → Archetyp-Vollspec
• AP2.3/AP2.4 als Voraussetzung anerkannt
• Phase M1 gestartet (2026-07-25)
• Methodenkern v0.1 Freeze (2026-07-25)
• 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.