Native Android-App (Kotlin, CameraX, Room, WorkManager) fuer Dokumenten-/Kassenbeleg-Erfassung, ergaenzend zu INT-19. Backend-Ergaenzung minimal: POST /auth/mobile-login (langlebiges Token, additiv). Echter Architektur-Fund: dms-app erwartet ein audience-gebundenes Modul-Token (aud=dms), nicht das rohe Sitzungstoken -- App tauscht darum ueber den bereits bestehenden POST /auth/module-token (Cookie-Header), im Pruefprotokoll dokumentiert.
Ergebnisse:
Prueufung 1 (Login-Fehlerfaelle): erfuellt, real gegen echten account-api/dms-app auf Host 204 getestet
Pruefung 2 (Kamera-Erfassung): OFFEN -- kein Android-Emulator-System-Image auf Host 236 installiert, nicht ohne Rueckfrage nachinstalliert
Pruefung 3 (Offline-Szenario): Logik unit-getestet, echtes Geraet/Emulator-Szenario OFFEN (gleicher Grund wie Pruefung 2)
Pruefung 4 (Groessen-/Typ-Missbrauch): erfuellt, real getestet
Pruefung 5 (echter APK-Build): erfuellt, BUILD SUCCESSFUL auf Host 236, Smoke-Install auf Emulator OFFEN
13/13 Kotlin-Unit-Tests gruen. Kein Merge, kein Deploy.
Native Android-App (Kotlin, CameraX, Room, WorkManager) fuer Dokumenten-/Kassenbeleg-Erfassung, ergaenzend zu INT-19. Backend-Ergaenzung minimal: POST /auth/mobile-login (langlebiges Token, additiv). Echter Architektur-Fund: dms-app erwartet ein audience-gebundenes Modul-Token (aud=dms), nicht das rohe Sitzungstoken -- App tauscht darum ueber den bereits bestehenden POST /auth/module-token (Cookie-Header), im Pruefprotokoll dokumentiert.
Ergebnisse:
- Prueufung 1 (Login-Fehlerfaelle): erfuellt, real gegen echten account-api/dms-app auf Host 204 getestet
- Pruefung 2 (Kamera-Erfassung): OFFEN -- kein Android-Emulator-System-Image auf Host 236 installiert, nicht ohne Rueckfrage nachinstalliert
- Pruefung 3 (Offline-Szenario): Logik unit-getestet, echtes Geraet/Emulator-Szenario OFFEN (gleicher Grund wie Pruefung 2)
- Pruefung 4 (Groessen-/Typ-Missbrauch): erfuellt, real getestet
- Pruefung 5 (echter APK-Build): erfuellt, BUILD SUCCESSFUL auf Host 236, Smoke-Install auf Emulator OFFEN
13/13 Kotlin-Unit-Tests gruen. Kein Merge, kein Deploy.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Backend (kleinstmoeglich, wie im Ticket vorgesehen):
- internal/auth: TokenIssuer.IssueWithTTL, LoginService.LoginWithTTL
(additiv, bestehende Issue/Login unveraendert)
- internal/totp: LoginWithTOTPTTL (durchlaeuft denselben 2FA-Ablauf)
- cmd/account-api: neue Route POST /auth/mobile-login (JSON-Token statt
Cookie, 90 Tage TTL statt 30 Minuten)
Android-App (android/dms-capture, Kotlin, Gradle-Projekt):
- CameraX-Erfassung mit Live-Vorschau, erneuter Aufnahme, Mehrseiten-
Sammlung (AC2)
- Ruft ausschliesslich die bestehende DOC-01-Upload-API auf, kein neuer
Backend-Uploadpfad (AC3) -- echter Architektur-Fund dabei: dms-app
erwartet ein audience-gebundenes Modul-Token (aud=dms), kein rohes
Sitzungstoken; App tauscht ueber den bereits bestehenden Endpunkt
POST /auth/module-token (Cookie-Header), dokumentiert im Pruefprotokoll
- Room-basierte Offline-Warteschlange mit sichtbarem Status, WorkManager
fuer automatische Nachreichung ohne Nutzeraktion (AC4)
- Verstaendliche Fehlermeldungen bei Groessen-/Typ-Ablehnung statt nur
Fehlercode (AC5)
- Internes APK, kein Play-Store-Zwang (AC6)
Real getestet: Ende-zu-Ende-Auth-Kette (Login -> Modul-Token -> Bearer
gegen echten dms-app) auf Host 204, 13/13 Kotlin-Unit-Tests gruen, echter
APK-Build auf Host 236 (Android-SDK dort vorhanden, kein Install auf der
Entwicklungsmaschine, Gradle projektlokal nachgezogen statt System-Install).
Offen (Pruefprotokoll): Kamera-/Offline-/Smoke-Install-Pruefungen
brauchen einen Android-Emulator; kein System-Image auf Host 236
installiert, Nachinstallation bewusst nicht ohne Rueckfrage vorgenommen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Drei echte Bugs auf einem echten Android-Geraet gefunden, keiner davon
in den Unit-Tests sichtbar: QueueActivity griff synchron auf Room auf
dem Main-Thread zu (Absturz), Android verbietet Klartext-HTTP auch zu
127.0.0.1 (Login unmoeglich), Server-Adressen waren nur zur Build-Zeit
setzbar (Nutzer-Fund). Alle drei behoben; Login gegen einen echten
account-api real nachgewiesen.
Service-Discovery fuer eine einzelne Server-Adresse (statt zwei Felder)
ist blockiert: kein Core-Mechanismus dafuer vorhanden (moduleregistry
liefert keine Endpunkt-Adressen, web/portal nutzt eine statische
Konfiguration) -- Details im Pruefprotokoll-Nachtrag.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzerfund beim echten Gerätetest: kein android:icon gesetzt, keine
Launcher-Icon-Ressourcen vorhanden. Adaptive Icon (Vektor-basiert,
Dokument+Kamera-Symbol) ergänzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CaptureActivity.enqueueCapture rief Room synchron aus dem
OnImageSavedCallback auf dem Main-Thread auf, identisch zum
vorherigen QueueActivity-Fund. Behoben mit demselben
ioExecutor+runOnUiThread-Muster. Real auf T10Pro getestet:
Pruefung 2 vollstaendig bestanden, Pruefung 3 teilweise (Warteschlange
uebersteht Verbindungsabbruch ohne Datenverlust, automatische
Nachreichung nicht abschliessend beobachtet wegen wiederholter
Kabelloses-Debugging-Abbrueche der Testverbindung, kein App-Fehler).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Prüfung 3 abgeschlossen: Warteschlangen-Eintrag wechselt nach echter
Uebertragung sichtbar von \"wartet\" zu \"uebertragen\" mit realer
Dokument-ID. Fehlerursache der vorherigen 500er war eine unvollstaendige
Test-Backend-Konfiguration (fehlender KEK-Stub-Endpunkt), kein App-Bug --
alte fehlgeschlagene Eintraege bleiben korrekt als \"Abgelehnt\" mit
nachvollziehbarem Grund erhalten, kein stiller Datenverlust.
Neue Funktion (Nutzeranforderung): Kontrast-/Schaerfe-Korrektur der
Aufnahme vor dem Einreihen (de.nexarch.dmscapture.imaging.ImageProcessor),
per-Pixel statt ueber Canvas/ColorMatrix umgesetzt, da letzteres in
Robolectric-Tests nicht simuliert wird. Debug-Netzwerkkonfiguration um
den Test-Host im lokalen Netz ergaenzt (bleibt debug-only, kein
Release-Verweis).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzerfund: kein android:autofillHints auf E-Mail/Passwort-Feldern,
Androids Passwort-Manager konnte die Zugangsdaten deshalb nicht zum
Speichern anbieten. Das Sitzungstoken selbst wird bereits verschluesselt
gespeichert (SessionStore) -- dies betrifft nur die Erst-Eingabe, falls
der Nutzer sich erneut anmelden muss.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer distserver (eigenes go.mod, kein Login, nur intern erreichbar):
GET /version liefert Versionsangabe, GET /download die APK. VersionCheck
fragt das beim App-Start ab und zeigt einen Hinweis-Banner bei neuerer
Version (kein Auto-Update). Dritte, optionale Server-Adresse in
ServerConfig/Login-Ansicht ergaenzt.
Autofill-Hinweise (android:autofillHints) auf Login-Feldern ergaenzt --
Androids Passwort-Manager konnte Zugangsdaten vorher nicht anbieten,
obwohl das Sitzungstoken selbst schon verschluesselt gespeichert wird.
Echter Geraetetest teilweise abgeschlossen (UI-Feld bestaetigt, Backend
real aufgesetzt und getestet), letzter Sichtnachweis an Netzwerk-
Topologie-Grenze (isoliertes Geraete-Subnetz) gescheitert, ehrlich im
Pruefprotokoll vermerkt statt behauptet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
patrick
merged commit a0d6590470 into main2026-09-26 23:31:46 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Native Android-App (Kotlin, CameraX, Room, WorkManager) fuer Dokumenten-/Kassenbeleg-Erfassung, ergaenzend zu INT-19. Backend-Ergaenzung minimal: POST /auth/mobile-login (langlebiges Token, additiv). Echter Architektur-Fund: dms-app erwartet ein audience-gebundenes Modul-Token (aud=dms), nicht das rohe Sitzungstoken -- App tauscht darum ueber den bereits bestehenden POST /auth/module-token (Cookie-Header), im Pruefprotokoll dokumentiert.
Ergebnisse:
13/13 Kotlin-Unit-Tests gruen. Kein Merge, kein Deploy.
🤖 Generated with Claude Code