Finishes monitoring process in aidlc

2026-07-24 15:21:31 +02:00
parent 11250a584e
commit b8b0cd2e2c
8 changed files with 290 additions and 8 deletions
@@ -2,4 +2,4 @@

 | Feature | Status | Branch | Affected Components | Session Start |
 |---------|--------|--------|---------------------|---------------|
-| react-frontend | 🟡 Operations | master | React frontend (SLP Software marketing site) | 2026-07-18 |
+| react-frontend | ✅ Complete | master | React frontend (SLP Software marketing site) | 2026-07-18 |
@@ -5,7 +5,7 @@
 - **Feature Slug**: react-frontend
 - **Project Type**: Greenfield
 - **Start Date**: 2026-07-18T00:37:00Z
- **Current Stage**: OPERATIONS - Deployment Setup Complete, awaiting approval
+- **Current Stage**: OPERATIONS - Monitoring Setup (in progress)
 - **Branch**: master

 ## Workspace State
@@ -37,6 +37,10 @@
 - **Included**: Yes
 - **Method**: Manually-triggered Gitea Actions pipeline (build/test/lint gate + artifact packaging); actual host upload is manual for now, to be automated later

+### Monitoring Setup
+- **Included**: Yes
+- **Approach**: Combination (Logging + Dashboards; Alerting explicitly out of scope)
+
 ## Execution Plan Summary
 - **Total Stages**: 10 (2 skipped, 8 executed)
 - **Stages to Execute**: Functional Design, NFR Requirements, NFR Design, Code Generation, Build and Test, Deployment Setup, Monitoring Setup, Production Readiness Validation
@@ -62,11 +66,11 @@

 ### 🟡 OPERATIONS PHASE
 - [x] Deployment Setup (EXECUTE) - Completed 2026-07-19
- [ ] Monitoring Setup (EXECUTE)
- [ ] Production Readiness Validation (EXECUTE)
+- [x] Monitoring Setup (EXECUTE) - Completed 2026-07-24
+- [x] Production Readiness Validation (EXECUTE) - Completed 2026-07-24

 ## Current Status
- **Lifecycle Phase**: OPERATIONS
- **Current Stage**: Deployment Setup Complete, awaiting approval
- **Next Stage**: Monitoring Setup (Operations Phase)
- **Status**: Ready to proceed
+- **Lifecycle Phase**: Complete
+- **Current Stage**: Complete
+- **Next Stage**: N/A
+- **Status**: Workflow complete
@@ -287,3 +287,52 @@
 **Context**: Deployment Setup (OPERATIONS PHASE) - requested change addressed, re-presenting completion message.

 ---
