137 lines
5.3 KiB
Markdown
137 lines
5.3 KiB
Markdown
# QA Issues – 2026-02-24
|
||
|
||
Scope: Agentische, statische QA-Review (Flutter/Dart CLI lokal nicht verfügbar: `flutter` fehlt). Fokus auf 4-Step-Flow, Save/Load/Delete, JSON-Export und UX-Kantenfälle.
|
||
|
||
## Issue 1 (P1) – 4-Step-Flow lässt Fortschritt ohne Pflichtdaten zu
|
||
**Bereich:** 4-Step-Flow
|
||
|
||
**Beobachtung**
|
||
- Im `Stepper` kann man per `Weiter`/Tap bis Schritt 4 springen, auch ohne Bildauswahl.
|
||
- Auf Schritt 4 ist „Generate Mosaic“ aktiv, aber `_generate()` bricht stillschweigend ab, wenn kein Bild vorhanden ist.
|
||
|
||
**Code-Hinweis**
|
||
- `lib/main.dart:1068-1127` (`Stepper` ohne Guard/Validation)
|
||
- `lib/main.dart:1250-1255` (Generate-Button nur an `_isGenerating` gebunden)
|
||
- `lib/main.dart:884`ff (`_generate()` returnt bei `_sourceImageBytes == null` ohne User-Feedback)
|
||
|
||
**Repro-Schritte**
|
||
1. App öffnen (kein Bild geladen).
|
||
2. Im Mosaic-Stepper mehrfach „Weiter“ klicken oder direkt auf Schritt 4 tippen.
|
||
3. „Generate Mosaic“ klicken.
|
||
4. Es passiert visuell nichts (kein Ergebnis, kein Hinweis).
|
||
|
||
**Akzeptanzkriterium**
|
||
- Schritt-Navigation ist zustandsbasiert: Schritt 2-4 erst zugänglich, wenn notwendige Voraussetzungen erfüllt sind.
|
||
- „Generate Mosaic“ ist deaktiviert, solange kein Bild geladen ist.
|
||
- Alternativ/zusätzlich: verständliche Fehlermeldung (Snackbar), falls Generierung ohne Bild ausgelöst wird.
|
||
|
||
---
|
||
|
||
## Issue 2 (P1) – Projekt-Load mit leerem Bild leert bestehenden Zustand nicht
|
||
**Bereich:** Save/Load-Flow
|
||
|
||
**Beobachtung**
|
||
- Beim Laden werden `_sourceImageBytes` und `_result` nur gesetzt, wenn `data.sourceImageBytes != null`.
|
||
- Lädt man ein Projekt ohne Bild, bleibt ggf. ein altes Bild/Ergebnis aus vorherigem Zustand erhalten.
|
||
|
||
**Code-Hinweis**
|
||
- `lib/main.dart:308-313` (fehlender `else`-Zweig zum expliziten Zurücksetzen)
|
||
|
||
**Repro-Schritte**
|
||
1. Projekt A mit Bild laden/generieren.
|
||
2. Projekt B laden, das ohne Bild gespeichert wurde (oder manuell erstellt wurde).
|
||
3. Erwartung: leerer/initialer Zustand.
|
||
4. Ist-Zustand: vorheriges Bild kann bestehen bleiben.
|
||
|
||
**Akzeptanzkriterium**
|
||
- Beim Laden eines Projekts ohne `sourceImageBytes` wird Zustand explizit zurückgesetzt (`_sourceImageBytes = null`, `_result = null`, ggf. Step auf 1).
|
||
- UI zeigt konsistent den tatsächlich geladenen Projektzustand.
|
||
|
||
---
|
||
|
||
## Issue 3 (P1) – Projekt-Snapshots sind nicht reproduzierbar, da Katalog nicht versioniert wird
|
||
**Bereich:** Save/Load-Flow + JSON-Export
|
||
|
||
**Beobachtung**
|
||
- Gespeicherte Projekte enthalten Parameter + Bild, aber **keinen Snapshot des verwendeten Farb-Katalogs**.
|
||
- Beim Laden wird mit aktuellem globalen `_catalog` neu generiert → Ergebnis kann von ursprünglichem Snapshot abweichen.
|
||
|
||
**Code-Hinweis**
|
||
- `lib/project_codec.dart` (`MosaicProjectData` ohne Katalogdaten)
|
||
- `lib/main.dart:316` (`_generate()` nach Load nutzt aktuellen `_catalog`)
|
||
|
||
**Repro-Schritte**
|
||
1. Mit Katalog-Set A ein Projekt erzeugen/speichern.
|
||
2. Katalogfarben ändern (hinzufügen/löschen/umfärben).
|
||
3. Projekt laden.
|
||
4. Ergebnisfarben/Zuordnung unterscheiden sich vom ursprünglichen Stand.
|
||
|
||
**Akzeptanzkriterium**
|
||
- Projektspeicherung enthält eine Palette/Katalog-Snapshot-Version (mind. Name + Farbe pro Eintrag).
|
||
- Load nutzt standardmäßig den gespeicherten Snapshot (mit klarer UX bei Konflikten/Optionen).
|
||
- Reproduzierbarkeit des Mosaiks ist gewährleistet.
|
||
|
||
---
|
||
|
||
## Issue 4 (P2) – Export JSON nicht klar reproduzierbar ohne Ergebnis
|
||
**Bereich:** JSON-Export
|
||
|
||
**Beobachtung**
|
||
- Export enthält `project` immer, `result` aber nur falls bereits generiert.
|
||
- Wenn vor Export keine Generierung lief, fehlt Kerninformation (`assignments`/`palette`) ohne klaren Nutzerhinweis.
|
||
|
||
**Code-Hinweis**
|
||
- `lib/main.dart:378-392`
|
||
|
||
**Repro-Schritte**
|
||
1. Bild laden, aber nicht generieren.
|
||
2. „Export JSON“ klicken.
|
||
3. Exportdatei enthält kein `result`-Objekt.
|
||
|
||
**Akzeptanzkriterium**
|
||
- UX-Entscheidung explizit umsetzen:
|
||
- entweder Export-Button nur mit vorhandenem Ergebnis aktivieren, oder
|
||
- vor Export automatisch generieren, oder
|
||
- deutlichen Hinweisdialog anzeigen („Export ohne Ergebnisdaten“).
|
||
|
||
---
|
||
|
||
## Issue 5 (P3) – „Fertig“-CTA im letzten Step ohne klaren Effekt
|
||
**Bereich:** 4-Step-Flow UX
|
||
|
||
**Beobachtung**
|
||
- Im letzten Step zeigt der Continue-Button „Fertig“, führt aber funktional zu keiner sichtbaren Aktion.
|
||
|
||
**Code-Hinweis**
|
||
- `lib/main.dart:1071-1093` (`onStepContinue` erhöht nur bis max. letztem Step)
|
||
|
||
**Repro-Schritte**
|
||
1. Bis Schritt 4 navigieren.
|
||
2. „Fertig“ klicken.
|
||
3. Kein Abschluss-Feedback/State-Change.
|
||
|
||
**Akzeptanzkriterium**
|
||
- Letzter CTA hat klare Bedeutung (z. B. „Generieren“, „Abschließen“, „Zum Export“) oder wird im letzten Step ausgeblendet.
|
||
- Nutzer erhält eindeutiges Abschlussfeedback.
|
||
|
||
---
|
||
|
||
## Issue 6 (P3) – Lösch-Flow ohne Hinweis auf betroffenen Arbeitsstand
|
||
**Bereich:** Delete-Flow UX
|
||
|
||
**Beobachtung**
|
||
- Beim Löschen eines Snapshots gibt es nur Dateiname + Bestätigung.
|
||
- Kein Hinweis, ob gerade geladener Stand betroffen ist bzw. wie sich das auf „Letzten Stand laden“ auswirkt.
|
||
|
||
**Code-Hinweis**
|
||
- `lib/main.dart:333-367`
|
||
|
||
**Repro-Schritte**
|
||
1. Snapshot laden.
|
||
2. In Projekte denselben Snapshot löschen.
|
||
3. Nutzer bleibt ohne Kontext, ob aktiver Stand/Latest-Verhalten beeinflusst ist.
|
||
|
||
**Akzeptanzkriterium**
|
||
- Dialog/Feedback benennt Auswirkungen klar (z. B. „Aktuell geladener Zustand bleibt im Speicher bis Wechsel/Neustart“).
|
||
- Optional: Markierung des aktuell geladenen Snapshots in der Liste.
|