Voeg productie-nginx-voorbeeldconfiguratie toe voor de reverse-proxy-Pi

production-nginx.conf.example (vóór certbot) en
production-nginx.conf.post-certbot.example (referentie, na certbot) dekken
alléén de react-frontend-site op slpsoftware.nl/www.slpsoftware.nl; de
mail/iRedAdmin-proxying die op de daadwerkelijke productieserver ook op dit
domein draait valt buiten de scope van deze feature en is bewust
weggelaten. Bevat de acme-challenge location in het 443-blok (niet het
poort-80-blok) en de sentry-tunnel-proxy, analoog aan de testomgeving-
configuratie. Documentatie in deployment-plan.md en
deployment-instructions.md bijgewerkt met productie-nginx-setupstappen.

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

aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md

@@ -47,14 +47,21 @@ Dit vervangt het eerder hardcoded `DEPLOY_PATH` in het `env:`-blok van `continuo
 
 ## Eenmalige Setup — Domeinnaam & DNS
 - **Test**: `test.slpsoftware.nl` → moet als DNS A-record wijzen naar het publieke IP van de reverse-proxy-Pi.
-- **Productie** (domein al bekend, nginx/SSL-configuratie op de Pi's moet nog opgezet worden): `slpsoftware.nl` (en `www.slpsoftware.nl`) → zelfde reverse-proxy-Pi. De deploy-pipeline zelf ondersteunt productie al (zie hieronder); wat nog ontbreekt is de nginx/SSL-configuratie en het aanmaken van de webroot-map op de Pi's, analoog aan de teststappen hieronder.
+- **Productie** (domein al bekend, nginx/SSL-configuratie op de Pi's moet nog opgezet worden voor de react-frontend): `slpsoftware.nl` (en `www.slpsoftware.nl`) → zelfde reverse-proxy-Pi. De deploy-pipeline zelf ondersteunt productie al (zie hieronder); wat nog ontbreekt is de webroot-map op de webserver-Pi, analoog aan de teststappen hieronder.
 
 ## Eenmalige Setup — nginx & SSL op de Raspberry Pi's
+### Test
 1. Kopieer `operations/deployment/nginx/webserver-nginx.conf.example` naar `/etc/nginx/sites-available/` op de webserver-Pi, maak een symlink in `sites-enabled/`, en herlaad nginx. Dit bestand is de daadwerkelijk in gebruik zijnde configuratie (`server_name test.slpsoftware.nl`, luistert op poort 80, serveert vanaf `/mnt/storage1/www/html/test/slpsoftware`).
 2. Kopieer `operations/deployment/nginx/reverse-proxy-nginx.conf.example` naar `/etc/nginx/sites-available/slpsoftware-test.conf` op de reverse-proxy-Pi, maak een symlink in `sites-enabled/`, en herlaad nginx. Dit is de versie van vóór certbot (alleen poort 80, geen SSL), met `server_name test.slpsoftware.nl`.
 3. Vraag op de reverse-proxy-Pi een SSL-certificaat aan met certbot (Let's Encrypt), nadat het DNS-record klopt: `sudo certbot --nginx -d test.slpsoftware.nl`. Certbot herschrijft dit bestand automatisch met de HTTPS-configuratie en de HTTP→HTTPS-redirect — zie `operations/deployment/nginx/reverse-proxy-nginx.conf.post-certbot.example` voor hoe het er dan uitziet (referentie, niet zelf kopiëren).
 4. Zorg dat de map `/mnt/storage1/www/html/test/slpsoftware` bestaat op de webserver-Pi en schrijfbaar is voor de gebruiker `webadmin` (bijv. `sudo mkdir -p /mnt/storage1/www/html/test/slpsoftware && sudo chown webadmin:webadmin /mnt/storage1/www/html/test/slpsoftware`).
 
+### Productie
+De reverse-proxy-Pi bedient op `slpsoftware.nl`/`www.slpsoftware.nl` in werkelijkheid meer dan alleen deze react-frontend-site (o.a. mail/iRedAdmin-proxying naar een aparte host) — dat valt buiten de scope van deze feature. De onderstaande voorbeeldbestanden dekken alléén het react-frontend-gedeelte:
+1. Kopieer `operations/deployment/nginx/production-nginx.conf.example` naar `/etc/nginx/sites-available/slpsoftware.conf` op de reverse-proxy-Pi (of voeg het `location`/`server`-gedeelte toe aan een bestaand bestand als daar al andere server-blocks voor dit domein in staan), maak een symlink in `sites-enabled/`, en herlaad nginx. Dit is de versie van vóór certbot (alleen poort 80, geen SSL).
+2. Vraag op de reverse-proxy-Pi een SSL-certificaat aan met certbot, nadat de DNS-records kloppen: `sudo certbot --nginx -d slpsoftware.nl -d www.slpsoftware.nl`. Certbot herschrijft dit bestand automatisch — zie `operations/deployment/nginx/production-nginx.conf.post-certbot.example` voor hoe het er dan uitziet (referentie, niet zelf kopiëren). Let op: de acme-challenge location hoort in het 443-blok, niet in het losse poort-80-blok — zie de toelichting in dat referentiebestand.
+3. Zorg dat de productie-webroot-map bestaat op de webserver-Pi en schrijfbaar is voor `webadmin` (bijv. `sudo mkdir -p /mnt/storage1/www/html/slpsoftware && sudo chown webadmin:webadmin /mnt/storage1/www/html/slpsoftware`), analoog aan stap 4 van de testomgeving.
+
 > **Waarom `deploy_path` en de nginx `root` niet hetzelfde pad zijn**: de pipeline uploadt via SCP naar `deploy_path` = `/html/test/slpsoftware` (de waarde van de Gitea variable `DEPLOY_PATH_TEST`, ingelezen via `env.DEPLOY_PATH` in `continuous_integration.yaml`), terwijl de nginx `root` in `webserver-nginx.conf.example` het volledige pad `/mnt/storage1/www/html/test/slpsoftware` is. Dit is geen fout of inconsistentie: de SSH/SCP-gebruiker (`webadmin`) heeft `/mnt/storage1/www` als root (vergelijkbaar met een FTP-chroot), dus vanuit het perspectief van deze gebruiker is `/html/test/slpsoftware` het juiste (relatieve) pad, terwijl dat op het bestandssysteem van de Pi zelf overeenkomt met het volledige pad `/mnt/storage1/www/html/test/slpsoftware` dat nginx als `root` gebruikt. Kortom: `deploy_path` (`/html/test/slpsoftware`) + de root van de `webadmin`-gebruiker (`/mnt/storage1/www`) = de nginx `root` (`/mnt/storage1/www/html/test/slpsoftware`).
 
 ## How to Deploy to Test
@@ -77,7 +84,7 @@ Productie deployt **nooit** automatisch bij een push naar `master` — alleen vi
 Vereist eenmalig vooraf:
 - De Gitea-variable `DEPLOY_PATH_PRODUCTION` (zie boven).
 - De Gitea-variable `VITE_UMAMI_WEBSITE_ID_PRODUCTION` (zie `umami-setup.md` stap 4/5) — zónder deze wordt productieverkeer per ongeluk meegeteld bij de teststatistieken.
-- De productie-nginx/SSL-configuratie + webroot-map op de Pi's (zie "Eenmalige Setup — Domeinnaam & DNS").
+- De productie-nginx/SSL-configuratie + webroot-map op de Pi's (zie "Eenmalige Setup — nginx & SSL op de Raspberry Pi's → Productie").
 
 ## Verifying a Deployment
 1. Bevestig dat de Gitea Actions run succesvol is (alle relevante jobs groen — `deploy-test` altijd, `build-production`/`deploy-production` alleen als je `deploy_production` had aangevinkt).
@@ -85,5 +92,5 @@ Vereist eenmalig vooraf:
 
 ## Future Work
 - **Van wachtwoord naar SSH-key**: vervang `sshpass -p "${{ secrets.PI_MAIN_PASSWORD }}" scp ...` in `deploy.yaml` door een `scp`-commando met `-i <key-bestand>` (een nieuwe secret `PI_MAIN_SSH_KEY` die je eerst als bestand wegschrijft in de run-stap), en zet de bijbehorende public key in `~/.ssh/authorized_keys` van de `webadmin`-gebruiker op de webserver-Pi. Verwijder daarna het wachtwoord-secret.
-- **Productie nginx/SSL-configuratie**: de deploy-pipeline ondersteunt productie al (`build-production`/`deploy-production`), maar er is nog geen productie-nginx-voorbeeldconfiguratie — deze is op verzoek van de gebruiker verwijderd totdat er een goed-werkende versie is, en kan later opnieuw opgebouwd worden naar analogie van `nginx/webserver-nginx.conf.example` en `nginx/reverse-proxy-nginx.conf.example`, met domein `slpsoftware.nl`.
+- **Webserver-Pi-vhost voor productie**: er is nog geen `webserver-nginx.conf.example`-tegenhanger voor productie (de vhost op de webserver-Pi zelf die `slpsoftware.nl` serveert vanaf de productie-webroot). Bouw die op naar analogie van `nginx/webserver-nginx.conf.example`, met `server_name slpsoftware.nl www.slpsoftware.nl` en de productie-webroot als `root`.
 - **Apart productie-Sentry-project**: `build-production` gebruikt momenteel dezelfde `VITE_SENTRY_DSN` als de testbuild (Umami heeft al aparte website-ID's per omgeving, zie `umami-setup.md`). Overweeg dit te splitsen zodra test- en productie-events niet meer door elkaar gemengd mogen worden in hetzelfde Sentry-project.