#96 — Manuelle Mobile-/Touch-Verifizierungsrunde für offene "nicht auf echtem Gerät getestet"-Punkte #138

New issue

Open

opened 2026-08-18 13:14:21 +02:00 by lena · 1 comment

lena commented

2026-08-18 13:14:21 +02:00

(Migrated from git.butzei.de)

Story: Manuelle Mobile-/Touch-Verifizierungsrunde für offene "nicht auf echtem Gerät getestet"-Punkte

As a Product Owner,
I want to die bereits mehrfach im Decisions Log als "nicht auf echtem Gerät verifiziert" markierten
mobile/touch-Verhalten einmal gebündelt auf einem echten Mobilgerät durchtesten,
so that bekannte, aber bisher nur defensiv implementierte Lücken tatsächlich bestätigt oder als echte Bugs
aufgedeckt werden, bevor sich weitere touch-sensible Interaktionen (z. B. #91's Drag-to-reposition auf der
2D-Karte, #86's Doppel-Tap) darauf aufbauen.

Acceptance criteria:

Liste aller offenen "nicht auf echtem Gerät verifiziert"-Punkte aus dem Decisions Log/Roadmap
zusammenstellen als Ausgangspunkt, u. a.:
- #46: die vier E2E-Screenshot-Baselines (Desktop HD + mobile Pixel 8a) wurden nie aus einem grünen CI-Artefakt
  gezogen und committet (offen seit 2026-07-11).
- #52: Multi-line-Paste-Bestätigungsdialog auf Touch/Mobile — defensiv mit clipboardData?. abgesichert, nie
  auf echtem Gerät verifiziert.
- #85: e2e/default-list.spec.ts wurde nur via playwright test --list geparst, nie real ausgeführt.
- #86: Doppel-Tap-Verhalten zum Bearbeiten von Todo-Text auf Touch-Geräten.
- #94/#113: Kamera-basiertes Barcode-Scannen (Vorratsschrank, und Einkaufsliste sobald #113 geliefert ist) —
  getUserMedia/zxing-Decode nie auf einem echten Handy verifiziert, inkl. Secure-Context-Verhalten
  (HTTPS-Anforderung) im tatsächlichen Deployment.
Jeden Punkt auf einem echten Mobilgerät (Android und/oder iOS, echter Touch-Browser statt
Chrome-DevTools-Emulation) manuell durchgehen und das Ergebnis pro Punkt festhalten (bestätigt
funktionsfähig / echter Bug gefunden).
Die vier CI-Screenshot-Baselines aus #46 werden aus einem grünen e2e-CI-Run als Artefakt gezogen und in
ReactUi/e2e/screenshots/ committet.
Gefundene echte Bugs werden als eigene, neue Bug-Stories in docs/features/new/ angelegt, nicht im Rahmen
dieser Story mitgefixt — diese Story ist reine Verifizierung, kein Fix-Sammelticket.

Out of scope for this story:

Implementierung neuer Features — reine Verifizierung bereits gelieferter, aber nie real getesteter
Funktionalität.
Automatisiertes Schließen der zugrunde liegenden Sandbox-Limitation (kein Docker/echtes Gerät im autonomen
Loop) — diese Story kompensiert das für den bisher aufgelaufenen Rückstand, verhindert aber keine künftigen
neuen Fälle.

Hinweis für die Umsetzung: Diese Story braucht zwingend Zugriff auf ein echtes Mobilgerät durch den
Menschen — der autonome Sandbox-Loop kann das laut wiederholten Decisions-Log-Einträgen (#46, #52, #61, #71,
#81, #82) nicht selbst leisten.

Fortschritt (2026-08-10, "go for 96"):

#85 verifiziert — e2e/default-list.spec.ts lokal 3× gegen echten bare-host Backend/Frontend
ausgeführt (vorher nur playwright test --list geparst, nie real gelaufen). Ergebnis: alle 3 Tests grün.
Ein einzelner Timeout im allerersten Lauf (zweite Listenerstellung, 22.5s) konnte in 2 Folgeläufen nicht
reproduziert werden — vermutlich Kaltstart-Overhead des seit 18h laufenden Hintergrundprozesses, kein
bestätigter Bug. Kein separates Ticket dafür; falls das Verhalten im echten Mobile-Test (#86) als spürbare
Verzögerung wieder auftaucht, dort vermerken.
#46 weiterhin offen, aber Ursache korrigiert (2026-08-31) — Gitea-API-Zugriff ist in der aktuellen
Sandbox vorhanden (nicht mehr der blockierende Faktor). Tatsächlicher Grund: der "Desktop HD"-E2E-CI-Job
ist über den gesamten einsehbaren Verlauf (~200 Runs, mehrere Tage) durchgehend rot — es gibt aktuell
keinen grünen e2e-CI-Run, aus dem sich die Screenshot-Artefakte ziehen ließen. Das ist ein eigenständiges,
bisher unbemerktes CI-Problem, kein Geräte-Erfordernis. Eine parallele Session arbeitet Stand jetzt aktiv an
der E2E-Rotursache (15bbff9, Playwright-Locale-Scoping). #46 bleibt offen, bis entweder dieser Fix
greift und ein grüner Desktop-HD-Run existiert, oder die CI-Rotursache separat untersucht wird.
#52, #86 (Touch-Verifizierung), #94, #113 offen — brauchen ein echtes Touch-Gerät. Checkliste dafür:
https://claude.ai/code/artifact/9d85dbeb-209c-45bf-b23f-4eafc8fcb3ac (lokal im Browser gespeicherter
Fortschritt, Ergebnisse werden per Chat zurückgemeldet). (Hinweis: die Implementierung von Doppelklick/
Doppel-Tap zum Bearbeiten ist bereits als Issue #86 geschlossen — offen ist hier nur noch die manuelle
Touch-Geräte-Verifizierung dieses bereits gelieferten Verhaltens, nicht die Funktion selbst.)

# Story: Manuelle Mobile-/Touch-Verifizierungsrunde für offene "nicht auf echtem Gerät getestet"-Punkte **As a** Product Owner, **I want to** die bereits mehrfach im Decisions Log als "nicht auf echtem Gerät verifiziert" markierten mobile/touch-Verhalten einmal gebündelt auf einem echten Mobilgerät durchtesten, **so that** bekannte, aber bisher nur defensiv implementierte Lücken tatsächlich bestätigt oder als echte Bugs aufgedeckt werden, bevor sich weitere touch-sensible Interaktionen (z. B. `#91`'s Drag-to-reposition auf der 2D-Karte, `#86`'s Doppel-Tap) darauf aufbauen. **Acceptance criteria:** - [ ] Liste aller offenen "nicht auf echtem Gerät verifiziert"-Punkte aus dem Decisions Log/Roadmap zusammenstellen als Ausgangspunkt, u. a.: - `#46`: die vier E2E-Screenshot-Baselines (Desktop HD + mobile Pixel 8a) wurden nie aus einem grünen CI-Artefakt gezogen und committet (offen seit 2026-07-11). - `#52`: Multi-line-Paste-Bestätigungsdialog auf Touch/Mobile — defensiv mit `clipboardData?.` abgesichert, nie auf echtem Gerät verifiziert. - `#85`: `e2e/default-list.spec.ts` wurde nur via `playwright test --list` geparst, nie real ausgeführt. - `#86`: Doppel-Tap-Verhalten zum Bearbeiten von Todo-Text auf Touch-Geräten. - `#94`/`#113`: Kamera-basiertes Barcode-Scannen (Vorratsschrank, und Einkaufsliste sobald `#113` geliefert ist) — `getUserMedia`/zxing-Decode nie auf einem echten Handy verifiziert, inkl. Secure-Context-Verhalten (HTTPS-Anforderung) im tatsächlichen Deployment. - [ ] Jeden Punkt auf einem echten Mobilgerät (Android und/oder iOS, echter Touch-Browser statt Chrome-DevTools-Emulation) manuell durchgehen und das Ergebnis pro Punkt festhalten (bestätigt funktionsfähig / echter Bug gefunden). - [ ] Die vier CI-Screenshot-Baselines aus `#46` werden aus einem grünen `e2e`-CI-Run als Artefakt gezogen und in `ReactUi/e2e/screenshots/` committet. - [ ] Gefundene echte Bugs werden als eigene, neue Bug-Stories in `docs/features/new/` angelegt, nicht im Rahmen dieser Story mitgefixt — diese Story ist reine Verifizierung, kein Fix-Sammelticket. **Out of scope for this story:** - Implementierung neuer Features — reine Verifizierung bereits gelieferter, aber nie real getesteter Funktionalität. - Automatisiertes Schließen der zugrunde liegenden Sandbox-Limitation (kein Docker/echtes Gerät im autonomen Loop) — diese Story kompensiert das für den bisher aufgelaufenen Rückstand, verhindert aber keine künftigen neuen Fälle. **Hinweis für die Umsetzung:** Diese Story braucht zwingend Zugriff auf ein echtes Mobilgerät durch den Menschen — der autonome Sandbox-Loop kann das laut wiederholten Decisions-Log-Einträgen (`#46`, `#52`, `#61`, `#71`, `#81`, `#82`) nicht selbst leisten. **Fortschritt (2026-08-10, "go for 96"):** - **`#85` verifiziert** — `e2e/default-list.spec.ts` lokal 3× gegen echten bare-host Backend/Frontend ausgeführt (vorher nur `playwright test --list` geparst, nie real gelaufen). Ergebnis: alle 3 Tests grün. Ein einzelner Timeout im allerersten Lauf (zweite Listenerstellung, 22.5s) konnte in 2 Folgeläufen nicht reproduziert werden — vermutlich Kaltstart-Overhead des seit 18h laufenden Hintergrundprozesses, kein bestätigter Bug. Kein separates Ticket dafür; falls das Verhalten im echten Mobile-Test (`#86`) als spürbare Verzögerung wieder auftaucht, dort vermerken. - **`#46` weiterhin offen, aber Ursache korrigiert (2026-08-31)** — Gitea-API-Zugriff ist in der aktuellen Sandbox vorhanden (nicht mehr der blockierende Faktor). Tatsächlicher Grund: der "Desktop HD"-E2E-CI-Job ist über den gesamten einsehbaren Verlauf (~200 Runs, mehrere Tage) durchgehend rot — es gibt aktuell keinen grünen `e2e`-CI-Run, aus dem sich die Screenshot-Artefakte ziehen ließen. Das ist ein eigenständiges, bisher unbemerktes CI-Problem, kein Geräte-Erfordernis. Eine parallele Session arbeitet Stand jetzt aktiv an der E2E-Rotursache (`15bbff9`, Playwright-Locale-Scoping). `#46` bleibt offen, bis entweder dieser Fix greift und ein grüner Desktop-HD-Run existiert, oder die CI-Rotursache separat untersucht wird. - **`#52`, `#86` (Touch-Verifizierung), `#94`, `#113` offen** — brauchen ein echtes Touch-Gerät. Checkliste dafür: https://claude.ai/code/artifact/9d85dbeb-209c-45bf-b23f-4eafc8fcb3ac (lokal im Browser gespeicherter Fortschritt, Ergebnisse werden per Chat zurückgemeldet). (Hinweis: die *Implementierung* von Doppelklick/ Doppel-Tap zum Bearbeiten ist bereits als Issue #86 geschlossen — offen ist hier nur noch die manuelle Touch-Geräte-Verifizierung dieses bereits gelieferten Verhaltens, nicht die Funktion selbst.)

lena commented

2026-08-31 21:44:03 +02:00

(Migrated from git.butzei.de)

Story-Body korrigiert (auf Nutzeranfrage): die veraltete Zeile "Blocked by (old numbering): #86" entfernt (Issue #86 ist bereits geschlossen), und die #46-Begründung präzisiert (rote Desktop-HD-CI statt fehlender Geräte-/Token-Zugriff). Der Rest der Story (#52, #86-Touch-Verifizierung, #94, #113) bleibt korrekt als geräteabhängig blockiert - status/blocked bleibt daher bestehen, nur die Begründung wurde genauer.