backend/tests/test_ap22c_maturity_e2e.py

@@ -1,179 +0,0 @@
-"""AP2.2c — A1 maturity journey End-to-End (Spagat Happy Path)."""
-
-from __future__ import annotations
-
-from tests.factories import provision_user_in_tenant
-from tests.test_initiatives_actions import _auth, _create_initiative, _login
-
-_STAGE1 = "Stufe 1 — Basis"
-_STARTER_RECURRING = "Tägliche Übung"
-
-
-def _create_spagat(client, token):
-    created = _create_initiative(
-        client,
-        token,
-        title="Spagat können",
-        archetype_key="initiative.maturity_journey",
-    )
-    assert created.status_code == 201
-    body = created.json()
-    assert body["starter_kit"]["applied"] is True
-    return body["id"]
-
-
-def test_a1_starter_kit_spagat_structure(client):
-    """Starter-Kit: Stufen, Training-Project, tägliche Übung, Operating Context."""
-    user = provision_user_in_tenant(tenant_role="admin")
-    token = _login(client, user)
-    initiative_id = _create_spagat(client, token)
-
-    ctx = client.get(
-        f"/api/initiatives/{initiative_id}/operating-context",
-        headers=_auth(token),
-    )
-    assert ctx.status_code == 200
-    body = ctx.json()
-    assert body["method_key"] == "maturity_progression"
-    assert "maturity_stage" in body["steering_elements"]
-    assert "recurring_rhythm" in body["steering_elements"]
-    assert body["ui_profile"]["controlDefaultRoute"] == "/control/status"
-
-    roadmap = client.get(
-        f"/api/initiatives/{initiative_id}/roadmap/items",
-        headers=_auth(token),
-    )
-    assert roadmap.status_code == 200
-    stages = [i for i in roadmap.json() if i.get("item_type") == "maturity_stage"]
-    assert len(stages) == 3
-    assert sum(1 for s in stages if s["status"] == "active") == 1
-    assert any(s["title"] == _STAGE1 and s["status"] == "active" for s in stages)
-
-    recurring = client.get(
-        f"/api/initiatives/{initiative_id}/recurring",
-        headers=_auth(token),
-    )
-    assert recurring.status_code == 200
-    assert any(r["title"] == _STARTER_RECURRING and r["status"] == "active" for r in recurring.json())
-
-    projects = client.get(
-        f"/api/initiatives/{initiative_id}/projects",
-        headers=_auth(token),
-    )
-    assert projects.status_code == 200
-    assert any(p["title"] == "Training" for p in projects.json())
-
-    snap = client.get(
-        f"/api/initiatives/{initiative_id}/steering-snapshot",
-        headers=_auth(token),
-    )
-    assert snap.status_code == 200
-    snap_body = snap.json()
-    assert snap_body["steering_kernel"]["primary_method_key"] == "maturity_progression"
-    assert snap_body.get("steering_guidance")
-    next_actions = snap_body.get("next_actions") or []
-    assert next_actions
-    top = next_actions[0]
-    assert top.get("kind") in ("recurring_due", "action", "review_milestone")
-    if top.get("kind") == "recurring_due":
-        assert top.get("reason_code") == "recurring_due"
-
-
-def test_a1_stage_verify_rotates_recurring_and_next_action(client):
-    """AP2.0e: Stufe 1 reached → alte Übung pausiert, Stufe 2 aktiv, neue Routine."""
-    user = provision_user_in_tenant(tenant_role="admin")
-    token = _login(client, user)
-    initiative_id = _create_spagat(client, token)
-
-    items = client.get(
-        f"/api/initiatives/{initiative_id}/roadmap/items",
-        headers=_auth(token),
-    ).json()
-    stage1 = next(i for i in items if i["title"] == _STAGE1)
-
-    snap_before = client.get(
-        f"/api/initiatives/{initiative_id}/steering-snapshot",
-        headers=_auth(token),
-    )
-    assert snap_before.status_code == 200
-
-    client.post(
-        f"/api/initiatives/{initiative_id}/evidence",
-        json={
-            "title": "Stufe 1 geschafft",
-            "roadmap_item_id": stage1["id"],
-            "status": "accepted",
-        },
-        headers=_auth(token),
-    )
-
-    verify = client.post(
-        f"/api/roadmap-items/{stage1['id']}/verify-reached",
-        headers=_auth(token),
-    )
-    assert verify.status_code == 200
-    body = verify.json()
-    assert body["status"] == "reached"
-    transition = body.get("maturity_transition") or {}
-    assert transition.get("new_recurring_id")
-
-    recurring = client.get(
-        f"/api/initiatives/{initiative_id}/recurring",
-        headers=_auth(token),
-    ).json()
-    titles = {r["title"]: r["status"] for r in recurring}
-    assert titles.get(_STARTER_RECURRING) == "paused"
-    assert any(t.startswith("Übung — Stufe 2") and titles[t] == "active" for t in titles)
-
-    items_after = client.get(
-        f"/api/initiatives/{initiative_id}/roadmap/items",
-        headers=_auth(token),
-    ).json()
-    stage2 = next(i for i in items_after if i["title"] == "Stufe 2 — Aufbau")
-    assert stage2["status"] == "active"
-
-    snap_after = client.get(
-        f"/api/initiatives/{initiative_id}/steering-snapshot",
-        headers=_auth(token),
-    )
-    assert snap_after.status_code == 200
-    next_after = snap_after.json().get("next_actions") or []
-    assert next_after
-    assert next_after[0].get("kind") == "recurring_due" or next_after[0].get("title", "").startswith(
-        "Übung —"
-    )
-
-
-def test_a1_journey_lists_stage_reached_event(client):
-    """Journey enthält nach Verify mindestens ein Ereignis."""
-    user = provision_user_in_tenant(tenant_role="admin")
-    token = _login(client, user)
-    initiative_id = _create_spagat(client, token)
-
-    items = client.get(
-        f"/api/initiatives/{initiative_id}/roadmap/items",
-        headers=_auth(token),
-    ).json()
-    stage1 = next(i for i in items if i["title"] == _STAGE1)
-
-    client.post(
-        f"/api/initiatives/{initiative_id}/evidence",
-        json={
-            "title": "Nachweis Stufe 1",
-            "roadmap_item_id": stage1["id"],
-            "status": "accepted",
-        },
-        headers=_auth(token),
-    )
-    client.post(
-        f"/api/roadmap-items/{stage1['id']}/verify-reached",
-        headers=_auth(token),
-    )
-
-    journey = client.get(
-        f"/api/initiatives/{initiative_id}/journey",
-        headers=_auth(token),
-    )
-    assert journey.status_code == 200
-    events = journey.json().get("events") or []
-    assert len(events) >= 1

docs/architecture/ADP_Template_Blueprint_Scope_Lock_v0.1.md

@@ -1,77 +0,0 @@
-# ADP — Template / Blueprint Scope Lock v0.1
-
-**Status:** Entwurf — gilt ab PO-Freigabe von `ADP_Vorhaben_Template_Blueprint_v0.1.md`  
-**Stand:** 2026-07-27  
-**Bezug:** `ADP_Vorhaben_Template_Blueprint_v0.1.md` §13, `ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`, `Kairo_MVP_Definition_v0.3.md` §3
-
----
-
-## Geltungsbereich
-
-Dieses Scope Lock gilt für **alle Implementierungs-APs AP-BP-1 bis AP-BP-5**. AP-BP-6 (Designer) erfordert eigenes Scope-Lock-Update.
-
----
-
-## Phase 1 (BP-1 … BP-4) — explizit **nicht** bauen
-
-| # | Verboten | Begründung |
-|---|----------|------------|
-| SL-1 | **Blueprint-Designer** (visueller Editor, Drag-Drop) | BP-6; Over-Engineering |
-| SL-2 | **YAML/JSON-Import** für Tenant-Blueprints | BP-6 |
-| SL-3 | **Produktive KI/Prompt-Ausführung** aus Blueprint-Bindings | AP2.1 Freeze; SK-13 |
-| SL-4 | **Agent-Ranker** (`agent_v1`) aktiviert durch Template | BP-5 nach AP2.1 Go |
-| SL-5 | **MCP / Workflow-Fragmente** an Blueprint gebunden | Schicht 4 eingefroren |
-| SL-6 | **Neue steering_elements** durch Blueprint-Aktivierung | Nur Method Registry |
-| SL-7 | **method_key- oder archetype_key-Override** via Blueprint | Natur bleibt Archetyp |
-| SL-8 | **Neue OM-Tabellen** pro Blueprint-Typ | Scope Lock OM |
-| SL-9 | **Steuerungslogik** in Blueprint-Resolver, Routern, React-Pages | SK-01, SK-03 |
-| SL-10 | **Archetyp-Ifs** (`blueprint_key === '…'`) in Pages | Composition + Context |
-| SL-11 | **Auto-Upgrade** materialisierter Struktur bei Blueprint-Version | O-5 offen; v1 verboten |
-| SL-12 | **Tenant-Custom-Field-Schema** im Blueprint erfinden | EFS-ADP Phase 2 |
-| SL-13 | **User-Scope Blueprints** (`scope_type=user`) | BP-6 Kandidat |
-| SL-14 | **Vollständiger Structure Builder** getriggert durch Blueprint | Deferred MVP |
-| SL-15 | **Projekt-Blueprints** (`entity_type=project`) | AP1.10 Phase 2 |
-| SL-16 | **Neue Composition-Provider-Kinds** ohne ADP UX Composition | Open/Closed FE |
-| SL-17 | **Portfolio-weite** Blueprint-Copy (Cockpit) | Initiative-scoped only |
-| SL-18 | **Hardcodierter Prompt-Text** in `bindings_json` | Prompt-Registry only |
-
----
-
-## Phase 1 — **erlaubt** (nach ADP-Freigabe)
-
-| # | Erlaubt | Phase |
-|---|---------|-------|
-| E-1 | Tabelle `blueprints` + System-Seed-Migration aus `method_profiles/registry.py` | BP-1 |
-| E-2 | `GET /api/blueprints` list/get; Alias `method-profiles` | BP-1 |
-| E-3 | Operating Context: `blueprint_key`, `blueprint_bindings` (read-only slice) | BP-1 |
-| E-4 | Anlage-Dialog: Blueprint wählen | BP-2 |
-| E-5 | `apply_starter_kit` liest `starter_kit` aus Blueprint | BP-2 |
-| E-6 | EFS `field_defaults` bei Anlage | BP-2 |
-| E-7 | Tenant-Fork System-Blueprint → `scope_type=tenant`, `status=draft` | BP-3 |
-| E-8 | PATCH Tenant-Blueprint (Presets, Copy) mit Capability-Gate | BP-3 |
-| E-9 | Merge Copy in `resolveSteeringComposition` + `PROPOSAL_UI_CONFIG` | BP-4 |
-| E-10 | Backlog-Vocabulary-Override aus Blueprint | BP-4 |
-| E-11 | `prompt_refs` **speichern** und in API exposieren (ohne Ausführung) | BP-4 |
-
----
-
-## Abhängigkeiten — nicht vorher starten
-
-| AP | Blocker |
-|----|---------|
-| BP-2 (Materialisierung) | AP2.2a Starter-Kit-Pipeline stabil |
-| BP-4 (Composition) | UX Composition Kernel MVP (AP-UX-1) |
-| BP-5 (Prompt/Agent) | **AP2.1 Go** + Principle Gate Prompts |
-| BP-3 (Tenant-Fork) | Tenant-Invariants; Capability `kairo.blueprint.manage` definiert |
-
----
-
-## Abnahme Scope Lock
-
-- [ ] PO bestätigt: BP-1…4 ohne SL-1…18
-- [ ] Kein Agent startet BP-5 ohne explizite AP2.1-Freigabe
-- [ ] Truth Table aktualisieren bei BP-1 Lieferung
-
----
-
-*Kurz-Scope-Lock — Detailkonzept in `ADP_Vorhaben_Template_Blueprint_v0.1.md`.*

