Some checks failed
Deploy Development / deploy (push) Successful in 48s
Test Suite / pytest-backend (push) Failing after 3m23s
Test Suite / k6 /api/health Baseline (push) Has been skipped
Test Suite / playwright-smoke (push) Has been skipped
Test Suite / lint-backend (push) Successful in 3s
Test Suite / compose-smoke (push) Has been skipped
Decision-Lock, Spec-D-Methoden und C1-Massstab-Vollspecs als Zielbild; Steering-Registry/Compat und Horizon-Tests an die Normierung anbinden. Implementierungsausreichendheit bleibt bewusst offen. Co-authored-by: Cursor <cursoragent@cursor.com>
4.5 KiB
4.5 KiB
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:
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)
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):
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:
- Pro Methode eine substanzielle Spec mit konkreten Steuerungsregeln (Ready, Ranking, Attention, Events, Graph-Semantik, Nested) — gespeist aus Decision-Lock, ADPs, Ist-Code.
- PO-Interview nur zu Spannungen / offenen Regeln (D12), nicht zu Label-Feldern.
- „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) |