MABEA/ergebnisse/sprintplan.md

# Sprint-Plan MVP (V1)

Bezug: [[18_version_1]], [[22_testkonzept]], `testphasen.md` (Phase 0–5; Phase S = Satellit, Roadmap), `reihenfolge.md`, Karten [[01_rollen_zuordnung]], [[04_organisationsstruktur]], [[13_satelliten_server]].

Grundprinzip: fachliche Abhängigkeitskette bauen, Domänenlogik vor UI, Leitplanke „Mindermenge ≠ erledigt" früh beweisen. Kein Feature ohne Test (CI-Gate greift ab Sprint 0). Satelliten-Betrieb ist NICHT Teil dieses Plans (eigene Phase S in `testphasen.md`).

## 0. Fixierte Entscheidungen (bindend)

| # | Entscheidung | Konsequenz |
|---|---|---|
| E1 | **Keine Kontrollfälligkeit/-intervalle in V1.** Einzige zeitgetriebene Sichtbarkeit: Ablaufdaten (Prompt 14). Kontrolle wird organisatorisch angewiesen, System dokumentiert nur Durchführung (letzter Kontrollzeitpunkt sichtbar). | Kein Fälligkeitsfeld im Schema, keine „überfällig"-Kennzahl. Dashboard-Zeitkennzahl bleibt nur „bevorstehende Ablaufdaten" (Prompt 12.7). Fälligkeitslogik = Roadmap-Kandidat (verwandt mit Eskalation, Karte 12). |
| E2 | **Zuständigkeit vererbt sich vom Standort auf alle dortigen Objekte.** Standort-Zuordnung impliziert alle Objekte am Standort; objektspezifische Zeilen (`zustaendigkeit.objekt_id`) sind feinere Ergänzung, kein Ersatz. | Auswertelogik: Benutzer ist für Objekt zuständig, wenn ENTWEDER Standort-Zeile für dessen Standort ODER Objekt-Zeile existiert (Vereinigung, keine Überschreibung). Mehrere Verantwortliche je Objekt möglich (n:m). (Karte 04) |
| E3 | **Kontrollverantwortung ist nur Sichtbarkeit/Priorisierung, keine Pflichtkontrolle.** Zugewiesene Objekte werden im UI hervorgehoben, schließen andere Mitarbeiter nicht aus. | Screen 1 (Prompt 11): zugewiesene Objekte zuerst/hervorgehoben, darunter „alle Objekte". Keine Sperrlogik durch Zuweisung – Schutz vor Doppelarbeit ist die Objekt-Sperre (Prompt 02.8). (Karte 01) |
| E4 | **Nachfüllung über Soll hinaus ist erlaubt**, wird als Überbestand protokolliert (informativ), erzeugt keinen Fehlbestand und keinen Fehler (Prompt 02.4 / 21.9). | API: kein 422, Response kennzeichnet den Fall als „Überbestand"-Info. |
| E5 | **Touch-Signatur: Datenmodell-Feld vorhanden (`kontrolle.signatur`, Prompt 20), UI dafür Roadmap.** V1 nutzt Login-gebundenen Kontrollnachweis als Unterschriftsersatz (Prompt 16.5). | Keine Einstellungs-Entität „Signatur pro Standort ein/aus" in V1; Konfigurierbarkeit erst mit Signatur-UI (Roadmap). |
| E6 | **V1-Seed: genau ein `systemknoten`-Datensatz (typ='haupt')** per Alembic-Migration angelegt; Backend liest dessen ID aus Config (z. B. Umgebungsvariable `SYSTEMKNOTEN_ID`) und setzt sie bei jedem Insert in `erzeugt_von_server_id`/`zustaendiger_server_id`. | Verhindert NOT NULL-Verletzungen ab dem allerersten Datensatz (Details/Begründung: `testphasen.md` Phase 0); Satelliten kommen später als weitere Zeilen dazu. |

## 1. Sprint-Übersicht

| Sprint | Inhalt | Fachbasis | Tests |
|---|---|---|---|
| **0 Fundament** | FastAPI-Skeleton, SQLAlchemy/Alembic, PostgreSQL, CI (pytest + Coverage-Gate 50 %); Auth (JWT, Passwort-Hashing bcrypt/argon2) + Rollen-Dependency; Schema-Grundgerüst inkl. `systemknoten` + UUID-Tabellen (Karte-13-Vorbereitung, kein späterer Umbau); Seed Hauptserver (E6) | Prompt 19/20, Karte 09 | Testphase 0 komplett |
| **1 Stammdaten** | Bereich, Kategorie, Standort, Objekttyp, Material (3 Typen); Benutzer/Rollen/Zuständigkeiten inkl. Vererbungslogik (E2); Admin-API 7a (Prompt 21) | Prompt 06/07, Karte 04 | Testphase 2 für diese Endpunkte; parametrisierter Rollenmatrix-Test angelegt |
| **2 Vorlagen & Objekte** | Beladungsvorlagen + Versionierung, Objekte anlegen/duplizieren, Objektpositionen + Override-Logik | Prompt 08/09/10 | U8, U9, U10 |
| **3 Kontroll-Kern** | Kontroll-Statusmaschine, Objekt-Sperre + Übernahme (protokolliert), Abschluss/Abbruch, Kontrollnachweis, automatische Fehlbestand-Erzeugung; Mitarbeiter-UI Screens 1–6 inkl. Zuweisungs-Hervorhebung (E3) | Prompt 02/11/16 | U1, U11, U12; Sperr-/409-Tests |
| **4 Fehlbestand & Nachfüllung** | Fehlbestand-Statusmaschine komplett, Nachfüllung sofort/später/teilweise, Überbestand-Regel (E4) | Prompt 03 | U3, U4, U5, U13 |
| **5 Mindermengen & Historie** | Genehmigung + automatischer Ablauf bei nächster Kontrolle; Historie-Vervollständigung (alle Ereignistypen), Audit-Suche/-UI | Prompt 04/13 | **U2, U6, U7, U14 – Leitplanke final bewiesen**; Testphase 3 startet (S7–S9, S15) |
| **6 Dashboard, Ablaufdaten, E-Mail** | Kennzahlen mit Aggregationsregel (offen + in_bearbeitung + nachgefuellt_teilweise = offen), Filter, Ablauf-Warnungen (einzige Zeit-Sicht, E1), asynchroner E-Mail-Versand bei neuem Fehlbestand | Prompt 12/14, Karte 05 | Testphase 3 weiter |
| **7 Offline-Härtung & E2E** | Service Worker / lokale Pufferung, Abschluss blockiert bei ungesendeten Positionen, Idempotenz, Statusanzeige | Prompt 17 | Testphase 3 komplett (S1–S17), Testphase 4 (Playwright, Viewports, Praktiker-Session) |
| **8 Pilotvorbereitung** | Excel-Import der 3 Ist-Listen, Test-Deployment auf VPS, Parallelbetrieb Papier, Go/No-Go | Prompt 23 | Testphase 5 |

