diff --git a/dms/docs/UX-14-PRUEFPROTOKOLL.md b/dms/docs/UX-14-PRUEFPROTOKOLL.md new file mode 100644 index 00000000..e4f89c6d --- /dev/null +++ b/dms/docs/UX-14-PRUEFPROTOKOLL.md @@ -0,0 +1,43 @@ +# UX-14 – Prüfprotokoll: Barrierefreiheits-Audit Mail/E-Rechnung + Token-Modus + +Basis: `integration/gesamtprojekt`, Head `27d3dca`. Geprüft auf Entwicklungshost 204 (Wegwerf-Cluster `17/coredev`; `archivdms`-Cluster unberührt). Chrome und pa11y waren durch den vorigen Chrome-Nachtrag (PR #132) bereits installiert, nichts Neues wurde installiert. + +## Umsetzung + +**AK1 – `a11y-fixture` erweitert:** +`dms/cmd/a11y-fixture/main.go` registriert zusätzlich `mailimportapi` und `einvoiceapi` und seedet: +- ein Postfach (`mailimport.Store.Create`, echter Envelope-verschlüsselter Passwortpfad, kein Klartext), +- eine Mail-Regel (`mailimport.CreateRule`, Betreffmuster `(?i)rechnung`, verknüpft mit dem bestehenden `rechnung`-Tag), +- einen Klärungskorb-Eintrag (direkter Insert in `mail_messages`, da es keine öffentliche „Nachricht ohne Regel“-Erzeugungsfunktion gibt — die Importlogik selbst ist bereits durch INT-03/INT-04 geprüft), +- ein Dokument mit E-Rechnung-Ergebnis (`revision_einvoice` und `revision_einvoice_conformance`, Status `valid`/`conformant`, synthetisch). + +`web/a11y-audit/run.sh` bekommt `NEXT_PUBLIC_MAIL_API_URL`/`NEXT_PUBLIC_EINVOICE_API_URL` und die vier neuen Seiten in `pages.txt`. + +**AK2 – Token-Modus-Lauf in `scripts/gesamt-token-smoke.sh`:** +Pragmatischer Weg (wie im Chrome-Nachtragsprotokoll vorgeschlagen): statt `a11y-fixture` hinter die echte Auth-Kette zu hängen, nutzt der neue Schritt den bereits laufenden echten Kontodienst. Ein echter `POST /auth/login` liefert das httpOnly-Sitzungscookie, das per Puppeteer (`page.setCookie`) injiziert wird; danach navigiert ein echter Chrome gegen ein frisch gebautes `dms-browser` im Token-Modus (`NEXT_PUBLIC_AUTH_MODE=token`) gegen das laufende `dms-app`. Neues Skript `scripts/token-mode-a11y.js` (axe-Lauf, hell, ohne die volle Matrix aus `audit.js` – bewusst schlank, weil der Kernzweck der Nachweis ist, dass der Token-Modus überhaupt rendert, nicht eine zweite vollständige Audit-Matrix). + +## Echter Fund und Fix + +Der erste Lauf gegen die vier neuen UX-11-Seiten bei 320 px Breite fand horizontalen Seitenscroll auf `/mail-accounts` (Tabelle 603 px bei 320 px Fensterbreite) und `/mail-rules` (350 px). Beide Tabellen hatten keinen `overflow-x`-Wrapper. Behoben durch `
` um beide Tabellen (Muster, das andernorts im Projekt für breite Tabellen fehlt – die bestehenden Tabellen in `trash`/`audit-log` sind zufällig schmal genug für 320 px). Commit-Nachweis: erster Lauf 2 Verstöße, zweiter Lauf (nach Fix) 0. + +## Prüfungen + +1. **`web/a11y-audit/run.sh` (Übergangsmodus, Wegwerf-Cluster):** 68 Zeilen im Hauptdurchlauf, alle `ok`, axe „keine“ auf allen 32 Seiten×Schema-Kombinationen (28 vorher + 4 neue Seiten × 2 Schemata), Tastatur erreicht auf jeder neuen Seite alle interaktiven Elemente (`mail-accounts` 13/13, `mail-rules` 10/10, `clarification` 5/5, `einvoice` 1/1). Reflow bei 320 px: 0 horizontale Überläufe nach dem Fix (vorher 2). Exit 0. +2. **`scripts/gesamt-token-smoke.sh`, Abschnitt „a11y: Barrierefreiheits-Lauf im echten Token-Modus“:** echter Login gegen den Kontodienst, 5 Seiten (`/browse`, `/trash`, `/mail-accounts`, `/mail-rules`, `/clarification`) je `ok`, axe „keine“, `anmeldeseite: false` (also kein unerwarteter Rückfall auf die Login-Ansicht). Gesamtlauf: 45 von 45 Kern-Prüfungen weiterhin bestanden, `GESAMT-FEHLER=0`. +3. **Rückbau:** Vorher-/Nachher-Snapshot des Gesamtsystem-Smoke ist identisch (`IDENTISCH`). Der separate `a11y-fixture`-Lauf entfernt sein Schema beim Beenden wie zuvor. + +## Regression + +`go build`/`go vet` für das DMS-Modul sauber. `tsc --noEmit`, `vitest run app/mail-accounts app/mail-rules` (5/5 bestanden, unverändert gegenüber UX-11), `next build` (alle 14 Routen inkl. der vier neuen) auf 204 sauber. + +## QA und Entscheidungen + +1. **Klärungskorb-Eintrag per Direkt-Insert statt Importpfad:** Der reale IMAP-Importweg ist bereits durch INT-03/INT-04 geprüft; ein Fixture-Seed muss diesen Weg nicht wiederholen, nur einen Datensatz für den Browserlauf bereitstellen. +2. **Token-Modus-Skript bewusst schlank** (nur axe, kein Tastatur-/Reflow-/Kontrastlauf): Der Kernzweck ist der Nachweis, dass die Seiten im Token-Modus überhaupt korrekt rendern und keine axe-Regression zeigen; die volle Matrix läuft bereits im Übergangsmodus gegen dieselben Komponenten. Eine Verdopplung der gesamten Prüfmatrix im Token-Modus wäre unverhältnismäßig zum Aufwand dieses Tickets. +3. **CORS-Frage nicht vertieft:** Vor dem Lauf wurde vermutet, dass der browserseitige `fetch` von `dms-browser` (Port 4210) zum Kontodienst (Port 8099) an fehlenden CORS-Headern scheitern könnte (`cmd/account-api` hat keine erkennbare CORS-Behandlung). Der reale Lauf zeigte das Gegenteil – alle fünf Seiten rendern authentifiziert. Warum genau (evtl. `no-cors`-Verhalten des konkreten Fetch-Aufrufs, oder Same-Origin durch `127.0.0.1`-Cookie-Scoping) wurde nicht weiter untersucht, da außerhalb des Ticket-Scopes; falls das Verhalten sich als Zufallsartefakt herausstellt, würde ein künftiger CORS-Audit das aufdecken. +0 Iterationen im Sinne ungelöster Bugs – der einzige Fund (Reflow) wurde in einer Runde behoben und real verifiziert. + +## Offen + +- Kein CI-Job führt den Token-Modus-Lauf automatisch aus (FDN-07 betrifft nur den Standardlauf). +- `keyboard-flow.js`/vollständige Kontrastprüfung liefen nicht im Token-Modus, nur im Übergangsmodus.