diff --git a/docs/product/Kairo_Implementation_Truth_Table_v0.1.md b/docs/product/Kairo_Implementation_Truth_Table_v0.1.md
index 432b1c1..5d852e2 100644
--- a/docs/product/Kairo_Implementation_Truth_Table_v0.1.md
+++ b/docs/product/Kairo_Implementation_Truth_Table_v0.1.md
@@ -176,7 +176,7 @@ Verhindert, dass Zielbild-Dokumente als Ist-Stand gelesen werden.
 | maturity / sequential / queue / recurring Strategien | ✓ | AP2.0d; pytest + Deploy |
 | Referenz-Ausprägungen (Kumite, Buch, Kairo) | ◐ | Code-Registry; Nutzer wählt bei Anlage |
 | Archetyp Starter-Kits | ◐ | AP2.2a |
-| MVP-Abnahfe Stufe A validiert | ✗ | AP2.1 nach AP2.2b–e |
+| MVP-Abnahfe Stufe A validiert | ◐ | AP2.1: Report v0.3 + Assignment — PO-Validation auf Dev ausstehend |
 | Operational Actor API | ✓ | AP1.7: `/api/operational/` + Service Tokens |
 | Actor Service Token | ✓ | AP1.7c; Tenant-scoped, capability-gebunden |
 | MCP produktiv | ✗ | nach AP2.1 Go |
@@ -234,7 +234,7 @@ Details: `Kairo_Status_Review_and_Next_Steps_v0.1.md` §2.1
 | AP2.2c | A1 Reifegrad E2E ✓ (2026-07-27) |
 | AP1.9d | Work-Composition + Drill-down ◐→✓ (2026-07-27) |
 | AP2.2c–e | Referenz-Archetypen End-to-End ◐→✓ |
-| AP2.1 | MVP-Abnahfe ✗→✓ |
+| AP2.1 | MVP-Abnahfe ◐→✓ (Report v0.3 + Assignment 2026-07-28; PO-Smoke auf Dev) |
 | AP1.7b | Op-API Parität ◐→✓ (2026-07-27) |
 
 ---
diff --git a/docs/product/Kairo_MVP_Execution_Plan_v0.2.md b/docs/product/Kairo_MVP_Execution_Plan_v0.2.md
index 32a5132..21dc2e9 100644
--- a/docs/product/Kairo_MVP_Execution_Plan_v0.2.md
+++ b/docs/product/Kairo_MVP_Execution_Plan_v0.2.md
@@ -2,7 +2,7 @@
 ## MVP Execution Plan v0.2
 
 **Status:** PO-Kurskorrektur — **führend für Implementierung ab 2026-07-12**  
-**Stand:** 2026-07-25 (AP2.3/AP2.4 Plugin-Architektur ✓)  
+**Stand:** 2026-07-28 (Phase 5 AP2.1 — Validation-Artefakte bereit)  
 **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)  
 **Spezifikationsphase (ab 2026-07-24/25):**  
 - Decision-Lock: `Kairo_Archetype_Decision_Lock_Interview_2026-07-25.md`  
@@ -84,7 +84,7 @@ Phase 3   AP2.2b  A2 Linear End-to-End                             ✓
           AP2.2d  B2b Product + B3 Sprint                          ✓
           AP2.2e  B2a Programm (optional vor AP2.1)
 Phase 4   AP1.7b  Operational API — Pflege-Parität                    ✓
