Kairo-Jinkendo/docs/sprints/Sprint1_AP2_1_Validation_Findings_Register_v0.1.md

AP2.1 — Validation Findings Register

v0.1 (PO-Smoke → Architektur-Review)

Status: aktiv — wird während AP2.1 ergänzt
Stand: 2026-07-28 (A1 Minimum Slice implementiert — PO Re-Abnahme ausstehend)
Bezug: Sprint1_AP2_1_MVP_Validation_Report_v0.3.md, Kairo_MVP_Definition_v0.3.md §5–8
Dev: https://dev.kairo.jinkendo.de · nach Deploy Migration 030 + A1-Slice

---

1. Zweck

Dieses Register hält PO-Beobachtungen aus der MVP-Validation fest und ordnet sie architektonisch ein:

Kategorie	Bedeutung
Bug	Abweichung vom aktuellen Soll (Spec + gelieferte Architektur) — Fix ohne ADP
Config-Drift	Inkonsistenz innerhalb der Plugin-/Profile-Schicht (kein Modellbruch)
Implementierungsschuld	Architektur und Spec stimmen; Code liefert Teilmenge
Aufgeschoben (Spec)	Explizit in Archetyp-/Methoden-Spec oder ADP als „später“ / Stufe B+
Architektur-Lücke	Zielmodell dokumentiert, tragfähige Basis fehlt oder widerspricht sich über Spec hinaus

Leitfrage des Reviews: Brauchen wir ein neues Architektur-Design, oder ist die Plugin-/Kernel-Schicht korrekt und es fehlen Slices?

---

2. Architektur-Urteil (Stand nach A1-Smoke)

2.1 Kurzfazit (technisch)

Kein generelles Architektur-Design-Problem. Die vier Schichten (Methode → Archetyp → Profil → UI-Composition, AP2.3/AP2.4) tragen den A1-Happy-Path technisch.

2.1b PO-Produkturteil A1 (2026-07-28)

No-Go für echten Einsatz — unabhängig vom grünen E2E-Test.

Leitfrage lässt sich nicht sinnvoll beantworten. Für tagesbezogenes Tracking (durchgeführt; optional Messwerte wie Anzahl, 45°-Spagat), aktive Einschätzung des Gate-Fortschritts und übersichtliche Steuerung ist der Vorhabentyp unbrauchbar. Hürden > Nutzen.

Dimension	Technische Validation	PO-Produktnutzen
Happy Path (Anlage → Verify)	✓	◐ — nur Demo, kein Alltag
Leitfrage ≤2 Min (MVP §5.6)	—	✗
Tages-Tracking / Übung erledigen	✗	Blocker
Messgrößen / Metriken	✗	Blocker (PO)
Gate-Fortschritt sichtbar steuerbar	◐	✗
Übersichtlichkeit	◐	✗

Architektur-Einordnung: PO-Anforderungen stehen bereits in SPEC A1 / Spec-D (CadenceInstance, Tages-Übung, Kriterien, Metriken). Es fehlt nicht ein neues Design — es fehlt der Minimal-Slice für nutzbaren A1, der fälschlich als „post-MVP“ behandelt wurde.

Konsequenz AP2.1 / MVP Stufe A: A1 erfüllt nicht die MVP-Nutzbarkeits-Bar §5 für PO-Abnahme. Gesamt-Go Stufe A blockiert, solange A1 Pflicht-Szenario bleibt (Kairo_MVP_Definition_v0.3.md §4).

Die Validation zeigt drei Lückentypen:

(1) Config-Drift     planOutlineKeys ≠ dataSlices          → schneller Fix
(2) Spec-Deferred    CadenceInstance, Alternanz, metric    → geplant, Spec §11
(3) Polymorphie-Gap  Kernel Q2 Work-Items: BE ja, FE nein  → Implementierungsschuld

2.2 Referenz-Architektur (Prüfmaßstab)

