fix: pull_policy build -- der Auto-Deploy zog, baute aber nie

Der erste Verdacht ("kein Runner") war die halbe Wahrheit. Portainers
GitOps-Weg funktioniert, nachgemessen in seinem eigenen Datenverzeichnis:

    /d/compose/1/src/melden.js     12:48   <- die Uhrzeit des Pushes
    /d/compose/1/stack.env         12:57   <- Portainer hat neu geschrieben
    docker images d4rkbot:latest   00:21   <- das Abbild 15 Stunden alt

Portainer holt den neuen Stand also brav ins Stack-Verzeichnis und ruft dann
docker compose up -d. UND DAS BAUT NUR, WENN DAS ABBILD FEHLT. d4rkbot:latest
gab es -- also kein Bau, kein neuer Container, und der Bot lief weiter mit dem
Code von vorgestern.

Kein Runner, kein Webhook, keine Fehlermeldung: es sah nach "nichts zu tun"
aus. Das ist die unangenehme Sorte Fehler -- man pusht, hakt es ab, und der
Fehler, den man gerade behoben hat, laeuft weiter.

pull_policy: build laesst compose bei jedem Ausrollen neu bauen. Geprueft mit
docker compose config (v5.3.1 nimmt es an und gibt es aufgeloest zurueck).

Einmal noch von Hand, denn die Zeile wirkt erst, wenn sie selbst ausgerollt
ist: Portainer -> Stack ecobot -> Pull and redeploy.

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

docker-compose.yml

@@ -5,6 +5,18 @@ services:
   d4rkbot:
     build: .
     image: d4rkbot:latest
+    # IMMER neu bauen, nicht nur wenn das Abbild fehlt.
+    #
+    # Ohne das ist der Auto-Deploy ein Leerlauf, und das war er: Portainer zieht
+    # den neuen Stand brav ins Stack-Verzeichnis (nachgemessen -- die Dateien
+    # trugen die Uhrzeit des Pushes) und ruft dann `docker compose up -d`. Das
+    # baut aber nur, wenn das Abbild FEHLT. `d4rkbot:latest` gab es, also
+    # passierte nichts: kein Bau, kein Neustart, und der Bot lief weiter mit dem
+    # Code von vorgestern.
+    #
+    # Das ist die unangenehme Sorte Fehler -- man pusht, hakt es ab, und der
+    # Fehler, den man gerade behoben hat, laeuft weiter.
+    pull_policy: build
     container_name: d4rkbot
     restart: unless-stopped
     # Werte kommen per Interpolation: lokal aus der .env im Projektordner (liest

docs/befunde-2026-08-12.md

@@ -314,9 +314,36 @@ Code im Container         grep pruefeSicherung -> 0   <- der alte Stand
 abarbeitet — und der Webhook-Weg (der ohne Runner auskäme) ist offenbar auch
 nicht eingerichtet.
 
-**Das heißt: pushen allein rollt nichts aus.** Bis einer der beiden Wege steht,
-gilt weiterhin der Weg von Hand — Portainer → Stack `ecobot` → *Pull and
-redeploy*.
+### Nachgefasst: er zieht, aber er baut nicht
+
+Der erste Verdacht („kein Runner") war nur die halbe Wahrheit. Portainers
+GitOps-Weg **funktioniert** — nachgemessen in seinem eigenen Datenverzeichnis:
+
+```
+/d/compose/1/src/melden.js        12:48   <- die Uhrzeit meines Pushes
+/d/compose/1/stack.env            12:57   <- Portainer hat neu geschrieben
+docker images d4rkbot:latest      00:21   <- das Abbild ist 15 Stunden alt
+```
+
+Portainer holt den neuen Stand also brav ins Stack-Verzeichnis und ruft dann
+`docker compose up -d`. **Und das baut nur, wenn das Abbild fehlt.**
+`d4rkbot:latest` gab es — also kein Bau, kein neuer Container, und der Bot lief
+weiter mit dem Code von vorgestern. Kein Runner, kein Webhook und keine
+Fehlermeldung; es sah nach „nichts zu tun" aus.
+
+**Die Zeile, die gefehlt hat**, steht jetzt in `docker-compose.yml`:
+
+```yaml
+pull_policy: build
+```
+
+Damit baut `docker compose up -d` das Abbild bei jedem Ausrollen neu. Geprüft
+mit `docker compose config` (Compose v5.3.1 nimmt es an und gibt es aufgelöst
+zurück).
+
+**Einmal noch von Hand**, denn die Zeile wirkt erst, wenn sie selbst ausgerollt
+ist: Portainer → Stack `ecobot` → *Pull and redeploy*. Danach greift der
+Auto-Deploy von allein.
 
 Das ist keine Kleinigkeit für die Zukunft: ein Deploy, von dem man glaubt, dass
 er automatisch läuft, ist schlimmer als gar keiner. Man pusht, hakt es ab, und