docs: Archetyp-Vollspecs und Methodenkern vorlaeufig freigeben.

Decision-Lock, Spec-D-Methoden und C1-Massstab-Vollspecs als Zielbild; Steering-Registry/Compat und Horizon-Tests an die Normierung anbinden. Implementierungsausreichendheit bleibt bewusst offen.

Co-authored-by: Cursor <cursoragent@cursor.com>

backend/method_profiles/registry.py

@@ -39,6 +39,16 @@ METHOD_PROFILES: tuple[dict[str, Any], ...] = (
             "default_actor_setup": "po_plus_vibe_coder",
         },
     },
+    {
+        "key": "project.agile_iteration",
+        "label": "Projekt mit Sprint",
+        "description": "Lineares Projekt (A2) mit optionaler Agile-Iteration.",
+        "initiative_archetype_key": "initiative.linear_project",
+        "method_key": "sequential_dependency",
+        "seed_hints": {
+            "agile_iteration_profile": True,
+        },
+    },
 )
 
 _PROFILE_INDEX = {item["key"]: item for item in METHOD_PROFILES}

backend/services/archetype_starter_kit.py

@@ -22,7 +22,7 @@ _GUIDANCE: dict[str, str] = {
         "Aktuelle Stufe und heutige Übung steuern deinen nächsten Schritt."
     ),
     "initiative.linear_project": (
-        "Nächster Schritt am kritischen Pfad — Abhängigkeiten im Plan-Graph."
+        "Kritischer Pfad und Abhängigkeiten steuern Next — nicht die Gesamtliste."
     ),
     "initiative.product": (
         "Eingang triagieren, dann committete Actions — optional Sprint-Zeitbox (B3)."
@@ -34,7 +34,7 @@ _GUIDANCE: dict[str, str] = {
 
 _PROFILE_HINTS: dict[str, list[str]] = {
     "initiative.maturity_journey": ["maturity.karate_kumite"],
-    "initiative.linear_project": [],
+    "initiative.linear_project": ["project.agile_iteration"],
     "initiative.product": ["product.kairo_dev"],
     "initiative.program": [],
 }
@@ -75,6 +75,7 @@ def get_starter_preview(
             {"kind": "milestone", "title": "G4 — Abschluss", "status": "planned"},
             {"kind": "project", "title": "Hauptpfad"},
             {"kind": "project", "title": "Begleitung"},
+            {"kind": "action", "title": "Erster Schritt — Planung konkretisieren"},
         ]
     elif archetype_key == "initiative.product":
         items = [
@@ -128,6 +129,7 @@ def apply_starter_kit(
         "projects": [],
         "recurring": [],
         "backlog_items": [],
+        "actions": [],
     }
 
     if archetype_key == "initiative.maturity_journey":
@@ -282,9 +284,28 @@ def _apply_a2(
                 user_id=user_id,
             )
 
+    from services.actions import create_action, list_actions_for_initiative
+
+    projects = list_projects_for_initiative(tenant_id=tenant_id, initiative_id=initiative_id)
+    hauptpfad = _find_by_title(projects, "Hauptpfad")
+    actions = list_actions_for_initiative(tenant_id=tenant_id, initiative_id=initiative_id)
+    if not _find_by_title(actions, "Erster Schritt — Planung konkretisieren"):
+        create_action(
+            tenant_id=tenant_id,
+            initiative_id=initiative_id,
+            title="Erster Schritt — Planung konkretisieren",
+            description="Starter-Arbeitspaket am ersten Gate",
+            status="open",
+            roadmap_item_id=gate_ids[0],
+            project_id=hauptpfad["id"] if hauptpfad else None,
+            sort_order=0,
+            user_id=user_id,
+        )
+
     return {
         "roadmap_items": gate_ids,
         "projects": ["Hauptpfad", "Begleitung"],
+        "actions": ["Erster Schritt — Planung konkretisieren"],
     }
 
 

backend/services/operating_context.py

@@ -18,6 +18,7 @@ from steering.graph.profiles import LIGHT, graph_profile_as_dict
 from steering.methods.registry import (
     get_method,
     list_compatible_methods,
+    list_composable_modifiers,
     method_to_dict,
     ui_features_as_dict,
 )
@@ -166,4 +167,32 @@ def get_operating_context(
             om_capabilities=om_capabilities,
             active_method_key=method_key,
         ),
+        "composable_modifiers": [
+            method_to_dict(m, include_compatibility=False)
+            for m in list_composable_modifiers(method_key)
+        ],
+        "active_composition_modifier": (
+            "agile_iteration"
+            if _resolve_active_agile_composition(
+                tenant_id=tenant_id,
+                initiative_id=initiative_id,
+                primary_method_key=method_key,
+            )
+            else None
+        ),
     }
+
+
+def _resolve_active_agile_composition(
+    *,
+    tenant_id: str,
+    initiative_id: str,
+    primary_method_key: str,
+) -> bool:
+    from services.work_cycle import get_active_work_cycle
+    from steering.methods.registry import get_method
+
+    agile = get_method("agile_iteration")
+    if not agile or primary_method_key not in agile.composes_with:
+        return False
+    return get_active_work_cycle(tenant_id=tenant_id, initiative_id=initiative_id) is not None

backend/steering/__init__.py

@@ -22,6 +22,9 @@ def bootstrap_steering() -> None:
     program_delivery.register()
     continuous_product.register()
     ap20_method_stubs.register()
+    from steering.methods.registry import validate_method_registry
+
+    validate_method_registry()
 
 
 bootstrap_steering()

backend/steering/methods/registrations/ap20_method_stubs.py

@@ -32,7 +32,7 @@ def register() -> None:
         description="Graph-Pfade, kritischer Pfad (read model)",
         next_action_strategy_key="sequential_dependency",
         data_slices=SLICES_OM_STANDARD,
-        compatible_archetype_keys="*",
+        compatible_archetype_keys=frozenset({"initiative.linear_project"}),
         steering_elements=ELEM_NEXT
         | frozenset({"critical_path", "gate_fulfillment"}),
         ui_features=frozenset({"criticalPathControl"}),
@@ -50,26 +50,38 @@ def register() -> None:
     )
     register_stub_method(
         key="queue_pull",
-        label="Inbox / Queue",
-        description="Pull oder Empfehlung aus Queue",
+        label="Inbox / Queue (Legacy)",
+        description="Pull oder Empfehlung aus Queue — abgelöst durch checklist_flow",
         next_action_strategy_key="queue_pull",
         data_slices=SLICES_QUEUE,
-        compatible_archetype_keys="*",
+        compatible_archetype_keys=frozenset({"initiative.support_queue"}),
         steering_elements=ELEM_NEXT | frozenset({"queue_inbox"}),
         graph_profile=LIGHT,
     )
     register_stub_method(
         key="agile_iteration",
         label="Iterations-Zeitbox",
-        description="Sprint/work_cycle Profil auf Product/Programm",
+        description="Sprint/work_cycle Profil — komponiert mit Primary-Methoden",
         next_action_strategy_key="agile_iteration",
         data_slices=SLICES_AGILE,
-        compatible_archetype_keys="*",
+        compatible_archetype_keys=frozenset(
+            {
+                "initiative.linear_project",
+                "initiative.product",
+                "initiative.recurring_program",
+            }
+        ),
         steering_elements=ELEM_NEXT | frozenset({"work_cycle_scope"}),
         ui_features=frozenset({"steeringSnapshotOnWorkSprint"}),
         graph_profile=STRICT,
         method_role="modifier",
-        composes_with=frozenset({"continuous_product", "program_delivery"}),
+        composes_with=frozenset(
+            {
+                "continuous_product",
+                "sequential_dependency",
+                "recurring_control",
+            }
+        ),
     )
     register_stub_method(
         key="dispute_procedure",

backend/steering/methods/registrations/product_milestone_driven.py

@@ -38,8 +38,6 @@ def register() -> None:
                 {
                     "initiative.product",
                     "initiative.generic",
-                    "initiative.linear_project",
-                    "initiative.program",
                 }
             ),
             steering_elements=ELEM_NEXT | frozenset({"gate_fulfillment"}),

backend/steering/methods/registry.py

@@ -66,9 +66,44 @@ def register_method(defn: MethodDefinition) -> None:
         raise ValueError(f"Method already registered: {defn.key}")
     if defn.steering_elements:
         validate_steering_element_keys(defn.steering_elements)
+    if defn.method_role == "modifier" and not defn.composes_with:
+        raise ValueError(
+            f"Modifier method {defn.key} must declare composes_with primary keys"
+        )
     _METHODS[defn.key] = defn
 
 
+def validate_method_registry() -> None:
+    """Post-bootstrap: strategy keys exist; composes_with targets are primary methods."""
+    from steering.strategies.next_action.registry import get_next_action_strategy
+
+    for method in _METHODS.values():
+        strategy_key = method.next_action_strategy_key
+        if strategy_key != "default" and not get_next_action_strategy(strategy_key):
+            raise ValueError(
+                f"Method {method.key} references unknown next_action_strategy: {strategy_key}"
+            )
+        for primary_key in method.composes_with:
+            primary = get_method(primary_key)
+            if not primary:
+                raise ValueError(
+                    f"Method {method.key} composes_with unknown method: {primary_key}"
+                )
+            if primary.method_role != "primary":
+                raise ValueError(
+                    f"Method {method.key} composes_with non-primary method: {primary_key}"
+                )
+
+
+def list_composable_modifiers(primary_method_key: str) -> tuple[MethodDefinition, ...]:
+    """Modifier methods that may compose with the given primary method."""
+    return tuple(
+        m
+        for m in _METHODS.values()
+        if m.method_role == "modifier" and primary_method_key in m.composes_with
+    )
+
+
 def get_method(key: str) -> MethodDefinition | None:
     return _METHODS.get(key)
 

backend/steering/signals/engine.py

@@ -25,6 +25,13 @@ def _resolve_method_key(ctx: TenantContext, initiative_id: str | None) -> str:
     return "generic_operating"
 
 
+def _primary_composes_with_agile(method_key: str) -> bool:
+    agile = get_method("agile_iteration")
+    if not agile:
+        return False
+    return method_key in agile.composes_with
+
+
 def _resolve_next_action_strategy_key(
     ctx: TenantContext, initiative_id: str | None
 ) -> str:
@@ -37,7 +44,7 @@ def _resolve_next_action_strategy_key(
     from services.work_cycle import get_active_work_cycle
 
     active = get_active_work_cycle(tenant_id=ctx.tenant_id, initiative_id=initiative_id)
-    if active and strategy_key == "continuous_product":
+    if active and _primary_composes_with_agile(method_key):
         agile = get_next_action_strategy("agile_iteration")
         if agile:
             return agile.key

backend/steering/strategies/next_action/agile_iteration.py

@@ -1,19 +1,16 @@
-"""Agile iteration NextAction strategy — AP2.0f (active work_cycle first)."""
+"""Agile iteration NextAction strategy — Komposition (Primary ∩ Sprint)."""
 
 from __future__ import annotations
 
 from typing import Any
 
-from steering.signals import default_rules
-from steering.strategies.next_action.continuous_product import (
-    ContinuousProductStrategy,
-)
+from steering.methods.registry import get_method
 from steering.strategies.next_action.default_strategy import DefaultNextActionStrategy
 from steering.strategies.next_action.execution_ready import (
-    blocked_execution_action_ids,
     build_execution_ready_candidates,
-    list_execution_ready_candidates,
-    merge_candidates,
+    filter_actions_for_work_cycle,
+    gate_horizon_scope_for_method,
+    resolve_initiative_method_key,
 )
 from steering.strategies.next_action.registry import (
     get_next_action_strategy,
@@ -23,7 +20,13 @@ from services.work_cycle import get_active_work_cycle
 from tenant_context import TenantContext
 
 _default = DefaultNextActionStrategy()
-_continuous = ContinuousProductStrategy()
+
+
+def _primary_strategy_for_initiative(ctx: TenantContext, initiative_id: str):
+    method_key = resolve_initiative_method_key(ctx, initiative_id)
+    method = get_method(method_key)
+    strategy_key = method.next_action_strategy_key if method else _default.key
+    return get_next_action_strategy(strategy_key) or _default
 
 
 class AgileIterationStrategy:
@@ -41,59 +44,55 @@ class AgileIterationStrategy:
         if not initiative_id:
             return _default.evaluate(ctx, limit=limit)
 
+        primary = _primary_strategy_for_initiative(ctx, initiative_id)
         active = get_active_work_cycle(
             tenant_id=ctx.tenant_id, initiative_id=initiative_id
         )
         if not active:
-            return _continuous.evaluate(ctx, initiative_id=initiative_id, limit=limit)
+            return primary.evaluate(ctx, initiative_id=initiative_id, limit=limit)
+
+        primary_key = resolve_initiative_method_key(ctx, initiative_id)
+        gate_scope = gate_horizon_scope_for_method(primary_key, ctx, initiative_id)
+        cycle_id = str(active["id"])
 
-        cycle_id = active["id"]
         from services import actions as action_service
         from steering.graph.execution_engine import load_initiative_execution_graph_state
 
         actions = action_service.list_actions_for_initiative(
             tenant_id=ctx.tenant_id, initiative_id=initiative_id
         )
-        cycle_actions = [
-            a for a in actions if str(a.get("work_cycle_id") or "") == cycle_id
+        scoped = filter_actions_for_work_cycle(actions, work_cycle_id=cycle_id)
+        if gate_scope:
+            scope = str(gate_scope)
+            scoped = [
+                a
+                for a in scoped
+                if a.get("roadmap_item_id") and str(a["roadmap_item_id"]) == scope
             ]
-        if not cycle_actions:
-            ready = list_execution_ready_candidates(
-                ctx, initiative_id, limit=limit, prefer_critical_path=True
-            )
-            if ready:
-                return ready[:limit]
-            return _continuous.evaluate(ctx, initiative_id=initiative_id, limit=limit)
+
+        if not scoped:
+            return []
 
         graph_state = load_initiative_execution_graph_state(
             tenant_id=ctx.tenant_id,
             initiative_id=initiative_id,
+            scope_roadmap_item_id=gate_scope,
         )
-        blocked_ids = blocked_execution_action_ids(ctx, initiative_id)
         ready = build_execution_ready_candidates(
-            actions=cycle_actions,
+            actions=scoped,
             graph_state=graph_state,
             limit=limit,
             prefer_critical_path=True,
         )
         for item in ready:
             item["reason_code"] = "work_cycle_ready"
-            item["summary"] = f"Aktive Zeitbox „{active['title']}“ — ausführungsbereit"
+            item["summary"] = (
+                f"Aktive Zeitbox „{active['title']}“ — ausführungsbereit im Horizont"
+            )
             item["recommended_action"] = "In dieser Iteration ausführen"
 
-        if len(ready) >= limit:
         return ready[:limit]
 
-        rest = _continuous.evaluate(
-            ctx, initiative_id=initiative_id, limit=limit - len(ready)
-        )
-        filtered = [
-            item
-            for item in rest
-            if not item.get("action_id") or item["action_id"] not in blocked_ids
-        ]
-        return merge_candidates(ready, filtered, limit=limit, exclude_action_ids=blocked_ids)
-
 
 agile_iteration_strategy = AgileIterationStrategy()
 

backend/steering/strategies/next_action/execution_ready.py

@@ -184,7 +184,9 @@ def first_active_gate_id(ctx: TenantContext, initiative_id: str) -> str | None:
                 JOIN roadmaps r ON r.id = ri.roadmap_id AND r.tenant_id = ri.tenant_id
                 WHERE ri.tenant_id = %s AND r.initiative_id = %s
                   AND ri.status = 'active'
-                ORDER BY ri.target_date ASC NULLS LAST, ri.updated_at DESC
+                ORDER BY ri.sort_order ASC NULLS LAST,
+                         ri.target_date ASC NULLS LAST,
+                         ri.updated_at DESC
                 LIMIT 1
                 """,
                 (ctx.tenant_id, initiative_id),
@@ -193,3 +195,32 @@ def first_active_gate_id(ctx: TenantContext, initiative_id: str) -> str | None:
             return str(row["id"]) if row else None
     finally:
         conn.close()
+
+
+def resolve_initiative_method_key(ctx: TenantContext, initiative_id: str) -> str:
+    from services import steering_context as sc_service
+
+    row = sc_service.get_steering_context(
+        tenant_id=ctx.tenant_id, initiative_id=initiative_id
+    )
+    if row:
+        return row["method_key"]
+    return "generic_operating"
+
+
+def gate_horizon_scope_for_method(method_key: str, ctx: TenantContext, initiative_id: str) -> str | None:
+    """Plan-Horizont (aktives Gate) für gate-geführte Primary-Methoden."""
+    if method_key in (
+        "sequential_dependency",
+        "program_delivery",
+        "maturity_progression",
+    ):
+        return first_active_gate_id(ctx, initiative_id)
+    return None
+
+
+def filter_actions_for_work_cycle(
+    actions: list[dict[str, Any]], *, work_cycle_id: str
+) -> list[dict[str, Any]]:
+    cycle = str(work_cycle_id)
+    return [a for a in actions if str(a.get("work_cycle_id") or "") == cycle]

backend/steering/strategies/next_action/sequential_dependency.py

@@ -1,14 +1,13 @@
-"""Sequential dependency NextAction strategy — AP2.0d."""
+"""Sequential dependency NextAction strategy — AP2.0d / Spec-D D6."""
 
 from __future__ import annotations
 
 from typing import Any
 
-from steering.signals import default_rules
 from steering.strategies.next_action.default_strategy import DefaultNextActionStrategy
 from steering.strategies.next_action.execution_ready import (
+    first_active_gate_id,
     list_execution_ready_candidates,
-    merge_candidates,
 )
 from steering.strategies.next_action.registry import (
     get_next_action_strategy,
@@ -34,30 +33,16 @@ class SequentialDependencyStrategy:
         if not initiative_id:
             return _default.evaluate(ctx, limit=limit)
 
+        gate_scope = first_active_gate_id(ctx, initiative_id)
         ready = list_execution_ready_candidates(
             ctx,
             initiative_id,
             limit=limit,
+            scope_roadmap_item_id=gate_scope,
             prefer_critical_path=True,
         )
-        if len(ready) >= limit:
         return ready[:limit]
 
-        from steering.strategies.next_action.execution_ready import (
-            blocked_execution_action_ids,
-        )
-
-        rest = default_rules.get_next_action_candidates_for_initiative(
-            ctx, initiative_id=initiative_id, limit=limit - len(ready)
-        )
-        blocked_ids = blocked_execution_action_ids(ctx, initiative_id)
-        filtered = [
-            item
-            for item in rest
-            if not item.get("action_id") or item["action_id"] not in blocked_ids
-        ]
-        return merge_candidates(ready, filtered, limit=limit)
-
 
 sequential_dependency_strategy = SequentialDependencyStrategy()
 

backend/tests/test_ap22a_starter_kit.py

@@ -86,6 +86,32 @@ def test_create_initiative_b2b_starter_kit(client):
     assert "Betrieb" in titles
 
 
+def test_create_initiative_a2_starter_kit_includes_action(client):
+    user = provision_user_in_tenant(tenant_role="admin")
+    token = _login(client, user)
+
+    created = client.post(
+        "/api/initiatives",
+        json={
+            "title": "Test Projekt",
+            "archetype_key": "initiative.linear_project",
+        },
+        headers=_auth(token),
+    )
+    assert created.status_code == 201
+    initiative_id = created.json()["id"]
+    assert created.json()["starter_kit"]["applied"] is True
+
+    actions = client.get(
+        f"/api/initiatives/{initiative_id}/actions",
+        headers=_auth(token),
+    )
+    assert actions.status_code == 200
+    assert any(
+        a["title"] == "Erster Schritt — Planung konkretisieren" for a in actions.json()
+    )
+
+
 def test_starter_kit_skipped_when_structure_exists(client):
     user = provision_user_in_tenant(tenant_role="admin")
     token = _login(client, user)

backend/tests/test_ap22c_sequential_horizon.py

@@ -0,0 +1,188 @@
+"""AP2.2c — A2 sequential_dependency: Gate-Horizont + Agile-Komposition."""
+
+from __future__ import annotations
+
+from tests.factories import provision_user_in_tenant
+from tests.test_initiatives_actions import _auth, _create_initiative, _login
+
+
+def _gate_ids(client, token, initiative_id):
+    roadmap = client.get(
+        f"/api/initiatives/{initiative_id}/roadmap/items",
+        headers=_auth(token),
+    )
+    assert roadmap.status_code == 200
+    items = roadmap.json()
+    active = next(i for i in items if i.get("status") == "active")
+    planned = next(i for i in items if i.get("title", "").startswith("G2"))
+    return active["id"], planned["id"]
+
+
+def test_sequential_next_action_only_in_active_gate_horizon(client):
+    user = provision_user_in_tenant(tenant_role="admin")
+    token = _login(client, user)
+
+    created = _create_initiative(
+        client,
+        token,
+        title="Horizon Test",
+        archetype_key="initiative.linear_project",
+    )
+    initiative_id = created.json()["id"]
+    g1_id, g2_id = _gate_ids(client, token, initiative_id)
+
+    off_horizon = client.post(
+        f"/api/initiatives/{initiative_id}/actions",
+        json={
+            "title": "Außerhalb Horizont",
+            "status": "open",
+            "roadmap_item_id": g2_id,
+            "sort_order": 0,
+        },
+        headers=_auth(token),
+    )
+    on_horizon = client.post(
+        f"/api/initiatives/{initiative_id}/actions",
+        json={
+            "title": "Im aktiven Gate",
+            "status": "open",
+            "roadmap_item_id": g1_id,
+            "sort_order": 1,
+        },
+        headers=_auth(token),
+    )
+    assert off_horizon.status_code == 201 and on_horizon.status_code == 201
+
+    snap = client.get(
+        f"/api/initiatives/{initiative_id}/steering-snapshot",
+        headers=_auth(token),
+    )
+    assert snap.status_code == 200
+    next_actions = snap.json().get("next_actions") or []
+    assert next_actions
+    next_ids = {n.get("action_id") for n in next_actions}
+    assert off_horizon.json()["id"] not in next_ids
+    assert on_horizon.json()["id"] in next_ids
+
+
+def test_agile_on_linear_delegates_primary_without_active_sprint(client):
+    user = provision_user_in_tenant(tenant_role="admin")
+    token = _login(client, user)
+
+    created = _create_initiative(
+        client,
+        token,
+        title="Agile Primary",
+        archetype_key="initiative.linear_project",
+    )
+    initiative_id = created.json()["id"]
+    g1_id, _ = _gate_ids(client, token, initiative_id)
+
+    action = client.post(
+        f"/api/initiatives/{initiative_id}/actions",
+        json={
+            "title": "Gate Action",
+            "status": "open",
+            "roadmap_item_id": g1_id,
+        },
+        headers=_auth(token),
+    )
+    assert action.status_code == 201
+
+    snap = client.get(
+        f"/api/initiatives/{initiative_id}/steering-snapshot",
+        headers=_auth(token),
+    )
+    assert snap.status_code == 200
+    assert snap.json().get("active_work_cycle") is None
+    next_actions = snap.json().get("next_actions") or []
+    assert next_actions[0]["action_id"] == action.json()["id"]
+    assert next_actions[0]["reason_code"] in (
+        "execution_ready",
+        "execution_critical_path",
+    )
+
+
+def test_agile_on_linear_sprint_intersects_gate_horizon(client):
+    user = provision_user_in_tenant(tenant_role="admin")
+    token = _login(client, user)
+
+    created = _create_initiative(
+        client,
+        token,
+        title="Sprint Horizon",
+        archetype_key="initiative.linear_project",
+    )
+    initiative_id = created.json()["id"]
+    g1_id, _ = _gate_ids(client, token, initiative_id)
+
+    cycle = client.post(
+        f"/api/initiatives/{initiative_id}/work-cycles",
+        json={"title": "Montage-Woche", "status": "active"},
+        headers=_auth(token),
+    )
+    assert cycle.status_code == 201
+    cycle_id = cycle.json()["id"]
+
+    outside_sprint = client.post(
+        f"/api/initiatives/{initiative_id}/actions",
+        json={
+            "title": "Nur Gate",
+            "status": "open",
+            "roadmap_item_id": g1_id,
+        },
+        headers=_auth(token),
+    )
+    in_sprint = client.post(
+        f"/api/initiatives/{initiative_id}/actions",
+        json={
+            "title": "Im Sprint",
+            "status": "ready",
+            "roadmap_item_id": g1_id,
+            "work_cycle_id": cycle_id,
+        },
+        headers=_auth(token),
+    )
+    assert outside_sprint.status_code == 201 and in_sprint.status_code == 201
+
+    snap = client.get(
+        f"/api/initiatives/{initiative_id}/steering-snapshot",
+        headers=_auth(token),
+    )
+    assert snap.status_code == 200
+    assert snap.json().get("active_work_cycle")
+    next_actions = snap.json().get("next_actions") or []
+    assert next_actions
+    assert next_actions[0]["action_id"] == in_sprint.json()["id"]
+    assert next_actions[0]["reason_code"] == "work_cycle_ready"
+
+
+def test_operating_context_active_composition_modifier_with_sprint(client):
+    user = provision_user_in_tenant(tenant_role="member")
+    token = _login(client, user)
+
+    created = _create_initiative(
+        client,
+        token,
+        title="Composition Flag",
+        archetype_key="initiative.linear_project",
+    )
+    initiative_id = created.json()["id"]
+
+    ctx_before = client.get(
+        f"/api/initiatives/{initiative_id}/operating-context",
+        headers=_auth(token),
+    )
+    assert ctx_before.json().get("active_composition_modifier") is None
+
+    client.post(
+        f"/api/initiatives/{initiative_id}/work-cycles",
+        json={"title": "S1", "status": "active"},
+        headers=_auth(token),
+    )
+
+    ctx_after = client.get(
+        f"/api/initiatives/{initiative_id}/operating-context",
+        headers=_auth(token),
+    )
+    assert ctx_after.json().get("active_composition_modifier") == "agile_iteration"

backend/tests/test_ap23e_method_compatibility.py

@@ -6,7 +6,28 @@ from tests.factories import provision_user_in_tenant
 from tests.test_initiatives_actions import _auth, _create_initiative, _login
 
 
-def test_update_method_queue_pull_on_linear_ok(client):
+def test_update_method_queue_pull_on_support_queue_ok(client):
+    user = provision_user_in_tenant(tenant_role="member")
+    token = _login(client, user)
+
+    created = _create_initiative(
+        client,
+        token,
+        title="Queue Override",
+        archetype_key="initiative.support_queue",
+    )
+    initiative_id = created.json()["id"]
+
+    res = client.patch(
+        f"/api/steering/initiatives/{initiative_id}/context",
+        json={"method_key": "queue_pull"},
+        headers=_auth(token),
+    )
+    assert res.status_code == 200
+    assert res.json()["method_key"] == "queue_pull"
+
+
+def test_update_method_queue_pull_on_linear_rejected(client):
     user = provision_user_in_tenant(tenant_role="member")
     token = _login(client, user)
 
@@ -23,8 +44,8 @@ def test_update_method_queue_pull_on_linear_ok(client):
         json={"method_key": "queue_pull"},
         headers=_auth(token),
     )
-    assert res.status_code == 200
-    assert res.json()["method_key"] == "queue_pull"
+    assert res.status_code == 400
+    assert "kompatibel" in res.json()["detail"].lower()
 
 
 def test_update_method_maturity_on_product_rejected(client):
@@ -55,8 +76,8 @@ def test_operating_context_reflects_method_slice_intersection(client):
     created = _create_initiative(
         client,
         token,
-        title="Queue Linear",
-        archetype_key="initiative.linear_project",
+        title="Queue Support",
+        archetype_key="initiative.support_queue",
     )
     initiative_id = created.json()["id"]
 

backend/tests/test_ap24_steering_elements.py

@@ -30,11 +30,33 @@ def test_continuous_product_ui_features_from_method():
     assert features["steeringSnapshotOnWorkSprint"] is True
 
 
-def test_list_compatible_methods_linear_includes_queue_pull():
+def test_list_compatible_methods_linear_excludes_queue_pull():
     methods = list_compatible_methods("initiative.linear_project")
     keys = {m.key for m in methods}
     assert "sequential_dependency" in keys
-    assert "queue_pull" in keys
+    assert "queue_pull" not in keys
+    assert "agile_iteration" not in keys  # modifier, not primary switch target
+
+
+def test_agile_iteration_composes_with_matrix():
+    method = get_method("agile_iteration")
+    assert method is not None
+    assert method.composes_with == frozenset(
+        {
+            "continuous_product",
+            "sequential_dependency",
+            "recurring_control",
+        }
+    )
+    assert "program_delivery" not in method.composes_with
+
+
+def test_list_composable_modifiers_for_linear():
+    from steering.methods.registry import list_composable_modifiers
+
+    modifiers = list_composable_modifiers("sequential_dependency")
+    assert len(modifiers) == 1
+    assert modifiers[0].key == "agile_iteration"
 
 
 def test_list_compatible_methods_product_excludes_maturity():
@@ -101,32 +123,43 @@ def test_steering_methods_filtered_by_archetype(client):
     assert product["is_default"] is True
 
 
-def test_queue_pull_on_linear_changes_steering_elements(client):
-    from tests.factories import provision_user_in_tenant
-    from tests.test_initiatives_actions import _auth, _create_initiative, _login
-
+def test_queue_pull_rejected_on_linear(client):
     user = provision_user_in_tenant(tenant_role="member")
     token = _login(client, user)
 
     created = _create_initiative(
         client,
         token,
-        title="Linear Queue",
+        title="Linear Block Queue",
         archetype_key="initiative.linear_project",
     )
     initiative_id = created.json()["id"]
 
-    client.patch(
+    res = client.patch(
         f"/api/steering/initiatives/{initiative_id}/context",
         json={"method_key": "queue_pull"},
         headers=_auth(token),
     )
+    assert res.status_code == 400
+    assert "kompatibel" in res.json()["detail"].lower()
+
+
+def test_operating_context_composable_modifiers_linear(client):
+    user = provision_user_in_tenant(tenant_role="member")
+    token = _login(client, user)
+
+    created = _create_initiative(
+        client,
+        token,
+        title="Linear Modifiers",
+        archetype_key="initiative.linear_project",
+    )
+    initiative_id = created.json()["id"]
 
     ctx = client.get(
         f"/api/initiatives/{initiative_id}/operating-context",
         headers=_auth(token),
     )
-    body = ctx.json()
-    assert "queue_inbox" in body["steering_elements"]
-    assert "critical_path" not in body["steering_elements"]
-    assert body["ui_features"].get("criticalPathControl") is not True
+    assert ctx.status_code == 200
+    modifiers = ctx.json().get("composable_modifiers") or []
+    assert any(m["key"] == "agile_iteration" for m in modifiers)

docs/architecture/ADP_Archetype_and_Method_Catalog_v0.2.md

@@ -1,11 +1,16 @@
 # ADP — Archetyp- & Methoden-Katalog v0.2
 
-**Status:** PO-freigegeben  
+**Status:** PO-freigegeben — **Inventar teilweise überholt** (2026-07-25)  
 **Stand:** 2026-07-10 (Archetypen-, Project- und Methoden-Schichten; Vier-Schichten-Modell)  
+**Aktuelles Inventar / Decision-Lock:** `docs/product/Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`  
+**Nächste Katalog-Konsolidierung:** v0.3 nach Methoden-Normierung (`Kairo_Steering_Method_Normalization_Program_v0.1.md`)  
+**Architektur-Voraussetzung:** `ADP_Archetype_Method_Plugin_Architecture_v0.1.md`, `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`  
 **Bezug:** `Kairo_MVP_Definition_v0.3.md`, `ADP_AP1_10_Initiative_Archetypes_and_Entity_Field_System_v0.1.md`, `Kairo_Method_Design_Principles_v0.1.md`, `Kairo_Canonical_Operating_Model_v0.2.md`  
 **Ersetzt:** `ADP_Archetype_and_Method_Catalog_v0.1.md` (Inhalt konsolidiert + B3 Agile Iteration)  
 **Auslöser:** Vorhaben jenseits von Software; heterogenes Portfolio; **Agile (Backlog, Sprint, Release)** vollständig im Katalog verankern
 
+> **Hinweis 2026-07-25:** D1 als eigener Archetyp, B1-Label und fehlendes Care sind im Decision-Lock korrigiert. Bei Konflikt gilt das Decision-Lock; dieses v0.2 bleibt Referenz für Vier-Schichten und historische Begründung.
+
 ---
 
 ## 1. Problem

docs/architecture/Kairo_Steering_Method_Contract_Fachlich_v0.1.md

@@ -0,0 +1,117 @@
+# Jinkendo Kairo
+## Steuerungsmethoden — Fachlicher Kern & Contract v0.1 (M1 reframed)
+
+**Status:** Entwurf — Phase M1 **umgebogen** (Kern zuerst, nicht Spec-Formular)  
+**Stand:** 2026-07-25  
+**Programm:** `Kairo_Steering_Method_Normalization_Program_v0.1.md`  
+**Nordstern:** `Kairo_Target_Architecture_Method_Driven_Adaptive_Steering_Core_v0.1.md`  
+**Prinzipien:** `Kairo_Method_Design_Principles_v0.1.md`  
+**Technik:** `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`  
+**Archetypen:** `Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`
+
+---
+
+## 0. Kurskorrektur
+
+**Verworfen als Einstieg:** 10 Spec-Felder + Primitive-Stichliste (zu früh, MVP-verkürzt).
+
+**Neuer M1-Pfad:**
+
+```text
+1) Methodenkern (invariant) — Steuerungszyklus, Lifecycle, Core vs Methode
+2) Extension Points — Hooks, Strategies, Builder, Policies
+3) Gemeinsame Primitive / Read Models
+4) Methoden-Deltas (Besonderheiten)
+5) Archetyp × Methode
+6) Spec-Template (abgeleitet)
+```
+
+Spec-Tiefe = holistisch. Implementierungstiefe später MVP.
+
+---
+
+## 1. Methodenkern — Arbeitsstand
+
+### 1.1 Leitfrage (unverändert)
+
+> Welcher nächste Schritt bringt ein Vorhaben aktuell am wirkungsvollsten voran — und warum?
+
+### 1.2 Steuerungszyklus (Kandidat — aus Target Architecture)
+
+```text
+intake → method_selection → structure_setup → planning → action_selection
+  → assignment → waiting → result_intake → validation → review
+  → adaptation → closure
+```
+
+| Schritt | Core (invariant) | Methode (Extension) |
+|---------|------------------|---------------------|
+| intake | SteeringContext, Ziel/Scope | zusätzliche Hooks |
+| method_selection | Registry, Kompatibilität zu Archetyp | Domain-Filter, Default |
+| structure_setup | Hook-Dispatch, Builder-Interface | welche Structure Builder |
+| planning | Transition, Audit | DoD/Plan-Dichte-Policy |
+| action_selection | Signal-/NextAction-Orchestrierung | Next-Action-Strategy |
+| assignment | Actor-Validierung, Assignment-Service | Assignment-Strategy |
+| waiting | Wartezustand (Runtime später) | Waiting/Reminder/Escalation |
+| result_intake | Ergebnis entgegennehmen | Intake-Strategy |
+| validation | Evidence/DoD-Checks anstoßen | Evidence-Policy |
+| review | Review-Objekt | Review-Strategy |
+| adaptation | Replan-Hooks | Structure-/Method-Adjustment |
+| closure | Closure-Policy aufrufen | ob/wann Closure sinnvoll |
+
+**Regel (Kandidat):** Methode darf Schritte **auslassen/spezialisieren**, nicht Tenant/Actor/Capability/OM-Kern umgehen.
+
+**Analyse:** `M1_Lifecycle_Fit_Analysis_Archetypes_v0.1.md` — Lifecycle allein **nicht hinreichend**; siehe §5 dort (Kern-Anker A–G).
+
+*(PO-Bestätigung: Interview M1.1 — reframed nach Analyse)*
+
+### 1.3 Core vs. Methode vs. Archetyp (Kandidat)
+
+| | Core | Methode | Archetyp |
+|--|------|---------|----------|
+| Rolle | Orchestrierung, Invarianten, Registries | Steuerungsverhalten | Natur/Horizont/UI-Hülle/OM-Fähigkeiten |
+| Persistenz | OM + SteeringContext | nutzt OM, keine Parallelwelt | `archetype_key`, ui_profile, om_capabilities |
+| UI Verhalten Work/Control | Element-Registry auflösen | `steering_elements`, `ui_features` | Nav/Routen/Outline |
+| Next Action | Engine ruft Strategy | liefert Strategy | begrenzt über om_capabilities |
+
+### 1.4 Extension Points (Kandidat — Pflicht vs. optional)
+
+| Extension | Pflicht primary? | Bemerkung |
+|-----------|------------------|-----------|
+| `next_action_strategy` | **ja** | Kern der Leitfrage |
+| `attention` / signal rules | **ja** (min. leer explizit) | Portfolio + Vorhaben |
+| `compatible_archetype_keys` + `data_slices` | **ja** | AP2.4 |
+| `steering_elements` | **ja** (min. `next_action_primary`) | AP2.4 |
+| `lifecycle_steps` aktiv/skip | **ja** | welche Schritte gelten |
+| Structure Builder | empfohlen | sonst manuelle Struktur |
+| assignment / waiting / reminder / escalation | optional | Default-Core |
+| evidence / review / closure policy | optional bis nötig | |
+| Hook-Bindings über Standard-Slugs | empfohlen | stabil versioniert |
+| `agile_iteration` als modifier | nur Komposition | kein primary Ersatz |
+
+---
+
+## 2. Primitive — später (nach Kern)
+
+Arbeitsliste unverändert als Kandidaten; Definition **nach** M1.1–M1.3.
+
+---
+
+## 3. Spec-Formular (10 Punkte) — später
+
+Wird **abgeleitet** aus Kern + Extensions — nicht Einstieg.
+
+---
+
+## 4. Interview-Log
+
+| ID | Thema | Entscheidung |
+|----|-------|--------------|
+| — | Kurskorrektur Kern zuerst | ✓ A (2026-07-25) |
+| — | Lifecycle allein hinreichend? | ✗ Analyse — Anker nötig |
+| M1-Pfad | Hybrid A1 | ✓ (2026-07-25): Kandidat-Kern → Tiefe D → Freeze |
+| Prozess | | `M1_Hybrid_Path_and_Depth_D_v0.1.md` |
+
+---
+
+*Living document.*

docs/architecture/Kairo_Steering_Method_Kernel_v0.1.md

@@ -0,0 +1,215 @@
+# Jinkendo Kairo
+## Universeller Steuerungsmethoden-Kern v0.1
+
+**Status:** PO-freigegeben (Freeze M1c) — 2026-07-25  
+**Zweck:** Fachlich universeller Kern für **alle** Steuerungsmethoden  
+**Nicht:** Archetyp-Katalog (→ Decision-Lock) · keine offene Workflow-Engine  
+**Voraussetzung Technik:** AP2.3/AP2.4 Plugin-Architektur  
+**Abgeleitet aus:** Spec-Tiefe D (`docs/architecture/methods/SPEC_D_*.md`), Fit-Analyse, Target Architecture Lifecycle
+
+---
+
+## 1. Was dieser Kern ist
+
+Der **Steuerungsmethoden-Kern** ist die **eine gemeinsame Maschine**, mit der Kairo jedes Vorhaben steuert — unabhängig von der Methode.
+
+Methoden sind **Steuerungspakete**: sie füllen feste Schlitze (Strategien, Policies, Skip-Regeln).  
+Sie bauen **keine** zweite Engine daneben.
+
+```text
+SteeringContext (Vorhaben + gebundene primary-Methode [+ Komposition])
+        │
+        ▼
+┌─────────────────────────────────────────────────────────┐
+│         UNIVERSALER STEUERUNGSMETHODEN-KERN             │
+│                                                         │
+│   Auslöser:  Plan-Zug  und/oder  Event-Schub            │
+│   Schlitze:  Intake … Closure (unten)                   │
+│   Querschnitt: Horizont · Attention · Audit · Nested    │
+└─────────────────────────────────────────────────────────┘
+        │
+        ▼
+   Method Plugin (sequential_dependency, care_navigation, …)
+```
+
+**Leitfrage (unverändert):**  
+*Welcher nächste Schritt bringt das Vorhaben jetzt am wirkungsvollsten voran — und warum?*
+
+---
+
+## 2. Explizit nicht
+
+| Nicht | Stattdessen |
+|-------|-------------|
+| Offene Workflow-/Plugin-Engine (beliebige Nodes) | Feste Schlitze + Method Registry |
+| Eine Engine pro Vorhaben-Typ | Ein Kern, Methoden spezialisieren |
+| Nur Plan-Pipeline ohne Events | Dualer Auslöser |
+| Nur Action als „nächste Arbeit“ | Polymorphes Work Item |
+| Programm überschreibt Child-NA | Nested: Impulse ≠ Child-NA |
+
+PO ✓ 2026-07-25: Dual-Auslöser; **keine** offene Engine.
+
+---
+
+## 3. Duale Auslöser (PO ✓)
+
+| Auslöser | Bedeutung | Typisch |
+|----------|-----------|---------|
+| **Plan-Zug** | Horizont/Plan fragt: was ist ready? | A2, B2a, B2b, Checklisten (dünn), Agile-Slice |
+| **Event-Schub** | Etwas passiert → Reaktion/Arbeit öffnen oder ändern | C1, Care-Reaktionen, Cadence-Zeitpunkte (A3/A1) |
+
+Beide münden in dieselben Schlitze (Next work, Result, DoD, Adaptation, Attention).
+
+Jede Methode deklariert eine **Dominanz**:
+
+| Dominanz | Bedeutung |
+|----------|-----------|
+| `plan` | Planung/Horizont führt |
+| `event` | Ereignisse führen |
+| `hybrid` | beides wesentlich (z. B. Care) |
+
+---
+
+## 4. Universelle Schlitze (Lifecycle als Schleife)
+
+Der Kern orchestriert immer dieselbe Schrittliste.  
+Methode setzt pro Schritt: `active` | `skip` | `n/a` (+ Lieferant für den Schlitz).
+
+| # | Schlitz | Kern tut immer | Methode liefert |
+|---|---------|----------------|-----------------|
+| 1 | **Intake** | Kontext/Ziel/Scope absichern | zusätzliche Aufnahme |
+| 2 | **Method bind** | Methode binden, Kompatibilität zu Archetyp | Default/Wechselregeln |
+| 3 | **Structure setup** | Builder/Struktur-Hooks aufrufen | welche Struktur |
+| 4 | **Planning** | Planungsphase ermöglichen | *was* geplant wird — oder `n/a` |
+| 5 | **Next work** | Strategie aufrufen, Kandidaten + Begründung | Ready-Logik, Ranking, Leading-Typ |
+| 6 | **Assignment** | Actor-Zuweisung über Services | Assignment-Policy |
+| 7 | **Waiting** | Wartezustand führen | Reminder/Eskalation |
+| 8 | **Result / Event** | Rückmeldung **und** externe/situative Events annehmen | Interpretation |
+| 9 | **DoD / Validation** | Prüfung gegen Kriterien/Evidence anstoßen | Criteria-/Evidence-Policy — oder `n/a` |
+| 10 | **Review** | Review/Entscheidungspfad | wann Pflicht |
+| 11 | **Adaptation** | Nachsteuern/Replan-Hooks | was sich ändert |
+| 12 | **Closure** | Abschluss-Policy aufrufbar | ob Closure vorgesehen |
+
+**Schleife:** Nach Adaptation (und oft nach Result) wieder Next work / Planning — kein Zwang zum Closure.  
+**Intake** kann erneut feuern (dauerhafter Eingang).
+
+---
+
+## 5. Querschnittsfähigkeiten (Anker — Teil des Kerns)
+
+Damit Plan- und Event-Methoden dieselbe Maschine nutzen:
+
+| # | Fähigkeit | Pflicht |
+|---|-----------|---------|
+| Q1 | **Horizont** auflösen („worauf schauen wir?“) | ja |
+| Q2 | **Work-Item-Polymorphie** (Action, CadenceInstance, ChecklistItem, Decision, ProgramImpulse, …) | ja |
+| Q3 | **Event-Eingang** gleichberechtigt zu Actor-Result | ja |
+| Q4 | **Nested Contexts** (Parent-Impulse ≠ Child-Next-Work) | ja wenn Kinder existieren |
+| Q5 | **Attention**-Orchestrierung | ja |
+| Q6 | Formale Schritt-Status `active`/`skip`/`n/a` | ja |
+| Q7 | **Kompositions-Methoden** (z. B. Agile): eigener Horizont-Slice, Primary bleibt Natur | ja |
+
+---
+
+## 6. Methodentypen (verbindlich)
+
+Jede Methode hat genau eine **fachliche Rolle**. Technik-Feld AP2.4: `method_role`.
+
+| Methodentyp | `method_role` | Bedeutung | Beispiele |
+|-------------|---------------|-----------|-----------|
+| **Primary (Ausführung)** | `primary` | Trägt Vorhaben-Natur: Horizon, Leading Work, Closure-Haltung, Ready/Ranking | `sequential_dependency`, `continuous_product`, `recurring_control`, `maturity_progression`, `checklist_flow`, `care_navigation`, `dispute_procedure`, `generic_operating` |
+| **Primary (Meta)** | `primary` | Primary, aber **kein** Ausführungs-Leading der Kinder: Impulse, Nested, Lagebild | `program_delivery` (nur B2a) |
+| **Komposition** | `modifier` | Horizont-/Takt-Slice; **braucht** Primary; ersetzt Natur nicht | `agile_iteration` |
+
+**Regeln:**
+
+1. Pro Vorhaben genau **eine** Primary-Methode (Ausführung oder Meta).  
+2. Komposition nur wenn Primary in `composes_with` der Kompositions-Methode steht.  
+3. Meta-Primary (`program_delivery`) komponiert **nicht** mit Agile am Dach; Agile nur an Kind-Primaries.  
+4. „Kompatible Methoden“ eines Archetyps = erlaubte Primary **plus** erlaubte Kompositionen — kein wilder Primary-Wechsel ohne Archetyp-Passung.
+
+---
+
+## 7. Method Plugin — was jede Methode am Kern anmeldet
+
+Mindestens:
+
+| Anmeldung | Inhalt |
+|-----------|--------|
+| Methodentyp / `method_role` | `primary` \| `modifier` (+ Meta nur fachlich bei `program_delivery`) |
+| Dominanz | `plan` \| `event` \| `hybrid` |
+| Lifecycle-Map | Status je Schlitz |
+| Next-work-Strategie | Leading-Typ + Ready + Ranking + reason_codes |
+| Attention-Regeln | Codes + Auslöser |
+| Horizont-Definition | was Horizont ist |
+| DoD-Policy | oder explizit `n/a` |
+| `compatible_archetype_keys` + `data_slices` | AP2.4 |
+| `steering_elements` | UI-Bausteine |
+| Komposition | bei Primary: ob komponierbar; bei modifier: `composes_with` |
+
+Details: jeweilige `SPEC_D_<method>.md`.
+
+---
+
+## 8. Komposition Agile (PO ✓)
+
+`agile_iteration` = **Kompositions-/Horizont-Methode** mit eigener Sprint-Planungs- und Lifecycle-Logik.  
+Technisch `modifier`. Ersetzt Primary nicht. Genau ein aktiver Sprint. Ohne Sprint → nur Primary.  
+`composes_with`: `sequential_dependency`, `continuous_product`, `recurring_control` — **nicht** `program_delivery`.
+
+---
+
+## 9. Abbildung Dominanz (aus Spec-D)
+
+| Methode | Dominanz |
+|---------|----------|
+| `sequential_dependency` | plan |
+| `program_delivery` | plan (+ Signale aus Kindern) |
+| `continuous_product` | plan (hybrid-light bei Incidents) |
+| `checklist_flow` | plan (sehr dünn) |
+| `maturity_progression` | hybrid (Cadence-Zeit + Stufe) |
+| `recurring_control` | event (Cadence) |
+| `care_navigation` | hybrid |
+| `dispute_procedure` | event |
+| `agile_iteration` | plan-Slice (Komposition; mit sequential, continuous_product, recurring_control) |
+| `generic_operating` | plan (dünn) |
+
+---
+
+## 10. Beziehung zu Archetypen und Templates
+
+| Schicht | Rolle |
+|---------|--------|
+| Archetyp | Natur, Horizont-Erwartung, OM-Fähigkeiten, UI-Hülle, Default-Methode |
+| **Vorhaben-Template** | konkrete Vorlage **auf** einem Archetyp (Zusatzfelder, Darstellung, Sortierung/Filter, ggf. Profil) — **kein** neuer Archetyp (PO 2026-07-25) |
+| **dieser Kern** | universelle Steuerungs-Maschine |
+| Methode | Plugin in den Kern |
+| Operating Context | Laufzeit-Auflösung (AP2.3/AP2.4) |
+
+UI-Namen und Template-Darstellung sind nachrangig gegenüber Archetyp-Merkmalen + Methodensteuerung.
+
+---
+
+## 11. Freigabe-Log
+
+| Datum | Entscheidung |
+|-------|--------------|
+| 2026-07-25 | Hybrid A1 Spec-D → Kern |
+| 2026-07-25 | Dual-Auslöser; keine offene Workflow-Engine |
+| 2026-07-25 | Schlitze 1–12 + Querschnitt Q1–Q7 = Methodenkern v0.1 Freeze |
+| 2026-07-25 | Batch-Methoden Spec-D als Delta zum Kern akzeptiert (inhaltlich Decision-Lock; explizit mit Freeze) |
+| 2026-07-25 | Methodentypen: Primary (Ausführung) / Primary (Meta) / Komposition; Agile + A3; nicht am Programm-Dach |
+| 2026-07-26 | PO: Architektur beibehalten (schlank: Default-Primary + wenige Kompositionen); Vollspec-/Spec-D-Welle freigegeben |
+
+---
+
+## 12. Nächste Arbeit (nach Freeze)
+
+1. Spec-D Dominanz-Feld + Schlitz-Maps gegen dieses Dokument normalisieren (redaktionell)  
+2. Ist-Code-Lücken (v. a. `program_delivery` Nested/Impulse) als Implementierungs-Schuld listen  
+3. Archetyp-Vollspecs / Catalog v0.3 auf diesem Kern aufsetzen  
+4. Kein neuer Methoden-Code außerhalb Open/Closed Registry
+
+---
+
+*Freeze-Dokument. Bei Änderung: Version v0.2 + PO-Entscheid.*

docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md

@@ -0,0 +1,147 @@
+# 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.*

docs/architecture/M1_Hybrid_Path_and_Depth_D_v0.1.md

@@ -0,0 +1,117 @@
+# M1 — Hybrid-Pfad & Spec-Tiefe D
+
+**Status:** PO-Entscheidung A1 (2026-07-25)  
+**Bezug:** `M1_Lifecycle_Fit_Analysis_Archetypes_v0.1.md`, `Kairo_Steering_Method_Contract_Fachlich_v0.1.md`
+
+---
+
+## 1. Entscheidung
+
+**Hybrid A1:**
+
+```text
+1) Kandidat-Kern (Lifecycle-Loop + Anker A–G) — Hypothese, nicht eingefroren
+2) Alle primary-Methoden (+ Modifier agile_iteration) auf gleicher Spec-Tiefe D
+3) Abgleich → Kern erweitern/streichen/schärfen
+4) Kern einfrieren
+5) Skip/n/a pro Methode formal finalisieren
+```
+
+Nicht: Kern jetzt final. Nicht: Methoden ohne gemeinsames Raster.
+
+---
+
+## 2. Kandidat-Kern (Hypothese)
+
+```text
+Methodenkern (Kandidat) =
+  1) Steerable Context (+ optional Child Contexts)
+  2) Standard-Lifecycle als Loop (Schritte mit Status active|skip|n/a)
+  3) Horizon (aktiver Ausschnitt)
+  4) Work-Item-Polymorphie (ReadyWorkItem-Union)
+  5) Signal-/Event-Eingang (Actor-Ergebnis + externe/situative Events)
+  6) Extension Points (Strategies, Policies, Builder, Hooks, steering_elements)
+  7) Orchestrierung: Attention + Next Action
+     (+ Program Impulse getrennt von Child Next Action)
+```
+
+Lifecycle-Schritte (Rückgrat):
+
+```text
+intake → method_selection → structure_setup → planning → action_selection
+→ assignment → waiting → result_intake → validation → review
+→ adaptation → closure
+```
+
+---
+
+## 3. Spec-Tiefe D (verbindlich für Schritt 2)
+
+### 3.0 Kurskorrektur Erhebungsstil (2026-07-25)
+
+Meta-Abfrage von D1–D12 Abschnitt für Abschnitt **reproduziert nur die Fit-Analyse** und trägt nicht.
+
+**Stattdessen:**
+
+1. Pro Methode **eine substanzielle Spec** mit **konkreten Steuerungsregeln** (Ready, Ranking, Attention, Events, Graph-Semantik, Nested) — gespeist aus Decision-Lock, ADPs, Ist-Code.  
+2. PO-Interview nur zu **Spannungen / offenen Regeln** (D12), nicht zu Label-Feldern.  
+3. „Leichte“ Methoden (z. B. `sequential_dependency`) schnell verdichten; Härtetests (`program_delivery`, `care_navigation`, `checklist_flow`) gleich tief.
+
+Jede Methode wird auf **genau dieser Tiefe** beschrieben — nicht tiefer (kein GUI/EFS), nicht flacher — aber **inhaltlich konkret**, nicht meta.
+
+| # | Abschnitt | Inhalt |
+|---|-----------|--------|
+| D1 | Identität | `method_key`, Rolle primary/modifier, Label, 2–3 Sätze Zweck |
+| D2 | Geltung | `compatible_archetype_keys` (Ziel), Default für welche Archetypen |
+| D3 | Horizon | Was ist der aktive Horizont? (auch „keiner / Liste“) |
+| D4 | Leading Work Item | Union-Mitglied: Action / Cadence / Checklist / Decision / ProgramImpulse / … |
+| D5 | Lifecycle-Pfad | pro Schritt: `active` / `skip` / `n/a` + ein Satz warum |
+| D6 | Next Action | Eingaben, Ranking-Idee, leerer Fall, reason_codes (Namen) |
+| D7 | Attention | typische Auslöser + Codes (Namen) |
+| D8 | Events | welche Ereignisse greifen ein (Actor-Result, extern, situativ, Kind-Status) |
+| D9 | Nested | nur wenn relevant: Beziehung Parent/Child (B2a, Modifier) |
+| D10 | OM-Voraussetzungen | minimale Slices/Objekte |
+| D11 | Extension Points | welche Strategies/Policies/Elements (Namen, auch TBD) |
+| D12 | Spannungen zum Kandidat-Kern | was der Kern noch nicht trägt / was gestrichen werden könnte |
+
+**Explizit nicht in Tiefe D:** GUI-Layouts, EFS-Feldlisten, Starter-Kits, API-Routen, Implementierungsplan.
+
+---
+
+## 4. Methoden-Reihenfolge (Empfehlung)
+
+Zuerst **Extreme** und **Kernfälle**, damit der Kandidat-Kern früh gestresst wird:
+
+| Nr | Methode | Warum jetzt |
+|----|---------|-------------|
+| 1 | `sequential_dependency` | passt Lifecycle am besten — Referenz-Delta |
+| 2 | `program_delivery` | Nested — härtester Anker-Test |
+| 3 | `care_navigation` | Multi-Leading-Object |
+| 4 | `checklist_flow` | degenerierter Pfad |
+| 5 | `recurring_control` | Cadence / Anti-Duplikat |
+| 6 | `continuous_product` | Loop / kein Closure |
+| 7 | `maturity_progression` | Recurring + Stages |
+| 8 | `dispute_procedure` | Event-Pfad |
+| 9 | `agile_iteration` | Modifier auf A2/B2b |
+| 10 | `generic_operating` | Fallback |
+| — | Legacy `queue_pull` / `chapter_based_*` / `product_milestone_driven` | nachziehen / migrieren |
+
+---
+
+## 5. Arbeitsartefakte
+
+| Artefakt | Rolle |
+|----------|--------|
+| `docs/architecture/methods/SPEC_D_<method_key>_v0.1.md` | eine Datei pro Methode auf Tiefe D |
+| `docs/architecture/methods/_TEMPLATE_Method_Spec_Depth_D_v0.1.md` | Template |
+| dieses Dokument | Prozess + Tiefe D |
+| Fit-Analyse | Begründung Kandidat-Kern |
+
+---
+
+## 6. Freigabe-Log
+
+| Datum | Entscheidung |
+|-------|--------------|
+| 2026-07-25 | Hybrid A1 gewählt |
+| … | Kandidat-Kern eingefroren (nach Methoden-Durchgang) |

docs/architecture/M1_Lifecycle_Fit_Analysis_Archetypes_v0.1.md

@@ -0,0 +1,195 @@
+# M1 — Passungsprüfung Lifecycle-Kern × Archetypen/Methoden
+
+**Status:** Analyse (keine Freigabe)  
+**Stand:** 2026-07-25  
+**Zweck:** Prüfen, ob der Standard-Lifecycle allein als Methodenkern trägt — gegen Decision-Lock (8 Typen)
+
+Geprüfter Kandidat:
+
+```text
+intake → method_selection → structure_setup → planning → action_selection
+→ assignment → waiting → result_intake → validation → review → adaptation → closure
+```
+
+Legende Passung: **✓** natürlich · **◐** nur mit Interpretation/Skip · **✗** Bruch / fehlender Anker
+
+---
+
+## 1. Urteil (kurz)
+
+Der Lifecycle ist ein **taugliches Phasen-Rückgrat**, aber **nicht ausreichend** als alleiniger Methodenkern für unser Portfolio.
+
+Er ist klar aus **Projekt-/Produktentwicklung** gedacht (A2, B2b). Für A3, B1, B2a, C1, Care und teilweise A1 braucht der Kern **zusätzliche invariante Anker**. Sonst werden „Skip“ und „Action“ zu Platzhaltern, die Unterschiede verdecken statt zu tragen.
+
+---
+
+## 2. Matrix pro Typ × Methode
+
+### A2 · `sequential_dependency` (+ `agile_iteration`)
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| intake … structure_setup | ✓ | Ziel, Gates/Pfade |
+| planning | ✓ | rollierend erlaubt |
+| action_selection | ✓ | ready am Pfad |
+| assignment … validation | ✓ | |
+| review / adaptation | ✓ | |
+| closure | ✓ | Ende/DoD |
+| Agile-Modifier | ◐ | braucht **Horizon = work_cycle** als Kernkonzept, nicht nur Skip von planning |
+
+**Fazit A2:** Lifecycle passt am besten. Ankerpunkt Horizon/Sprint fehlt im reinen Schrittnamen.
+
+### B2b · `continuous_product` (+ Agile)
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| intake | ◐ | nicht nur einmalig — **Dauer-Eingang** |
+| structure_setup | ✓ | Orientierungsgates |
+| planning | ◐ | Triage/Backlog; mit Agile Sprint-Planung |
+| action_selection | ✓ | |
+| closure | ◐ | oft **dauerhaft inaktiv** — Zyklus ist Schleife, kein Pfad zum Ende |
+| adaptation → action_selection | ✓ nötig | **Re-entrancy** muss Kern sein |
+
+**Fazit B2b:** Lifecycle nur tragfähig, wenn er als **Loop mit optionalem Closure** gilt, nicht als einmalige Pipeline.
+
+### A1 · `maturity_progression`
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| structure_setup | ✓ | Stufen, Recurring |
+| planning | ◐ | oft skip / schwach |
+| action_selection | ◐ | Leading object oft **Recurring/Übung**, nicht Action |
+| validation | ✓ | Stufenkriterien |
+| adaptation | ✓ | Stufenwechsel, Routinen-Rotation |
+| closure | ◐ | weich / selten |
+
+**Fazit A1:** Bruch, wenn Core „Next Action = Action“ hardcodet. Kern braucht **polymorphes Work Item**.
+
+### A3 · `recurring_control`
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| planning | ◐ | typisch skip |
+| action_selection | ◐ | fällige **CadenceInstance** |
+| result_intake | ✓ | erledigt → nächster Zyklus, **kein Duplikat** |
+| validation/review | ◐ | eher Gesundheits-/Abweichungssignal |
+| closure | ◐ | meist nie |
+
+**Fazit A3:** Lifecycle nur mit Cadence-Semantik im Kern; sonst wird A3 zu „Mini-A2 mit Skips“.
+
+### B1 · `checklist_flow`
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| intake | ✓ | Items fortlaufend |
+| structure_setup | ◐ | Listen/Gruppen — dünn |
+| planning | ◐ | oft dauerhaft skip |
+| action_selection | ✓ | nächstes Item |
+| assignment / waiting | ◐ | oft entbehrlich |
+| validation / review / closure | ◐ | meist skip |
+
+**Fazit B1:** Sehr viele Schritte dauerhaft NA. Kern muss **degenerierte, gültige Pfade** erlauben — sonst wirkt der Lifecycle wie aufgezwungene Projektmetaphorik. Das ist kein Ausschluss von B1, aber ein Warnsignal an den Kern.
+
+### B2a · `program_delivery`
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| structure_setup | ✓ | Programm-Horizont + Kinder |
+| planning | ◐ | übergeordnete Priorisierung |
+| action_selection | ✗/**kritisch** | PO: konkrete Next Action liegt bei **Kindern**; Programm liefert **Impulse** (Roadblocker, Kreuz-Deps) |
+| assignment | ◐ | selten auf Programmebene |
+| waiting | ✓ | auf Kinder/externe Lagen |
+| closure | ✓ | Programm-Abschluss |
+
+**Fazit B2a:** Größter struktureller Bruch. Ein Lifecycle auf **einem** SteeringContext erklärt nicht **verschachtelte Steuerung** (Parent-Impulse vs. Child-Next-Action). Das ist kein Methoden-Detail — das ist ein **Kern-Anker**.
+
+### C1 · `dispute_procedure`
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| planning | ◐ | schwach |
+| waiting | ✓ | zentral |
+| result_intake | ◐/**kritisch** | oft **externe Ereignisse**, nicht nur Actor-Ergebnis |
+| action_selection | ✓ | nächste Frist/Entscheidung |
+| review | ✓ | Decision |
+| closure | ✓ | Fallende |
+
+**Fazit C1:** Lifecycle braucht **Event-Injection** als erstklassigen Pfad (nicht nur result_intake von zugewiesener Arbeit).
+
+### Care · `care_navigation`
+
+| Schritt | Passung | Anmerkung |
+|---------|---------|-----------|
+| structure_setup | ✓ | Prinzipien, Meilensteine, Rituale |
+| planning | ◐ | gemischt |
+| action_selection | ◐/**kritisch** | Leading object wechselt: Ritual **oder** Reaktion **oder** Meilenstein-Schritt |
+| waiting / result_intake | ✓ | inkl. situativer Ereignisse |
+| closure | ◐ | weich |
+
+**Fazit Care:** Ein Schritt `action_selection` reicht nur, wenn der Kern **mehrere parallele Bedenken** (Cadence + offene Reaktion + Horizon) tragen kann — nicht nur eine flache Action-Queue.
+
+---
+
+## 3. Was der Lifecycle allein nicht trägt
+
+| Fehlender Kern-Anker | Warum nötig | Betroffen |
+|----------------------|-------------|-----------|
+| **A. Zyklus als Loop** | Closure optional; Wiedereintritt nach adaptation; Intake jederzeit | B2b, A3, B1, Care |
+| **B. Horizon** | Aktiver Ausschnitt (Gate, Stage, Sprint, Care-Checkpoint, Programm-Meilenstein) | A2+Agile, B2b, A1, B2a, Care |
+| **C. Polymorphes Work Item** | Next Action zeigt nicht immer auf `Action` | A1, A3, B1, C1, Care, B2a-Impulse |
+| **D. Nested / Child Steering** | Parent-Impulse ≠ Child-Next-Action | **B2a** |
+| **E. Event-Pfad** | Externe/situative Ereignisse mittendrin | C1, Care, teils B2b |
+| **F. Step-Status pro Methode** | active / skip / N/A dauerhaft — formal | B1, A3, B2b closure |
+| **G. Extension Points** | Strategies/Policies/Hooks an Schritten — sonst leerer Zyklus | alle |
+
+Ohne A–G bleibt der Lifecycle eine **Erzählung**. Mit A–G wird er zum **Methodenkern**.
+
+---
+
+## 4. Was gut am Lifecycle bleibt
+
+- Gemeinsame Sprache für „wo im Steuerungsgeschehen wir sind“
+- Klare Orchestrierungsorte für Hooks/Strategies (Target Architecture §7)
+- Passt stark zu A2 und brauchbar zu B2b (mit Loop)
+- Verhindert freie Workflow-Engine
+- Aligniert mit bereits beschlossenem Adaptive Steering Core
+
+**Empfehlung:** Lifecycle **behalten als Rückgrat**, aber **nicht** als hinreichende Definition des Kerns freigeben.
+
+---
+
+## 5. Empfohlenes Kernmodell (Kandidat zur Entscheidung)
+
+```text
+Methodenkern =
+  1) Steerable Context (+ optional Child Contexts)
+  2) Standard-Lifecycle als Loop (Schritte mit Status active|skip|n/a)
+  3) Horizon (aktiver Ausschnitt)
+  4) Work-Item-Polymorphie (ReadyWorkItem-Union)
+  5) Signal-/Event-Eingang (Actor-Ergebnis + externe/situative Events)
+  6) Extension Points (Strategies, Policies, Builder, Hooks, steering_elements)
+  7) Orchestrierung: Attention + Next Action (+ Program Impulse getrennt von Child NA)
+```
+
+Abbildung B2a:
+
+```text
+Program Context --impulse/attention-->  (kein Ersatz)
+Child Context  --next_action------->  konkrete Arbeit
+```
+
+---
+
+## 6. Risiko bei „nur Lifecycle + Skip“
+
+| Risiko | Folge |
+|--------|--------|
+| Alles wird Action | A3/B1/Care verbogen |
+| Programm = großes Projekt | Hybrid-Entscheidung aus Interview unterlaufen |
+| Closure implizit erwartet | Product/Rhythmus falsch modelliert |
+| Events nur als Result | C1/Care zweitklassig |
+| AP2.4-Felder ohne Semantik | Plugin-Technik ohne fachlichen Kern |
+
+---
+
+*Analyse für PO-Review. Keine Implementierungsentscheidung.*

docs/architecture/M2_Method_Compatibility_and_Code_Debt_v0.1.md

@@ -0,0 +1,99 @@
+# M2 — Methoden: Kompatibilität & Code-Schuld
+
+**Status:** erledigt (Dokumentation) — 2026-07-25  
+**Voraussetzung:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-D:** `docs/architecture/methods/SPEC_D_*.md`  
+**Nächste Phase:** Archetyp-Vollspecs
+
+---
+
+## 1. Dominanz (Kernel §3 / §8)
+
+| Methode | Dominanz | Rolle |
+|---------|----------|-------|
+| `sequential_dependency` | plan | primary |
+| `program_delivery` | plan (+ Kind-Signale) | primary |
+| `continuous_product` | plan (hybrid-light) | primary |
+| `checklist_flow` | plan (dünn) | primary |
+| `maturity_progression` | hybrid | primary |
+| `recurring_control` | event (Cadence) | primary |
+| `care_navigation` | hybrid | primary |
+| `dispute_procedure` | event | primary |
+| `agile_iteration` | plan-Slice | **Komposition** |
+| `generic_operating` | plan (dünn) | primary Fallback |
+| `queue_pull` | — | **Legacy** → ablösen durch `checklist_flow` |
+| `chapter_based_progression` | — | **Legacy** → Content = A2 + Profil, keine eigene Methode nötig |
+| `product_milestone_driven` | — | **Legacy** → migrieren zu program/product |
+
+---
+
+## 2. Kompatibilitätsmatrix Ziel (Archetyp × Methode)
+
+| Archetyp | Default-Methode | Auch erlaubt | Komposition |
+|----------|-----------------|--------------|-------------|
+| `linear_project` (A2) | `sequential_dependency` | — | `agile_iteration` |
+| `program` (B2a) | `program_delivery` | Kind-Methoden an Kindern | Agile nur an Kindern A2/B2b |
+| `product` (B2b) | `continuous_product` | — | `agile_iteration` |
+| `maturity_journey` (A1) | `maturity_progression` | — | — |
+| `recurring_program` (A3) | `recurring_control` | — | `agile_iteration` |
+| `checklists` (B1) | `checklist_flow` | — | — |
+| `care` (NEU) | `care_navigation` | — | — |
+| `dispute_case` (C1) | `dispute_procedure` | — | — |
+| `generic` | `generic_operating` | Übergang zu konkreter Methode | — |
+| `content_project` | **entfernt** als Archetyp | Content → A2 | — |
+
+Kind unter B2a: jeder Kind-Archetyp mit seiner Default-Methode (Hybrid Decision-Lock).
+
+---
+
+## 3. Ist-Code vs. Ziel
+
+| Methode | Ist `compatible_archetype_keys` | Ziel | Gap |
+|---------|-------------------------------|------|-----|
+| `sequential_dependency` | `*` | `linear_project` (+ Kind A2) | zu weit |
+| `program_delivery` | `program` | `program` | Strategy ≠ Nested/Impulse |
+| `continuous_product` | product-like | `product` | prüfen |
+| `queue_pull` | `*` | ersetzen durch `checklist_flow` + Checklisten-Archetyp | Rename/neu |
+| `agile_iteration` | `*`, composes_with product+**program** | composes_with **product + sequential + recurring** (nicht Programm-Meta) | composes_with unvollständig |
+| `care_navigation` | fehlt | `care` | neu |
+| `checklist_flow` | fehlt | checklists | neu |
+| `chapter_based_*` | `content_project` | deprecated | entfernen/umwidmen |
+| `maturity` / `recurring` / `dispute` | ok eng | ok | Strategie-Tiefe |
+
+---
+
+## 4. Code-Schuld (Implementierung später — priorisiert)
+
+| Prio | Schuld | Bezug |
+|------|--------|-------|
+| P0 | `program_delivery`: Impulse + Nested; Child-NA getrennt | SPEC_D_program_delivery |
+| P0 | Registry: `care_navigation` + Archetyp `initiative.care` | Decision-Lock |
+| P0 | `checklist_flow` + Archetyp `initiative.checklists`; Nested Tiefe 3 + Roll-up; Multi-Listen | SPEC_B1_checklists / Spec-D |
+| P1 | `sequential_dependency` compat auf A2 einschränken | Matrix §2 |
+| P1 | `agile_iteration.composes_with` → `continuous_product`, `sequential_dependency`, `recurring_control` | Spec Agile |
+| P1 | Dual-Auslöser Event-Pfad in Strategies (C1/Care) | Kernel §3 |
+| P2 | Legacy `chapter_based_progression` / `content_project` Seed | Decision-Lock |
+| P2 | Spec-D Dominanz-Feld redaktionell in alle Dateien | Kernel §8 |
+| P3 | Stubs → volle Strategien (recurring, dispute, …) | Spec-D |
+
+**Kein Code in M2** — nur Verbindlichkeit für spätere APs.
+
+---
+
+## 5. Implementierungsreife Methoden (ehrlich)
+
+| Reife | Methoden |
+|-------|----------|
+| Fachlich bau-bar (Verhalten klar, Code teils da) | `sequential_dependency`, `continuous_product`, `agile_iteration` (Komposition), `maturity_progression` |
+| Fachlich klar, Code weit weg | `program_delivery` (Umbau), `checklist_flow`, `care_navigation` |
+| Spec-D gehärtet, Code teils Stub | `recurring_control`, `dispute_procedure`, `maturity_progression`, `continuous_product`, `generic_operating` |
+
+Assignment-DoD für Code-APs: Kernel-Schlitze + Spec-D + diese Matrix — keine Page-Ifs.
+
+---
+
+## 6. Freigabe
+
+- [x] Matrix Ziel §2
+- [x] Code-Schuld §4
+- [x] Weiter mit Archetyp-Vollspecs

docs/architecture/methods/README.md

@@ -0,0 +1,18 @@
+# methods/ — Spec-Tiefe D Index
+
+**Prozess:** `../M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Methodenkern (Freeze):** [`../Kairo_Steering_Method_Kernel_v0.1.md`](../Kairo_Steering_Method_Kernel_v0.1.md) — Methodentypen: Kernel §6  
+**PO 2026-07-26:** Architektur beibehalten; Spec-D-Batch **vorläufig freigegeben** (Implementierungsausreichendheit noch offen)
+
+| Methode | Typ | Datei | Status |
+|---------|-----|-------|--------|
+| `sequential_dependency` | Primary (Ausführung) | SPEC_D_sequential_dependency_v0.1.md | vorläufig freigegeben|
+| `continuous_product` | Primary (Ausführung) | SPEC_D_continuous_product_v0.1.md | vorläufig freigegeben|
+| `recurring_control` | Primary (Ausführung) | SPEC_D_recurring_control_v0.1.md | vorläufig freigegeben|
+| `maturity_progression` | Primary (Ausführung) | SPEC_D_maturity_progression_v0.1.md | vorläufig freigegeben|
+| `checklist_flow` | Primary (Ausführung) | SPEC_D_checklist_flow_v0.1.md | vorläufig freigegeben|
+| `care_navigation` | Primary (Ausführung) | SPEC_D_care_navigation_v0.1.md | vorläufig freigegeben|
+| `dispute_procedure` | Primary (Ausführung) | SPEC_D_dispute_procedure_v0.1.md | vorläufig freigegeben|
+| `generic_operating` | Primary (Ausführung, Fallback) | SPEC_D_generic_operating_v0.1.md | vorläufig freigegeben|
+| `program_delivery` | Primary (**Meta**) | SPEC_D_program_delivery_v0.1.md | vorläufig freigegeben|
+| `agile_iteration` | **Komposition** | SPEC_D_agile_iteration_v0.1.md | vorläufig freigegeben|

docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md

@@ -0,0 +1,100 @@
+# SPEC-D — `agile_iteration`
+## Steuerungsmethode — Spec-Tiefe D v0.1 (Kompositions-Methode)
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-25  
+**Rolle:** **Kompositions- / Horizont-Methode** (technisch AP2.4: `method_role=modifier`)  
+**Komponiert mit:** `continuous_product`, `sequential_dependency`, `recurring_control`  
+**Nicht:** eigene Vorhaben-Natur / kein Archetyp
+
+---
+
+## D1 Identität — PO ✓
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `agile_iteration` |
+| Fachliche Rolle | **Komposition** (Kernel §6) mit eigener Plan-/Lifecycle-Logik für den Iterations-Horizont |
+| Technische Rolle | `modifier` (ersetzt Primary nicht; nicht mit `program_delivery`) |
+| Label (DE) | Agile Iteration / Sprint |
+| Zweck | Taktet Arbeit in `work_cycle` (Sprint): Planung, Sprint-Backlog, Ausführung, Abschluss/Carryover. Ändert nicht, ob das Vorhaben Projekt (Ende) oder Product (Dauer) ist. |
+
+**Klarstellung PO:** „Modifier“ ≠ schwache Logik. Agile hat volle Steuerungslogik für den Sprint — braucht aber eine **Primary** für Vorhaben-Natur (Closure, Gates-Rolle, Dauerbetrieb vs. Ende).
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Komponiert mit | B2b + `continuous_product`; A2 + `sequential_dependency`; A3 + `recurring_control` |
+| Nicht allein | ohne Primary keine Aussage über Vorhaben-Natur |
+| Nicht Archetyp | Decision-Lock |
+
+---
+
+## D3 Horizon
+
+| Schicht | Owner |
+|---------|--------|
+| **Vorhaben- / Plan-Horizont** | Primary (Gate, Orientierung, …) |
+| **Iterations-Horizont (Ist)** | diese Methode: aktiver `work_cycle` |
+
+Beide gleichzeitig gültig; Ist-Default bei aktivem Sprint = Sprint-Backlog.
+
+---
+
+## D4 Leading Work Item
+
+**Im Sprint-Slice:** **Action**, gefiltert auf `work_cycle_id` des aktiven Sprints (Primary-Ready ∩ Sprint).
+
+**Mit Primary `recurring_control` (A3):** Sprint taktet Actions (Verbesserung/Sonderarbeit). **CadenceInstances** bleiben Leading der Primary und liegen **nicht** als Sprint-Backlog-Todos; Ranking: Cadence overdue/due vor Sprint-Actions (siehe Spec-D `recurring_control` D6).
+
+---
+
+## D5 Lifecycle — eigener Slice (nicht „Flag“)
+
+| Sprint-Phase | Steuerung |
+|--------------|-----------|
+| Sprint anlegen / geplant | Plan-Container |
+| Sprint-Planung | Items aus Eingang/Backlog in Sprint legen (Commit/`work_cycle_id`) |
+| Sprint aktiv | action_selection nur Sprint-Scope; Work-Default Sprint |
+| Sprint abschließen | Review/Carryover/Unplan; Status `reached`/`closed` |
+| Reaktivierung | optional laut bestehendem Flow |
+| Kein aktiver Sprint | Komposition wirkungslos → **nur Primary** (kein leerer Sprint-Sackgasse) |
+
+Primary-Lifecycle (intake … closure des Vorhabens) bleibt; dieser Slice **hängt sich** in planning / action_selection / waiting / result_intake / adaptation ein.
+
+---
+
+## D6–D8
+
+Next: ready Actions im aktiven Sprint (Primary-Ready-Regeln ∩ work_cycle).  
+Codes: `sprint_ready`, `sprint_empty`, `sprint_ending`.  
+Attention: leerer aktiver Sprint; Überhang vor Abschluss.  
+Events: activate, complete, carryover, reactivate, unplan.
+
+---
+
+## D9 Nested
+
+Kann auf Kind unter B2a liegen, wenn Kind A2/B2b + Agile nutzt. Programm-Meta bleibt `program_delivery`.
+
+---
+
+## D10–D11
+
+OM: `RoadmapItem(work_cycle)` + `actions.work_cycle_id`.  
+Elements: `work_cycle_scope`.  
+`composes_with`: `continuous_product`, `sequential_dependency`, `recurring_control`.
+
+---
+
+## D12
+
+| Punkt | PO ✓ |
+|-------|------|
+| Eigene Steuerungslogik | ja — Planen + Sprint-Lifecycle |
+| Primary nötig | ja — Vorhaben-Natur |
+| Bezeichnung | fachlich Kompositions-/Horizont-Methode; technisch modifier |
+| Ein aktiver Sprint | ja (Decision-Lock) |

docs/architecture/methods/SPEC_D_care_navigation_v0.1.md

@@ -0,0 +1,170 @@
+# SPEC-D — `care_navigation`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Quellen:** Decision-Lock Care, `SPEC_Care_initiative_care_v0.1.md`, Fit-Analyse  
+**Ist-Code:** Methode existiert noch nicht (neu) — P0  
+**OM/UI:** Archetyp-Vollspec Care
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `care_navigation` |
+| Rolle | primary (**Ausführung** — Kernel §6) |
+| Label (DE) | Fürsorge-Navigation |
+| Zweck | Steuert das **Wohlergehen einer Person im Fürsorgefokus** (andere oder Self-Care). Vereinigt Prinzipien, Meilensteine, Rituale und reaktive Stränge unter **einer** Methode — ohne Archetyp-Mix A3+C1+A2. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default für | `initiative.care` |
+| kompatibel | `initiative.care` |
+| nicht Default für | A1 (Können), A3 (Cadence ohne Fürsorge-Kern), C1 (Verfahren/Fall), B1 (Checklisten) |
+
+---
+
+## D3 Horizon
+
+| Schicht | Inhalt |
+|---------|--------|
+| **CareFocus** | welche Person (Selbst/Andere) ist der Fürsorgefokus |
+| **Checkpoint** | optionaler Lebens-/Entwicklungs-Meilenstein („bis Schuleingang“, „Stabilität nach Krise“) |
+| **Jetzt** | Schnitt aus: fälliges Ritual **oder** offene Reaktion **oder** nächster Checkpoint-Schritt |
+
+Horizon ist **mehrschichtig** — nicht nur ein Gate.
+
+---
+
+## D4 Leading Work Item — polymorph (Kern)
+
+Next Action zeigt auf **genau eines** der folgenden, je Ranking:
+
+| Typ | Wann typisch |
+|-----|----------------|
+| `CadenceInstance` | fälliges/überfälliges Ritual (eine Instanz, kein Duplikat) |
+| `CareReaction` | offener situativer Strang (Situation → Reaktion); oft Action oder Decision |
+| `HorizonStep` | nächster Schritt am Care-Checkpoint (Action oder Kriterium) |
+| `PrincipleReminder` | selten: Prinzip verletzt / Drift ohne konkrete Aufgabe — eher Attention als NA |
+
+**Nicht Leading:** flache Todo-Wand; fremde Rechtsfall-Logik (C1); Skill-Übung ohne Fürsorge-Framing (A1).
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung Care |
+|---------|--------|----------------|
+| intake | active | Fokus-Person, Prinzipien, Ausgangslage |
+| method_selection | active | Default `care_navigation` |
+| structure_setup | active | Prinzipien (EFS/Config), optionale Checkpoints, Rituale, Reaktions-Eingang |
+| planning | skip/light | keine Vollplanung; Checkpoints rollierend |
+| action_selection | active | Ranking über Cadence / Reaction / HorizonStep |
+| assignment | active | oft ein Primary Caregiver; Übernahme möglich (später) |
+| waiting | active | auf Ritual-Erledigung, situatives Ereignis, Termin |
+| result_intake | active | Ritual done, Reaktion abgeschlossen, Evidence |
+| validation | optional | Checkpoint-Kriterien |
+| review | optional | Lage der Fürsorge / Retrospektive |
+| adaptation | active | Rituale/Prinzipien/Checkpoints anpassen |
+| closure | skip/soft | Fürsorge oft dauerhaft; Closure nur wenn Fokus endet (z. B. Fall abgeschlossen) |
+
+---
+
+## D6 Next Action — Ranking (Ziel)
+
+**Priorität (Vorschlag):**
+
+1. **Offene kritische Reaktion** (akuter Bedarf, Frist, Sicherheit) → `care_reaction_urgent`  
+2. **Überfälliges Ritual** (verpasste Cadence, Eskalation) → `care_ritual_overdue`  
+3. **Heute fälliges Ritual** → `care_ritual_due`  
+4. **Checkpoint-Schritt ready** → `care_checkpoint_ready`  
+5. Sonst ruhige Lage → leerer NA-Kanal + Attention „stabil“ / Prinzip-Drift
+
+**Anti-Patterns:**
+
+- jedes verpasste Ritual erzeugt neuen Task-Duplikat (A3-Verbot gilt hier analog)  
+- alle Rituale + Reaktionen als gleichwertige Todo-Liste  
+- Self-Care als A1-Skill-Training umdeklarieren
+
+**Leerer Fall:** erlaubt („gerade kein Schritt nötig“) — anders als A2, wo leerer Fall oft Planning Debt ist.
+
+---
+
+## D7 Attention
+
+| Code | Wann |
+|------|------|
+| `care_reaction_open` | offene Reaktion ohne Fortschritt |
+| `care_ritual_overdue` | Cadence verpasst |
+| `care_checkpoint_at_risk` | Meilenstein gefährdet |
+| `care_principle_drift` | wiederholte Abweichung von Prinzipien |
+| `care_caregiver_overload` | zu viele offene Lasten auf einem Actor (später) |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| Situatives Ereignis erfasst | öffnet/aktualisiert `CareReaction` |
+| Ritual erledigt | CadenceInstance schließt; nächster Zyklus geplant (eine Instanz) |
+| Checkpoint verify | Horizon wechselt |
+| Prinzip geändert | Attention/Guidance, kein Auto-Commit von Arbeit |
+| Externer Termin (Arzt, Schule) | kann Reaction oder Waiting speisen — **nicht** automatisch C1 |
+
+---
+
+## D9 Nested
+
+`n/a` typisch. Care kann Kind unter B2a sein (selten); dann gilt Child-NA = diese Methode, Parent = Impulse.
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Optional |
+|---------|----------|
+| Initiative `initiative.care` | Checkpoints als RoadmapItems |
+| CareFocus (EFS oder gleichwertig) | Evidence |
+| ≥1 Ritual (Recurring) **oder** Reaktions-Eingang | Decision bei schweren Abwägungen |
+| Prinzipien (EFS/Text) | Mehrere Fokus-Personen — TBD |
+
+---
+
+## D11 Extension Points
+
+| Art | Ziel |
+|-----|------|
+| next_action_strategy | `care_navigation` |
+| steering_elements | `next_action_primary`, `recurring_rhythm`, neu `care_focus`, `care_reactions` |
+| attention rules | siehe D7 |
+| hooks | `on_next_action_requested`, `on_result_received`, `on_escalation_required`, `on_reassessment_required` |
+| structure builder | optionales Minimal-Kit: Fokus + 1 Ritual + 1 Prinzip |
+
+---
+
+## D12 Spannungen zum Kandidat-Kern · offene PO-Punkte
+
+| Anker | Bedarf |
+|-------|--------|
+| Work-Item-Polymorphie | **zwingend** (Cadence + Reaction + HorizonStep) |
+| Event-Pfad | **zwingend** (Situation → Reaktion) |
+| Loop / weiches Closure | **zwingend** |
+| Horizon mehrschichtig | CareFocus + Checkpoint — Kern-Horizon muss mehr als „ein Gate“ können |
+
+**PO ✓ (2026-07-25) — in Klartext:**
+
+1. **Ein Vorhaben = eine Fokus-Person** (oder „ich“ bei Self-Care). Mehrere Personen → mehrere Vorhaben / später Programm.  
+2. **Reaktion = normales Arbeitspaket** (ggf. kurz über Eingang); kein neues OM-Objekt „CareReaction“ — nur Spec-/Read-Model-Begriff.  
+3. **Meilensteine/Checkpoints optional** — Care nur mit Ritualen + Reaktionen ist gültig.
+
+## Nächste Methode
+
+Degenerierter Pfad: **`checklist_flow`**.

docs/architecture/methods/SPEC_D_checklist_flow_v0.1.md

@@ -0,0 +1,157 @@
+# SPEC-D — `checklist_flow`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Archetyp:** `initiative.checklists`  
+**OM/UI:** `SPEC_B1_checklists_v0.1.md`  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Quellen:** Decision-Lock B1, Archetyp-Vollspec B1, Fit-Analyse  
+**Ist-Code:** nah an `queue_pull` — fachlich umbenennen/ablösen
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `checklist_flow` |
+| Rolle | primary (**Ausführung** — Kernel §6) |
+| Label (DE) | Checklisten-Flow |
+| Zweck | Items in Listen/Gruppen sammeln und abhaken bzw. als Nächstes ziehen. Leichte Steuerung — bewusst nah an klassischer Todo-Logik, als **ein** Vorhaben-Typ im Portfolio. Ersetzt fachlich das Label `queue_pull`. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default für | B1 Checklisten (`initiative.support_queue` → Zielrename `initiative.checklists`) |
+| kompatibel | Checklisten-Archetyp |
+| nicht | Product-Backlog von B2b (bleibt Eingang am Product); A2-Lieferprojekt; Care-Rituale |
+
+---
+
+## D3 Horizon
+
+| Horizont | Bedeutung |
+|----------|-----------|
+| **Aktive Liste** | eine von mehreren parallelen Listen im Vorhaben |
+| **Kein Gate-Pflicht-Horizont** | Meilensteine nicht steuerungsführend |
+
+---
+
+## D4 Leading Work Item
+
+**ChecklistItem** — bevorzugt **offenes Blatt-ToDo** (Tiefe ≤ 3).
+
+Struktur (PO ✓):
+
+- Mehrere Listen parallel; Liste hat Beschreibung  
+- Punkte verschachtelt max. **Tiefe 3**; Punkt = ToDo (Blatt) oder Sammlung (Kinder)  
+- Parent erst schließbar, wenn alle Kinder geschlossen (Roll-up)
+
+Abbildung: Items mit `parent_id`; Listen-Container siehe Archetyp-Vollspec.
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung |
+|---------|--------|-----------|
+| intake | active | Items erfassen (Paste, einzeln, später Capture) |
+| method_selection | active | Default checklist_flow |
+| structure_setup | light | Listen/Gruppen/Tags anlegen |
+| planning | **n/a** | keine Projektplanung |
+| action_selection | active | nächstes Item (Pull oder Priorität) |
+| assignment | optional | oft entbehrlich (Selbst) |
+| waiting | **n/a**/selten | |
+| result_intake | active | abhaken / erledigt |
+| validation | **n/a** | |
+| review | **n/a** | |
+| adaptation | light | Liste umsortieren, Gruppe wechseln |
+| closure | optional | Liste leer / Archiv — nicht Pflicht |
+
+**Kern-Konsequenz:** viele Schritte dauerhaft `n/a` — gültiger degenerierter Pfad, keine „kaputte“ Methode.
+
+---
+
+## D6 Next Action
+
+**Ready:** offenes Item in aktivem Listen-Horizont, nicht erledigt.
+
+**Ranking:**
+
+1. manuell priorisiert / markiert (`!`, high)  
+2. mit Fälligkeit (früher zuerst)  
+3. Listen-Reihenfolge / sort_order  
+
+**reason_codes:** `checklist_next`, `checklist_due`, `checklist_priority`
+
+**Leerer Fall:** Liste leer → „nichts offen“ (Erfolg), nicht Planning Debt.
+
+**Anti-Pattern:** alle Items des Portfolios als eine Wand; Product-Issues hier statt in B2b.
+
+---
+
+## D7 Attention
+
+| Code | Wann |
+|------|------|
+| `checklist_overdue` | Item überfällig |
+| `checklist_overflow` | sehr viele offene Items (Schwellwert später) |
+| `checklist_unscoped` | Item ohne Gruppe/Thema (wenn Gruppierung genutzt wird) |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| Item angelegt | Ready-Menge |
+| Item abgehakt | aus Next entfernt |
+| Gruppe/Liste gewechselt | Horizon |
+| Bulk-Capture freigegeben | viele Items intake |
+
+---
+
+## D9 Nested
+
+`n/a`. Kann Kind unter B2a sein (selten).
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Optional |
+|---------|----------|
+| Initiative Checklisten-Typ | Fälligkeiten |
+| ≥1 Liste/Gruppe oder Default-Liste „Allgemein“ | Tags Ort/Thema |
+| Items (BacklogItem oder äquivalent) | Convert zu Action |
+
+---
+
+## D11 Extension Points
+
+| Art | Ziel |
+|-----|------|
+| next_action_strategy | `checklist_flow` (Nachfolger von queue_pull-Verhalten) |
+| steering_elements | `next_action_primary`, `queue_inbox` → fachlich Checklisten-Panel |
+| hooks | `on_next_action_requested`, `on_result_received` |
+
+---
+
+## D12 Spannungen · offene PO-Punkte
+
+| Punkt | Detail |
+|-------|--------|
+| Degenerierter Lifecycle | Kern muss `n/a`-Schritte erlauben ohne Qualitätsmakel |
+| Item vs Action | zu schweres Action-Modell zerstört Checklisten-Charakter |
+| Rename | `queue_pull` → `checklist_flow`; Archetyp-Key später |
+
+**PO ✓ (2026-07-25):**
+
+1. Abhaken am Item = Normalfall; volles Arbeitspaket nur wenn nötig.  
+2. Bucket/Einkauf = Templates auf Archetyp Checklisten.  
+3. Nested Tiefe 3, Multi-Listen, Roll-up Parent←Kinder — vollständiges Modell (siehe Archetyp-Vollspec).  
+4. Listen-Container = Project (`project.checklists`); Punkte = BacklogItem + `parent_id`.

docs/architecture/methods/SPEC_D_continuous_product_v0.1.md

@@ -0,0 +1,170 @@
+# SPEC-D — `continuous_product`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Default für:** B2b `initiative.product`  
+**Komposition:** `agile_iteration`  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Quellen:** Decision-Lock B2b, Archetyp-Vollspec B2b, Kernel Freeze  
+**OM/UI:** `SPEC_B2b_product_v0.1.md` (C1-Maßstab 2026-07-26)
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `continuous_product` |
+| Rolle | primary (**Ausführung** — Kernel §6) |
+| Label (DE) | Kontinuierliches Produkt |
+| Zweck | Dauerhaftes System steuern: Eingang triagieren → Actions committen → wirkungsvollsten Schritt wählen; optional Sprint-Takt. Closure ist **nicht** Kernziel. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default | B2b `initiative.product` |
+| kompatibel als Primary | B2b / `project.product` (+ Kind unter B2a) |
+| Komposition | `agile_iteration` |
+| nicht | A2-Default (Ende/DoD); B1 (Product-Backlog ≠ Checklist-Vorhaben); A1 (Können); B2a-Meta |
+| Dominanz | `plan` (hybrid-light bei kritischen Incidents/Bugs) |
+
+---
+
+## D3 Horizon
+
+| Situation | Horizont |
+|-----------|----------|
+| **Ohne aktiven Sprint** | Orientierungs-Gate (falls genutzt) **oder** „wirkungsvollster Schritt“ über committete Ist-Arbeit + triagierter Eingang |
+| **Mit `agile_iteration` + aktivem Sprint** | Ist-Default = aktiver `work_cycle`; Plan-Orientierung (Gate) bleibt Primary-Nebenblick |
+| **Kein Sprint aktiv** | Komposition wirkungslos → nur Continuous (kein leerer Sprint-Screen) |
+
+---
+
+## D4 Leading Work Item
+
+**Leading:** committete `Action` (ready).  
+**Eingang:** `BacklogItem` bis Commit — triage-/planungsrelevant, nicht Leading Next (außer expliziter „triage next“-Hinweis als Attention/Nebenkanal).
+
+Sprint: Action ∩ `work_cycle_id` des aktiven Sprints (Primary-Ready ∩ Agile-Filter).
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung |
+|---------|--------|-----------|
+| intake | **active** | jederzeit neuer Eingang (Idee, Issue, Bug, Ops) |
+| method_bind | active | Default `continuous_product` |
+| structure_setup | active | Projects (z. B. Entwicklung/Betrieb), optional Orientierungs-Gates, Eingang |
+| planning | active | Triage Backlog; Commit zu Action; mit Agile: Sprint-Planung |
+| next_work | active | Continuous-Ranking oder Sprint-Ready (D6) |
+| assignment | active | Actor an Action |
+| waiting | active | auf Erledigung / Freigaben |
+| result / event | active | done, Evidence, Blocker; Incident-Events |
+| validation | light | Gate-Verify nur wo Orientierungs-Gates genutzt |
+| review | optional | Sprint-Review / Product-Lage |
+| adaptation | **active** | Re-Triage, Replan, Sprint Carryover → Loop zu next_work |
+| closure | **n/a** / selten | kein Closure-Zwang; Archiv nur Ausnahmefall |
+
+---
+
+## D6 Next Action — konkrete Regeln
+
+### Ready (Action)
+
+1. Status ∈ offene Arbeitszustände  
+2. Deps/`requires` erfüllt (falls genutzt)  
+3. nicht blocked  
+4. **Mit aktivem Sprint:** `work_cycle_id` = aktiver Sprint  
+5. **Ohne Sprint:** im Continuous-Horizont (fokussiertes Gate-Segment und/oder priorisierte Ist-Menge — nicht „alle historischen APs“)
+
+### Ranking
+
+**Ohne Sprint:**
+
+1. kritische Issues / Incidents (`product_issue_critical`)  
+2. ready am Orientierungs-Gate / fokussiertem Horizont  
+3. manuelle Prio / Impact / `sort_order`  
+4. reason: `product_next`
+
+**Mit aktivem Sprint:**
+
+1. ready im Sprint (Primary-Ready ∩ Sprint) → `sprint_ready`  
+2. leerer aktiver Sprint → Attention `sprint_empty`, **kein** Ausweichen auf außer-Sprint als Fake-Primary-Next (außer Incident-Override laut Ranking 1 ohne Sprint-Bruch nur wenn Policy es erlaubt — Default: Sprint-Scope hält, Incident = Attention + optional Unplan/Override-Decision)
+
+**Leerer Fall ohne Sprint:** keine ready Action → Attention `planning_debt` / „Eingang triagieren oder committen“ — kein Closure-Druck.
+
+**Anti:** Sprint-Backlog als BacklogItem-Liste; Product-Backlog als B1-Checklisten-Vorhaben; leere Sprint-Sackgasse ohne aktiven Sprint; Closure erzwingen.
+
+---
+
+## D7 Attention
+
+| Code | Wann |
+|------|------|
+| `product_issue_critical` | kritischer Bug/Incident offen |
+| `planning_debt` | Horizont ohne ready Actions / nur untriagierter Eingang |
+| `sprint_empty` | aktiver Sprint ohne Items (Agile) |
+| `sprint_ending` | Sprint-Ende nahe, Überhang |
+| `product_backlog_overflow` | Eingang stark überladen (Schwellwert) |
+| `gate_orient_stale` | Orientierungs-Gate ohne Fortschritt (wenn Gates genutzt) |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| BacklogItem angelegt | Intake; Triage |
+| Commit Backlog → Action | Ready-Menge |
+| Blocker gesetzt/gelöst | Ready/Attention |
+| Incident/Bug kritisch | Ranking/Attention |
+| Sprint activate / complete / carryover / unplan | Agile-Slice (Spec-D `agile_iteration`) |
+| Gate verify (orientierend) | Validation light |
+
+---
+
+## D9 Nested
+
+Kann Kind unter B2a sein — Parent-Impulse ≠ Child-Next. Product-Backlog bleibt am Kind.
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Mit Agile / Gates |
+|---------|-------------------|
+| Initiative B2b + Methode | `work_cycles` |
+| Eingang (Backlog) | Orientierungs-Gates |
+| Commit-Pfad → Action | Evidence/Blocker |
+| | Projects Entwicklung/Betrieb |
+
+---
+
+## D11 Extension Points
+
+| Art | Ziel |
+|-----|------|
+| next_work_strategy | `continuous_product` |
+| attention_rules | D7 |
+| horizon_resolver | Gate und/oder Continuous; Sprint via Komposition |
+| dod_policy | light / n/a (kein Closure-Kern); Gate optional |
+| composes_with | `agile_iteration` |
+| steering_elements | `next_action_primary`, `work_cycle_scope`, `gate_fulfillment` (orientierend) |
+| compatible_archetype_keys | `initiative.product` |
+| data_slices | backlog, actions, roadmap, projects, blockers, evidence, decisions, reviews, work_cycles, steering_methods |
+
+---
+
+## D12 Spannungen · PO
+
+| Punkt | Lage |
+|-------|------|
+| Closure n/a | Kernel erlaubt; Produkt-Natur |
+| Sprint optional | Komposition; ohne Sprint nur Primary |
+| ≠ B1 | Product-Backlog = Eingang dieses Vorhabens |
+| Incident hybrid-light | Event darf Ranking drücken, ersetzt Primary nicht |

docs/architecture/methods/SPEC_D_dispute_procedure_v0.1.md

@@ -0,0 +1,194 @@
+# SPEC-D — `dispute_procedure`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Default für:** C1 `initiative.dispute_case`  
+**OM-Struktur:** `SPEC_C1_dispute_case_v0.1.md` §4  
+**Nicht:** Workflow-Engine-Runtime · künstliche Parallel-/Dep-Limits · keine Rechts-Fachlogik
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `dispute_procedure` |
+| Rolle | primary (**Ausführung** — Kernel §6) |
+| Label (DE) | Verfahrenssteuerung |
+| Zweck | Event→Reaktionsstrang steuern (reaktiv dominant): parallele/abhängige Schritte, Dritt-Actors, Fristen; optional **vorbereitete** Stränge aktivieren; Waiting ≠ Fall-Freeze. Closure am Fallende. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default | C1 `initiative.dispute_case` |
+| kompatibel als Primary | nur C1 |
+| Komposition | — |
+| Dominanz | `event` |
+| nicht | Care; A3-Cadence-Kern; offene Workflow-Engine |
+
+---
+
+## D3 Horizon
+
+| Horizont | Bedeutung |
+|----------|-----------|
+| Aktive `procedure_phase` | Phasen-Fokus |
+| Aktive Reaktionsstränge | steuerungsrelevante Arbeitscluster (`active`) |
+| Vorbereitete Stränge | Plan-Nebenblick (`prepared`) — nicht Next |
+| Nächste Frist(en) | Schritt-, Strang- oder Phasen-Deadline |
+
+---
+
+## D4 Leading Work Item
+
+Polymorph:
+
+| Typ | Wann |
+|-----|------|
+| `Action` (ready) | Deps erfüllt, nicht im Waiting, nicht blocked |
+| `Decision` | offene Entscheidungspflicht |
+| Strang-/Schritt-Frist | fällige/überfällige Deadline-Arbeit |
+
+Primary-Next = Top-Rank eines ready Items. **Weitere parallele Ready-Items** sind Nebenkandidaten (sichtbar), kein Singleton-Zwang der Ready-Menge.
+
+Waiting-Schritt ist **nicht** Leading, erzeugt Attention; parallele Ready-Geschwister bleiben Leading-fähig.
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung |
+|---------|--------|-----------|
+| intake | active | Fall, Parteien/Actors (inkl. Dritte) |
+| method_bind | active | `dispute_procedure` |
+| structure_setup | active | Phasen; Event-Eingang; Strang-Editor (prepared/active) |
+| planning | light | vorbereiten & nachziehen — **kein** Vollplanungszwang; Dominanz bleibt event/reaktiv |
+| next_work | active | Ready nur aus `active`-Strängen (D6) |
+| assignment | active | Actor je Schritt (Selbst, Anwalt, …) |
+| waiting | **central** | am Schritt/Strang — Fall bleibt steuerbar |
+| result / event | **central** | Actor-Done + externe Events |
+| validation | active | Phasen-/Strang-Kriterien |
+| review | active | Decisions |
+| adaptation | active | Strang erweitern, Deps/Fristen ändern nach Event |
+| closure | **active** | Fallende |
+
+---
+
+## D6 Next Action — konkrete Regeln
+
+### Ready
+
+Action/Decision ist ready wenn:
+
+1. Strang-Status = **`active`** (nicht `prepared`), und  
+2. Status offen, und  
+3. alle `requires`-Vorgänger erfüllt, und  
+4. **nicht** im Waiting-Zustand, und  
+5. nicht durch Blocker gesperrt  
+
+Parallel: fehlende Dep ⇒ gleichzeitig ready — **ohne Obergrenze** für parallele Schritte oder parallele `active`-Stränge.  
+Deps: gerichteter azyklischer Graph, **ohne** Maximaltiefe/-kanten-Cap; Zyklen = Validierungsfehler.  
+`prepared`: nicht ready. Strang-übergreifende `requires` erlaubt.
+
+### Ranking
+
+1. überfällige Schritt-/Strang-/Phasen-Frist  
+2. heute fällige Frist / Fenster-Druck  
+3. offene Pflicht-Decision  
+4. ready Schritte (Owner Selbst vor optionaler Anzeige Dritter — oder nach `due`/`sort_order`)  
+5. reine Waiting-Hinweise → Attention, nicht Fake-Next
+
+**reason_codes:**  
+`dispute_deadline_overdue`, `dispute_deadline`, `dispute_decision_open`, `dispute_phase_step`, `dispute_parallel_ready`, `dispute_waiting_event`
+
+**Leerer Fall:** nur Waiting, keine parallele Ready-Arbeit → Next leer + Attention `dispute_waiting` (kein A2-Planning-Debt).
+
+**Anti:** Waiting friert Fall; `prepared` als Ready; Todo-Wand; Engine-Runtime; Pflicht-Vollplanung; künstliche Caps auf Parallelität/Deps.
+
+### Event / Result → Strang (Steuerregel)
+
+1. **Neu reaktiv:** Event/manuell → Strang `active` mit 1..n Schritten.  
+2. **Aktivierung:** Event, Actor-Result, Decision-Outcome oder manuell → passenden Strang `prepared` → `active` (Aktivierungsregel am Strang oder Auswahl-UI).  
+3. **Erweitern:** Adaptation fügt Schritte an `active`-Strang an; kein Duplikat-Chaos.  
+4. **Weiche:** ein Outcome aktiviert genau einen (oder bewusst mehrere) vorbereitete Stränge — deklarativ, keine offene Engine.
+
+---
+
+## D7 Attention
+
+| Code | Wann |
+|------|------|
+| `dispute_deadline_overdue` | Frist überschritten |
+| `dispute_deadline_soon` | Frist/Fenster nahe |
+| `dispute_decision_stale` | Decision ohne Fortschritt |
+| `dispute_waiting` | Strang/Schritt wartet (extern) |
+| `dispute_third_party_stale` | zugewiesener Dritt-Actor ohne Rückmeldung über Schwellwert |
+| `dispute_phase_stalled` | Phase ohne Ready und ohne begründetes Waiting |
+| `dispute_unscoped_event` | Event ohne Strang/Phase-Zuordnung und ohne aktivierbaren prepared-Strang |
+| `dispute_dep_blocked` | kritische Dep blockiert fristrelevanten Schritt |
+| `dispute_prepared_pending` | Outcome/Event legt Aktivierung nahe, passender prepared-Strang noch nicht aktiviert |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| Brief / Dokument | Evidence; `active`-Strang öffnen/erweitern **oder** `prepared` aktivieren |
+| Termin gesetzt | Schritt/Frist; ggf. Waiting |
+| Gegenseite / Behörde | Ready/Decision; Waiting lösen; ggf. prepared aktivieren |
+| Fristablauf | Attention + Pflicht-Schritt/Decision |
+| Actor-Result (inkl. Dritte) | Schritt done; Deps freigeben; **kann** prepared-Strang aktivieren |
+| Decision-Outcome | Pfad fortsetzen, Closure, **oder** vorbereiteten Strang aktivieren |
+| Phasen-Kriterien | nächste Phase |
+| Fallabschluss | Closure |
+
+---
+
+## D9 Nested
+
+Kann Kind unter B2a sein. Parent-Impulse ≠ Child-Next.
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Vollmodell |
+|---------|------------|
+| C1 + Methode | mehrere Phasen |
+| Event-Eingang | Reaktionsstränge mit strand_id |
+| Actions + `requires` | parallele Ready-Mengen |
+| Assignment (Actors) | Dritt-Actors |
+| Fristen an Action | Strang-/Phasen-Fenster |
+| Waiting an Action/Strang | Evidence, Decision, Closure |
+
+---
+
+## D11 Extension Points
+
+| Art | Ziel |
+|-----|------|
+| next_work_strategy | `dispute_procedure` (Parallel-Ready + Ranking) |
+| attention_rules | D7 |
+| horizon_resolver | Phase + Stränge + Fristen |
+| event_hooks | Event→Strang öffnen/erweitern |
+| assignment_policy | inkl. Dritt-Actors |
+| steering_elements | `next_action_primary`, `dispute_timeline` |
+| compatible_archetype_keys | `initiative.dispute_case` |
+| data_slices | actions, roadmap, evidence, decisions, blockers, reviews, steering_methods |
+
+---
+
+## D12 Spannungen · PO
+
+| Punkt | Lage |
+|-------|------|
+| Komplexität | beliebig viele Stränge/Deps/Parallelen — **keine** Produktlimits |
+| Optik | Graph/Timeline als Hilfe, nicht als Engine |
+| prepared → active | verbindlich; reaktiv dominant |
+| Waiting ≠ Freeze | verbindlich |
+| Dritte | Actors + Assignment |

docs/architecture/methods/SPEC_D_generic_operating_v0.1.md

@@ -0,0 +1,105 @@
+# SPEC-D — `generic_operating`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Rolle:** Primary (**Ausführung**, dünn) — Fallback / Übergang  
+**Default für:** `initiative.generic`  
+**Nicht:** empfohlen für neue Vorhaben
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `generic_operating` |
+| Rolle | primary (**Ausführung**, absichtlich dünn — Kernel §6) |
+| Label (DE) | Generischer Betrieb |
+| Zweck | Minimale Steuerung ohne Vorhaben-Natur: offene Actions grob priorisieren; Attention „Struktur/Methode fehlt“; Übergang zu konkreter Primary. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default | `initiative.generic` |
+| kompatibel | nur generic (Übergang: Methode wechseln → anderer Archetyp empfohlen) |
+| Komposition | — |
+| Dominanz | `plan` (sehr dünn) |
+| nicht | als Dauer-Default für neue Vorhaben |
+
+---
+
+## D3 Horizon
+
+Schwach / keiner — kein Gate-, Cadence- oder Phasen-Horizont als Pflicht.
+
+---
+
+## D4 Leading Work Item
+
+Offene `Action`, grob priorisiert (`sort_order` / Fälligkeit falls vorhanden).
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung |
+|---------|--------|-----------|
+| intake | active | Vorhaben existiert |
+| method_bind | active | Fallback; Wechsel zu konkreter Methode empfohlen |
+| structure_setup | light | optional |
+| planning | light / n/a | |
+| next_work | active | nächste offene Action |
+| assignment | active | |
+| waiting | light | |
+| result / event | active | |
+| validation | n/a | |
+| review | n/a | |
+| adaptation | light | Archetyp/Methode wechseln |
+| closure | optional | |
+
+---
+
+## D6 Next Action
+
+**Ready:** offene Action.  
+**Ranking:** manuelle Prio / due / sort_order.  
+**reason_codes:** `generic_next_action`, `generic_unstructured`.  
+**Leerer Fall:** keine Action → Attention `generic_needs_archetype` (nicht „Erfolg wie A3 im Takt“).
+
+---
+
+## D7 Attention
+
+| Code | Wann |
+|------|------|
+| `generic_needs_archetype` | Vorhaben noch generic / ohne spezifische Struktur |
+| `generic_method_drift` | Daten legen anderen Archetyp nahe (optional Heuristik) |
+
+---
+
+## D8 Events
+
+Standard Actor-Result. Keine Fall-/Cadence-Spezialevents.
+
+---
+
+## D9 Nested
+
+Kann Kind unter B2a sein — unerwünscht dauerhaft; Migration zu konkretem Kind-Archetyp.
+
+---
+
+## D10–D11
+
+OM: actions minimal. Elements: `next_action_primary`.  
+`compatible_archetype_keys`: `initiative.generic`.
+
+---
+
+## D12
+
+PO: Create-UI zeigt primär konkrete Archetypen; `generic` nur Altbestand / expliziter Notfall.

docs/architecture/methods/SPEC_D_maturity_progression_v0.1.md

@@ -0,0 +1,196 @@
+# SPEC-D — `maturity_progression`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Default für:** A1 `initiative.maturity_journey`  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Quellen:** Decision-Lock A1, Archetyp-Vollspec A1, Kernel Freeze, AP2.0e  
+**OM-Struktur (Stage Activity Set, Felder):** verbindlich in `SPEC_A1_maturity_journey_v0.1.md` §4 / §10
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `maturity_progression` |
+| Rolle | primary (**Ausführung** — Kernel §6) |
+| Label (DE) | Reifegrad-Progression |
+| Zweck | Fähigkeit über Stufen steuern: Active Stage als Horizont; Next = fällige/alternierende Übung oder Stage-Action; bei Stage `reached` Activity Set wechseln. Weiches Vorhaben-Ende. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default | A1 `initiative.maturity_journey` |
+| kompatibel | nur A1 (Project-Spiegel `project.maturity_journey`) |
+| nicht | Care (Wohlergehen); A3 (Rhythmus ohne Stufen); A2 (Liefer-DoD) |
+| Dominanz | `hybrid` — Cadence-Zeit (Event) + Stufen-Plan (Plan) |
+
+---
+
+## D3 Horizon
+
+| Horizont | Bedeutung |
+|----------|-----------|
+| **Aktive `maturity_stage`** | fokussierte Stufe; nur deren Stage Activity Set liefert Next |
+| Plan-Nebenblick | nächste Stufe / Graph-Voraussetzungen — nicht Leading für Next |
+| Ist | CadenceInstances + Stage-Actions der aktiven Stufe |
+
+Keine Next-Kandidaten aus inaktiven Stufen.
+
+---
+
+## D4 Leading Work Item
+
+**Primär:** `CadenceInstance` (Übung/Ritual am RecurringElement der aktiven Stufe).  
+**Sekundär:** `Action` (Stage-gebunden: Prüfung, Workshop, Nachweis).  
+**Hinweis-Objekt (kein Leading Work):** offenes Stufen-Kriterium / Verify-Fortschritt — erscheint in Next/Attention als Steuerhinweis.
+
+Pro Recurring: genau **eine** offene Instanz (kein Duplikat bei Verpassen).
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung |
+|---------|--------|-----------|
+| intake | active | Fähigkeit/Fokus, Vorhaben anlegen |
+| method_bind | active | Default `maturity_progression` |
+| structure_setup | active | Stufen, Graph, Stage Activity Sets (Recurrings + Stage-Actions), Alternanz-Gruppen |
+| planning | light | Fokus/Frequenz; keine Vollprojekt-Planungspflicht |
+| next_work / action_selection | active | Ready-Menge + Ranking (D6) |
+| assignment | active | Owner-Actor an Ritual/Action (oft Selbst) |
+| waiting | active | auf Cadence-Zeitpunkt / Erfüllung |
+| result / event | active | practice done; externe/situative Events möglich |
+| dod / validation | active | Stufenkriterien + Evidence vor `reached` |
+| review | optional | bei Stufenwechsel / Nachweis — nicht jede Übung |
+| adaptation | active | Set-Wechsel bei `reached`; manuelle Set-/Cadence-/Alternanz-Änderung |
+| closure | soft / skip | Vorhaben-Ende nicht erzwungen |
+
+Kernel-Schlitznamen: Abbildung auf §4 Kernel (Intake … Closure).
+
+---
+
+## D6 Next Action — konkrete Regeln
+
+### Ready-Menge (aktive Stufe)
+
+Ein Work Item ist ready, wenn:
+
+1. gebunden an die **aktive** `maturity_stage` und Aktivität **aktiv**, und  
+2. eines von:
+   - **Cadence ohne Alternanz:** Instanz fällig oder überfällig (heute laut Cadence / overdue), oder  
+   - **Cadence in Alternanz-Gruppe:** Instanz ist das **aktuelle** Gruppenmitglied **und** fällig/überfällig (bzw. „dran“ laut Gruppenpolicy, wenn Cadence der Gruppe geteilt ist), oder  
+   - **Stage-Action:** Status offen und Deps/Blocker erlauben Arbeit  
+
+**Nicht ready:** Mitglieder einer Alternanz-Gruppe, die nicht aktuell sind — auch wenn ihre Kalender-Cadence „heute“ wäre.
+
+### Ranking
+
+1. überfällige CadenceInstances (inkl. Alternanz-aktuell overdue)  
+2. heutige fällige Cadences (ohne Alternanz)  
+3. Alternanz-aktuell (fällig / dran)  
+4. offene Stage-Actions (sort_order / Fälligkeit)  
+5. Steuerhinweis offenes Stufen-Kriterium (wenn Verify offen und keine höher priorisierte Arbeit)
+
+**reason_codes:**
+
+| Code | Bedeutung |
+|------|-----------|
+| `maturity_practice_overdue` | Übung überfällig |
+| `maturity_today_practice` | Übung heute fällig |
+| `maturity_alternation_current` | aktuelles Alternanz-Mitglied |
+| `maturity_stage_action` | Stage-Action |
+| `maturity_stage_criteria` | Kriterien/Verify-Hinweis |
+
+**Leerer Fall:** aktive Stufe, nichts fällig → „nächste geplante Übung am …“ / Fokus auf Kriterien — **keine** Fake-Action, **keine** Todo-Wand aus allen Stufen.
+
+### Alternanz (Steuerregeln)
+
+1. Pro `alternation_group_id` genau ein aktuelles Mitglied (State am Group- oder Recurring-Kontext).  
+2. Nach erfolgreicher Erfüllung des aktuellen Mitglieds: Rotation zum nächsten `alternation_order` (zyklisch).  
+3. Attention bei overdue nur auf aktuelles Mitglied.  
+4. Bei Stage-Wechsel: Gruppen der alten Stufe inaktiv; neue Stufe eigene Gruppen.
+
+### Zeitversatz
+
+Unabhängige Cadences am gleichen Stage → mehrere ready am selben Tag möglich; Ranking wie oben. Kein Zwang zur Alternanz.
+
+---
+
+## D7 Attention
+
+| Code | Wann |
+|------|------|
+| `maturity_practice_overdue` | fällige/überfällige Übung (inkl. Alternanz-aktuell) |
+| `maturity_alternation_blocked` | aktuelles Mitglied dauerhaft nicht erfüllbar / ohne Owner |
+| `maturity_stage_stagnant` | aktive Stufe ohne Fortschritt (keine fulfilled practice / kein Kriterien-Fortschritt über Schwellwert) |
+| `maturity_criteria_open` | Verify/Kriterien offen bei sonst leerer Ready-Menge oder Stage „bereit“ |
+| `maturity_inactive_set` | aktive Stufe ohne aktives Activity Set (Strukturfehler) |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| practice done / Cadence erfüllt | Instanz schließen; nächste Instanz laut Cadence; bei Alternanz Rotation |
+| Stage-Action done | aus Ready; ggf. Kriterien-Fortschritt |
+| Evidence / Kriterium erfüllt | Validation-Fortschritt |
+| stage `reached` (Verify ok) | altes Activity Set deaktivieren; nächste Stufe aktiv; neues Set aktiv (AP2.0e erweitert) |
+| manuelle Adaptation (Set/Cadence/Alternanz) | Ready-Menge neu; auditiert |
+| Cadence-Zeitpunkt erreicht | Event-Schub → Ready neu bewerten |
+
+---
+
+## D9 Nested
+
+`n/a` als Parent-Methode. Kann Kind unter B2a sein — dann Parent-Impulse ≠ Child-Next (Kernel Q4).
+
+Multi-Fähigkeit = mehrere Projects im selben Vorhaben, **kein** Nested-Parent/Child im Methoden-Sinn.
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Optional / Template |
+|---------|---------------------|
+| Initiative A1 + Methode gebunden | Graph-Voraussetzungen |
+| ≥1 `maturity_stage`, eine aktiv | mehrere Fähigkeits-Projects |
+| Stage Activity Set der aktiven Stufe (≥1 Recurring oder Stage-Action) | Alternanz-Gruppen |
+| Recurring: Stage-Bindung, Cadence, aktiv/inaktiv | EFS Fokus/Frequenz |
+| Evidence/Kriterien-Pfad für Verify | |
+
+Felder `alternation_group_id`, `alternation_order`: Archetyp-Vollspec A1 §10.
+
+---
+
+## D11 Extension Points
+
+| Art | Ziel |
+|-----|------|
+| next_work_strategy | `maturity_progression` |
+| attention_rules | Codes D7 |
+| horizon_resolver | aktive `maturity_stage` |
+| dod_policy | Stage-Kriterien / Verify |
+| adaptation_hooks | `on_stage_reached` → Set-Wechsel; manuelle Set-Änderung |
+| steering_elements | `next_action_primary`, `maturity_stage`, `recurring_rhythm` |
+| compatible_archetype_keys | `initiative.maturity_journey` |
+| data_slices | recurring, roadmap, actions, evidence, decisions, reviews, projects, steering_methods |
+
+---
+
+## D12 Spannungen · PO
+
+| Punkt | Lage |
+|-------|------|
+| Hybrid Dominanz | Cadence-Event + Stage-Plan — Kernel trägt Dual-Auslöser |
+| Leading polymorph | Cadence + Action — Kernel Q2 |
+| Alternanz-State | Persistenz am Group-/Recurring-Kontext — Implementierungsdetail, fachlich hier verbindlich |
+| Multi-Fähigkeit | mehrere Projects ok; kein Abnahme-Zwang für Kern-Kit |
+
+**PO-Empfehlung:** A1-Vollspec §4 OM + diese Spec-D = Steuervertrag; UI nur in Archetyp-Vollspec.

docs/architecture/methods/SPEC_D_program_delivery_v0.1.md

@@ -0,0 +1,188 @@
+# SPEC-D — `program_delivery`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Quellen:** Decision-Lock B2a, `SPEC_B2a_program_v0.1.md`, Fit-Analyse, Ist-Code `ProgramDeliveryStrategy` (⚠ Gap)  
+**OM/UI:** Archetyp-Vollspec B2a
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `program_delivery` |
+| Rolle | primary (**Meta** — Kernel §6; kein Ausführungs-Leading der Kinder) |
+| Label (DE) | Programm-Lieferung / Programm-Controlling |
+| Zweck | Steuert den **Schirm** über Kind-Kontexte: Lagebild, Kreuz-Abhängigkeiten, Roadblocker, Priorisierungsimpulse, Programm-Horizont/Closure. **Ersetzt nicht** die Next Action der Kinder. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default für | B2a `initiative.program` |
+| kompatibel | `initiative.program` |
+| nicht | als Default für A2-Einzelprojekt (dort `sequential_dependency`); nicht für dauerhaftes Product ohne Abschluss-Natur |
+
+---
+
+## D3 Horizon
+
+| Ebene | Horizont |
+|-------|----------|
+| **Programm-Plan** | übergreifende Zielzustände / Phasen-Meilensteine des Programms |
+| **Programm-Steuerung** | Menge der Kind-Kontexte + deren Blockade-/Fortschrittslage |
+| **Nicht** | Sprint der Kinder als Programm-Horizon (Kinder behalten eigene Modifier) |
+
+---
+
+## D4 Leading Work Item
+
+**Zielbild (Decision-Lock):** Leading Object auf Programmebene = **`ProgramImpulse`** (Priorisierungs-/Roadblocker-Empfehlung), **nicht** die konkrete Child-Action.
+
+| Objekt | Ebene |
+|--------|-------|
+| `ProgramImpulse` | Parent — „Kind X zuerst entblocken / Priorität verschieben“ |
+| Child Next Action (`Action` / …) | Kind-Methode — unverändert |
+
+**Ist-Code (Abweichung):** Strategy liefert heute ready **Actions am Programm-Initiative** + Gate-Reviews — als wäre das Programm ein flaches A2/B2. Das unterläuft Nested-Entscheidung.
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung Programm |
+|---------|--------|-------------------|
+| intake | active | Programmziel, Scope, Abschlussabsicht |
+| method_selection | active | Default `program_delivery` |
+| structure_setup | active | Programm-Meilensteine + **Kind-Kontexte** anbinden (Initiativen/Projects mit eigenem Archetyp/Methode) |
+| planning | active | übergeordnete Priorisierung / Reihenfolge der Kinder-Horizonte — nicht AP-Feinplanung der Kinder |
+| action_selection | **umgedeutet** | wählt **Impulse**, nicht Child-AP als „die“ Next Action des Programms |
+| assignment | skip/optional | selten auf Meta-Ebene; Arbeit liegt in Kindern |
+| waiting | active | auf Kind-Fortschritt / externe Programm-Lage |
+| result_intake | active | Kind-Statusänderungen, Programm-Meilenstein-Evidence |
+| validation | active | Programm-Gate/Meilenstein-Kriterien |
+| review | active | Programm-Reviews, Go/No-Go zwischen Phasen |
+| adaptation | active | Kinder umpriorisieren, Scope des Programms anpassen |
+| closure | active | **erwartet** — Programm hat Ende (≠ Product) |
+
+---
+
+## D6 Next Action / Impulse — konkrete Regeln (Zielbild)
+
+**Auf dem Programm-Kontext zeigt die Steuerung zwei getrennte Kanäle:**
+
+| Kanal | Inhalt | UI/API-Semantik |
+|-------|--------|-----------------|
+| **A — Child Next Actions** | unverändert von Kind-Methode | Scope = Kind; Programm listet/aggregiert höchstens |
+| **B — Program Impulse** | Empfehlung mit reason_code | Scope = Programm; **kein** Ersatz für A |
+
+**Impulse-Ranking (Ziel):**
+
+1. Kreuz-Abhängigkeit / Roadblocker, der ≥2 Kinder oder Programm-Meilenstein blockiert  
+2. Kind auf kritischem Programm-Pfad ohne Fortschritt  
+3. Priorisierungsempfehlung (Portfolio-/Programm-Rang zwischen Kindern)  
+4. Programm-Meilenstein mit offenen Kriterien ohne zurechenbares Kind
+
+**reason_codes (Ziel):** `program_roadblocker`, `program_cross_dependency`, `program_child_stalled`, `program_priority_shift`, `program_milestone_risk`
+
+**Leerer Fall:** keine Impulse und Kinder ohne Attention → Programm-Lage „stabil“; trotzdem Child-NAs in Kindern sichtbar — Programm zeigt nicht „nichts zu tun“ indem es Child-APs als eigene NA ausgibt.
+
+**Verboten (Zielbild):**
+
+- Programm-`action_selection` gibt Child-Action als *die* Next Action des Programms aus und suggeriert, das Programm steuere die AP-Reihenfolge restriktiv wie A2
+
+---
+
+## D7 Attention
+
+| Code (Ziel) | Wann |
+|-------------|------|
+| `program_roadblocker` | Blocker/Dep über Kinder hinweg |
+| `program_milestone_at_risk` | Programm-Gate gefährdet |
+| `program_child_stalled` | Kind ohne Fortschritt am kritischen Programm-Pfad |
+| `program_orphan_work` | Arbeit ohne Zuordnung zu Kind/Meilenstein |
+| `program_closure_ready` | alle Kinder/Meilensteine closure-fähig |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| Kind Next Action / Statusänderung | Programm-Lage + Impulse neu |
+| Kreuz-Dep angelegt/gelöst | Impulse + Attention |
+| Programm-Meilenstein verify | Horizont |
+| Kind Archetyp/Methode gewechselt | Hybrid bleibt erlaubt; Impulse neu bewerten |
+| Kind closure | Programm-Closure-Prüfung |
+
+---
+
+## D9 Nested — Kernanker (Härtetest)
+
+```text
+Program Context (method = program_delivery)
+  ├── Impulse / Attention / Programm-Horizont / Closure
+  └── Child Context 1 (eigene Methode, z. B. sequential_dependency)
+  └── Child Context 2 (eigene Methode, z. B. continuous_product oder A2 Content)
+        └── deren Next Action unverändert
+```
+
+**PO ✓ Decision-Lock:** konkrete Next Action auf Projektebene; Programm = übergeordnete Impulse.
+
+**Kern-Konsequenz:** Kandidat-Anker **D Nested Steering** und **polymorphes Work Item (`ProgramImpulse`)** sind für diese Methode **nicht optional**.
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Optional |
+|---------|----------|
+| Programm-Initiative + `program_delivery` | Programm-Backlog (Eingang) |
+| ≥1 Programm-Meilenstein/Phase | work_cycle nur wenn Modifier auf Kind oder explizit am Programm gewünscht |
+| ≥1 Kind-Kontext (Initiative oder Project mit eigenem Steering) | Kreuz-Deps als Graph-Kanten zwischen Kind-Horizonten / Programm-Items |
+| Lagebild-Read-Model über Kinder | |
+
+**Offen modellseitig:** Sind Kinder **eigene Initiativen** unter einem Programm-Portfolio-Link, oder **Projects** mit eigenem `method_key`-Override unter einer Programm-Initiative? Decision-Lock erlaubt hybrid inhaltlich — **Datenmodell muss in D12 entschieden werden**.
+
+---
+
+## D11 Extension Points
+
+| Art | Ziel |
+|-----|------|
+| next_action_strategy | `program_delivery` → Impulse-Kanal; Aggregation Child-NA getrennt |
+| steering_elements | `next_action_primary` (Impulse), `gate_fulfillment` (Programm), neu z. B. `program_child_lage` / `cross_dependency` |
+| graph_profile | Programm-Meilensteine; Kreuz-Deps |
+| ui_features | Programm-Lage vs. Child-Drilldown getrennt |
+| hooks | `on_next_action_requested` (Impulse), `on_replan_required`, `on_closure_requested`, Kind-Status-Hooks |
+
+---
+
+## D12 Spannungen — Ist vs. Ziel · offene PO-Punkte
+
+| Spannung | Detail |
+|----------|--------|
+| **Ist-Code ≠ Decision-Lock** | `ProgramDeliveryStrategy` ≈ Gate-ready Actions auf derselben Initiative — **kein** Nested/Impulse-Modell |
+| **Katalog v0.2 veraltet** | „Next Action: nächstes Gate/AP am Programm-Horizont“ widerspricht Interview |
+| **Kern** | Ohne Nested + ProgramImpulse bricht diese Methode den Kandidat-Kern |
+
+**PO ✓ (2026-07-25):**
+
+1. **Kind-Modell:** beides erlaubt; Logik adressiert Child SteeringContext; Primärbild Projects + `method_key`-Override, verlinkte Initiativen optional später.  
+2. **Programm-Widget:** Impulse primär; Child-NAs als klar getrennter zweiter Block.  
+3. **Programm-Büro-Actions:** erlaubt, sekundär — dürfen Impulse-NA nicht ersetzen/tarnen.
+
+---
+
+## Bezug sequential_dependency
+
+Als Kind-Methode unverändert (`SPEC_D_sequential_dependency`). Programm darf Kind-NA nicht überschreiben.
+
+## Nächste Methode
+
+Härtetest Multi-Leading-Object: **`care_navigation`**.

docs/architecture/methods/SPEC_D_recurring_control_v0.1.md

@@ -0,0 +1,171 @@
+# SPEC-D — `recurring_control`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**Default für:** A3 `initiative.recurring_program`  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Quellen:** Decision-Lock A3, Archetyp-Vollspec A3, Kernel Freeze  
+**OM-Struktur:** verbindlich in `SPEC_A3_recurring_program_v0.1.md`
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `recurring_control` |
+| Rolle | primary |
+| Label (DE) | Rhythmus-Steuerung |
+| Zweck | Systemgesundheit über wiederkehrende Rituale steuern: Next = fällige/überfällige CadenceInstance; eine offene Instanz pro Rhythmus; Abweichung/Score sichtbar — kein Todo-Duplikat bei Verpassen. |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default | A3 `initiative.recurring_program` |
+| kompatibel als Primary | nur A3 / `project.recurring_program` |
+| Komposition | `agile_iteration` (Sprint-Slice für Actions; Cadence bleibt Leading der Primary) |
+| nicht | Care; A1; B1 als Primary-Ersatz |
+| Dominanz | `event` — Cadence führt; bei Agile zusätzlich plan-Slice auf Actions |
+
+---
+
+## D3 Horizon
+
+| Horizont | Bedeutung |
+|----------|-----------|
+| **Zeitfenster „heute / fällig / überfällig“** | über alle aktiven Rituale (optional gefiltert nach Domain-Project) |
+| Domain-Filter | aktiver Domain-Ausschnitt (Project) — optional, nicht Pflicht für Next |
+| Gates | nicht steuerungsführend (`n/a` / light) |
+
+---
+
+## D4 Leading Work Item
+
+**`CadenceInstance`** am `RecurringElement`.
+
+- Pro Ritual genau **eine** offene Instanz.  
+- Verpassen → Instanz bleibt / eskaliert (Attention, Score) — **kein** zweites offenes Duplikat.  
+- `Action` nur für Ausnahme/Eskalation (Reparatur, Sonderarbeit), nicht Leading für Normalzyklus.
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status | Bedeutung |
+|---------|--------|-----------|
+| intake | active | System/Domains/Rhythmen erfassen |
+| method_bind | active | Default `recurring_control` |
+| structure_setup | active | Domain-Projects, RecurringElements, Owner-Actors, Cadences |
+| planning | n/a | keine Gate-/Lieferplanung als Kern |
+| next_work / action_selection | active | fällige/überfällige Instanzen (D6) |
+| assignment | active | Owner; optionale freiwillige Übernahme |
+| waiting | active | auf Cadence-Zeitpunkt |
+| result / event | active | erledigt → genau eine nächste Instanz planen |
+| dod / validation | light | optional Qualitätscheck am Ritual — nicht Gate-DoD |
+| review | light | periodischer System-Health-Blick |
+| adaptation | active | Cadence/Owner/Score-Parameter anpassen |
+| closure | skip | Dauerprogramm — Closure nicht erwartet |
+
+---
+
+## D6 Next Action — konkrete Regeln
+
+### Ready
+
+CadenceInstance ist ready, wenn:
+
+1. Ritual aktiv, und  
+2. Instanz offen, und  
+3. Fälligkeit ≤ jetzt (fällig/heute) **oder** überfällig, und  
+4. nicht durch Blocker gesperrt (sonst Attention)
+
+### Ranking
+
+1. überfällig (älter zuerst / höherer Abweichungs-Score zuerst)  
+2. heute fällig  
+3. als Nächstes geplant (nur Anzeige/Hinweis, nicht als Fake-Druck-Next)
+
+**reason_codes:** `recurring_overdue`, `recurring_due`, `recurring_next_scheduled`
+
+**Leerer Fall:** nichts fällig → „System im Takt“ / nächste Fälligkeit — Erfolg, nicht Planning Debt.
+
+**Anti:** alle historischen Verfehlungen als Task-Wand; Gates als Leading Horizon.
+
+### Komposition `agile_iteration`
+
+Bei aktivem Sprint (siehe Spec-D Agile):
+
+1. CadenceInstance overdue/due bleibt Ready und rankt **vor** Sprint-Actions.  
+2. Sprint filtert **Actions** (Verbesserung/Sonderarbeit), nicht Ritual-Instanzen.  
+3. reason_codes Primary unverändert; zusätzlich Agile-Codes für Sprint-Actions.  
+4. Ohne aktiven Sprint: nur diese Primary.
+
+---
+
+## D7 Attention
+
+| Code | Wann |
+|------|------|
+| `recurring_overdue` | Instanz überfällig |
+| `recurring_deviation` | Abweichungs-Score über Schwellwert (verpasste Zyklen, Verspätung) |
+| `recurring_unowned` | Ritual ohne Owner-Actor |
+| `recurring_stale_definition` | Ritual lange ohne erfolgreichen Zyklus trotz aktiv |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| Cadence-Zeitpunkt | Event-Schub → Ready |
+| Instanz erledigt | schließen; genau eine nächste Instanz; Score aktualisieren |
+| Verpasst / überfällig | Score/Attention; **keine** zweite Instanz |
+| Owner-Wechsel / Übernahme | Assignment; Audit |
+| Cadence geändert | Adaptation; nächste Fälligkeit neu |
+
+---
+
+## D9 Nested
+
+`n/a` primary. Kann Kind unter B2a sein — Parent-Impulse ≠ Child-Next.
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Vollmodell |
+|---------|------------|
+| Initiative A3 + Methode | Domain-Projects |
+| ≥1 RecurringElement mit Cadence + Owner | Multi-Actor / Übernahme |
+| eine offene Instanz-Semantik | Abweichungs-Score je Ritual/Domain |
+| | optionale Eskalations-Action |
+
+---
+
+## D11 Extension Points
+
+| Art | Ziel |
+|-----|------|
+| next_work_strategy | `recurring_control` |
+| attention_rules | Codes D7 |
+| horizon_resolver | Zeitfenster + optional Domain |
+| dod_policy | light / n/a |
+| adaptation_hooks | Cadence, Score, Owner |
+| steering_elements | `next_action_primary`, `recurring_rhythm` (+ `work_cycle_scope` bei Agile) |
+| compatible_archetype_keys | `initiative.recurring_program` |
+| composes_with | `agile_iteration` |
+| data_slices | recurring, projects, actions, blockers, steering_methods (+ work_cycles bei Agile) |
+
+---
+
+## D12 Spannungen · PO
+
+| Punkt | Lage |
+|-------|------|
+| Event-Dominanz | Kernel Dual-Auslöser — Plan-Zug dünn ok |
+| Score | Teil des vollständigen Steuerungsmodells; Implementierungs-Schnitt in APs |
+| ≠ Care / ≠ A1 | Gegenstand = Systemrhythmus, nicht Wohlergehen oder Können-Stufen |

docs/architecture/methods/SPEC_D_sequential_dependency_v0.1.md

@@ -0,0 +1,170 @@
+# SPEC-D — `sequential_dependency`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — mit zugehöriger Archetyp-Vollspec; Implementierungsausreichendheit noch offen
+**Stand:** 2026-07-26  
+**OM/UI:** `SPEC_A2_linear_project_v0.1.md`  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md` (+ Kurskorrektur: konkrete Steuerungsregeln)  
+**Quellen:** Decision-Lock A2, ADP Execution Plan / AP1.16, Fit-Analyse, Code `execution_ready` / graph-state
+
+---
+
+## D1 Identität — PO ✓
+
+| Feld | Wert |
+|------|------|
+| `method_key` | `sequential_dependency` |
+| Rolle | primary (**Ausführung** — Kernel §6) |
+| Label (DE) | Sequenzielle Abhängigkeit / kritischer Pfad |
+| Zweck | Begrenztes Vorhaben über Gates/Abhängigkeiten; Next Action = nächster **ready**-Schritt am relevanten Pfad (typisch kritischer Pfad). |
+
+---
+
+## D2 Geltung — PO ✓
+
+| Feld | Wert |
+|------|------|
+| Default | A2 `initiative.linear_project` |
+| kompatibel | A2; projektartige Kind-Projekte unter B2a |
+| nicht Meta für | B2a-Programm (`program_delivery`); B2b Default (`continuous_product`) |
+
+---
+
+## D3 Horizon — PO ✓ (AA)
+
+| Horizont | Bedeutung |
+|----------|-----------|
+| **Plan** | aktives / fokussiertes Gate (Zielzustand) + erreichbarer Teilgraph |
+| **Ist (ohne Agile)** | Actions am Gate-/Pfad-Ausschnitt |
+| **Ist (mit `agile_iteration`)** | zusätzlich aktiver `work_cycle` als Ausführungs-Takt; Gate bleibt Plan-Horizont |
+
+---
+
+## D4 Leading Work Item — PO ✓ (AA)
+
+**Action** (Arbeitspaket). Ready über Abhängigkeiten. Task = unter Action, nicht Leading Object.
+
+---
+
+## D5 Lifecycle-Pfad (konkret)
+
+| Schritt | Status | Konkrete Bedeutung in dieser Methode |
+|---------|--------|--------------------------------------|
+| intake | active | Ziel, Scope, Vorhaben anlegen |
+| method_selection | active | Default A2; Wechsel auditiert |
+| structure_setup | active | Projects/Stränge, Gates, Gate-Deps (`requires`), optional Action-Deps |
+| planning | active | rollierend: nächster Gate-Horizont + APs; nicht „alles vorab“ Pflicht |
+| action_selection | active | `ready_actions` ∩ Ranking kritischer Pfad |
+| assignment | active | Actor an Action |
+| waiting | active | auf Erledigung / Freigabe Deps |
+| result_intake | active | Status done / Evidence / Blocker |
+| validation | active | Gate-Kriterien / Verify vor `reached` |
+| review | skip/optional | bei Meilenstein-Review; nicht jeder AP |
+| adaptation | active | Replan Graph/APs bei Blocker oder Planänderung |
+| closure | active | Vorhaben-/Gate-Abschluss möglich und erwartet |
+
+---
+
+## D6 Next Action — konkrete Regeln
+
+**Ready (Action):**
+
+1. Status ∈ offene Arbeitszustände (`open` / `ready` / `in_progress` … je OM)  
+2. Alle `requires`-Vorgänger (Action-Deps und ggf. Gate-Bindung laut Graph-Profil) erfüllt (`done` oder waived per Decision)  
+3. Nicht durch Blocker gesperrt (sonst Attention, nicht Next)  
+4. Im aktiven Horizont (Gate und/oder Sprint, wenn Modifier aktiv) — **PO ✓:** kritischer Pfad nur **innerhalb** des Horizonts; keine Next Action außerhalb des Gate-/Sprint-Filters nur weil „auf globalem critical path“
+
+**Ranking:**
+
+1. Actions auf dem **critical_path** vor anderen ready  
+2. dann `sort_order` / Titel  
+3. reason_codes: `execution_critical_path`, `execution_ready`
+
+**Leerer Fall:**
+
+- keine ready Action → Attention: blockiert / Planning Debt / „nächstes Gate ohne APs“ — **keine** Fake-Next-Action
+
+**Nicht Next Action:**
+
+- blockierte Nachfolger als ready verkaufen  
+- Programm-Impulse (das ist `program_delivery`)  
+- Recurring/Checklist als Leading Object
+
+---
+
+## D7 Attention — konkrete Auslöser
+
+| Signal (Ziel-Code) | Wann |
+|--------------------|------|
+| `path_blocked` | kritische Action/Gate durch Blocker oder offene requires |
+| `gate_at_risk` | `target_date` / Kriterien gefährdet |
+| `planning_debt` | aktiver Horizont ohne planbare/ready APs (AP1.16d-Semantik) |
+| `overdue_action` | Action überfällig |
+
+---
+
+## D8 Events
+
+| Event | Wirkung |
+|-------|---------|
+| Action → `done` | Deps neu auswerten → neue ready-Menge |
+| Blocker create/clear | Attention + ready neu |
+| Gate verify / reopen | Horizont + Erfüllung |
+| Plan-Graph-Änderung | critical_path / ready neu |
+| (mit Agile) Sprint aktiv/complete | Ist-Horizont wechselt |
+
+Externe Gerichts-/Fürsorge-Events: **nicht** Kern dieser Methode.
+
+---
+
+## D9 Nested
+
+`n/a` als Programm-Meta.  
+Als **Kind** unter B2a: diese Methode steuert nur den Kind-Kontext; Parent nutzt `program_delivery` für Impulse.
+
+---
+
+## D10 OM-Voraussetzungen
+
+| Minimal | Optional |
+|---------|----------|
+| Initiative + SteeringContext | Tasks unter Action |
+| ≥1 Gate/Milestone oder äquivalenter Zielzustand | Gate-Kriterien |
+| Actions | `work_cycle` nur mit Agile-Modifier |
+| Abhängigkeiten: Gate- und/oder Action-Deps (sonst degeneriert zu flacher Liste — Attention `planning_debt` / Hinweis) | Evidence, Blocker |
+
+---
+
+## D11 Extension Points
+
+| Art | Key / Verhalten |
+|-----|-----------------|
+| next_action_strategy | `sequential_dependency` → nutzt `ready_actions` + `critical_path` |
+| steering_elements | `next_action_primary`, `critical_path`, `gate_fulfillment` |
+| graph_profile | Gate-Blocking / Fulfillment betont (`enforce_gate_blocking` typisch true) |
+| ui_features | `criticalPathControl` |
+| modifier | `agile_iteration` komponierbar (Horizon Ist = Sprint) |
+| hooks (Ziel) | `on_next_action_requested`, `on_structure_required`, `on_dependency_analysis_required`, `on_evidence_required`, `on_replan_required` |
+
+---
+
+## D12 Spannungen zum Kandidat-Kern / offene Punkte
+
+| Punkt | Bewertung |
+|-------|-----------|
+| Lifecycle-Loop | passt; Closure expected |
+| Horizon-Anker | **nötig** — ohne ihn Agile-Komposition unklar |
+| Work-Item-Polymorphie | hier nur Action — stützt Anker, nutzt Union minimal |
+| Nested | nur als Kind — stützt Trennung zu `program_delivery` |
+| Zwei Graphen (Gate vs Action-Deps) | **Besonderheit:** beide erlaubt; Next Action primär Ist-Graph (Actions), Plan-Graph begrenzt Horizont — muss im Kern als „Horizon + ReadyWorkItem“ klar bleiben, nicht vermischt werden |
+
+**PO ✓ (2026-07-25):**
+
+1. Next Action **nicht** außerhalb des aktiven Horizonts, auch wenn global auf critical path.  
+2. Gate-Graph allein reicht als **Minimalstart**; Action-Deps schärfen Ready/Critical Path. Ohne jegliche Deps → flache Liste + Attention `planning_debt`, Methode bleibt gültig.
+
+---
+
+## Nächste Methode
+
+Härtetest Nested: **`program_delivery`**.

docs/architecture/methods/_TEMPLATE_Method_Spec_Depth_D_v0.1.md

@@ -0,0 +1,104 @@
+# SPEC-D — `{method_key}`
+## Steuerungsmethode — Spec-Tiefe D v0.1
+
+**Status:** Entwurf  
+**Stand:** YYYY-MM-DD  
+**Prozess:** `M1_Hybrid_Path_and_Depth_D_v0.1.md`  
+**Kandidat-Kern:** Hypothese (Lifecycle-Loop + Anker A–G)
+
+---
+
+## D1 Identität
+
+| Feld | Wert |
+|------|------|
+| `method_key` | |
+| Rolle | primary / modifier |
+| Label (DE) | |
+| Zweck (2–3 Sätze) | |
+
+---
+
+## D2 Geltung
+
+| Feld | Wert |
+|------|------|
+| Default für Archetypen | |
+| `compatible_archetype_keys` (Ziel) | |
+| Nicht kompatibel mit | |
+
+---
+
+## D3 Horizon
+
+Was begrenzt „jetzt relevant“?
+
+---
+
+## D4 Leading Work Item
+
+Welches Union-Mitglied zeigt Next Action primär?
+
+---
+
+## D5 Lifecycle-Pfad
+
+| Schritt | Status (`active`/`skip`/`n/a`) | Warum |
+|---------|--------------------------------|-------|
+| intake | | |
+| method_selection | | |
+| structure_setup | | |
+| planning | | |
+| action_selection | | |
+| assignment | | |
+| waiting | | |
+| result_intake | | |
+| validation | | |
+| review | | |
+| adaptation | | |
+| closure | | |
+
+---
+
+## D6 Next Action
+
+- Eingaben:
+- Ranking:
+- Leerer Fall:
+- reason_codes:
+
+---
+
+## D7 Attention
+
+---
+
+## D8 Events
+
+---
+
+## D9 Nested
+
+`n/a` oder Beschreibung Parent/Child.
+
+---
+
+## D10 OM-Voraussetzungen
+
+---
+
+## D11 Extension Points
+
+| Art | Keys / TBD |
+|-----|------------|
+| next_action_strategy | |
+| attention / signals | |
+| steering_elements | |
+| policies / builder | |
+| hooks (Namen) | |
+
+---
+
+## D12 Spannungen zum Kandidat-Kern
+
+1. …

docs/product/Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md

@@ -0,0 +1,177 @@
+# Jinkendo Kairo
+## Archetyp-Decision-Lock (PO-Interview 2026-07-24/25)
+
+**Status:** verbindliches Inventar + Prinzipien — **keine** Feature-/GUI-Vollspec  
+**Stand:** 2026-07-25  
+**Ersetzt nicht:** Plugin-ADPs AP2.3/AP2.4 (Architektur-Voraussetzung)  
+**Wird Grundlage für:** `ADP_Archetype_and_Method_Catalog_v0.3` (nach Methoden-Normierung)  
+**Vorgänger-Inventar:** `ADP_Archetype_and_Method_Catalog_v0.2.md` (teilweise überholt — siehe §6)
+
+---
+
+## 0. Architektur-Voraussetzung (verbindlich)
+
+Fachliches Design an der Schnittstelle **Methode ↔ Vorhabentyp** setzt voraus:
+
+| Dokument | Rolle |
+|----------|--------|
+| `ADP_Archetype_Method_Plugin_Architecture_v0.1.md` | Plugin-Schichten, Open/Closed, Operating Context |
+| `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md` | MethodDefinition, steering_elements, Kompatibilität |
+| `.cursor/rules/kairo-plugin-architecture.mdc` | Guardrails für Implementierung |
+| `Kairo_Method_Design_Principles_v0.1.md` | Designprinzipien registrierbarer Methoden |
+
+**Regel:** Archetyp-Vollspecs und neue Methoden nur gegen diesen Vertrag — keine Page-Ifs, kein paralleler Steuerungskern.
+
+---
+
+## 1. Meta-Modell (PO ✓)
+
+| Schicht | Liefert |
+|---------|---------|
+| **Archetyp** | Natur, Horizont, Plan-/Ist-Vertrag, om_capabilities, UI-Hülle (ui_profile), Default-Methode (Empfehlung) |
+| **Methode (Primary)** | Steuerungsnatur — Ausführung **oder** Meta (program_delivery) |
+| **Methode (Komposition)** | Horizont-/Takt-Slice (gile_iteration); technisch modifier; kein Archetyp |
+| **Ausprägung** | optionale Profile/Templates (Felder, Seeds) — kein neuer Typ |
+
+**Methodentypen & Komposition** (Detail: Kernel §6):
+
+1. Ein Vorhaben = **ein** Archetyp; genau **eine** Primary-Methode.
+2. Hybrid unterschiedlicher Typen nur über **B2a Programm → Kind-Projekte** mit je eigenem Archetyp/Primary.
+3. B2a-Dach: nur Meta-Primary program_delivery — keine Ausführungs-Methoden und **kein** Agile am Dach.
+4. Agile = **Komposition** auf Primary von **A2, B2b, A3**.
+5. Laufzeit: nur kompatible Primary + erlaubte Komposition (AP2.4).
+
+---
+
+## 2. Vorhaben-Archetypen (Zielbild-Portfolio — 8 Typen)
+
+| ID | `archetype_key` | Label | Default-Methode | Kern |
+|----|-----------------|-------|-----------------|------|
+| A1 | `initiative.maturity_journey` | Reifegrad | `maturity_progression` | Kontinuierliche Entwicklung **persönlicher Fähigkeit/Kompetenz**; Stufen, Übung, Historie |
+| A2 | `initiative.linear_project` | Projekt | `sequential_dependency` (+ `agile_iteration`) | Begrenztes Vorhaben, Anfang/Ende/DoD; Plan **darf rollieren**; inkl. Content; Steuerung eng im Vorhaben |
+| A3 | `initiative.recurring_program` | Rhythmus | `recurring_control` (+ `agile_iteration`) | Cadence / Systemgesundheit; eine Instanz pro Rhythmus; **ohne** Fürsorge-Kern |
+| B1 | `initiative.support_queue` *(Zielrename: `initiative.checklists`)* | Checklisten | `checklist_flow` | Listen sammeln, gruppieren, abhaken / nächstes Item; inkl. Bucket List |
+| B2a | `initiative.program` | Programm | `program_delivery` | Meta/Controlling; Kinder hybrid; konkrete Next Action auf Projektebene |
+| B2b | `initiative.product` | Produkt | `continuous_product` (+ `agile_iteration`) | Kontinuierliches System/Produkt; kein Closure als Kern |
+| C1 | `initiative.dispute_case` | Verfahren | `dispute_procedure` | Event-/fallgetrieben, reaktiv, Fristen/Entscheidungen |
+| **NEU** | `initiative.care` | Fürsorge | `care_navigation` | Wohlergehen der Person im Fürsorgefokus (**andere oder Self-Care**) |
+
+### 2.1 Definitionen (kurz, PO-bestätigt)
+
+**A1 — Reifegrad:** Kontinuierliche Entwicklung einer Fähigkeit/Kompetenz. Fortschritt über Stufen, Wiederholung, Historie — nicht einmaliges Lieferobjekt.
+
+**A2 — Projekt:** Begrenztes Vorhaben mit Ziel/DoD/Meilensteinen. Planung rollierend erlaubt. Multi-Stream *innerhalb* eines Projekts. Content (Buch, Konzept) = A2 + optionales Content-Profil (kein eigener Archetyp D1).
+
+**A3 — Rhythmus:** Gesundheit eines wiederkehrenden Systems über Cadence/Abweichung. Kein Todo-Duplikat bei Verpassen. Nicht Care.
+
+**B1 — Checklisten:** Listen-/Checklist-Vorhaben (Alltag bis Bucket List). Leichte Steuerung; kein Projekt-DoD und keine Cadence als Kern. Product-Backlog von B2b bleibt Eingang des Produkts, kein Zwang zu eigenem B1.
+
+**B2a — Programm:** Schirm über Kinder. Programmebene: Kreuz-Abhängigkeiten, Roadblocker, Priorisierungsimpulse. Next Action der Kinder bleibt bei den Kindern. Kinder dürfen unterschiedliche Archetypen/Methoden haben.
+
+**B2b — Produkt:** Dauerhaftes Produkt/System (Weiterentwicklung, Betrieb, Bugs). Gegenstand = System, nicht persönliche Fähigkeit (≠ A1).
+
+**C1 — Verfahren:** Fall-/ereignisgetrieben, bedingt planbar. Kern = Fall/Verfahren, nicht Fürsorge-Wohlergehen.
+
+**Care — Fürsorge:** Prinzipien, Meilensteine, Rituale und reaktive Stränge unter einem Typ. Führend: Wohlergehen der Person (Selbst oder andere). ≠ A1 (Können), ≠ A3 (Cadence ohne Fürsorge), ≠ C1 (Verfahren).
+
+### 2.2 Bewusst keine eigenen Archetypen
+
+| Thema | Zuordnung |
+|-------|-----------|
+| Content / Buch | A2 + Profil |
+| Bucket List | B1 |
+| Gesundheit / Genesung | A1 / A3 / Care / C1 nach Steuerungslogik |
+| Lernen / Ausbildung | A1 (Können) oder A2 (Abschluss/DoD) |
+| Agiles Projekt | A2 + `agile_iteration` |
+| Agiler Rhythmus / Systemtakt | A3 + `agile_iteration` (Cadence bleibt Primary; Sprint für Actions) |
+| Sprint | Modifier/Methode, kein Typ |
+
+---
+
+## 3. B2a — Hybrid-Steuerung (PO ✓)
+
+| Ebene | Verantwortung |
+|-------|----------------|
+| Kind-Projekt | Eigene Next Action nach eigenem Archetyp × Methode |
+| Programm | Übergreifende Zielzustände, Kreuz-Deps, Roadblocker / kritischer Pfad über Kinder, Priorisierungsempfehlung |
+| Nicht | Programm ersetzt Kind-Next-Action |
+
+---
+
+## 4. Default-Methoden & erlaubte Komposition (Ziel)
+
+| Archetyp | Default | Auch erlaubt (Ziel) |
+|----------|---------|---------------------|
+| A1 | `maturity_progression` | — |
+| A2 | `sequential_dependency` | `agile_iteration` (modifier) |
+| A3 | `recurring_control` | `agile_iteration` (modifier) |
+| B1 | `checklist_flow` | — *(ersetzt fachlich `queue_pull`-Label)* |
+| B2a | `program_delivery` | — |
+| B2b | `continuous_product` | `agile_iteration` (modifier) |
+| C1 | `dispute_procedure` | — |
+| Care | `care_navigation` | — |
+
+**Normierung ausstehend:** Method Contract AP2.4 ist technisch geliefert; **fachliche Primitive**, einheitliche Voraussetzungen und vollständige `compatible_archetype_keys` / `om_capabilities` / `steering_elements` pro Methode → siehe Methoden-Normierungsprogramm.
+
+---
+
+## 5. Nächste Phase (verbindlich)
+
+```text
+✓ Decision-Lock Archetypen (dieses Dokument)
+✓ Steuerungsmethoden-Kern v0.1
+  → docs/architecture/Kairo_Steering_Method_Kernel_v0.1.md
+→ Archetyp-Vollspecs / Catalog v0.3 auf diesem Kern
+→ Code nur Open/Closed in Kernel-Schlitze
+```
+
+Programm: `docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md`
+
+---
+
+## 6. Delta zu Katalog v0.2
+
+| v0.2 | Decision-Lock |
+|------|----------------|
+| D1 `content_project` als Archetyp | **entfernt** → A2 + Profil |
+| B1 „Inbox/Queue“ | **Checklisten**; Methode `checklist_flow` |
+| Care fehlt | **`initiative.care`** neu |
+| B3 als „Profil“ im Archetyp-Inventar vermischt | klar: **nur Methode** |
+| A2 „nahezu vollständige AP-Planung“ | **rollierende Planung** erlaubt |
+| Gesundheit/Ausbildung nicht adressiert | Zuordnungsregeln §2.2 |
+
+---
+
+## 7. Archetyp ≠ Vorhaben-Template (PO ✓ 2026-07-25)
+
+| | Archetyp | Vorhaben-Template |
+|--|----------|-------------------|
+| Rolle | Wesentliche Natur + Steuerbarkeit über Default-Methode | Konkrete Vorlage **auf** einem Archetyp |
+| Kann liefern | om_capabilities, Plan/Ist-Vertrag, Default-Methode | Zusatzfelder, Darstellung, Sortierung/Filter, Presets, ggf. Profil |
+| Neu bei jeder Vorlage? | **Nein** | Ja, ohne neuen Archetyp |
+| UI-Namen | Arbeitslabel reicht | dürfen abweichen / spezialisieren |
+
+Wesentliche Merkmale bleiben am Archetyp; Steuerung über die Methode (Methodenkern). Templates ändern die Natur nicht.
+
+---
+
+## 8. PO-Freigabe
+
+- [x] Meta-Modell Archetyp ↔ Methode  
+- [x] Archetyp ≠ Template  
+- [x] 8 Vorhaben-Archetypen inkl. Care  
+- [x] D1/Bucket/Gesundheit/Ausbildung ohne eigene Typen  
+- [x] B2a Hybrid-Steuerung  
+- [x] Agile auf A2, B2b und A3 (Komposition)  
+- [x] Reihenfolge: Methoden-Normierung vor Archetyp-Vollspec  
+- [x] Methodenkern v0.1 + Spec-D Care/Checklisten  
+- [x] **2026-07-26:** Architektur Archetyp ↔ Methode ↔ Komposition **beibehalten** (schlank: Default-Primary pro Typ + wenige Kompositionen; kein spekulativer Methoden-Marktplatz)  
+- [x] Archetyp-Vollspecs auf C1-Maßstab nachgezogen (2026-07-26)  
+- [x] Spec-D-Batch für bestehende Methoden vorhanden  
+- [x] **2026-07-26: vorläufige Freigabe** aller Archetyp-Vollspecs + zugehöriger Spec-Ds als Zielbild — **ohne** abschließende Bewertung der Implementierungsausreichendheit; Nachschärfung beim Bauen erwartet  
+- [ ] Endgültige Spec-Freigabe nach Implementierungs-Härte  
+- [ ] Technische Keys: Rename `support_queue` → `checklists` (Label zuerst)  
+
+---
+
+*Interview-Protokoll verdichtet. Keine Implementierungs-DoD. Guardrails AP2.3/AP2.4 bleiben führend für die Schnittstelle.*

docs/product/Kairo_Archetype_Specification_Program_v0.1.md

@@ -76,14 +76,17 @@ Template: [`archetypes/_TEMPLATE_Archetype_Spec_v0.1.md`](archetypes/_TEMPLATE_A
 ## 4. Reihenfolge (verbindlich in dieser Phase)
 
 ```text
-Welle 0   Programm + Template + Lückenmatrix                 ← dieses Dokument
-Welle 1   Stufe A verdichten: A1, A2, B2a, B2b, B3          ← Spec = Abnahmebasis
-Welle 2   Stufe B spezifizieren: B1, A3, D1                 ← Spec vor Code
-Welle 3   Portfolio-Capture (ADP, Querschnitt)              ← nach B1-Kern
-Welle 4   C1 Katalog-Vertiefung                             ← Spec only, kein MVP-Code
+Welle 0   Programm + Template + Lückenmatrix                 ✓
+Welle 0b  Archetyp-Decision-Lock (Interview)                 ✓ 2026-07-25
+Welle 0c  Methoden-Normierung (Primitive + Contract)         ← JETZT
+          → docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md
+Welle 1   Archetyp-Vollspecs auf normierter Methodenbasis
+Welle 2   Catalog ADP v0.3 konsolidieren
+Welle 3   Portfolio-Capture (ADP, Querschnitt) nach B1-Spec
 ```
 
-**Stop-Regel:** Kein neues Implementierungs-AP für einen Archetyp, solange Spec-Status ≠ `freigegeben` (Stufe A: `abnahmereif` reicht für Validation AP2.1).
+**Voraussetzung:** AP2.3/AP2.4 Plugin-Architektur + Guardrails.  
+**Stop-Regel:** Keine Archetyp-Vollspec / kein neuer Archetyp-Code, solange betroffene Methode nicht gegen das Normierungsprogramm freigegeben ist.
 
 ---
 

docs/product/Kairo_MVP_Execution_Plan_v0.2.md

@@ -4,7 +4,10 @@
 **Status:** PO-Kurskorrektur — **führend für Implementierung ab 2026-07-12**  
 **Stand:** 2026-07-25 (AP2.3/AP2.4 Plugin-Architektur ✓)  
 **Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–9, `ADP_Archetype_and_Method_Catalog_v0.2.md` §3, `ADP_Archetype_Method_Plugin_Architecture_v0.1.md`, `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`, `Kairo_Corrected_MVP_Roadmap_v0.2.md` (AP-Historie)  
-**Spezifikationsphase (ab 2026-07-24):** `Kairo_Archetype_Specification_Program_v0.1.md` + `docs/product/archetypes/` — Spec vor neuem Archetyp-Code (Welle 2+); ersetzt diesen Plan nicht
+**Spezifikationsphase (ab 2026-07-24/25):**  
+- Decision-Lock: `Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`  
+- **Jetzt:** Methoden-Normierung `docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md` (auf AP2.3/AP2.4)  
+- Danach: Archetyp-Vollspecs — ersetzt diesen Plan nicht
 
 ---
 

docs/product/archetypes/README.md

@@ -1,18 +1,23 @@
 # Archetyp-Spezifikationen — Index
 
-**Programm:** [`../Kairo_Archetype_Specification_Program_v0.1.md`](../Kairo_Archetype_Specification_Program_v0.1.md)  
-**Katalog:** [`../../architecture/ADP_Archetype_and_Method_Catalog_v0.2.md`](../../architecture/ADP_Archetype_and_Method_Catalog_v0.2.md)  
-**Template:** [`_TEMPLATE_Archetype_Spec_v0.1.md`](_TEMPLATE_Archetype_Spec_v0.1.md)
+**Programm:** [`VOLLSPEC_PROGRAM_v0.1.md`](VOLLSPEC_PROGRAM_v0.1.md)  
+**Decision-Lock:** [`../Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`](../Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md)  
+**Methodenkern:** [`../../architecture/Kairo_Steering_Method_Kernel_v0.1.md`](../../architecture/Kairo_Steering_Method_Kernel_v0.1.md)  
+**Methoden Spec-D:** [`../../architecture/methods/README.md`](../../architecture/methods/README.md)
 
-| ID | Datei | Status | Welle |
-|----|-------|--------|-------|
-| A1 | [SPEC_A1_maturity_journey_v0.1.md](SPEC_A1_maturity_journey_v0.1.md) | Entwurf | 1 |
-| A2 | [SPEC_A2_linear_project_v0.1.md](SPEC_A2_linear_project_v0.1.md) | Entwurf | 1 |
-| B2a | [SPEC_B2a_program_v0.1.md](SPEC_B2a_program_v0.1.md) | Entwurf | 1 |
-| B2b | [SPEC_B2b_product_v0.1.md](SPEC_B2b_product_v0.1.md) | Entwurf | 1 |
-| B3 | [SPEC_B3_sprint_profile_v0.1.md](SPEC_B3_sprint_profile_v0.1.md) | Entwurf | 1 |
-| A3 | [SPEC_A3_recurring_program_v0.1.md](SPEC_A3_recurring_program_v0.1.md) | Entwurf | 2 |
-| B1 | [SPEC_B1_support_queue_v0.1.md](SPEC_B1_support_queue_v0.1.md) | Entwurf | 2 |
-| D1 | [SPEC_D1_content_project_v0.1.md](SPEC_D1_content_project_v0.1.md) | Entwurf | 2 |
-| C1 | [SPEC_C1_dispute_case_v0.1.md](SPEC_C1_dispute_case_v0.1.md) | Entwurf | 4 |
-| — | [SPEC_generic_fallback_v0.1.md](SPEC_generic_fallback_v0.1.md) | Entwurf | — |
+**PO 2026-07-26:** Specs **vorläufig freigegeben** — Implementierungsausreichendheit noch nicht abschließend bewertet.
+
+| ID | Datei | Status |
+|----|-------|--------|
+| C1 | [SPEC_C1_dispute_case_v0.1.md](SPEC_C1_dispute_case_v0.1.md) | vorläufig freigegeben |
+| A1 | [SPEC_A1_maturity_journey_v0.1.md](SPEC_A1_maturity_journey_v0.1.md) | vorläufig freigegeben |
+| A2 | [SPEC_A2_linear_project_v0.1.md](SPEC_A2_linear_project_v0.1.md) | vorläufig freigegeben |
+| A3 | [SPEC_A3_recurring_program_v0.1.md](SPEC_A3_recurring_program_v0.1.md) | vorläufig freigegeben |
+| B1 | [SPEC_B1_checklists_v0.1.md](SPEC_B1_checklists_v0.1.md) | vorläufig freigegeben |
+| B2a | [SPEC_B2a_program_v0.1.md](SPEC_B2a_program_v0.1.md) | vorläufig freigegeben (Code-P0) |
+| B2b | [SPEC_B2b_product_v0.1.md](SPEC_B2b_product_v0.1.md) | vorläufig freigegeben |
+| Care | [SPEC_Care_initiative_care_v0.1.md](SPEC_Care_initiative_care_v0.1.md) | vorläufig freigegeben (Code-P0) |
+| — | [SPEC_generic_fallback_v0.1.md](SPEC_generic_fallback_v0.1.md) | vorläufig freigegeben (Fallback) |
+| B3 | [SPEC_B3_sprint_profile_v0.1.md](SPEC_B3_sprint_profile_v0.1.md) | kein Archetyp → Agile |
+| D1 | [SPEC_D1_content_project_v0.1.md](SPEC_D1_content_project_v0.1.md) | entfernt (→ A2) |
+| B1 alt | [SPEC_B1_support_queue_v0.1.md](SPEC_B1_support_queue_v0.1.md) | alt → Checklisten |

docs/product/archetypes/SPEC_A1_maturity_journey_v0.1.md

@@ -1,11 +1,14 @@
 # SPEC — A1 `initiative.maturity_journey`
-## Implementierungs-Spezifikation v0.1
+## Archetyp-Vollspec (implementierbar) v0.1
 
-**Status:** Entwurf (Welle 1 — Verdichtung)  
-**Stand:** 2026-07-24  
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
 **MVP-Stufe:** A  
-**Katalog:** `ADP_Archetype_and_Method_Catalog_v0.2.md` §5 A1  
-**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+**Decision-Lock:** A1 Reifegrad  
+**Default-Methode:** [`SPEC_D_maturity_progression_v0.1.md`](../../architecture/methods/SPEC_D_maturity_progression_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS/Kit/Happy Path hier; Ready/Ranking/Events/Attention/Lifecycle in Spec-D.
 
 ---
 
@@ -14,119 +17,195 @@
 | Feld | Wert |
 |------|------|
 | `archetype_key` | `initiative.maturity_journey` |
-| Label (DE) | Reifegrad-Entwicklung |
+| Label (Arbeit) | Reifegrad |
 | Default-`method_key` | `maturity_progression` |
-| Ausprägungen | z. B. `maturity.karate_kumite` (optional) |
+| Primary (kompatibel) | nur `maturity_progression` (**Ausführung**, Kernel §6) |
+| Komposition | — (kein Agile-Default; nur nach späterem Lock) |
 | Project-Spiegel | `project.maturity_journey` |
-| MVP-Stufe | A |
+| Dominanz (über Methode) | hybrid (Cadence + Stufen-Plan) |
+| Closure | weich — kein erzwungenes Vorhaben-Ende |
 
 ### Abgrenzung
 
-| Nicht verwechseln mit | Unterschied |
-|-----------------------|-------------|
-| A2 Linear | Kein festes End-Gate; Fortschritt über Stufen + Historie |
-| A3 Recurring | Recurring dient der **Übung**, nicht dem Haushalt-Score |
-| B2 Product | Kein dauerhaftes Issue-Backlog als Kern |
+| Nicht | Stattdessen |
+|-------|-------------|
+| Care | Wohlergehen Fokus-Person |
+| A3 | Cadence ohne Reifegrad-Stufen als Kern |
+| A2 | einmaliges Lieferende / DoD-Projekt |
+| Templates | z. B. Kumite = Template/Profil auf A1 |
 
 ---
 
-## 2. Nutzerbild & Referenzbeispiel
+## 2. Nutzerbild
 
-**Wer / Situation:** Person entwickelt eine Fähigkeit über Stufen (Karate, Fitness, Spagat).
+Kontinuierliche Entwicklung einer Fähigkeit über **Phasen/Stufen**. Eine Phase enthält **mehrere Aktivitäten und Übungen**. Innerhalb einer Phase können Übungen **zeitversetzt** oder **alternierend** laufen. Bei Erreichen eines Meilensteins/Gates wird das Aktivitäts-Set der Phase **modifiziert**.
 
-**Referenzbeispiel:** „Spagat können“ oder „Karate Kumite“ — mehrere Fähigkeiten als Projects, Stufen als `maturity_stage`, tägliche Übung als Recurring.
+**Wer / Situation:** Lernende / Trainierende Person (oder Coach mit Fokus auf Können), die Stufen und Übungspraxis steuert.
 
-**Leitfrage:** *Welche Stufe ist aktiv — und welche Übung bringt mich heute weiter?*
+**Referenzbeispiel (durchspielbar) — „Grundschule Kata“:**
+
+1. Stufen: Anfänger → Mittelstufe → Fortgeschritten; Stufe Anfänger aktiv.  
+2. Project „Technik“.  
+3. Auf Anfänger: Übung A täglich; optional Übung B Di/Do (Zeitversatz) **oder** Alternanz A/B.  
+4. Today: Next = fällige Übung / Alternanz-aktuell; Erfüllen ohne Duplikat-Task.  
+5. Evidence/Kriterien für Anfänger → Verify → Stufe Mittelstufe aktiv; neues Activity Set; alte Übungen nicht mehr in Next.  
+6. Innerhalb Mittelstufe Übung hinzufügen (Adaptation), auditiert.  
+7. Optional zweites Fähigkeits-Project + Graph-Voraussetzung.
+
+**Leitfrage:** Welche Stufe ist aktiv — und welche Übung/Aktivität ist **jetzt** dran (inkl. Alternanz/Zeitversatz)?
 
 ---
 
-## 3. Plan-Objekte
+## 3. om_capabilities
 
-| Objekt | Pflicht / optional | Regeln |
-|--------|-------------------|--------|
-| `maturity_stage` | Pflicht (min. 1 aktiv) | Reihenfolge / Graph-Voraussetzungen |
-| Project (Spiegel) | empfohlen | z. B. pro Fähigkeit |
-| Graph-Kanten | optional, empfohlen bei Multi-Fähigkeit | Stufe X requires Stufe Y |
-| `milestone` / Gate-Graph | sekundär | UI: Graph-als-Hauptwerkzeug **aus** |
-| `work_cycle` | nein (nicht Kern) | |
-
-**Plan-Anti-Pattern:** Alle Übungen als flache Milestone-Liste ohne Recurring.
+```text
+actions, roadmap, projects, recurring, blockers,
+evidence, decisions, reviews, steering_methods
+```
 
 ---
 
-## 4. Ist-Objekte
+## 4. Plan- / Ist-Vertrag
 
-| Objekt | Rolle | Commit-Regel |
-|--------|-------|--------------|
-| RecurringElement | heutige Übung / Routine der aktiven Stufe | eine aktive Routine-Familie pro Fokus |
-| Action | optional (Workshops, Prüfungen) | nicht Hauptliste |
-| BacklogItem | selten | |
-| Evidence | Stufen-Verify / Nachweis | vor `reached` |
-| Journey | Entwicklungsnarrative | Pflicht für Abnahme |
+### 4.1 Stufen / Phasen
 
-**Ist-Anti-Pattern:** 200 Übungs-Tasks in Ausführen.
+| Element | Rolle |
+|---------|--------|
+| `maturity_stage` (RoadmapItem) | Phase/Stufe; eine **aktive** Stufe (Horizon) |
+| Kriterien / Evidence | Verify vor `reached` |
+| Graph | Voraussetzungen zwischen Stufen und/oder Fähigkeits-Projects |
+| Project `project.maturity_journey` | Fähigkeit/Spur; eine oder mehrere |
 
-**Stufenwechsel (AP2.0e):** Bei `maturity_stage` → `reached` wechselt / rotiert das Recurring-Set der nächsten Stufe.
+### 4.2 Aktivitäts-Set einer Phase (verbindlich)
+
+| Aktivitätstyp | Persistenz | Rolle |
+|---------------|------------|--------|
+| Übung / Ritual | `RecurringElement`, gebunden an `maturity_stage` | wiederkehrend |
+| Einmal-/Sonderaktivität | `Action`, gebunden an Stufe | Prüfung, Workshop, Nachweis |
+
+- Pro Stufe: **beliebig viele** Aktivitäten; **≥1 reicht**.  
+- Pro Recurring: **eine** offene CadenceInstance (kein Duplikat bei Verpassen).  
+- Inaktive Stufen: kein Next, keine neuen Instanzen; Historie bleibt.
+
+### 4.3 Zeitversatz und Alternanz (gleiche Phase)
+
+| Muster | Modell |
+|--------|--------|
+| Zeitversetzt | eigene Cadence je Recurring; mehrere fällig am selben Tag möglich |
+| Alternierend | `alternation_group_id` + `alternation_order`; genau ein aktuelles Mitglied next-fähig |
+| Gemischt | beides erlaubt |
+
+Alternanz-Regeln: Rotation nach Erfüllung; Overdue nur auf aktuelles Mitglied; Gruppe an Stufe gebunden.
+
+### 4.4 Modifikation bei Stage `reached`
+
+1. Altes Activity Set deaktivieren.  
+2. Nächste Stufe aktiv; neues Set aktiv.  
+3. Neues Set darf Übungen/Cadences/Alternanz/Actions ersetzen/erweitern/reduzieren.  
+4. Adaptation innerhalb Stufe (manuell) erlaubt und auditiert.  
+
+Erweitert AP2.0e auf ganze Activity Sets.
+
+### 4.5 Datenfelder am Recurring (verbindlich)
+
+| Feld | Zweck |
+|------|-------|
+| Bindung an `maturity_stage` | Stage Activity Set |
+| Cadence | Zeitversatz |
+| `alternation_group_id` + `alternation_order` | Alternanz (leer = keine Gruppe) |
+| status aktiv/inaktiv | Set-Wechsel / Adaptation |
+
+### 4.6 Anti-Patterns
+
+- Übungen aller Stufen als flache Action-Liste  
+- Verpasste Übung → Duplikat-Task  
+- Alternanz ohne Gruppen-Semantik  
 
 ---
 
 ## 5. Steuerung
 
-**Methode:** `maturity_progression`
+**Verbindlich:** Spec-D `maturity_progression` (D3–D8, D11).
 
-| Signal | Logik | `reason_code` (Ziel) |
-|--------|-------|----------------------|
-| Next Action | heutige Recurring-Instanz + offenes Stufen-Kriterium | `maturity_today_practice`, `maturity_stage_criteria` |
-| Attention | Stagnation, keine Erfüllung über Zeit | `maturity_stagnation` |
-| Lifecycle | kein erzwungenes Closure; Reifegrad bleibt adaptierbar | — |
+| Aspekt | Kurz |
+|--------|------|
+| Dominanz | hybrid |
+| Horizon | aktive `maturity_stage` |
+| Leading | CadenceInstance; sekundär Stage-Action |
+| Next / Ranking | Spec-D D6 |
+| Attention / Events | Spec-D D7 / D8 |
+| Steering nur in | `backend/steering/` |
+
+### Steuerungselemente
+
+| `steering_element_key` | Rolle | Pflicht |
+|------------------------|-------|---------|
+| `next_action_primary` | Next Practice / Stage-Action | ja |
+| `maturity_stage` | aktive Stufe / Fortschritt | ja |
+| `recurring_rhythm` | Übungsrhythmus | ja |
 
 ---
 
-## 6. UI / IA
+## 6. EFS
 
-| Aspekt | Vorgabe |
-|--------|---------|
-| Prozessleiste | Stufen → Rhythmen/Journey → Ausführen → Kontrolle |
-| Plan-Default | `/plan/gates` (Stufen) |
-| Work-Default | `/work/today` |
-| Control-Default | `/control/status` (+ Journey prominent) |
-| Versteckt | Gate-Designer als Hauptwerkzeug; Sprint-Nav sekundär |
+| `field_key` | Typ (Ziel) | Pflicht | Zweck |
+|-------------|------------|---------|-------|
+| `current_focus` | text | **ja** | Fähigkeits-/Übungsfokus |
+| `training_frequency` | text | **ja** | übergeordneter Soll-Rhythmus |
+| `progress_notes` | text | nein | Notizen |
+| `discipline` | text | nein | Domäne; Template darf vorbelegen |
+
+Cadence im Detail am RecurringElement.
 
 ---
 
-## 7. EFS-Felder
-
-| `field_key` | Typ | Pflicht | Zweck |
-|-------------|-----|---------|-------|
-| `current_focus` | text | empfohlen | aktueller Fokus (Code: vorhanden) |
-| `training_frequency` | text/enum | optional | Cadence-Hinweis (Code: vorhanden) |
-| `progress_notes` | text | optional | Katalog; Spec: optional nachziehen |
-| `discipline` | enum | optional | karate, fitness, … |
-
----
-
-## 8. Starter-Kit & Ausprägung
+## 7. Basiserfassung / Starter-Kit
 
 | Element | Inhalt |
 |---------|--------|
-| Kit | 3× `maturity_stage`, 1× Project „Training“, 1× Recurring „Tägliche Übung“ |
-| Guidance | „Aktuelle Stufe und heutige Übung steuern deinen nächsten Schritt.“ |
-| Ausprägung | `maturity.karate_kumite` — mehr Fähigkeiten/Stufen, Kit bleibt minimal |
+| Kit (Minimum) | 3× `maturity_stage`; 1× Project; ≥1 Übung auf aktiver Stufe |
+| Kit (Beispiel reich) | ≥2 Übungen (zeitversetzt oder Alternanz) — Demo |
+| Guidance | „Übung der Stufe steuert Next; Set kann bei Stufen-Erreichen wechseln.“ |
+| Create | Titel, Archetyp, `current_focus`, `training_frequency` |
+| Templates | Kumite etc. — reichere Sets/Graphen auf A1 |
 
 ---
 
-## 9. Happy Path
+## 8. UI-Hülle
 
-1. Vorhaben anlegen (Archetyp + optional Ausprägung), Kit bestätigen  
-2. Aktive Stufe prüfen; Recurring „heute“ in Ausführen sehen  
-3. Evidence / Kriterien für Stufe; Verify → `reached`  
-4. Recurring der nächsten Stufe aktiv; Kontrolle zeigt neue Next Action  
-5. Journey zeigt Stufenwechsel
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Stufen** | Timeline/Liste; aktiv; Kriterien; Verify |
+| **Plan → Stufe Detail** | Activity Set: Übungen (Cadence, Alternanz), Stage-Actions |
+| **Plan → Struktur** | Fähigkeits-Projects + Graph |
+| **Plan → Profil** | EFS Fokus/Frequenz/Disziplin |
+| **Ausführen / Today** | fällige Übungen + Alternanz-aktuell + Stage-Actions |
+| **Kontrolle** | Stufe, Next + Begründung, Attention, Verify-Fortschritt |
+| **Journey** | Stufenwechsel, Set-Modifikationen, erfüllte Übungen |
+| **Process** | Stufen → Stufe/Übungen → Ausführen → Kontrolle |
+| **Elements** | `next_action_primary`, `maturity_stage`, `recurring_rhythm` |
+| **Nicht dominant** | Sprint, Checklisten-Queue, Gate-Designer als Hauptwerkzeug |
 
-### Negative
+---
 
-1. Alle Übungen als Actions anlegen → Attention/Guidance gegen Todo-Wand  
-2. Stufe `reached` ohne Kriterien → Verify-Pfad blockiert / Override auditiert
+## 9. Happy Path (Abnahme-Flow)
+
+1. A1 anlegen; Fokus/Frequenz setzen; Kit mit Stufen + ≥1 Übung.  
+2. Aktive Stufe + Recurring sichtbar; Next = Übung (reason_code).  
+3. Übung erfüllen → eine nächste Instanz; kein Duplikat.  
+4. Optional: zweite Cadence (Zeitversatz) oder Alternanz A/B.  
+5. Evidence/Kriterien → Stage verify → neues Set aktiv, altes nicht in Next.  
+6. Adaptation: Übung in aktiver Stufe ändern, auditiert.  
+7. Optional: zweites Fähigkeits-Project + Graph-Voraussetzung.
+
+### Negative / Randfälle
+
+1. Nur eine Übung → gültig.  
+2. Verpasste Übung → Attention/overdue, keine zweite Instanz.  
+3. Alternanz-Nicht-Aktuelle erscheinen nicht als Ready.  
+4. Übungen inaktiver Stufe nicht in Next.  
+5. Leere Active Stage ohne Set → Attention `maturity_inactive_set`.  
+6. Todo-Wand aller Übungen aller Stufen → Anti-Pattern.
 
 ---
 
@@ -134,39 +213,41 @@
 
 | # | Kriterium | Erfüllt wenn |
 |---|-----------|--------------|
-| 1 | Anlegen | Archetyp + Kit + Methode `maturity_progression` |
-| 2 | Struktur | ≥2 Stufen, 1 Recurring, optional Graph |
-| 3 | Ist | Heutige Übung sichtbar; kein Task-Wall |
-| 4 | Kontrolle | Stufe + Übung + Begründung |
-| 5 | Journey | ≥1 Stufenwechsel nachvollziehbar |
-| 6 | ≤2 Min | Leitfrage aus Kontrolle beantwortbar |
-| 7 | Cockpit | Attention bei Stagnation (wenn Daten) |
-
-Szenario MVP §8 A1.
+| 1 | Anlegen | Kit + EFS Fokus/Frequenz + `maturity_progression` |
+| 2 | Minimum | eine Übung auf aktiver Stufe steuert Next |
+| 3 | Anti-Duplikat | eine Instanz pro Ritual |
+| 4 | Optional Multi | Zeitversatz und/oder Alternanz durchspielbar |
+| 5 | Stage-Wechsel | Verify → Set-Wechsel korrekt |
+| 6 | Adaptation | Set-Änderung innerhalb Stufe auditiert |
+| 7 | Leitfrage | ≤2 Min |
+| 8 | Journey | Stufenwechsel/Übungen nachvollziehbar |
+| 9 | Elements | next + maturity_stage + recurring_rhythm |
+| 10 | Anti | keine Übungs-Todo-Wand |
 
 ---
 
-## 11. Ist-Stand
+## 11. Ist-Stand (Spec vs. Code)
 
 | Bereich | Spec | Code/Truth | Lücke |
 |---------|------|------------|-------|
-| Registry | ✓ | ✓ | — |
-| Starter-Kit | ✓ | ✓ AP2.2a | — |
-| UI-Defaults | ✓ | ✓ AP1.9d | Journey-Prominenz prüfen |
-| Stufenwechsel Recurring | ✓ | ✓ AP2.0e | UX-Feinschliff |
-| Next-Action-Strategie | ✓ | ◐ | reason_codes / Copy |
-| Attention Stagnation | ✓ | ◐ | Spec schärfen bei Validation |
+| Registry / Kit | A1 + Stufen | weitgehend AP2.0e/Kit | Multi-Übung/Alternanz |
+| Methode | `maturity_progression` | vorhanden | Ranking Alternanz Spec-D |
+| Stage Activity Set | verbindlich | Teilmenge | Stage-Bindung + UI Detail |
+| Alternanz-Felder | verbindlich | fehlt/teilweise | Persistenz + Strategy |
+| EFS Pflicht | focus/frequency | Seeds prüfen | Seed-AP |
+| steering_elements | D11 | teilweise | FE/BE Parität |
+| UI Stufe-Detail | Pflicht | lückenhaft | UI-AP |
 
 ---
 
-## 12. Offene PO-Fragen
+## 12. Implementierung
 
-1. Reicht 1 Project „Training“ für Abnahme A, oder muss Multi-Fähigkeit (Kumite) Pflicht sein?  
-2. Soll Gate-Graph in UI für A1 komplett ausgeblendet oder nur de-emphasized bleiben?
+Fachmodell vollständig. Lücken (Alternanz, Multi-Übung-UI, EFS-Seeds) = Implementierungs-Schuld — Spec nicht kürzen.
 
 ---
 
 ## 13. Nachfolger
 
-- Validation: AP2.1 Szenario A1  
-- Feinschliff nur nach Spec-Status `abnahmereif`
+- Alternanz-Persistenz + Strategy  
+- UI Stufe-Detail / Activity Set  
+- Template Kumite  

docs/product/archetypes/SPEC_A2_linear_project_v0.1.md

@@ -1,11 +1,15 @@
 # SPEC — A2 `initiative.linear_project`
-## Implementierungs-Spezifikation v0.1
+## Archetyp-Vollspec (implementierbar) v0.1
 
-**Status:** Entwurf (Welle 1 — Verdichtung)  
-**Stand:** 2026-07-24  
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
 **MVP-Stufe:** A  
-**Katalog:** `ADP_Archetype_and_Method_Catalog_v0.2.md` §5 A2  
-**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+**Decision-Lock:** A2 Projekt  
+**Default-Methode:** [`SPEC_D_sequential_dependency_v0.1.md`](../../architecture/methods/SPEC_D_sequential_dependency_v0.1.md)  
+**Komposition:** [`SPEC_D_agile_iteration_v0.1.md`](../../architecture/methods/SPEC_D_agile_iteration_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS/Kit/Happy Path hier; Ready/Ranking/Attention/Events in Spec-D.
 
 ---
 
@@ -14,146 +18,255 @@
 | Feld | Wert |
 |------|------|
 | `archetype_key` | `initiative.linear_project` |
-| Label (DE) | Lineares Vorhaben |
+| Label (Arbeit) | Projekt |
 | Default-`method_key` | `sequential_dependency` |
+| Primary (kompatibel) | nur `sequential_dependency` (**Ausführung**, Kernel §6) |
+| Komposition | `agile_iteration` (optional) |
 | Project-Spiegel | `project.linear_project` |
-| MVP-Stufe | A |
+| Dominanz (über Methode) | plan (+ Sprint plan-Slice wenn Agile aktiv) |
+| Closure | **active / erwartet** — Vorhaben- und Gate-Abschluss |
 
 ### Abgrenzung
 
-| Nicht verwechseln mit | Unterschied |
-|-----------------------|-------------|
-| B2a Programm | A2 = Einmalprojekt (privat/operativ); B2a = Programm mit Closure/Release-Semantik |
-| B2b Product | A2 hat Abschluss-Horizont; kein Dauer-Issue-Backlog als Kern |
-| A1 Reifegrad | Gates/Pfade statt Stufen+Recurring |
+| Nicht | Stattdessen |
+|-------|-------------|
+| B2a Programm | Meta-Schirm, Impulse; A2 steuert konkrete Next Action im eigenen Kontext |
+| B2b Product | Dauerbetrieb, Closure nicht Kern |
+| B1 Checklisten | Abhaken ohne Liefer-DoD / Gate-Verify |
+| C1 Verfahren | Event→Reaktionsstränge; A2 = plangeführter Lieferpfad |
+| A1 / A3 / Care | Können / Rhythmus / Fürsorge — nicht einmaliges Lieferende |
+| Content als eigener Typ | Content/Buch = **dieses A2** + optionales Template/Profil |
+| Agiles Projekt als Typ | A2 + Komposition `agile_iteration` |
 
 ---
 
-## 2. Nutzerbild & Referenzbeispiel
+## 2. Nutzerbild
 
-**Referenzbeispiel:** „Neue Küche“ — Hauptpfad (Handwerker-Sequenz) + Begleitung (parallel: Entsorgung, Finanzierung).
+Begrenztes Vorhaben mit Ziel, DoD und Meilensteinen (Gates). Planung **darf rollieren** — nicht alles muss vorab feststehen. Mehrere Stränge (Projects) innerhalb eines Projekts möglich (Hauptpfad + Begleitung). Next Action = nächster **ready**-Schritt am kritischen Pfad **innerhalb** des aktiven Horizonts (Gate und/oder Sprint).
 
-**Leitfrage:** *Was ist der nächste ready Schritt am kritischen Pfad — und was blockiert?*
+**Wer / Situation:** Person oder kleines Team liefert ein abgegrenztes Ergebnis (Umbau, Release eines abgeschlossenen Vorhabens, Buch/Konzept mit Abschluss).
+
+**Referenzbeispiel (durchspielbar) — „Neue Küche“:**
+
+1. Gates: Bestellung → Demontage → Montage → Abnahme.  
+2. Projects: „Hauptpfad Küche“, „Begleitung Elektro/Wasser“.  
+3. Actions am Gate Montage mit `requires` (z. B. Geräte geliefert → Einbau).  
+4. Kontrolle zeigt Next auf kritischem Pfad; Blocker „Lieferung verspätet“ → Attention, keine Fake-Ready.  
+5. Optional Agile: Sprint „Montage-Woche“ filtert Ist; Gate bleibt Plan-Horizont.  
+6. Gate Abnahme verify + Evidence → Closure.
+
+**Leitfrage (Kontrolle):** Welcher nächste ready Schritt bringt das Projekt im aktiven Horizont am wirkungsvollsten voran — und warum (critical path / ready)?
 
 ---
 
-## 3. Plan-Objekte
+## 3. om_capabilities
+
+```text
+backlog, actions, roadmap, projects, blockers,
+evidence, decisions, reviews, steering_methods
+(+ work_cycles wenn agile_iteration aktiv)
+```
+
+---
+
+## 4. Plan- / Ist-Vertrag
+
+### 4.1 Plan-Objekte
 
 | Objekt | Pflicht / optional | Regeln |
 |--------|-------------------|--------|
-| `milestone` (Gates) | Pflicht | Kette / Graph; `requires` |
-| Project | empfohlen | „Hauptpfad“, „Begleitung“ |
-| Graph | empfohlen | kritischer Pfad = Read Model |
-| Execution-Plan (Action-Deps) | optional MVP | ergänzt Gate-Graph, ersetzt ihn nicht |
-| Recurring / work_cycle | nein als Kern | |
+| RoadmapItem Gate / Zielzustand (`milestone` / Gate-Semantik) | **≥1** Pflicht im laufenden Betrieb | fokussiertes / aktives Gate = Plan-Horizont; Verify vor `reached` |
+| Gate-Kette / Reihenfolge | empfohlen | Gate-Deps (`requires`) begrenzen, welches Gate „dran“ ist |
+| Project `project.linear_project` | optional, typisch ≥1 | Stränge (Hauptpfad, Begleitung, …); beliebig viele |
+| Graph Gate↔Gate | empfohlen | ohne jegliche Deps: Methode gültig, aber Attention `planning_debt` / flache Liste |
+| Graph Action↔Action | optional, schärft Ready | `requires`; azyklisch; keine künstliche Tiefencap |
+| `work_cycle` (Sprint) | nur mit Komposition Agile | genau ein aktiver Sprint; ohne aktiven Sprint → nur Primary |
+| BacklogItem (Eingang) | optional | Idee → Commit zu Action; nicht Leading Next |
 
-**Plan-Anti-Pattern:** Nur flache Action-Liste ohne Gates/Abhängigkeiten.
+**Plan-Anti-Pattern:** alle Gates gleichzeitig als gleichwertige Todo-Wand; Next außerhalb des aktiven Gate-/Sprint-Horizonts nur weil global „kritisch“.
 
----
-
-## 4. Ist-Objekte
+### 4.2 Ist-Objekte
 
 | Objekt | Rolle | Commit-Regel |
 |--------|-------|--------------|
-| Action | Arbeit am Strang / Gate | ready nur wenn Deps erfüllt |
-| Task | Feingranularität | unter Action |
-| BacklogItem | selten | Ideen vor Commit |
-| Blocker | Attention-Trigger | an Action/Initiative |
+| Action | Leading Work Item; Arbeitspaket am Gate/Pfad | aus Planung oder Commit aus Eingang; Assignment an Actor |
+| Task | unter Action | nicht Leading Object der Steuerung |
+| Evidence | Nachweis für Gate-Verify / Action | an Action oder Gate gebunden |
+| Decision | Waive von Deps, Scope-Änderung, Go/No-Go | auditiert |
+| Review | optional bei Meilenstein | nicht jeder AP |
+| Blocker | sperrt Ready | Attention `path_blocked`, nicht als ready verkaufen |
+| RecurringElement | nicht Kern | selten; kein A3-Ersatz |
+
+**Ist-Anti-Pattern:** flache Action-Liste ohne Horizont; blockierte Nachfolger als Next; Programm-Impulse als A2-Next.
+
+### 4.3 Multi-Stream innerhalb A2
+
+Mehrere Projects = parallele Stränge **im selben** Vorhaben (nicht B2a-Kinder).  
+Ready-Menge über alle Stränge, gefiltert auf aktiven Gate-/Sprint-Horizont.  
+Kritischer Pfad innerhalb dieses Horizonts — Spec-D D6.
+
+### 4.4 Closure & DoD
+
+| Ebene | Erwartung |
+|-------|-----------|
+| Gate | Kriterien + Verify → `reached`; Evidence nach Policy |
+| Vorhaben | Closure erwartet, wenn Lieferziel/DoD erreicht |
+| Ohne Closure-Druck wie B2b | A2 **hat** Ende als Natur |
+
+### 4.5 Komposition Agile (A2 + `agile_iteration`)
+
+| Schicht | Owner |
+|---------|--------|
+| Plan-Horizont | aktives Gate (Primary) |
+| Ist-Horizont | aktiver `work_cycle` |
+| Leading | weiterhin Action; Sprint filtert `work_cycle_id` |
+| Ohne aktiven Sprint | nur Primary — **kein** leerer Sprint-Screen |
+
+Sprint-Planung: Actions aus Eingang/Horizont in Sprint legen; Abschluss mit Carryover/Unplan — Spec-D Agile.
+
+### 4.6 Content / Buch
+
+Kein eigener Archetyp. Gleiche A2-Objekte; Template darf Kapitel als Gates/Projects labeln und EFS vorbelegen.
 
 ---
 
 ## 5. Steuerung
 
-**Methode:** `sequential_dependency`
+**Verbindlich:** Spec-D `sequential_dependency` (D3–D8, D11).  
+**Bei Agile:** zusätzlich Spec-D `agile_iteration`.
 
-| Signal | Logik | `reason_code` (Ziel) |
-|--------|-------|----------------------|
-| Next Action | nächster ready Schritt am kritischen Pfad | `critical_path_ready` |
-| Attention | Blocker, Gate at risk, überfälliges `target_date` | `path_blocked`, `gate_at_risk` |
-| Lifecycle | Abschluss möglich wenn Horizont erreicht | — |
+| Aspekt | Kurz |
+|--------|------|
+| Dominanz | plan |
+| Horizon | aktives Gate; mit Agile + Sprint zusätzlich work_cycle |
+| Leading | Action (ready ∩ Horizont ∩ critical-path-Ranking) |
+| Leerer Fall | Attention (blockiert / planning_debt) — keine Fake-Next |
+| Closure | erwartet |
+| Steering nur in | `backend/steering/` |
+
+### Steuerungselemente (Default-Methode)
+
+| `steering_element_key` | Rolle | Pflicht |
+|------------------------|-------|---------|
+| `next_action_primary` | begründete Next Action | ja |
+| `critical_path` | Pfad-/Horizon-Hinweis in Kontrolle | ja |
+| `gate_fulfillment` | Gate-Fortschritt / Verify | ja |
+| `work_cycle_scope` | Sprint-Scope | nur wenn Agile aktiv |
+
+`ui_features` (Methode): u. a. `criticalPathControl`; bei Agile Sprint-Work-Defaults.
 
 ---
 
-## 6. UI / IA
+## 6. EFS
 
-| Aspekt | Vorgabe |
-|--------|---------|
-| Prozessleiste | Zielzustände → Ausführen → Kontrolle |
-| Plan-Default | `/plan/gates` |
-| Work-Default | `/work/today` |
-| Control-Default | `/control/status` inkl. Critical-Path-Panel |
-| Versteckt | Recurring; Sprint nicht dominant |
+| `field_key` | Typ (Ziel) | Pflicht | Zweck |
+|-------------|------------|---------|-------|
+| `project_goal` | text | empfohlen | Ziel / Outcome in einem Satz |
+| `definition_of_done` | text | empfohlen | Vorhaben-DoD |
+| `target_completion` | date | nein | angestrebtes Ende |
+| `success_criteria` | text | nein | ergänzende Erfolgskriterien |
+| `scope_notes` | text | nein | Scope / Nicht-Scope |
+
+Gate-`target_date` und Kriterien liegen am RoadmapItem, nicht nur im EFS.
 
 ---
 
-## 7. EFS-Felder
-
-| `field_key` | Typ | Pflicht | Zweck |
-|-------------|-----|---------|-------|
-| `budget_summary` | text | optional | Katalog |
-| `primary_contractor` | text | optional | Katalog |
-| `target_completion` | date | empfohlen | Abnahme-Horizont |
-
-*(Code-Seeds ggf. nachziehen — Spec ist verbindlich für Welle 1.)*
-
----
-
-## 8. Starter-Kit
+## 7. Basiserfassung / Starter-Kit
 
 | Element | Inhalt |
 |---------|--------|
-| Kit | 4× Gate (G1 active … G4), `requires`-Kette; Projects Hauptpfad + Begleitung |
-| Guidance | „Nächster Schritt am kritischen Pfad — Abhängigkeiten im Plan-Graph.“ |
+| Kit (Minimum) | ≥1 Gate; ≥1 Project; ≥1 Action; Guidance |
+| Kit (Standard, bestehend AP2.2a) | 4 Gates in Kette; Projects „Hauptpfad“ + „Begleitung“; Dependency-Hinweis |
+| Guidance | „Kritischer Pfad und Abhängigkeiten steuern Next — nicht die Gesamtliste.“ |
+| Create | Titel, Archetyp; `project_goal` / DoD-Text empfohlen |
+| Ausprägung / Template | z. B. Content/Buch — Labels/Gates vorbelegen, Natur bleibt A2 |
 
 ---
 
-## 9. Happy Path
+## 8. UI-Hülle
 
-1. Anlegen mit Kit  
-2. Actions an G1 / Hauptpfad; Abhängigkeit setzen  
-3. Kontrolle: kritischer Pfad + Begründung  
-4. Blocker setzen → Attention  
-5. Gates fortschreiben bis Abschluss
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Profil** | EFS Ziel, DoD, Termine |
+| **Plan → Struktur** | Projects/Stränge anlegen, zuordnen |
+| **Plan → Gates** | Gate-Liste/-kette, aktiv/fokussiert, Kriterien, Verify, Deps |
+| **Plan → Graph / Optik** | Gate- und Action-Abhängigkeiten (Planungshilfe; keine Engine) |
+| **Plan → Eingang** | BacklogItems triage → Commit Action |
+| **Plan → Sprint** | nur wenn Agile: planen, aktiver Sprint, Carryover |
+| **Ausführen / Today** | Next + ready im Horizont; mit Sprint: Sprint-Backlog |
+| **Ausführen / Mine** | zugewiesene Actions |
+| **Kontrolle** | Status, Next + reason_code, Critical Path, Gate-Erfüllung, Attention |
+| **Journey** | Gate-Wechsel, Verify, Blocker, Closure, Sprint-Events |
+| **Process-Leiste** | Zielzustände → (optional Sprint) → Ausführen → Kontrolle |
+| **Nicht dominant** | Cadence-Health, Checklisten-Queue, Verfahrens-Timeline, Programm-Impulse als Primary-Next |
 
-### Negative
+Defaults: Plan `/plan/gates`; Work `/work/today` bzw. `/work/sprint` wenn Sprint aktiv.  
+Keine Archetyp-Ifs in Pages — Operating Context / `steering_elements`.
 
-1. Alle Handwerker-Schritte als gleichwertige Todos ohne Graph  
-2. Next Action zeigt blockierte AP als ready
+Product Language: Gate/Zielzustand, Arbeitspaket, kritischer Pfad; mit Agile: Sprint (nicht „Zeitbox“ als Ersatzwort erzwingen).
+
+---
+
+## 9. Happy Path (Abnahme-Flow)
+
+1. Projekt anlegen (A2) → Kit erzeugt Gates + Projects.  
+2. EFS Ziel/DoD setzen.  
+3. Actions am ersten Gate anlegen; mindestens eine `requires`-Kante (Gate oder Action).  
+4. Assignment; Ausführen zeigt Next mit Begründung `execution_critical_path` oder `execution_ready`.  
+5. Action erledigen → nächste ready Action erscheint.  
+6. Gate-Kriterien + Evidence → Verify → Gate `reached` → nächstes Gate Horizont.  
+7. Letztes Gate / DoD → Vorhaben-Closure.
+
+### Negative / Randfälle
+
+1. Aktives Gate ohne Actions → Attention `planning_debt`, keine Fake-Next.  
+2. Action durch Blocker gesperrt → nicht ready; Attention `path_blocked`.  
+3. Action auf globalem kritischem Pfad, aber **außerhalb** aktivem Gate/Sprint → **nicht** Next.  
+4. Agile ohne aktiven Sprint → Continuous-/Today-Pfad der Primary, kein leerer Sprint.  
+5. Keine Deps überhaupt → flache Liste möglich, aber Attention/Hinweis; Empfehlung Deps nachziehen.  
+6. Content-Template ändert Labels, nicht die Methode.
 
 ---
 
 ## 10. Abnahme-DoD
 
-| # | Erfüllt wenn |
-|---|--------------|
-| 1–2 | Kit + mind. eine Dependency-Kante |
-| 3 | ≥1 Action am Pfad |
-| 4 | Critical Path Panel mit Begründung |
-| 5–6 | Journey/Events + Leitfrage ≤2 Min |
-| 7 | Cockpit Attention bei Blocker (wenn Signal aktiv) |
-
-Szenario MVP §8 A2.
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Anlegen | A2 + Kit + Methode `sequential_dependency` |
+| 2 | Struktur | ≥1 Gate, ≥1 Project, ≥1 Dependency, ≥1 Action |
+| 3 | Ist | Action assignbar/erledigbar; Evidence an Gate möglich |
+| 4 | Next begründet | reason_code critical path oder ready; nur im Horizont |
+| 5 | Journey | Gate-Verify und Statuswechsel nachvollziehbar |
+| 6 | Leitfrage | ≤2 Min in Kontrolle beantwortbar |
+| 7 | Attention | Blocker / leerer Horizont sichtbar |
+| 8 | Optional Agile | Sprint aktiv → Work-Default Sprint; Horizon-Filter hält |
+| 9 | Closure | Vorhaben-/Gate-Abschluss durchspielbar |
+| 10 | Anti | keine Todo-Wand als Steuerung; kein program_delivery-Default |
 
 ---
 
-## 11. Ist-Stand
+## 11. Ist-Stand (Spec vs. Code)
 
-| Bereich | Spec | Code | Lücke |
-|---------|------|------|-------|
-| Starter-Kit | ✓ | ✓ | — |
-| Critical Path UI | ✓ | ◐ AP2.2b | Copy/Edge-cases |
-| Execution-Graph | ✓ optional | ◐ AP1.16 | nicht Pflicht für A2-Abnahme |
-| EFS target_completion | empfohlen | ○ | Seed nachziehen |
+| Bereich | Spec | Code/Truth (Stand Doku) | Lücke |
+|---------|------|-------------------------|-------|
+| Registry / Archetyp | A2 | vorhanden | compat eng auf A2 (M2 P1) |
+| Methode | `sequential_dependency` | Strategy/`execution_ready` nah | Feinschliff Horizon-Filter |
+| Starter-Kit | 4 Gates + 2 Projects | AP2.2a | EFS-Seeds |
+| `steering_elements` | next, critical_path, gate_fulfillment | teilweise | Parität FE/BE prüfen |
+| Agile Komposition | erlaubt | vorhanden | `composes_with` inkl. sequential |
+| Attention-Codes | Spec-D D7 | teilweise | angleichen |
+| EFS-Felder | diese Spec | Seeds lückenhaft | Seed-AP |
 
 ---
 
-## 12. Offene PO-Fragen
+## 12. Implementierung
 
-1. Ist Execution-Plan (AP-Deps) für A2-Abnahme Pflicht oder nice-to-have?  
-2. Muss Begleit-Project Actions haben, oder reicht leeres Parallel-Project?
+Fachmodell vollständig. Implementierungs-Schnitte (Seeds, Compat-Engführung, UI-Flächen Graph) nur in APs — Spec nicht kürzen.
 
 ---
 
 ## 13. Nachfolger
 
-- AP2.1 Szenario A2
+- EFS-Seed-AP für `project_goal` / `definition_of_done` / `target_completion`  
+- M2 P1: `compatible_archetype_keys` auf A2 (+ Kind)  
+- Validation gegen Happy Path auf Dev nach Deploy  

docs/product/archetypes/SPEC_A3_recurring_program_v0.1.md

@@ -1,11 +1,15 @@
 # SPEC — A3 `initiative.recurring_program`
-## Implementierungs-Spezifikation v0.1
+## Archetyp-Vollspec (implementierbar) v0.1
 
-**Status:** Entwurf (Welle 2 — Spec vor Code)  
-**Stand:** 2026-07-24  
-**MVP-Stufe:** B (Minimal) / B+ Score = AP2.0g  
-**Katalog:** ADP §5 A3  
-**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
+**MVP-Stufe:** B  
+**Decision-Lock:** A3 Rhythmus  
+**Default-Methode:** [`SPEC_D_recurring_control_v0.1.md`](../../architecture/methods/SPEC_D_recurring_control_v0.1.md)  
+**Komposition:** [`SPEC_D_agile_iteration_v0.1.md`](../../architecture/methods/SPEC_D_agile_iteration_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS/Kit/Happy Path hier; Ready/Ranking/Events/Attention in Spec-D.
 
 ---
 
@@ -14,122 +18,230 @@
 | Feld | Wert |
 |------|------|
 | `archetype_key` | `initiative.recurring_program` |
-| Label (DE) | Dauerprogramm / Rhythmus |
+| Label (Arbeit) | Rhythmus |
 | Default-`method_key` | `recurring_control` |
+| Primary (kompatibel) | nur `recurring_control` (**Ausführung**, Kernel §6) |
+| Komposition | `agile_iteration` (optional) |
 | Project-Spiegel | `project.recurring_program` |
-| MVP-Stufe | B |
+| Dominanz (über Methode) | event (+ plan-Slice wenn Agile aktiv) |
+| Closure | skip — Dauerprogramm |
 
 ### Abgrenzung
 
-| Nicht verwechseln mit | Unterschied |
-|-----------------------|-------------|
-| A1 | A3 steuert **Systemgesundheit/Rhythmus**, nicht Fähigkeits-Stufen |
-| B1 | Queue = Ad-hoc-Tickets; A3 = wiederkehrende Cadence |
-| Todo-Listen | **verboten:** verpasste Ausführung → neuer Task |
+| Nicht | Stattdessen |
+|-------|-------------|
+| A1 Reifegrad | Stufen/Können; Activity Sets bei Gate |
+| Care | Wohlergehen einer Fokus-Person |
+| B1 Checklisten | Ad-hoc Abhaken ohne Cadence-Kern |
+| A2 Projekt | Liefer-DoD / Closure erwartet |
+| B2a Programm | Meta-Schirm (anderer Key trotz „program“ im A3-Key) |
+| Templates | z. B. Haushalt = Template/Profil auf A3 |
 
 ---
 
-## 2. Nutzerbild & Referenzbeispiel
+## 2. Nutzerbild
 
-**Referenzbeispiel:** „Haus in Ordnung“ — Domains (Küche, Garten), Rhythmen pro Actor, Übernahme möglich (B+).
+Wiederkehrende Systempflege: Domains (Bereiche) und Rituale mit Cadence. Steuerung über **heute / fällig / überfällig** und Abweichung — nicht über Stufen und nicht über Task-Duplikate. Ein Ritual reicht (z. B. tägliche Meditation).
 
-**Leitfrage:** *Was ist heute fällig / überfällig — und wo weicht das System ab?*
+**Wer / Situation:** Haushalt, Facility-Rhythmus, persönliche Systempflege ohne Fürsorge- oder Skill-Kern.
+
+**Referenzbeispiel (durchspielbar) — „Haus in Ordnung“:**
+
+1. Domain-Projects: Küche, Garten (optional bei nur einem Ritual weglassbar).  
+2. Ritual „Küche wöchentlich“ + optional „Garten monatlich“ — eigene Cadences, Owner-Actors.  
+3. Today: fällig/überfällig; Erledigen → genau eine nächste Instanz.  
+4. Verpassen → Attention + Score, **kein** zweites offenes Duplikat.  
+5. Optional: Owner-Übernahme auditiert.  
+6. Optional Agile: Sprint mit Verbesserungs-Actions; Cadence overdue bleibt vor Sprint-Next.  
+7. Kontrolle: Domain-Health / Abweichung — keine Mitglieder-Task-Wall.
+
+**Leitfrage:** Was ist heute fällig / überfällig — und wo weicht das System ab?
 
 ---
 
-## 3. Plan-Objekte
+## 3. om_capabilities
 
-| Objekt | Pflicht / optional | Regeln |
-|--------|-------------------|--------|
-| Project (Domain) | optional | EFS `domain_label` |
-| Gates | minimal / aus | nicht Steuerungskern |
-| Recurring-Definitionen | Kern | Cadence, Owner-Actor |
+```text
+recurring, projects, actions, blockers,
+decisions, reviews, steering_methods
+(+ work_cycles wenn agile_iteration aktiv)
+```
+
+Roadmap/Gates: nicht steuerungsführend (dürfen existieren, steuern Next nicht).
 
 ---
 
-## 4. Ist-Objekte
+## 4. Plan- / Ist-Vertrag
 
-| Objekt | Regel |
-|--------|-------|
-| RecurringElement | **eine** offene Instanz pro Rhythmus |
-| ActionAssignment | Owner; B+: freiwillige Übernahme mit Audit |
-| Action | nur Eskalation / Ausnahme, nicht Duplikat-Staubsaugen |
+### 4.1 Plan-Objekte
 
-**Anti-Pattern:** 10× „Staubsaugen“ mit unterschiedlichen Daten als Tasks.
+| Element | Pflicht / optional | Regeln |
+|---------|-------------------|--------|
+| Project Domain | optional bei 1 Ritual; typisch ≥1 | Bereich, Beschreibung |
+| RecurringElement | **≥1** | Cadence + Owner; Domain-Bindung oder vorhaben-weit |
+| Abweichungs-Score | Vollmodell | je Ritual (+ verdichtet Domain) |
+| Gates | nicht Leading | |
+
+### 4.2 Ist-Objekte
+
+| Element | Rolle |
+|---------|--------|
+| CadenceInstance | Leading; **eine** offene Instanz pro Ritual |
+| Action | nur Ausnahme/Eskalation / bei Agile: Verbesserungsarbeit |
+| Assignment | Owner; freiwillige Übernahme mit Audit |
+| Blocker | Attention, nicht Fake-Ready |
+
+### 4.3 Regeln
+
+1. Verpassen → keine zweite Instanz; Attention + Score.  
+2. Mehrere Rituale zeitversetzt (eigene Cadences) — parallel erlaubt.  
+3. ≠ A1: kein Stage Activity Set / keine Stufen-Alternanz als Kern.  
+4. Meditation allein = gültiges Minimal-A3.
+
+### 4.4 Komposition Agile (A3 + `agile_iteration`)
+
+| Schicht | Inhalt |
+|---------|--------|
+| Cadence | Event-Kern der Systemgesundheit — auch mit Sprint |
+| Sprint | taktet **Actions** (Verbesserung/Sonderarbeit), nicht Ritual-Instanzen |
+| Ranking | Cadence overdue/due → Sprint-ready Actions → nächste Cadence als Hinweis |
+| Ohne Sprint | nur Primary |
+| Nicht | Rituale als Sprint-Todos; Primary ersetzen |
+
+### 4.5 Anti-Patterns
+
+- Task-Wand aus verpassten Terminen  
+- Alles als Action-Todos  
+- Gates als Leading Horizon  
 
 ---
 
 ## 5. Steuerung
 
-**Methode:** `recurring_control`
+**Verbindlich:** Spec-D `recurring_control` (D3–D8, D11).  
+**Bei Agile:** Spec-D `agile_iteration`.
 
-| Stufe | Signal |
-|-------|--------|
-| **B Minimal** | Next Action = fällig/heute; Attention = überfällig |
-| **B+ / AP2.0g** | Score (Cadence, verpasste Zyklen, Freiwilligkeit); Haushalts-Pool |
+| Aspekt | Kurz |
+|--------|------|
+| Dominanz | event (+ Sprint plan-Slice) |
+| Horizon | heute/fällig/überfällig (+ optional Domain) |
+| Leading | CadenceInstance |
+| Attention / Score | Spec-D D7 |
+| Steering nur in | `backend/steering/` |
+
+### Steuerungselemente
+
+| `steering_element_key` | Rolle | Pflicht |
+|------------------------|-------|---------|
+| `next_action_primary` | fällige/überfällige Instanz | ja |
+| `recurring_rhythm` | Ritual-Lage / Score | ja |
+| `work_cycle_scope` | Sprint | wenn Agile aktiv |
 
 ---
 
-## 6. UI / IA
+## 6. EFS
 
-Ausführen + „Team-Health“ dominant; Plan minimal; **kein** Task-Wall aller Mitglieder. Prozessleiste: spezifizieren in Welle 2 (noch kein methodUiDefaults-Eintrag).
+| `field_key` | Typ (Ziel) | Pflicht | Zweck |
+|-------------|------------|---------|-------|
+| `cadence_default` | text | empfohlen | Default-Rhythmus-Hinweis |
+| `domain_label` | text | nein | an Domain-Project; Template |
+| `household_members` | text | nein | Multi-Person-Hinweis (Template) |
+| `health_notes` | text | nein | Systemgesundheit |
+
+Cadence im Detail am RecurringElement.
 
 ---
 
-## 7. EFS
+## 7. Basiserfassung / Starter-Kit
 
-| `field_key` | Pflicht | Zweck |
-|-------------|---------|-------|
-| `household_members` | optional B / empfohlen B+ | |
-| `cadence_default` | empfohlen | |
-| `domain_label` | optional | Küche, Garten, … |
-
-*(Seeds fehlen weitgehend — Spec treibt Seeds.)*
+| Element | Inhalt |
+|---------|--------|
+| Kit (Minimum) | ≥1 Recurring (z. B. „Tägliche Meditation“); Domain optional |
+| Kit (Beispiel reich) | 1 Domain + 2 Rituale — Demo |
+| Guidance | „Heute fällig steuert — keine Task-Duplikate; ein Ritual reicht.“ |
+| Create | Titel, Archetyp; optional `cadence_default` |
+| Templates | Haushalt etc. auf A3 |
 
 ---
 
-## 8. Starter-Kit (Ziel)
+## 8. UI-Hülle
 
-1 Domain-Project, 2 Recurring (z. B. wöchentlich / monatlich), Guidance: „Heute fällig steuert — keine Task-Duplikate.“
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Domains** | Domain-Projects |
+| **Plan → Rituale** | Cadence, Owner, Domain-Bindung, aktiv |
+| **Plan → Profil** | EFS / Haushalt-Hinweise |
+| **Plan → Sprint** | nur bei Agile: Verbesserungs-Actions |
+| **Ausführen / Today** | fällig + überfällig; Sprint-Actions nachrangig |
+| **Kontrolle** | Next + Attention/Score; Domain-Health |
+| **Journey** | Zyklen, Übernahmen, Cadence-Änderungen, Sprint-Events |
+| **Process** | Domains/Rituale → Ausführen → Kontrolle |
+| **Elements** | `next_action_primary`, `recurring_rhythm`; ggf. `work_cycle_scope` |
+| **Nicht dominant** | Gate-Designer, Checklisten-Queue, Stufen-Timeline; Sprint nur Kompositions-Slice |
 
 ---
 
-## 9. Happy Path (B Minimal)
+## 9. Happy Path (Abnahme-Flow)
 
-1. Anlegen + 1–2 Rhythmen  
-2. Ausführen: heute fällig  
-3. Erledigen → nächster Zyklus, **kein** zweites offenes Duplikat  
-4. Überfällig → Attention  
-5. Kontrolle: Abweichung, nicht Gesamtliste
+1. A3 anlegen; ein Ritual (z. B. täglich Meditation).  
+2. Today zeigt fällig/überfällig korrekt.  
+3. Erledigen → genau eine nächste Instanz.  
+4. Verpassen simulieren → Attention + Score; kein Duplikat.  
+5. Optional: zweite Domain/Ritual; Owner-Übernahme.  
+6. Optional: Agile-Sprint mit Action; Cadence overdue vor Sprint-Next.  
+7. Leitfrage in Kontrolle ≤2 Min.
+
+### Negative / Randfälle
+
+1. Kein Ritual → ungültig / Kit erzwingen.  
+2. Verpasste Termine als Action-Wand → Anti-Pattern.  
+3. Agile ohne Sprint → nur Primary.  
+4. Rituale in Sprint-Backlog legen → Anti-Pattern.  
+5. Mit Care verwechseln (Wohlergehen) → falscher Archetyp.  
+6. Leerer Fall „nichts fällig“ → Erfolg „im Takt“, nicht Planning Debt.
 
 ---
 
-## 10. Abnahme-DoD (B Minimal)
+## 10. Abnahme-DoD
 
-Anlegen, Rhythmen, heute/fällig, Anti-Duplikat, Leitfrage ≤2 Min. Score/Übernahme = separat B+.
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Anlegen | A3 + ≥1 Ritual + `recurring_control` |
+| 2 | Today | fällig/überfällig korrekt |
+| 3 | Anti-Duplikat | eine Instanz; Verpassen ohne zweiten Task |
+| 4 | Attention/Score | überfällig sichtbar |
+| 5 | Optional Multi | zweites Ritual/Domain |
+| 6 | Optional Übernahme | Owner-Wechsel auditiert |
+| 7 | Optional Agile | Cadence vor Sprint-Next |
+| 8 | Leitfrage | ≤2 Min |
+| 9 | Journey | Zyklen nachvollziehbar |
+| 10 | Anti | keine Task-Wand |
 
 ---
 
-## 11. Ist-Stand
+## 11. Ist-Stand (Spec vs. Code)
 
-| Bereich | Code | Lücke |
-|---------|------|-------|
-| Registry | ✓ | — |
-| Strategie recurring_control | Stub/minimal | volle Spec + Implementierung |
-| Starter-Kit | ✗ | Welle 2 |
-| UI-Defaults | ✗ | Welle 2 |
-| Score / Übernahme | ✗ | AP2.0g nach Minimal |
+| Bereich | Spec | Code/Truth | Lücke |
+|---------|------|------------|-------|
+| Registry | A3 | vorhanden | — |
+| Methode | `recurring_control` | Stub/teilweise | volle Strategy + Score |
+| Kit | ≥1 Ritual | fehlt/teilweise | Kit-AP |
+| UI Domains/Rituale | Pflicht | lückenhaft | ui_profile |
+| Score/Abweichung | Vollmodell | fehlt | AP (Schnitt ok) |
+| Agile composes_with | recurring | Spec ✓ / Code prüfen | M2 P1 |
+| EFS | cadence_default etc. | Seeds lückenhaft | Seed-AP |
 
 ---
 
-## 12. Offene PO-Fragen
+## 12. Implementierung
 
-1. Reicht B Minimal (fällig/heute) für erste Auslieferung, Score später? **Empfehlung: ja**  
-2. Multi-Actor-Haushalt schon in B Minimal oder erst B+?  
-3. Domain = Project oder nur EFS-Tag?
+Fachmodell vollständig. Stub-Strategie, Score, Kit, UI = Implementierungs-Schuld — Spec nicht kürzen.
 
 ---
 
 ## 13. Nachfolger
 
-Assignment AP2.2f / AP2.0g nach Spec-Freigabe.
+- Strategy `recurring_control` voll  
+- Score/Attention  
+- Kit + ui_profile  
+- Agile-Parität Ranking  

docs/product/archetypes/SPEC_B1_checklists_v0.1.md

@@ -0,0 +1,245 @@
+# SPEC — B1 `initiative.checklists`
+## Archetyp-Vollspec (implementierbar) v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
+**MVP-Stufe:** B  
+**Decision-Lock:** B1 Checklisten (inkl. Bucket List)  
+**Default-Methode:** [`SPEC_D_checklist_flow_v0.1.md`](../../architecture/methods/SPEC_D_checklist_flow_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS/Kit/Happy Path hier; Ready/Ranking/Attention in Spec-D.  
+**Nicht im Zielbild:** `initiative.support_queue`, Methode `queue_pull` (Rename-Schuld).
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.checklists` |
+| Label (Arbeit) | Checklisten |
+| Default-`method_key` | `checklist_flow` |
+| Primary (kompatibel) | nur `checklist_flow` (**Ausführung**, Kernel §6) |
+| Komposition | — (kein Agile-Default) |
+| Project-Spiegel | `project.checklists` (Listen-Container) |
+| Dominanz | plan (sehr dünn) |
+| Closure | optional — Liste/Vorhaben archivieren, nicht Pflicht |
+
+### Abgrenzung
+
+| Nicht | Stattdessen |
+|-------|-------------|
+| B2b Product-Backlog | Eingang **am Product**; kein eigenes Checklisten-Vorhaben erzwingen |
+| A2 Projekt | Liefer-DoD / Gate-Pfad |
+| A3 / Care Rituale | Cadence/Fürsorge; Checkliste = Abhaken |
+| C1 Verfahren | Event→Stränge |
+| Bucket/Einkauf als Typ | **Templates** auf B1 |
+
+---
+
+## 2. Nutzerbild
+
+Mehrere Listen parallel; Punkte verschachtelt (Tiefe ≤ 3); Abhaken mit Parent-Roll-up. Leichte Steuerung — nah an klassischer Todo-Logik, aber als **ein** Vorhaben-Typ im Portfolio.
+
+**Wer / Situation:** Alltagslisten, Bucket List, Einkauf, Errands, Packlisten.
+
+**Referenzbeispiel (durchspielbar) — „Wochenende / Bucket“:**
+
+1. Listen: „Heute“, „Bucket“, „Einkauf“ — jede mit Beschreibung.  
+2. Unter „Bucket“: Sammlung „Reisen“ → Blatt „Island“, Blatt „Japan“.  
+3. Unter „Heute“: Blätter mit Fälligkeit/Prio.  
+4. Parent „Reisen“ lässt sich nicht schließen, solange Island/Japan offen.  
+5. Aktive Liste „Heute“ → Next = priorisiertes offenes Blatt.  
+6. Liste leer → „nichts offen“ (Erfolg), nicht Planning Debt.  
+7. Template „Einkauf“ legt nur Presets — Natur bleibt Checklisten.
+
+**Leitfrage:** Welches offene Blatt-ToDo ist als Nächstes dran — und welche Sammlung blockiert noch?
+
+---
+
+## 3. om_capabilities
+
+```text
+backlog, actions, projects, blockers, steering_methods
+```
+
+Roadmap/Gates: nicht steuerungsführend. Recurring: nicht Kern.
+
+---
+
+## 4. Plan- / Ist-Vertrag
+
+### 4.1 Listen
+
+| Regel | Inhalt |
+|-------|--------|
+| Anzahl | beliebig viele Listen parallel je Vorhaben |
+| Felder | Titel + Beschreibung (Beschreibung darf leer sein, Feld existiert) |
+| Verschachtelung Listen | **nein** — Listen sind Geschwister |
+| Persistenz | Liste = `Project` mit Spiegel `project.checklists` (Checklisten-Container) |
+| Horizon | **aktive Liste** (Nutzerwahl); Filter „alle Listen“ optional für Next |
+
+### 4.2 Punkte
+
+| Regel | Inhalt |
+|-------|--------|
+| Persistenz | `BacklogItem` (+ `parent_id`, `sort_order`, Listenbezug `project_id`) |
+| Tiefe | max. **3** unter der Liste: Liste → L1 → L2 → L3 |
+| Blatt-ToDo | erledigbar; keine Kinder (oder Kinder alle closed bevor es Sammlung bleibt) |
+| Sammlung | hat Unterpunkte (ToDo und/oder Sammlung bis Tiefe 3) |
+| Commit zu Action | optional, wenn volles Arbeitspaket nötig — **Normalfall = Abhaken am Item** |
+
+### 4.3 Schließen / Roll-up
+
+| Regel | Inhalt |
+|-------|--------|
+| Blatt | direkt schließbar |
+| Parent / Sammlung | **nur** schließbar, wenn alle direkten und indirekten Nachfahren geschlossen |
+| Validierung | System verhindert Schließen bei offenen Kindern (API + UI) |
+
+### 4.4 Ist / Nebenobjekte
+
+| Objekt | Rolle |
+|--------|-------|
+| Fälligkeit / Prio-Markierung am Item | Ranking (Spec-D) |
+| Blocker | selten; Attention |
+| Action | Ausnahme nach Commit |
+| Tags Ort/Thema | optional Template |
+
+### 4.5 Anti-Patterns
+
+- Product-Issues hier statt B2b-Eingang  
+- Alle Portfolio-Items als eine Wand  
+- Action als Pflicht für jedes Abhaken  
+- Listen ineinander verschachteln  
+- Tiefe > 3  
+
+---
+
+## 5. Steuerung
+
+**Verbindlich:** Spec-D `checklist_flow` (D3–D8, D11).
+
+| Aspekt | Kurz |
+|--------|------|
+| Horizon | aktive Liste |
+| Leading | offenes Blatt-ToDo (ChecklistItem / BacklogItem) |
+| Ranking | Prio → due → sort_order |
+| Leerer Fall | Erfolg „nichts offen“ |
+| Lifecycle | viele Schlitze `n/a` — gültig degeneriert |
+| Steering nur in | `backend/steering/` |
+
+### Steuerungselemente
+
+| `steering_element_key` | Rolle | Pflicht |
+|------------------------|-------|---------|
+| `next_action_primary` | Next Blatt | ja |
+| Checklisten-Panel (`queue_inbox` → fachlich umwidmen) | Listen/Punkte | ja |
+
+---
+
+## 6. EFS
+
+| `field_key` | Typ (Ziel) | Pflicht | Zweck |
+|-------------|------------|---------|-------|
+| `default_list_label` | text | nein | Name der ersten Liste (Kit) |
+| `checklist_notes` | text | nein | Notizen zum Vorhaben |
+| `capture_hints` | text | nein | Hinweis Bulk/Paste (Template) |
+
+Listenbeschreibung liegt am Project/Liste, nicht nur im EFS.
+
+---
+
+## 7. Basiserfassung / Starter-Kit
+
+| Element | Inhalt |
+|---------|--------|
+| Kit (Minimum) | 1 Liste inkl. Beschreibungsfeld; Beispielstruktur mindestens Tiefe 2; Guidance Roll-up |
+| Kit (Abnahme) | ≥2 Listen; Struktur Tiefe 3 demonstrierbar |
+| Guidance | „Blatt abhaken; Parent erst wenn alle Kinder closed; aktive Liste steuert Next.“ |
+| Create | Titel, Archetyp |
+| Templates | Bucket, Einkauf, Errands — Presets auf B1 |
+
+---
+
+## 8. UI-Hülle
+
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Listen** | Umschalter / Nebeneinander; Titel + Beschreibung; aktive Liste wählen |
+| **Plan → Punkte (Outline)** | Nested-Outline Tiefe ≤ 3; drag/sort; Blatt vs. Sammlung erkennbar |
+| **Plan → Profil** | EFS / Notizen |
+| **Eingang / Capture** | einzeln, Paste/Bulk (wenn freigegeben) |
+| **Ausführen / Next** | priorisiertes offenes Blatt (aktive Liste oder Filter alle) |
+| **Kontrolle** | Next + Attention (overdue, overflow, Parent mit offenen Kindern) |
+| **Journey** | Abhak-Historie, Listenwechsel (leicht) |
+| **Process** | Listen → Ausführen/Next → Kontrolle |
+| **Elements** | `next_action_primary`, Checklisten-Panel |
+| **Nicht dominant** | Sprint, Gate-Designer, Cadence-Health, Verfahrens-Stränge |
+
+Product Language: Liste, Punkt, Blatt, Sammlung — nicht „Gate“/„Sprint“ als Kernworte.
+
+---
+
+## 9. Happy Path (Abnahme-Flow)
+
+1. Checklisten-Vorhaben anlegen → Kit-Liste.  
+2. Zweite Liste anlegen inkl. Beschreibung.  
+3. Tiefe-3-Struktur: Sammlung → Unter-Sammlung → Blatt.  
+4. Versuch Parent zu schließen bei offenem Kind → verhindert.  
+5. Blätter schließen → Parent schließbar.  
+6. Aktive Liste wählen → Next zeigt offenes Blatt mit reason_code.  
+7. Liste leer → „nichts offen“.
+
+### Negative / Randfälle
+
+1. Tiefe 4 anlegen → Validierungsfehler.  
+2. Product-Bug hier erfassen → Anti-Pattern (nach B2b).  
+3. Jeden Punkt als Action committen → schwerfällig, nicht Normalfall.  
+4. Filter „alle Listen“: Ranking über Listen, Horizon-Hinweis behalten.  
+5. Rename-Schuld `support_queue`/`queue_pull` sichtbar in Altcode — Zielkeys nutzen.
+
+---
+
+## 10. Abnahme-DoD
+
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Anlegen | `initiative.checklists` + `checklist_flow` |
+| 2 | Multi-Listen | ≥2 Listen mit Beschreibungsfeld |
+| 3 | Nested | Tiefe 3 durchspielbar |
+| 4 | Roll-up | Parent-Schließen erst nach Kindern |
+| 5 | Next | offenes Blatt, begründet |
+| 6 | Leerer Fall | Erfolg, nicht Planning Debt |
+| 7 | Leitfrage | ≤2 Min |
+| 8 | Template | Preset ändert nicht Archetyp-Natur |
+| 9 | Anti | kein Product-Backlog-Ersatz |
+| 10 | Keys | Ziel `checklists` / `checklist_flow` (Rename-AP) |
+
+---
+
+## 11. Ist-Stand (Spec vs. Code)
+
+| Bereich | Spec | Code/Truth | Lücke |
+|---------|------|------------|-------|
+| Archetyp-Key | `initiative.checklists` | oft `support_queue` | Rename P0/P1 |
+| Methode | `checklist_flow` | `queue_pull` nah | Rename + Nested |
+| Nested Tiefe 3 + Roll-up | Pflicht | unvollständig | P0 |
+| Multi-Listen | Pflicht | prüfen | P0 |
+| Starter-Kit | diese Spec | fehlt/teilweise | P1 |
+| steering_elements | Panel umwidmen | queue_inbox | fachlich umbenennen |
+
+---
+
+## 12. Implementierung
+
+Fachmodell vollständig. APs dürfen phasieren (Nested zuerst, Templates danach) — **ohne** Spec zu kürzen.
+
+---
+
+## 13. Nachfolger
+
+- Seed + Rename Keys  
+- Nested-Validierung  
+- Template-APs Bucket/Einkauf  

docs/product/archetypes/SPEC_B2a_program_v0.1.md

@@ -1,11 +1,15 @@
 # SPEC — B2a `initiative.program`
-## Implementierungs-Spezifikation v0.1
+## Archetyp-Vollspec (implementierbar) v0.1
 
-**Status:** Entwurf (Welle 1)  
-**Stand:** 2026-07-24  
-**MVP-Stufe:** A\* (ADP Stufe A; MVP v0.3 nennt A1/A2/B2b primär — B2a mitdenken)  
-**Katalog:** ADP §5 B2a  
-**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
+**MVP-Stufe:** A (Validation mitdenken; Strategy-Umbau P0)  
+**Decision-Lock:** B2a Hybrid-Steuerung  
+**Default-Methode:** [`SPEC_D_program_delivery_v0.1.md`](../../architecture/methods/SPEC_D_program_delivery_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md` (Q4 Nested Pflicht)  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS/Kit/Happy Path hier; Impulse/Ranking/Attention in Spec-D.  
+**Hinweis Code:** Ist-Strategy weicht ab (flach) — Spec = Zielbild; DoD voll erst nach M2-P0.
 
 ---
 
@@ -14,117 +18,233 @@
 | Feld | Wert |
 |------|------|
 | `archetype_key` | `initiative.program` |
-| Label (DE) | Programm (begrenzt) |
+| Label (Arbeit) | Programm |
 | Default-`method_key` | `program_delivery` |
-| Project-Spiegel | `project.program` |
-| MVP-Stufe | A\* |
+| Primary (kompatibel) | nur `program_delivery` (**Meta**, Kernel §6) |
+| Komposition am Dach | **keine** (insb. kein `agile_iteration` am Programm) |
+| Kinder | je eigener Archetyp + Primary (+ deren Komposition, z. B. Agile am Kind) |
+| Project-Spiegel | `project.program` (Programm-Stränge); Kinder = Child-Kontexte |
+| Dominanz | plan (+ Signale aus Kindern) |
+| Closure | **erwartet** — Programm ist begrenzt |
 
 ### Abgrenzung
 
-| Nicht verwechseln mit | Unterschied |
-|-----------------------|-------------|
-| B2b Product | Programm hat **Abschluss/Closure**; Product ist Dauerbetrieb |
-| A2 Linear | Programm = Phasen/Release-Horizont + Backlog; A2 = Einmalprojekt-Pfade |
-| B3 | Sprint optional auf Programm, kein eigener Typ |
+| Nicht | Stattdessen |
+|-------|-------------|
+| A2 Multi-Stream | ein Vorhaben, eine Ausführungs-Methode, restriktiver Pfad |
+| B2b Product | Dauerbetrieb, Closure nicht Kern |
+| A3 `recurring_program` | Rhythmus-Vorhaben, kein Meta-Schirm |
+| Agile am Programm-Meta | Agile nur an Kind A2/B2b/A3 |
+| Programm steuert Child-AP-Reihenfolge | Impulse + aggregierte Kind-Lage; Child-NA bleibt Kind |
 
 ---
 
-## 2. Nutzerbild & Referenzbeispiel
+## 2. Nutzerbild
 
-**Referenzbeispiel:** Release-Programm / Großvorhaben mit Ende („Kairo Release-Programm“).
+Dach über mehreren eigenständigen Teilen. Das Programm priorisiert, entblockt und prüft übergreifende Meilensteine — es **ersetzt nicht** die Next Action der Kinder.
 
-**Leitfrage:** *Was blockiert den nächsten Meilenstein — und wann ist Closure sinnvoll?*
+**Wer / Situation:** Release- oder Transformationsprogramm mit heterogenen Teilen (z. B. Fachkonzept als A2 + laufendes System als B2b).
+
+**Referenzbeispiel (durchspielbar) — „Produktlaunch-Programm“:**
+
+1. Programm mit Phasen „Konzept“, „Build“, „Go-Live“.  
+2. Kind A: A2 „Fachkonzept“ (`sequential_dependency`).  
+3. Kind B: B2b „Plattform“ (`continuous_product`, optional Agile).  
+4. Kreuz-Dep: Go-Live-Meilenstein braucht Konzept-Gate `reached` **und** Plattform-Release-Action.  
+5. Kontrolle Programm: Impuls „Kind A entblocken / Priorität Konzept“ — **nicht** die konkrete Schreib-Action aus Kind A als Programm-Next.  
+6. Zweiter Block in UI: Child-NAs nur als Lage („Kind A: Next = …“).  
+7. Kind B Sprint läuft — Programm-Horizon bleibt Programm-Phase, nicht der Sprint.  
+8. Programm-Closure wenn Meilensteine/Kinder closure-fähig.
+
+**Leitfrage Programm:** Welcher übergeordnete Impuls (Roadblocker, Kreuz-Dep, Priorität, Meilenstein-Risiko)?  
+**Leitfrage Kind:** unverändert die Kind-Methode.
 
 ---
 
-## 3. Plan-Objekte
+## 3. om_capabilities
+
+```text
+backlog, actions, roadmap, projects, blockers,
+evidence, decisions, reviews, steering_methods
+(+ read-model: child_contexts / lage)
+(+ work_cycles nur auf Kind-Kontexten, nicht als Programm-Default)
+```
+
+---
+
+## 4. Plan- / Ist-Vertrag
+
+### 4.1 Programm-Ebene (Dach)
 
 | Objekt | Pflicht / optional | Regeln |
 |--------|-------------------|--------|
-| `milestone` / Phasen-Gates | Pflicht | Horizont mit Abschluss-Gate |
-| Backlog (Eingang) | empfohlen | zahlt auf Gates ein |
-| `work_cycle` | optional | B3-Komposition |
-| `feature` / `review_gate` | optional | post-A ok |
+| Programm-Initiative | Pflicht | Archetyp program, Methode `program_delivery` |
+| Programm-Meilensteine / Phasen (RoadmapItem) | ≥1 empfohlen | Programm-Plan-Horizont; Verify vor `reached` |
+| Kreuz-Deps | empfohlen | Kanten zwischen Kind-Horizonten / Programm-Items |
+| Programm-Büro-Actions | optional, **sekundär** | interne Programm-Arbeit; dürfen Impulse-Next **nicht** ersetzen/tarnen |
+| Programm-Eingang (Backlog) | optional | Ideen/Impulse-Vorstufen |
+| ProgramImpulse | Leading Meta (Read-Model / Steuerobjekt) | reason_codes Spec-D D6; kein Child-AP |
 
----
+### 4.2 Kind-Kontexte (Hybrid)
 
-## 4. Ist-Objekte
+| Regel | Inhalt |
+|-------|--------|
+| **Primärbild** | Child = **Project** unter der Programm-Initiative mit eigenem `archetype_key` / `method_key`-Override und eigenem SteeringContext |
+| **Optional später** | verlinkte eigene Initiativen als Kinder — Logik adressiert immer Child SteeringContext |
+| Archetyp-Mix | Kinder dürfen **unterschiedliche** oder gleiche Archetypen haben |
+| Create | Programm ohne Kind erlaubt; Guidance „Kind anlegen“ Pflicht; Create-Blocker optional |
+| Nested | Parent-Impulse ≠ Child-Next (Kernel Q4) |
 
-| Objekt | Rolle |
-|--------|-------|
-| Action + Task | Lieferung am Horizont |
-| BacklogItem → Action | Commit mit optionalem Gate-Link |
-| Review | Abschluss / Gate-Review |
+### 4.3 Zwei Steuerkanäle (verbindlich)
+
+| Kanal | Inhalt | UI |
+|-------|--------|-----|
+| **B — Program Impulse** | Roadblocker, Kreuz-Dep, Priorität, Meilenstein-Risiko | **primär** auf Programm-Kontrolle |
+| **A — Child Next Actions** | unverändert von Kind-Methode | **zweiter, klar getrennter** Block / Drilldown |
+
+**Verboten:** Programm-`action_selection` gibt eine Child-Action als *die* Next Action des Programms aus.
+
+### 4.4 Closure
+
+Programm-Ende erwartet. Kind-Closures speisen Programm-Closure-Prüfung. Product-Kinder können „dauerhaft“ bleiben — dann Closure-Kriterien am Programm explizit (Scope-Schnitt), nicht stillschweigend Kind-Closure erzwingen.
+
+### 4.5 Anti-Patterns
+
+- Flaches A2 auf Programm-Initiative (Ist-Code-Schuld)  
+- Agile als Programm-Default  
+- Impulse und Child-NA in einem ungetrennten Next  
+- Programm-Büro-Action als Tarn-Primary-Next  
 
 ---
 
 ## 5. Steuerung
 
-**Methode:** `program_delivery`
+**Verbindlich:** Spec-D `program_delivery` (D3–D9, D11).
 
-| Signal | Logik |
-|--------|-------|
-| Next Action | Gate / AP am Programm-Horizont |
-| Attention | Gate at risk, Blocker, Backlog am aktiven Gate |
-| Lifecycle | **inkl. Closure** |
+| Aspekt | Kurz |
+|--------|------|
+| Methodentyp | Primary **Meta** |
+| Horizon | Programm-Phasen + Kind-Lage |
+| Leading Dach | ProgramImpulse |
+| Leading Kind | Kind-Methode |
+| Closure | erwartet |
+| Steering nur in | `backend/steering/` |
+
+### Steuerungselemente
+
+| `steering_element_key` | Rolle | Pflicht |
+|------------------------|-------|---------|
+| `next_action_primary` | zeigt **Impulse** auf Programm-Kontext | ja |
+| `gate_fulfillment` | Programm-Meilensteine | ja |
+| `program_child_lage` | aggregierte Kind-Lage / Child-NA-Block | ja |
+| `cross_dependency` | Kreuz-Deps sichtbar | empfohlen |
 
 ---
 
-## 6. UI / IA
+## 6. EFS
 
-Prozessleiste: Phasen → Eingang → Ausführen → Kontrolle. Plan-Default: Gates.
+| `field_key` | Typ (Ziel) | Pflicht | Zweck |
+|-------------|------------|---------|-------|
+| `program_goal` | text | empfohlen | Programmziel |
+| `program_definition_of_done` | text | empfohlen | Wann ist das Programm „fertig“? |
+| `target_completion` | date | nein | angestrebtes Programm-Ende |
+| `program_scope_notes` | text | nein | Scope / Nicht-Scope / Kind-Grenzen |
+| `sponsor_actor_ref` | actor ref | nein | Sponsor / Auftraggeber |
 
 ---
 
-## 7. EFS
+## 7. Basiserfassung / Starter-Kit
 
-| `field_key` | Pflicht | Zweck |
-|-------------|---------|-------|
-| `stakeholder_map` | optional | vorhanden (program/product seeds) |
-| `success_criteria` | empfohlen | Abschlusskriterien |
-| `release_theme` | optional | |
+| Element | Inhalt |
+|---------|--------|
+| Kit | Phase 1–2 + Abschluss-Meilenstein (bestehend AP2.2a-Idee) |
+| Nach Create | Guidance: mindestens ein Kind-Kontext (Project + Archetyp/Methode) |
+| Guidance | „Kinder steuern sich selbst; Programm zeigt Blocker und Priorität.“ |
+| Create | Titel, Archetyp; Ziel/DoD empfohlen |
+| Beispiel-Setup Abnahme | Kind A2 + Kind B2b |
 
 ---
 
-## 8. Starter-Kit
+## 8. UI-Hülle
 
-Phase 1 Start (active), Phase 2 Lieferung, Abschluss — laut AP2.2a.
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Profil** | EFS Programmziel, DoD, Sponsor |
+| **Plan → Phasen / Gates** | Programm-Meilensteine, Verify |
+| **Plan → Struktur / Kinder** | Child-Projects anlegen, Archetyp/Methode je Kind, Navigation in Kind-Kontext |
+| **Plan → Kreuz-Deps** | Deps zwischen Kindern / Meilensteinen (Optik erlaubt) |
+| **Plan → Eingang** | optional Programm-Backlog |
+| **Ausführen** | sekundär: Programm-Büro-Actions; **nicht** Child-AP-Liste als Primary |
+| **Kontrolle** | **Kanal B** Impulse primär; **Kanal A** Child-Lage getrennt; Attention Programm |
+| **Kind-Drilldown** | volle Kind-UI laut Kind-Archetyp |
+| **Journey** | Meilenstein-Wechsel, Impuls-Historie, Kind-Status, Closure |
+| **Process** | Phasen → Kinder/Struktur → Kontrolle (Impulse) → optional Büro-Arbeit |
+| **Nicht** | Sprint als Programm-Default; Child-Action als einzige Programm-Next |
+
+Defaults: Plan `/plan/gates` (Programm-Phasen); Control = Programm-Lage.
 
 ---
 
-## 9. Happy Path
+## 9. Happy Path (Abnahme-Flow)
 
-1. Anlegen mit Phasen-Kit  
-2. Backlog → Action am aktiven Gate  
-3. Kontrolle: Horizont + Next Action  
-4. Abschluss-Gate / Lifecycle Closure
+1. Programm anlegen → Kit Phasen.  
+2. Kind A (A2) + Kind B (B2b) anlegen.  
+3. Kreuz-Dep / Roadblocker setzen, der beide betrifft.  
+4. Kontrolle Programm: Impulse mit `program_roadblocker` oder `program_cross_dependency` — **nicht** identisch mit Kind-A-Next.  
+5. Child-Block zeigt getrennte Next je Kind.  
+6. Kind A arbeitet im eigenen Scope; Programm-Impulse aktualisieren sich.  
+7. Programm-Meilenstein verify; Closure-Pfad erkennbar.
+
+### Negative / Randfälle
+
+1. Strategy liefert Child-Action als Programm-Next → **Spec-Verstoß** / Gap-Test (Ist-Code).  
+2. Nur ein Kind, gleicher Archetyp → gültig.  
+3. Create ohne Kind → gültig mit Guidance.  
+4. Agile nur am Kind B → Programm-Horizon bleibt Phase.  
+5. Programm-Büro-Action erledigen ändert nicht die Bedeutung von Impulse-Primary.  
+6. Leere Impulse + stabile Kinder → Lage „stabil“, nicht Fake-Child-NA.
 
 ---
 
 ## 10. Abnahme-DoD
 
-Mindestens: Phasen sichtbar, Next Action am Horizont, Closure-Pfad dokumentiert (auch wenn UI minimal). Leitfrage ≤2 Min.
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Anlegen | Programm + Kit + `program_delivery` |
+| 2 | Hybrid | ≥2 Kinder, unterschiedliche Methoden/Archetypen durchspielbar |
+| 3 | Kanäle | Impulse ≠ Kopie einer Child-NA |
+| 4 | Nested | Child-NA nur im Kind-Scope korrekt |
+| 5 | Kreuz-Dep / Roadblocker | erzeugt Programm-Impulse/Attention |
+| 6 | Meilenstein / Closure | Pfad erkennbar |
+| 7 | Leitfrage | Programm ≤2 Min (Impuls/Blocker) |
+| 8 | UI | zwei getrennte Blöcke |
+| 9 | Anti | kein Agile-Default am Dach |
+| 10 | Code-Gap | bis M2-P0 Tests markieren Ist≠Spec |
 
 ---
 
-## 11. Ist-Stand
+## 11. Ist-Stand (Spec vs. Code)
 
-| Bereich | Code | Lücke |
-|---------|------|-------|
-| Kit | ✓ | — |
-| UI-Prozess | ✓ | — |
-| Closure-Lifecycle UX | ◐ | Spec: expliziter Abschluss-Schritt nötig |
-| Strategie program_delivery | ◐ | vs. Legacy product_milestone_driven |
+| Bereich | Spec | Code/Truth | Lücke |
+|---------|------|------------|-------|
+| Registry | program | vorhanden | — |
+| Strategy | Impulse + Nested | flach Gate/AP am Programm | **P0 M2** |
+| Read-Model Kind-Lage | Pflicht | fehlt/unvollständig | P0 |
+| UI zwei Kanäle | Pflicht | fehlt | P0 |
+| Child Context an Project-Override | Primärbild | teilweise | P1 |
+| Starter-Kit Phasen | vorhanden | AP2.2a | behalten |
+| EFS | diese Spec | Seeds lückenhaft | Seed-AP |
 
 ---
 
-## 12. Offene PO-Fragen
+## 12. Implementierung
 
-1. Ist B2a **Pflicht** für AP2.1 oder nur „mitdenken“?  
-2. Wann wechselt ein abgeschlossenes Programm bewusst zu Product-Betrieb (Datenmodell)?
+Fachmodell vollständig als Zielbild. P0 Strategy/UI ist Implementierungs-Schuld gegen diese Spec — Spec nicht auf Ist-Code zurückbiegen.
 
 ---
 
 ## 13. Nachfolger
 
-AP2.2e / AP2.1 nach Spec-Freigabe.
+- M2 P0: `program_delivery` Nested + Impulse + UI-Kanäle  
+- EFS-Seeds  
+- optional verlinkte Initiativen als Kinder  

docs/product/archetypes/SPEC_B2b_product_v0.1.md

@@ -1,11 +1,15 @@
 # SPEC — B2b `initiative.product`
-## Implementierungs-Spezifikation v0.1
+## Archetyp-Vollspec (implementierbar) v0.1
 
-**Status:** Entwurf (Welle 1 — Verdichtung)  
-**Stand:** 2026-07-24  
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
 **MVP-Stufe:** A  
-**Katalog:** ADP §5 B2b  
-**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+**Decision-Lock:** B2b Produkt  
+**Default-Methode:** [`SPEC_D_continuous_product_v0.1.md`](../../architecture/methods/SPEC_D_continuous_product_v0.1.md)  
+**Komposition:** [`SPEC_D_agile_iteration_v0.1.md`](../../architecture/methods/SPEC_D_agile_iteration_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS/Kit/Happy Path hier; Ready/Ranking/Attention/Events in Spec-D.
 
 ---
 
@@ -14,126 +18,227 @@
 | Feld | Wert |
 |------|------|
 | `archetype_key` | `initiative.product` |
-| Label (DE) | Produkt (kontinuierlich) |
+| Label (Arbeit) | Produkt |
 | Default-`method_key` | `continuous_product` |
-| Ausprägung | z. B. `product.kairo_dev` |
+| Primary (kompatibel) | nur `continuous_product` (**Ausführung**, Kernel §6) |
+| Komposition | `agile_iteration` (optional) |
 | Project-Spiegel | `project.product` |
-| MVP-Stufe | A |
+| Dominanz | plan (Incidents hybrid-light) |
+| Closure | **nicht** Kernziel — Dauerbetrieb / Adaptation; Closure `n/a` bzw. selten |
 
 ### Abgrenzung
 
-| Nicht verwechseln mit | Unterschied |
-|-----------------------|-------------|
-| B2a Programm | kein fixes Closure-Ziel; Adaptation / Dauerbetrieb |
-| B1 Queue | Product hat Plan-Horizont + optional Sprint; Queue ist Pull-Inbox |
-| B3 | Profil auf Product, kein eigener Archetyp |
+| Nicht | Stattdessen |
+|-------|-------------|
+| A2 Projekt | angestrebtes Ende / DoD-Abschluss |
+| B2a Programm | Meta-Schirm + Impulse |
+| A1 Reifegrad | persönliches Können |
+| B1 Checklisten | Product-Backlog = Eingang **dieses** Produkts |
+| A3 Rhythmus | System-Cadence ohne Produkt-Weiterentwicklung als Kern |
 
 ---
 
-## 2. Nutzerbild & Referenzbeispiel
+## 2. Nutzerbild
 
-**Referenzbeispiel:** Kairo-Betrieb — Issues, Features, Wartung; optional Sprints mit Vibe-Coder.
+Dauerhaftes System/Produkt: Weiterentwicklung, Betrieb, Bugs, Ops. Eingang dauerhaft triagieren und zu Actions committen. Optional Sprints als Takt — ohne Sprint bleibt Continuous gültig.
 
-**Leitfrage:** *Was ist jetzt am wirksamsten — im aktiven Gate- oder Sprint-Horizont?*
+**Wer / Situation:** Product Owner / Dev-Team / Vibe-Coder an einem laufenden Produkt (Referenz: Kairo selbst).
+
+**Referenzbeispiel (durchspielbar) — „Kairo-Betrieb“:**
+
+1. Eingang: BacklogItem „Login-Timeout Bug“ + „Export-Feature“.  
+2. Bug als kritisch committen → Action → Next/Attention `product_issue_critical`.  
+3. Feature triagieren → Action am Orientierungs-Gate „Q-Horizon“ (optional).  
+4. Ohne Sprint: Today zeigt wirkungsvollste ready Action.  
+5. Optional: Sprint anlegen, Items einplanen, Work-Default Sprint, abschließen mit Carryover.  
+6. Ohne aktiven Sprint: **kein** leerer Sprint-Screen — Fallback Continuous.  
+7. Kein Zwang, das Product-Vorhaben zu closen.
+
+**Leitfrage:** Wirkungsvollster Schritt im aktiven Horizont (Orientierungs-Gate **oder** Sprint) — warum?
 
 ---
 
-## 3. Plan-Objekte
+## 3. om_capabilities
+
+```text
+backlog, actions, roadmap, projects, blockers,
+evidence, decisions, reviews, work_cycles, steering_methods
+```
+
+`work_cycles` in Capabilities auch wenn Sprint ungenutzt; Strategie/UI ohne aktiven Sprint = Continuous.
+
+---
+
+## 4. Plan- / Ist-Vertrag
+
+### 4.1 Plan-Objekte
 
 | Objekt | Pflicht / optional | Regeln |
 |--------|-------------------|--------|
-| Gates/Meilensteine | Orientierung | kein finales End-Gate erzwingen |
-| Eingang (BacklogItem) | Kern | Product Backlog |
-| `work_cycle` | optional | B3 |
-| Projects | empfohlen | z. B. Entwicklung, Betrieb |
+| Eingang (BacklogItem) | **dauerhaft Pflicht-Kanal** | Triage; nicht Leading Next bis Commit |
+| Orientierungs-Gate / Meilenstein | optional | kein finales End-Gate erzwingen; Create-Blocker **nein** |
+| Project `project.product` | empfohlen | z. B. Entwicklung / Betrieb |
+| `work_cycle` | nur mit Agile | genau ein aktiver Sprint |
 
----
+### 4.2 Ist-Objekte
 
-## 4. Ist-Objekte
+| Objekt | Rolle | Commit-Regel |
+|--------|-------|--------------|
+| Action | Leading nach Commit | aus Backlog oder direkt; Assignment |
+| Task | unter Action | nicht Leading |
+| Sprint-Backlog | Actions mit `work_cycle_id` | **nicht** BacklogItem-Liste |
+| Evidence / Blocker / Decision | Normalbetrieb | Incident/Bug = Normalzustand |
+| Review | optional (Sprint/Product-Lage) | |
 
-| Objekt | Rolle |
-|--------|-------|
-| Action | Feature / Fix / Ops — committet |
-| Action + `work_cycle_id` | Sprint-Backlog |
-| BacklogItem | noch nicht committet |
-| Task | unter Action |
+### 4.3 Continuous vs. Sprint
 
-**Anti-Pattern:** Sprint-Backlog als BacklogItem-Liste; alle APs aller Gates in einer Hauptliste.
+| Situation | Verhalten |
+|-----------|-----------|
+| Kein aktiver Sprint | Next = Continuous-Ranking (Spec-D D6); Work today/mine |
+| Aktiver Sprint | Next = ready ∩ Sprint; Work-Default Sprint |
+| Sprint beendet / keiner | Carryover/Unplan; zurück Continuous |
+| Incident kritisch | Ranking/Attention hybrid-light (Spec-D) |
+
+### 4.4 Closure
+
+Kein Closure-Zwang. Archiv nur Ausnahmefall. Gates sind Orientierung, nicht „Projektende“.
+
+### 4.5 Anti-Patterns
+
+- Sprint-Backlog als BacklogItem-Liste  
+- Alle APs aller Gates in einer Hauptliste  
+- Leerer Sprint-Screen ohne aktiven Sprint  
+- Closure erzwingen  
+- Product-Backlog als separates B1-Vorhaben erzwingen  
 
 ---
 
 ## 5. Steuerung
 
-**Methode:** `continuous_product` (+ `agile_iteration` wenn Sprint aktiv)
+**Verbindlich:** Spec-D `continuous_product` + bei Nutzung Spec-D `agile_iteration`.
 
-| Signal | Logik |
-|--------|-------|
-| Next Action | wirkungsvollster Schritt im aktiven Horizont (Gate **oder** Sprint) |
-| Attention | kritische Issues, leerer Sprint bei aktivem Zyklus, Planning Debt |
-| Lifecycle | kein erzwungenes Closure |
+| Aspekt | Kurz |
+|--------|------|
+| Dominanz | plan (Incident hybrid-light) |
+| Horizon | Orientierungs-Gate und/oder Continuous; Ist-Sprint wenn aktiv |
+| Leading | committete Action |
+| Intake | jederzeit |
+| Closure-Schlitz | typisch `n/a` |
+| Steering nur in | `backend/steering/` |
+
+### Steuerungselemente
+
+| `steering_element_key` | Rolle | Pflicht |
+|------------------------|-------|---------|
+| `next_action_primary` | begründete Next | ja |
+| `work_cycle_scope` | Sprint-Scope | wenn Agile aktiv |
+| `gate_fulfillment` | Orientierungs-Gates | wenn Gates genutzt |
+
+`ui_features`: `continuousProductWorkMode`; bei Sprint `steeringSnapshotOnWorkSprint`.
 
 ---
 
-## 6. UI / IA
+## 6. EFS
 
-| Aspekt | Vorgabe |
-|--------|---------|
-| Prozessleiste | Eingang → Sprint planen → Ausführen → Kontrolle |
-| Plan-Default | `/plan/inbox` |
-| Work-Default | `/work/sprint` (Fallback continuous wenn kein Sprint) |
-| Product Language | Sprint (nicht „Zeitbox“), Arbeitspaket, Eingang = Product Backlog |
+| `field_key` | Typ (Ziel) | Pflicht | Zweck |
+|-------------|------------|---------|-------|
+| `product_vision` | text | empfohlen | Vision / Produktziel |
+| `product_notes` | text | nein | Betriebshinweise |
+| `primary_repo_or_system` | text | nein | System-/Repo-Hinweis (Template) |
+| `incident_severity_default` | text/enum | nein | Default für Bug-Triage (Template) |
 
 ---
 
-## 7. EFS
+## 7. Basiserfassung / Starter-Kit
 
-| `field_key` | Zweck |
-|-------------|-------|
-| `metrics` | optional (Seed product) |
-| `release_theme` | optional |
+| Element | Inhalt |
+|---------|--------|
+| Kit (AP2.2a) | Orientierungs-Gate; Projects Entwicklung/Betrieb; 1 BacklogItem „Idee / Issue“; Guidance; Hinweis optionale Sprints |
+| Guidance | „Eingang triagieren → committen; optional Sprint — ohne Sprint Continuous.“ |
+| Create | Titel, Archetyp; Vision empfohlen |
+| Ausprägung | optional `product.kairo_dev` / Templates |
 
 ---
 
-## 8. Starter-Kit
+## 8. UI-Hülle
 
-Orientierungs-Gate, nächster Release-Horizont, Projects Entwicklung/Betrieb, 1 BacklogItem „Idee / Issue“, B3-Hinweis.
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Profil** | Vision, Notizen, EFS |
+| **Plan → Eingang / Inbox** | Backlog triage, Commit → Action (`/plan/inbox`) |
+| **Plan → Gates** | optionale Orientierungs-Meilensteine |
+| **Plan → Struktur** | Projects Entwicklung/Betrieb |
+| **Plan → Sprint** | anlegen, planen, aktiv, abschließen/Carryover (wenn Agile) |
+| **Ausführen / Today** | Continuous Next ohne Sprint |
+| **Ausführen / Sprint** | Sprint-Backlog wenn aktiv |
+| **Ausführen / Mine** | zugewiesene Actions |
+| **Kontrolle** | Next + reason_code; Attention; Sprint-Banner wenn aktiv |
+| **Journey** | Commits, Sprint-Events, Incidents, Gate-Verify |
+| **Process** | Eingang → (optional Sprint) → Ausführen → Kontrolle |
+| **Outline** | profile, inbox, sprint, gates |
+| **Product Language** | Sprint, Arbeitspaket, Eingang = Product Backlog |
+| **Nicht** | Closure-Wizard als Kern; Checklisten-Queue als Product-Backlog; leere Sprint-Sackgasse |
 
 ---
 
-## 9. Happy Path
+## 9. Happy Path (Abnahme-Flow)
 
-1. Product anlegen  
-2. Ideen im Eingang; triagieren → Action (optional in Sprint)  
-3. Sprint planen / ausführen / abschließen  
-4. Kontrolle: Next Action begründet (Gate oder Sprint)  
-5. Ohne Sprint: continuous_product Fallback, keine leere Sprint-Wand
+1. Product anlegen → Kit (Gate, Projects, Beispiel-BacklogItem).  
+2. Item committen → Action.  
+3. Kontrolle: Next begründet **ohne** Sprint.  
+4. Kritischen Bug erfassen → Attention/Ranking Incident.  
+5. Optional: Sprint anlegen → planen → Work zeigt Sprint → complete/Carryover.  
+6. Ohne Sprint navigieren → Continuous, kein leerer Sprint-Zwang.  
+7. Kein Closure nötig für „Erfolg“.
+
+### Negative / Randfälle
+
+1. Aktiver Sprint leer → Attention `sprint_empty`, nicht Fake-außer-Sprint-Next (Default Spec-D).  
+2. Sprint-UI ohne aktiven Sprint → Fallback Continuous.  
+3. BacklogItem als Sprint-Backlog führen → Anti-Pattern.  
+4. Orientierungs-Gate fehlt → gültig.  
+5. Kind unter B2a → Child-NA bleibt Product-Methode; Parent = Impulse.
 
 ---
 
 ## 10. Abnahme-DoD
 
-MVP §8 B2b + B3 minimal: Eingang ≠ Sprint-Backlog; Leitfrage ≤2 Min; kein Closure-Zwang.
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Anlegen | Kit + `continuous_product` |
+| 2 | Commit | Eingang → Action |
+| 3 | Next ohne Sprint | begründet, Horizon ok |
+| 4 | Incident | kritische Issue beeinflusst Attention/Ranking |
+| 5 | Optional Agile | Sprint-Flow durchspielbar |
+| 6 | Anti Sprint-Leere | kein leerer Sprint-Screen ohne Sprint |
+| 7 | Leitfrage | ≤2 Min |
+| 8 | Closure | kein Zwang |
+| 9 | ≠ B1 | Product-Backlog am Product |
+| 10 | Elements | next_action_primary; work_cycle_scope wenn Sprint |
 
 ---
 
-## 11. Ist-Stand
+## 11. Ist-Stand (Spec vs. Code)
 
-| Bereich | Code | Lücke |
-|---------|------|-------|
-| Kit / UI-Prozess | ✓ | — |
-| Sprint-Planung / Lifecycle | ◐ AP2.2d–e | lokale uncommitted Änderungen prüfen |
-| continuous_product Strategie | ◐ | — |
-| Product Language überall | ◐ | Spec: Audit UI-Strings |
+| Bereich | Spec | Code/Truth | Lücke |
+|---------|------|------------|-------|
+| Registry / Kit | B2b | AP2.2a/d/e/f vorhanden | EFS-Seeds |
+| Methode | `continuous_product` | registriert | Strategie an Spec-D halten |
+| Agile | composes_with product | vorhanden | nicht Programm-Meta |
+| UI Continuous/Sprint | diese Spec | weitgehend | Feinschliff leerer Sprint |
+| Op-API / Vibe-Coder | Parität | später | AP1.7b |
+| EFS | product_vision etc. | lückenhaft | Seed-AP |
 
 ---
 
-## 12. Offene PO-Fragen
+## 12. Implementierung
 
-1. Muss jedes Product-Vorhaben Gates haben, oder reicht Eingang + Actions?  
-2. Ist aktiver Sprint für Stufe-A-Abnahme Pflicht oder optional?
+Fachmodell vollständig. Feinschliff und Seeds in APs — Spec nicht kürzen.
 
 ---
 
 ## 13. Nachfolger
 
-AP2.1 B2b (+ B3); SPEC_B3 parallel halten.
+- EFS-Seeds  
+- Strategy-Parität Spec-D D6/D7  
+- Vibe-Coder Op-API Parität  

docs/product/archetypes/SPEC_C1_dispute_case_v0.1.md

@@ -1,11 +1,15 @@
 # SPEC — C1 `initiative.dispute_case`
-## Implementierungs-Spezifikation v0.1
+## Archetyp-Vollspec (implementierbar) v0.1
 
-**Status:** Entwurf (Welle 4 — Katalogvertiefung, **kein MVP-Code**)  
-**Stand:** 2026-07-24  
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
 **MVP-Stufe:** C  
-**Katalog:** ADP §5 C1  
-**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+**Decision-Lock:** C1 Verfahren  
+**Default-Methode:** [`SPEC_D_dispute_procedure_v0.1.md`](../../architecture/methods/SPEC_D_dispute_procedure_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS hier; Ready/Ranking/Events/Attention in Spec-D.  
+**Nicht:** offene Workflow-Engine · keine Rechts-Fachlogik.
 
 ---
 
@@ -14,56 +18,254 @@
 | Feld | Wert |
 |------|------|
 | `archetype_key` | `initiative.dispute_case` |
-| Label (DE) | Verfahren / Konflikt |
+| Label (Arbeit) | Verfahren |
 | Default-`method_key` | `dispute_procedure` |
+| Primary (kompatibel) | nur `dispute_procedure` (**Ausführung**, Kernel §6) |
+| Komposition | — (kein Agile-Default) |
 | Project-Spiegel | `project.dispute_case` |
-| MVP-Stufe | C (Katalog) |
+| Dominanz (über Methode) | event |
+| Closure | active — Fallende erwartet |
 
 ### Abgrenzung
 
-Reaktiv (Fristen, Entscheidungen aus Status) — nicht planerisches Programm. Keine Rechts-Fachlogik aus Spezialsoftware.
+| Nicht | Stattdessen |
+|-------|-------------|
+| Care | Wohlergehen Fokus-Person |
+| A2 | Liefer-DoD ohne Fall-/Event-Kern; C1 = laufendes Event→Reaktions-Modell |
+| A3 | Cadence ohne Verfahrensfall |
+| Workflow-Engine im engeren Sinn | dieselben OM-Bausteine, **beliebig** viele Stränge/Deps/Parallelen; Editor + optische Planungshilfe — keine Engine-Runtime |
+| Templates | z. B. Mietstreit-Labels auf C1 |
 
 ---
 
 ## 2. Nutzerbild
 
-**Referenz:** Miterstreit — Phasen, Fristen, Decision-Pflicht bei Reopen, Evidence.
+**Ongoing Event→Reaktion**, überwiegend reaktiv — aber mit optionaler **Vorausplanung**: Handlungsstränge können vorbereitet (`prepared`) und später durch Event/Ergebnis/Decision **aktiviert** werden. Aktive Stränge haben parallele und/oder abhängige Schritte; Dritte (z. B. Anwalt) als Actors; Fristen am Schritt/Strang/Fenster. Waiting blockiert nicht den ganzen Fall.
 
-**Leitfrage:** *Welche Frist / Entscheidung ist als Nächstes dran?*
+**Referenz:** Mietstreit — „Wenn Vergleich scheitert“ als vorbereiteter Strang; bei negativem Ergebnis → Aktivierung; parallel laufen schon andere Schritte.
+
+**Leitfrage:** Was ist jetzt ready — welche Stränge warten — und welche vorbereiteten Stränge könnten als Nächstes greifen?
 
 ---
 
-## 3–5. Skizze (nicht implementierungsreif)
+## 3. om_capabilities
 
-| Schicht | Inhalt |
+```text
+actions, roadmap, blockers, evidence, decisions,
+reviews, steering_methods
+```
+
+Assignments über Actors (inkl. Dritte). Recurring nicht Kern. Projects optional (Stränge/Themen im Fall).
+
+---
+
+## 4. Plan- / Ist-Vertrag
+
+### 4.1 Phasen & Fall
+
+| Element | Rolle |
 |---------|--------|
-| Plan | `phase` Gates, Iterationen |
-| Ist | Decision, Evidence, Actions aus Statuswechsel |
-| Steuerung | Next = Frist / offene Decision / neuer Strang |
+| `procedure_phase` | Verfahrensphase (Horizon); ≥1, typisch mehrere |
+| Closure | Fallende |
+
+### 4.2 Event → Reaktionsstrang (Kern)
+
+| Element | Rolle |
+|---------|--------|
+| **Event** | Eingang — erstklassig |
+| **Reaktionsstrang** | zusammengehörige Schritte (± Decision); an Phase gebunden |
+| **Schritt (Action)** | Arbeitsschritt; Assignment (Selbst, Anwalt, …) |
+| **Decision** | Weiche; kann vorbereitete Stränge aktivieren |
+| **Evidence** | Dokumente/Eingänge |
+| **Waiting** | am Schritt/Strang — kein Fall-Freeze |
+
+Abbildung: Event-Log + Strang mit Status + Actions (`reaction_strand_id`, `requires`, Fristen).
+
+### 4.2a Strang-Zustände (verbindlich)
+
+| Status | Bedeutung | Next? |
+|--------|-----------|-------|
+| **`prepared`** | vorausgeplant; Schritte/Deps/Frist-Skizze existieren; **noch nicht** steuerungsaktiv | nein (außer Planungs-UI) |
+| **`active`** | laufender Strang — Ready/Waiting/Ranking greifen | ja |
+| **`completed` / `cancelled`** | abgeschlossen bzw. verworfen | nein |
+
+**Öffnen / Aktivieren:**
+
+1. **Reaktiv:** Event oder manuell → neuer Strang direkt `active` (Normalfall am Anfang).  
+2. **Vorbereitet:** Nutzer/Template legt Strang als `prepared` an (Editor).  
+3. **Aktivierung:** Event, Actor-Result, Decision-Outcome oder manuell setzt `prepared` → `active` (optional Schritte konkretisieren, Fristen setzen).  
+4. Ein Outcome kann **einen von mehreren** vorbereiteten Strängen wählen (Weiche) — ohne BPMN-Engine: Zuordnung Event/Decision-Ergebnis → `strand_id` / Aktivierungsregel am Strang.
+
+Dominanz bleibt reaktiv: Vorausplanung ist erlaubt und sinnvoll, **nicht** Pflicht für Fallstart.
+
+### 4.2b Strang-Editor & optische Planungshilfe (UI)
+
+Planungs- und Übersichtfläche für Stränge/Schritte — **Planungshilfe**, keine Workflow-Engine-Runtime:
+
+| Kann | Nicht |
+|------|--------|
+| Stränge `prepared`/`active` anlegen, beliebig viele | Token-Engine, BPMN-Ausführungssemantik |
+| Schritte, parallele Kanten, `requires`, Assignments, Fristen | künstliche Limits (Anzahl/Tiefe) |
+| Aktivierungsauslöser (Event-Typ, Decision-Ergebnis → Strang) | zweite Steuerungsengine |
+| **Optische Hilfe:** Graph- oder Kartenansicht (Stränge, Deps, parallel, Statusfarben); Timeline | Pflicht, den ganzen Fall vorab zu zeichnen |
+| Liste + Filter (prepared / active / waiting) | Rechtsnormen-Automaten |
+
+Editor unter Plan; Ausführen bleibt Next/Timeline. Optik unterstützt Verstehen und Vorplanen — Ready/Ranking bleiben Spec-D.
+
+### 4.3 Parallelität und Abhängigkeiten (ohne künstliche Limits)
+
+| Muster | Modell |
+|--------|--------|
+| **Parallel Schritte** | Actions ohne gegenseitige `requires` → gleichzeitig ready |
+| **Parallele Stränge** | beliebig viele `active` und `prepared` Stränge gleichzeitig |
+| **Abhängig** | `requires` (Action→Action); ggf. Strang-übergreifend |
+| **Gemischt** | parallel + abhängig beliebig kombinierbar |
+
+**Keine Produktlimits** (verbindlich):
+
+- keine Obergrenze paralleler Stränge oder paralleler ready Schritte  
+- keine künstliche Maximaltiefe / Maximalanzahl von `requires`-Kanten  
+- Zyklen in Deps sind ungültig (Validierung), aber **keine** „nur Baum / nur 2 Ebenen“-Beschränkung  
+
+Waiting an einem Schritt/Strang friert weder Fall noch andere Stränge. Komplexität darf hoch sein; Steuerbarkeit bleibt über Ranking, Horizon (Phase), Attention — nicht über Abschneiden des Graphen.
+
+### 4.3a Freiheitsgrade vs. Engine
+
+| Erlaubt (Freiheit) | Nicht nötig / nicht gebaut |
+|--------------------|----------------------------|
+| Beliebig viele Stränge, Schritte, Deps, parallele Ready-Mengen | BPMN-/Token-Workflow-Engine |
+| prepared→active, Weichen über Decision/Event→Strang | beliebiges Plugin-Node-Modell |
+| Optische Planungshilfe (Graph/Timeline der Stränge) | zweite Steuerungsruntime neben Kernel |
+| Reaktiv + optional vorplanen | Pflicht-Vollplanung |
+
+### 4.4 Fristen
+
+| Art | Bedeutung |
+|-----|-----------|
+| Schritt-Frist | `due` an Action |
+| Strang-Frist | Deadline für den gesamten Reaktionsstrang (Fenster) |
+| Phasen-/Fall-Frist | übergeordnete Frist (z. B. Klagefrist) |
+| Arbeit *innerhalb* Frist | mehrere Schritte müssen vor `due` des Fensters fertig sein — Ranking/Attention über Fenster |
+
+### 4.5 Dritte / Rollen
+
+Actors (nicht nur „User“): z. B. Anwalt, Sachverständiger, interne Rolle. Assignment am Schritt. Attention wenn zugewiesener Dritt-Schritt überfällig / ohne Rückmeldung.
+
+### 4.6 Anti-Patterns
+
+- Workflow-Engine-Runtime (Editor/Optik ≠ Engine)  
+- Künstliche Caps: „max. N parallele Stränge / max. Dep-Tiefe“  
+- Pflicht-Vollplanung vor dem ersten Event  
+- `prepared` als Ready-Next  
+- Event → Todo-Wand ohne Strang/Deps  
+- Waiting = Fall-Freeze  
+- Rechtsnormen hardcoden  
 
 ---
 
-## 6–10. UI / EFS / Kit / DoD
+## 5. Steuerung
 
-**Absichtlich dünn:** Nur Katalog + Profilfelder bis PO Stufe C freigibt. Kein Starter-Kit-AP, keine Validation in AP2.1.
+**Verbindlich:** Spec-D `dispute_procedure`. Kurz:
 
-EFS (Ziel, später): `case_reference`, `next_deadline`, `counsel_actor_ref`.
+| Aspekt | Verweis |
+|--------|---------|
+| Dominanz | event |
+| Horizon | aktive Phase + aktive Stränge + Fristen; vorbereitete Stränge im Plan-Nebenblick |
+| Leading | nur Schritte in **`active`**-Strängen |
+| Parallel Next | mehrere ready Schritte; Primary-Next = Top-Rank |
+| Events / Results | öffnen `active`-Strang **oder** aktivieren `prepared`-Strang (Spec-D D8) |
+| Planung | light — Editor für prepared/active; kein Planungszwang |
 
 ---
 
-## 11. Ist-Stand
+## 6. EFS
 
-Registry + Stub-Methode ✓. Alles andere ✗ / deferred.
+| `field_key` | Pflicht | Zweck |
+|-------------|---------|-------|
+| `case_reference` | ja | Aktenzeichen / interne Referenz |
+| `next_deadline` | nein | Hinweis (Wahrheit: Schritt-/Strang-/Phasen-Frist) |
+| `counsel_actor_ref` | nein | typischer Vertretungs-Actor (Template) |
+| `counterparty_label` | nein | Gegenseite |
+| `case_notes` | nein | Lagenotiz |
 
 ---
 
-## 12. Offene PO-Fragen
+## 7. Basiserfassung / Starter-Kit
 
-1. Wann Stufe C starten?  
-2. Welche Phasen-Typen sind generisch genug ohne Rechts-Domäne?
+| Element | Inhalt |
+|---------|--------|
+| Kit (Minimum) | 1 Phase; 1 aktiver Beispiel-Strang (2 Schritte); Guidance |
+| Kit (reich) | + 1× `prepared`-Strang mit Aktivierungshinweis; Anwalt-Actor; Strang-Frist |
+| Guidance | „Meist reaktiv; Stränge vorplanen und bei Ergebnis aktivieren möglich.“ |
+| Create | Titel, Archetyp, `case_reference` |
 
 ---
 
-## 13. Nachfolger
+## 8. UI-Hülle
 
-Kein Assignment bis Welle 4 PO-Go.
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Phasen** | Phasenfolge |
+| **Plan → Strang-Editor** | Stränge/Schritte/Deps/Auslöser — ohne Anzahl-Limits |
+| **Plan → Optik** | Graph/Karten + Status; Timeline — Planungshilfe |
+| **Plan → Strang-Liste** | prepared / active / waiting / done (beliebig viele) |
+| **Timeline** | Events, Aktivierungen, Fristen, Waiting (`dispute_timeline`) |
+| **Eingang / Events** | Event → neuen `active`-Strang **oder** passenden `prepared`-Strang aktivieren |
+| **Ausführen** | Next nur aus `active`; Waiting je Strang; prepared nur als Hinweis „aktivierbar“ |
+| **Kontrolle** | Fristen, Deps, Waiting, Dritt-Assignments, ungenutzte prepared bei relevantem Outcome |
+| **Journey** | Event/Result → Aktivierung → Schritte → Decision → Closure |
+| **Elements** | `next_action_primary`, `dispute_timeline` |
+| **Nicht** | Workflow-Engine-Runtime; Caps auf Parallel/Deps; Sprint/Cadence dominant; Vollplanungszwang |
+
+Process: Fall/Phasen → (optional vorplanen) → Event/Aktivierung → Ausführen → Kontrolle.
+
+---
+
+## 9. Happy Path (Abnahme-Flow)
+
+1. C1 anlegen; `case_reference`; Kit-Phase + aktiver Beispiel-Strang.  
+2. Event „Schreiben eingegangen“ → `active`-Strang mit ≥2 Schritten.  
+3. Ein Schritt Waiting (Gegenseite); paralleler Schritt bleibt ready in Next.  
+4. `prepared`-Strang im Editor („wenn Vergleich scheitert“); Decision-Outcome aktiviert ihn.  
+5. Dritt-Actor (Anwalt) an Schritt; Frist am Schritt oder Strang.  
+6. Fall-Closure durchspielen.
+
+### Negative / Randfälle
+
+1. `prepared` vor Aktivierung in Next → Spec-Verstoß.  
+2. Waiting friert ganzen Fall → Spec-Verstoß.  
+3. Künstliche Caps Parallel/Deps → Spec-Verstoß.  
+4. BPMN-Engine statt Editor → Spec-Verstoß.
+
+---
+
+## 10. Abnahme-DoD
+
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Event→Strang | `active` mit ≥2 Schritten |
+| 2 | Parallel + Waiting | Waiting an einem, Ready am anderen |
+| 3 | prepared→active | Aktivierung durch Event/Decision |
+| 4 | Deps / Dritte | Assignment + requires funktionieren |
+| 5 | Anti prepared-Ready | nicht vor Aktivierung in Next |
+| 6 | Closure | Fallende möglich |
+| 7 | Leitfrage | ≤2 Min |
+| 8 | Anti Engine | keine Workflow-Runtime; keine Caps |
+
+---
+
+## 11. Ist-Stand (Spec vs. Code)
+
+| Bereich | Spec | Code/Truth | Lücke |
+|---------|------|------------|-------|
+| Registry | C1 | Stub/teilweise | volle Strategy |
+| Event→Strang / prepared | Pflicht | fehlt | P0/P1 APs |
+| Strang-Editor / Optik | Pflicht | fehlt | UI-AP |
+| Parallel/Deps ohne Caps | Pflicht | Action-Deps teilweise | Strang-Modell |
+| EFS case_reference | Pflicht | Seeds prüfen | Seed-AP |
+
+---
+
+## 12. Implementierung
+
+Fachmodell vollständig. Kein neues OM jenseits Event-Bindung + Strang-ID + bestehender Action-Deps/Assignments — Schnitte nur in APs.

docs/product/archetypes/SPEC_Care_initiative_care_v0.1.md

@@ -0,0 +1,259 @@
+# SPEC — Care `initiative.care`
+## Archetyp-Vollspec (implementierbar) v0.1
+
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
+**MVP-Stufe:** neu (Decision-Lock; Code P0)  
+**Decision-Lock:** Fürsorge inkl. Self-Care  
+**Default-Methode:** [`SPEC_D_care_navigation_v0.1.md`](../../architecture/methods/SPEC_D_care_navigation_v0.1.md)  
+**Methodenkern:** `Kairo_Steering_Method_Kernel_v0.1.md`  
+**Spec-Regel:** vollständiges Fachmodell; Umsetzungsphasen nur in APs.  
+**Schicht:** OM/UI/EFS/Kit/Happy Path hier; Ready/Ranking/Attention/Events in Spec-D.  
+**Hinweis:** Arbeitslabel „Fürsorge“; Templates dürfen Anzeigenamen überschreiben (Archetyp ≠ Template).
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.care` |
+| Label (Arbeit) | Fürsorge |
+| Default-`method_key` | `care_navigation` |
+| Primary (kompatibel) | nur `care_navigation` (**Ausführung**, Kernel §6) |
+| Komposition | — (kein Agile-Default) |
+| Project-Spiegel | `project.care` |
+| Dominanz (über Methode) | hybrid (Plan-Checkpoints + Event-Reaktionen + Cadence-Rituale) |
+| Closure | soft / skip — oft dauerhaft; Closure nur wenn Fokus endet |
+| CareFocus | **genau eine** Person (andere **oder** „ich“ / Self-Care) |
+
+### Abgrenzung
+
+| Nicht | Stattdessen |
+|-------|-------------|
+| A3 Rhythmus | Cadence/Systemgesundheit ohne Fürsorge-Wohlergehen als Kern |
+| A1 Reifegrad | Können/Skill-Stufen, nicht Wohlergehen |
+| C1 Verfahren | Fall/Fristen/Reaktionsstränge ohne Fürsorgekern |
+| B1 Checklisten | Abhaken ohne Ritual/Reaktion/Prinzipien |
+| A2 Projekt | Liefer-DoD / Closure erwartet |
+| Multi-Fokus in einem Vorhaben | mehrere Care-Vorhaben (oder später B2a über mehreren Care-Kindern) |
+
+---
+
+## 2. Nutzerbild
+
+Kontinuierliche Fürsorge für **eine** Fokus-Person: Prinzipien/Haltung, wiederkehrende Rituale, situative Reaktionen, optional Checkpoints (Lebens-/Stabilitäts-Meilensteine). Self-Care = derselbe Archetyp mit Fokus „ich“.
+
+**Wer / Situation:** Elternteil, Partner:in, pflegende Angehörige, oder Person, die die eigene Stabilität steuert.
+
+**Referenzbeispiel (durchspielbar) — „Einschulungsjahre Kind“:**
+
+1. Fokus-Person: Kind (Name/Label).  
+2. Prinzipien: „Schlaf vor Leistung“, „Konflikt ansprechen am selben Tag“.  
+3. Ritual: wöchentlicher Check-in (Recurring, eine offene Instanz).  
+4. Event: „Streit in der Schule“ → Reaktion als Action, urgent in Next.  
+5. Optional Checkpoint: „Schuleingang“ mit vorbereitenden Actions.  
+6. Kontrolle: Next = entweder kritische Reaktion, oder überfälliges Ritual, oder Checkpoint-Schritt — begründet.  
+7. Verpasstes Ritual → Attention, **kein** zweites Todo-Duplikat.
+
+**Leitfrage:** Was braucht die Fürsorge **jetzt** — akute Reaktion, fälliges Ritual, oder Checkpoint-Schritt?
+
+---
+
+## 3. om_capabilities
+
+```text
+actions, backlog, roadmap, recurring, blockers,
+evidence, decisions, reviews, steering_methods
+```
+
+Projects optional (Themenstränge der Fürsorge, z. B. Schule / Gesundheit) — ändern nicht den einen Fokus.
+
+---
+
+## 4. Plan- / Ist-Vertrag
+
+### 4.1 Plan-Objekte
+
+| Objekt | Pflicht / optional | Regeln |
+|--------|-------------------|--------|
+| CareFocus (EFS) | **Pflicht** | genau eine Person oder „ich“; Freitext zuerst, Actor-Link optional |
+| Prinzipien (EFS / strukturierte Texte) | **≥1** | Haltung; Drift → Attention, nicht Auto-Arbeit |
+| RecurringElement (Ritual) | **≥1 Ritual oder** nutzbarer Reaktions-Eingang | Cadence; **eine** offene CadenceInstance |
+| Checkpoint (RoadmapItem, z. B. milestone / care_checkpoint) | optional | Lebens-/Stabilitätsziel; Verify optional |
+| Project `project.care` | optional | Themen unter dem einen Fokus |
+| BacklogItem | optional | kurzer Eingang vor Commit der Reaktion |
+
+**Plan-Anti-Pattern:** mehrere Fokus-Personen in einem Vorhaben; Checkpoints als Pflicht für gültiges Care.
+
+### 4.2 Ist-Objekte
+
+| Objekt | Rolle | Commit-Regel |
+|--------|-------|--------------|
+| CadenceInstance | Leading bei fälligem/überfälligem Ritual | eine Instanz pro Ritual; Verpassen → Eskalation/Attention, kein Duplikat |
+| Action (**CareReaction**) | Leading bei situativer Reaktion | Spec-/Read-Model-Begriff; **OM = normales Arbeitspaket** (ggf. über Eingang) |
+| Action / Schritt am Checkpoint | Leading als HorizonStep | ready am optionalen Checkpoint |
+| Decision | schwere Abwägung | auditiert |
+| Evidence | Beobachtung, Arztbrief, Notiz | an Reaktion/Checkpoint |
+| Blocker | sperrt konkrete Arbeit | Attention |
+| PrincipleReminder | eher Attention als Next | bei Drift ohne konkrete Aufgabe |
+
+**Ist-Anti-Pattern:** Ritual-Verpassen erzeugt Task-Wand; alle Rituale+Reaktionen als gleichwertige Todo-Liste; Self-Care als A1-Skill-Training.
+
+### 4.3 Reaktions-Eingang (Event → Reaktion)
+
+1. Situatives Ereignis erfassen (Freitext + optional Schwere/Frist).  
+2. Öffnet oder aktualisiert eine Reaction-Action (Commit).  
+3. Ranking: kritische/urgent Reaktionen vor Ritualen (Spec-D D6).  
+4. Mehrere offene Reaktionen parallel erlaubt; Primary-Next = Top-Rank.  
+5. Waiting auf externes (Arzttermin) am Schritt — andere Rituale/Reaktionen bleiben steuerbar.
+
+### 4.4 Rituale
+
+Beliebig viele Rituale; jedes mit eigener Cadence (zeitversetzt).  
+Keine Alternanz-Pflicht wie A1 — optional später über Recurring-Felder, nicht Care-Kern.  
+A3-Semantik „eine Instanz“ gilt analog.
+
+### 4.5 Checkpoints
+
+Optional. Care nur mit Fokus + Prinzipien + (Rituale und/oder Reaktions-Eingang) ist **vollständig gültig**.  
+Checkpoint-Verify wechselt Horizon-Nebenblick; Closure des Vorhabens nicht erzwungen.
+
+### 4.6 Self-Care
+
+Identisches Modell; `care_focus` = „ich“ / Self. Kein zweiter Archetyp.
+
+---
+
+## 5. Steuerung
+
+**Verbindlich:** Spec-D `care_navigation` (D3–D8, D11).
+
+| Aspekt | Kurz |
+|--------|------|
+| Dominanz | hybrid |
+| Horizon | CareFocus + optional Checkpoint + „Jetzt“-Schnitt |
+| Leading | polymorph: CadenceInstance \| Reaction-Action \| Checkpoint-Schritt |
+| Ranking | urgent Reaction → Ritual overdue → Ritual due → Checkpoint |
+| Leerer Fall | erlaubt („stabil“) — nicht automatisch Planning Debt |
+| Closure | soft |
+| Steering nur in | `backend/steering/` |
+
+### Steuerungselemente
+
+| `steering_element_key` | Rolle | Pflicht |
+|------------------------|-------|---------|
+| `next_action_primary` | polymorphe Next | ja |
+| `recurring_rhythm` | Ritual-Lage | ja wenn Rituale |
+| `care_focus` | Fokus-Person sichtbar | ja |
+| `care_reactions` | offene Reaktionen | ja |
+
+---
+
+## 6. EFS
+
+| `field_key` | Typ (Ziel) | Pflicht | Zweck |
+|-------------|------------|---------|-------|
+| `care_focus` | text (optional später actor_ref) | **ja** | Fokus-Person oder „ich“ |
+| `care_focus_is_self` | bool | empfohlen | Self-Care-Kennzeichnung |
+| `principles` | text / list | **ja** (≥1) | Haltung / Prinzipien |
+| `care_notes` | text | nein | Lagenotiz |
+| `primary_caregiver_actor_ref` | actor ref | nein | Haupt-Fürsorgende:r |
+| `checkpoint_summary` | text | nein | Hinweis; Wahrheit am RoadmapItem |
+
+---
+
+## 7. Basiserfassung / Starter-Kit
+
+| Element | Inhalt |
+|---------|--------|
+| Kit (Minimum) | `care_focus` Pflichtfeld; 1 Prinzip-Platzhalter; 1 Ritual „Regelmäßiger Check-in“; Guidance; Reaktions-Eingang nutzbar |
+| Kit (reich) | + 1 Checkpoint-Beispiel; zweites Ritual |
+| Guidance | „Eine Fokus-Person; Reaktion und Ritual steuern Next — kein Todo-Duplikat bei verpasstem Ritual.“ |
+| Create | Titel, Archetyp, **care_focus** Pflicht |
+| Template | Anzeigenamen (z. B. „Familienalltag“) — Natur bleibt Care |
+
+---
+
+## 8. UI-Hülle
+
+| Fläche | Inhalt |
+|--------|--------|
+| **Plan → Profil / Fokus** | CareFocus, Self-Flag, Prinzipien, Notizen, Caregiver |
+| **Plan → Rituale** | Recurrings: Cadence, Owner, aktiv; keine Instanz-Duplikate |
+| **Plan → Checkpoints** | optionale Meilensteine, Kriterien, Verify |
+| **Plan → Struktur** | optionale Projects/Themen |
+| **Eingang / Reaktion** | situatives Ereignis → Reaction-Action anlegen |
+| **Ausführen / Today** | polymorphe Next: Reaktion / Ritual / Checkpoint-Schritt |
+| **Kontrolle** | Next + Begründung; Attention (overdue, open reaction, principle drift, checkpoint risk) |
+| **Journey** | Events, erledigte Rituale, abgeschlossene Reaktionen, Checkpoint-Wechsel |
+| **Process** | Fokus/Prinzipien → Rituale/Reaktionen → Ausführen → Kontrolle |
+| **Elements** | `next_action_primary`, `recurring_rhythm`, `care_focus`, `care_reactions` |
+| **Nicht dominant** | Sprint, Gate-Designer als Hauptwerkzeug, Checklisten-Queue, Verfahrens-Strang-Editor |
+
+Defaults: Plan Profil oder Rituale; Work `/work/today`.
+
+---
+
+## 9. Happy Path (Abnahme-Flow)
+
+1. Care anlegen; Fokus-Person setzen; Prinzip speichern.  
+2. Kit-Ritual sichtbar; Today ohne Fake-Druck wenn nichts fällig.  
+3. Ereignis „akuter Bedarf“ → Reaction-Action → Next mit `care_reaction_urgent`.  
+4. Reaction erledigen → Next wechselt auf Ritual due/overdue oder leer/stabil.  
+5. Ritual erfüllen → eine nächste Instanz; kein Duplikat.  
+6. Optional: Checkpoint anlegen, Schritt ready, Verify.  
+7. Self-Care-Variante: Fokus = ich, gleicher Flow.
+
+### Negative / Randfälle
+
+1. Create ohne Fokus → ungültig.  
+2. Zweiten Fokus in demselben Vorhaben anlegen → nicht erlaubt (neues Vorhaben).  
+3. Ritual verpassen → Attention, keine zweite offene Instanz.  
+4. Nur Rituale, nie Checkpoint → gültig.  
+5. Nur Reaktions-Eingang, zunächst kein Ritual → gültig, wenn Eingang nutzbar; Kit empfiehlt Ritual.  
+6. Care als A1 umdeklarieren (Skill-Übungen ohne Wohlergehen) → Anti-Pattern.
+
+---
+
+## 10. Abnahme-DoD
+
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Anlegen | Fokus + Prinzip + Methode `care_navigation` |
+| 2 | Ritual | ≥1 Ritual oder klarer Reaktions-Eingang; eine Instanz-Semantik |
+| 3 | Reaktion | Event → Action in Next/Attention |
+| 4 | Ranking | urgent Reaction vor Ritual due |
+| 5 | Anti-Duplikat | verpasstes Ritual ohne zweiten Task |
+| 6 | Checkpoint | optional weglassbar |
+| 7 | Self-Care | Fokus ich durchspielbar |
+| 8 | Leitfrage | ≤2 Min |
+| 9 | Journey | Events/Rituale/Reaktionen nachvollziehbar |
+| 10 | Elements | care_focus / care_reactions sichtbar in Control |
+
+---
+
+## 11. Ist-Stand (Spec vs. Code)
+
+| Bereich | Spec | Code/Truth | Lücke |
+|---------|------|------------|-------|
+| Registry Archetyp | `initiative.care` / `project.care` | fehlt | P0 Seed |
+| Methode | `care_navigation` | fehlt | P0 Registry + Strategy |
+| EFS | care_focus, principles | fehlt | P0 |
+| Starter-Kit | diese Spec | fehlt | P1 |
+| steering_elements | care_* | fehlt | P1 |
+| Next polymorph | Spec-D | fehlt | P0 Strategy |
+
+---
+
+## 12. Implementierung
+
+Fachmodell vollständig. P0 = Seed + Methode + EFS + minimale Strategy — Spec nicht aufschieben. Kein neues OM „CareReaction“-Tabelle.
+
+---
+
+## 13. Nachfolger
+
+- M2 P0 Care Seed + `care_navigation`  
+- ui_profile + Kit AP  
+- optional Actor-Link für CareFocus  

docs/product/archetypes/SPEC_generic_fallback_v0.1.md

@@ -1,11 +1,12 @@
 # SPEC — Fallback `initiative.generic`
-## Implementierungs-Spezifikation v0.1
+## Archetyp-Vollspec (implementierbar) v0.1
 
-**Status:** Entwurf  
-**Stand:** 2026-07-24  
-**MVP-Stufe:** Fallback (kein Referenz-Archetyp)  
-**Katalog:** ADP §3.1 / §4.4  
-**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+**Status:** vorläufig freigegeben (PO 2026-07-26) — Zielbild; Implementierungsausreichendheit noch nicht abschließend bewertet
+**Stand:** 2026-07-26  
+**Rolle:** Fallback / Altbestand — **nicht** Referenz-Archetyp für neue Vorhaben  
+**Default-Methode:** [`SPEC_D_generic_operating_v0.1.md`](../../architecture/methods/SPEC_D_generic_operating_v0.1.md)  
+**Methodenkern:** Kernel §6 Primary (Ausführung, dünn)  
+**Spec-Regel:** bewusst minimal, aber Abschnitte vollständig für den Fallback-Zweck.
 
 ---
 
@@ -14,26 +15,112 @@
 | Feld | Wert |
 |------|------|
 | `archetype_key` | `initiative.generic` |
-| Methode | `generic_operating` |
-| Rolle | Notfall / Altbestand — **nicht** empfohlen für neue Vorhaben |
+| Label | Allgemein / Unspezifisch |
+| Default-`method_key` | `generic_operating` |
+| Primary | nur `generic_operating` (**Ausführung**, dünn) |
+| Komposition | — |
+| Project-Spiegel | `project.generic` vermeiden — von Initiative erben |
+| Closure | optional |
+
+### Abgrenzung
+
+Kein „neunter Natur-Typ“. Platzhalter bis konkreter Archetyp gewählt ist.
 
 ---
 
-## 2. Regeln
+## 2. Nutzerbild
 
-1. Neue Vorhaben: Nutzer wählt konkreten Archetyp (Stufe A/B).  
-2. `generic` → Attention / Hinweis: „Keine Steuerungsstruktur — Archetyp wählen.“  
-3. Kein Starter-Kit (oder bewusst leeres Kit).  
-4. Project-Default `project.generic` vermeiden — von Initiative erben.
+Altbestand oder Notfall ohne passende Typwahl.
+
+**Referenz:** Altes Vorhaben ohne Typ; Admin legt Notfall-generic an und wechselt sofort auf A2/B1/…
+
+**Leitfrage:** Welchen konkreten Archetyp braucht dieses Vorhaben?
 
 ---
 
-## 3. Abnahme
+## 3. om_capabilities
 
-Kein eigenes MVP-Szenario. Migration bestehender `generic`-Vorhaben = optionaler Cleanup, nicht Spec-Blocker.
+```text
+actions, steering_methods
+```
 
 ---
 
-## 4. Offene PO-Fragen
+## 4. Plan- / Ist-Vertrag
 
-1. Soft-Prompt beim Anlegen `generic` erlauben oder UI nur konkrete Archetypen zeigen?
+| Element | Rolle |
+|---------|--------|
+| Action | optionale offene Arbeit |
+| Struktur | bewusst dünn |
+| Attention | dauerhaft `generic_needs_archetype` |
+
+**Anti:** generic als Dauer-Default; Kits die einen Natur-Typ vortäuschen.
+
+---
+
+## 5. Steuerung
+
+**Verbindlich:** Spec-D `generic_operating`.
+
+| Aspekt | Kurz |
+|--------|------|
+| Next | offene Action grob priorisiert |
+| Attention | Struktur/Methode fehlt |
+| Elements | `next_action_primary` |
+
+---
+
+## 6. EFS / Kit
+
+Kein Pflicht-EFS. **Kein** Starter-Kit (oder leeres Kit).  
+Create-UI: primär die 8 Natur-Archetypen; `generic` nur Notfall/Admin/Altbestand.
+
+---
+
+## 7. UI-Hülle
+
+| Fläche | Inhalt |
+|--------|--------|
+| **Banner** | Archetyp wählen / wechseln |
+| **Work** | flache Next falls Actions existieren |
+| **Nicht** | reiche Plan-/Journey-Hülle wie Natur-Typen |
+
+---
+
+## 8. Happy Path (Fallback)
+
+1. Altbestand `generic` öffnen → Attention sichtbar.  
+2. Archetyp auf konkreten Typ wechseln → Attention entfällt / Methode wechselt.  
+3. Neues Vorhaben: Create-Default ist **nicht** generic.
+
+### Negative
+
+1. generic als Standard-Create → Spec-Verstoß.  
+2. Reichhaltiges Kit auf generic → Anti-Pattern.
+
+---
+
+## 9. Abnahme-DoD
+
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Create-Default | ohne generic (konkreter Typ) |
+| 2 | Attention | auf bestehendem generic sichtbar |
+| 3 | Wechsel | zu konkretem Archetyp möglich |
+| 4 | Kein Kit-Zwang | — |
+
+---
+
+## 10. Ist-Stand (Spec vs. Code)
+
+| Bereich | Spec | Code | Lücke |
+|---------|------|------|-------|
+| Archetyp generic | Fallback | oft Default-Altlast | Create-UI einschränken |
+| Attention | Pflicht | prüfen | Code |
+| Methode | `generic_operating` | dünn/Stub | an Spec-D |
+
+---
+
+## 11. Implementierung
+
+Fachmodell bewusst minimal und vollständig für den Fallback. Cleanup Altbestand optional.

docs/product/archetypes/VOLLSPEC_PROGRAM_v0.1.md

@@ -0,0 +1,34 @@
+# Archetyp-Vollspec — Arbeitsprogramm (nach Kernel + M2)
+
+**Status:** **vorläufig freigegeben** (PO 2026-07-26)  
+**Voraussetzung:** Kernel v0.1 ✓ · M2 ✓ · Decision-Lock ✓ · Methodentypen Kernel §6 ✓  
+
+**Architektur (PO 2026-07-26):** Archetyp ↔ Primary-Methode ↔ Komposition beibehalten (schlank).
+
+**Freigabe-Vorbehalt (PO 2026-07-26):** Die Specs sind **vorläufig** freigegeben als verbindliches fachliches Zielbild für die nächste Arbeit. Ob sie für die Implementierung **wirklich ausreichen**, ist noch **nicht** abschließend bewertet — Nachschärfung bei Implementierungsfragen ausdrücklich erlaubt und erwartet.
+
+**Spec-Regel:** Vollspecs beschreiben das vollständige Fachmodell. Schnitte nur in Implementierungs-APs. Lücken, die sich beim Bauen zeigen → Spec nachziehen, Spec nicht stillschweigend verwässern.
+
+## Stand Archetypen
+
+| Nr | Archetyp | Spec | Status |
+|----|----------|------|--------|
+| 1 | A2 Projekt | SPEC_A2_linear_project_v0.1.md | vorläufig freigegeben |
+| 2 | B2b Product | SPEC_B2b_product_v0.1.md | vorläufig freigegeben |
+| 3 | B2a Programm | SPEC_B2a_program_v0.1.md | vorläufig freigegeben (Code-P0) |
+| 4 | Care | SPEC_Care_initiative_care_v0.1.md | vorläufig freigegeben (Code-P0) |
+| 5 | B1 Checklisten | SPEC_B1_checklists_v0.1.md | vorläufig freigegeben |
+| 6 | A1 Reifegrad | SPEC_A1_maturity_journey_v0.1.md | vorläufig freigegeben |
+| 7 | A3 Rhythmus | SPEC_A3_recurring_program_v0.1.md | vorläufig freigegeben |
+| 8 | C1 Verfahren | SPEC_C1_dispute_case_v0.1.md | vorläufig freigegeben |
+| 9 | generic | SPEC_generic_fallback_v0.1.md | vorläufig freigegeben (Fallback) |
+
+B3/D1: keine Archetypen (→ Agile-Methode bzw. A2+Profil).
+
+## Nächste Arbeit
+
+1. Catalog v0.3 / Registry an Specs angleichen  
+2. M2 / Implementierungs-APs; Spec bei Bedarf nachschärfen  
+3. Spätere **endgültige** Freigabe nach erster Implementierungs-Härte  
+
+Template: `_TEMPLATE_Archetype_Spec_v0.1.md`