Dokument	Rolle
ADP_Archetype_Method_Plugin_Architecture_v0.1.md	Route Gating, Slices, kein Page-If
SPEC_A1_maturity_journey_v0.1.md §4, §8, §11	A1-Fachmodell + Ist-Stand-Tabelle
methods/SPEC_D_maturity_progression_v0.1.md D4–D6	Leading = CadenceInstance; Ranking
ADP_Roadmap_Graph_and_Gate_Checklist_v0.1.md	Kriterien, Evidence, metric später
Kairo_Steering_Method_Kernel_v0.1.md Q2	Work-Item-Polymorphie
Kairo_Steering_Method_Normalization_Program_v0.1.md	CadenceInstance als Normalform

2.3 Was nicht neu designt werden muss

• Archetyp ↔ Methode ↔ UI-Profil (Operating Context)
• Gate-Verify + Kriterien-Checkliste (AP1.4b)
• Stufenwechsel + Recurring-Rotation (AP2.0e)
• Composition-Slots (maturity_stage, recurring_rhythm, work.today)

---

3. Findings — Szenario A1 (Spagat / Reifegrad)

PO-Validation: 2026-07-28 · Vorhaben „Spagat können“ · initiative.maturity_journey
Urteil A1: No-Go (Produkt) · technischer Kernpfad ✓ · MVP §5 für PO ✗

ID	PO-Beobachtung	Kategorie	Architektur-Urteil	MVP Stufe A	Follow-up
F-A1-01	Klick Plan → Eingang leitet auf Zielzustände um	Config-Drift	planOutlineKeys enthält inbox, dataSlices ohne backlog → Route Gating korrekt, Nav falsch. Kein Modellproblem. Spec A1 §8: Eingang „nicht dominant“.	Mitverantwortlich Unübersicht	Fix: inbox aus planOutlineKeys bei initiative.maturity_journey
F-A1-02	Keine Konfiguration Wochentage / Rhythmus; kein Tages-Tracking („heute erledigt“)	Implementierungsschuld (Spec-Pflicht)	Spec A1 §4.3–4.5 + Spec-D D4: CadenceInstance. Code: nur RecurringElement + Fälligkeit. Kein Designbruch — fehlender Kern-Slice.	PO-Blocker	AP A1-Cadence-MVP: Instanz + „heute erledigt“
F-A1-03	Ausführen: AP statt Übung; Rhythmus-Link tot; AP nicht öffenbar	Implementierungsschuld	Kernel Q2: Leading = CadenceInstance; FE verlinkt nur Actions.	PO-Blocker	AP A1-Work-UI
F-A1-04	Kriterien auto-erfüllt via Evidence; keine laufende Gate-Einschätzung	By Design + Lücke UX	AP1.4b korrekt für Verify-Moment; PO braucht Fortschrittsbild während Stufe (Spec A1 §8 Kontrolle).	PO-Blocker (Einschätzung)	Fortschritts-Panel + manuelle/metric Kriterien
F-A1-05	Keine Messung (4×/Woche, 80 Punkte, 45° Spagat, …)	Implementierungsschuld (Spec vorbereitet)	criterion_kind: metric + Cadence-Erfüllung geplant; keine Engine. Schema reicht — Feature fehlt, kein ADP neu.	PO-Blocker	Messwert am Tagesabschluss + optional metric-Kriterium
F-A1-06	Keine kontinuierliche Fortschrittskontrolle in der Stufe	Implementierungsschuld	Plan/Ist-Trennung korrekt; Ist-Tracking für Übungen fehlt (CadenceInstance).	PO-Blocker	Teil A1-Cadence-MVP
F-A1-07	Nach Verify keine AP-Aktivierung; nur Recurring rotiert	Implementierungsschuld	Spec A1 §4.4 Activity Set — Scope AP2.0e minimal.	Sekundär vs. F-A1-02–06	AP A1-Activity-Set
F-A1-08	Journey unklar; pausierte Übung verwirrend	IA	Technisch korrekt (AP2.0e); PO wahrgenommene Unübersicht.	Mitverantwortlich	IA A1 Today-first
F-A1-09	Leitfrage nicht beantwortbar — Hürden > Nutzen	PO-Produkturteil	MVP §5.6 nicht erfüllt. Symptom von F-A1-02…05, nicht Doku-Problem.	No-Go	siehe §8 Minimum-Slice
F-A1-10	Extreme Unübersichtlichkeit (Eingang-Redirect, AP vs. Übung, Journey vs. Rhythmen)	IA + Implementierungsschuld	Plugin-Architektur OK; A1-Profil und Work-Default spiegeln Nutzerbild Spec §8 nicht. Kein neues OM nötig — falsche/fehlende UI-Hülle.	PO-Blocker	A1-IA-Slice (Eingang weg, Today=Übung, klare Stufenleiste)

