Laufzettel/docs/issues/038-e2e-im-tor.md

#038 Die E2E-Abläufe laufen in keinem Tor und waren monatelang rot

Status: erledigt Im Tracker: – Meilenstein: v0.2.0 Labels: phase-2, test, infra Geschätzt: 3 h Tatsächlich: 1 h 35 min

Ziel

Beim Abschluss von #027 lief pnpm test:e2e erstmals seit dem 26. September wieder vollständig. Sieben Abläufe waren rot, und niemand hatte es gemerkt.

Keiner der sieben war ein Produktfehler — und genau das ist das Problem. Vier Ursachen:

Ablauf	Ursache	Seit
laeufe.spec.ts	zählt die Felder des Zustands auf, anzahlAnhaenge fehlte	#033
stammdaten.spec.ts	„kommt aus dem Verzeichnis“ steht seit #020 zweimal auf der Seite	#020
vorlagen-editor.spec.ts	zieht am Handy feste 300 px, der Abstand ist 532 px	#030/#031
onboarding.spec.ts	die Entwicklungsdaten wichen vom Seed ab	unbekannt

Alle vier sind behoben. Das Muster bleibt: die E2E-Schicht trägt Zusagen, die das Commit-Tor nicht fährt — Rückfall auf Polling, Herzschlag, 390 px, die Auslieferung eines Anhangs über seine Adresse. Steht eine Zusage nur in Playwright, und läuft Playwright nur gelegentlich, dann ist sie eine Notiz und keine Prüfung.

Zu entscheiden

• pnpm test:e2e ins Tor vor dem Commit? → Nein. Dagegen: es verlangt einen gebauten, laufenden Stand (pnpm build && pnpm start), dauert über vier Minuten und braucht eine Datenbank mit Seed-Bestand. Vier Minuten vor jedem Commit ist ein Tor, das umgangen wird.
• Gewählt: eine kleinere, verbindliche Regel. E2E läuft vor jedem Merge nach main — das wären acht Läufe in Phase 2 gewesen und hätte jeden der vier Befunde am Tag seiner Entstehung gezeigt. Das ist die Empfehlung.
• Nicht im CI (.gitea/workflows/ci.yml). Dort ist kein Runner registriert; das zu ändern ist eine eigene Entscheidung und gehört nicht in dieses Issue.

Aufgaben

• Die gewählte Regel in CLAUDE.md aufschreiben, mit gemessener Dauer und der Begründung, warum sie nicht im Commit-Tor steht
• Die Voraussetzungen, die tests/e2e/global-setup.ts prüft, in derselben Reihenfolge dokumentieren — der Vorlauf ist inzwischen die ehrlichste Beschreibung dessen, was E2E braucht
• Prüfen, welche Zusagen ausschließlich in E2E stehen, und für jede entscheiden: gehört sie zusätzlich in einen Vitest-Test, der den Handler direkt fährt? (Das Muster steht in tests/scim.test.ts, tests/anhang-route.test.ts und tests/lauf-ereignisse.test.ts.)
• Mindestens die Rechteprüfung der beiden Phase-2-Handler ist damit schon abgedeckt — bleiben Rückfall auf Polling, Herzschlag am echten Browser und 390 px

Akzeptanzkriterien

• In CLAUDE.md steht, wann E2E läuft, und die Angabe ist gemessen, nicht geschätzt
• Eine Liste der Zusagen, die nur in E2E stehen — und zu jeder eine Entscheidung

Die Entscheidung, und was sie gekostet hat

Nicht im Commit-Tor. Gemessen am 2026-10-11: Bau 14 s, Start 7 s, Abläufe 256 s — zusammen 4 min 37 s, zu den vier Minuten des bestehenden Tores. Neun Minuten vor jedem Commit ist ein Tor, das umgangen wird, und ein umgangenes Tor prüft nichts.

Vor jedem Merge nach main. In Phase 2 wären das acht Läufe gewesen, und jeder der vier Befunde aus #027 wäre am Tag seiner Entstehung aufgefallen. Die Regel steht in CLAUDE.md mit den gemessenen Zahlen und der Begründung; docs/architektur.md §5b trägt sie mit.

Nicht im CI, weil dort kein Runner registriert ist. Das zu ändern ist eine eigene Entscheidung und gehört nicht in dieses Issue.

Die Liste der Zusagen — und was sich davon holen ließ

Geprüft wurde jeder der 16 Abläufe gegen die Frage „gibt es dafür ein Vitest-Gegenstück?“. Das Ergebnis steht als Tabelle in CLAUDE.md. Die Kurzfassung:

Nichts davon lässt sich nach Vitest holen — alle brauchen einen echten Browser: Layout bei 390 px, BarcodeDetector, Touch-Ereignisse, zwei Browser-Kontexte gleichzeitig, Zwischenablage, Print-CSS, gerendertes DOM, und überhaupt die Hydrierung. Die Antwort auf #038 ist deshalb nicht „verlagern“, sondern „regelmäßig laufen lassen“.

Was sich holen ließ, ist geholt — und das war mehr als erwartet:

• Die Rechteprüfung der Route Handler steht seit #036 in tests/anhang-route.test.ts, tests/lauf-ereignisse.test.ts und tests/scim.test.ts: die Handler werden mit echten Request-Objekten gefahren, nicht über die Oberfläche.

• Neu in diesem Issue: tests/zugang.test.ts prüft strukturell, dass jede page.tsx unter (app) und jeder route.ts sein Recht selbst prüft. Die Ausnahmen (Auth, Healthcheck) stehen dort namentlich samt Begründung, und ein Test prüft auch die Gegenrichtung: eine Ausnahme für einen Handler, den es nicht mehr gibt, verdeckt beim nächsten Mal einen echten Befund.

  Dass das nötig war, ist der eigentliche Fund: die Zusage „jede Seite prüft selbst“ steht seit #007 in CLAUDE.md, und sie hielt bis hierher nur durch Nachsehen von Hand. Der Review von Phase 2 hat alle 27 Seiten durchgesehen — das gilt für den Tag, an dem es lief. Beide Gegenproben (eine Seite, ein Handler ohne Prüfung) werden jetzt rot.