# AP0.8 – Abschlussbericht Operating Model Extension I

**Status:** abgeschlossen (Implementierung) · QA mit DB ausstehend  
**Stand:** 2026-07-05  
**Version:** Backend/Frontend `0.8.0-ap0.8` · Schema `007`  
**Auftrag:** `Sprint0_AP0_8_Assignment_v0.2.md` (abgeglichen mit System Target State v0.1)

---

## 1. Scope und Einordnung

AP0.8 ist der erste fachliche Ausbau nach dem Product Reset. Er operationalisiert die Leitfrage über regelbasierte Attention/NextAction und erweitert das Domänenmodell um Blocker, BacklogItem und Milestone.

Einordnung in der Evolutionslinie (System Target State §24):

- Foundation ✓ (AP0.7)
- **Signal / NextAction Engine — erste Instanz** ✓ (AP0.8a, Data Layer)
- Operating Model Phase A ✓ (Blocker, Backlog, Milestone)
- SteeringContext / Method Registry — bewusst **nicht** in AP0.8

---

## 2. Definition of Done — Prüfmatrix

| Kriterium | Ergebnis | Nachweis |
|-----------|----------|----------|
| Migration 007 | ✓ | `007_operating_model_extension_i.sql` |
| Attention Regeln 1–6 | ✓ | `data_layer/attention.py` |
| NextActionCandidates | ✓ | `get_next_action_candidates` |
| Blocker CRUD | ✓ | `services/blockers.py`, Router |
| Backlog CRUD + Convert | ✓ | `services/backlog.py` |
| Milestone CRUD | ✓ | `services/milestones.py` |
| AttentionWidget | ✓ | `widgets/AttentionWidget.jsx` |
| Initiative-Detail Sektionen | ✓ | Blockers/Backlog/Milestones |
| 25 Capabilities | ✓ | `operating_model_ops.py` |
| Frontend Vitest + Build | ✓ | 9/9, build grün |
| Backend pytest | ⏳ Remote | Gitea `test.yml` nach Push auf `develop` (Pi, Container) |
| Kein KI/MCP/Steering | ✓ | Scope eingehalten |

---

## 3. Migration 007

Tabellen: `blockers`, `backlog_items`, `milestones` — alle mit `tenant_id`, FK RESTRICT/CASCADE wie AP0.5.

---

## 4. Attention / NextActionCandidate

- Datei: `backend/data_layer/attention.py`
- API: `GET /api/workspace/attention`, `GET /api/workspace/next-actions`
- Regeln: blocked_action, open_blocker, high_priority (personal), unassigned, initiative_without_next_action, stale_initiative, milestone_at_risk
- DTOs mit `reason_code`, `scope_type`, `data_source` (Erklärbarkeit gemäß System Target State §17)

---

## 5. Blocker

- Service + nested/flat API
- Audit: `blocker.created/updated/status_changed/deleted`
- Optional: `set_action_blocked` bei Create

---

## 6. BacklogItem

- Getrennt von Actions (RoadmapItem/Backlog/Action-Unterscheidung)
- Convert-to-action mit Audit `backlog.converted_to_action`

---

## 7. Milestone minimal

- MVP-Brücke (langfristig RoadmapItem — AD-TA-08)
- Attention-Regel 6 für `at_risk`

---

## 8. Data Layer Erweiterung

Neu: `attention.py` — Read-only, tenant-scoped, keine Router-SQL.

---

## 9. API-Endpunkte

Siehe README AP0.8-Tabelle.

---

## 10. Capabilities

7 neue: `kairo.attention.read`, `kairo.blocker.*`, `kairo.backlog.*`, `kairo.milestone.*`  
Gesamt: 25

---

## 11. Frontend-Integration

- `AttentionWidget` (order 8, capability `kairo.attention.read`)
- `BlockersSection`, `BacklogSection`, `MilestonesSection` im Vorhaben-Detail
- Status-Badges erweitert für blocker/backlog/milestone

---

## 12. Tests und Verifikation

| Test | Status |
|------|--------|
| `test_ap08_operating_model.py` | 14 Tests — Lauf auf Pi via `test.yml` |
| `test_rights_registry.py` | aktualisiert (25 Capabilities) |
| `test_migrations.py` | Migration 007 ergänzt |
| `conftest.py` | Session-Guard: skip lokal ohne DB, kein Migrations-Timeout |
| Vitest | 9/9 grün (lokal) |
| `vite build` | grün (lokal) |

**Verifikation:** Push auf `develop` → `deploy-dev.yml` + `test.yml` (pytest im Backend-Container gegen PostgreSQL im Compose-Stack).

---

## 13. Abweichungen von diesem Auftrag

| Punkt | Abweichung |
|-------|------------|
| Auftrag v0.1 | Ersetzt durch v0.2 nach Abgleich System Target State |
| Attention DTO | Zusätzlich `scope_type`, `data_source`, Regel 1b open_blocker |
| NextAction DTO | Explizit dokumentiert und implementiert |
| Milestone API target_date | Router akzeptiert ISO-Date-String |

Keine fachlichen Scope-Abweichungen.

---

## 14. Offene Punkte für AP0.9

- Evidence, Decision, Review, RecurringElement
- Action-Status `ready`, `review_required`
- Due Dates auf Actions + Attention Regeln 7–9
- Attention-Refactor in `backend/steering/signals/` (wenn Steering Core startet)

---

## 15. Empfehlung für AP0.10 / Validation

Nach AP0.9 ein reales Testvorhaben durchspielen (Backlog → Action → Blocker → Meilenstein → Attention). Milestone→RoadmapItem-Konsolidierung als ADP vor Phase C klären.

---

*Implementierung abgeschlossen — Backend-pytest und Smoke auf dem Pi nach Push auf `develop`.*