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,36 @@
+# AI-DLC State Tracking
+
+## Project Information
+- **Feature Name**: CMS Frontend
+- **Feature Slug**: cms-frontend
+- **Project Type**: Brownfield
+- **Start Date**: 2026-06-16T20:27:00Z
+- **Current Stage**: INCEPTION - Requirements Analysis (awaiting question answers)
+- **Branch**: unknown
+
+## Workspace State
+- **Existing Code**: Yes (.NET API backend + example React app in ZIP)
+- **Reverse Engineering Needed**: Yes (shared reverse engineering for backend; example app analyzed)
+- **Workspace Root**: K:\Development\Projects\SlpModularCms
+
+## Code Location Rules
+- **Application Code**: src/SlpModularCms.Frontend/ (new React app)
+- **Feature Documentation**: aidlc-docs/features/cms-frontend/ only
+- **Shared Artifacts**: aidlc-docs/_shared/
+- **Structure patterns**: See code-generation.md Critical Rules
+
+## Language Configuration
+- **Documentation Language**: English
+- **Conversation Language**: Dutch (nl)
+
+## Extension Configuration
+[Will be populated during Requirements Analysis]
+
+## Stage Progress
+- [x] Workspace Detection — Completed 2026-06-16T20:28:00Z
+- [x] Reverse Engineering (shared) — Completed 2026-06-16T20:32:00Z — Artifacts: aidlc-docs/_shared/reverse-engineering/
+- [ ] Requirements Analysis — Not Started
+- [ ] User Stories — Not Started
+- [ ] Workflow Planning — Not Started
+- [ ] Construction — Not Started
+- [ ] Build and Test — Not Started
@@ -0,0 +1,49 @@
+# Audit Log — cms-frontend
+
+## Workspace Detection — Initial Request
+
+**Timestamp**: 2026-06-16T20:27:00Z
+
+**User Input**: "Start een aidlc workflow voor het aanmaken van de front-end. De frontend moet gebaseerd worden op een voorbeeld React-app in de volgende ZIP-bestand: "K:\Libraries\Downloads\Admin panel with dashboard.zip" Hier is een grove opzet gemaakt met een style gebaseerd op dfe hoofdkleur #ac0000 en de shadcn componenten. Met deze basis wil ik een front-end voor de CMS neerzetten."
+
+**AI Response**: "Started aidlc workflow for cms-frontend feature. Inspected ZIP file, analyzed existing React app structure and backend API. Created feature directory structure."
+
+**Context**: Workspace Detection initiated; brownfield project with existing .NET API backend and example React app in ZIP file.
+
+---
+
+## Gap Identified — Language Preference
+
+**Timestamp**: 2026-06-16T20:35:00Z
+
+**User Input**: "Skill-creator. Waarom ben ik niet gevraagd in welke taal ik de aidlc-workflow wil doen? Volgens mij zou dat bij elke feature gevraagd moeten worden. Nu wordt de default gebruikt zonder dat ik gevraagd ben wat ik wil"
+
+**AI Response**: "Acknowledged gap. Created gap report at aidlc-docs/gap-reports/gap-001-language-preference-per-feature.md. User chose to continue with English documentation for cms-frontend feature."
+
+**Context**: User identified missing language preference question for new features in existing workspace. Gap hand-off document created. CMS frontend workflow resumes with English documentation.
+
+---
+
+## Reverse Engineering — User Approval
+
+**Timestamp**: 2026-06-16T20:33:00Z
+
+**User Input**: "Goedkeuren en doorgaan"
+
+**AI Response**: "Reverse Engineering approved. Proceeding to Requirements Analysis."
+
+**Context**: User approved reverse engineering artifacts; Requirements Analysis phase starting.
+
+---
+
+## Reverse Engineering — Completion
+
+**Timestamp**: 2026-06-16T20:32:00Z
+
+**User Input**: "(Automatic — triggered by Workspace Detection as no shared reverse engineering artifacts existed)"
+
+**AI Response**: "Generated 8 reverse engineering artifacts covering business overview, architecture, code structure, API documentation, component inventory, technology stack, dependencies, and code quality assessment."
+
+**Context**: Reverse Engineering completed; artifacts saved to aidlc-docs/_shared/reverse-engineering/. Awaiting user approval to proceed to Requirements Analysis.
+
+---
@@ -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