docs: AP2.3/AP2.4 Plugin-Architektur verbindlich dokumentieren.

Guardrails, Truth Table und ADPs auf gelieferten Stand bringen; Spezifikationsprogramm und Archetyp-Template um steering_elements ergänzen.

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

.cursor/rules/kairo-architecture.mdc

@@ -51,6 +51,7 @@ Referenzmaterial unter `docs/reference/design-principles/`. Nicht automatisch Sc
 - Keine Mitai-/Shinkan-Domänenlogik kopieren
 - Keine parallele Steuerungslogik außerhalb `backend/steering/`
 - Keine neuen OM-Tabellen ohne ADP (Scope Lock bis RoadmapItem-ADP)
+- **Archetyp-/Methoden-Plugin (AP2.3/AP2.4):** siehe `.cursor/rules/kairo-plugin-architecture.mdc` — keine Archetyp-Ifs in Pages, keine neuen Features in `methodUiDefaults.js`
 
 ## Abweichungen
 

.cursor/rules/kairo-plugin-architecture.mdc

@@ -0,0 +1,60 @@
+---
+description: Archetyp-/Methoden-Plugin-Architektur (AP2.3/AP2.4) — verbindlich für neue Implementierungen
+globs: backend/steering/**,backend/entity_archetypes/**,backend/services/operating_context.py,frontend/src/registry/**,frontend/src/pages/**,frontend/src/context/InitiativeOperationsContext.jsx
+alwaysApply: true
+---
+
+# Kairo Plugin-Architektur (AP2.3 / AP2.4)
+
+Verbindliche ADPs: `docs/architecture/ADP_Archetype_Method_Plugin_Architecture_v0.1.md`, `docs/architecture/ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`
+
+## Vier Schichten — Auflösung zur Laufzeit
+
+| Schicht | Registry | Liefert |
+|---------|----------|---------|
+| **Archetyp** | `entity_archetypes` + `ui_profile_json` | Nav, Routen, Plan-Outline, `om_capabilities` |
+| **Methode** | `steering/methods/registrations/` | `data_slices`, `steering_elements`, `ui_features`, `graph_profile`, Strategie |
+| **Element** | `steering/elements/registry.py` + FE `steeringElementRegistry.js` | Control-/Work-Bausteine |
+| **Runtime** | `GET /api/initiatives/:id/operating-context` | Schnittmenge + Methoden-Vertrag |
+
+```text
+data_slices       = archetype.om_capabilities ∩ method.data_slices
+steering_elements = method.steering_elements   (nur Methode)
+ui_features       = method.ui_features           (nur Methode)
+nav / routes      = archetype.ui_profile         (nur Archetyp)
+```
+
+Archetyp-Default-Methode ist **Empfehlung**, nicht Lock — kompatible Methoden über `compatible_archetype_keys` + `om_capabilities`.
+
+## Erweitern (Open/Closed)
+
+**Neue Methode:** neues Modul unter `steering/methods/registrations/` → `MethodDefinition` vollständig → Import in `steering/__init__.py` → pytest. **Kein** Core-Edit.
+
+**Neuer Archetyp:** Seed in `entity_archetypes/registry.py` + `ui_profiles.py` + optional EFS — **kein** React-If in Pages.
+
+**Neues Steuerungselement:** Eintrag in `steering/elements/registry.py` + FE `steeringElementRegistry.js`; Methoden referenzieren nur registrierte Keys.
+
+## Frontend — verbindlich
+
+- UI aus `operating-context` via `resolveOperatingProfile.js`
+- Control/Work: `hasSteeringElement(steeringElements, '…')` — **keine** `archetype_key === 'initiative.…'`-Ifs
+- Daten: `loadOperatingSlices` / `refreshOm([…])` — **kein** Full-Reload nach Mutationen
+- Route Gating: `OperatingRouteGate` + `MODE_ROUTE_GROUPS`
+- Provider: `ScopedOperationsBridge` (ein Provider pro Vorhaben)
+
+## Verboten
+
+- `uiFeatures` am Archetyp-Profil (deprecated — nur Methode)
+- Hardcodierte Methoden-UI in `methodUiDefaults.js` für **neue** Archetypen
+- Parallele Steuerungslogik außerhalb `backend/steering/`
+- Methoden-Dropdown ohne Archetyp-Filter (`GET /steering/methods?archetype_key=…`)
+
+## Fallback (legacy)
+
+`methodUiDefaults.js` nur wenn Operating Context fehlt — nicht für neue Features erweitern.
+
+## Abnahme neuer Archetyp-/Methoden-Slices
+
+- Operating Context liefert `steering_elements` + `ui_features`
+- pytest für Methoden-Vertrag (`test_ap24_*`) grün
+- Spec unter `docs/product/archetypes/` referenziert Elemente und kompatible Methoden

CLAUDE.md

@@ -18,7 +18,9 @@ Foundation AP0.1–AP0.7 abgeschlossen. Operating Model AP0.8–AP0.10, Steering
 
 - Tenant, User, Actor, TenantContext, Auth, Capabilities
 - OM-Entitäten (Backlog, Blocker, Milestone-Brücke, Evidence, Decision, Review, Recurring)
-- `backend/steering/` (Lifecycle, Snapshot, Method Registry minimal)
+- `backend/steering/` (Lifecycle, Snapshot, Method Registry, **Plugin-Architektur AP2.3/AP2.4**)
+- **Operating Context API** + slice-bewusstes Frontend-Laden (AP2.3)
+- **Steuerungselement-Registry** + Methoden-Vertrag (AP2.4)
 - Workspace-GUI, Data Layer, Actor Directory
 
 **Produktlich fehlt (Vision):**
@@ -30,7 +32,7 @@ Foundation AP0.1–AP0.7 abgeschlossen. Operating Model AP0.8–AP0.10, Steering
 
 **Ist-Stand:** `docs/product/Kairo_Implementation_Truth_Table_v0.1.md`
 
-Nächster Fokus: **Dokumentations-Konsolidierung (Welle 2)**, dann **IA-Skeleton (AP1.2c)** und **RoadmapItem/Gates (AP1.4 + ADP)** — nicht weiteres Layout-Patching auf InitiativeDetail.
+Nächster Fokus: **Specs Welle 1 finalisieren**, dann **Stufe-A End-to-End** (AP2.2b/c/e, AP1.9d) und **AP2.1 Validation** — auf Plugin-Architektur AP2.3/4 aufsetzen, kein Layout-Patching auf InitiativeDetail.
 
 ---
 
@@ -48,6 +50,9 @@ Lies bei Projektstart in dieser Reihenfolge:
 8. `docs/architecture/Kairo_Tenant_Invariants_v0.1.md`
 9. `docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md`
 10. `.cursor/rules/kairo-architecture.mdc`
+11. `docs/architecture/ADP_Archetype_Method_Plugin_Architecture_v0.1.md` (AP2.3 — **geliefert**)
+12. `docs/architecture/ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md` (AP2.4 — **geliefert**)
+13. `.cursor/rules/kairo-plugin-architecture.mdc`
 
 Historisch / Referenz (nicht führend bei Konflikt):
 
@@ -138,6 +143,14 @@ Mitai/Shinkan-Prinzipien dürfen Kairo nicht überstimmen.
 11. Admin- und Agentenaktionen werden auditiert.
 12. Migrationen sind nummeriert und reproduzierbar.
 
+### Plugin-Architektur (AP2.3 / AP2.4 — verbindlich)
+
+13. **Archetyp ≠ Methode:** Archetyp = IA-Hülle + `om_capabilities`; Methode = Steuerungsmotor (`steering_elements`, `ui_features`, Strategie).
+14. Runtime-Auflösung über `GET …/operating-context` — kein hardcodiertes Methoden-/Archetyp-UI in React-Pages.
+15. Neue Archetypen/Methoden nur über **Registrierungsmodule** (`entity_archetypes/`, `steering/methods/registrations/`) — Open/Closed.
+16. Control-/Work-UI aus `steering_elements` + `steeringElementRegistry.js`, nicht aus Archetyp-Ifs.
+17. Siehe `.cursor/rules/kairo-plugin-architecture.mdc` und ADP AP2.3 / AP2.4.
+
 ---
 
 ## 6. Nicht tun
@@ -155,6 +168,9 @@ Mitai/Shinkan-Prinzipien dürfen Kairo nicht überstimmen.
 - kein Billing oder SSO bauen
 - keine strategischen Produktentscheidungen eigenmächtig ändern
 - keine Designprinzipien aus `docs/reference/` ohne Principle-Gate oder Architecture Decision in Scope ziehen
+- **keine Archetyp-Ifs** in Pages für Steuerungs-UI (`initiative.product === …`) — AP2.4 `steering_elements`
+- **`methodUiDefaults.js` nicht für neue Archetypen erweitern** — Operating Context + Resolver
+- **kein Full-`load()`** nach OM-Mutationen — `refreshOm([sliceKeys])`
 
 ---
 
@@ -168,4 +184,4 @@ Bei notwendiger Abweichung erstelle ein Architecture Decision Proposal.
 
 Siehe `docs/product/Kairo_Corrected_MVP_Roadmap_v0.2.md` und `Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md`.
 
-Foundation AP0.1–AP1.1b technisch weit. **Produkt:** IA + RoadmapItem/Gates vor weiterem UI-Polish. Scope Lock: `ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`.
+Foundation AP0.1–AP2.4 Plugin-Architektur geliefert. **Produkt:** Specs Welle 1 → AP2.2b/c/e + AP1.9d → AP2.1 Validation. Scope Lock: `ADP_AP1_0_Steering_Foundation_Scope_Lock_v0.1.md`; Plugin: ADP AP2.3/AP2.4.

docs/architecture/ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md

@@ -1,6 +1,6 @@
 # ADP — Steuerungselemente & Methoden-Vertrag v0.1 (AP2.4)
 
-**Status:** vorgeschlagen — Implementierung AP2.3g/AP2.4  
+**Status:** PO-freigegeben — **geliefert** (2026-07-25)  
 **Stand:** 2026-07-25  
 **Bezug:** `ADP_Archetype_Method_Plugin_Architecture_v0.1.md` (AP2.3), `ADP_Archetype_and_Method_Catalog_v0.2.md`, `Kairo_Method_Design_Principles_v0.1.md`  
 **Ersetzt nicht:** AP2.3 A–F; **vertieft** Schicht 1 (Methode) und schließt Restschuld AP2.3g

docs/architecture/ADP_Archetype_Method_Plugin_Architecture_v0.1.md

@@ -1,7 +1,7 @@
 # ADP — Archetyp- & Methoden-Plugin-Architektur v0.1
 
-**Status:** vorgeschlagen (PO-Freigabe vor weiteren Archetypen)  
+**Status:** PO-freigegeben — **geliefert** (AP2.3 A–F, 2026-07-25)  
-**Stand:** 2026-07-24  
+**Stand:** 2026-07-25  
 **Autor:** Architektur / PO-Session (Sprint-Planung & Typen-Trennung)  
 **Bezug:** `ADP_Archetype_and_Method_Catalog_v0.2.md`, `ADP_AP1_10_Initiative_Archetypes_and_Entity_Field_System_v0.1.md`, `Kairo_Target_Architecture_Method_Driven_Adaptive_Steering_Core_v0.1.md`, `Kairo_Method_Design_Principles_v0.1.md`, `Kairo_MVP_Execution_Plan_v0.2.md`  
 **Auslöser:** Sprint-UI und Vorhabentypen wirken monolithisch; weitere Archetypen und Steuerungstypen sollen **ohne Änderung bestehender Module** erweiterbar sein — nicht nutzerkonfigurierbar, aber **code-modular registrierbar**
@@ -16,18 +16,18 @@
 - Archetypen jenseits von Product/Linear/Maturity/Program sehen dieselbe IA wie Product, obwohl Backend-Methoden anders steuern.
 - Mode-Wechsel (Plan → Sprint → Work) löst wiederholt **vollständige Datenladung** aus.
 
-### 1.2 Architektur-Ist (technisch)
+### 1.2 Architektur-Ist (technisch) — Stand 2026-07-25
 
-| Bereich | Soll (ADP v0.2) | Ist (Code Jul 2026) |
+| Bereich | Soll (ADP v0.2) | Ist (Code) |
-|---------|-----------------|---------------------|
+|---------|-----------------|------------|
-| **Schicht 1 — Methode** | Registrierte Module in `backend/steering/methods/` | Registry + einige Registrierungen; viele Stubs teilen Strategien |
+| **Schicht 1 — Methode** | Registrierte Module in `backend/steering/methods/` | ✓ Registry + AP2.4 Vertrag (`steering_elements`, `ui_features`, `graph_profile`) |
-| **Schicht 2 — Archetyp** | `entity_archetypes` + `ui_profile_json` | Registry-Seeds; **`ui_profile_json` nicht an Frontend angebunden** |
+| **Schicht 2 — Archetyp** | `entity_archetypes` + `ui_profile_json` | ✓ Seeds + Operating Context an Frontend |
-| **Schicht 3 — Ausprägung** | `method_profiles` | 3 Code-Seeds; Komposition (Product + Sprint) nicht in UI modelliert |
+| **Schicht 3 — Ausprägung** | `method_profiles` | ◐ 3 Code-Seeds; Komposition (Product + Sprint) teilweise |
-| **Frontend IA** | Methode/Archetyp steuert Nav & Slices | **`methodUiDefaults.js` hardcodiert 4/9 Archetypen** |
+| **Frontend IA** | Methode/Archetyp steuert Nav & Slices | ✓ Resolver + Route Gating; `methodUiDefaults` nur Fallback |
-| **Datenladung** | Typ- und mode-bewusst | **`InitiativeOperationsContext.load()` ~14 parallele Requests für alle Typen** |
+| **Datenladung** | Typ- und mode-bewusst | ✓ `loadOperatingSlices`, `refreshOm`; Provider gehoisted |
-| **Provider-Lifecycle** | Ein Scope-Cache pro Vorhaben | **`ScopedInitiativeProvider` pro Mode-Page → Remount + Full Reload** |
+| **Provider-Lifecycle** | Ein Scope-Cache pro Vorhaben | ✓ `ScopedOperationsBridge`; Legacy-Wrapper optional |
 
-**Fazit:** Backend ist **strukturell** auf Plugin-Registrierung vorbereitet; Frontend und Client-Datenschicht behandeln alle Vorhaben wie **ein gemeinsames OM-Monolith**. Weitere Archetypen würden die Kopplung verstärken, nicht entkoppeln.
+**Fazit (historisch Jul 2026):** Monolith-Auflösung abgeschlossen. Weitere Archetypen über Registrierung + Specs — nicht über Page-Ifs.
 
 ### 1.3 Risiko bei Fortsetzung ohne Glättung
 
@@ -295,7 +295,7 @@ Neue Archetyp-Page = **neuer Registry-Eintrag** + Backend-Seed — keine `App.js
 | **E** | AP2.3e Method `data_slices` | Backend-Registrations refactoren; Stubs deklarieren Slices | A |
 | **F** | Archetyp-Specs Welle 2 | `support_queue`, `content_project`, … **nach** A–E | PO Specs |
 
-**Stop-the-line:** Keine neuen **UI-spezifischen** Archetyp-Features in React-Ifs bis Phase B abgeschlossen. Bugfixes und horizontale OM-Features (Sprint, Backlog) sind erlaubt.
+**Stop-the-line (aufgehoben 2026-07-25):** AP2.3 A–F und AP2.4 geliefert. Neue Archetyp-UI nur über Plugin-Regeln (`.cursor/rules/kairo-plugin-architecture.mdc`).
 
 ---
 
@@ -348,7 +348,7 @@ Dieses ADP **ersetzt nicht** den MVP Execution Plan, sondern **priorisiert** die
 Foundation / Sprint-Planung (AP2.2*)  →  AP2.3 Plugin-Glättung  →  Archetyp Specs + Seeds  →  IA pro Typ
 ```
 
-PO-Entscheidung erforderlich: **AP2.3 (A–E) vor** breiter Implementierung von `support_queue`, `content_project`, `dispute_case` UI.
+PO-Entscheidung: **AP2.3 (A–F) und AP2.4 abgeschlossen** — Archetyp-Welle 2 (B1, A3, D1) über Specs + Registrierung.
 
 ---
 

docs/architecture/Kairo_Method_Design_Principles_v0.1.md

@@ -2,7 +2,7 @@
 ## v0.1 – Designprinzipien für registrierbare Steuerungsmethoden
 
 **Status:** verbindlicher Architektur- und Methodendesign-Entwurf  
-**Stand:** 2026-07-05  
+**Stand:** 2026-07-25 (§11 AP2.4-Vertrag ergänzt)  
 **Zweck:** Definition der Designprinzipien, nach denen Kairo-Methoden künftig entwickelt, registriert, erweitert und versioniert werden.
 
 ---
@@ -377,7 +377,26 @@ Signal Rules müssen tenant-sicher sein und dürfen nicht quer über Tenants les
 
 ## 11. Method Definition Contract
 
-Eine MethodDefinition sollte mindestens enthalten:
+**Implementiert (AP2.4, Jul 2026):** Der produktive Vertrag in `backend/steering/methods/registry.py` ist schmaler als das Zielbild unten, aber verbindlich für MVP. Vollständige Spezifikation: `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md`.
+
+**AP2.4-Pflichtfelder (heute):**
+
+```text
+method_key
+label
+data_slices                    # Schnittmenge mit archetype.om_capabilities
+compatible_archetype_keys
+steering_elements              # Keys aus steering/elements/registry.py
+ui_features                    # z. B. critical_path, recurring_panel
+graph_profile                  # Kanten-/Graph-Strenge
+next_action_strategy           # optional, Strategie-Slug
+method_role                    # primary | composable | profile
+composes_with                  # optional, andere method_keys
+```
+
+**Zielbild (langfristig, noch nicht voll implementiert):**
+
+Eine MethodDefinition sollte zusätzlich mindestens enthalten:
 
 ```text
 method_key
@@ -406,6 +425,8 @@ allowed_node_types
 default_configuration
 ```
 
+**Regel:** Neue MVP-Methoden erweitern den AP2.4-Vertrag — keine parallelen UI-Registry-Hacks im Frontend.
+
 ---
 
 ## 12. Method Versioning

docs/product/DOCUMENTATION_REVISION_PROGRAM_v0.2.md

@@ -117,8 +117,9 @@ Schicht G — Reference / Design Principles  ← Nicht automatisch Scope
 
 | Dokument | Status | Aktion |
 |----------|--------|--------|
-| `CLAUDE.md` | ⚠ veraltet | Lesereihenfolge → Vision v0.2 |
+| `CLAUDE.md` | ✓ aktualisiert (2026-07-25) | AP2.3/AP2.4, Plugin-Regeln |
-| `.cursor/rules/kairo-architecture.mdc` | ⚠ veraltet | Doc-Priorität + Stop CRUD-Wand |
+| `.cursor/rules/kairo-architecture.mdc` | ✓ aktualisiert | Querverweis Plugin-Rule |
+| `.cursor/rules/kairo-plugin-architecture.mdc` | ✓ neu | Verbindliche AP2.3/AP2.4 Guardrails |
 | `Kairo_Architecture_References_v0.1.md` | ⚠ veraltet | → v0.2 |
 
 ---
@@ -145,6 +146,16 @@ Schicht G — Reference / Design Principles  ← Nicht automatisch Scope
 - [x] `Sprint0_Vibe_Coder_Handover_v0.2.md`
 - [x] `Sprint1_AP1_2c_IA_Skeleton_Assignment_v0.1.md`
 
+### Welle 2b — Plugin-Architektur-Doku (2026-07-25) ✓
+
+- [x] `ADP_Archetype_Method_Plugin_Architecture_v0.1.md` — Status geliefert, Ist-Tabelle
+- [x] `ADP_AP2_4_Steering_Elements_and_Method_Contract_v0.1.md` — Status geliefert
+- [x] `Kairo_Implementation_Truth_Table_v0.1.md` — AP2.3/4 ✓
+- [x] `Kairo_MVP_Execution_Plan_v0.2.md` — Phase 0b ✓
+- [x] `Kairo_Method_Design_Principles_v0.1.md` §11 — AP2.4-Vertrag
+- [x] `Kairo_Archetype_Specification_Program_v0.1.md` + Archetyp-Template — Schicht 1b
+- [x] `.cursor/rules/kairo-plugin-architecture.mdc` + `CLAUDE.md` + `kairo-architecture.mdc`
+
 ### Welle 3 — Architektur-Konsolidierung
 
 - [ ] Target Architecture / Universal Steering Engine — Duplikate reduzieren, ein Master-Index

docs/product/Kairo_Archetype_Specification_Program_v0.1.md

@@ -0,0 +1,136 @@
+# Jinkendo Kairo
+## Archetyp-Spezifikationsprogramm v0.1
+
+**Status:** aktiv — Spezifikationsphase (vor weiterer Archetyp-Implementierung)  
+**Stand:** 2026-07-25  
+**Auslöser:** Katalog (ADP) reicht für Portfolio-Inventar, nicht für erschöpfende Implementierung  
+**Ersetzt nicht:** `ADP_Archetype_and_Method_Catalog_v0.2.md` (führender Katalog), `Kairo_MVP_Execution_Plan_v0.2.md` (Priorisierung)  
+**Architektur-Basis:** AP2.3/AP2.4 Plugin-Architektur **geliefert** — Specs beschreiben fachliche Ausprägung, nicht Page-Ifs
+
+---
+
+## 1. Ziel
+
+Jeder Archetyp im Referenz-Portfolio erhält eine **Implementierungs-Spezifikation**, die:
+
+1. fachlich **eindeutig** sagt, was Nutzer anlegen, steuern und sehen
+2. **Abnahme-DoD** liefert (MVP-Nutzbarkeits-Bar abgebildet)
+3. Lücken zum Ist (Truth Table / Code) **explizit** macht
+4. ohne neuen Parallel-Katalog den ADP **vertieft**, nicht ersetzt
+
+**Ausgang:** Ohne Spec kein neues Code-Paket für A3/B1/D1/C1 und keine „fertig“-Markierung für Stufe A.
+
+---
+
+## 2. Dokumentenlage
+
+```text
+ADP_Archetype_and_Method_Catalog_v0.2.md     ← Was existiert im Portfolio? (PO ✓)
+        │
+        ▼
+docs/product/archetypes/SPEC_*.md            ← Wie genau implementieren/abnehmen?
+        │
+        ▼
+docs/sprints/Sprint1_AP*_Assignment_*.md     ← Code-Auftrag (nach Spec-Freigabe)
+        │
+        ▼
+Kairo_Implementation_Truth_Table_v0.1.md     ← Was ist wirklich da?
+```
+
+| Schicht | Dokument | Rolle |
+|---------|----------|--------|
+| Katalog | ADP v0.2 §3–§5 | Inventar, Nutzerbild, Scope Lock |
+| Plugin | ADP AP2.3 / AP2.4 | Archetyp ↔ Methode, Element-Registry, Operating Context |
+| Spec | `docs/product/archetypes/` | Implementierbare Detail-Spec |
+| Auftrag | Sprint Assignments | Scope + DoD für ein AP |
+| Ist | Truth Table | Living Check |
+| Guardrails | `.cursor/rules/kairo-plugin-architecture.mdc` | Verbindlich für Code |
+
+**Konfliktregel:** Vision / MVP v0.3 / ADP Katalog > Spec > Assignment. Spec darf Katalog **präzisieren**, nicht widersprechen — Abweichung nur per ADP-Update.
+
+---
+
+## 3. Spezifikations-DoD („Spec vollständig“)
+
+Eine Archetyp-Spec ist **fertig zur Implementierung / Abnahme**, wenn alle Punkte ✓ oder bewusst `n/a` sind:
+
+| # | Kriterium |
+|---|-----------|
+| 1 | Identität: `archetype_key`, Default-`method_key`, MVP-Stufe, Abgrenzung zu Nachbarn |
+| 2 | Referenzbeispiel (konkret durchspielbar) |
+| 3 | Plan-Objekte: erlaubte `RoadmapItem`-Typen, Projects, Graph-Regeln |
+| 4 | Ist-Objekte: Backlog / Action / Task / Recurring / work_cycle — was ja/nein |
+| 5 | Steuerung: Next Action, Attention, Lifecycle, **`steering_elements`** (Methode) |
+| 6 | UI: Prozessleiste (`ui_profile`), Default-Routen, **`ui_features`** (Methode), Anti-Todo-Wand |
+| 7 | EFS: verbindliche Felder (min. Liste) vs. optional |
+| 8 | Starter-Kit / Ausprägung: was bei Anlage, was später |
+| 9 | Happy Path (Schrittfolge) + mind. 2 Negative/Anti-Patterns |
+| 10 | Abnahme-Checkliste (MVP §5 + Szenario aus MVP §8) |
+| 11 | Ist-Stand-Tabelle (Spec vs. Code) |
+| 12 | Offene PO-Fragen = leer **oder** terminiert entschieden |
+
+Template: [`archetypes/_TEMPLATE_Archetype_Spec_v0.1.md`](archetypes/_TEMPLATE_Archetype_Spec_v0.1.md)
+
+---
+
+## 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
+```
+
+**Stop-Regel:** Kein neues Implementierungs-AP für einen Archetyp, solange Spec-Status ≠ `freigegeben` (Stufe A: `abnahmereif` reicht für Validation AP2.1).
+
+---
+
+## 5. Lückenmatrix (Stand 2026-07-25)
+
+Legende Spec-Status: `Lücke` · `Entwurf` · `abnahmereif` · `freigegeben`
+
+| ID | Archetyp | Katalog ADP §5 | Spec-Datei | Spec-Status | Code (grob) | Nächster Spec-Fokus |
+|----|----------|----------------|------------|-------------|-------------|---------------------|
+| A1 | maturity_journey | ✓ | SPEC_A1 | Entwurf → abnahmereif | ◐ Starter+Steuerung | DoD + Happy Path schärfen |
+| A2 | linear_project | ✓ | SPEC_A2 | Entwurf → abnahmereif | ◐ krit. Pfad | DoD + Begleitstrang |
+| B2a | program | ✓ | SPEC_B2a | Entwurf | ◐ | Closure-Lifecycle vs Product |
+| B2b | product | ✓ | SPEC_B2b | Entwurf → abnahmereif | ◐ Sprint-Flow | Product Language + Defaults |
+| B3 | agile_iteration *(Profil)* | ✓ | SPEC_B3 | Entwurf | ◐ | Abgrenzung Action vs work_cycle |
+| A3 | recurring_program | ✓ grob | SPEC_A3 | Entwurf | ○ Stub | Minimal-B vs AP2.0g Score |
+| B1 | support_queue | ✓ grob | SPEC_B1 | Entwurf | ○ Stub | Inbox vs Queue vs Capture |
+| D1 | content_project | ✓ grob | SPEC_D1 | Entwurf | ○ Stub | `chapter` item_type + Kit |
+| C1 | dispute_case | ✓ Katalog | SPEC_C1 | Entwurf | ○ Stub | nur Katalog-Felder |
+| — | generic | Fallback | SPEC_generic | Entwurf | ✓ | Attention „Struktur fehlt“ |
+
+---
+
+## 6. Arbeitsmodus
+
+1. Spec öffnen / anlegen nach Template  
+2. ADP §5 + MVP §5/§8 + Truth Table einarbeiten  
+3. Offene Fragen als PO-Block listen (nicht still entscheiden)  
+4. PO-Review → Status `abnahmereif` / `freigegeben`  
+5. Erst dann Assignment / Code  
+
+**Nicht:** Execution Plan v0.3 schreiben · Seeds als Spec-Ersatz · UI-Hints ohne Spec-DoD.
+
+---
+
+## 7. Bezug Portfolio-Capture
+
+Listen-Erfassung / Einsortieren ist **kein Archetyp**, sondern Querschnitt (vorgeschlagen nach B1). Eigene ADP später; Spec B1 muss die Schnittstelle „ungeordnete Items → Themen-Zuordnung“ vorsehen.
+
+---
+
+## 8. PO-Freigabe (offen)
+
+- [ ] Spezifikationsprogramm v0.1 als verbindliche Phase
+- [ ] Template Pflichtabschnitte akzeptiert
+- [ ] Reihenfolge Welle 1 → 2 bestätigt
+- [ ] Erste Specs (A1/A2/B2b) Review-Termin
+
+---
+
+*Erstellt 2026-07-24. Katalog bleibt ADP v0.2; dieses Programm steuert nur die Vertiefung.*

docs/product/Kairo_Implementation_Truth_Table_v0.1.md

@@ -1,7 +1,7 @@
 # Kairo — Implementation Truth Table v0.1
 
 **Status:** living document — bei jedem AP aktualisieren  
-**Stand:** 2026-07-12 (Execution-Plan ADP, AP1.16 in Roadmap)  
+**Stand:** 2026-07-25 (AP2.3/AP2.4 Plugin-Architektur geliefert)  
 **Zweck:** Ehrliche Trennung von **implementiert**, **teilweise**, **nur API/Schema**, **nur Dokumentiert**
 
 Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
@@ -77,7 +77,7 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
 | steering_contexts (009) | ✓ | Lifecycle, method_key |
 | backend/steering/ lifecycle | ✓ | |
 | Signal Engine | ◐ | Regeln begrenzt; Cockpit-Kacheln AP1.9c ✓ |
-| Method Registry | ◐ | AP2.0a: Stubs inkl. `continuous_product`, `program_delivery`, …; 2 Strategien aktiv |
+| Method Registry | ◐ | AP2.0a Stubs; AP2.4 erweiterter `MethodDefinition`-Vertrag |
 | Archetyp-/Methoden-Katalog PO | ✓ | ADP v0.2 + MVP v0.3 |
 | NextActionCandidate | ◐ | API + Widget; `reason_code` AP2.0c/d; Strategien nutzen `ready_actions` (AP2.0d) |
 | Portfolio-Priorität (Initiativen) | ◐ | AP1.8a: `portfolio_rank`, Reorder, Next-Action-Sort |
@@ -85,8 +85,8 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
 | AttentionItem | ◐ | |
 | Initiative Steering Snapshot | ✓ | Actions + linked; Archetyp/Guidance AP2.0c |
 | Operating Context API | ✓ | AP2.3a: `GET …/operating-context`, `ui_profile_json` Migration 027 |
-| Archetyp-/Methoden-Plugin-Architektur | ◐ | AP2.3 A–F ✓; AP2.4 Steuerungselemente + Methoden-Vertrag ◐ |
+| Archetyp-/Methoden-Plugin-Architektur | ✓ | AP2.3 A–F + AP2.4; Operating Context, Slice-Loader, Route Gating |
-| Steuerungselement-Registry | ◐ | AP2.4: `steering/elements/`, FE `steeringElementRegistry` |
+| Steuerungselement-Registry | ✓ | AP2.4: `steering/elements/`, FE `steeringElementRegistry`, Methoden-Vertrag |
 | operating_phase | ✗ | entfernt AP1.2 |
 | signals (Snapshot) | ✓ | `snapshot_signals.py` |
 | Graph Read Models (blocked/ready) | ◐ | AP1.4d/e; Join/OR AP1.15d deferred |
@@ -120,8 +120,8 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
 | Plan-Outline | ◐ | AP1.12a–d: Baum, Modal, Reorder, Actions; AP-Kanten AP1.16c offen |
 | Execution-Plan (AP-Graph) | ◐ | AP1.16c: Outline + Arbeit-Liste + Action-Detail |
 | Profil-Modal (Archetyp/EFS) | ◐ | AP1.10c |
-| Operating Profile Resolver (FE) | ◐ | AP2.3b/f: API-first, `methodUiDefaults` Fallback |
+| Operating Profile Resolver (FE) | ✓ | AP2.3b/f + AP2.4: API-first; `methodUiDefaults` nur Legacy-Fallback |
-| Route Gating (Modus-Routen) | ◐ | AP2.3d/f: `OperatingRouteGate`, `MODE_ROUTE_GROUPS` |
+| Route Gating (Modus-Routen) | ✓ | AP2.3d/f: `OperatingRouteGate`, `MODE_ROUTE_GROUPS`, `renderModeRoutes` |
 | Modal-Bearbeitung (Gates/Profil) | ◐ | viele Sektionen noch Inline-CRUD |
 | Admin-UI | ✗ | |
 | Team-Modus | ✗ | AP1.9f |
@@ -221,6 +221,7 @@ Details: `Kairo_Status_Review_and_Next_Steps_v0.1.md` §2.1
 
 | AP | Erwartung |
 |----|-----------|
+| AP2.3/4 | ✓ Plugin-Architektur + Element-Registry (2026-07-25) |
 | AP2.2a | Starter-Kits ◐→✓ |
 | AP2.2b–e | Referenz-Archetypen End-to-End ◐→✓ |
 | AP2.1 | MVP-Abnahfe ✗→✓ |

docs/product/Kairo_MVP_Execution_Plan_v0.2.md

@@ -2,9 +2,8 @@
 ## MVP Execution Plan v0.2
 
 **Status:** PO-Kurskorrektur — **führend für Implementierung ab 2026-07-12**  
-**Stand:** 2026-07-12  
+**Stand:** 2026-07-25 (AP2.3/AP2.4 Plugin-Architektur ✓)  
-**Ersetzt als Priorisierung:** Dogfooding-Seed als Implementierungs-Hebel; Status-Review §5 (Dogfooding-first)  
+**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)  
-**Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–9, `ADP_Archetype_and_Method_Catalog_v0.2.md` §3, `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
 
 ---
@@ -50,6 +49,7 @@ Legende: **Anlage** · **Struktur** · **Ist** · **Kontrolle** · **UI-Default*
 - Execution-Graph / `ready_actions` (AP1.16)
 - `work_cycle` + `actions.work_cycle_id` (AP2.0f)
 - Operational Actor API + Service Tokens (AP1.7)
+- **Plugin-Architektur AP2.3/AP2.4:** Operating Context, Slice-Loader, Route Gating, Steuerungselement-Registry, Methoden-Vertrag
 
 ### 3.2 Produkt-Lücken (MVP-kritisch)
 
@@ -71,8 +71,10 @@ Legende: **Anlage** · **Struktur** · **Ist** · **Kontrolle** · **UI-Default*
 ## 4. Implementierungsfolge (korrigiert)
 
 ```text
-Phase 0   DOC + Kurskorrektur (dieses Dokument)                    ← jetzt
+Phase 0   DOC + Kurskorrektur (dieses Dokument)                    ✓
+Phase 0b  AP2.3/AP2.4 Plugin-Architektur (Archetyp ↔ Methode)      ✓
 Phase 1   AP2.2a  Archetyp-geführte Anlage + Starter-Kits           ✓
+Phase 1b  Specs Welle 1 finalisieren (A1,A2,B2a,B2b,B3)            ◐
 Phase 2   AP1.9d  Methoden-Default-Ansichten (Anti-Todo-Wand)       ◐ (Hints + Recurring)
 Phase 3   AP2.2b  A2 Linear End-to-End                             ◐
           AP2.2c  A1 Reifegrad + AP2.0e                            ◐ Code

docs/product/archetypes/README.md

@@ -0,0 +1,18 @@
+# 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)
+
+| 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 | — |

docs/product/archetypes/SPEC_A1_maturity_journey_v0.1.md

@@ -0,0 +1,172 @@
+# SPEC — A1 `initiative.maturity_journey`
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf (Welle 1 — Verdichtung)  
+**Stand:** 2026-07-24  
+**MVP-Stufe:** A  
+**Katalog:** `ADP_Archetype_and_Method_Catalog_v0.2.md` §5 A1  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.maturity_journey` |
+| Label (DE) | Reifegrad-Entwicklung |
+| Default-`method_key` | `maturity_progression` |
+| Ausprägungen | z. B. `maturity.karate_kumite` (optional) |
+| Project-Spiegel | `project.maturity_journey` |
+| MVP-Stufe | A |
+
+### 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 |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Wer / Situation:** Person entwickelt eine Fähigkeit über Stufen (Karate, Fitness, Spagat).
+
+**Referenzbeispiel:** „Spagat können“ oder „Karate Kumite“ — mehrere Fähigkeiten als Projects, Stufen als `maturity_stage`, tägliche Übung als Recurring.
+
+**Leitfrage:** *Welche Stufe ist aktiv — und welche Übung bringt mich heute weiter?*
+
+---
+
+## 3. Plan-Objekte
+
+| 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.
+
+---
+
+## 4. Ist-Objekte
+
+| 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 |
+
+**Ist-Anti-Pattern:** 200 Übungs-Tasks in Ausführen.
+
+**Stufenwechsel (AP2.0e):** Bei `maturity_stage` → `reached` wechselt / rotiert das Recurring-Set der nächsten Stufe.
+
+---
+
+## 5. Steuerung
+
+**Methode:** `maturity_progression`
+
+| 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 | — |
+
+---
+
+## 6. UI / IA
+
+| 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 |
+
+---
+
+## 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
+
+| 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 |
+
+---
+
+## 9. Happy Path
+
+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
+
+### Negative
+
+1. Alle Übungen als Actions anlegen → Attention/Guidance gegen Todo-Wand  
+2. Stufe `reached` ohne Kriterien → Verify-Pfad blockiert / Override auditiert
+
+---
+
+## 10. Abnahme-DoD
+
+| # | 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.
+
+---
+
+## 11. Ist-Stand
+
+| 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 |
+
+---
+
+## 12. Offene PO-Fragen
+
+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?
+
+---
+
+## 13. Nachfolger
+
+- Validation: AP2.1 Szenario A1  
+- Feinschliff nur nach Spec-Status `abnahmereif`

docs/product/archetypes/SPEC_A2_linear_project_v0.1.md

@@ -0,0 +1,159 @@
+# SPEC — A2 `initiative.linear_project`
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf (Welle 1 — Verdichtung)  
+**Stand:** 2026-07-24  
+**MVP-Stufe:** A  
+**Katalog:** `ADP_Archetype_and_Method_Catalog_v0.2.md` §5 A2  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.linear_project` |
+| Label (DE) | Lineares Vorhaben |
+| Default-`method_key` | `sequential_dependency` |
+| Project-Spiegel | `project.linear_project` |
+| MVP-Stufe | A |
+
+### 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 |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Referenzbeispiel:** „Neue Küche“ — Hauptpfad (Handwerker-Sequenz) + Begleitung (parallel: Entsorgung, Finanzierung).
+
+**Leitfrage:** *Was ist der nächste ready Schritt am kritischen Pfad — und was blockiert?*
+
+---
+
+## 3. 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 | |
+
+**Plan-Anti-Pattern:** Nur flache Action-Liste ohne Gates/Abhängigkeiten.
+
+---
+
+## 4. 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 |
+
+---
+
+## 5. Steuerung
+
+**Methode:** `sequential_dependency`
+
+| 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 | — |
+
+---
+
+## 6. UI / IA
+
+| 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 |
+
+---
+
+## 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
+
+| 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.“ |
+
+---
+
+## 9. Happy Path
+
+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
+
+### Negative
+
+1. Alle Handwerker-Schritte als gleichwertige Todos ohne Graph  
+2. Next Action zeigt blockierte AP als ready
+
+---
+
+## 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.
+
+---
+
+## 11. Ist-Stand
+
+| 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 |
+
+---
+
+## 12. Offene PO-Fragen
+
+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?
+
+---
+
+## 13. Nachfolger
+
+- AP2.1 Szenario A2

docs/product/archetypes/SPEC_A3_recurring_program_v0.1.md

@@ -0,0 +1,135 @@
+# SPEC — A3 `initiative.recurring_program`
+## Implementierungs-Spezifikation 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`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.recurring_program` |
+| Label (DE) | Dauerprogramm / Rhythmus |
+| Default-`method_key` | `recurring_control` |
+| Project-Spiegel | `project.recurring_program` |
+| MVP-Stufe | B |
+
+### 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 |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Referenzbeispiel:** „Haus in Ordnung“ — Domains (Küche, Garten), Rhythmen pro Actor, Übernahme möglich (B+).
+
+**Leitfrage:** *Was ist heute fällig / überfällig — und wo weicht das System ab?*
+
+---
+
+## 3. Plan-Objekte
+
+| Objekt | Pflicht / optional | Regeln |
+|--------|-------------------|--------|
+| Project (Domain) | optional | EFS `domain_label` |
+| Gates | minimal / aus | nicht Steuerungskern |
+| Recurring-Definitionen | Kern | Cadence, Owner-Actor |
+
+---
+
+## 4. Ist-Objekte
+
+| Objekt | Regel |
+|--------|-------|
+| RecurringElement | **eine** offene Instanz pro Rhythmus |
+| ActionAssignment | Owner; B+: freiwillige Übernahme mit Audit |
+| Action | nur Eskalation / Ausnahme, nicht Duplikat-Staubsaugen |
+
+**Anti-Pattern:** 10× „Staubsaugen“ mit unterschiedlichen Daten als Tasks.
+
+---
+
+## 5. Steuerung
+
+**Methode:** `recurring_control`
+
+| Stufe | Signal |
+|-------|--------|
+| **B Minimal** | Next Action = fällig/heute; Attention = überfällig |
+| **B+ / AP2.0g** | Score (Cadence, verpasste Zyklen, Freiwilligkeit); Haushalts-Pool |
+
+---
+
+## 6. UI / IA
+
+Ausführen + „Team-Health“ dominant; Plan minimal; **kein** Task-Wall aller Mitglieder. Prozessleiste: spezifizieren in Welle 2 (noch kein methodUiDefaults-Eintrag).
+
+---
+
+## 7. EFS
+
+| `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.)*
+
+---
+
+## 8. Starter-Kit (Ziel)
+
+1 Domain-Project, 2 Recurring (z. B. wöchentlich / monatlich), Guidance: „Heute fällig steuert — keine Task-Duplikate.“
+
+---
+
+## 9. Happy Path (B Minimal)
+
+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
+
+---
+
+## 10. Abnahme-DoD (B Minimal)
+
+Anlegen, Rhythmen, heute/fällig, Anti-Duplikat, Leitfrage ≤2 Min. Score/Übernahme = separat B+.
+
+---
+
+## 11. Ist-Stand
+
+| 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 |
+
+---
+
+## 12. Offene PO-Fragen
+
+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?
+
+---
+
+## 13. Nachfolger
+
+Assignment AP2.2f / AP2.0g nach Spec-Freigabe.

docs/product/archetypes/SPEC_B1_support_queue_v0.1.md

@@ -0,0 +1,147 @@
+# SPEC — B1 `initiative.support_queue`
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf (Welle 2 — Spec vor Code; Capture-Schnittstelle)  
+**Stand:** 2026-07-24  
+**MVP-Stufe:** B  
+**Katalog:** ADP §5 B1  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.support_queue` |
+| Label (DE) | Inbox / Queue |
+| Default-`method_key` | `queue_pull` |
+| Project-Spiegel | `project.support_queue` |
+| MVP-Stufe | B |
+
+### Abgrenzung
+
+| Nicht verwechseln mit | Unterschied |
+|-----------------------|-------------|
+| B2b Eingang | Product-Backlog zahlt auf Produkt/Gates ein; B1 = Ad-hoc / themenbezogene Queue |
+| Portfolio-Capture | Capture ist Querschnitt; B1 kann **Ziel** oder **Sammel-Queue** sein |
+| Kanban-Board | Pull/Empfehlung, kein Board-Kern |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Nutzerbild:** „Nicht vergessen“-Inbox + bearbeitbare Queue. Items müssen **themenbezogen** zuordenbar sein — keine globale Mülltonne.
+
+**Varianten (PO zu wählen):**
+
+| Variante | Bedeutung |
+|----------|-----------|
+| A | Eigene Initiative pro Thema (Queue = Vorhaben) |
+| B | Queue-Project unter Product/Programm |
+| C | Tenant-weite Sammel-Queue + Weiterleitung in Ziel-Vorhaben |
+
+**Leitfrage:** *Welches eine Item ziehe ich als Nächstes — und in welchem Themen-Scope?*
+
+---
+
+## 3. Plan-Objekte
+
+| Objekt | Regeln |
+|--------|--------|
+| Eingang / Queue-Streams | triage vor Commit |
+| Gates | nicht dominant |
+| Themen-Zuordnung | Pflicht: Initiative / Project / Tag |
+
+---
+
+## 4. Ist-Objekte
+
+| Objekt | Rolle |
+|--------|-------|
+| BacklogItem | Inbox („nicht vergessen“) |
+| Action | Ticket nach Commit / Pull |
+| Assignment | unassigned → Attention |
+
+---
+
+## 5. Steuerung
+
+**Methode:** `queue_pull`
+
+| Signal | Logik |
+|--------|-------|
+| Next Action | 1 Empfehlung im Scope **oder** Nutzer-Pull |
+| Attention | SLA, unassigned high-priority, Überlauf |
+
+---
+
+## 6. UI / IA
+
+Eingang + Ausführen (Queue) dominant; thematische Filter **Pflicht**. Prozessleiste: noch zu definieren (Welle 2).
+
+---
+
+## 7. EFS
+
+| `field_key` | Zweck |
+|-------------|-------|
+| `queue_policy` | pull vs recommend |
+| `sla_hours` | Attention |
+| `default_topic_ref` | optional Default-Thema |
+
+---
+
+## 8. Starter-Kit (Ziel)
+
+1 Queue-Project oder Guidance „Thema = dieses Vorhaben“; 2 Beispiel-Inbox-Items; kein Gate-Kit.
+
+---
+
+## 9. Happy Path
+
+1. Queue-Vorhaben anlegen  
+2. Items erfassen (manuell; später Capture-Import)  
+3. Triage: Thema bestätigen / umhängen  
+4. Pull → eine Action in Arbeit  
+5. Kontrolle/Ausführen: eine Empfehlung, keine Gesamtwand
+
+### Schnittstelle Portfolio-Capture (vorbereiten)
+
+```text
+Capture-Review → Ziel = support_queue ODER konkretes Vorhaben
+              → Persistenz erst nach Freigabe als BacklogItem
+```
+
+Details: separates ADP nach Spec-Freigabe B1.
+
+---
+
+## 10. Abnahme-DoD (B)
+
+Inbox + Queue + Themen-Zuordnung minimal; Next Action = 1 Pull/Empfehlung; Leitfrage ≤2 Min; kein Board.
+
+---
+
+## 11. Ist-Stand
+
+| Bereich | Code | Lücke |
+|---------|------|-------|
+| Registry | ✓ | — |
+| queue_pull | Stub | volle Strategie |
+| Kit / UI | ✗ | Welle 2 |
+| Capture | ✗ | nach B1-Kern |
+
+---
+
+## 12. Offene PO-Fragen
+
+1. Variante A/B/C für MVP B — welche ist Default?  
+2. Ist Portfolio-Capture Teil von B1-AP oder eigenes AP danach?  
+3. Dürfen Queue-Items ohne Ziel-Vorhaben persistiert werden? (Empfehlung: ja, Status `unrouted`)
+
+---
+
+## 13. Nachfolger
+
+Assignment nach PO-Entscheidung Variante; Capture-ADP.

docs/product/archetypes/SPEC_B2a_program_v0.1.md

@@ -0,0 +1,130 @@
+# SPEC — B2a `initiative.program`
+## Implementierungs-Spezifikation 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`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.program` |
+| Label (DE) | Programm (begrenzt) |
+| Default-`method_key` | `program_delivery` |
+| Project-Spiegel | `project.program` |
+| MVP-Stufe | A\* |
+
+### 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 |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Referenzbeispiel:** Release-Programm / Großvorhaben mit Ende („Kairo Release-Programm“).
+
+**Leitfrage:** *Was blockiert den nächsten Meilenstein — und wann ist Closure sinnvoll?*
+
+---
+
+## 3. Plan-Objekte
+
+| 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 |
+
+---
+
+## 4. Ist-Objekte
+
+| Objekt | Rolle |
+|--------|-------|
+| Action + Task | Lieferung am Horizont |
+| BacklogItem → Action | Commit mit optionalem Gate-Link |
+| Review | Abschluss / Gate-Review |
+
+---
+
+## 5. Steuerung
+
+**Methode:** `program_delivery`
+
+| Signal | Logik |
+|--------|-------|
+| Next Action | Gate / AP am Programm-Horizont |
+| Attention | Gate at risk, Blocker, Backlog am aktiven Gate |
+| Lifecycle | **inkl. Closure** |
+
+---
+
+## 6. UI / IA
+
+Prozessleiste: Phasen → Eingang → Ausführen → Kontrolle. Plan-Default: Gates.
+
+---
+
+## 7. EFS
+
+| `field_key` | Pflicht | Zweck |
+|-------------|---------|-------|
+| `stakeholder_map` | optional | vorhanden (program/product seeds) |
+| `success_criteria` | empfohlen | Abschlusskriterien |
+| `release_theme` | optional | |
+
+---
+
+## 8. Starter-Kit
+
+Phase 1 Start (active), Phase 2 Lieferung, Abschluss — laut AP2.2a.
+
+---
+
+## 9. Happy Path
+
+1. Anlegen mit Phasen-Kit  
+2. Backlog → Action am aktiven Gate  
+3. Kontrolle: Horizont + Next Action  
+4. Abschluss-Gate / Lifecycle Closure
+
+---
+
+## 10. Abnahme-DoD
+
+Mindestens: Phasen sichtbar, Next Action am Horizont, Closure-Pfad dokumentiert (auch wenn UI minimal). Leitfrage ≤2 Min.
+
+---
+
+## 11. Ist-Stand
+
+| Bereich | Code | Lücke |
+|---------|------|-------|
+| Kit | ✓ | — |
+| UI-Prozess | ✓ | — |
+| Closure-Lifecycle UX | ◐ | Spec: expliziter Abschluss-Schritt nötig |
+| Strategie program_delivery | ◐ | vs. Legacy product_milestone_driven |
+
+---
+
+## 12. Offene PO-Fragen
+
+1. Ist B2a **Pflicht** für AP2.1 oder nur „mitdenken“?  
+2. Wann wechselt ein abgeschlossenes Programm bewusst zu Product-Betrieb (Datenmodell)?
+
+---
+
+## 13. Nachfolger
+
+AP2.2e / AP2.1 nach Spec-Freigabe.

docs/product/archetypes/SPEC_B2b_product_v0.1.md

@@ -0,0 +1,139 @@
+# SPEC — B2b `initiative.product`
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf (Welle 1 — Verdichtung)  
+**Stand:** 2026-07-24  
+**MVP-Stufe:** A  
+**Katalog:** ADP §5 B2b  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.product` |
+| Label (DE) | Produkt (kontinuierlich) |
+| Default-`method_key` | `continuous_product` |
+| Ausprägung | z. B. `product.kairo_dev` |
+| Project-Spiegel | `project.product` |
+| MVP-Stufe | A |
+
+### 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 |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Referenzbeispiel:** Kairo-Betrieb — Issues, Features, Wartung; optional Sprints mit Vibe-Coder.
+
+**Leitfrage:** *Was ist jetzt am wirksamsten — im aktiven Gate- oder Sprint-Horizont?*
+
+---
+
+## 3. 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 |
+
+---
+
+## 4. Ist-Objekte
+
+| Objekt | Rolle |
+|--------|-------|
+| Action | Feature / Fix / Ops — committet |
+| Action + `work_cycle_id` | Sprint-Backlog |
+| BacklogItem | noch nicht committet |
+| Task | unter Action |
+
+**Anti-Pattern:** Sprint-Backlog als BacklogItem-Liste; alle APs aller Gates in einer Hauptliste.
+
+---
+
+## 5. Steuerung
+
+**Methode:** `continuous_product` (+ `agile_iteration` wenn Sprint aktiv)
+
+| 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 |
+
+---
+
+## 6. UI / IA
+
+| 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 |
+
+---
+
+## 7. EFS
+
+| `field_key` | Zweck |
+|-------------|-------|
+| `metrics` | optional (Seed product) |
+| `release_theme` | optional |
+
+---
+
+## 8. Starter-Kit
+
+Orientierungs-Gate, nächster Release-Horizont, Projects Entwicklung/Betrieb, 1 BacklogItem „Idee / Issue“, B3-Hinweis.
+
+---
+
+## 9. Happy Path
+
+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
+
+---
+
+## 10. Abnahme-DoD
+
+MVP §8 B2b + B3 minimal: Eingang ≠ Sprint-Backlog; Leitfrage ≤2 Min; kein Closure-Zwang.
+
+---
+
+## 11. Ist-Stand
+
+| 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 |
+
+---
+
+## 12. Offene PO-Fragen
+
+1. Muss jedes Product-Vorhaben Gates haben, oder reicht Eingang + Actions?  
+2. Ist aktiver Sprint für Stufe-A-Abnahme Pflicht oder optional?
+
+---
+
+## 13. Nachfolger
+
+AP2.1 B2b (+ B3); SPEC_B3 parallel halten.

docs/product/archetypes/SPEC_B3_sprint_profile_v0.1.md

@@ -0,0 +1,113 @@
+# SPEC — B3 Sprint / Iteration (Profil)
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf (Welle 1)  
+**Stand:** 2026-07-24  
+**MVP-Stufe:** A (Minimal)  
+**Hinweis:** **Kein** Initiative-Archetyp — Profil/`method_key`-Hook auf B2a/B2b  
+**Katalog:** ADP §5 B3  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| Eigenständiger `archetype_key` | **nein** |
+| Methode / Profil | `agile_iteration` auf `continuous_product` / `program_delivery` |
+| Plan-Objekt | `RoadmapItem(item_type=work_cycle)` |
+| Ist-Bindung | `actions.work_cycle_id` |
+
+### Abgrenzung
+
+| Nicht | Stattdessen |
+|-------|-------------|
+| `initiative.agile_team` | Product/Programm + work_cycle |
+| Sprint-Backlog = BacklogItems | Actions mit work_cycle_id |
+| Kanban / Velocity | explizit out of scope |
+
+---
+
+## 2. Nutzerbild
+
+PO + optional Vibe-Coder; Kairo ersetzt Scrum-Master-Logik (Next Action, Attention, Sprint-Grenzen). Sprint = Planungs-Container, kein Kalender-Zwang.
+
+**Leitfrage:** *Was ist der nächste Schritt **in diesem Sprint**?*
+
+---
+
+## 3–4. Plan / Ist
+
+| Plan | Ist |
+|------|-----|
+| work_cycle anlegen (geplant/aktiv/abgeschlossen) | Actions dem Sprint zuordnen |
+| Sprint-Planung aus Eingang | Ausführen zeigt Sprint-Backlog (1–3 Fokus) |
+| Abschluss → Review/Carryover | offene Items: behalten / zurück Eingang / nächster Sprint |
+
+---
+
+## 5. Steuerung
+
+| Signal | Logik |
+|--------|-------|
+| Next Action | Items im aktiven work_cycle (ready) |
+| Attention | leerer aktiver Sprint; Sprint überfällig (wenn Datum gesetzt) |
+| Ohne aktiven Sprint | Fallback Parent-Methode (continuous_product) |
+
+---
+
+## 6. UI
+
+Product Language: **Sprint**. Prozessschritte: Sprint planen, Ausführen/Sprint. Kein Team-Board.
+
+---
+
+## 7. EFS (optional)
+
+`sprint_goal` am work_cycle — empfohlen, nicht MVP-blockierend.
+
+---
+
+## 8. Starter-Kit
+
+Kein eigener Kit — Hinweis im Product-Kit: „Optional Sprint unter Plan anlegen“.
+
+---
+
+## 9. Happy Path
+
+1. Product mit Eingang  
+2. Sprint anlegen → Items aus Eingang committen/zuordnen  
+3. Ausführen = Sprint-Backlog  
+4. Abschließen → Carryover-Entscheidung  
+5. Ohne Sprint: kein leerer Sprint-Screen als Sackgasse
+
+---
+
+## 10. Abnahme-DoD (Minimal A)
+
+Ein aktiver Zyklus; Next Action im Zyklus; Abschluss-Pfad; kein Board/Velocity.
+
+---
+
+## 11. Ist-Stand
+
+| Bereich | Code | Lücke |
+|---------|------|-------|
+| work_cycle API/UI | ◐ | Complete/Reactivate ggf. WIP lokal |
+| agile_iteration Strategie | ◐ | |
+| Carryover-UX | ◐ | Spec schärfen |
+
+---
+
+## 12. Offene PO-Fragen
+
+1. Pflicht-Carryover-Dialog bei Abschluss oder soft hint?  
+2. Darf mehr als ein „aktiver“ Sprint existieren? (Empfehlung Spec: **nein**, genau einer aktiv)
+
+---
+
+## 13. Nachfolger
+
+An SPEC_B2b koppeln; Validation mit B2b.

docs/product/archetypes/SPEC_C1_dispute_case_v0.1.md

@@ -0,0 +1,69 @@
+# SPEC — C1 `initiative.dispute_case`
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf (Welle 4 — Katalogvertiefung, **kein MVP-Code**)  
+**Stand:** 2026-07-24  
+**MVP-Stufe:** C  
+**Katalog:** ADP §5 C1  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.dispute_case` |
+| Label (DE) | Verfahren / Konflikt |
+| Default-`method_key` | `dispute_procedure` |
+| Project-Spiegel | `project.dispute_case` |
+| MVP-Stufe | C (Katalog) |
+
+### Abgrenzung
+
+Reaktiv (Fristen, Entscheidungen aus Status) — nicht planerisches Programm. Keine Rechts-Fachlogik aus Spezialsoftware.
+
+---
+
+## 2. Nutzerbild
+
+**Referenz:** Miterstreit — Phasen, Fristen, Decision-Pflicht bei Reopen, Evidence.
+
+**Leitfrage:** *Welche Frist / Entscheidung ist als Nächstes dran?*
+
+---
+
+## 3–5. Skizze (nicht implementierungsreif)
+
+| Schicht | Inhalt |
+|---------|--------|
+| Plan | `phase` Gates, Iterationen |
+| Ist | Decision, Evidence, Actions aus Statuswechsel |
+| Steuerung | Next = Frist / offene Decision / neuer Strang |
+
+---
+
+## 6–10. UI / EFS / Kit / DoD
+
+**Absichtlich dünn:** Nur Katalog + Profilfelder bis PO Stufe C freigibt. Kein Starter-Kit-AP, keine Validation in AP2.1.
+
+EFS (Ziel, später): `case_reference`, `next_deadline`, `counsel_actor_ref`.
+
+---
+
+## 11. Ist-Stand
+
+Registry + Stub-Methode ✓. Alles andere ✗ / deferred.
+
+---
+
+## 12. Offene PO-Fragen
+
+1. Wann Stufe C starten?  
+2. Welche Phasen-Typen sind generisch genug ohne Rechts-Domäne?
+
+---
+
+## 13. Nachfolger
+
+Kein Assignment bis Welle 4 PO-Go.

docs/product/archetypes/SPEC_D1_content_project_v0.1.md

@@ -0,0 +1,134 @@
+# SPEC — D1 `initiative.content_project`
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf (Welle 2 — Spec vor Code)  
+**Stand:** 2026-07-24  
+**MVP-Stufe:** B  
+**Katalog:** ADP §5 D1  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.content_project` |
+| Label (DE) | Inhalt / Kapitel |
+| Default-`method_key` | `chapter_based_progression` |
+| Ausprägung | `content.book_writing` |
+| Project-Spiegel | `project.content_project` |
+| MVP-Stufe | B |
+
+### Abgrenzung
+
+| Nicht verwechseln mit | Unterschied |
+|-----------------------|-------------|
+| A2 Linear | Kapitel-Progression + Review, nicht Handwerker-Gate-Pfad |
+| A1 | Keine Übungs-Recurring als Kern |
+| B2 Product | Inhaltliches Ende (Manuskript) denkbar, aber Steuerung = Kapitel |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Referenzbeispiel:** Buch schreiben — Kapitel als Plan, Schreib-APs als Ist, Review-Gates.
+
+**Leitfrage:** *Welches Kapitel / welcher Schreib-Schritt ist als Nächstes dran?*
+
+---
+
+## 3. Plan-Objekte
+
+| Objekt | Pflicht | Regeln |
+|--------|---------|--------|
+| `chapter` | ja | Reihenfolge; nächstes offenes Kapitel |
+| `review_gate` | empfohlen | nach Kapitel-Blöcken |
+| `milestone` | optional | grobe Horizont-Marker |
+
+**Voraussetzung:** `item_type=chapter` muss im Schema/API unterstützt und in UI anlegbar sein (heute Lücke).
+
+---
+
+## 4. Ist-Objekte
+
+| Objekt | Rolle |
+|--------|-------|
+| Action | Schreib-AP, Recherche |
+| BacklogItem | Ideen / Szenen-Ideen vor Commit |
+| Evidence | Draft-Links, Review-Notizen |
+| Recurring | optional (Schreibroutine) — nicht Kern |
+
+---
+
+## 5. Steuerung
+
+**Methode:** `chapter_based_progression`
+
+| Signal | Logik |
+|--------|-------|
+| Next Action | nächstes Kapitel / offenes Schreib-AP / Review |
+| Attention | Kapitel ohne Fortschritt; Review überfällig |
+
+---
+
+## 6. UI / IA
+
+Plan: Kapitel-Outline dominant. Kontrolle: nächstes Kapitel. Prozessleiste: noch zu definieren.
+
+---
+
+## 7. EFS
+
+| `field_key` | Status Code | Zweck |
+|-------------|-------------|-------|
+| `manuscript_status` | ✓ Seed | |
+| `word_count_goal` | ✓ Seed | |
+| Rollen Autor/Lector | Ausprägung | Schicht 3 |
+
+---
+
+## 8. Starter-Kit (Ziel)
+
+3× `chapter` (geplant/aktiv), 1× `review_gate`, 1 Schreib-Action am aktiven Kapitel; Ausprägung book_writing optional mit Gliederungs-Template.
+
+---
+
+## 9. Happy Path
+
+1. Anlegen + Kapitel-Kit  
+2. Schreib-AP am Kapitel 1  
+3. Kontrolle: nächstes Kapitel begründet  
+4. Review-Gate nach Block  
+5. Journey: Kapitel-Fortschritt
+
+---
+
+## 10. Abnahme-DoD (B)
+
+MVP §8 D1: chapters + mind. 1 Schreib-AP; Next Action = Kapitel/AP; Leitfrage ≤2 Min.
+
+---
+
+## 11. Ist-Stand
+
+| Bereich | Code | Lücke |
+|---------|------|-------|
+| Registry / EFS Kern | ✓ | — |
+| `chapter` item_type | ○/✗ | Migration + UI |
+| Strategie | Stub → default | echte chapter-Strategie |
+| Starter-Kit | ✗ | |
+
+---
+
+## 12. Offene PO-Fragen
+
+1. Ist `chapter` eigener `item_type` (ADP ja) — bestätigen vor Migration  
+2. Reicht lineare Kapitel-Liste oder Graph zwischen Kapiteln für B?  
+3. Validation D1 in AP2.1 oder erst nach Stufe-A-Go?
+
+---
+
+## 13. Nachfolger
+
+AP2.2f nach Spec-Freigabe.

docs/product/archetypes/SPEC_generic_fallback_v0.1.md

@@ -0,0 +1,39 @@
+# SPEC — Fallback `initiative.generic`
+## Implementierungs-Spezifikation 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`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | `initiative.generic` |
+| Methode | `generic_operating` |
+| Rolle | Notfall / Altbestand — **nicht** empfohlen für neue Vorhaben |
+
+---
+
+## 2. Regeln
+
+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.
+
+---
+
+## 3. Abnahme
+
+Kein eigenes MVP-Szenario. Migration bestehender `generic`-Vorhaben = optionaler Cleanup, nicht Spec-Blocker.
+
+---
+
+## 4. Offene PO-Fragen
+
+1. Soft-Prompt beim Anlegen `generic` erlauben oder UI nur konkrete Archetypen zeigen?

docs/product/archetypes/_TEMPLATE_Archetype_Spec_v0.1.md

@@ -0,0 +1,186 @@
+# SPEC — {ID} `{archetype_key}`
+## Implementierungs-Spezifikation v0.1
+
+**Status:** Entwurf | abnahmereif | freigegeben  
+**Stand:** YYYY-MM-DD  
+**MVP-Stufe:** A | B | C  
+**Katalog:** `ADP_Archetype_and_Method_Catalog_v0.2.md` §5  
+**Programm:** `Kairo_Archetype_Specification_Program_v0.1.md`
+
+---
+
+## 1. Identität
+
+| Feld | Wert |
+|------|------|
+| `archetype_key` | |
+| Label (DE) | |
+| Default-`method_key` | |
+| Optional: `method_profile_key` / Ausprägungen | |
+| Project-Spiegel | `project.…` |
+| MVP-Stufe | |
+
+### Abgrenzung
+
+| Nicht verwechseln mit | Unterschied |
+|-----------------------|-------------|
+| | |
+
+---
+
+## 2. Nutzerbild & Referenzbeispiel
+
+**Wer / Situation:** …
+
+**Referenzbeispiel (durchspielbar):** …
+
+**Leitfrage in Kontrolle:** *Welcher nächste Schritt … und warum?*
+
+---
+
+## 3. Plan-Objekte
+
+| Objekt | Pflicht / optional | Regeln |
+|--------|-------------------|--------|
+| RoadmapItem `item_type=…` | | |
+| Project | | |
+| Graph-Kanten | | |
+| work_cycle | | |
+
+**Plan-Anti-Pattern:** …
+
+---
+
+## 4. Ist-Objekte
+
+| Objekt | Rolle | Commit-Regel |
+|--------|-------|--------------|
+| BacklogItem | | |
+| Action | | |
+| Task | | |
+| RecurringElement | | |
+| Evidence / Decision / Review | | |
+
+**Ist-Anti-Pattern:** …
+
+---
+
+## 5. Steuerung
+
+**Methode:** `{method_key}`
+
+| Signal | Logik | `reason_code` (Ziel) |
+|--------|-------|----------------------|
+| Next Action | | |
+| Attention | | |
+| Lifecycle | | |
+
+**Steering nur in** `backend/steering/` — keine Heuristik in Routern/Frontend.
+
+### Steuerungselemente (Schicht 1b — AP2.4)
+
+Welche Control-/Work-Bausteine die **Methode** (nicht der Archetyp) aktiviert:
+
+| `steering_element_key` | Rolle in Control/Work | Pflicht für Default-Methode? |
+|------------------------|----------------------|------------------------------|
+| | | |
+
+Registry: `backend/steering/elements/registry.py`, FE `steeringElementRegistry.js`. Pages composen nur über `operating_context.steering_elements` — **keine** Archetyp-Ifs.
+
+### Kompatible Methoden (optional)
+
+| `method_key` | Wann sinnvoll | Abweichung zu Default |
+|--------------|---------------|------------------------|
+| | | |
+
+Filter: `compatible_archetype_keys` + `data_slices ⊆ om_capabilities` (siehe ADP AP2.4).
+
+---
+
+## 6. UI / IA
+
+| Aspekt | Vorgabe |
+|--------|---------|
+| Prozessleiste | aus `ui_profile` (Archetyp) |
+| Plan-Default | |
+| Work-Default | |
+| Control-Default | |
+| `ui_features` (Methode) | z. B. recurring_panel — **nicht** am Archetyp |
+| Versteckt / sekundär | |
+
+Product Language: …
+
+---
+
+## 7. EFS-Felder
+
+| `field_key` | Typ | Pflicht | Zweck |
+|-------------|-----|---------|-------|
+| | | | |
+
+---
+
+## 8. Starter-Kit & Ausprägung
+
+| Element | Inhalt |
+|---------|--------|
+| Kit bei Anlage | |
+| Guidance (1 Satz) | |
+| Ausprägung (optional) | |
+
+---
+
+## 9. Happy Path (Abnahme-Flow)
+
+1. …
+2. …
+3. …
+
+### Negative / Randfälle
+
+1. …
+2. …
+
+---
+
+## 10. Abnahme-DoD
+
+Abgebildet auf MVP v0.3 §5:
+
+| # | Kriterium | Erfüllt wenn |
+|---|-----------|--------------|
+| 1 | Anlegen | |
+| 2 | Struktur | |
+| 3 | Ist committen | |
+| 4 | Kontrolle begründet | |
+| 5 | Journey | |
+| 6 | Leitfrage ≤2 Min | |
+| 7 | Cockpit Attention | |
+
+Szenario MVP §8: …
+
+---
+
+## 11. Ist-Stand (Spec vs. Code)
+
+| Bereich | Spec | Code/Truth | Lücke |
+|---------|------|------------|-------|
+| Registry / Methode | | | |
+| Starter-Kit | | | |
+| `steering_elements` / Control-UI | | | |
+| Operating Context / Slice-Loader | | | |
+| Next-Action-Strategie | | | |
+| Attention | | | |
+
+---
+
+## 12. Offene PO-Fragen
+
+1. …
+
+---
+
+## 13. Nachfolger
+
+- Assignment: …
+- Validation: AP2.1 / …