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