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

**Status:** offen
**Im Tracker:** –
**Meilenstein:** v0.3.0
**Labels:** phase-2, test, infra
**Geschätzt:** 3 h   **Tatsächlich:** –

## Ziel

Beim Abschluss von [#027](027-e2e-reste-vorlagen.md) 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?** 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.
- [ ] **Oder 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.
- [ ] **Oder 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