148 lines
6.0 KiB
Markdown
148 lines
6.0 KiB
Markdown
|
# 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.*
|