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