docs/architecture/ADP_Vorhaben_Template_Blueprint_v0.1.md

@@ -1,616 +0,0 @@
-# ADP — Vorhaben-Template / Blueprint v0.1 (AP-BP-0)
-
-**Status:** Konzeptionsentwurf — PO-Freigabe ausstehend  
-**Stand:** 2026-07-27  
-**Autor:** Architektur (AP-BP-0 Konzeptionsauftrag)  
-**Bezug:** `AP_BP_0_Template_Blueprint_Conception_Prompt_v0.1.md`, `Kairo_Vision_and_Product_Direction_v0.2.md`, `Kairo_Canonical_Operating_Model_v0.2.md`, `Kairo_MVP_Definition_v0.3.md`, `Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`, `ADP_Archetype_and_Method_Catalog_v0.2.md`, `Kairo_Steering_Method_Kernel_v0.1.md`, `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`, `ADP_Steering_Kernel_Coding_Rules_v0.1.md`, `ADP_UX_Composition_Kernel_v0.1.md`, `ADP_AP1_10_Initiative_Archetypes_and_Entity_Field_System_v0.1.md`, `Kairo_Method_Design_Principles_v0.1.md`, `Kairo_MVP_Execution_Plan_v0.2.md`  
-**Ersetzt nicht:** Plugin-ADPs AP2.3/AP2.4, Steering Kernel Coding Rules, UX Composition Kernel  
-**Begleitdokument:** `ADP_Template_Blueprint_Scope_Lock_v0.1.md`
-
----
-
-## 1. Problem & Nordstern
-
-### 1.1 Ausgangslage
-
-Kairo hat nach AP2.3/AP2.4 eine saubere Trennung **Archetyp (Schicht 2) ↔ Methode (Schicht 1)** und einen zentralen **Steering Kernel** (`evaluate_steering()`). Für konkrete Vorhabenarten — Karate Kumite, Kairo-Entwicklung, Buch schreiben — fehlt jedoch eine **implementierbare Schicht 3**, die:
-
-- bei Anlage **sinnvolle Startstruktur** liefert (Starter-Kits AP2.2a),
-- **domänenspezifische Felder, Labels und Copy** parametrisiert,
-- **tenant-/nutzer-konfigurierbar** ist, ohne neue Archetypen zu erfinden,
-- und **keine Steuerungslogik** dupliziert.
-
-Heute existieren **dünne Code-Seeds** in `backend/method_profiles/registry.py` (`method_profile_key`) mit Metadaten und `seed_hints`, aber **ohne** profil-differenzierte Materialisierung in der UI, ohne Copy-Bindings und ohne tenant-scoped Persistenz.
-
-### 1.2 Nordstern
-
-> **Blueprint** = konkrete Vorlage **auf** einem Archetyp für einen **bestimmten Aufgabentyp**.  
-> Blueprint **parametrisiert und präsentiert** — es **ersetzt keine Methode** und **erfindet keine Steuerungslogik**.
-
-Kairo bleibt **Program Director** (Vision v0.2, MVP v0.3 §1). Die Leitfrage bleibt:
-
-> Welcher nächste Schritt bringt dieses Vorhaben **jetzt** am wirksamsten voran — und **warum**?
-
-Blueprints helfen dem Nutzer, **schneller in methodengerechte Struktur** zu kommen und **passende Sprache** zu sehen — ohne Todo-Explosion (MVP v0.3 §7) und ohne versteckte Archetypen.
-
-### 1.3 Warum nach MVP Stufe A — nicht davor blockierend
-
-| Aspekt | Begründung |
-|--------|------------|
-| AP2.1 Validation | Stufe A muss Steuerung **ohne** Blueprint-Tiefe beweisen |
-| AP2.2a Starter-Kits | Liefern **generische** Archetyp-Struktur — Blueprint **verfeinert** dieselbe Pipeline |
-| Konzept jetzt | Migrationspfad von Code-Seeds → DB; Bindings-Matrix; Guardrails **vor** Implementierung |
-| Implementierung BP-1+ | **Nach** ADP-Freigabe; parallel zu AP2.2c/e möglich — PO entscheidet Minimal-Slice |
-
----
-
-## 2. Begriffe
-
-| Begriff | Definition | Abgrenzung |
-|---------|------------|------------|
-| **Blueprint** (`blueprint_key`) | Versionierte, scope-gebundene Vorlage **auf** einem Archetyp. Bindet Felder, Presets, Copy, Composition-Config, Prompt-Refs — **nicht** Steuerungsalgorithmus. | ≠ Archetyp; ≠ Methode |
-| **Vorhaben-Template** | Product-Sprache für Blueprint; synonym im PO-Kontext | Technischer Key: `blueprint_key` |
-| **Archetyp** | Schicht 2: Natur, `om_capabilities`, Default-Methode (Empfehlung), EFS-Basis, `ui_profile` (Nav/Routen/Outline) | Ändert sich **nicht** durch Blueprint |
-| **Methode** | Schicht 1: Steuerungsplugin im Kernel — `steering_elements`, Strategien, Proposals, Attention | Blueprint darf **keine** Methode ersetzen |
-| **Ausprägung** (historisch) | Katalog v0.2 §2.0 Schicht-3-Label für `method_profile_key` | **Wird durch Blueprint ersetzt** (Rename + Superset, siehe §4.4) |
-| **Method Profile** (Ist-Code) | Code-Seed in `method_profiles/registry.py` | **Legacy-Anker** → migriert zu System-Blueprint |
-| **Preset** | Deklarativer Seed-Block innerhalb eines Blueprints (Starter-Kit-Definition, Recurring-Vorlage, Gate-Namen) | Wird bei Instanziierung **materialisiert** (OM-Objekte) |
-| **Seed** | System-definierter Initialwert (Code oder DB), nicht tenant-editierbar im MVP | Blueprint **referenziert** Seeds; Tenant-Kopie darf Presets überschreiben (BP-3+) |
-| **Structure Builder** (voll) | Hook-getriebene **Tiefenstruktur** via Method Registry (`on_structure_required`, Builder-Registry) | **Deferred** (MVP Execution Plan); Blueprint **liefert** leichte Presets, **triggert nicht** vollen Builder |
-| **Starter-Kit** | AP2.2a: idempotente Materialisierung bei Anlage (`apply_starter_kit`) | Blueprint **liefert** Kit-Definition; Fallback = Archetyp-Default-Kit |
-| **Instanziierung** | Vorhaben-Anlage: Blueprint wählen → Presets materialisieren, Referenzen setzen | `initiatives.blueprint_key` + `steering_context.lifecycle_metadata` |
-| **Materialisiert** | Kopie in OM (RoadmapItems, Projects, BacklogItems, …) — danach **unabhängig** editierbar | |
-| **Referenz** | Bleibt am Vorhaben: `blueprint_key`, `blueprint_version`, Prompt-Refs, Composition-Overrides | Änderung am Blueprint **propagiert nicht** rückwirkend auf materialisierte OM-Objekte (v1) |
-
-### 2.1 Entscheidungs-Lock: Archetyp ≠ Template
-
-PO 2026-07-25 (Decision-Lock §7): Template ändert die **Natur** eines Vorhabens nicht. Wesentliche Merkmale (Plan/Ist-Vertrag, Default-Methode-Empfehlung, OM-Capabilities) bleiben am Archetyp; Blueprint liefert **Konkretisierung** (Felder, Darstellung, Presets, Copy).
-
----
-
-## 3. Schichtenmodell (erweitert)
-
-### 3.1 Fünf Schichten + Blueprint-Position
-
-```text
-┌──────────────────────────────────────────────────────────────────────────┐
-│  Schicht 4 — Integrationen & Agenten (eingefroren bis AP2.1 Go)          │
-│  MCP, Vibe-Coder, Gitea — Hook Slugs, Operational API                    │
-├──────────────────────────────────────────────────────────────────────────┤
-│  Schicht 3 — Blueprint (Vorhaben-Template / Ausprägung)                  │
-│  blueprint_key, bindings_json — Felder, Presets, Copy, Composition,      │
-│  Prompt-Refs; Scope: system | tenant | user                              │
-├──────────────────────────────────────────────────────────────────────────┤
-│  Schicht 2 — Archetyp (entity_archetypes + EFS + ui_profile)             │
-│  Natur, om_capabilities, Default-Methode, Nav/Routen/Plan-Outline        │
-├──────────────────────────────────────────────────────────────────────────┤
-│  Schicht 1 — Methode (Method Registry + Steering Kernel)                 │
-│  steering_elements, data_slices, Strategien, Proposals, Attention          │
-├──────────────────────────────────────────────────────────────────────────┤
-│  Schicht 0 — Framework (OM, TenantContext, Audit, Capabilities)          │
-└──────────────────────────────────────────────────────────────────────────┘
-```
-
-**Katalog v0.2 §2.0 Mapping:** Schicht 3 hieß „Ausprägung (Method Profile)“. Dieses ADP **benennt** sie verbindlich **Blueprint** und erweitert den Vertrag.
-
-### 3.2 Auflösungskette zur Laufzeit
-
-```text
-Initiative (archetype_key, blueprint_key?)
-        │
-        ▼
-SteeringContext (method_key, lifecycle_metadata)
-        │
-        ├──► Archetyp-Registry ──► ui_profile, om_capabilities, EFS-Basis
-        ├──► Method Registry ──► steering_elements, data_slices, graph_profile
-        └──► Blueprint-Resolver ──► bindings (Copy, Presets-Metadaten, Composition-Overrides)
-                    │
-                    ▼
-        GET /initiatives/:id/operating-context
-        (bestehend + blueprint-Binding-Slice)
-                    │
-                    ▼
-        evaluate_steering() ──► Snapshot (read_models, proposals, agent_slots)
-                    │
-                    ▼
-        resolveSteeringComposition() ──► UI-Slots + Provider (UX Composition Kernel)
-```
-
-**Regel:** Blueprint-Resolver läuft **neben** Operating Context — **nicht** im Kernel. Kernel liest höchstens **parametrisierte** Werte aus Operating Context (z. B. `proposal_rankers`, `agent_slot_config`) — nie Blueprint-Ifs.
-
-### 3.3 Kompatibilitätsmatrix (Blueprint ↔ Archetyp ↔ Methode)
-
-```text
-compatible(blueprint, initiative) :=
-  blueprint.initiative_archetype_key = initiative.archetype_key
-  AND blueprint.method_key = steering_context.method_key
-     OR blueprint.method_key IS NULL  -- „any compatible primary“
-  AND blueprint.method_key ∈ compatible_methods(archetype)
-  AND blueprint.scope erlaubt für Tenant/User
-```
-
-| Kardinalität | Regel |
-|--------------|-------|
-| Archetyp → Blueprint | **1:n** — mehrere Blueprints pro Archetyp (Kumite, Spagat, … auf A1) |
-| Blueprint → Archetyp | **1:1** — kein Multi-Archetyp-Blueprint |
-| Blueprint → Methode | **1:1** optional fix; `NULL` = Default-Methode des Archetyps |
-| Vorhaben → Blueprint | **0:1** — optional; ohne Blueprint = Archetyp-Default-Starter |
-| Modifier (`agile_iteration`) | Über Blueprint-Flag `composition_hints.agile_iteration` — **kein** eigener Blueprint-Typ |
-
----
-
-## 4. Template-Metamodell
-
-### 4.1 Entität `blueprint` (Ziel-Schema)
-
-Persistenz Zielbild: Tabelle `blueprints` (tenant-scoped für Kopien; `tenant_id NULL` = System). Bis BP-1: Code-Seeds analog `method_profiles/registry.py`.
-
-| Feld | Typ | Pflicht | Beschreibung |
-|------|-----|---------|--------------|
-| `blueprint_key` | string (stable slug) | ja | z. B. `maturity.karate_kumite` |
-| `version` | semver / int | ja | Monotonic; Published-Version immutable |
-| `label` | string | ja | UI-Anzeige (darf Archetyp-Label übersteuern) |
-| `description` | text | nein | Kurzbeschreibung für Auswahl-Dialog |
-| `initiative_archetype_key` | string | ja | Bindung Schicht 2 |
-| `method_key` | string \| null | nein | Fixierte Primary-Methode; null = Archetyp-Default |
-| `scope_type` | enum | ja | `system` \| `tenant` \| `user` |
-| `scope_tenant_id` | uuid \| null | bedingt | Pflicht bei tenant/user |
-| `scope_user_id` | uuid \| null | bedingt | Pflicht bei user |
-| `parent_blueprint_key` | string \| null | nein | Vererbung (Tenant-Kopie von System-Blueprint) |
-| `status` | enum | ja | `draft` \| `published` \| `deprecated` |
-| `bindings_json` | jsonb | ja | Siehe §4.2 |
-| `created_at`, `updated_at`, `published_at` | timestamp | ja | Audit |
-| `is_system` | bool | ja | System-Blueprints nicht löschbar |
-
-**Initiative-Referenz:**
-
-| Feld auf `initiatives` / `steering_context` | Beschreibung |
-|---------------------------------------------|--------------|
-| `blueprint_key` | Gewählter Blueprint bei Anlage |
-| `blueprint_version` | Eingefrorene Version bei Instanziierung |
-| `method_profile_key` | **Deprecated-Alias** bis Migrationsende (BP-1) |
-
-### 4.2 `bindings_json` — Top-Level-Struktur
-
-Implementierbarer JSON-Vertrag (Auszug):
-
-```json
-{
-  "efs": {
-    "field_defaults": { "discipline": "Karate" },
-    "field_overrides": [],
-    "tenant_field_extensions_allowed": false
-  },
-  "starter_kit": {
-    "kit_key": "maturity.karate_kumite.v1",
-    "items": [
-      { "kind": "project", "title": "Kumite", "sort_order": 1 },
-      { "kind": "maturity_stage", "title": "Stufe 1 — Basis", "status": "active" }
-    ]
-  },
-  "composition": {
-    "steering_element_copy": {
-      "gate_fulfillment": { "horizon_label": "Release-Horizont Kairo" }
-    },
-    "provider_overrides": [
-      { "provider_key": "steering.critical_path", "order": 5, "props": {} }
-    ],
-    "proposal_ui": {
-      "intake_triage": { "lead": "Product-Issues triagieren — nicht alles committen." }
-    }
-  },
-  "steering_presentation": {
-    "attention_labels": {},
-    "agent_slot_copy": {},
-    "backlog_vocabulary": { "backlog_item": "Issue" },
-    "journey_event_labels": {},
-    "graph_labels": {},
-    "plan_outline_hints": []
-  },
-  "prompt_refs": [
-    {
-      "prompt_key": "kairo.product.triage_hint",
-      "context_kind": "initiative_snapshot",
-      "placeholder_bindings": { "product_name": "efs.product_vision" }
-    }
-  ],
-  "composition_hints": {
-    "agile_iteration": true,
-    "default_actor_setup": "po_plus_vibe_coder"
-  },
-  "ranker_params": {
-    "intake_triage": { "stale_days_weight": 1.2 }
-  },
-  "guidance": "Eingang triagieren, dann committete Actions — optional Sprint."
-}
-```
-
-**Nicht in bindings_json:** `method_key`-Override auf inkompatiblen Archetyp, Lifecycle-States, neue `steering_elements`, Router-Logik, React-Komponenten-Keys ohne Provider-Registry.
-
-### 4.3 Lifecycle (draft / published / deprecated)
-
-| Status | Bedeutung |
-|--------|-----------|
-| `draft` | Editierbar; nicht in Anlage-Dialog für Endnutzer |
-| `published` | Wählbar bei Anlage; Version frozen |
-| `deprecated` | Nicht wählbar; bestehende Referenzen bleiben gültig |
-
-**Versionierung:** Neues `published` = neue `version`; laufende Initiativen behalten `blueprint_version` bei Instanziierung. Kein Auto-Upgrade materialisierter Struktur (v1).
-
-### 4.4 Method Profile → Blueprint (Rename + Superset)
-
-**Empfehlung:**
-
-| Aspekt | Entscheidung |
-|--------|--------------|
-| Konzept | **Superset** — Blueprint enthält alles, was `method_profile` heute kann, plus Bindings-Matrix |
-| Technischer Key | **`blueprint_key`** — `method_profile_key` wird **Alias** in API/Snapshot bis BP-2 abgeschlossen |
-| Modul | `backend/method_profiles/` → `backend/blueprints/` (BP-1); Re-Export für Kompatibilität |
-| Decision-Lock D1 | `content.book_writing` bindet an **`initiative.linear_project`**, nicht `initiative.content_project` |
-
----
-
-## 5. Bindings-Matrix
-
-Legende:
-
-| Spalte | Bedeutung |
-|--------|-----------|
-| **Template darf** | Blueprint darf Wert setzen/übersteuern (Präsentation, Defaults, Presets) |
-| **Nur System** | Nur `scope_type=system` Blueprints; Tenant/User-Kopien eingeschränkt |
-| **Kernel bleibt Owner** | Logik, Algorithmus, Aktivierung — nicht durch Template ersetzbar |
-| **Phase** | Erste Implementierungsphase |
-
-| Bindbares Artefakt | Template darf | Nur System | Kernel bleibt Owner | Phase |
-|--------------------|---------------|------------|---------------------|-------|
-| **EFS-Felddefinitionen** (Schema) | Nein — nur Archetyp-Registry + Tenant-EFS-Override (AP1.10 Phase 2) | Archetyp-Seeds | EFS-Validierungsservice | — |
-| **EFS-Default-Werte** | Ja — `bindings.efs.field_defaults` | System-Blueprints | Validierung gegen `field_definitions` | BP-2 |
-| **EFS-Label-Overrides** (Anzeige) | Ja — `field_overrides[].label` | — | Feldtyp/Required | BP-3 |
-| **Tenant-nutzerdefinierte Felder** | Flag `tenant_field_extensions_allowed`; keine Schema-Erfindung im Template | Governance-Policy | Tenant-Invariants | BP-3+ |
-| **Standardspalten** (`vision`, `goal`, …) | Default-Vorschläge bei Anlage | — | Initiative-Service | BP-2 |
-| **Starter-Kit / Struktur-Presets** | Ja — vollständige `starter_kit.items[]` | System-Blueprints für Referenz-Portfolio | `apply_starter_kit` Idempotenz-Regeln | BP-2 |
-| **Recurring-Presets** | Ja — als Starter-Items `kind: recurring` | — | Recurring-Service, AP2.0e Cadence-Logik | BP-2 |
-| **steering_element UI-Copy** | Ja — Labels/Hints/Empfehlungstexte | — | **Aktivierung** via Methode `steering_elements` | BP-4 |
-| **steering_element Sichtbarkeit** | Nein — nur über Methode + `data_slices` | — | `resolve_effective_steering_elements()` | — |
-| **Composition-Provider** (Slot, order) | Ja — `order`, `props`, optionales Ausblenden via `enabled: false` | Neue Provider-Kinds | Provider-Registry + Match-Regeln | BP-4 |
-| **Proposal-UI-Config** (`gate_next_actions`, `intake_triage`, `sprint_commit`) | Ja — `title`, `lead`, `acceptLabel` | — | Proposal-**Generierung** im Kernel | BP-4 |
-| **Proposal-Ranker-Parameter** | Ja — `ranker_params.{proposal_key}` numerische Gewichte | Grenzen via Method Contract | Ranker-Implementierung, SK-05 | BP-5 |
-| **Attention-Labels / Severity-Hints** | Ja — Präsentations-Copy für bekannte `attention_code` | — | Attention-**Auslösung** (Contributors) | BP-4 |
-| **Agent-Slot-Copy** | Ja — Titel/Hinweis pro `slot_key` | — | Slot-**Existenz** + `agent_slot_config` | BP-5 |
-| **Prompt-Referenzen** (key, context_kind, Platzhalter) | Ja — `prompt_refs[]` | Prompt-Inhalt in Prompt-Registry | Ausführung, Audit, Principle Gate | BP-5 |
-| **Graph-/Gate-Labels** | Ja — Achsen-/Knoten-Labels, Gate-Titel-Vorschläge | — | Graph-Berechnung, Gate-Fulfillment | BP-4 |
-| **Plan-Outline-Hints** | Ja — empfohlene Outline-Reihenfolge, Sektions-Titel | — | Archetyp `ui_profile.planOutline` Basis | BP-4 |
-| **Backlog-Vocabulary-Profil** | Ja — Begriffe (`backlog_item` → „Issue“) | — | `resolve_backlog_vocabulary()` Logik | BP-4 |
-| **Journey-Event-Typ-Labels** | Ja — Darstellungslabels für Event-Typen | — | Journey-Event-Erzeugung | BP-4 |
-| **method_key** | Nein | — | SteeringContext + Kompatibilitätsprüfung | — |
-| **archetype_key** | Nein | — | Initiative | — |
-| **steering_elements (Aktivierung)** | Nein | — | Method Registry | — |
-| **Next-Action-Algorithmus** | Nein | — | `evaluate_steering()` | — |
-| **Lifecycle-Override** | Nein | — | Lifecycle-Orchestrator | — |
-| **Neue OM-Tabellen / Entitätstypen** | Nein | — | Scope Lock | — |
-| **Neue Provider-Kinds (UX)** | Nein | ADP UX Composition | Composition Kernel | — |
-| **Archetyp-Ifs in Pages** | Verboten | — | `hasSteeringElement`, Operating Context | — |
-
----
-
-## 6. Steuerungs-Grenze
-
-### 6.1 Was bei Archetyp + Methode bleibt
-
-| Verantwortung | Owner |
-|---------------|-------|
-| Natur, Plan/Ist-Vertrag | Archetyp |
-| `steering_elements`, Proposals, Read Models, Attention | Methode + Kernel |
-| Next Work, Ranking, `reason_code` | `evaluate_steering()` |
-| Komposition `agile_iteration` | Method Registry (`composes_with`) |
-| `data_slices` | Schnittmenge Archetyp ∩ Methode |
-| Gate-Fulfillment, Planning Debt | Provider in `steering/proposals/`, `steering/read_models/` |
-
-### 6.2 SK-Regeln (verbindlich)
-
-| Regel | Konsequenz für Blueprint |
-|-------|--------------------------|
-| **SK-01** | Kein Blueprint-Zweig in `evaluate_steering()` |
-| **SK-03** | Keine Steuerungsheuristik in Blueprint-Resolver |
-| **SK-04** | UI bindet an Proposal-Keys — Blueprint ändert nur Copy/Parameter |
-| **SK-05** | Ranker-Parameter nur Gewichte/Schwellen — keine „Bug-zuerst“-Policy im Template |
-| **SK-10–12** | Frontend: Composition + `PROPOSAL_UI_CONFIG` Merge aus Operating Context |
-| **SK-13–14** | Prompt-Inhalt nie im Blueprint-JSON — nur `prompt_key`-Referenz |
-
-### 6.3 Anti-Patterns (explizit)
-
-| Verboten | Konsequenz |
-|----------|------------|
-| Template als versteckter Archetyp | Neuer `archetype_key` nur via Archetyp-Registry + ADP |
-| Todo-Wand durch Template-Listen | Presets ≠ 200 materialisierte Actions; Starter-Kit-Limits |
-| Parallele Steuerung in Blueprint-Resolver | Ein Spine: Kernel |
-| `if blueprint_key === '…'` in Pages | Nur Composition/Context |
-| Template überschreibt `method_key` auf inkompatibel | Validierung bei Anlage |
-
----
-
-## 7. EFS & nutzerdefinierte Felder
-
-### 7.1 Feldquellen (Priorität)
-
-```text
-1. Archetyp field_definitions (system, EFS)
-2. Tenant-Overrides auf field_definitions (AP1.10 Phase 2 — tenant-scoped)
-3. Blueprint field_defaults + label overrides (Schicht 3)
-4. Initiative field_values (Instanz)
-```
-
-### 7.2 Grenzen
-
-| Thema | Regel |
-|-------|-------|
-| **Schema-Erfindung** | Blueprint darf **keine** neuen `field_key` ohne Archetyp/EFS-ADP einführen |
-| **Tenant-Custom-Fields** | Eigene ADP-Erweiterung; Blueprint kann `tenant_field_extensions_allowed: true` setzen — **nicht** MVP BP-1/2 |
-| **Validierung** | PATCH `/fields` validiert gegen effektive Definition — Blueprint-Defaults bei Anlage, danach normal |
-| **Steering-Nutzung** | Dynamische Felder in Heuristiken nur mit ADP — Standardspalten + explizite Platzhalter-Bindings |
-| **Search/Hot Path** | Nur `searchable=true` Felder; Blueprint-Defaults schreiben `field_values` |
-
-### 7.3 Tenant-Invariants
-
-- Alle Blueprint-Kopien: `tenant_id NOT NULL`
-- User-Scope: zusätzlich `scope_user_id`; Capability `kairo.blueprint.manage_own`
-- System-Blueprints: read-only für Tenants; Kopie erzeugt `scope_type=tenant`
-
----
-
-## 8. UX / Composition
-
-### 8.1 Template → UI-Slots
-
-UX Composition Kernel (ADP UX v0.1) bleibt **Owner** der Slot-/Provider-Registry. Blueprint liefert **Overrides**:
-
-```text
-resolveSteeringComposition(
-  operatingContext,          // enthält blueprint_bindings
-  steeringSnapshot,
-  ...
-)
-  → merge PROPOSAL_UI_CONFIG with blueprint.composition.proposal_ui
-  → merge steeringElementRegistry labels with blueprint.composition.steering_element_copy
-  → apply provider_overrides (order, props, enabled)
-```
-
-### 8.2 Verboten
-
-- Neue `kind`-Werte in `compositionProviders.js` ohne ADP
-- Archetyp-Ifs zur Panel-Aktivierung
-- Blueprint-spezifische React-Pages
-
-### 8.3 Cockpit / Portfolio
-
-Blueprint-Bindings gelten **initiative-scoped**. Portfolio-Aggregation (`GET /workspace/steering`) nutzt **keine** Blueprint-Copy — nur Kernel-Output.
-
----
-
-## 9. Impulse, Proposals, Attention
-
-| Aspekt | Blueprint | Kernel |
-|--------|-----------|--------|
-| Proposal **Existenz** | — | Provider + `steering_elements` |
-| Proposal **summary** in DTO | — | Ranker/Provider |
-| UI **title/lead/acceptLabel** | Ja | — |
-| **reason_code** → Label-Mapping | Erweiterung `proposalReasonLabel`-Map | Codes stabil |
-| Attention **Auslösung** | — | Contributors |
-| Attention **Anzeige-Text** | Ja (`attention_labels`) | — |
-| Programm-**Impulse** (B2a) | Copy für Impulse-Typen | Nested Context Kernel |
-
-**Ranker-Parameterisierung:** Blueprint liefert `ranker_params` → Operating Context → Kernel liest bei Ranker-Aufruf. Keine neuen Ranker-Keys im Template ohne Registry-Eintrag.
-
----
-
-## 10. KI / Prompts
-
-### 10.1 Binding-Modell
-
-```text
-Blueprint.prompt_refs[]:
-  prompt_key        → Eintrag in prompt_definitions (Foundation)
-  context_kind      → initiative_snapshot | operating_context | agent_slot_payload
-  placeholder_bindings → { "product_name": "efs.product_vision" | "snapshot.method_key" }
-```
-
-### 10.2 Governance
-
-| Regel | Detail |
-|-------|--------|
-| Freeze | **Keine produktive KI-Ausführung** bis AP2.1 Go — BP-5 Implementierung, nicht BP-1 |
-| SK-13 | Kein Prompt-Text in Blueprint, UI, Router |
-| Audit | Ausführung über bestehende `prompt_execution_logs` |
-| Agent-Slots | SK-17: Slots deklarativ; Prompt-Ref optional an Slot |
-
----
-
-## 11. Structure Builder — Abgrenzung
-
-| Aspekt | Starter-Kit / Blueprint | Structure Builder (voll) |
-|--------|-------------------------|---------------------------|
-| **Wann** | Bei Initiative-Anlage | Hook `on_structure_required` / Lifecycle Schlitz 3 |
-| **Tiefe** | 5–15 Seed-Objekte, Guidance | Tiefen-WBS, Feature-Landschaft, Graph-Generierung |
-| **Owner** | Blueprint `starter_kit` + `apply_starter_kit` | Method Registry Builder |
-| **MVP** | **Ja** (AP2.2a + BP-2) | **Deferred** |
-| **Beziehung** | Blueprint **kann** `structure_builder_hint` setzen — triggert später optional Builder | Builder liest Hint, nicht Blueprint-If |
-
-**Regel:** Blueprint **ersetzt** Structure Builder nicht. Bei BP-6+ Designer kann Tenant Presets erweitern — bleibt unter Builder-Hook-Governance.
-
----
-
-## 12. Persistenz-Zielbild
-
-### 12.1 Tabellen (Phase C Erweiterung Target Architecture §15)
-
-```text
-blueprints (
-  id, blueprint_key, version, label, description,
-  initiative_archetype_key, method_key,
-  scope_type, tenant_id, user_id,
-  parent_blueprint_key, status, bindings_json,
-  is_system, created_at, updated_at, published_at
-)
-
-initiatives.blueprint_key          -- nullable
-initiatives.blueprint_version      -- nullable, gesetzt bei Anlage
-steering_context.lifecycle_metadata.blueprint_key  -- Spiegel / Legacy method_profile_key
-```
-
-**Indizes:** `(tenant_id, initiative_archetype_key, status)`, `(blueprint_key, version)` unique.
-
-### 12.2 Code-Seeds → DB (BP-1)
-
-1. Inhalt von `METHOD_PROFILES` nach `blueprints` migrieren (System, `published`)
-2. `bindings_json` minimal: `guidance`, `starter_kit` aus erweiterten Seeds, `composition_hints`
-3. API: `GET /api/blueprints?archetype_key=…` ersetzt erweitert `GET /steering/method-profiles`
-4. Alias: `method_profile_key` ↔ `blueprint_key` (identische Werte in v1)
-
----
-
-## 13. Migrationspfad — Phasenplan AP-BP-1…n
-
-| Phase | Ziel | Deliverables | Abhängigkeit | Nicht in Phase |
-|-------|------|--------------|--------------|----------------|
-| **BP-0** | Konzeption | Dieses ADP + Scope Lock | — | Code |
-| **BP-1** | Read-only System-Blueprints | DB-Tabelle + Seed-Migration; API list/get; Operating Context `blueprint_key`; Alias `method_profile_key` | ADP frei | Anlage-Materialisierung, Tenant-Kopien |
-| **BP-2** | Anlage: Template wählen + materialisierte Presets | Anlage-Dialog Blueprint-Auswahl; `apply_starter_kit` aus Blueprint; EFS-Defaults; `blueprint_version` speichern | AP2.2a+, BP-1 | Copy-Bindings, Designer |
-| **BP-3** | Tenant-Kopie + editierbare Felder/Presets | Fork System→Tenant; PATCH bindings (draft); Capability-Gate | Tenant-Invariants, BP-2 | Prompt-Ausführung |
-| **BP-4** | Composition + Copy-Bindings | Merge in `resolveSteeringComposition`; Backlog-Vocabulary; Proposal/Attention-Copy | UX Kernel MVP, BP-1 | KI-Produktion |
-| **BP-5** | Prompt/Agent-Bindings | `prompt_refs` Auflösung; Agent-Slot-Copy; `ranker_params` | **AP2.1 Go**, BP-4 | Designer |
-| **BP-6** | Designer / Import | Visueller Blueprint-Editor; YAML-Import; Versionierung UI | BP-3, PO-Priorität | — |
-
-### 13.1 Parallelität zu MVP Stufe A
-
-```text
-AP2.1 Validation (Stufe A Abschluss)     ──┐
-AP2.2c / AP1.9d                          ──┼── parallel möglich, nicht blockiert durch BP-0
-BP-1 (Read-only Seeds)                   ──┘  nach ADP-Freigabe; PO entscheidet Minimal-Slice
-
-BP-2+ sollte AP2.2a Starter-Kit-Pipeline nutzen — nicht ersetzen.
-BP-5 explizit nach AP2.1 Go — KI/Prompt eingefroren.
-```
-
-### 13.2 Was **nicht** vor AP2.1 Go
-
-- Produktive Prompt-Ausführung aus Blueprint
-- Agent-Ranker (`agent_v1`) Parameter aus Template
-- MCP/Workflow-Fragmente an Blueprint gebunden
-
----
-
-## 14. Referenz-Blueprints (Beispiele — keine Vollimplementierung)
-
-### 14.1 `product.kairo_dev`
-
-| Attribut | Wert |
-|----------|------|
-| Archetyp | `initiative.product` |
-| Methode | `continuous_product` |
-| Komposition | `agile_iteration` via `composition_hints` |
-| EFS-Defaults | `product_vision`, `primary_repo_or_system` (Platzhalter) |
-| Starter-Kit | Gates „Orientierung“, „Nächster Release-Horizont“; Projects „Entwicklung“, „Betrieb“; Sample-Backlog „Idea“ |
-| Composition | `gate_fulfillment`-Horizont-Copy; Sprint-Hinweis wenn `work_cycle_scope` aktiv |
-| Proposals | `intake_triage.lead` product-spezifisch |
-| Prompt-Ref (BP-5) | `kairo.product.triage_hint` |
-| Backlog-Vocabulary | `backlog_item` → „Issue“ |
-| **Nicht** | Eigene Next-Action-Strategie; kein erzwungenes `critical_path`; kein Archetyp-Wechsel |
-
-**Differenzierung zu Generic Product:** Labels, Gate-Namen, Issue-Vokabular, PO+Vibe-Coder-Hint — **gleiche** `steering_elements` wie `continuous_product`.
-
-### 14.2 `maturity.karate_kumite`
-
-| Attribut | Wert |
-|----------|------|
-| Archetyp | `initiative.maturity_journey` |
-| Methode | `maturity_progression` |
-| EFS-Defaults | `discipline` = „Karate“ |
-| Starter-Kit | 8 Projects (Fähigkeiten) × Stufen-Presets (5–7 `maturity_stage` pro Skill — **Struktur-Seed**, nicht 200 Tasks); Recurring „Training“ |
-| Journey-Labels | Kumite-spezifische Event-Darstellung |
-| Graph | `graph_prerequisites: true` — Labels only; Kanten manuell/separater Graph-Setup |
-| **Nicht** | Stufenwechsel-Logik im Template — bleibt Kernel + AP2.0e; keine neuen OM-Typen |
-
-**Differenzierung zu Generic A1:** Disziplin-Feld, 8-Skill-Raster, Kumite-Vokabular — **gleiche** Methode `maturity_progression`.
-
-### 14.3 `content.book_writing`
-
-| Attribut | Wert |
-|----------|------|
-| Archetyp | **`initiative.linear_project`** (Decision-Lock D1 — kein `content_project`) |
-| Methode | `sequential_dependency` (+ optional `agile_iteration`) |
-| EFS-Defaults | `word_goal`, `genre` |
-| Starter-Kit | Kapitel als `milestone`/`chapter`-RoadmapItems; Review-Gate-Presets; Project „Manuskript“ |
-| Composition | `gate_next_actions.lead` schreib-orientiert |
-| Plan-Outline-Hints | Kapitel → Review → Revision |
-| **Nicht** | Eigene Kapitel-Steuerungsmethode; `chapter_based_progression` nur wenn Methode explizit gewählt und kompatibel |
-
-**Hinweis Migration:** Ist-Seed `content.book_writing` in `method_profiles/registry.py` referenziert noch `initiative.content_project` — bei BP-1 auf Decision-Lock korrigieren.
-
----
-
-## 15. Abnahme & PO-Freigabe
-
-### 15.1 Qualitätskriterien (AP-BP-0 Prompt)
-
-- [x] Entwickler kann aus §4.2 + §5 ableiten, welche JSON-Felder ein Blueprint hat
-- [x] Laufzeit-Auflösung neben Operating Context dokumentiert (§3.2)
-- [x] Mindestens zwei Referenz-Blueprints differenzierbar ohne neues Steering (§14.1, §14.2)
-- [x] Anti-Patterns MVP v0.3 §3 und SK-Regeln adressiert (§6.3)
-- [x] Migrationspfad `method_profiles/registry.py` dokumentiert (§12.2, §4.4)
-- [x] KI/Designer als Phasen, nicht MVP-Blocker (§13, BP-5/6)
-- [x] Konflikte Katalog v0.2 / Decision-Lock markiert (§14.3, §16)
-
-### 15.2 PO-Freigabe-Checkliste
-
-- [ ] Blueprint vs. Method Profile Rename akzeptiert
-- [ ] Bindings-Matrix Scope für BP-1…4 bestätigt
-- [ ] Referenz-Blueprints (Kumite, Kairo Dev, Buch) als System-Seeds freigegeben
-- [ ] Parallelität BP-1 vs. AP2.1 explizit entschieden
-- [ ] Tenant-Custom-Fields-Grenze (BP-3 vs. EFS Phase 2) entschieden
-
----
-
-## 16. Offene Entscheidungen (PO)
-
-| # | Frage | Optionen | Empfehlung |
-|---|-------|----------|------------|
-| **O-1** | Minimal-Slice: BP-1 vor AP2.1? | A) BP-1 parallel B) BP-1 nach AP2.1 Go | A — read-only, risikoarm |
-| **O-2** | API-Key: sofort `blueprint_key` oder Alias-Phase? | A) Dual-Key 6 Monate B) Hard cut | A — Dual-Key |
-| **O-3** | User-Scope Blueprints (`scope_type=user`)? | A) BP-3 B) BP-6 C) Nie | B — erst mit Designer |
-| **O-4** | Tenant darf System-Blueprint `bindings_json` überschreiben oder nur Fork? | A) Fork only B) Overlay | A — Fork only (Audit, Versionierung) |
-| **O-5** | Materialisierte Presets bei Blueprint-Version-Upgrade? | A) Nie auto B) Opt-in Migration C) Nur Copy | A für v1 |
-| **O-6** | `content.book_writing`: Methode `sequential_dependency` oder `chapter_based_progression`? | Decision-Lock: A2 + Profil | `sequential_dependency` Default; `chapter_based_progression` wenn PO als kompatible Methode freigibt |
-| **O-7** | Blueprint-Auswahl Pflicht bei Anlage? | A) Optional B) Pflicht wenn >1 | A — Optional mit Empfehlung |
-| **O-8** | Projekt-Blueprints (Phase 2 AP1.10)? | A) Initiative only v1 B) Project später | A — Initiative only v1 |
-| **O-9** | Ranker-Parameter: Allowlist pro Proposal-Key? | A) Ja B) Freies JSON | A — Allowlist in Method Contract |
-| **O-10** | Katalog v0.3: Schicht-3-Label „Blueprint“ statt „Ausprägung“? | A) Ja B) Beide | A |
-
----
-
-## 17. Konfliktauflösung
-
-| Konflikt | Auflösung |
-|----------|-----------|
-| Katalog v0.2 D1 `content_project` vs. Decision-Lock A2+Profil | **Decision-Lock führt** — Blueprint `content.book_writing` auf `linear_project` |
-| Katalog v0.2 „Ausprägung“ vs. PO „Template“ | **Blueprint** = offizieller Name; Ausprägung historisch |
-| `method_profile_key` in API/Snapshot | Alias bis BP-2 abgeschlossen |
-| UX Composition: Provider-Props aus Blueprint vs. Registry | Registry definiert Kind; Blueprint nur `props`/`order`/`enabled` |
-| AP2.4: `agile_iteration` über Profil | **`composition_hints.agile_iteration`** im Blueprint — kein separates Profil-Objekt |
-
----
-
-## 18. Referenzen
-
-| Artefakt | Pfad |
-|----------|------|
-| Konzeptions-Prompt | `docs/architecture/AP_BP_0_Template_Blueprint_Conception_Prompt_v0.1.md` |
-| Scope Lock | `docs/architecture/ADP_Template_Blueprint_Scope_Lock_v0.1.md` |
-| Method Profiles (Ist) | `backend/method_profiles/registry.py` |
-| Starter-Kits | `backend/services/archetype_starter_kit.py` |
-| Operating Context | `backend/services/operating_context.py` |
-| UX Composition | `frontend/src/composition/` |
-| Proposal UI Config | `frontend/src/utils/steeringProposals.js` |
-
----
-
-*AP-BP-0 Ergebnis — kein Code. Implementierung erst nach PO-Freigabe dieses ADP.*

