Merge branch 'master' into feature/analytics_uptime_dashboard
# Conflicts: # .env.example # aidlc-docs/features/react-frontend/aidlc-state.md # aidlc-docs/features/react-frontend/audit.md # aidlc-docs/features/react-frontend/operations/monitoring/monitoring-plan.md # aidlc-docs/features/react-frontend/operations/monitoring/monitoring-setup.md # aidlc-docs/features/react-frontend/operations/production-readiness-checklist.md # src/components/RootLayout.tsx # src/vite-env.d.ts
This commit is contained in:
@@ -433,6 +433,138 @@
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: SCP Method Fixed (Docker/Podman Issue) & nginx Configs Finalized
|
||||
|
||||
**Timestamp**: 2026-07-25T12:22:00Z
|
||||
|
||||
**User Input**: "ik heb de deploy-workflow iets aangepast. De originele manier werkte niet met Docker/Podman. De huidige manier werkt wel. Kan je dat doorvoeren door de documentatie? Verder heb ik in `reverse-proxy-nginx.conf.example` en `webserver-nginx.conf.example` onder de comment '# Gebruikte versie' de daadwerkelijke versie staan. Dit werkt nu. Kan je de configuraties controleren en als example opnemen ipv jouw variant? Controleer even of alle headers goed genoemd zijn of dat je andere foutjes ziet. [...] De productieversie mag je van mij ook weg doen voor nu."
|
||||
|
||||
**AI Response**: "Confirmed the user's own fix to `deploy.yaml` (already merged to `master` externally): the `appleboy/scp-action` Docker-container-action failed on the self-hosted Podman-based runner (`failed to attach to container: unable to upgrade to tcp, received 409`); replaced with a plain `run:` step using `sshpass`+`scp`. Updated `deployment-instructions.md`, `deployment-plan.md` and `rollback-plan.md` to describe this. Replaced both nginx example files with only the user's 'Gebruikte versie' configs (removed the earlier draft variants), found and fixed a header typo (`X-Real_IP` should be `X-Real-IP`) in `reverse-proxy-nginx.conf.example`, and flagged a path discrepancy: the pipeline uploads to `/html/test/slpsoftware` while nginx's `root` is `/mnt/storage1/www/html/test/slpsoftware` (documented as needing a symlink/mount check on the Pi). Deleted `nginx/reverse-proxy-nginx-production.conf.example` per explicit request."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); reconciles documentation with manual workflow/nginx changes made directly by the user outside this session. Changes not yet committed/pushed.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Path Difference Between `deploy_path` and nginx `root` Clarified
|
||||
|
||||
**Timestamp**: 2026-07-25T12:33:00Z
|
||||
|
||||
**User Input**: "Ik zie dat je het pad-verschil hebt opgemerkt van wat er in de nginx config staat en wat er wordt meegegeven in de deploy-workflow. Het pad op de server zelf en wat gebruikt wordt voor de nginx configuratie is het volledige pad `/mnt/storage1/www/html/test/slpsoftware` terwijl de ftp gebruiker als root heeft `/mnt/storage1/www` dus het pad voor deployment is `/html/test/slpsoftware`. Misschien dat dat verschil wat mooier kan worden verwoord in de documentatie"
|
||||
|
||||
**AI Response**: "Reworded the earlier 'path discrepancy — verify on the Pi' warning in `deployment-instructions.md` and `rollback-plan.md`: this is not a potential bug requiring verification, but expected behavior, since the SCP/SSH user's root is `/mnt/storage1/www` (comparable to an FTP chroot). `deploy_path` (`/html/test/slpsoftware`) is therefore the correct path relative to that user's root, which on the Pi's actual filesystem resolves to the full path `/mnt/storage1/www/html/test/slpsoftware` used as nginx's `root`."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); clarifies wording of the previous follow-up's path-discrepancy note per user feedback. Changes not yet committed/pushed.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Client-Side Error Logging Destination Decided (Sentry)
|
||||
|
||||
**Timestamp**: 2026-07-25T12:55:00Z
|
||||
|
||||
**User Input**: "Als het goed is stonden er nog een paar punten open? Zullen we het volgende punt oppakken? Kan je ook een feature-branch aanmaken met een passende naam? [...]" — followed by selecting "Logging-bestemming kiezen" and then "Sentry (free tier)" as the concrete destination.
|
||||
|
||||
**AI Response**: "Picked up the next open follow-up from `production-readiness-checklist.md`: the client-side error logging destination. Created feature branch `feature/sentry_error_logging` (carrying over the previously uncommitted path-documentation changes, committed there first). Added `@sentry/react` as a dependency, initialized it in `src/main.tsx` via `Sentry.init({ dsn: import.meta.env.VITE_SENTRY_DSN })` (no-op if the DSN is unset), added `src/vite-env.d.ts` for `import.meta.env` typing, and hooked `ErrorBoundary.componentDidCatch` to also call `Sentry.captureException`. Wired the DSN as a Gitea Actions repository variable (`vars.VITE_SENTRY_DSN`, not a secret) into the `Build` step of `continuous_integration.yaml`. Updated `monitoring-plan.md`, `monitoring-setup.md`, and `production-readiness-checklist.md` to mark this open item resolved, with the remaining manual step (creating the actual `VITE_SENTRY_DSN` Gitea variable with a real Sentry DSN) called out explicitly."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); resolves open follow-up #2 from `production-readiness-checklist.md`. Work done on new branch `feature/sentry_error_logging`.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Sentry Setup Checked Against Official Instrumentation Guide
|
||||
|
||||
**Timestamp**: 2026-07-25T13:20:00Z
|
||||
|
||||
**User Input**: "Ik zie dat sentry al helemaal is ingericht, maar ik kreeg vanuit Sentry zelf de volgende prompt voor het opzetten. Kan je kijken of je misschien dingen hebt gemist of dat er alsnog wat nodig is: Use curl to download, read and follow https://skills.sentry.dev/instrument to set up the Sentry React SDK."
|
||||
|
||||
**AI Response**: "Fetched and read the official Sentry instrumentation guide and its React/Vite-specific reference. Compared it against the existing setup and found the following gaps: (1) no tracing/performance monitoring configured (the guide's recommended default is errors + tracing, not errors alone), (2) no `environment`/`release` tags, (3) no TanStack Router tracing integration, (4) no automatic source map upload (stack traces would show minified code in production). Asked the user which gaps to address; they chose tracing and environment/release tags, explicitly declining source maps for now. Implemented: added `tanstackRouterBrowserTracingIntegration(router)` + `tracesSampleRate: 1.0` and `environment: import.meta.env.MODE` + `release: __APP_VERSION__` to `Sentry.init()` in `src/main.tsx`; `__APP_VERSION__` is injected at build time from `package.json`'s version via a new `define` block in `vite.config.ts` (typed in `src/vite-env.d.ts`). Updated `monitoring-setup.md` to describe the new tracing/environment/release behavior and explicitly note that source map upload was deliberately left out of scope (would require a new Sentry auth-token/org/project secret)."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch with a gap-check against Sentry's own official setup guide. Build, lint and tests re-verified successfully after the change.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Temporary Sentry Test Button Added (Dev/Test Only)
|
||||
|
||||
**Timestamp**: 2026-07-25T13:41:00Z
|
||||
|
||||
**User Input**: "Ik heb hier een code snippet met een intentionele fout om sentry te kunnen testen. Kan je die ergens toevoegen zodat we tijdelijk een test hebben of misschien iets slims bedenken zodat het alleen in development- en testomgevingen zichtbaar is" (a `Sentry.logger.info` + `Sentry.metrics.count` + throw snippet for a "Break the world" button).
|
||||
|
||||
**AI Response**: "Added `src/components/SentryTestButton.tsx`, mounted globally via `RootLayout.tsx`. Extracted the click logic into an exported `handleSentryTestErrorClick` function for reliable unit testing (React error boundaries don't catch event-handler errors, so the throw is intentionally left uncaught for Sentry's global handler to pick up). Added `enableLogs: true` to `Sentry.init()` in `main.tsx`, required for `Sentry.logger.*` calls. Introduced a new build-time `VITE_APP_ENV` variable (typed in `vite-env.d.ts`, set to `DEPLOY_ENVIRONMENT` i.e. `test` in the `Build` step of `continuous_integration.yaml`) so the button is only visible during local development (`import.meta.env.DEV`) or when explicitly built for the test environment — hidden by default, including in any future production build. Added `SentryTestButton.test.tsx` (2 tests) and updated `monitoring-setup.md` with a new subsection documenting this temporary tool and noting it should be removed once Sentry has been confirmed to receive test errors/logs/metrics end-to-end."
|
||||
|
||||
**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.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Sentry "Tunnel" Added to Bypass Ad-Blocker on Test Environment
|
||||
|
||||
**Timestamp**: 2026-07-25T15:30:00Z
|
||||
|
||||
**User Input**: "Op de testomgeving heb ik hetzelfde. Laten we de tunnel-fix toevoegen" (confirming the same `ERR_BLOCKED_BY_CLIENT` ad-blocker issue also occurs on the test environment, after previously choosing "just disable the ad-blocker" for local development).
|
||||
|
||||
**AI Response**: "Added `tunnel: import.meta.env.DEV ? undefined : '/sentry-tunnel'` to `Sentry.init()` in `src/main.tsx`, so built (test/production) environments route Sentry traffic through the app's own domain instead of posting straight to `*.ingest.de.sentry.io` — this makes the request first-party from the browser's perspective, so ad-blockers no longer recognize/block it as third-party tracking. Local development is left untouched (tunnel stays `undefined`), since the user already resolved that case by disabling the ad-blocker. Added a `location /sentry-tunnel` block to `nginx/reverse-proxy-nginx.conf.example` that forwards to Sentry's envelope endpoint for the specific org/project baked into the DSN, with a comment flagging that this must be kept in sync if the Sentry project/DSN ever changes. Updated `monitoring-setup.md` with a new bullet explaining the tunnel approach, why it works here (full control over the reverse-proxy Pi's nginx config) and its limitation (would not work on a third-party host without reverse-proxy access)."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. `pnpm run build`, `pnpm run lint` and `pnpm run test` re-verified successfully after the change. Changes not yet committed/pushed.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Sentry "Tunnel" Extended to Local Development
|
||||
|
||||
**Timestamp**: 2026-07-25T15:45:00Z
|
||||
|
||||
**User Input**: "Is het ook gefixt voor lokaal?" — followed by: "Ja voeg voor lokaal ook een tunnel toe".
|
||||
|
||||
**AI Response**: "Added a `server.proxy` entry for `/sentry-tunnel` in `vite.config.ts`, forwarding to the same Sentry envelope endpoint as the reverse-proxy Pi's nginx tunnel (matching the org/project baked into the local `.env.local` DSN). Simplified `src/main.tsx`'s `tunnel` option from the previous `import.meta.env.DEV ? undefined : '/sentry-tunnel'` to an unconditional `'/sentry-tunnel'`, since `pnpm dev` now also has a matching proxy route — local testing no longer requires disabling the ad-blocker. Updated `monitoring-setup.md` to describe the tunnel as active in all environments (including local), and to flag that the org/project id must stay in sync across the nginx config, the Vite proxy target, and the configured DSN."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch. `pnpm run build`, `pnpm run lint` and `pnpm run test` re-verified successfully after the change. Changes not yet committed/pushed.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Regenerated Build Artifacts Removed from Git Tracking
|
||||
|
||||
**Timestamp**: 2026-07-25T15:47:00Z
|
||||
|
||||
**User Input**: "ik wil niet dat er wijzigingen open blijven staan lokaal. zorg dat je ze mee-commit of ignored. Als het nodig is maak je een lokale versie die ignored moet worden."
|
||||
|
||||
**AI Response**: "Investigated the two remaining locally-modified files (`tsconfig.node.tsbuildinfo`, `vite.config.js`) and confirmed both are build artifacts regenerated by `tsc -b` (per `tsconfig.node.json`, which has no `outDir`/`noEmit`, `vite.config.ts` gets compiled to `vite.config.js` right next to it, and its own incremental-build cache is `tsconfig.node.tsbuildinfo`) — neither is source, so committing their contents would just cause perpetual diff noise. Removed both from git tracking (`git rm --cached`) and added them to `.gitignore` alongside the already-ignored `tsconfig.tsbuildinfo`, so they remain on disk (needed for `tsc -b` to work) but are never tracked again."
|
||||
|
||||
**Context**: Post-workflow follow-up (feature already marked Complete); continues the `feature/sentry_error_logging` branch, ensuring no local changes are left uncommitted/untracked.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Sentry Logging Follow-up Confirmed Working & Closed
|
||||
|
||||
**Timestamp**: 2026-07-25T16:04:00Z
|
||||
|
||||
**User Input**: "het werkt zoals ik zou verwachten. De feature mag afgerond worden. De documentatie updaten en committen. Dan door naar het volgende openstaande punt en ook daarvoor een feature branch aanmaken."
|
||||
|
||||
**AI Response**: "User confirmed Sentry (errors, logs, and metrics via the tunnel) works as expected, both locally and on the test environment. Updated `monitoring-setup.md`, `monitoring-plan.md`, and `production-readiness-checklist.md` to mark the 'client-side error logging destination' open follow-up as resolved and verified end-to-end, leaving only the manual `VITE_SENTRY_DSN` Gitea repository variable creation as an outstanding step for the test/production build. Also corrected `aidlc-state.md`'s stale `Current Stage`/`Branch` fields to reflect that the workflow is complete and work is happening on `feature/sentry_error_logging`."
|
||||
|
||||
**Context**: Closes out the Sentry logging-destination follow-up. Three open follow-ups remain per `production-readiness-checklist.md`: production hosting/deploy, analytics/uptime dashboard tool selection, and a formal Lighthouse performance check.
|
||||
|
||||
---
|
||||
|
||||
## Post-Completion Follow-up: Analytics + Uptime Dashboard Tools Decided (Umami self-hosted + UptimeRobot)
|
||||
|
||||
**Timestamp**: 2026-07-25T16:10:00Z
|
||||
|
||||
Reference in New Issue
Block a user