Splits Umami website-ID per omgeving in productie-build (was per ongeluk gedeeld)

build-production hergebruikte vars.VITE_UMAMI_WEBSITE_ID van de testbuild,
maar Umami-website-ID's horen bij één specifieke domeinentry in het
dashboard. Zonder deze fix zou productieverkeer in de teststatistieken
terechtkomen. Introduceert VITE_UMAMI_WEBSITE_ID_PRODUCTION als losse Gitea
variable, en documenteert dat er twee aparte Umami-website-entries nodig
zijn (test.slpsoftware.nl / slpsoftware.nl). VITE_UMAMI_SCRIPT_URL en
VITE_SENTRY_DSN blijven bewust gedeeld tussen omgevingen.

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

.gitea/workflows/continuous_integration.yaml

@@ -170,11 +170,17 @@ jobs:
 
       - name: Build
         env:
-          # Zelfde Umami/Sentry-variabelen als de testbuild hierboven, want er
-          # is (nog) geen apart productie-Umami-website-ID of -Sentry-project
-          # gekozen. Splits deze pas op zodra dat nodig blijkt.
+          # Umami-website-ID's zijn NIET gedeeld tussen omgevingen: elke Umami
+          # "website"-entry (test.slpsoftware.nl vs slpsoftware.nl) heeft een
+          # eigen ID, anders komt productieverkeer in de teststatistieken
+          # terecht (of andersom). Vereist dus een eigen Umami-website +
+          # Gitea-variable VITE_UMAMI_WEBSITE_ID_PRODUCTION — zie umami-setup.md.
           VITE_UMAMI_SCRIPT_URL: ${{ vars.VITE_UMAMI_SCRIPT_URL }}
-          VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID }}
+          VITE_UMAMI_WEBSITE_ID: ${{ vars.VITE_UMAMI_WEBSITE_ID_PRODUCTION }}
+          # VITE_SENTRY_DSN wordt wél gedeeld met de testbuild: één Sentry-
+          # project voor beide omgevingen, VITE_APP_ENV hieronder tagt de
+          # events al als 'test' vs 'production'. Splits dit pas op als je
+          # ooit aparte Sentry-projecten per omgeving wilt.
           VITE_SENTRY_DSN: ${{ vars.VITE_SENTRY_DSN }}
           VITE_APP_ENV: ${{ env.DEPLOY_ENVIRONMENT_PRODUCTION }}
         run: pnpm run build

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

@@ -74,7 +74,10 @@ Productie deployt **nooit** automatisch bij een push naar `master` — alleen vi
 4. Vink **`deploy_production`** aan voordat je de run start.
 5. Dit triggert naast de gebruikelijke `build`/`test`/`deploy-test` ook `build-production` en `deploy-production`.
 
-Vereist eenmalig vooraf: de Gitea-variable `DEPLOY_PATH_PRODUCTION` (zie boven) en de productie-nginx/SSL-configuratie + webroot-map op de Pi's (zie "Eenmalige Setup — Domeinnaam & DNS").
+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").
 
 ## 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).

aidlc-docs/features/react-frontend/operations/monitoring/umami-setup.md

@@ -185,28 +185,36 @@ uit stap 0.3 is hiervoor al gezet, dus deze service blijft ook draaien zonder da
    wijzigen na eerste login**).
 
 ## 4. Website registreren in Umami en het website-ID ophalen
+Maak een **aparte Umami-website-entry per omgeving** aan — test en productie zijn
+verschillende domeinen en horen dus niet in dezelfde statistieken te belanden:
 1. Log in op `https://analytics.slpsoftware.nl` en wijzig direct het standaardwachtwoord.