-Phase 5   AP2.1   Validation Report v0.3 (alle Stufe-A-Szenarien)
+Phase 5   AP2.1   Validation Report v0.3 (alle Stufe-A-Szenarien)     ◐ PO
 Phase 6   AP2.2f  Stufe B: A3, B1, D1
 Phase 7   Schicht 4: Gitea-Webhook, MCP (nach AP2.1 Go)
 ```
@@ -131,17 +131,23 @@ Auth: Actor Service Token (Tenant-scoped). Kein Gate-Verify, kein Lifecycle-Over
 
 ## 7. AP2.1 Validation (nach Stufe-A-Flows)
 
+**Status:** Artefakte bereit (2026-07-28) — **PO-Smoke auf Dev ausstehend**  
+**Dev:** https://dev.kairo.jinkendo.de (`0.20.2-ap2.2d`, schema 025)
+
 **Nicht:** ein Dogfooding-Vorhaben auf Pi.  
 **Sondern:** PO füllt Report mit **echten, in der UI angelegten** Referenz-Vorhaben:
 
 - A1 (Reifegrad)
 - A2 (Linear)
-- B2b (+ optional B3 Zeitbox)
-- D1 wenn Stufe B bis dahin fertig
+- B2b (+ B3 Sprint minimal)
+- D1 optional (Stufe B)
 
-Vorlage: `docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` (neu bei AP2.1)
+| Artefakt | Pfad |
+|----------|------|
+| Auftrag (Ablauf, Go-Kriterien) | `docs/sprints/Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md` |
+| Report (ausfüllen) | `docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` |
 
-Go-Kriterium: MVP v0.3 §5 — pro Stufe-A-Archetyp Leitfrage ≤2 Min + Next Action begründet.
+Go-Kriterium: MVP v0.3 §5 — pro Stufe-A-Archetyp Leitfrage ≤2 Min + Next Action begründet; Portfolio Cockpit-Attention (Kriterium 7).
 
 ---
 
diff --git a/docs/sprints/Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md b/docs/sprints/Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md
new file mode 100644
index 0000000..c511b77
--- /dev/null
+++ b/docs/sprints/Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md
@@ -0,0 +1,125 @@
+# AP2.1 — MVP Validation (Stufe A)
+## Auftrag v0.1
+
+**Status:** freigegeben  
+**Stand:** 2026-07-28  
+**Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–8, `Kairo_MVP_Execution_Plan_v0.2.md` §7  
+**Output:** ausgefüllter `Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` + Go/No-Go
+
+---
+
+## 1. Ziel
+
+Kairo ist **MVP-abnahmefähig (Stufe A)**, wenn ein PO **vier Referenz-Szenarien** in der **UI auf Dev** durchspielt und dokumentiert — **ohne** Dogfooding-Seed, **ohne** vorbefüllte Demo-Daten.
+
+**Leitfrage (pro Vorhaben, ≤2 Minuten):**
+
+> Welcher nächste Schritt bringt dieses Vorhaben **jetzt** am wirksamsten voran — und **warum**?
+
+---
+
+## 2. Abnahfe-Umfang (Stufe A)
+
+| ID | Szenario | Archetyp | Methode | Pflicht |
+|----|----------|----------|---------|---------|
+| **A1** | Spagat können | `initiative.maturity_journey` | `maturity_progression` | ✓ |
+| **A2** | Neue Küche | `initiative.linear_project` | `sequential_dependency` | ✓ |
+| **B2b** | Product-Betrieb (z. B. Kairo selbst) | `initiative.product` | `continuous_product` | ✓ |
+| **B3** | Sprint-Zeitbox auf B2b | Profil `agile_iteration` | `work_cycle` | ✓ minimal |
+| D1 | Buch schreiben | Stufe B | — | optional (nicht MVP-Blocker) |
+
+**B3** wird im **selben** Product-Vorhaben wie B2b geprüft (kein eigener Archetyp).
+
+---
+
+## 3. Umgebung
+
+| | |
+|---|---|
+| **Dev-Instanz** | [https://dev.kairo.jinkendo.de](https://dev.kairo.jinkendo.de) |
+| **Health** | `GET /api/health` |
+| **Branch** | `develop` (nach letztem Deploy) |
+| **CI-Referenz** | Gitea Actions `test.yml` — E2E-Tests als technische Vorprüfung |
+
+**Regeln:**
+
+- Vorhaben **neu in der UI anlegen** (Starter-Kit optional aktivieren)
+- **Kein** `seed_004` / Dogfooding als Abnahme-Shortcut
+- Screenshots oder Initiative-IDs im Report notieren
+
+---
+
+## 4. Ablauf pro Szenario (~20–30 Min)
+
+1. **Anlegen** — Archetyp wählen, Starter-Kit, Scope setzen
+2. **Struktur** — Stufen / Gates / Sprint anlegen (methodenabhängig)
+3. **Ist committen** — mindestens 1–2 Arbeitspakete; bei B2b: Backlog → Sprint
+4. **Kontrolle** — Lagebild: Methode, Next Action (1–3), Begründung, keine Todo-Wand
+5. **Ausführen** — Default-Route (Heute / Sprint) zeigt Steuerung, nicht Gesamtliste
+6. **Journey** — min. ein steuerungsrelevantes Event sichtbar
+7. **Leitfrage** — PO beantwortet schriftlich in ≤2 Min (Stopuhr)
+8. **Anti-Patterns** — explizit prüfen (§7 MVP v0.3)
+
+Detaillierte Schritte: Abschnitt 6 in `Sprint1_AP2_1_MVP_Validation_Report_v0.3.md`.
+
+---
+
+## 5. Go-Kriterien (verbindlich)
+
+### Pro Archetyp (A1, A2, B2b+B3)
+
+| # | Kriterium (MVP v0.3 §5) | Go |
+|---|------------------------|-----|
+| 1 | Anlage + Default-Methode + Profil | ☐ |
+| 2 | Passende Struktur modellierbar | ☐ |
+| 3 | Ist committet (nicht alles gleichzeitig sichtbar) | ☐ |
+| 4 | Kontrolle: Next Action **begründet** | ☐ |
+| 5 | Journey nachvollziehbar (≥1 Event) | ☐ |
+| 6 | Leitfrage ≤2 Min **ohne CRUD-Wand** | ☐ |
+
+### Portfolio
+
+| # | Kriterium | Go |
+|---|-----------|-----|
+| 7 | Cockpit: Attention pro Vorhaben, nicht Task-Details | ☐ |
+
+### Gesamt-Go
+
+- **Go Stufe A:** alle Pflicht-Szenarien (A1, A2, B2b+B3) + Kriterium 7 = ja
+- **Bedingt:** ≤1 Szenario mit dokumentierter Lücke + Workaround + Fix-AP
+- **No-Go:** Leitfrage nicht beantwortbar oder Todo-Explosion als Hauptbild
+
+---
+
+## 6. Technische Vorprüfung (Agent/CI — kein PO-Ersatz)
+
+| Paket | Test-Datei | Szenario |
+|-------|------------|----------|
+| AP2.2a | `test_ap22a_starter_kit.py` | Kits A1, A2, B2b |
+| AP2.2b | `test_ap22b_linear_e2e.py` | A2 Küche Happy Path |
+| AP2.2c | `test_ap22c_maturity_e2e.py` | A1 Spagat + Stufenwechsel |
+| AP2.2d | `test_ap22d_sprint_backlog.py` | B2b Backlog → Sprint |
+
+Grüne CI-Tests sind **notwendig**, aber **nicht hinreichend** für AP2.1 Go.
+
+---
+
+## 7. Deliverables
+
+| Artefakt | Pfad |
+|----------|------|
+| Report (ausfüllen) | `docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md` |
+| Truth Table | `AP2.1` Zeile nach Go aktualisieren |
+| Execution Plan | Phase 5 als ✓ markieren |
+
+---
+
+## 8. Nach Go
+
+- Merge `develop` → `main` (Prod-Deploy) erst nach **PO Go Stufe A**
+- Template/Blueprint-Konzeption (AP-BP-0) parallel, nicht MVP-Blocker
+- Stufe B (A3, B1, D1) erst nach AP2.1 Go planen
+
+---
+
+*Vorlage Report: `Sprint1_AP2_1_MVP_Validation_Report_v0.3.md`*
diff --git a/docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md b/docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md
new file mode 100644
index 0000000..36753cc
--- /dev/null
+++ b/docs/sprints/Sprint1_AP2_1_MVP_Validation_Report_v0.3.md
@@ -0,0 +1,243 @@
+# AP2.1 — MVP Validation Report
+## v0.3 (Stufe A)
+
+**Status:** Entwurf — vom Product Owner auszufüllen  
+**Stand:** 2026-07-28  
+**Bezug:** `Kairo_MVP_Definition_v0.3.md` §5–8  
+**Assignment:** `Sprint1_AP2_1_MVP_Validation_Assignment_v0.1.md`
+
+| Feld | Wert |
+|------|------|
+| **Kairo-Version / Deploy** | |
+| **Dev-URL** | https://dev.kairo.jinkendo.de |
+| **Branch / Commit** | `develop` @ |
+| **Tester (PO)** | |
+| **Testdatum** | |
+
+---
+
+## 1. Executive Summary
+
+| Entscheidung | ☐ Go Stufe A · ☐ Bedingt · ☐ No-Go |
+|--------------|-------------------------------------|
+
+**Kurzfazit (3–5 Sätze):**
+
+
+**Blocker (falls No-Go / Bedingt):**
+
+
+---
+
+## 2. Portfolio (Kriterium 7)
+
+**Leitfrage Portfolio:** *Welches Vorhaben braucht jetzt welche Art von Attention?*
+
+| Check | ja/nein | Notiz |
+|-------|---------|-------|
+| Cockpit zeigt Vorhaben mit Attention-Signal (nicht Task-Listen) | | |
+| Unterschiedliche Vorhabenarten parallel erkennbar | | |
+| Drill-down zu Details nur bewusst | | |
+| Leitfrage Portfolio ≤2 Min | | |
+
+---
+
+## 3. Szenario A1 — Spagat können (Reifegrad)
+
+**Initiative-ID / Titel:**  
+**Archetyp:** `initiative.maturity_journey` · **Methode:** `maturity_progression`
+
+### 3.1 Smoke-Schritte (Dev)
+
+| # | Schritt | Route | erledigt |
+|---|---------|-------|----------|
+| 1 | Vorhaben „Spagat können“ anlegen, Starter-Kit | Vorhaben → Neu | ☐ |
+| 2 | Operating Context: `maturity_stage`, `recurring_rhythm` | API oder Kontrolle | ☐ |
+| 3 | Kontrolle: Stufen-Panel + Rhythmen + Next Action | `/control/status` | ☐ |
+| 4 | Ausführen: Next Action sichtbar, Liste eingeklappt | `/work/today` | ☐ |
+| 5 | Evidence an Stufe 1, Verify → Stufe 2 aktiv | Plan → Stufen / Journey | ☐ |
+| 6 | Recurring rotiert (alte Übung pausiert, neue aktiv) | Kontrolle / Rhythmen | ☐ |
+| 7 | Journey zeigt Stufen-Event | `/control/journey` | ☐ |
+
+**Technische Referenz:** `backend/tests/test_ap22c_maturity_e2e.py`
+
+### 3.2 MVP-Nutzbarkeits-Bar (§5)
+
+| # | Kriterium | ja/nein | Notiz |
+|---|-----------|---------|-------|
+| 1 | Anlage + Default-Methode | | |
+| 2 | Stufen + Recurring strukturiert | | |
+| 3 | Ist committet (Übung/Routine, nicht 200 Tasks) | | |
+| 4 | Kontrolle: Next Action begründet (Rhythmus/Stufe) | | |
+| 5 | Journey ≥1 Event | | |
+| 6 | Leitfrage ≤2 Min ohne Listen-Wand | | |
+
+### 3.3 Leitfrage-Antwort (PO, ≤2 Min)
+
+**Nächster Schritt:**  
+**Warum:**  
+**Stopuhr (Min):**
+
+### 3.4 Anti-Patterns (§7)
+
+| Verboten | aufgetreten? | Notiz |
+|----------|--------------|-------|
+| Flache Liste aller Übungs-Tasks als Hauptbild | ☐ ja ☐ nein | |
+| Recurring im Action-Backlog statt Rhythmus-Ansicht | ☐ ja ☐ nein | |
+
+**Lücken / UX-Schmerz:**
+
+
+---
+
+## 4. Szenario A2 — Neue Küche (Linear)
+
+**Initiative-ID / Titel:**  
+**Archetyp:** `initiative.linear_project` · **Methode:** `sequential_dependency`
+
+### 4.1 Smoke-Schritte (Dev)
+
+| # | Schritt | Route | erledigt |
+|---|---------|-------|----------|
+| 1 | Vorhaben „Neue Küche“ anlegen, Starter-Kit | Vorhaben → Neu | ☐ |
+| 2 | Gate-Kette G1–G4, G1 aktiv | Plan → Zielzustände | ☐ |
+| 3 | Projekte Hauptpfad + Begleitung vorhanden | Plan | ☐ |
+| 4 | Kontrolle: Kritischer Pfad + Next Action | `/control/status` | ☐ |
+| 5 | Ersten Schritt erledigen → nächster ready am Pfad | Ausführen / AP-Detail | ☐ |
+| 6 | Gate-Verify / reached wo sinnvoll | Plan / Gates | ☐ |
+| 7 | Ausführen: Steuerung, nicht alle Handwerker-Tasks | `/work/today` | ☐ |
+
+**Technische Referenz:** `backend/tests/test_ap22b_linear_e2e.py`
+
+### 4.2 MVP-Nutzbarkeits-Bar (§5)
+
+| # | Kriterium | ja/nein | Notiz |
+|---|-----------|---------|-------|
+| 1 | Anlage + sequential_dependency | | |
+| 2 | Gate-Kette + Abhängigkeiten | | |
+| 3 | APs committet, nicht Backlog-Wand | | |
+| 4 | Kontrolle: kritischer Pfad / ready Schritt begründet | | |
+| 5 | Journey / Gate-Fortschritt sichtbar | | |
+| 6 | Leitfrage ≤2 Min | | |
+
+### 4.3 Leitfrage-Antwort (PO)
+
+**Nächster Schritt:**  
+**Warum:**  
+**Stopuhr (Min):**
+
+### 4.4 Anti-Patterns
+
+| Verboten | aufgetreten? | Notiz |
+|----------|--------------|-------|
+| Alle Handwerker-Schritte als flache Todo-Liste | ☐ ja ☐ nein | |
+| Gate nur Status-Dropdown ohne Steuerung | ☐ ja ☐ nein | |
+
+**Lücken:**
+
+
+---
+
+## 5. Szenario B2b + B3 — Product + Sprint
+
+**Initiative-ID / Titel:**  
+**Archetyp:** `initiative.product` · **Methode:** `continuous_product` (+ optional `agile_iteration`)
+
+### 5.1 Smoke-Schritte B2b (Dev)
+
+| # | Schritt | Route | erledigt |
+|---|---------|-------|----------|
+| 1 | Product-Vorhaben anlegen (Starter-Kit) | Vorhaben → Neu | ☐ |
+| 2 | Eingang: Backlog-Item anlegen / triagieren | Plan → Eingang | ☐ |
+| 3 | Gate/Meilenstein als Orientierung | Plan → Zielzustände | ☐ |
+| 4 | Kontrolle: Next Action (Product-Horizont) | `/control/status` | ☐ |
+| 5 | Prozessleiste: Eingang → Sprint planen → Ausführen | Scope-Navigation | ☐ |
+
+### 5.2 Smoke-Schritte B3 (Sprint minimal)
+
+| # | Schritt | Route | erledigt |
+|---|---------|-------|----------|
+| 6 | Sprint anlegen (geplant oder aktiv) | Plan → Sprint | ☐ |
+| 7 | Backlog-Items in gewählten Sprint committen | Plan → Sprint (Checkbox / Vorschlag) | ☐ |
+| 8 | Sprint-Backlog sichtbar getrennt vom Product Backlog | Plan → Sprint / Ausführen → Sprint | ☐ |
+| 9 | Ausführen: Next Action im Sprint, Liste Drill-down | `/work/sprint` | ☐ |
+| 10 | Optional: Sprint abschließen / Carryover | Sprint-Panel | ☐ |
+
+**Technische Referenz:** `backend/tests/test_ap22d_sprint_backlog.py`, `test_ap22i_sprint_commit_proposal.py`
+
+### 5.3 MVP-Nutzbarkeits-Bar (§5)
+
+| # | Kriterium | ja/nein | Notiz |
+|---|-----------|---------|-------|
+| 1 | Anlage + continuous_product | | |
+| 2 | Eingang + Gates + Sprint-Struktur | | |
+| 3 | Product Backlog ≠ Sprint-Backlog ≠ committete APs | | |
+| 4 | Kontrolle: Next Action Gate **oder** Sprint begründet | | |
+| 5 | Journey / Sprint-Lifecycle Event | | |
+| 6 | Leitfrage ≤2 Min | | |
+
+### 5.4 Leitfrage-Antwort (PO)
+
+**Nächster Schritt:**  
+**Warum:**  
+**Stopuhr (Min):**
+
+### 5.5 Anti-Patterns
+
+| Verboten | aufgetreten? | Notiz |
+|----------|--------------|-------|
+| Alle APs aller Gates gleichzeitig in Hauptliste | ☐ ja ☐ nein | |
+| Sprint-Backlog = Product Backlog | ☐ ja ☐ nein | |
+| Ausführen zeigt Gesamtliste statt Sprint-Default | ☐ ja ☐ nein | |
+| Begriff „Zeitbox“ statt Sprint in UI | ☐ ja ☐ nein | |
+
+**Lücken:**
+
+
+---
+
+## 6. Querschnitt — Composition & Product Language
+
+| Check | ja/nein | Notiz |
+|-------|---------|-------|
+| MethodProcessBar zeigt Prozess (Product: Eingang→Sprint→Ausführen) | | |
+| Work-Modus: Next Action vor voller AP-Liste | | |
+| Begriffe konsistent (Sprint, Arbeitspaket, Eingang) | | |
+| Keine Archetyp-Ifs spürbar (Steuerung methodengebunden) | | |
+
+---
+
+## 7. Op-API (AP1.7b — Stichprobe)
+
+Optional: Agent/Service-Token gegen Dev.
+
+| Endpoint | funktioniert | Notiz |
+|----------|--------------|-------|
+| `GET /api/operational/initiatives/{id}/context` | ☐ | |
+| `GET /api/operational/next-action?initiative_id=` | ☐ | |
+| `POST /api/operational/backlog/{id}/convert-to-action` | ☐ | |
+
+---
+
+## 8. Abgeleitete Prioritäten (nach Validation)
+
+| Prio | Lücke | Fix-AP / Slice |
+|------|-------|----------------|
+| P0 | | |
+| P1 | | |
+| P2 | | |
+
+---
+
+## 9. Sign-off
+
+| Rolle | Name | Datum | Go Stufe A |
+|-------|------|-------|------------|
+| Product Owner | | | ☐ ja ☐ nein ☐ bedingt |
+
+**Bedingungen (falls bedingt):**
+
+
+---
+
+*Bei Go: Truth Table `AP2.1` → ✓, Execution Plan Phase 5 → ✓, dann Merge `develop` → `main` für Prod.*