+
+## Deployment Setup - Approved
+
+**Timestamp**: 2026-07-19T23:20:00Z
+
+**User Input**: "Commit en ga door naar de volgende fase"
+
+**AI Response**: "Deployment Setup approved. Committed all deployment artifacts (.gitea/workflows/deploy.yml, deployment-plan.md, deployment-instructions.md, rollback-plan.md) to git. Proceeding to Monitoring Setup (OPERATIONS PHASE)."
+
+**Context**: Deployment Setup stage complete and approved; moving to Monitoring Setup.
+
+---
+
+## Monitoring Setup - Answers Reviewed, Clarification Needed
+
+**Timestamp**: 2026-07-21T00:16:00Z
+
+**User Input**: "ga verder met de aidlc workflow. ik heb de vragen over het monitoring plan beantwoord" (answers filled in directly in operations/plans/monitoring-setup-plan.md: Q1:A, Q2:A, Q3:C, Q4:S, Q5:C, Q6:C, Q7:A)
+
+**AI Response**: "Detected a contradiction: Question 2 answer is 'A' (Logging only), yet Question 4, 5 and 6 (only relevant for Alerting/Dashboards) were also answered, implying the user may actually want Alerting and/or Dashboards too. Also detected an invalid answer on Question 4 ('S' is not one of the offered A-E options). Created operations/plans/monitoring-setup-clarification-questions.md with 2 clarification questions to resolve both issues before generating monitoring artifacts."
+
+**Context**: Monitoring Setup (OPERATIONS PHASE) - Step 5, contradiction/ambiguity detection; awaiting user clarification before proceeding to Step 6 (artifact generation).
+
+---
+
+## Monitoring Setup - Clarification Answers Received, Artifacts Generated
+
+**Timestamp**: 2026-07-24T15:00:00Z
+
+**User Input**: "Ik heb de vragen ingevuld" (clarification answers filled in directly in operations/plans/monitoring-setup-clarification-questions.md: Clarification Q1:C (Logging + Dashboards, no Alerting), Clarification Q2:D (not applicable / decide later)).
+
+**AI Response**: "Read and validated the clarification answers: chosen approach resolved to Logging + Dashboards, Alerting explicitly out of scope. Generated operations/monitoring/monitoring-plan.md (decision, chosen approaches, rationale, open items) and operations/monitoring/monitoring-setup.md (concrete logging destination options, analytics + uptime dashboard tool options and setup steps). Updated aidlc-state.md: Operations Configuration > Monitoring Setup (Included: Yes, Approach: Combination) and Stage Progress marked complete."
+
+**Context**: Monitoring Setup (OPERATIONS PHASE) - Step 6/7 artifacts generated; presenting completion message, awaiting approval before Production Readiness Validation.
+
+---
+
+## Production Readiness Validation - Complete
+
+**Timestamp**: 2026-07-24T15:12:00Z
+
+**User Input**: "ga verder" (approval to proceed to Production Readiness Validation)
+
+**AI Response**: "Reviewed Deployment Setup and Monitoring Setup outcomes; no blocking gaps requiring new user questions were found (remaining items are already-tracked open follow-ups: host upload automation, logging destination, analytics/uptime tool selection, formal Lighthouse run). Generated operations/production-readiness-checklist.md with Overall Readiness = 'Yes with caveats'. Marked Production Readiness Validation and the overall feature as Complete in aidlc-state.md, and updated active-features.md status to ✅ Complete."
+
+**Overall Readiness**: Yes with caveats
+**Feature Status**: Complete
+
+---
@@ -0,0 +1,34 @@
+# Monitoring Plan
+
+## Context
+This feature is a static marketing website (`dist/` bundle, no back-end, no database) currently deployed manually via a build artifact (see `operations/deployment/deployment-plan.md`). There is no existing monitoring/logging infrastructure in this project yet.
+
+## Decision
+Monitoring/observability is **included** for this feature (Question 1 = A / clarified further via Clarification Question 1).
+
+Initial answers to the monitoring plan were contradictory: Question 2 selected "Logging" only (A), yet the alerting/dashboard follow-up questions (4, 5, 6) were also answered, and the answer to Question 4 (`S`) was not a valid option. A clarification round was run (`operations/plans/monitoring-setup-clarification-questions.md`) to resolve this before generating artifacts.
+
+**Clarified answer**: **Logging + Dashboards** (Clarification Question 1 = C). Alerting is explicitly **out of scope** for this feature at this time (Clarification Question 2 = D, "not needed yet / decide later" — consistent with not choosing Alerting in Clarification Question 1).
+
+## Chosen Approach(es)
+
+### Logging
+Client-side errors (JavaScript crashes, broken links) should be logged, but the concrete destination is not yet decided (original Question 3 = C, "not yet determined"). This is tracked as an **open action item** below rather than blocking this stage.
+
+### Dashboards
+A combination of:
+- **Website analytics** (visitors, page views, basic engagement) — e.g. a simple/free tool such as Plausible, Umami, or Google Analytics/Search Console.
+- **Uptime dashboard** (site reachability) — e.g. an external monitoring service such as UptimeRobot or Better Uptime.
+
+(Original Question 6 = C, "Both (analytics + uptime dashboard)".)
+
+## Explicitly Out of Scope
+- **Alerting/notifications**: not requested. If the uptime dashboard tool supports basic notifications (e.g. UptimeRobot's own e-mail alert on downtime), that MAY be enabled opportunistically as part of dashboard setup, but no dedicated alerting channel, escalation policy, or alert-on-error-rate logic is designed or required here.
+- **Reuse of existing infrastructure**: this feature does not plug into any pre-existing shared monitoring (original Question 7 = A) — there is none yet. Should a shared back-end/CMS monitoring stack be introduced later, this can be revisited.
+
+## Open Action Items
+1. **Decide logging destination**: choose between "browser console only" (no central storage, manual debugging) or a free/low-cost external error-tracking service (e.g. Sentry free tier) once this becomes a priority. Until decided, `monitoring-setup.md` documents both options so either can be adopted without re-doing this stage.
+2. **Pick concrete analytics + uptime tools**: `monitoring-setup.md` lists candidate free-tier tools; final tool selection/account creation is a manual follow-up outside this workflow (no code changes required to swap providers, since neither is wired into the codebase yet beyond an optional embed snippet).
+
+## Rationale
+Given this is a simple static marketing site with no backend and no existing monitoring, the aim is lightweight, low/no-cost observability: enough to know if the site is down (uptime) and how it's being used (analytics), plus a documented (if not yet finalized) path for capturing client-side errors. Alerting was deliberately left out to avoid over-engineering a notification pipeline before there's a concrete trigger/audience for it.
@@ -0,0 +1,62 @@
+# Monitoring Setup Instructions
+
+Concrete setup steps for the approaches chosen in `monitoring-plan.md`: **Logging** and **Dashboards** (no Alerting).
+
+## Logging
+
+### What to log
+- Uncaught JavaScript errors / exceptions (the app already has an `ErrorBoundary` component from Code Generation — this is the natural hook point).
+- Broken/failed navigation (e.g. an unexpected router error).
+- No user PII, form input, or sensitive data should ever be logged — this is a public marketing site, but keep this discipline regardless.
+
+### Destination — open decision
+The destination was not finalized (original Question 3 = C). Two supported options, either of which can be adopted later without further design work:
+
+**Option 1: Browser console only (default today)**
+- No code changes needed — errors already surface via `console.error` inside the existing `ErrorBoundary`.
+- Zero cost, but not centrally visible; only useful for manual debugging (e.g. via a user's screenshot or a support request).
+
+**Option 2: External error-tracking service (e.g. Sentry free tier)**
+- When decided, add `@sentry/react` as a dependency, initialize it once in the app entry point (e.g. `src/main.tsx`) with the project DSN, and report caught errors from the `ErrorBoundary`'s `componentDidCatch`/`onError` hook to Sentry in addition to the console.
+- Store the DSN as a Gitea Actions variable (or a build-time `.env` value, since it's not a secret — Sentry DSNs are safe to expose client-side) and inject it via Vite's `import.meta.env`.
+- Free tier limits (error volume, retention) are typically sufficient for a low-traffic marketing site.
+
+**Log level strategy**: only errors are logged (no verbose/info-level client logging) — this is a static site with no meaningful "business events" beyond page views, which are covered by analytics (see Dashboards below), not logging.
+
+## Dashboards
+
+### Website analytics
+Pick one (all have generous free tiers suitable for a small marketing site):
+
+| Option | Notes |
+|---|---|
+| Plausible / Umami | Privacy-friendly, lightweight, no cookie banner typically required; self-hosted or low-cost hosted tier |
+| Google Analytics (GA4) / Search Console | Free, widely known, but heavier script and involves third-party data sharing (cookie/consent implications) |
+
+**Setup (once a tool is picked)**:
+1. Create an account/site entry with the chosen provider and obtain the tracking snippet or `<script>` tag.
+2. Add the snippet to `index.html` (or load it conditionally in `src/main.tsx`) — this is a documentation/config task, not something the current codebase needs restructuring for.
+3. Key metrics to surface: unique visitors, page views per route (Home, Packages, etc. — see `frontend-components.md`), and referral sources.
+
+### Uptime dashboard
+Pick one:
+
+| Option | Notes |
+|---|---|
+| UptimeRobot | Free tier: up to 50 monitors, 5-minute check interval, optional e-mail notification on downtime (opportunistic, not a designed alerting feature per `monitoring-plan.md`) |
+| Better Uptime | Free tier available; similar capability, nicer public status page option |
+
+**Setup (once a tool is picked)**:
+1. Register the production URL (once hosting is finalized — see `operations/deployment/deployment-plan.md` "Open Item") as an HTTP(S) monitor, checking for a `200` response.
+2. Optional: publish a public status page if desired for transparency to visitors.
+3. Key metric to surface: uptime percentage / current status.
+
+## Summary Table
+
+| Concern | Approach | Status |
+|---|---|---|
+| Client-side errors | Logging (console today; Sentry free tier optional later) | Destination open item |
+| Visitor/usage insight | Analytics dashboard (Plausible/Umami/GA4) | Tool selection open item |
+| Site reachability | Uptime dashboard (UptimeRobot/Better Uptime) | Tool selection + production URL open item |
+| Alerting | Out of scope | Not configured |
+| Shared infrastructure reuse | Out of scope | None exists yet |
@@ -0,0 +1,31 @@
+# Monitoring Setup Clarification Questions
+
+Ik heb je antwoorden in `monitoring-setup-plan.md` bekeken en twee dingen gevonden die ik moet verduidelijken voordat ik de monitoring-artefacten kan opstellen.
+
+## Contradictie 1: Gekozen aanpak vs. beantwoorde vervolgvragen
+Bij **Question 2 (Monitoring-aanpak)** heb je **A) Logging** gekozen, wat zou betekenen dat alleen Question 3 (logging-bestemming) relevant is. Maar je hebt ook Question 4, 5 en 6 beantwoord — deze zijn alleen relevant als je óók Alerting en/of Dashboards wilt. Dit is tegenstrijdig: kies je alleen Logging, of wil je ook Alerting en Dashboards?
+
+### Clarification Question 1
+Welke monitoring-aanpak(en) wil je daadwerkelijk voor deze feature?
+
+A) Alleen Logging (Question 4, 5 en 6 worden dan genegeerd)
+B) Logging + Alerting (geen Dashboards)
+C) Logging + Dashboards (geen Alerting)
+D) Een combinatie van Logging, Alerting én Dashboards
+E) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]: C
+
+## Ambiguïteit 1: Ongeldig antwoord op Question 4
+Je antwoord op **Question 4 (Alerting — kanaal)** was `S`, wat geen geldige optie is (de opties waren A t/m E). Ik kan hier niet uit afleiden welk kanaal je bedoelt.
+
+### Clarification Question 2
+Via welk kanaal wil je gewaarschuwd worden als er iets misgaat (bijv. de site is onbereikbaar)? (Alleen relevant als je bij Clarification Question 1 voor Alerting kiest.)
+
+A) E-mail
+B) Slack of Teams
+C) Sms/telefonische melding
+D) Nog niet nodig / later bepalen
+E) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]: D
@@ -0,0 +1,78 @@
+# Monitoring Setup Questions
+
+Context: deze feature is een statische marketing-website (`dist/` bundel, geen back-end, geen database) die voorlopig handmatig via een build-artifact naar een host geüpload wordt (zie `operations/deployment/deployment-plan.md`). Er is nog geen bestaande monitoring-/logging-infrastructuur in dit project.
+
+Beantwoord elke vraag door de letter van je keuze na de `[Answer]:` tag in te vullen.
+
+## Question 1: Include Monitoring Setup?
+Wil je dat monitoring/observability voor deze feature wordt opgezet als onderdeel van deze workflow?
+
+A) Ja — help me met het opzetten van monitoring
+B) Nee — deze feature hergebruikt bestaande gedeelde monitoring, of monitoring is voorlopig niet nodig
+C) Niet zeker — stel een aanpak voor op basis van het project en ik beslis dan
+X) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]: A
+
+## Question 2: Monitoring-aanpak
+Welke vormen van monitoring wil je voor deze feature? (Kies de dichtstbijzijnde match — je kunt aanpakken combineren in je antwoord.)
+
+A) Logging — gestructureerde applicatielogs (fouten, belangrijke gebeurtenissen)
+B) Alerting/notificaties — automatische meldingen als er iets misgaat (e-mail, Slack, PagerDuty, sms)
+C) Dashboards — visueel overzicht van statistieken/gezondheid (bijv. bezoekers, foutpercentage, laadtijd)
+D) Een combinatie van bovenstaande
+E) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]: A
+
+## Question 3: Logging — bestemming
+Als je logging wilt: waar moeten client-side fouten (bijv. JavaScript-crashes, gebroken links) naartoe gelogd worden?
+
+A) Alleen browserconsole (geen centrale opslag, puur voor handmatig debuggen)
+B) Een gratis/eenvoudige externe foutregistratieservice (bijv. Sentry free tier)
+C) Nog niet bepaald — vermeld dit als open actiepunt in de instructies
+D) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]: C
+
+## Question 4: Alerting — kanaal (alleen relevant als je alerting wilt)
+Via welk kanaal wil je gewaarschuwd worden als er iets misgaat (bijv. de site is onbereikbaar)?
+
+A) E-mail
+B) Slack of Teams
+C) Sms/telefonische melding
+D) Nog niet nodig / later bepalen
+E) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]: S
+
+## Question 5: Alerting — waarop reageren (alleen relevant als je alerting wilt)
+Waar moet een alert op afgaan?
+
+A) De site is onbereikbaar (uptime-check faalt)
+B) Er treden veel JavaScript-fouten op bij bezoekers
+C) Beide (uptime + fouten)
+D) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]:C
+
+## Question 6: Dashboards (alleen relevant als je dashboards wilt)
+Welk soort dashboard/tool heeft de voorkeur voor een overzicht van bezoekers/gezondheid van de site?
+
+A) Eenvoudige, gratis website-analytics (bijv. Plausible, Umami, of een gratis Google Analytics/Search Console-achtig overzicht)
+B) Uptime-dashboard van een externe monitoringdienst (bijv. UptimeRobot, Better Uptime)
+C) Beide (analytics + uptime-dashboard)
+D) Nog niet nodig / later bepalen
+E) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]:C
+
+## Question 7: Hergebruik van bestaande infrastructuur
+Moet deze feature aansluiten op monitoring die je elders al gebruikt (bijv. voor een ander project of de toekomstige back-end/CMS), in plaats van iets nieuws op te zetten?
+
+A) Nee, dit is voorlopig losstaand — later evalueren als de back-end/CMS er is
+B) Ja, ik wil dit alvast voorbereiden op gedeelde monitoring met de toekomstige back-end/CMS
+C) Nog niet van toepassing — ik heb nog geen bestaande monitoring-infrastructuur
+D) Anders (beschrijf na de [Answer]: tag hieronder)
+
+[Answer]:A
@@ -0,0 +1,24 @@
+# Production Readiness Checklist
+
+## Deployment
+- **Status**: Configured
+- **Method**: Manually-triggered Gitea Actions pipeline (`workflow_dispatch`, also runs automatically as a build/test/lint gate on pull requests) that packages the `dist/` build as a downloadable artifact; actual upload to the host is currently a manual step (see `operations/deployment/deployment-plan.md`)
+- **Rollback Plan**: Yes — `operations/deployment/rollback-plan.md` (manual re-upload of a previous `release/*` build; no persistent/database state to roll back)
+
+## Monitoring
+- **Status**: Configured
+- **Approach**: Combination (Logging + Dashboards; Alerting explicitly out of scope) — see `operations/monitoring/monitoring-plan.md` and `operations/monitoring/monitoring-setup.md`
+
+## Additional Readiness Items
+- **Backups**: N/A — this unit is a static marketing site (`dist/` bundle) with no database and no server-side/persistent state; nothing to back up beyond the source repository itself, which is already under git version control.
+- **Secrets Management**: N/A for now — no automated host upload exists yet, so no host credentials are configured in Gitea Actions at this stage. When the automatic deploy step is added later (tracked as an open item in `deployment-plan.md`), credentials must be stored as Gitea Actions Secrets, never committed to the repo.
+- **Runbook/Support Handover**: Partially covered — `operations/deployment/deployment-instructions.md` and `operations/deployment/rollback-plan.md` document how to trigger a release, upload the build, and roll back. No separate incident-response runbook exists beyond these documents, which is proportionate given this is a single-owner static site with no backend to page someone about.
+- **Alert Ownership**: N/A — Alerting was explicitly declared out of scope in Monitoring Setup, so there is no alert-on-call/ownership rotation to define. If the chosen uptime dashboard tool (UptimeRobot/Better Uptime) is configured with its own opportunistic e-mail notification, the site owner is the sole recipient.
+
+## Overall Readiness
+- **Ready for Production**: Yes with caveats
+- **Open Follow-ups**:
+  - Finalize the hosting/domain setup and extend `.gitea/workflows/deploy.yml`'s `deploy` job to actually upload `dist/` to the host, instead of only packaging it as a downloadable artifact (see `deployment-plan.md` "Open Item")
+  - Decide the client-side error logging destination (browser console only vs. an external service such as Sentry free tier) — see `monitoring-setup.md`
+  - Pick and configure the concrete analytics tool (e.g. Plausible/Umami/GA4) and uptime dashboard tool (e.g. UptimeRobot/Better Uptime), including registering the final production URL once hosting is finalized
+  - Run a formal Lighthouse performance check before the first real production deployment (flagged as not yet run in `build-and-test-summary.md`)