diff --git a/docs/architecture/ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md b/docs/architecture/ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md index 496ddf4..e26a46e 100644 --- a/docs/architecture/ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md +++ b/docs/architecture/ADP_RoadmapItem_and_Quality_Gate_Model_v0.1.md @@ -159,6 +159,19 @@ Steering Snapshot: `upcoming_milestones` liest aus `roadmap_items` statt `milest - [ ] item_type initial: milestone, review_gate, maturity_stage - [ ] milestones-Tabelle darf deprecated werden - [ ] AP1.4 nach AP1.2c +- [ ] **Methodenneutralität:** Schema/UI nicht nur für sequenzielle Software-Gates + +--- + +## Methodische Neutralität (AP1.4) + +AP1.4 liefert das **generische Plan-Gerüst**. Konkrete Methoden (z. B. `product_milestone_driven`, Reifegrad-Parallelpfade, Content-Kapitel) **registrieren sich** über: + +- `item_type` + `sequencing_mode` auf RoadmapItem +- `method_key` auf `steering_context` (bereits vorhanden) +- später: Method-spezifische Verify-Policies, Structure Builder, Next-Action-Strategien + +**Nicht:** fest codierte „Meilenstein = lineare Software-Roadmap“-UI oder Dependency-Modell nur für WBS. --- diff --git a/docs/product/Kairo_Canonical_Operating_Model_v0.2.md b/docs/product/Kairo_Canonical_Operating_Model_v0.2.md index 82366c2..a3962f1 100644 --- a/docs/product/Kairo_Canonical_Operating_Model_v0.2.md +++ b/docs/product/Kairo_Canonical_Operating_Model_v0.2.md @@ -298,4 +298,18 @@ UI-Unterseiten und Agent-API müssen **fachlich äquivalent** bleiben. --- +## 15. Methodische Flexibilität (verbindlich) + +Kairo unterstützt **unterschiedliche Entwicklungs- und Steuerungsmethoden** — auf Portfolio-, Initiativ-, Plan- und Ausführungsebene. + +- **Kernmodell generisch:** RoadmapItem-Typen, Lifecycle, Actions — nicht „nur Software-PM“ +- **Methoden in Registry:** `steering_context.method_key` + Strategy/Hook-Pakete — keine Sonder-Tabellen pro Methode +- **Plan flexibel:** `sequencing_mode` sequenziell | parallel | optional; `item_type` (milestone, maturity_stage, chapter, …) +- **Verify flexibel:** Gate-`reached` über Evidence/Review/Decision — Policies methodenabhängig konfigurierbar (später) +- **UI methodenbewusst, nicht methodenfix:** Plan-Tab rendert RoadmapItems; Labels/Filter aus Method-Profil, nicht hardcodiert + +Siehe Vision v0.2 §9.1. + +--- + *v0.1 bleibt als historische Referenz erhalten.* diff --git a/docs/product/Kairo_Vision_and_Product_Direction_v0.2.md b/docs/product/Kairo_Vision_and_Product_Direction_v0.2.md index 80cba44..763c689 100644 --- a/docs/product/Kairo_Vision_and_Product_Direction_v0.2.md +++ b/docs/product/Kairo_Vision_and_Product_Direction_v0.2.md @@ -359,6 +359,41 @@ Prompt/KI/MCP bleiben **eingefroren**, bis Plan/Ist und Gates tragfähig modelli --- +## 9.1 Methodische Flexibilität auf allen Ebenen (verbindlich) + +Kairo ist **kein** einzelnes PM- oder Software-Framework. Auf **allen Ebenen** können unterschiedliche **Entwicklungs- und Steuerungsmethoden** gelten — parallel im Portfolio, unterschiedlich pro Vorhaben, später auch pro Project/Stream. + +**Prinzip:** Das **Kernmodell bleibt generisch**; konkrete Methoden stecken in der **Method Registry** (`backend/steering/methods/`), nicht in hardcodierten UI-Flows oder Tabellen pro Methode. + +| Ebene | Was variiert methodisch | Mechanismus (Ziel) | +|-------|-------------------------|---------------------| +| **Portfolio** | Priorisierung, Attention | Strategien in `steering/` (AP1.8) | +| **Initiative / Programm** | Lifecycle, Signals, Next Action | `steering_context.method_key` | +| **Plan** | Gate-Typen, Abfolge, DoD | `RoadmapItem.item_type`, `sequencing_mode`, Method-Hooks | +| **Ist / Ausführung** | Hierarchie (WBS vs. flach), Commit-Regeln | Method-Profil + Structure Builder (später) | +| **Verify / Review** | Was zählt als „erreicht“ | Evidence/Review-Policies pro Methode | +| **Agenten / Vibe-Coder** | Empfohlene nächste Schritte | Operational API + gleiche Steering-Strategien | + +**Beispiele gleichzeitig im Tenant:** + +- Vorhaben A: `product_milestone_driven` — sequenzielle Gates, Meilenstein-Horizont +- Vorhaben B: Reifegrad-Modell — **parallele** `maturity_stage`-RoadmapItems +- Vorhaben C: Content/Buch — Kapitel-Gates, andere DoD-Kriterien +- Vorhaben D: `generic_operating` — leichte Struktur, wenig Plan-Zwang + +**Was Implementierung nicht tun darf:** + +- Ein einziges Gate-Modell (nur sequenzielle Software-Meilensteine) +- UI, die nur eine Methoden-Metapher zeigt +- Abhängigkeiten nur als Gantt-Denke +- Next Action fest auf Priorität+Fälligkeit — ohne methoden-/kontextabhängige Strategie + +**AP1.4-Konsequenz:** RoadmapItem-Schema und Plan-UI **methodenneutral** bauen; `product_milestone_driven` ist **eine** registrierte Methode, nicht das Produkt. + +**Später:** Method Packages (Structure Builder, Hook-Sets, Next-Action-Strategien) erweiterbar — ohne OM-Tabellen pro Methode (Target State §7–8, §14). + +--- + ## 10. Ehrlicher Implementierungsstand (Kurz) | Visionselement | Stand | @@ -410,9 +445,25 @@ Kein weiteres Layout-Patching auf der Omnibus-Seite, bevor: | **AP1.5** | Hierarchie: Project, Task unter Action | | **AP1.6** | Plan/Ist-Views, Journey | +*Später:* Method Packages (Structure Builder, Hook-Sets, Next-Action-Strategien) erweiterbar — ohne OM-Tabellen pro Methode (Target State §7–8, §14). + +## 13. Product Owner Leitplanken + +Entscheidungen an diesem Dokument prüfen: + +1. Beantwortet die Änderung die **Leitfrage** auf der richtigen **Ebene** (Ausführung vs. Plan)? +2. Trennt sie **Plan** und **Ist**? +3. Ist ein Meilenstein **prüfbar** — oder nur ein Statusfeld? +4. Passiert Bearbeitung in **Modal/Detail** — oder wächst wieder eine CRUD-Wand? +5. Wird die **Reise** nachvollziehbar — oder nur der aktuelle Zustand? +6. Verhindert sie Scope-Creep in Richtung To-do-Tool? +7. Wird die Änderung **nur für eine Methode** hardcodiert — oder über Registry/Profil erweiterbar? +8. Unterstützt das Schema **sequenziell und parallel** (Gates vs. Reifegrade)? +9. Bleibt **Plan/Ist** getrennt, unabhängig von der gewählten Methode? + --- -## 12. Verbindliche Dokumenten-Hierarchie (neu) +## 14. Verbindliche Dokumenten-Hierarchie (neu) Bei Konflikten ab 2026-07-05: @@ -427,17 +478,4 @@ Bei Konflikten ab 2026-07-05: --- -## 13. Product Owner Leitplanken - -Entscheidungen an diesem Dokument prüfen: - -1. Beantwortet die Änderung die **Leitfrage** auf der richtigen **Ebene** (Ausführung vs. Plan)? -2. Trennt sie **Plan** und **Ist**? -3. Ist ein Meilenstein **prüfbar** — oder nur ein Statusfeld? -4. Passiert Bearbeitung in **Modal/Detail** — oder wächst wieder eine CRUD-Wand? -5. Wird die **Reise** nachvollziehbar — oder nur der aktuelle Zustand? -6. Verhindert sie Scope-Creep in Richtung To-do-Tool? - ---- - *Verwandt: `DOCUMENTATION_REVISION_PROGRAM_v0.2.md`, `Kairo_Canonical_Operating_Model_v0.2.md`, `Kairo_Implementation_Truth_Table_v0.1.md`*