Kairo-Jinkendo/docs/architecture/ADP_AP0_5_Sprint0_Scope_Shift_v0.1.md
Lars 802c9259dc
All checks were successful
Deploy Development / deploy (push) Successful in 33s
Test Suite / pytest-backend (push) Successful in 29s
Test Suite / lint-backend (push) Successful in 2s
Test Suite / compose-smoke (push) Has been skipped
Test Suite / k6 /api/health Baseline (push) Successful in 18s
Test Suite / playwright-smoke (push) Successful in 12s
Doku AP0.5: ADP Scope-Verschiebung, MIGRATIONS 006, Abschlussbericht v0.2.
2026-07-05 06:23:24 +02:00

3.6 KiB
Raw Blame History

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-01G-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.10.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.10.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