# Architecture Decision Proposal — AP0.5 Scope-Verschiebung Sprint 0

**Status:** angenommen (Umsetzung abgeschlossen)  
**Stand:** 2026-07-05  
**Autor:** Sprint-0-Umsetzung (Cursor/Claude)  
**Commits:** `afa6815`, `a34a614`

---

## Problem

In `Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md` ist **AP0.5** als *Audit und minimale Admin-Prüfbarkeit* definiert. Gleichzeitig verbietet §13 *Vorhaben/Projektlogik in Sprint 0 vorziehen*; Sprint 1 sieht Vorhaben und Maßnahmen vor.

Für den ersten **fachlich nutzbaren Kairo-Slice** wurde AP0.5 bewusst neu beauftragt als *Minimaler Vorhaben- und Maßnahmen-Slice* (Migration 006, CRUD, Assignments, Capability-Gates, Tests).

Ohne dokumentierte Entscheidung entsteht ein **Nummerierungs- und Scope-Konflikt** zwischen Foundation-Dokument und Implementierung.

---

## Betroffene Regel

| Dokument | Regel |
|----------|--------|
| `Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md` § AP0.5 | Audit + Admin-Prüfbarkeit |
| `Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md` §13 | Keine Vorhaben/Projektlogik in Sprint 0 vorziehen |
| `Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md` §14 | Vorhaben/Maßnahmen in Sprint 1 |
| `Kairo_Sprint0_Principle_Gate_v0.1.md` G-01–G-12 | Architekturprinzipien (weiterhin verbindlich) |

---

## Optionen

| Option | Kurzbeschreibung | Pro | Contra |
|--------|------------------|-----|--------|
| A | Foundation-AP0.5 zuerst (Audit/Admin), Vorhaben in Sprint 1 | Entspricht Foundation 1:1 | Kein fachlicher End-to-End-Slice; Audit ohne Domäne schwer demonstrierbar |
| B | **AP0.5 = Vorhaben/Maßnahmen-Slice; Foundation-AP0.5 → AP0.6 umbenennen** | Erster nutzbarer Slice; Principle Gate eingehalten (Tenant, Actor, Capability, Audit) | Scope-Verschiebung; Foundation-Dokument veraltet bis Update |
| C | Vorhaben ohne AP-Nummer (Sprint-1-Vorgriff) | Schnell | Undokumentiert; verwirrt Sprint-Tracking |

---

## Empfehlung

**Option B** — angenommen und umgesetzt.

Begründung:

1. Der Slice ist **minimal** (keine Projects, Milestones, Programs, Reviews, KI).
2. **Principle Gate** bleibt eingehalten: Tenant-first, Actor-first, TenantContext, Capability Registry, nummerierte Migration, Audit.
3. Der ursprüngliche Foundation-AP0.5-Inhalt (granulares Audit, Admin-Routen) wird als **AP0.6** eingeplant — kein Verlust, nur Verschiebung.

---

## Risiko

| Risiko | Mitigation |
|--------|------------|
| Foundation-Dokument und Code divergieren | Dieses ADP + Abschlussbericht AP0.5 v0.2; Foundation-Update in separatem Doc-Pass |
| Sprint-1-Doppelarbeit | AP0.5 bewusst minimal; Meilensteine/Programme/Backlog bleiben Sprint 1 |
| Audit-Schema ohne `actor_id` | Bekannte Lücke seit AP0.2; AP0.6 kann Schema erweitern |

---

## Rückbaubarkeit

- Tabellen `initiatives`, `actions`, `action_assignments` sind additiv (Migration 006).
- Rückbau: neue Migration mit `DROP TABLE` — keine Änderung an AP0.1–0.4-Tabellen.
- Capabilities in `initiative_ops.py` können deaktiviert werden, ohne andere Module zu brechen.

---

## Auswirkung auf Sprint 0

| Thema | Auswirkung |
|-------|------------|
| Sprint-0-Fundament (AP0.1–0.4) | unverändert |
| AP0.5 (neu) | fachlicher Minimal-Slice Vorhaben/Maßnahmen |
| Foundation-AP0.5 (Audit/Admin) | **→ AP0.6** (empfohlen) |
| Sprint-0 DoD §12 | Vorhaben-Teil formal Sprint 1 — durch ADP begründete Ausnahme |
| Prod/Dev | Schema `006`; pytest 55/55 grün nach Cleanup-Seed-Fix |

---

## Nächste Schritte (Dokumentation)

1. ~~ADP (dieses Dokument)~~
2. ~~`docs/MIGRATIONS.md` um 006 ergänzen~~
3. ~~`Sprint0_AP0_5_Completion_Report_v0.2.md`~~
4. Foundation v0.4 (optional): AP-Nummern und §13/§14 angleichen