Adds reverse engineering docs and adds new aidlc feature for front-end development

2026-06-16 23:25:22 +02:00
parent 95d986790e
commit 73025c5a84
15 changed files with 994 additions and 0 deletions
@@ -0,0 +1,23 @@
+# Requirements Clarification Questions — CMS Frontend
+
+I detected a contradiction in your responses that needs clarification:
+
+## Contradiction: Authentication Security vs. Security Baseline
+
+You indicated **JWT in localStorage** (Q2: A) but also **Enforce all SECURITY rules as blocking constraints** (Q11: A).
+
+Storing JWT tokens in `localStorage` is a known security vulnerability — XSS attacks can steal tokens from localStorage. When the Security Baseline extension is enforced, this pattern is typically flagged as a **blocking security finding**.
+
+This means either:
+- The security baseline must be applied → the localStorage auth approach cannot be used
+- The localStorage auth approach is acceptable → security baseline must be relaxed or skipped
+
+### Clarification Question 1
+How should this contradiction be resolved for the cms-frontend project?
+
+A) Use a secure authentication approach (access token in memory + refresh token in httpOnly cookie) AND keep the security baseline enforced — this is the secure production-ready choice
+B) Keep localStorage for now (faster to implement, familiar) AND disable the security baseline — acceptable for a prototype/development phase
+C) Keep localStorage for now AND keep the security baseline, but acknowledge and document this as an accepted risk / technical debt
+X) Other (please describe after [Answer]: tag below)
+
+[Answer]: 
@@ -0,0 +1,147 @@
+# Requirements Verification Questions — CMS Frontend
+
+Please answer each question by filling in the letter choice after the `[Answer]:` tag.
+If none of the provided options match, choose the last option and describe your preference.
+
+---
+
+## Vraag 1: Scope van de frontend
+Welke pagina's / secties moeten worden gebouwd in de eerste versie van de CMS frontend?
+
+A) Alleen de pagina's die al in het voorbeeld aanwezig zijn: Login, Dashboard, CMS Beheer, Gebruikersbeheer
+B) Dezelfde pagina's als het voorbeeld, plus een Systeeminstellingen / Beschikbaarheid beheerpagina
+C) Een uitgebreidere set: Login, Dashboard, CMS Beheer, Gebruikersbeheer, Beschikbaarheid beheer, Profiel/account instellingen
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: X, Een Login-pagina, Gebruikersbeheer, Profiel/account instellingen en systeeminstellingen. CMS beheer komt later
+
+---
+
+## Vraag 2: Authenticatiestrategie
+Hoe moet de frontend authenticatie afhandelen?
+
+A) JWT opslaan in localStorage (eenvoudig, minder veilig — zelfde als voorbeeld app)
+B) JWT access token in geheugen (geen persistentie), refresh token in httpOnly cookie (veiliger voor productie)
+C) JWT access token in geheugen, refresh token ook in geheugen (volledig stateloos — gebruiker moet opnieuw inloggen na paginaverversing)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: A
+
+---
+
+## Vraag 3: API-configuratie en base URL
+Hoe moet de frontend-app de API-basis-URL configureren?
+
+A) Via een `.env` bestand (VITE_API_BASE_URL variabele) — standaard Vite aanpak
+B) Hardcoded in een aparte config file (bijv. `src/config.ts`)
+C) Via runtime configuratie (window.__ENV__ of een /config endpoint)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: X, via .env, maar voor gevoelige data zoals secrets wil ik net als de backend environment variables gebruiken
+
+---
+
+## Vraag 4: Routebeveiliging
+Hoe moeten beveiligde routes worden beheerd?
+
+A) Eenvoudige ProtectedRoute component — redirect naar /login als niet ingelogd
+B) Rolgebaseerde routebeveiliging — bepaalde pagina's alleen toegankelijk voor Owner of Admin rollen
+C) Combinatie: ProtectedRoute voor auth + role guards per pagina
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: C
+
+---
+
+## Vraag 5: Initialisatie-flow (Setup)
+Moet de frontend de initialisatiestatus van het systeem afhandelen?
+
+A) Ja — als `/setup/status` aangeeft dat het systeem niet geïnitialiseerd is, redirect naar een Initialisatiepagina (maak eerste Owner aan)
+B) Nee — de initialisatiepagina is een aparte, standalone pagina buiten de normale app-flow
+C) Ja, maar combineer het als een eerste-keer-login scherm
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: A
+
+---
+
+## Vraag 6: Gebruikersuitnodiging flow
+Hoe moet de uitnodigingsstroom worden verwerkt?
+
+A) Volledig in de frontend: Gebruikersbeheer pagina heeft een "Uitnodigen" knop, en er is een aparte publieke pagina voor het voltooien van de account setup via uitnodigingstoken
+B) Alleen de Uitnodigen-knop in Gebruikersbeheer — de complete-setup pagina is out of scope voor nu
+C) Volledige flow inclusief validatie van uitnodigingstoken, foutafhandeling (verlopen/ongeldig token) en succesmelding
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: C
+
+---
+
+## Vraag 7: CMS Beheer pagina — inhoud
+Wat moet de CMS Beheer pagina tonen / doen in de eerste versie?
+
+A) Placeholder pagina — de CMS-inhoudmodules zijn nog niet geïmplementeerd in de backend, dus toon een lege "work in progress" sectie
+B) Basis structuur gereed met navigatiestructuur voor toekomstige content modules, maar zonder echte data
+C) Volledig functionele pagina als de backend-modules al beschikbaar zijn (geef aan welke)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: B
+
+---
+
+## Vraag 8: Beschikbaarheid beheer
+Moet de frontend een pagina hebben voor het beheren van de systeembeschikbaarheid?
+
+A) Ja — een pagina (alleen voor Owners) om de status in te stellen (Available/Maintenance/Unavailable) met optioneel bericht
+B) Nee — beschikbaarheidsstatus enkel tonen als readonly indicator in het dashboard
+C) Ja, maar als onderdeel van een bredere Instellingen-pagina in plaats van een eigen pagina
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: X, De beschikbaarheidsmodule is een core functionaliteit die uit 2 modules zal bestaand. De master en client modules waar de master module de status beheert van de client modules/CMS-en. De master-module is nog niet gebouwd. Als voorbereiding zou je op het dashboard kunnen laten zien "Beschikbaar" of "Niet beschikbaar" met een reden erbij. 
+
+---
+
+## Vraag 9: Donker/licht thema
+Moet de frontend ondersteuning bieden voor donker/licht thema?
+
+A) Ja — donker en licht thema wisselen via een schakelaar (next-themes zoals in voorbeeld app)
+B) Nee — alleen licht thema in eerste versie
+C) Alleen donker thema
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: A
+
+---
+
+## Vraag 10: Locatie van de frontend in het project
+Waar moet de React app worden geplaatst in de projectstructuur?
+
+A) `src/SlpModularCms.Frontend/` (naast de .NET projecten in de `src/` map)
+B) `frontend/` (aparte map op het root niveau van de solution)
+C) `client/` (aparte map op root niveau)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: B
+
+---
+
+## Vraag 11: Beveiligingsextensies
+Moeten de beveiligingsregels als harde vereisten worden afgedwongen voor dit project?
+
+A) Ja — dwing alle BEVEILIGINGSREGELS af als blokkerende vereisten (aanbevolen voor productietoepassingen)
+B) Nee — sla alle BEVEILIGINGSREGELS over (geschikt voor PoC's, prototypes en experimentele projecten)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: A
+
+---
+
+## Vraag 12: Property-Based Testing Extensie
+Moeten de property-based testing (PBT) regels worden afgedwongen voor dit project?
+
+A) Ja — dwing alle PBT-regels af als blokkerende vereisten
+B) Gedeeltelijk — dwing PBT-regels alleen af voor pure functies en serialisatie round-trips
+C) Nee — sla alle PBT-regels over (geschikt voor UI-projecten zonder complexe bedrijfslogica)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: C