**Nicht im Plan** (bewusst, Prompt 18 Abschnitt 4): QR-Scan-Funktion, Eskalation, Lagerverwaltung, Push, Satelliten-Betrieb (Phase S).

## 2. Regeln übergreifend

- **Historie ab Sprint 1 mitbauen:** jeder schreibende Endpunkt protokolliert ab seiner Entstehung (wer/wann/alt→neu); Sprint 5 komplettiert nur Ereignistypen und Audit-UI. Keine nachträgliche Nachrüstung.
- **Testphasen 1+2 laufen IN den Sprints** (kein Merge ohne Test, CI-Gate), Phasen 3–5 sind die Endphasen.
- **Kein UI vor Domänenlogik** – erste nennenswerte UI in Sprint 3, weil dort erstmals ein Mitarbeiter-Flow existiert (direkte Umsetzung der `reihenfolge.md`-Philosophie).

## 3. Größenordnung

9 Sprints × 2 Wochen ≈ 4–5 Monate bei Vollzeit-ähnlicher Kapazität; als Nebenbei-Projekt entsprechend länger. Engstellen: Sprint 3 (größter UI-Block), Sprint 7 (Offline-Verhalten technisch am fummeligsten).

## 4. Abnahmekriterien je Sprint

- **S0:** CI grün, Login funktioniert, Rollen-Dependency greift auf einem Test-Endpunkt, Seed `systemknoten` vorhanden und vom Backend verwendet (E6).
- **S1:** Alle Stammdaten-Endpunkte + Admin-API per Tests abgedeckt; Vererbungslogik (E2) durch Test bewiesen (Standort-Zuordnung → Sicht enthält alle Objekte des Standorts, Vereinigung mit Objekt-Zeilen).
- **S2:** Vorlagen-Versionierung + Duplizieren + Override durch U8/U9/U10 bewiesen.
- **S3:** Komplette Kontrolle digital durchspielbar inkl. Sperre/Übernahme/Abbrechen; Fehlbestand entsteht automatisch bei Ist < Soll.
- **S4:** Fehlbestand-Lebenszyklus komplett (U3/U4/U5/U13); Überbestand protokolliert ohne Fehlbestand (E4).
- **S5:** U2/U6/U7/U14 grün; Historie-Kette S15 vollständig referenziert und chronologisch korrekt.
- **S6:** Dashboard-Kennzahlen stimmen mit Aggregationsregel überein; E-Mail kommt bei neuem Fehlbestand an (Test-Mailserver).
- **S7:** Netzausfall-Szenario S16 grün, keine Datenverluste; Praktiker-Session ohne kritische UX-Befunde.
- **S8:** Echtdaten importiert, Parallelbetrieb ohne fachliche Diskrepanz → Go/No-Go-Entscheidung.

## 5. Excel-Import (Sprint 8)

Das detaillierte Spalten-Mapping, der Import-Ablauf und die bekannten Lücken (Einheiten-Nachpflege, Artikelnummer-Abgleich, Deployment-Regel) sind in **`testphasen.md`, Abschnitt „Excel-Import-Mapping"** ausgearbeitet und dort verbindlich – hier bewusst kein Duplikat, um Divergenz zu vermeiden.

Kurzfassung für die Sprint-Planung: einmaliges idempotentes CLI-Import-Skript (Abgleich über Artikelnummer) erzeugt Bereich/Kategorie, je Excel-Datei einen Objekttyp + Beladungsvorlage Version 1 mit Vorlagenpositionen; konkrete Objekte werden danach über die UI aus den Vorlagen angelegt (Prompt 09-Flow), erste Kontrolle erfasst den Ist-Bestand (= Übergang Papier → digital, Prompt 23). Review-Schritt für die Materialtyp-Zuordnung (`standard`/`geraet_sn`; `ablauf_charge` kommt in den drei Quell-Listen nicht vor) ist Pflicht.

## Referenzen
Bezug: [[18_version_1]], [[22_testkonzept]], [[19_technische_architektur]], [[20_datenbank_schema]], [[21_api]], Karten [[01_rollen_zuordnung]], [[04_organisationsstruktur]], [[05_benachrichtigungen]], [[09_authentifizierung]], [[13_satelliten_server]], `testphasen.md`