---

4. Detail-Notizen (Architektur-Check)

F-A1-01 — Eingang vs. Slices

ui_profiles.py  initiative.maturity_journey:
  planOutlineKeys: [profile, gates, inbox, work]   ← Nav zeigt Eingang
  dataSlices:      [actions, roadmap, recurring, …]  ← kein "backlog"

viewRegistry.js   /plan/inbox  requiredSlices: ['backlog']
→ isRouteAllowedForMode = false → Redirect planDefaultRoute (/plan/gates)

Urteil: Plugin-Architektur funktioniert wie designed; Profil-Seed ist inkonsistent.

F-A1-02 / F-A1-06 — CadenceInstance-Schicht

Schicht	Spec	Code heute
RecurringElement	Container + Bindung Stufe	✓
Cadence / Wochentage / Alternanz	Spec A1 §4.3–4.5	✗
CadenceInstance (eine offene Instanz)	Spec-D D4, Kernel Q2	✗ (nur next_due_at am Element)
Erfüllung → nächste Instanz	Spec A1 Happy Path §9.3	◐ (manuell / overdue-Logik minimal)

Urteil: Kein falsches Design — Normalization-Programm beschreibt Ziel; MVP lieferte Minimal-Rhythmus. Spec A1 §11 listet das explizit als Lücke.

F-A1-03 — Work-Item-Polymorphie (Kernel Q2)

Work Item	Next Action BE	Next Action FE Link
Action	✓	✓
Backlog	✓	✓
Recurring / Cadence	✓ (recurring_due)	✗ (nur Text recommended_action)

Urteil: Architektur-Lücke nur in der Präsentationsschicht — Steering-Kernel und Strategies sind erweiterbar; FE muss polymorphe Ziele unterstützen (Link-Typ-Registry analog Backend kind).

F-A1-04 / F-A1-05 — Kriterien & Metriken

• Evidence → satisfied: beabsichtigt (roadmap_criteria.prepare_criteria_for_verify).
• Manuelle Kriterien: bleiben offen bis manuell / waived — korrekt.
• Metriken: Schema vorbereitet, keine Regel-Engine — ADP „später“.

Urteil: Gate-Modell ist generisch genug; fehlende Metrik-Auswertung ist Feature-Deferral, kein Redesign.

F-A1-07 — Activity Set bei Stufenwechsel

maturity_stage_transition.on_maturity_stage_reached:

• pausiert aktive Recurring ✓
• aktiviert nächste Stufe ✓
• legt neue Recurring-Übung an ✓
• keine Stage-Actions, keine Graph-Aktivierung weiterer Plan-APs

Spec A1 §4.4 verlangt volles Set — Implementierungsschuld, Scope AP2.0e war Minimal-Slice.

---

5. Abgleich mit SPEC_A1 §11 (Ist-Stand-Tabelle)

Spec §11 Zeile	Validation bestätigt
Multi-Übung / Alternanz fehlt	F-A1-02 ✓
Stage Activity Set Teilmenge	F-A1-07 ✓
UI Stufe-Detail lückenhaft	F-A1-02, F-A1-03 ✓
steering_elements FE/BE Parität	F-A1-03 (recurring in Kontrolle ✓, Work ◐)

Keine neue Spec-Zeile nötig — Register präzisiert PO-Sicht für AP2.1.