docs/architecture/AP_BP_0_Template_Blueprint_Conception_Prompt_v0.1.md

@@ -1,227 +0,0 @@
-# AP-BP-0 — Konzeptions-Prompt: Vorhaben-Template / Blueprint-Architektur
-
-**Status:** Arbeitsauftrag für Konzeptionsphase (kein Implementierungs-AP)  
-**Stand:** 2026-07-27  
-**Ziel-Deliverable:** `ADP_Vorhaben_Template_Blueprint_v0.1.md` (+ optional Scope-Lock-ADP)  
-**Nicht-Ziel:** Code, Migrationen, UI-Implementierung — erst nach PO-Freigabe des ADP
-
----
-
-## Rolle des Agents
-
-Du bist **Architekt:in für Jinkendo Kairo**. Deine Aufgabe ist eine **implementierbare, guardrail-konforme Konzeption** für die Schicht **Vorhaben-Template / Blueprint** — nicht ein generisches Template-Engine-Design und kein zweites Operating Model.
-
-Kairo ist **Program Director**, kein To-do-Tool. Steuerung läuft zentral über `backend/steering/` (`evaluate_steering()`). Templates **parametrisieren und präsentieren**, sie **ersetzen keine Methode** und **erfinden keine neue Steuerungslogik**.
-
----
-
-## PO-Vorgabe (verbindlich)
-
-> Steuerung bleibt **Archetyp- und Steuerungstyp-spezifisch**.  
-> Templates liefern später einen **Blueprint für einen bestimmten Aufgabentyp**: individuelle Felder, Prompts für KI-Auswertungen, Empfehlungen/Impulse, grafische Darstellungen, nutzerdefinierte Felder, Presets — **tenant-/nutzer-konfigurierbar in weiten Teilen**.
-
-**Archetyp ≠ Template** (Decision-Lock 2026-07-25): Template ändert die **Natur** eines Vorhabens nicht.
-
----
-
-## Pflichtlektüre (in dieser Reihenfolge)
-
-1. `docs/product/Kairo_Vision_and_Product_Direction_v0.2.md`
-2. `docs/product/Kairo_Canonical_Operating_Model_v0.2.md`
-3. `docs/product/Kairo_MVP_Definition_v0.3.md` — §2 Schichtenmodell, §7 Anti-Todo-Wand
-4. `docs/architecture/ADP_Archetype_and_Method_Catalog_v0.2.md` — §2.0 Vier Schichten, §2.2 Ausprägung
-5. `docs/product/Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md` — §7 Archetyp ≠ Vorhaben-Template
-6. `docs/architecture/Kairo_Steering_Method_Kernel_v0.1.md` — §10 Beziehung zu Archetypen und Templates
-7. `docs/architecture/ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`
-8. `docs/architecture/ADP_Steering_Kernel_Coding_Rules_v0.1.md` (SK-01…SK-19)
-9. `docs/architecture/ADP_UX_Composition_Kernel_v0.1.md` — Frontend-Spiegel, UI-Slots
-10. `docs/architecture/ADP_AP1_10_Initiative_Archetypes_and_Entity_Field_System_v0.1.md` — EFS
-11. `docs/architecture/Kairo_Method_Design_Principles_v0.1.md` — §8 Structure Builder (Abgrenzung)
-12. `docs/product/Kairo_MVP_Execution_Plan_v0.2.md` — Starter-Kits statt voller Structure Builder
-
-**Ist-Code (Referenz, nicht blind kopieren):**
-
-- `backend/method_profiles/registry.py` — heutige Code-Seeds (Schicht-3-Anker)
-- `backend/services/archetype_starter_kit.py` — AP2.2a Starter-Kits
-- `backend/services/operating_context.py` — Laufzeit-Auflösung
-- `frontend/src/composition/` — UX Composition Kernel (Provider, Slots)
-- `frontend/src/registry/steeringElementRegistry.js`
-
----
-
-## Kontext: Was heute existiert (Baseline)
-
-| Baustein | Stand | Rolle |
-|----------|-------|-------|
-| Archetyp-Registry + EFS | ✓ | Schicht 2 — Natur, Default-Methode, Felder |
-| Method Registry + Kernel v0.4 | ✓ | Schicht 1 — Steuerung |
-| `method_profile_key` (4 Code-Seeds) | ◐ | Schicht-3-Anker; API + Metadata; **kein** profil-differenziertes Starter-Kit in UI |
-| Starter-Kits AP2.2a | ✓ | Leichte Startstruktur; Ersatz für MVP-Structure-Builder |
-| UX Composition Kernel | ✓ MVP | UI-Slots/Provider aus `steering_elements` + Kernel-Proposals |
-| Structure Builder (voll) | ✗ deferred | Zielbild in Method Design Principles |
-| Tenant-Template-Designer | ✗ | Zielbild Target Architecture §15 |
-| KI/Prompt produktiv | ✗ eingefroren | bis AP2.1 Go; Prompt-Registry existiert Foundation-seitig |
-
-**Wichtig:** Das Konzept muss den **Migrationspfad** von Code-Seeds → tenant-scoped Blueprints beschreiben, ohne MVP Stufe A zu blockieren.
-
----
-
-## Leitfragen der Konzeption
-
-1. **Was ist ein Blueprint/Template formal?** (Entität, Version, Scope: system / tenant / user, Vererbung)
-2. **Was darf ein Template binden?** (Felder, EFS-Overrides, Starter-Presets, UI-Copy, Composition-Provider-Config, Prompt-Ref-IDs, Impuls-Texte, Graph-Labels, …)
-3. **Was darf ein Template explizit NICHT?** (Next-Action-Algorithmus, Lifecycle-Override, neue OM-Tabellen, Archetyp-Ifs in Pages, Router-Steuerung)
-4. **Wie hängt Template an Archetyp + Methode?** (Kompatibilitätsmatrix; ein Template pro Aufgabentyp; mehrere Templates pro Archetyp?)
-5. **Wie unterscheidet sich Template von Ausprägung (`method_profile_key`) und von Structure Builder?**
-6. **Wie nutzt der UX Composition Kernel Template-Config?** (Provider-Props, Copy, Sichtbarkeit — nicht neue Provider-Kinds ohne ADP)
-7. **Wie nutzt der Steering Kernel Template-Config?** (Proposal-Copy, Ranker-Parameter, Attention-Schwellen — über Registry, nicht Hardcode)
-8. **Wie werden KI-Prompts gebunden?** (Platzhalter-Registry, Template → prompt_key + context_kind; Audit; kein Prompt im React)
-9. **Nutzerdefinierte Felder:** EFS-Erweiterung tenant-scoped vs. Template-scoped — Grenzen, Validierung, Governance
-10. **Instanziierung:** Bei Vorhaben-Anlage — Template wählen → was wird materialisiert vs. was bleibt Referenz?
-11. **Konfiguration durch User:** Was ist MVP-nah (Kopie + Felder editieren) vs. post-MVP (Designer, Import)?
-12. **Anti-Patterns:** Template als versteckter Archetyp; Todo-Wand durch Template-Listen; parallele Steuerung
-
----
-
-## Gewünschte Deliverables
-
-### 1. Hauptdokument: `ADP_Vorhaben_Template_Blueprint_v0.1.md`
-
-Mindestens diese Abschnitte:
-
-| § | Inhalt |
-|---|--------|
-| 1 Problem & Nordstern | Warum Blueprint nach MVP Stufe A; Bezug Program Director |
-| 2 Begriffe | Blueprint, Template, Ausprägung, Preset, Seed, Structure Builder — **eindeutige Abgrenzung** |
-| 3 Schichtenmodell (erweitert) | Schicht 0–4 + wo Blueprint sitzt; Diagramm |
-| 4 Template-Metamodell | Felder, Relationen, Lifecycle (draft/published/deprecated) |
-| 5 Bindings-Matrix | Zeilen = bindbare Artefakte; Spalten = erlaubt / parametrisierbar / verboten / Phase |
-| 6 Steuerungs-Grenze | Was bleibt bei Archetyp+Methode; SK-Regeln; `evaluate_steering()` single spine |
-| 7 EFS & nutzerdefinierte Felder | Feldquellen, Validierung, Tenant-Invariants |
-| 8 UX / Composition | Template → UI-Slots, Provider-Props, Labels; kein Archetyp-If |
-| 9 Impulse, Proposals, Attention | Template-Copy vs. Kernel-Logik; Ranker-Parameterisierung |
-| 10 KI / Prompts | Binding-Modell; Governance; Freeze bis AP2.1 |
-| 11 Structure Builder | Abgrenzung: wann Template seedet vs. Builder hook |
-| 12 Persistenz-Zielbild | Code-Seeds → DB-Tabellen (Referenz Target Architecture §15) |
-| 13 Migrationspfad | AP-BP-1…n Phasen; was **nicht** vor AP2.1 Go |
-| 14 Referenz-Blueprints | Kumite, Kairo Dev, Buch — als **Beispiele**, nicht als Vollimplementierung |
-| 15 Abnahme & PO-Freigabe | Checkliste |
-| 16 Offene Entscheidungen | Explizit markieren, nicht wegdesignen |
-
-### 2. Optional: `ADP_Template_Blueprint_Scope_Lock_v0.1.md`
-
-Kurzes Scope-Lock-Dokument: Was in Phase 1 **nicht** gebaut wird.
-
-### 3. Bindings-Matrix (Pflicht-Artefakt)
-
-Tabelle mindestens für:
-
-- EFS-Felddefinitionen & Default-Werte  
-- Starter-Kit / Struktur-Presets  
-- `steering_element` UI-Copy & Sichtbarkeit  
-- Composition-Provider (Slot, order, embedded props)  
-- Proposal-UI-Config (`gate_next_actions`, `intake_triage`, …)  
-- Attention-Labels / Severity-Hints  
-- Agent-Slot-Copy  
-- Prompt-Referenzen (key, context_kind, Platzhalter)  
-- Graph-/Gate-Labels, Plan-Outline-Hints  
-- Backlog-Vocabulary-Profil  
-- Journey-Event-Typ-Labels (Darstellung)
-
-Pro Zeile: **Template darf** | **nur System** | **Kernel bleibt Owner**
-
-### 4. Phasenplan AP-BP-1…n
-
-| Phase | Ziel | Abhängigkeit |
-|-------|------|--------------|
-| BP-1 | Read-only System-Blueprints (Seed-Migration) | ADP frei |
-| BP-2 | Anlage: Template wählen + materialisierte Presets | AP2.2a+ |
-| BP-3 | Tenant-Kopie + editierbare Felder/Presets | Tenant-Invariants |
-| BP-4 | Composition + Copy-Bindings | UX Kernel |
-| BP-5 | Prompt/Agent-Bindings | AP2.1 Go |
-| BP-6 | Designer / Import | optional spät |
-
----
-
-## Harte Guardrails (nicht verhandelbar)
-
-- Keine Steuerungslogik in Templates, Routern oder React-Pages  
-- Keine Archetyp-Ifs zur Aktivierung von Panels — nur `steering_elements`, Proposals, Capabilities, Template-Config  
-- Keine neuen OM-Tabellen pro Template-Typ ohne ADP + Scope Lock  
-- Keine hardcodierten Prompts in UI oder Backend-Routern  
-- User ≠ Actor; Tenant-scoped; Auth/Capability/Governance getrennt  
-- Template darf **nicht** `method_key` oder Archetyp-Natur überschreiben (nur kompatible Ausprägung innerhalb des Archetyps)  
-- MVP Stufe A (AP2.1) **nicht** als Blocker für Konzept — Implementierung BP-1+ **nach** AP2.1 unless explizit PO-Minimal-Slice
-
----
-
-## Explizite Abgrenzungen (im Konzept klären)
-
-| Konzept | Abgrenzung zu Blueprint |
-|---------|-------------------------|
-| **Archetyp** | Natur, OM-Capabilities, Default-Methode, Plan/Ist-Vertrag |
-| **Methode** | Steuerungsplugin im Kernel |
-| **Method Profile (heute)** | Dünner Seed-Anker — Blueprint **superset** oder **Rename**? Begründen. |
-| **Starter-Kit** | Materialisierung bei Anlage — Blueprint **liefert** Kit-Definition? |
-| **Structure Builder** | Hook-getriebene Tiefenstruktur — Blueprint **triggert** oder **ersetzt**? |
-| **UX Composition Provider** | Renderer — Blueprint **konfiguriert**, erfindet keine neue Kind-Logik |
-| **Referenz-Ausprägung (Kumite, Kairo Dev)** | Erste System-Blueprints |
-
----
-
-## Qualitätskriterien für das Konzept
-
-Das ADP ist **freigabefähig**, wenn:
-
-- [ ] Ein Entwickler aus §4 + Bindings-Matrix ableiten kann, **welche JSON/YAML-Felder** ein Blueprint hat  
-- [ ] Klar ist, **wo** Template zur Laufzeit aufgelöst wird (neben Operating Context)  
-- [ ] Mindestens **zwei Referenz-Blueprints** (Kumite, Kairo Dev) durch das Modell **differenzierbar** beschrieben sind — ohne neues Steering-Verhalten  
-- [ ] Anti-Patterns aus MVP v0.3 §3 und Method Kernel SK-Regeln **explizit** adressiert sind  
-- [ ] Migrationspfad von `method_profiles/registry.py` dokumentiert ist  
-- [ ] Kein Scope Creep: KI-Produktion, MCP, Designer als **Phasen**, nicht MVP-Blocker  
-- [ ] Konflikte mit ADP Catalog v0.2 / UX Composition v0.1 **aufgelöst oder als Offen markiert**
-
----
-
-## Arbeitsmodus
-
-1. **Nur lesen** — kein Code, keine Migration, kein UI-Patch  
-2. **Zuerst** Begriffe + Bindings-Matrix + Steuerungs-Grenze — dann Persistenz  
-3. **Diagramme:** Schichtenmodell + Auflösungskette (Template + Operating Context → Snapshot → Composition)  
-4. **Offene PO-Fragen** gesammelt am Ende — nicht still entscheiden  
-5. Output-Sprache: **Deutsch**  
-6. Format: Markdown unter `docs/architecture/`  
-7. Bei Widerspruch gilt: Vision v0.2 → COM v0.2 → MVP v0.3 → dieses Prompt-Dokument
-
----
-
-## Referenz-Beispiel (Zielbild, nicht implementieren)
-
-**Blueprint `product.kairo_dev`** auf Archetyp `initiative.product` + Methode `continuous_product`:
-
-- EFS: `product_vision`, `primary_repo_or_system` vorbelegt  
-- Starter: Orientierungs-Gates, Projects Entwicklung/Betrieb, Sample-Backlog „Idea“  
-- Composition: `gate_fulfillment`-Horizont-Copy, Sprint-Hinweis wenn `work_cycle_scope`  
-- Proposals: `intake_triage`-Lead-Text product-spezifisch  
-- Prompt-Ref (später): `kairo.product.triage_hint` — Platzhalter aus Snapshot  
-- **Nicht:** eigene Next-Action-Strategie, kein `critical_path`
-
-**Blueprint `maturity.karate_kumite`** auf A1:
-
-- EFS: `discipline` = Karate  
-- Starter: 8 Skills × Stufen-Presets (Struktur-Seed, nicht 200 Tasks)  
-- Recurring-Presets pro Stufe (Verweis AP2.0e)  
-- Journey-Labels kumite-spezifisch  
-- **Nicht:** Stufenwechsel-Logik im Template — bleibt Kernel/AP2.0e
-
----
-
-## Was nach der Konzeption passiert (nicht Teil dieses Prompts)
-
-- PO-Freigabe ADP  
-- Dann erst: MVP-Stufe-A-Abschluss (AP2.2c, AP1.9d, AP2.1) **parallel oder vor** BP-1 — PO entscheidet  
-- Implementierung AP-BP-1+ gemäß Phasenplan
-
----
-
-*Dieses Dokument ist der **Prompt/Arbeitsauftrag** für AP-BP-0. Ergebnis = ADP v0.1, kein Code.*

