diff --git a/PLAN_TESTUMGEBUNG_2026-08-12.md b/PLAN_TESTUMGEBUNG_2026-08-12.md
index 83a5819..2e7ba12 100644
--- a/PLAN_TESTUMGEBUNG_2026-08-12.md
+++ b/PLAN_TESTUMGEBUNG_2026-08-12.md
@@ -121,9 +121,9 @@ NEXT_PUBLIC_INDEXABLE=false
 
 # Eigene DB im Test-Stack
 POSTGRES_USER=postgres
-POSTGRES_PASSWORD=<eigenes>
-POSTGRES_DB=qrmaster
-DATABASE_URL=postgresql://postgres:<eigenes>@db:5432/qrmaster?schema=public
+POSTGRES_PASSWORD=<eigenes, hex - ein "/" aus base64 zerlegt die DATABASE_URL>
+POSTGRES_DB=qrmaster_test
+# DATABASE_URL nicht setzen - Compose baut sie aus den drei Werten oben
 
 # Test-Keys / leer, siehe Falle 3
 STRIPE_SECRET_KEY=sk_test_…
@@ -175,9 +175,15 @@ networks:
     driver: bridge
 ```
 
-`POSTGRES_DB` auf Test **gleich lassen** (`qrmaster`): der Healthcheck hat `pg_isready -d
-qrmaster` hartkodiert ([Zeile 19](docker-compose.yml:19)) und würde bei abweichendem Namen den
-Container als unhealthy melden. Die Trennung kommt vom Volume, nicht vom Datenbanknamen.
+`POSTGRES_DB` heißt auf Test `qrmaster_test`. Die Trennung kommt zwar schon vom eigenen
+Container und Volume, aber der abweichende Name macht bei einer von Hand getippten
+`psql`-Sitzung sofort sichtbar, auf welcher Instanz man ist - die billigste Versicherung
+gegen ein `DELETE` in der falschen Datenbank.
+
+Dafür muss der Healthcheck mitgezogen werden: das Basis-File hat `pg_isready -d qrmaster`
+hartkodiert ([Zeile 19](docker-compose.yml:19)). Ohne Override prüft er eine Datenbank, die
+es nicht gibt, der Container bleibt `unhealthy`, und `web` startet wegen
+`depends_on: condition: service_healthy` nie.
 
 Start:
 
@@ -222,11 +228,11 @@ Eigene PostgreSQL-Instanz im Test-Stack, befüllt mit **Struktur ohne Zeilen**.
 Kundendaten verlassen die Produktion.
 
 ```bash
-# auf dem Server, aus dem Prod-Stack
-docker compose exec db pg_dump -U postgres --schema-only qrmaster > /tmp/schema.sql
+# Struktur aus Prod ziehen (keine Zeilen)
+docker exec qrmaster-db pg_dump -U postgres --schema-only qrmaster > schema.sql
 
-# in den Test-Stack einspielen
-docker compose -p qrmaster-test exec -T db psql -U postgres qrmaster < /tmp/schema.sql
+# in die Test-DB einspielen
+docker exec -i qrmaster-test-db psql -U postgres -d qrmaster_test < schema.sql
 ```
 
 Danach einen Testaccount anlegen - entweder über das Signup-Formular auf testmodul oder per
diff --git a/docker-compose.test.yml b/docker-compose.test.yml
index 09fd620..1c02db2 100644
--- a/docker-compose.test.yml
+++ b/docker-compose.test.yml
@@ -12,6 +12,12 @@ services:
     container_name: qrmaster-test-db
     # Production already publishes 5435 on the host.
     ports: !reset []
+    # The base file hardcodes the database name in the probe. Staging uses its own name so a
+    # hand-typed psql session makes it obvious which instance you are on - without this
+    # override the probe would check a database that does not exist, the container would stay
+    # unhealthy and web (depends_on: service_healthy) would never start.
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U postgres -d qrmaster_test"]
     # Only on the internal network. `db` and `redis` are network aliases assigned per
     # compose project, so leaving them on the shared external network would make `db`
     # resolve to two containers and this stack could reach the production database.