docs: Testebenen dokumentieren, Version 0.6.0

FEATURES beschreibt beide Ebenen - Unit-Tests ohne Datenbank und
Ende-zu-Ende-Tests gegen die gebaute Anwendung - samt der beiden
Vorkehrungen gegen einen Lauf auf der echten Datenbank. Dazu die
Voraussetzungen fuer Gitea Actions.

ROADMAP: der Testausbau war Punkt 1 und ist erledigt; Benachrichtigungen
ruecken auf.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

FEATURES.md

@@ -402,8 +402,10 @@ nicht verloren gehen. Indizes auf Status, Verbindung und Änderungsdatum.
 
 ### 6.4 Tests
 
-`npm test` führt die Unit-Tests aus — reine Logik, kein DOM, keine Datenbank, unter einer
-Sekunde:
+Zwei Ebenen. `npm run test:all` führt beide aus.
+
+**`npm test` — Unit-Tests** (Vitest, 56 Stück, unter einer Sekunde, ohne DOM und ohne
+Datenbank):
 
 | Bereich | Was geprüft wird |
 | --- | --- |
@@ -411,11 +413,42 @@ Sekunde:
 | `git/parse` | URL-Zerlegung für https, SSH, verschachtelte GitLab-Gruppen und Oberflächenpfade; Provider-Erkennung; Bildung der Aktivitätskurve |
 | `security/ssrf` | Sperrlisten für Loopback, Link-Local, Metadaten-Endpunkt, CGNAT und Multicast; Formprüfung; die drei Umgebungsschalter |
 | `auth/password` | scrypt-Rundlauf, unterschiedliches Salz, Ablageformat, Verhalten bei kaputten Hashes, Passwortregeln |
+| `tasks` | Berechnung des abgeleiteten Fortschritts, Spaltenreihenfolge |
 
-Bewusst ohne Datenbank- und Browsertests: die brauchen Infrastruktur und gehören in eine
-CI-Pipeline. Das steht in der [ROADMAP](ROADMAP.md).
+**`npm run test:e2e` — Ende-zu-Ende** (Playwright, 13 Stück, rund 20 Sekunden). Läuft
+gegen die gebaute Anwendung mit eigener Datenbank auf Port 3111 — also durch Middleware,
+Authentifizierung, Validierung und Datenbank hindurch:
 
-### 6.5 API
+| Datei | Was geprüft wird |
+| --- | --- |
+| `e2e/api.spec.ts` | Einrichtung sperrt sich nach dem ersten Konto · kein Zugriff ohne Anmeldung · fremdes Origin und falscher Content-Type abgewiesen · SSRF geblockt · **Datentrennung zwischen zwei Konten** · Aufgaben-Reihenfolge, abgeleiteter Fortschritt und untergeschobene IDs · Export ohne Geheimnisse, Import je Strategie |
+| `e2e/ui.spec.ts` | Anmelden · Projekt anlegen · Aufgaben anlegen und **per Ziehen verschieben** (inklusive Prüfung nach dem Neuladen) · Volltextsuche · Abmelden sperrt geschützte Seiten wieder |
+
+Zwei Dinge sind bewusst so gebaut:
+
+- **Die Testdatenbank kann nicht die echte sein.** `e2e/global-setup.ts` bricht ab, wenn
+  der Datenbankname nicht `test` enthält — vor dem `TRUNCATE`. Der teuerste denkbare
+  Fehler wäre eine Testreihe, die die Produktivdaten leert.
+- **Playwright startet den Server selbst** (`webServer` in `playwright.config.ts`) mit
+  eigener `DATABASE_URL` und eigenem Port. Eine laufende Instanz auf 3000 stört nicht.
+
+Einmalig vorbereiten:
+
+```bash
+docker exec nebula-db psql -U nebula -d postgres -c "CREATE DATABASE nebula_e2e_test"
+```
+
+### 6.5 Fortlaufende Prüfung
+
+`.gitea/workflows/ci.yml` prüft jeden Push und jeden Pull Request: Typen, Unit-Tests,
+Bau und Ende-zu-Ende-Tests gegen einen frischen PostgreSQL-Dienst. Schlägt etwas fehl,
+wird der Playwright-Bericht als Artefakt abgelegt.
+
+Dafür müssen in der Gitea-Instanz Actions aktiviert sein (`app.ini`: `[actions] ENABLED
+= true`) und ein Runner registriert. Die Syntax ist GitHub-kompatibel — für GitHub die
+Datei nach `.github/workflows/` kopieren.
+
+### 6.6 API
 
 Zehn REST-Endpunkte für Projekte, Notizen, Verbindungen, Sync, Repo-Listen und Health.
 Alles, was die Oberfläche kann, ist damit auch scriptbar. Übersicht in der

README.md

@@ -301,6 +301,9 @@ nebula/
 | `npm test` | Unit-Tests (Vitest), unter einer Sekunde |
 | `npm run test:watch` | Tests im Beobachtungsmodus |
 | `npm run typecheck` | TypeScript prüfen |
+| `npm test` | Unit-Tests (Vitest, ohne Datenbank) |
+| `npm run test:e2e` | Ende-zu-Ende-Tests (Playwright, baut vorher) |
+| `npm run test:all` | Beides nacheinander |
 | `npm run docker:db` | Nur die Datenbank starten |
 | `npm run docker:up` / `docker:down` | Kompletten Stack starten / stoppen |
 | `npm run docker:tools` | Adminer auf `http://localhost:8080` |

ROADMAP.md

@@ -11,20 +11,7 @@ Was bereits steht, listet [FEATURES.md](FEATURES.md).
 
 ## 1 · Als Nächstes empfohlen
 
-### 1.1 Tests ausbauen: Datenbank und Browser `L`
-
-Das Fundament steht — 51 Unit-Tests der reinen Logik laufen in unter einer
-Sekunde. Was fehlt, ist die Schicht darüber:
-
-- **Integrationstests** gegen eine Wegwerf-Datenbank: Datentrennung zwischen
-  Konten, Import-Strategien, Backoff des Abgleichs
-- **Playwright** für die Wege durch die App: Einrichtung, Anmeldung, Kanban
-- **CI-Pipeline** bei GitHub oder Gitea Actions
-
-Ich prüfe bislang alles von Hand, inklusive Screenshots. Das trägt nicht
-dauerhaft und macht jede weitere Änderung teurer als nötig.
-
-### 1.2 Benachrichtigungen `M`
+### 1.1 Benachrichtigungen `M`
 
 Bei Sync-Fehlern, roter CI, neuen Releases oder Projekten, die lange
 stillstehen. Kanäle: E-Mail (SMTP), ntfy, generischer Webhook. Zusammen mit
@@ -129,6 +116,7 @@ Damit klar ist, was **nicht** kommt und warum:
 | **v0.3.0** Markdown, Volltextsuche über Notizen, PR- und Issue-Listen, Testfundament | ✓ |
 | **v0.4.0** Kanban mit Drag & Drop, CI-Status je Branch, Commit-Aktivität | ✓ |
 | **v0.5.0** Aufgabenbrett je Projekt mit sortierbaren Spalten, Fortschritt aus Aufgaben | ✓ |
+| **v0.6.0** Ende-zu-Ende-Tests mit Playwright, CI-Pipeline für Gitea Actions | ✓ |
 
 Zur Entscheidung beim Export: Git-Tokens gehen **nicht** mit. Die Verbindung wird nur
 beschrieben, das Token ist nach dem Import neu zu hinterlegen. Snapshots bleiben