docs/product/Kairo_Implementation_Truth_Table_v0.1.md

@@ -156,7 +156,7 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
 
 | Archetyp | Anlage+Kit | Struktur pflegen | Kontrolle | Op-API | Paket |
 |----------|------------|------------------|-----------|--------|-------|
-| A1 Reifegrad | ✓ AP2.2a | ✓ | ✓ | ◐ | AP2.2c ✓ |
+| A1 Reifegrad | ◐ AP2.2a | ◐ | ◐ | ◐ | AP2.2c + AP2.0e |
 | A2 Linear | ✓ AP2.2a | ✓ | ✓ | ◐ | AP2.2b ✓ |
 | B2b Product | ◐ AP2.2a | ◐ | ◐ | ◐ | AP2.2d ✓ |
 | B3 Sprint-Profil | ◐ | ◐ | ◐ | ◐ | AP2.2d ✓ |
@@ -231,7 +231,6 @@ Details: `Kairo_Status_Review_and_Next_Steps_v0.1.md` §2.1
 | ADP Backlog/Epic | P1–P8 ✓ · K-Ext-1/2/3/4/5 ✓ |
 | Steering Kernel Proposals | ✓ | sprint_commit · gate_next_actions · intake_triage (Kernel v0.4) |
 | AP2.2b | A2 Linear E2E ✓ (2026-07-27) |
