UX-14: Prüfprotokoll

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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 `<div style={{overflowX:"auto"}}>` 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.