Add local dev Sentry DSN support and fix environment tag for test vs. production

Co-authored-by: Junie <junie@jetbrains.com>

.env.example

@@ -0,0 +1,10 @@
+# Voorbeeldbestand voor lokale environment-variabelen (Vite).
+# Kopieer dit naar `.env.local` (die is al gitignored via de "*.local" regel)
+# en vul je eigen waarden in. `.env.local` overschrijft niets in Gitea CI/CD —
+# die gebruikt zijn eigen repository variables/secrets (zie continuous_integration.yaml).
+
+# Sentry DSN (Data Source Name) voor client-side error/performance-monitoring.
+# Geen secret — een DSN is veilig om client-side te tonen. Maak een (gratis)
+# Sentry-project aan op https://sentry.io en plak hier de DSN van dat project.
+# Laat leeg/weg om Sentry lokaal uit te schakelen (alleen console-logging blijft actief).
+VITE_SENTRY_DSN=

aidlc-docs/features/react-frontend/audit.md

@@ -492,3 +492,27 @@
 **Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. `pnpm run build`, `pnpm run lint` (0 errors, pre-existing-style warnings only) and `pnpm run test` (16/16 tests) all succeeded. Changes not yet committed/pushed.
 
 ---
+
+## Post-Completion Follow-up: Local Development Sentry DSN Added
+
+**Timestamp**: 2026-07-25T14:48:00Z
+
+**User Input**: "Kunnen we voor lokaal development ook een DSN toevoegen? Kan dat eventueel in een lokale environment file of iets?" (with a Sentry DSN value provided).
+
+**AI Response**: "Added a `.env.local` file containing the user-provided `VITE_SENTRY_DSN` for local development (`pnpm dev`) — already covered by the existing `.gitignore` `*.local` rule, so it is never committed. Added a committed `.env.example` template (empty `VITE_SENTRY_DSN` value) documenting how to set this up for other/future contributors. Updated `monitoring-setup.md` with a new bullet explaining the local-DSN workflow and recommending a separate Sentry project/DSN for local development so its noise doesn't mix with the test-environment data."
+
+**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. No code logic changes — only local-only config and documentation.
+
+---
+
+## Post-Completion Follow-up: Sentry `environment` Tag Fixed to Distinguish Test vs. Production
+
+**Timestamp**: 2026-07-25T14:52:00Z
+
+**User Input**: "Volgens mij hadden we iets van een onderscheiding tussen de test en productie-omgevingen. Is dat ook met de development-omgeving?"
+
+**AI Response**: "Identified a real gap: `environment: import.meta.env.MODE` correctly reports `'development'` for `pnpm dev`, but both the test build and any future production build run via `vite build` without an explicit mode, so `MODE` is always `'production'` for both — meaning Sentry would currently tag test-environment events as `'production'`, indistinguishable from real production. Fixed by changing `environment` to `import.meta.env.VITE_APP_ENV ?? import.meta.env.MODE` in `src/main.tsx`: this uses the already-existing `VITE_APP_ENV` build-time variable (`'test'`/`'production'`) when set, falling back to `MODE` only for local development where `VITE_APP_ENV` is unset. Updated `monitoring-setup.md` to describe this corrected behavior."
+
+**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. Build/lint/test re-verified after the change.
+
+---

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

@@ -19,8 +19,9 @@ Both the console and Sentry are now active (original Question 3 resolved as a co
 - `@sentry/react` is a dependency; `src/main.tsx` calls `Sentry.init({ ... })` at startup, but only when a DSN is present — if not configured, Sentry is silently skipped and only console-logging remains active (safe default, no crash on missing config).
 - `ErrorBoundary.componentDidCatch` calls `Sentry.captureException(error, { extra: { componentStack: info.componentStack } })` in addition to `console.error`.
 - **Tracing/performance** is also enabled (Sentry's recommended default alongside error monitoring, per the official React SDK setup guide): `tanstackRouterBrowserTracingIntegration(router)` is wired up so route navigations are captured as transactions, with `tracesSampleRate: 1.0` (capture all — appropriate for a low-traffic marketing site; lower this if traffic grows significantly).
-- **Environment/release tagging**: `environment` is set to `import.meta.env.MODE` (e.g. `production`) and `release` is set to the app version from `package.json` (injected at build time via `vite.config.ts`'s `define: { __APP_VERSION__ }`), so events in Sentry can be filtered/grouped per environment and per shipped version.
+- **Environment/release tagging**: `environment` is set to `import.meta.env.VITE_APP_ENV` (`'test'` / `'production'`, set at build time — see below), falling back to `import.meta.env.MODE` for local development (`pnpm dev` → `'development'`). This fallback is needed because `vite build` runs in production mode by default regardless of target environment, so `MODE` alone cannot distinguish a test build from a production build. `release` is set to the app version from `package.json` (injected at build time via `vite.config.ts`'s `define: { __APP_VERSION__ }`), so events in Sentry can be filtered/grouped per environment and per shipped version.
 - The DSN is injected at build time via Vite's `import.meta.env.VITE_SENTRY_DSN` (typed in `src/vite-env.d.ts`). It is **not** a secret (Sentry DSNs are safe to expose client-side), so it is passed as a **Gitea Actions repository variable** (`vars.VITE_SENTRY_DSN`, not a secret) to the `Build` step in `continuous_integration.yaml`.
+- **Local development DSN**: for `pnpm dev`, Vite automatically loads a `.env.local` file (already covered by `.gitignore`'s `*.local` rule, so it is never committed). Copy `.env.example` to `.env.local` and set `VITE_SENTRY_DSN` there to enable Sentry locally — a separate Sentry project/DSN is recommended so local test noise doesn't mix with the test-environment data. Omitting `.env.local` (or leaving the value empty) simply disables Sentry locally, falling back to console-only logging.
 - **Manual follow-up required**: create a free Sentry project (https://sentry.io) for this app, copy its DSN, and set it as the `VITE_SENTRY_DSN` repository variable in Gitea (Repository Settings → Actions → Variables). Until that variable is set, the build still succeeds and the site still works — Sentry reporting simply stays inactive.
 - Free tier limits (error volume, retention) are typically sufficient for a low-traffic marketing site.
 - **Not (yet) implemented, by explicit choice**: automatic source map upload (via `@sentry/vite-plugin`), which the official Sentry setup guide also recommends so stack traces show real source code instead of minified code. This requires a Sentry auth token/org/project as a new Gitea secret; deliberately left out of scope for now — revisit if readable production stack traces become a priority.

src/main.tsx

@@ -10,7 +10,10 @@ const sentryDsn = import.meta.env.VITE_SENTRY_DSN;
 if (sentryDsn) {
   Sentry.init({
     dsn: sentryDsn,
-    environment: import.meta.env.MODE,
+    // VITE_APP_ENV ('test' | 'production') distinguishes test vs. production builds — both use
+    // `vite build` without an explicit mode, so MODE alone would tag both as 'production'.
+    // Falls back to MODE for local development (`pnpm dev` -> 'development').
+    environment: import.meta.env.VITE_APP_ENV ?? import.meta.env.MODE,
     release: __APP_VERSION__,
     integrations: [Sentry.tanstackRouterBrowserTracingIntegration(router)],
     // Low-traffic marketing site: capture all traces (lower this if traffic grows significantly).