-| AP2.2c | A1 Reifegrad E2E ✓ (2026-07-27) |
 | AP2.2c–e | Referenz-Archetypen End-to-End ◐→✓ |
 | AP2.1 | MVP-Abnahfe ✗→✓ |
 | AP1.7b | Op-API Parität |

docs/product/Kairo_MVP_Execution_Plan_v0.2.md

@@ -80,7 +80,7 @@ Phase 1   AP2.2a  Archetyp-geführte Anlage + Starter-Kits           ✓
 Phase 1b  Specs Welle 1 finalisieren (A1,A2,B2a,B2b,B3)            ◐
 Phase 2   AP1.9d  Methoden-Default-Ansichten (Anti-Todo-Wand)       ◐ (Hints + Recurring)
 Phase 3   AP2.2b  A2 Linear End-to-End                             ✓
-          AP2.2c  A1 Reifegrad + AP2.0e                            ✓
+          AP2.2c  A1 Reifegrad + AP2.0e                            ◐ Code
           AP2.2d  B2b Product + B3 Sprint                          ✓
           AP2.2e  B2a Programm (optional vor AP2.1)
 Phase 4   AP1.7b  Operational API — Pflege-Parität

frontend/src/components/MaturityStagePanel.jsx

@@ -1,72 +0,0 @@
-import { Link } from 'react-router-dom'
-import { MILESTONE_STATUS_LABELS } from '../constants/status.js'
-import { EmptyState } from './EmptyState.jsx'
-import { scopedPath } from '../utils/routes.js'
-
-export function MaturityStagePanel({
-  initiativeId,
-  roadmapItems = [],
-  embedded = true,
-}) {
-  const stages = [...roadmapItems]
-    .filter((item) => item.item_type === 'maturity_stage')
-    .sort((a, b) => (a.sort_order ?? 0) - (b.sort_order ?? 0))
-
-  const activeStage = stages.find((s) => s.status === 'active')
-
-  const body =
-    stages.length === 0 ? (
-      <EmptyState message="Noch keine Reifegrad-Stufen — unter Plan anlegen oder Starter-Kit nutzen." />
-    ) : (
-      <>
-        {activeStage && (
-          <p className="maturity-stage-active muted">
-            Aktive Stufe: <strong>{activeStage.title}</strong>
-          </p>
-        )}
-        <ol className="item-list maturity-stage-list">
-          {stages.map((stage, index) => (
-            <li
-              key={stage.id}
-              className={
-                'list-item card-list-item maturity-stage-item' +
-                (stage.status === 'active' ? ' maturity-stage-item--active' : '') +
-                (stage.status === 'reached' ? ' maturity-stage-item--reached' : '')
-              }
-            >
-              <span className="maturity-stage-item__index muted">{index + 1}</span>
-              <div className="list-item-main">
-                <strong>{stage.title}</strong>
-                <span className="muted list-item-sub">
-                  {MILESTONE_STATUS_LABELS[stage.status] || stage.status}
-                </span>
-              </div>
-            </li>
-          ))}
-        </ol>
-        <p className="muted maturity-stage-hint">
-          Stufen und Übungen unter{' '}
-          <Link to={scopedPath('/control/journey', { initiativeId })} className="link-inline">
-            Kontrolle → Rhythmen & Journey
-          </Link>
-          .
-        </p>
-      </>
-    )
-
-  if (!embedded) return body
-
-  return (
-    <section className="card maturity-stage-panel">
-      <div className="section-header">
-        <div>
-          <h2>Reifegrad-Stufen</h2>
-          <p className="section-lead muted">
-            Aktive Stufe und Fortschritt — Steuerungshorizont für Reifegrad-Vorhaben (A1).
-          </p>
-        </div>
-      </div>
-      {body}
-    </section>
-  )
-}

