Eddy: „beim ersten Upload nach Screen schliessen kamen nicht mehr alle an, ich
habe noch die gruenen Labels gesehen, aber die Bilder waren nicht da".
Ursache: uploadPhoto() verkleinert das Foto, BEVOR es in die Queue geschrieben
wird. resizeImage() haengt an img.onload / canvas.toBlob und hatte keinen
Timeout — schaltet sich das Display ab, pausiert der Browser Decoding und
Canvas, es feuert weder onload noch onerror, das Promise loest nie auf. Damit
war das Foto NIRGENDS gesichert (nicht in der Queue, nicht am Server), und weil
die Galerie-Auswahl sequentiell laeuft, stand die komplette restliche Auswahl.
Deshalb hat auch nichts automatisch nachgeladen: es gab nichts nachzuholen.
An Auftrag (PROV105) fehlten so 8 von 19 Fotos.
- resizeImage() bekommt eine Schutzzeit (Promise.race, 15s): im Zweifel wird
das unverkleinerte Original gesichert statt gar nichts
- Auswahl-Schleife: jedes Foto einzeln abgesichert, ein Fehlschlag blockiert die
restliche Auswahl nicht mehr
- Wake Lock schon waehrend der Auswahl-Verarbeitung, nicht erst beim Sync — das
Verkleinern ist genau die Stelle, die pausiert wurde. Refcount, weil sich
Auswahl-Schleife und Sync verschachteln
Schutzzeit isoliert geprueft (haengendes Decoding simuliert): faellt nach der
Frist auf das Original zurueck statt zu blockieren.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Schaltet sich das Display waehrend einer Foto-Serie ab, friert der Browser die
laufenden fetch-Aufrufe ein — die halbe Serie blieb liegen, der zweite Anlauf
erzeugte Duplikate (28.08.2026, Auftrag PROV105: 11 doppelte Fotos).
- Wake Lock waehrend syncQueue(), inkl. Neuanforderung nach App-Wechsel
(visibilitychange). Scheitert die Anforderung, laeuft der Sync unveraendert
weiter — die Queue faengt Abbrueche ohnehin ab
- duplicate:true aus der Server-Antwort wandert durch das photo-uploaded-Event;
die Miniatur zeigt dann „War schon hochgeladen" statt eines zweiten Fotos
- api.js: Kommentar auf den neuen Server-Vertrag gebracht (Bericht 1.6.0 legt
identische Dateien nicht erneut ab, at-least-once bleibt Rueckfallebene)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Kamera bleibt nach jedem Schnappschuss offen (getUserMedia Live-Video statt
native capture-Input, der nach jedem Foto schliesst)
- Filmstreifen mit Status-Badges pro Foto (💾 gesichert → ⏳ lädt hoch → ✓ fertig)
- Persist-First: Foto zuerst in IndexedDB schreiben, Upload erst danach
- Foto verlässt Queue NUR nach HTTP-2xx mit gültigem relpath
- 2xx-HTML (abgelaufene Session, Proxy-Loginseite) wird als Fehler erkannt
- HTTP-Status auf Error-Objekt: 5xx/429/408 sind transient (nicht quarantänisiert)
- 45-Sekunden-Upload-Timeout via AbortController
- Quarantäne nach 6 Fehlversuchen, Recovery via Status-Badge-Tipp
- Beforeunload-Warnung wenn Fotos noch nicht gesichert
- idb.queueUpdate() für state-preserving ItemUpdates ohne Datenverlust
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mobile Progressive Web App für Baustellen-Doku, spricht die REST-API
des Dolibarr-Bericht-Moduls.
MVP-Features:
- Vanilla JavaScript, kein Build-Step nötig
- Login mit Dolibarr-Credentials → JWT (7 Tage)
- Auftragsliste mit Suche und Multi-User-Filter
- Auftragsdetail mit Kunde, Adresse, Click-to-Call
- Foto-Aufnahme via Kamera oder Galerie (multiple)
- Clientseitige Bildverkleinerung (max 2000px, JPEG q=0.85)
- Offline-Queue in IndexedDB für Uploads ohne Netz
- Auto-Sync bei Online-Event mit Status-Badge
- Service Worker für App-Shell-Cache
- PWA-installierbar (Manifest, Icons, Theme-Color)
Hosting: awl.data-it-solution.de/baustelle/ via Apache-Alias
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
