From dbc30356f64bc7b055b8344d1f157ee37505e725 Mon Sep 17 00:00:00 2001 From: patrick Date: Thu, 3 Sep 2026 22:26:06 +0200 Subject: [PATCH] =?UTF-8?q?Sprintplan=20MVP=20erg=C3=A4nzen=20(Sprints=200?= =?UTF-8?q?-8,=20E1-E6=20fixierte=20Entscheidungen,=20Abnahmekriterien)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01L85hmKbvX7Cqkq47KnQhFt --- DEVLOG.md | 14 +++++++++ GESAMTDOKUMENT.md | 66 ++++++++++++++++++++++++++++++++++++++++ ergebnisse/sprintplan.md | 63 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 143 insertions(+) create mode 100644 ergebnisse/sprintplan.md diff --git a/DEVLOG.md b/DEVLOG.md index ece55b7..8aa04f1 100644 --- a/DEVLOG.md +++ b/DEVLOG.md @@ -816,3 +816,17 @@ Keine Änderungen ermittelbar. - ergebnisse/testphasen.md | 1 + --- +## 2026-09-03 22:20 – 22:21 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** asb-material + +### Commits +- 3219145 Prompt 12 Nummerierung korrigieren (6/7 statt 6/6a), Verweis in Prompt 16 anpassen + +### Geänderte Dateien +- DEVLOG.md | 19 +++++++++++++++++++ +- GESAMTDOKUMENT.md | 8 ++++---- +- ergebnisse/12_verantwortlichen_dashboard.md | 6 +++--- +- ergebnisse/16_kontrollabschluss.md | 2 +- + +--- diff --git a/GESAMTDOKUMENT.md b/GESAMTDOKUMENT.md index abcaf62..4c31c17 100644 --- a/GESAMTDOKUMENT.md +++ b/GESAMTDOKUMENT.md @@ -1911,6 +1911,72 @@ Bezug: [[01_anforderungsanalyse]], [[02_prozess_kontrolle]], [[11_kontroll_ui]], --- +# 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` + +--- + # Testphasen – MABEA V1 Bezug: [[22_testkonzept]], [[18_version_1]], [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[04_mindermengen]], [[05_rollen_rechte]], [[17_mobile_offline]], [[21_api]]. diff --git a/ergebnisse/sprintplan.md b/ergebnisse/sprintplan.md new file mode 100644 index 0000000..a89c33b --- /dev/null +++ b/ergebnisse/sprintplan.md @@ -0,0 +1,63 @@ +# 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`