Kairo-Jinkendo/docs/architecture/ADP_Steering_Kernel_Spine_v0.1.md
Lars 75a6a63665
Some checks failed
Deploy Development / deploy (push) Successful in 48s
Test Suite / pytest-backend (push) Failing after 3m33s
Test Suite / k6 /api/health Baseline (push) Has been skipped
Test Suite / playwright-smoke (push) Has been skipped
Test Suite / lint-backend (push) Successful in 2s
Test Suite / compose-smoke (push) Has been skipped
feat(steering): Kernel Spine v0.1.1 als zentraler Initiative-Einstieg
evaluate_steering() vereinheitlicht Horizon, Next Work und Attention; Snapshot und Signal Engine delegieren dorthin; slot_map deklarativ fuer sequential_dependency und generic_operating.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-26 16:08:58 +02:00

3.4 KiB

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

Bei Erweiterung: v0.2 Event-Pfad + Slot-Provider — v0.2 + PO-Freigabe.