frontend/src/components/RecurringRhythmPanel.jsx

@@ -1,84 +0,0 @@
-import { Link } from 'react-router-dom'
-import { RECURRING_STATUS_LABELS } from '../constants/status.js'
-import { EmptyState } from './EmptyState.jsx'
-import { scopedPath } from '../utils/routes.js'
-
-function formatDueAt(iso) {
-  if (!iso) return null
-  try {
-    return new Date(iso).toLocaleString('de-DE')
-  } catch {
-    return iso
-  }
-}
-
-export function RecurringRhythmPanel({
-  initiativeId,
-  recurringItems = [],
-  embedded = true,
-}) {
-  const sorted = [...recurringItems].sort((a, b) => {
-    const statusOrder = { active: 0, paused: 1, archived: 2 }
-    const diff = (statusOrder[a.status] ?? 9) - (statusOrder[b.status] ?? 9)
-    if (diff !== 0) return diff
-    return (a.title || '').localeCompare(b.title || '', 'de')
-  })
-
-  const active = sorted.filter((item) => item.status === 'active')
-
-  const body =
-    sorted.length === 0 ? (
-      <EmptyState message="Noch keine Rhythmen — Starter-Kit oder Journey legt Übungen an." />
-    ) : (
-      <>
-        {active.length > 0 && (
-          <p className="recurring-rhythm-summary muted">
-            {active.length} aktive Routine{active.length === 1 ? '' : 'n'} — fällige Übung steuert
-            Next Action.
-          </p>
-        )}
-        <ul className="item-list recurring-rhythm-list">
-          {sorted.map((item) => (
-            <li
-              key={item.id}
-              className={
-                'list-item card-list-item recurring-rhythm-item' +
-                (item.status === 'active' ? ' recurring-rhythm-item--active' : '')
-              }
-            >
-              <div className="list-item-main">
-                <strong>{item.title}</strong>
-                <span className="muted list-item-sub">
-                  {RECURRING_STATUS_LABELS[item.status] || item.status}
-                  {item.next_due_at ? ` · Fällig: ${formatDueAt(item.next_due_at)}` : ''}
-                </span>
-              </div>
-            </li>
-          ))}
-        </ul>
-        <p className="muted recurring-rhythm-hint">
-          Rhythmen pflegen unter{' '}
-          <Link to={scopedPath('/control/journey', { initiativeId })} className="link-inline">
-            Kontrolle → Journey
-          </Link>
-          .
-        </p>
-      </>
-    )
-
-  if (!embedded) return body
-
-  return (
-    <section className="card recurring-rhythm-panel">
-      <div className="section-header">
-        <div>
-          <h2>Rhythmen & Übungen</h2>
-          <p className="section-lead muted">
-            Aktive Routinen am Reifegrad-Pfad — Leading Next aus fälliger Übung (A1).
-          </p>
-        </div>
-      </div>
-      {body}
-    </section>
-  )
-}