-2. Ga naar **Settings → Websites → Add website** en vul in:
-   - Name: `SLP Software` (of naar keuze)
-   - Domain: het domein van de daadwerkelijke website (bv. `slpsoftware.nl` of
-     `test.slpsoftware.nl`, afhankelijk van welke omgeving je eerst wilt meten)
-3. Na het opslaan toont Umami een **Website ID** (een UUID) — dit heb je nodig voor de
-   volgende stap.
+2. Ga naar **Settings → Websites → Add website** en maak een entry voor de testomgeving:
+   - Name: `SLP Software (test)` (of naar keuze)
+   - Domain: `test.slpsoftware.nl`
+3. Na het opslaan toont Umami een **Website ID** (een UUID) voor deze entry — nodig voor
+   `VITE_UMAMI_WEBSITE_ID` in de volgende stap.
+4. Herhaal stap 2-3 voor productie zodra die omgeving wordt opgezet: een tweede website-
+   entry met Domain `slpsoftware.nl`, met een eigen Website ID voor
+   `VITE_UMAMI_WEBSITE_ID_PRODUCTION`.
 
 ## 5. Tracking script koppelen aan de website (build-configuratie)
 De React-app (`src/components/UmamiAnalytics.tsx`) injecteert het Umami tracking-script
-automatisch, mits de volgende twee build-time variabelen zijn ingesteld — beide zijn
-**geen secrets** (client-side zichtbaar), dus als Gitea Actions **repository variables**
+automatisch, mits de volgende build-time variabelen zijn ingesteld — geen van deze zijn
+**secrets** (client-side zichtbaar), dus als Gitea Actions **repository variables**
 (niet secrets), net als `VITE_SENTRY_DSN`:
 
 | Variabele | Waarde |
 |---|---|
-| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` |
-| `VITE_UMAMI_WEBSITE_ID` | het Website ID uit stap 4 |
+| `VITE_UMAMI_SCRIPT_URL` | `https://analytics.slpsoftware.nl/script.js` (gedeeld tussen test en productie — zelfde Umami-instance/endpoint voor beide) |
+| `VITE_UMAMI_WEBSITE_ID` | het Website ID van de **test**-website-entry uit stap 4 |
+| `VITE_UMAMI_WEBSITE_ID_PRODUCTION` | het Website ID van de **productie**-website-entry uit stap 4 (pas nodig vóór de eerste `deploy_production`-run) |
 
-Stel deze in via **Gitea → Repository Settings → Actions → Variables**. Zodra beide
-bestaan, pakt de eerstvolgende build ze automatisch op; zonder deze variabelen slaat de
-app het inladen van het script gewoon over (geen crash, geen tracking).
+Stel deze in via **Gitea → Repository Settings → Actions → Variables**. Zodra ze bestaan,
+pakt de eerstvolgende build ze automatisch op; zonder deze variabelen slaat de app het
+inladen van het script gewoon over (geen crash, geen tracking). Let op:
+`continuous_integration.yaml`'s `build`-job (test) leest `VITE_UMAMI_WEBSITE_ID`, de
+`build-production`-job leest `VITE_UMAMI_WEBSITE_ID_PRODUCTION` — verwissel deze niet,
+anders komt productieverkeer in de teststatistieken terecht (of andersom).
 
 **Lokaal (`pnpm dev`)**: het tracking-script wordt hier bewust nooit geladen (zie
 `UmamiAnalytics.tsx`), zodat lokaal testen de bezoekersstatistieken niet vervuilt. Wil je
@@ -220,8 +228,9 @@ dit toch lokaal testen, zet dan tijdelijk beide waarden in `.env.local` (zie
 - [ ] Systemd user-service instellen (onder de `umami`-user) voor auto-start na reboot.
 - [ ] DNS-record + certbot voor `analytics.slpsoftware.nl` op de reverse-proxy-Pi.
 - [ ] Standaard Umami-wachtwoord direct wijzigen na eerste login.
-- [ ] Website aanmaken in Umami en het Website ID overnemen.
+- [ ] Website aanmaken in Umami voor de testomgeving en het Website ID overnemen.
 - [ ] `VITE_UMAMI_SCRIPT_URL` en `VITE_UMAMI_WEBSITE_ID` als Gitea repository variables instellen.
+- [ ] Zodra productie wordt opgezet: aparte website aanmaken in Umami voor `slpsoftware.nl` en het Website ID als `VITE_UMAMI_WEBSITE_ID_PRODUCTION` instellen (zie stap 4/5 hierboven — vereist vóór de eerste `deploy_production`-run).
 
 ## Vervolgstappen voor toekomstige self-hosted diensten
 Dit dedicated-user-patroon (stap 0 hierboven) is bewust generiek gehouden zodat het