fix: keep proxy healthy during tls pending

docs/deployment.md

@@ -42,9 +42,10 @@ is safe only when firewall/network policy makes the load balancer the sole NGINX
 caller and it overwrites `X-Forwarded-*` headers.
 
 For direct TLS, public DNS and inbound ports 80/443 must reach NGINX. Start with
-`LETSENCRYPT_STAGING=1`; application HTTP returns 503 until a certificate exists, then
-redirects to HTTPS. Switch to the production CA only after validating DNS and firewall
-behavior, removing only the staging certificate volume when necessary.
+`LETSENCRYPT_STAGING=1` and set `WP_URL` to the final HTTPS URL. Application HTTP
+returns 503 until a certificate exists, then redirects to HTTPS. Switch to the
+production CA only after validating DNS and firewall behavior, removing only the
+staging certificate directory when necessary.
 
 ## State and rollback
 

docs/runbook.md

@@ -31,6 +31,25 @@ Verify public DNS, inbound port 80, the operator email, and staging mode. Reques
 missing `/.well-known/acme-challenge/` path: an NGINX 404 confirms the route is yours.
 Avoid repeated production-CA retries while debugging.
 
+When Let's Encrypt is enabled, the proxy intentionally returns 503 for normal
+application paths until a certificate exists. ACME challenge paths and proxy health
+paths must still work in that pending state, otherwise Certbot will never start.
+
+## Bootstrap writes to the wrong data volume
+
+Do not combine the test override with production bootstrap commands. This command writes
+to isolated test volumes only:
+
+```bash
+docker compose -f docker-compose.yml -f docker-compose.test.yml --profile tools run --rm wp-cli /scripts/bootstrap.sh
+```
+
+Use this command for the real host-based WordPress data directory:
+
+```bash
+docker compose --profile tools run --rm wp-cli /scripts/bootstrap.sh
+```
+
 ## Rollback
 
 Revert the deployment commit and rebuild while preserving all host data directories.