frontend/src/composition/InitiativeCompositionSurface.jsx

@@ -25,8 +25,6 @@ export function InitiativeCompositionSurface({
     () => ({
       initiativeId: ops.initiativeId,
       actions: ops.actions,
-      roadmapItems: ops.roadmapItems,
-      recurringItems: ops.recurringItems,
       steeringSnapshotLoading: ops.steeringSnapshotLoading,
       steeringSnapshotError: ops.steeringSnapshotError,
       steeringMethods: ops.steeringMethods,
@@ -38,8 +36,6 @@ export function InitiativeCompositionSurface({
     [
       ops.initiativeId,
       ops.actions,
-      ops.roadmapItems,
-      ops.recurringItems,
       ops.steeringSnapshotLoading,
       ops.steeringSnapshotError,
       ops.steeringMethods,

frontend/src/composition/compositionProviders.js

@@ -57,26 +57,6 @@ export const COMPOSITION_PROVIDERS = [
     scopeTypes: ['initiative'],
     order: 10,
   },
-  {
-    key: 'steering.maturity_stage',
-    kind: 'steering_element',
-    steeringElement: 'maturity_stage',
-    slotKeys: ['control.status.steering'],
-    componentKey: 'MaturityStagePanel',
-    requiresCapability: 'kairo.initiative.read',
-    scopeTypes: ['initiative'],
-    order: 15,
-  },
-  {
-    key: 'steering.recurring_rhythm',
-    kind: 'steering_element',
-    steeringElement: 'recurring_rhythm',
-    slotKeys: ['control.status.steering'],
-    componentKey: 'RecurringRhythmPanel',
-    requiresCapability: 'kairo.initiative.read',
-    scopeTypes: ['initiative'],
-    order: 16,
-  },
   {
     key: 'steering.next_action',
     kind: 'steering_element',

frontend/src/composition/providerComponents.jsx

@@ -2,8 +2,6 @@ import { Link } from 'react-router-dom'
 import { scopedPath } from '../utils/routes.js'
 import { SteeringSnapshotPanel } from '../components/SteeringSnapshotPanel.jsx'
 import { CriticalPathPanel } from '../components/CriticalPathPanel.jsx'
-import { MaturityStagePanel } from '../components/MaturityStagePanel.jsx'
-import { RecurringRhythmPanel } from '../components/RecurringRhythmPanel.jsx'
 import { AgentSlotsPanel } from '../components/AgentSlotsPanel.jsx'
 import { SteeringProposalsPanel } from '../components/SteeringProposalsPanel.jsx'
 import { NextActionWidget } from '../widgets/NextActionWidget.jsx'
@@ -36,8 +34,6 @@ export function WidgetHost({ widget }) {
 export const PROVIDER_COMPONENTS = {
   SteeringSnapshotPanel,
   CriticalPathPanel,
-  MaturityStagePanel,
-  RecurringRhythmPanel,
   NextActionWidget,
   AgentSlotsPanel,
   SteeringProposalsPanel,

frontend/src/composition/resolveSteeringComposition.js

@@ -77,14 +77,7 @@ function resolveAgentSlots(input) {
  * @param {object | null | undefined} steeringSnapshot
  */
 export function resolveNextActionUi(elements, steeringSnapshot) {
-  const priority = [
-    'critical_path',
-    'recurring_rhythm',
-    'work_cycle_scope',
-    'maturity_stage',
-    'gate_fulfillment',
-    'queue_inbox',
-  ]
+  const priority = ['critical_path', 'work_cycle_scope', 'gate_fulfillment', 'queue_inbox']
   const hasActiveSprint = Boolean(steeringSnapshot?.active_work_cycle)
   for (const key of priority) {
     if (key === 'work_cycle_scope' && !hasActiveSprint) continue
@@ -172,16 +165,6 @@ export function buildProviderProps(provider, input) {
         scopeRoadmapItemId: kernel?.horizon?.gate_roadmap_item_id ?? null,
       }
     }
-    case 'MaturityStagePanel':
-      return {
-        initiativeId: ops.initiativeId,
-        roadmapItems: ops.roadmapItems || [],
-      }
-    case 'RecurringRhythmPanel':
-      return {
-        initiativeId: ops.initiativeId,
-        recurringItems: ops.recurringItems || [],
-      }
     case 'NextActionWidget': {
       const nextActionUi = resolveNextActionUi(elements, input.steeringSnapshot)
       return {

frontend/src/composition/resolveSteeringComposition.test.js

@@ -215,33 +215,7 @@ describe('resolveSteeringComposition', () => {
     expect(props.scopeRoadmapItemId).toBe('gate-1')
   })
 
-  it('activates maturity panels for A1 on control.status', () => {
-    const result = resolveSteeringComposition({
-      surfaceKey: 'control.status',
-      scope: 'initiative',
-      capabilities: CAPS,
-      steeringElements: ['next_action_primary', 'maturity_stage', 'recurring_rhythm'],
-      steeringSnapshot: { counts: {}, next_actions: [] },
-      opsContext: { initiativeId: 'init-1', roadmapItems: [], recurringItems: [] },
-    })
-    const steering = result.slots['control.status.steering'] || []
-    expect(steering.some((p) => p.key === 'steering.maturity_stage')).toBe(true)
-    expect(steering.some((p) => p.key === 'steering.recurring_rhythm')).toBe(true)
-    expect(steering.some((p) => p.key === 'steering.critical_path')).toBe(false)
-  })
-
-  it('buildProviderProps uses recurring rhythm next-action copy', () => {
-    const provider = COMPOSITION_PROVIDERS.find((p) => p.key === 'steering.next_action')
-    const props = buildProviderProps(provider, {
-      steeringElements: ['next_action_primary', 'recurring_rhythm', 'maturity_stage'],
-      steeringSnapshot: { next_actions: [] },
-      opsContext: { initiativeId: 'x', steeringSnapshotLoading: false },
-      capabilities: CAPS,
-    })
-    expect(props.title).toContain('Rhythmus')
-  })
-
-  it('buildProviderProps toggles gate horizon on steering snapshot', () => {
+  it('buildProviderProps gates milestone horizon in snapshot panel', () => {
     const provider = COMPOSITION_PROVIDERS.find((p) => p.key === 'core.steering_snapshot')
     const withGate = buildProviderProps(provider, {
       steeringElements: ['gate_fulfillment', 'next_action_primary'],

frontend/src/registry/steeringElementRegistry.js

@@ -14,15 +14,6 @@ export const STEERING_ELEMENT_UI = {
     nextActionSubtitle:
       'Empfehlung aus dem Sprint-Backlog — Continuous Next außerhalb des Sprints.',
   },
-  recurring_rhythm: {
-    nextActionTitle: 'Heutige Übung / Rhythmus',
-    nextActionSubtitle:
-      'Reifegrad — aktive Routine steuert den nächsten Schritt, nicht die Gesamtliste.',
-  },
-  maturity_stage: {
-    nextActionTitle: 'Nächster Schritt in der Reifegrad-Entwicklung',
-    nextActionSubtitle: 'Aktive Stufe und fällige Übung bestimmen die Empfehlung.',
-  },
   gate_fulfillment: {
     nextActionTitle: 'Nächster sinnvoller Schritt',
     nextActionSubtitle: