Adds reverse engineering docs and adds new aidlc feature for front-end development
This commit is contained in:
+147
@@ -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
|
||||
Reference in New Issue
Block a user