From 753f178b0ccac88d8fae631ed175e23a28b021dc Mon Sep 17 00:00:00 2001 From: Lars Date: Sun, 26 Jul 2026 15:01:40 +0200 Subject: [PATCH] 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 --- backend/method_profiles/registry.py | 10 + backend/services/archetype_starter_kit.py | 25 +- backend/services/operating_context.py | 29 ++ backend/steering/__init__.py | 3 + .../registrations/ap20_method_stubs.py | 26 +- .../registrations/product_milestone_driven.py | 2 - backend/steering/methods/registry.py | 35 +++ backend/steering/signals/engine.py | 9 +- .../strategies/next_action/agile_iteration.py | 71 +++-- .../strategies/next_action/execution_ready.py | 33 +- .../next_action/sequential_dependency.py | 25 +- backend/tests/test_ap22a_starter_kit.py | 26 ++ .../tests/test_ap22c_sequential_horizon.py | 188 ++++++++++++ .../tests/test_ap23e_method_compatibility.py | 31 +- backend/tests/test_ap24_steering_elements.py | 57 +++- .../ADP_Archetype_and_Method_Catalog_v0.2.md | 7 +- ..._Steering_Method_Contract_Fachlich_v0.1.md | 117 +++++++ .../Kairo_Steering_Method_Kernel_v0.1.md | 215 +++++++++++++ ...ering_Method_Normalization_Program_v0.1.md | 147 +++++++++ .../M1_Hybrid_Path_and_Depth_D_v0.1.md | 117 +++++++ ..._Lifecycle_Fit_Analysis_Archetypes_v0.1.md | 195 ++++++++++++ ...Method_Compatibility_and_Code_Debt_v0.1.md | 99 ++++++ docs/architecture/methods/README.md | 18 ++ .../methods/SPEC_D_agile_iteration_v0.1.md | 100 ++++++ .../methods/SPEC_D_care_navigation_v0.1.md | 170 +++++++++++ .../methods/SPEC_D_checklist_flow_v0.1.md | 157 ++++++++++ .../methods/SPEC_D_continuous_product_v0.1.md | 170 +++++++++++ .../methods/SPEC_D_dispute_procedure_v0.1.md | 194 ++++++++++++ .../methods/SPEC_D_generic_operating_v0.1.md | 105 +++++++ .../SPEC_D_maturity_progression_v0.1.md | 196 ++++++++++++ .../methods/SPEC_D_program_delivery_v0.1.md | 188 ++++++++++++ .../methods/SPEC_D_recurring_control_v0.1.md | 171 +++++++++++ .../SPEC_D_sequential_dependency_v0.1.md | 170 +++++++++++ .../_TEMPLATE_Method_Spec_Depth_D_v0.1.md | 104 +++++++ ...type_Decision_Lock_Interview_2026-07-25.md | 177 +++++++++++ ...ro_Archetype_Specification_Program_v0.1.md | 15 +- docs/product/Kairo_MVP_Execution_Plan_v0.2.md | 5 +- docs/product/archetypes/README.md | 35 ++- .../SPEC_A1_maturity_journey_v0.1.md | 273 +++++++++++------ .../archetypes/SPEC_A2_linear_project_v0.1.md | 287 ++++++++++++------ .../SPEC_A3_recurring_program_v0.1.md | 246 +++++++++++---- .../archetypes/SPEC_B1_checklists_v0.1.md | 245 +++++++++++++++ .../archetypes/SPEC_B2a_program_v0.1.md | 244 +++++++++++---- .../archetypes/SPEC_B2b_product_v0.1.md | 241 ++++++++++----- .../archetypes/SPEC_C1_dispute_case_v0.1.md | 252 +++++++++++++-- .../SPEC_Care_initiative_care_v0.1.md | 259 ++++++++++++++++ .../archetypes/SPEC_generic_fallback_v0.1.md | 121 ++++++-- .../archetypes/VOLLSPEC_PROGRAM_v0.1.md | 34 +++ 48 files changed, 5113 insertions(+), 531 deletions(-) create mode 100644 backend/tests/test_ap22c_sequential_horizon.py create mode 100644 docs/architecture/Kairo_Steering_Method_Contract_Fachlich_v0.1.md create mode 100644 docs/architecture/Kairo_Steering_Method_Kernel_v0.1.md create mode 100644 docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md create mode 100644 docs/architecture/M1_Hybrid_Path_and_Depth_D_v0.1.md create mode 100644 docs/architecture/M1_Lifecycle_Fit_Analysis_Archetypes_v0.1.md create mode 100644 docs/architecture/M2_Method_Compatibility_and_Code_Debt_v0.1.md create mode 100644 docs/architecture/methods/README.md create mode 100644 docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_care_navigation_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_checklist_flow_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_continuous_product_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_dispute_procedure_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_generic_operating_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_maturity_progression_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_program_delivery_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_recurring_control_v0.1.md create mode 100644 docs/architecture/methods/SPEC_D_sequential_dependency_v0.1.md create mode 100644 docs/architecture/methods/_TEMPLATE_Method_Spec_Depth_D_v0.1.md create mode 100644 docs/product/Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md create mode 100644 docs/product/archetypes/SPEC_B1_checklists_v0.1.md create mode 100644 docs/product/archetypes/SPEC_Care_initiative_care_v0.1.md create mode 100644 docs/product/archetypes/VOLLSPEC_PROGRAM_v0.1.md diff --git a/backend/method_profiles/registry.py b/backend/method_profiles/registry.py index 5e72222..0cc28e7 100644 --- a/backend/method_profiles/registry.py +++ b/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} diff --git a/backend/services/archetype_starter_kit.py b/backend/services/archetype_starter_kit.py index e2964f4..8b835a0 100644 --- a/backend/services/archetype_starter_kit.py +++ b/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"], } diff --git a/backend/services/operating_context.py b/backend/services/operating_context.py index 425365c..1743bcd 100644 --- a/backend/services/operating_context.py +++ b/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 diff --git a/backend/steering/__init__.py b/backend/steering/__init__.py index b638607..60f1052 100644 --- a/backend/steering/__init__.py +++ b/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() diff --git a/backend/steering/methods/registrations/ap20_method_stubs.py b/backend/steering/methods/registrations/ap20_method_stubs.py index 284d051..ff1c37e 100644 --- a/backend/steering/methods/registrations/ap20_method_stubs.py +++ b/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", diff --git a/backend/steering/methods/registrations/product_milestone_driven.py b/backend/steering/methods/registrations/product_milestone_driven.py index 195d9a2..56431f7 100644 --- a/backend/steering/methods/registrations/product_milestone_driven.py +++ b/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"}), diff --git a/backend/steering/methods/registry.py b/backend/steering/methods/registry.py index 5afc22a..fededa8 100644 --- a/backend/steering/methods/registry.py +++ b/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) diff --git a/backend/steering/signals/engine.py b/backend/steering/signals/engine.py index 76e49db..a19308f 100644 --- a/backend/steering/signals/engine.py +++ b/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 diff --git a/backend/steering/strategies/next_action/agile_iteration.py b/backend/steering/strategies/next_action/agile_iteration.py index fecdeac..c0a3ad4 100644 --- a/backend/steering/strategies/next_action/agile_iteration.py +++ b/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,58 +44,54 @@ 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 - ] - 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) + 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 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) + return ready[:limit] agile_iteration_strategy = AgileIterationStrategy() diff --git a/backend/steering/strategies/next_action/execution_ready.py b/backend/steering/strategies/next_action/execution_ready.py index 5e7e44b..8baa125 100644 --- a/backend/steering/strategies/next_action/execution_ready.py +++ b/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] diff --git a/backend/steering/strategies/next_action/sequential_dependency.py b/backend/steering/strategies/next_action/sequential_dependency.py index 57995b2..d1dc485 100644 --- a/backend/steering/strategies/next_action/sequential_dependency.py +++ b/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,29 +33,15 @@ 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) + return ready[:limit] sequential_dependency_strategy = SequentialDependencyStrategy() diff --git a/backend/tests/test_ap22a_starter_kit.py b/backend/tests/test_ap22a_starter_kit.py index 8720eef..427362b 100644 --- a/backend/tests/test_ap22a_starter_kit.py +++ b/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) diff --git a/backend/tests/test_ap22c_sequential_horizon.py b/backend/tests/test_ap22c_sequential_horizon.py new file mode 100644 index 0000000..99dad73 --- /dev/null +++ b/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" diff --git a/backend/tests/test_ap23e_method_compatibility.py b/backend/tests/test_ap23e_method_compatibility.py index ca3f33e..367577d 100644 --- a/backend/tests/test_ap23e_method_compatibility.py +++ b/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"] diff --git a/backend/tests/test_ap24_steering_elements.py b/backend/tests/test_ap24_steering_elements.py index e0f4e2d..6f1af2a 100644 --- a/backend/tests/test_ap24_steering_elements.py +++ b/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) diff --git a/docs/architecture/ADP_Archetype_and_Method_Catalog_v0.2.md b/docs/architecture/ADP_Archetype_and_Method_Catalog_v0.2.md index 217a107..75c31b1 100644 --- a/docs/architecture/ADP_Archetype_and_Method_Catalog_v0.2.md +++ b/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 diff --git a/docs/architecture/Kairo_Steering_Method_Contract_Fachlich_v0.1.md b/docs/architecture/Kairo_Steering_Method_Contract_Fachlich_v0.1.md new file mode 100644 index 0000000..6c928d1 --- /dev/null +++ b/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.* diff --git a/docs/architecture/Kairo_Steering_Method_Kernel_v0.1.md b/docs/architecture/Kairo_Steering_Method_Kernel_v0.1.md new file mode 100644 index 0000000..a6ce66b --- /dev/null +++ b/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_.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.* diff --git a/docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md b/docs/architecture/Kairo_Steering_Method_Normalization_Program_v0.1.md new file mode 100644 index 0000000..ad02e47 --- /dev/null +++ b/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.* diff --git a/docs/architecture/M1_Hybrid_Path_and_Depth_D_v0.1.md b/docs/architecture/M1_Hybrid_Path_and_Depth_D_v0.1.md new file mode 100644 index 0000000..6e9943d --- /dev/null +++ b/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__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) | diff --git a/docs/architecture/M1_Lifecycle_Fit_Analysis_Archetypes_v0.1.md b/docs/architecture/M1_Lifecycle_Fit_Analysis_Archetypes_v0.1.md new file mode 100644 index 0000000..3dfbebc --- /dev/null +++ b/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.* diff --git a/docs/architecture/M2_Method_Compatibility_and_Code_Debt_v0.1.md b/docs/architecture/M2_Method_Compatibility_and_Code_Debt_v0.1.md new file mode 100644 index 0000000..037c9c2 --- /dev/null +++ b/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 diff --git a/docs/architecture/methods/README.md b/docs/architecture/methods/README.md new file mode 100644 index 0000000..106ec25 --- /dev/null +++ b/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| diff --git a/docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md b/docs/architecture/methods/SPEC_D_agile_iteration_v0.1.md new file mode 100644 index 0000000..833f803 --- /dev/null +++ b/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) | diff --git a/docs/architecture/methods/SPEC_D_care_navigation_v0.1.md b/docs/architecture/methods/SPEC_D_care_navigation_v0.1.md new file mode 100644 index 0000000..4aa8298 --- /dev/null +++ b/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`**. diff --git a/docs/architecture/methods/SPEC_D_checklist_flow_v0.1.md b/docs/architecture/methods/SPEC_D_checklist_flow_v0.1.md new file mode 100644 index 0000000..9b86fd3 --- /dev/null +++ b/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`. diff --git a/docs/architecture/methods/SPEC_D_continuous_product_v0.1.md b/docs/architecture/methods/SPEC_D_continuous_product_v0.1.md new file mode 100644 index 0000000..f0fd291 --- /dev/null +++ b/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 | diff --git a/docs/architecture/methods/SPEC_D_dispute_procedure_v0.1.md b/docs/architecture/methods/SPEC_D_dispute_procedure_v0.1.md new file mode 100644 index 0000000..7b1e143 --- /dev/null +++ b/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 | diff --git a/docs/architecture/methods/SPEC_D_generic_operating_v0.1.md b/docs/architecture/methods/SPEC_D_generic_operating_v0.1.md new file mode 100644 index 0000000..6db9455 --- /dev/null +++ b/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. diff --git a/docs/architecture/methods/SPEC_D_maturity_progression_v0.1.md b/docs/architecture/methods/SPEC_D_maturity_progression_v0.1.md new file mode 100644 index 0000000..df7bfa8 --- /dev/null +++ b/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. diff --git a/docs/architecture/methods/SPEC_D_program_delivery_v0.1.md b/docs/architecture/methods/SPEC_D_program_delivery_v0.1.md new file mode 100644 index 0000000..243ba63 --- /dev/null +++ b/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`**. diff --git a/docs/architecture/methods/SPEC_D_recurring_control_v0.1.md b/docs/architecture/methods/SPEC_D_recurring_control_v0.1.md new file mode 100644 index 0000000..58bca65 --- /dev/null +++ b/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 | diff --git a/docs/architecture/methods/SPEC_D_sequential_dependency_v0.1.md b/docs/architecture/methods/SPEC_D_sequential_dependency_v0.1.md new file mode 100644 index 0000000..3b313f7 --- /dev/null +++ b/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`**. diff --git a/docs/architecture/methods/_TEMPLATE_Method_Spec_Depth_D_v0.1.md b/docs/architecture/methods/_TEMPLATE_Method_Spec_Depth_D_v0.1.md new file mode 100644 index 0000000..d88b5e3 --- /dev/null +++ b/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. … diff --git a/docs/product/Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md b/docs/product/Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md new file mode 100644 index 0000000..00274a9 --- /dev/null +++ b/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.* diff --git a/docs/product/Kairo_Archetype_Specification_Program_v0.1.md b/docs/product/Kairo_Archetype_Specification_Program_v0.1.md index b997c61..7dcf4af 100644 --- a/docs/product/Kairo_Archetype_Specification_Program_v0.1.md +++ b/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. --- diff --git a/docs/product/Kairo_MVP_Execution_Plan_v0.2.md b/docs/product/Kairo_MVP_Execution_Plan_v0.2.md index a4659d6..f020d56 100644 --- a/docs/product/Kairo_MVP_Execution_Plan_v0.2.md +++ b/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 --- diff --git a/docs/product/archetypes/README.md b/docs/product/archetypes/README.md index 10de867..c8b3dc5 100644 --- a/docs/product/archetypes/README.md +++ b/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 | diff --git a/docs/product/archetypes/SPEC_A1_maturity_journey_v0.1.md b/docs/product/archetypes/SPEC_A1_maturity_journey_v0.1.md index 21cbc2d..51cd13e 100644 --- a/docs/product/archetypes/SPEC_A1_maturity_journey_v0.1.md +++ b/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 diff --git a/docs/product/archetypes/SPEC_A2_linear_project_v0.1.md b/docs/product/archetypes/SPEC_A2_linear_project_v0.1.md index 97ca88d..6e630d1 100644 --- a/docs/product/archetypes/SPEC_A2_linear_project_v0.1.md +++ b/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 diff --git a/docs/product/archetypes/SPEC_A3_recurring_program_v0.1.md b/docs/product/archetypes/SPEC_A3_recurring_program_v0.1.md index 1eaa231..ea089fc 100644 --- a/docs/product/archetypes/SPEC_A3_recurring_program_v0.1.md +++ b/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 diff --git a/docs/product/archetypes/SPEC_B1_checklists_v0.1.md b/docs/product/archetypes/SPEC_B1_checklists_v0.1.md new file mode 100644 index 0000000..40efba2 --- /dev/null +++ b/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 diff --git a/docs/product/archetypes/SPEC_B2a_program_v0.1.md b/docs/product/archetypes/SPEC_B2a_program_v0.1.md index 9bb552b..30c3e52 100644 --- a/docs/product/archetypes/SPEC_B2a_program_v0.1.md +++ b/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 diff --git a/docs/product/archetypes/SPEC_B2b_product_v0.1.md b/docs/product/archetypes/SPEC_B2b_product_v0.1.md index 54377ea..0fa6cd8 100644 --- a/docs/product/archetypes/SPEC_B2b_product_v0.1.md +++ b/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 diff --git a/docs/product/archetypes/SPEC_C1_dispute_case_v0.1.md b/docs/product/archetypes/SPEC_C1_dispute_case_v0.1.md index fe4736b..ac7046a 100644 --- a/docs/product/archetypes/SPEC_C1_dispute_case_v0.1.md +++ b/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. diff --git a/docs/product/archetypes/SPEC_Care_initiative_care_v0.1.md b/docs/product/archetypes/SPEC_Care_initiative_care_v0.1.md new file mode 100644 index 0000000..950215d --- /dev/null +++ b/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 diff --git a/docs/product/archetypes/SPEC_generic_fallback_v0.1.md b/docs/product/archetypes/SPEC_generic_fallback_v0.1.md index 4961097..4adfbac 100644 --- a/docs/product/archetypes/SPEC_generic_fallback_v0.1.md +++ b/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. diff --git a/docs/product/archetypes/VOLLSPEC_PROGRAM_v0.1.md b/docs/product/archetypes/VOLLSPEC_PROGRAM_v0.1.md new file mode 100644 index 0000000..bf3c248 --- /dev/null +++ b/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`