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

ADP — Steering Kernel Spine v0.1

Status: PO-freigegeben — Implementierung aktiv (2026-07-26)
Stand: 2026-07-26
Bezug: Kairo_Steering_Method_Kernel_v0.1.md, ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md, Normierungsprogramm M5
Ersetzt nicht: AP2.3/AP2.4 Plugin-Schicht — setzt darauf auf

---

1. Problem

Steuerungslogik (Next Action, Attention, Horizont) entsteht heute verstreut in Strategies, signals/engine.py und Snapshot-Hilfsregeln. Es gibt keinen zentralen Runtime-Einstieg — Produkt wirkt unführbar, Spec-Kern (M1c) ist nicht im Code.

PO-Entscheidung: Erst Herzmaschine (Kernel Spine), dann Archetyp-Slices und UI.

---

2. Scope Lock — Spine v0.1 (schmal)

In Scope

#	Lieferung
K1	backend/steering/kernel/ — einziger Einstieg evaluate_steering() pro Vorhaben
K2	SteeringBinding — Primary-Methode + optional Composition (agile_iteration)
K3	HorizonMarker — aktives Gate / aktiver Sprint
K4	next_work + attention — nur über Spine; Snapshot/API für Initiative
K5	Event-Ingress Stub apply_steering_event() (Plan-Methoden: no-op)
K6	Referenz-Abnahme: A2 + sequential_dependency (+ Agile-Komposition)

Out of Scope (v0.1)

• Voller 12-Schritt-Lifecycle-Orchestrator als Schleife
• Nested Programm-Impulse (B2a P0)
• Event-Methoden C1/Care voll
• Neue OM-Tabellen
• Frontend-Umbau (nutzt bestehende Snapshot-Felder)

---

3. Architektur

GET …/steering-snapshot  ─┐
data_layer/attention     ─┼─► steering.kernel.evaluate_steering()
signals/engine (init.)   ─┘           │
                                        ├─ resolve_binding (primary + modifier)
                                        ├─ resolve_horizon
                                        ├─ next_work (Strategy via binding)
                                        └─ attention (method-aware, horizon-scoped)

Stop-the-line: Keine neue Steuerungsheuristik außerhalb backend/steering/kernel/ und registrierten Method-Strategies, die nur vom Kernel aufgerufen werden.

---

4. Abnahme (DoD)

1. A2 Happy Path Spec §9: Next im Gate-Horizont, blockiert → Attention, kein Fake-Next
2. Agile: Primary ohne Sprint; Sprint aktiv → work_cycle_ready ∩ Horizont
3. pytest test_ap_kernel_spine.py + test_ap22c_* grün
4. Kein Initiative-Snapshot-Pfad umgeht evaluate_steering()

---

5. Migration

Alt	Neu
signals/engine.evaluate(..., initiative_id=…)	delegiert an Kernel
Composition-If in engine._resolve_next_action_strategy_key	kernel/binding.py
Horizont in einzelnen Strategies	kernel/horizon.py + Strategies konsumieren Scope

Strategies bleiben Plugin-Lieferanten — werden nicht dupliziert, aber nur über Kernel geroutet.

---

6. Nächste Phasen (nach Spine ✓)

1. Zweite Methode durch dieselbe Spine (continuous_product)
2. checklist_flow, care_navigation als Plugins
3. Event-Ingress für hybrid/event-Methoden
4. Lifecycle-Schleife schrittweise (nicht Big Bang)

Phase v0.1.1 (2026-07-26) ✓

• slot_map in MethodDefinition (Spec-D D5) für sequential_dependency, generic_operating
• evaluate_steering() liefert lifecycle: current_state, slot_map, active_slots
• Snapshot-Feld steering_kernel.lifecycle

Phase v0.2 (2026-07-26) — Scope Lock

#	Lieferung
V1	Event-Ingress: Action done, Gate verify/reopen, Blocker resolve → apply_steering_event()
V2	Lifecycle-Kette methodenaware via slot_map + minimale Slot-Provider
V3	continuous_product mit slot_map durch dieselbe Spine
V4	pytest test_ap_kernel_spine_v02.py

Out of Scope v0.2: Voller 12-Schritt-Orchestrator-Loop pro Snapshot; C1/Care event-voll; Frontend.

---

Bei Erweiterung: v0.3 weitere Methoden + Event-Methoden — PO-Freigabe.