Urteil: Kein falsches Design — PO-Anforderung = Spec §4 / Spec-D. MVP lieferte Infrastruktur ohne Ist-Schicht. Für PO-Abnahme ist das kein „später“, sondern fehlender A1-Kern.

F-A1-09 / F-A1-10 — PO-Leitfrage & Unübersichtlichkeit

PO (2026-07-28, wörtlich zusammengefasst):

• Leitfrage nicht sinnvoll beantwortbar
• Tages-Tracking + optional Messwerte (Anzahl, Grad, …) + aktive Gate-Einschätzung erforderlich für echten Einsatz
• Extreme Unübersichtlichkeit → Hürden größer als Nutzen

Architektur: Symptome von fehlendem CadenceInstance-Modell, Work-UI auf AP statt Übung, IA-Rauschen (Eingang, Journey). Kein Widerspruch zwischen Vision und Spec — Widerspruch zwischen geliefertem MVP-Slice und PO-Mindestnutzen.

---

6. Priorisierte Follow-ups (PO-gesteuert)

6.1 A1 Minimum Usability Slice (vor erneuter A1-Abnahme)

Implementiert (2026-07-28, uncommitted): Migration 030, cadence_instance + POST /api/recurring/{id}/complete, WorkTodayPracticePanel, Next-Action-Link #today-practice, Gate-Fortschritt in MaturityStagePanel, Eingang aus A1-Nav. Offen: PO Re-Abnahme; Metric-Kriterium manuell (Slice #5, optional vor Re-Test).

#	Lieferung	Decke PO-Schmerz	Status
1	CadenceInstance + „Heute erledigt“	Tages-Tracking	✓ implementiert
2	Ausführen/Today = Übung	Nutzen Alltag	✓ implementiert
3	Kontrolle: Gate-Fortschritt	Gate-Einschätzung	✓ implementiert (Kriterien offen/erfüllt)
4	IA A1 (Eingang weg)	Unübersichtlichkeit	✓ implementiert
5	Metric-Kriterium manuell	Messgrößen	◐ Messnotiz am Complete; Auto-Engine weiter offen

Alternanz, volle Metric-Engine, Activity-Set-Automation → nach Slice 1–4.

6.2 Technische Quick-Wins (P0)

Prio	ID	Slice
P0	F-A1-01	Eingang aus A1-Nav
P1	F-A1-03	Next Action → Recurring/Übung-Aktion

---

7. Konsequenz für AP2.1 / MVP Stufe A

Option	Bedeutung	PO 2026-07-28
A — A1 nachziehen	Minimum Slice liefern	◐ Cadence done; Progressions-IA offen
B — MVP-Definition anpassen	A1 aus Stufe-A-Abnahfe	nicht gewählt
C — Spec schärfen, dann implementieren	PO-Lock vor Coding	✓ gewählt

PO-Lock (Option C): docs/product/archetypes/SPEC_A1_Progression_Model_PO_Lock_v0.1.md

Kernentscheide:

• Parallele Gates + Gate-Graph + Join-Gates (Lanes graph-abgeleitet — ADP A1 Lanes v0.1)
• Horizon: mehrere aktive Gates (nicht eine Stufe initiative-weit)
• Übung = RecurringElement am Gate (roadmap_item_id); Rhythmus = Feld
• A1 Go MVP: ≥2 parallele Gates + 1 Join + Gate-Activity-Set + Today — nicht nur Spagat-Demo

Validation A1: Re-Abnahme gemäß Sprint1_AP2_1_MVP_Validation_Report_v0.3.md §3.5 (Progressionsmodell, ohne Starter-Kit). A2/B2b-Smoke parallel möglich.

---

8. Nächste Register-Einträge

Szenario	Status
A2 — Neue Küche (Linear)	ausstehend
B2b + B3 — Product + Sprint	ausstehend
Portfolio / Cockpit (Kriterium 7)	ausstehend

---

Aktualisieren bei jedem PO-Smoke-Schritt. Bei Kategorie „Architektur-Lücke“ → ADP prüfen, nicht sofort implementieren.