Initial commit with inital CMS

2026-06-15 17:00:16 +02:00
commit 95d986790e
132 changed files with 7624 additions and 0 deletions
@@ -0,0 +1,33 @@
+# Code Generation Plan — Unit 04: API Shell & Integration
+
+Dit plan beschrijft de stappen voor de implementatie van de API Shell in `SlpModularCms.Api`.
+
+## Implementatie Stappen
+
+### 1. Voorbereiding & NuGet
+- [x] Toevoegen van NuGet packages aan `SlpModularCms.Api`:
+    - `Asp.Versioning.Mvc`
+    - `Swashbuckle.AspNetCore`
+    - `Microsoft.AspNetCore.Authentication.JwtBearer`
+- [x] Referenties toevoegen naar:
+    - `SlpModularCms.Core`
+    - `SlpModularCms.Modules.Availability` (Indien niet dynamisch geladen)
+
+### 2. Orkestratie & Infrastructuur
+- [x] Implementeren van de `ApiPrefixConvention`.
+- [x] Implementeren van de `ModuleOrchestrator` (Service Discovery).
+- [x] Implementeren van extensie methoden voor `IServiceCollection` en `IApplicationBuilder`.
+
+### 3. Program.cs Configuratie
+- [x] Configureren van de Exception Handler middleware (Unit 01).
+- [x] Configureren van de Availability middleware (Unit 03).
+- [x] Configureren van JWT Bearer authenticatie (Unit 02).
+- [x] Configureren van de `ModuleOrchestrator` in de startup flow.
+- [x] Opzetten van Swagger met JWT support en module tagging.
+
+### 4. Validatie
+- [x] Opstarten van de API en verifiëren van de `/swagger` pagina.
+- [x] Verifiëren dat `/api/v1/availability/status` werkt.
+
+## Volgende Stappen
+Na de implementatie volgt de finale integratietest.
@@ -0,0 +1,30 @@
+# Functional Design Plan — Unit 04: API Shell & Integration
+
+Dit plan beschrijft de stappen voor het functioneel ontwerpen van de API Shell (Unit 04), die alle modules samenbrengt.
+
+## Functional Design Stappen
+- [x] Ontwerpen van de `ModuleOrchestrator` voor dynamische discovery en registratie.
+- [x] Definiëren van de globale `Program.cs` structuur (Dependency Injection & Pipeline).
+- [x] Uitwerken van de JWT Bearer configuratie en Swagger integratie.
+- [x] Ontwerpen van de globale foutafhandeling integratie (GlobalExceptionHandler).
+- [x] Opstellen van de integratie-regels voor cross-module communicatie.
+
+## Vragen voor Functional Design (Unit 04)
+
+### 1. Swagger Documentatie
+**Vraag 1.1**: Hoe moeten de verschillende modules in Swagger worden weergegeven?
+- A) **Gecombineerd**: Eén grote lijst met alle endpoints van alle modules door elkaar.
+- B) **Gegroepeerd per Module**: Gebruik Swagger 'Docs' of 'Tags' om endpoints per module (bijv. Identity, Availability) te groeperen.
+
+### 2. Startup Volgorde
+**Vraag 2.1**: Moeten modules in een specifieke volgorde geladen worden?
+- A) Nee, de volgorde is willekeurig (behalve Core).
+- B) Ja, we hebben een expliciete `LoadOrder` eigenschap nodig in de `IModule` interface.
+
+### 3. API Versiebeheer
+**Vraag 3.1**: Moeten we API Versioning (bijv. `/api/v1/...`) direct integreren in de Shell?
+- A) Ja, configureer globale versiebeheer (v1) voor de hele API.
+- B) Nee, voor de MVP is geen versiebeheer nodig in het pad.
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/api-shell/functional-design/`.
@@ -0,0 +1,30 @@
+# NFR Design Plan — Unit 04: API Shell & Integration
+
+Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor de API Shell (Unit 04).
+
+## NFR Design Stappen
+- [x] Ontwerpen van de `ModuleOrchestrator` scanning logica.
+- [x] Uitwerken van de Swagger configuratie voor JWT en module groepering.
+- [x] Definiëren van de API Versioning configuratie (v1 prefix).
+- [x] Ontwerpen van de globale CORS policy configuratie.
+- [x] Vastleggen van de `Program.cs` extensie methoden voor module registratie.
+
+## Vragen voor NFR Design (Unit 04)
+
+### 1. Module Discovery Foutafhandeling
+**Vraag 1.1**: Wat moet er gebeuren als een module niet geladen kan worden (bijv. door een ontbrekende afhankelijkheid)?
+- A) **Fail Fast**: De hele API weigert op te starten. Meest veilig voor consistentie.
+- B) **Soft Fail**: Log de fout, sla de module over en start de rest van de API wel op.
+
+### 2. Route Prefixing
+**Vraag 2.1**: Hoe moeten we de `/api/v1/` prefix afdwingen?
+- A) **Expliciet**: In elke Controller route attribuut (bijv. `[Route("api/v1/[controller]")]`).
+- B) **Globaal**: Via een `IApplicationModelConvention` in de Shell die alle routes automatisch prefixen.
+
+### 3. Swagger Documentatie Locatie
+**Vraag 3.1**: Waar moet de Swagger UI bereikbaar zijn?
+- A) In de root (`/`).
+- B) Op het standaard pad (`/swagger`).
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/api-shell/nfr-design/`.
@@ -0,0 +1,31 @@
+# NFR Requirements Plan — Unit 04: API Shell & Integration
+
+Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de API Shell (Unit 04).
+
+## NFR Assessment Stappen
+- [x] Vaststellen van de performance targets voor de startup tijd (module discovery).
+- [x] Definiëren van de security baseline voor CORS en HTTPS.
+- [x] Keuze van de tech stack voor API Versioning en Swagger documentatie.
+- [x] Bepalen van de logging aggregatie strategie (centraal vs per module).
+
+## NFR Vragen voor Unit 04
+
+### 1. Startup Performance
+**Vraag 1.1**: Wat is de maximaal acceptabele startup tijd van de API (inclusief module scanning)?
+- A) **Snel**: < 2 seconden.
+- B) **Gemiddeld**: 2-5 seconden.
+- C) **Niet kritisch**: > 5 seconden (geschikt voor monolithische startup).
+
+### 2. CORS Beleid
+**Vraag 2.1**: Hoe strikt moet het CORS beleid zijn voor de MVP?
+- A) **Permissief**: Sta alle origins toe (`*`).
+- B) **Standaard**: Alleen specifieke, geconfigureerde origins toestaan via `appsettings.json`.
+- C) **Strikt**: Geen CORS ondersteuning (alleen same-origin).
+
+### 3. API Documentatie
+**Vraag 3.1**: Welke Swagger UI functies moeten ingeschakeld worden?
+- A) **Volledig**: Inclusief "Try it out" en JWT Bearer authenticatie ondersteuning.
+- B) **Read-only**: Alleen documentatie, geen interactie mogelijk.
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/api-shell/nfr-requirements/`.
@@ -0,0 +1,26 @@
+# Code Generation Plan — Unit 03: Availability Module
+
+Dit plan beschrijft de stappen voor de implementatie van de Availability Module (Unit 03).
+
+## Implementatie Stappen
+
+### 1. Project Creatie
+- [x] Aanmaken van `src/SlpModularCms.Modules.Availability` (Class Library).
+- [x] Toevoegen aan de solution.
+- [x] Referentie toevoegen naar `SlpModularCms.Core`.
+
+### 2. Domein Model & Data
+- [x] Implementeren van de `GlobalAvailabilityState` entiteit.
+- [x] Toevoegen van de entiteit aan de `ApplicationDbContext` (via een gedeeld interface of direct). *Noot: De DbContext zit in Core, dus we moeten mogelijk de entiteit ook in Core plaatsen of de DbContext uitbreiden via een module-extensie.*
+
+### 3. Services & Middleware
+- [x] Implementeren van `PersistentAvailabilityService` (in de module).
+- [x] Implementeren van de `AvailabilityMiddleware` (in de module of Shell).
+- [x] Implementeren van de `AvailabilityController`.
+
+### 4. Testing
+- [x] Aanmaken van `SlpModularCms.Modules.Availability.Tests`.
+- [x] Testen van de middleware blokkade en de circuit breaker logica.
+
+## Volgende Stappen
+Na de project-setup volgt de implementatie van de service en middleware.
@@ -0,0 +1,31 @@
+# Functional Design Plan — Unit 03: Availability Module
+
+Dit plan beschrijft de stappen voor het functioneel ontwerpen van de Availability Module (Unit 03).
+
+## Functional Design Stappen
+- [x] Definiëren van de `StubAvailabilityService` gedrag (altijd beschikbaar in MVP).
+- [x] Ontwerpen van de `AvailabilityController` voor publieke status check.
+- [x] Uitwerken van de "Remote Shutdown" interface (placeholder).
+- [x] Opstellen van de business rules voor beschikbaarheids-gebaseerde toegang.
+
+## Vragen voor Functional Design (Unit 03)
+
+### 1. Beschikbaarheidsstatus
+**Vraag 1.1**: Welke informatie moet het publieke `GET /api/availability/status` endpoint teruggeven?
+- A) **Simpel**: Alleen een boolean `isAvailable`.
+- B) **Gedetailleerd**: Een status string (`Available`, `Maintenance`, `Degraded`) en een timestamp.
+- C) **Extended**: Inclusief versie informatie van de API en geladen modules.
+
+### 2. Remote Shutdown Mechanisme
+**Vraag 2.1**: Voor de toekomstige "remote shutdown" functionaliteit (FR-05): hoe moet dit mechanisme in de architectuur verankerd worden?
+- A) **Middleware**: Een globale middleware die de `IAvailabilityService` checkt bij elk request en 503 Service Unavailable retourneert indien niet beschikbaar.
+- B) **Filter**: Een globaal Action Filter voor controllers.
+- C) **Manual Check**: Modules checken zelf de status indien nodig (niet aanbevolen voor consistentie).
+
+### 3. Bypass voor Beheerders
+**Vraag 3.1**: Mogen Beheerders en Owners de API nog wel gebruiken als de status op "Niet Beschikbaar" staat (bijv. voor onderhoud)?
+- A) Ja, Beheerders/Owners moeten altijd toegang hebben om het systeem te kunnen herstellen.
+- B) Nee, als het systeem uit staat, staat het voor iedereen uit.
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/availability-module/functional-design/`.
@@ -0,0 +1,31 @@
+# NFR Design Plan — Unit 03: Availability Module
+
+Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor Unit 03.
+
+## NFR Design Stappen
+- [x] Ontwerpen van de `AvailabilityMiddleware` en de bypass logica.
+- [x] Definiëren van de `PersistentAvailabilityService` implementatie.
+- [x] Uitwerken van het database schema voor de globale status.
+- [x] Ontwerpen van de `AvailabilityController` endpoints (publiek status, beheer status).
+- [x] Vastleggen van de integratie met de `AuditLogs` (Unit 02).
+
+## Vragen voor NFR Design (Unit 03)
+
+### 1. Middleware Registratie
+**Vraag 1.1**: Waar moet de `AvailabilityMiddleware` in de pipeline worden geplaatst?
+- A) **Helemaal vooraan**: Zelfs vóór de exception handler en logging (maximaal effectief, maar minder informatie bij fouten).
+- B) **Na de Exception Handler**: Fouten in de check worden dan netjes afgevangen door de globale handler (Aanbevolen).
+- C) **Na Authentication**: Dan weten we al wie de gebruiker is (nodig voor de bypass check), maar dan is de authenticatie overhead al geweest voor geblokkeerde requests.
+
+### 2. Status Update Endpoint
+**Vraag 2.1**: Hoe moet het endpoint voor het wijzigen van de status beveiligd worden?
+- A) **Policy-based**: Gebruik de `OwnerOnly` policy (Unit 02).
+- B) **Internal-only**: Alleen bereikbaar vanaf de lokale host of via een intern netwerk (minder flexibel voor cloud beheer).
+
+### 3. Fallback Gedrag (Circuit Breaker)
+**Vraag 3.1**: Als de database herhaaldelijk onbereikbaar is voor de status-check, hoe lang moet de fallback status (`Available`) worden aangehouden voordat we het opnieuw proberen?
+- A) Elke request opnieuw proberen.
+- B) Implementeer een eenvoudige circuit breaker (bijv. 30 seconden fallback na 3 opeenvolgende fouten).
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/availability-module/nfr-design/`.
@@ -0,0 +1,31 @@
+# NFR Requirements Plan — Unit 03: Availability Module
+
+Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de Availability Module (Unit 03).
+
+## NFR Assessment Stappen
+- [x] Vaststellen van de performance overhead van de Availability Middleware.
+- [x] Definiëren van de betrouwbaarheidseisen voor de status check (bijv. caching).
+- [x] Beveiligen van het onderhouds-bypass mechanisme.
+- [x] Keuze van de opslag voor de dynamische status (Config vs Cache vs Database).
+
+## NFR Vragen voor Unit 03
+
+### 1. Performance
+**Vraag 1.1**: Wat is de maximale toegestane latency die de Availability Middleware mag toevoegen aan elk request?
+- A) **Ultra-laag**: < 1ms (vereist in-memory check zonder database/I/O).
+- B) **Laag**: 1-5ms (staat een snelle cache of config check toe).
+- C) **Gemiddeld**: < 10ms.
+
+### 2. Status Opslag & Wijziging
+**Vraag 2.1**: Hoe moet een beheerder de status van de API kunnen wijzigen in de MVP?
+- A) **Static**: Alleen via `appsettings.json` (vereist herstart of config-reload).
+- B) **Dynamic (In-Memory)**: Via een specifiek (beveiligd) endpoint dat de status in het geheugen aanpast (gaat verloren bij herstart).
+- C) **Persistent**: Via de database, zodat de status over herstarts heen behouden blijft.
+
+### 3. Caching
+**Vraag 3.1**: Moet de resultaat van de beschikbaarheidscheck gecached worden in de middleware?
+- A) Nee, altijd de actuele status ophalen via de service.
+- B) Ja, voor een korte duur (bijv. 1 seconde) om performance te optimaliseren bij hoge belasting.
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de artifacts gegenereerd in `aidlc-docs/construction/availability-module/nfr-requirements/`.
@@ -0,0 +1,25 @@
+# Code Generation Plan — Unit 01: Core Base
+
+Dit plan beschrijft de stappen voor de initiële implementatie van de Core Base (Unit 01).
+
+## Implementatie Stappen
+- [x] Aanmaken van het `SlpModularCms.Core` class library project.
+- [x] Toevoegen van het project aan de solution (`SlpModularCms.sln`).
+- [x] Implementeren van de basis types en interfaces (Functional Design):
+    - [x] `IModule`
+    - [x] `IAvailabilityService`
+    - [x] `AvailabilityStatus` (Enum)
+    - [x] `ModuleInfo` (Record)
+- [x] Implementeren van de NFR componenten (NFR Design):
+    - [x] `GlobalExceptionHandler` (IExceptionHandler)
+    - [x] `ApiErrorResponse`
+    - [x] `ModuleOrchestrator` interfaces en basis logica (Verplaatst naar U04 Shell).
+- [x] Opzetten van het Unit Test project `SlpModularCms.Core.Tests`.
+- [x] Implementeren van de eerste unit tests voor de Exception Handler en Availability Service.
+
+## Vragen voor Code Generation (Unit 01)
+1. **Namespace**: Gaan we akkoord met de namespace `SlpModularCms.Core` voor de basis types?
+2. **Project Locatie**: De `unit-of-work.md` suggereerde `src/SlpModularCms.Core/`. Moet deze map aangemaakt worden in de root? (Huidige root bevat al `SlpModularCms.Api/` direct in de root).
+
+## Volgende Stappen
+Na bevestiging van de projectstructuur start de daadwerkelijke code generatie.
@@ -0,0 +1,53 @@
+# Functional Design Plan — Unit 01: Core Base
+
+Dit plan beschrijft het gedetailleerde functionele ontwerp voor het fundament van de SlpModularCms API.
+
+## Stap 1: Business Logic Modeling
+- [x] Modelleren van de module-levenscyclus (Discovery -> Registration -> Initialisation).
+- [x] Beschrijven van de orkestratie tussen de API Shell en de Core Base interfaces.
+
+## Stap 2: Domain Entities & Interfaces
+- [x] Definiëren van de `IModule` interface structureel.
+- [x] Definiëren van de `IAvailabilityService` contracten.
+- [x] Modelleren van gedeelde DTO's (bijv. `AvailabilityDetails`).
+- [x] Genereer `aidlc-docs/construction/core-base/functional-design/domain-entities.md`.
+
+## Stap 3: Business Rules & Validation
+- [x] Vastleggen van validatieregels voor module-namen en versies.
+- [x] Definiëren van de standaard "IsAvailable" logica (fallback gedrag).
+- [x] Genereer `aidlc-docs/construction/core-base/functional-design/business-rules.md`.
+
+## Stap 4: Data Flow & Error Handling
+- [x] Ontwerpen van de globale exception-to-response mapping.
+- [x] Beschrijven van de dataflow voor cross-cutting concerns (logging context).
+- [x] Genereer `aidlc-docs/construction/core-base/functional-design/business-logic-model.md`.
+
+---
+
+## Vragen voor Functional Design (Core Base)
+
+### Vraag 1: Module Identificatie
+Welke metadata moet elke module verplicht opgeven bij registratie?
+A) Minimale set: Alleen een unieke `Name`.
+B) Uitgebreid: `Name`, `Version`, `Description` en `Dependencies` (lijst met namen van andere modules).
+C) Dynamisch: De module bepaalt zelf welke metadata hij exposeert via een dictionary.
+X) Anders: ...
+
+[Answer]: B
+
+### Vraag 2: Exception Handling Strategie
+Hoe moeten domein-specifieke exceptions (bijv. `ModuleNotFoundException`) functioneel worden vertaald naar de buitenwereld?
+A) Uniform: Alle exceptions mappen naar een generiek fout-object met een `Code` en `Message`.
+B) Gedetailleerd: Elke exception heeft een eigen response model met specifieke velden voor debug-informatie.
+X) Anders: ...
+
+[Answer]: B
+
+### Vraag 3: Availability Fallback
+Als een module de `IAvailabilityService` niet expliciet implementeert, wat moet het standaard gedrag van de Core Base zijn?
+A) Optimistisch: Altijd `true` retourneren (beschikbaar).
+B) Pessimistisch: `false` retourneren (niet beschikbaar totdat expliciet aangezet).
+C) Foutmelding: De applicatie mag niet starten als een module geen statuscontrole heeft.
+X) Anders: ...
+
+[Answer]: X, de availability wordt voor de hele API gecontroleerd, niet per module
@@ -0,0 +1,19 @@
+# NFR Design Plan — Unit 01: Core Base
+
+Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor Unit 01.
+
+## NFR Design Stappen
+- [x] Ontwerpen van de `GlobalExceptionMiddleware` en de `ApiErrorResponse` mapping (SEC-01).
+- [x] Definiëren van de `IModule` interface en de dynamische discovery logica (PERF-01).
+- [x] Uitwerken van de `IAvailabilityService` decorator of middleware voor timeouts en fallback (AVAIL-01).
+- [x] Vastleggen van de AutoFixture configuratie patronen voor consistente testdata (MAINT-02).
+- [x] Controleren van de async-consistentie in alle voorgestelde interfaces (PERF-03).
+
+## Vragen voor NFR Design (Unit 01)
+
+1. **Exception Mapping**: Willen we gebruik maken van de nieuwe `IExceptionHandler` interface (geïntroduceerd in .NET 8) of de traditionele Middleware aanpak voor de globale foutafhandeling?
+2. **Module Discovery**: Voor de dynamische discovery: Gaan we uit van assembly scanning op basis van een naamconventie (bijv. `SlpModularCms.Modules.*`) of gebruiken we een specifiek attribuut (`[Module]`) op de entry classes?
+3. **Availability Timeout**: Moet de timeout voor `IAvailabilityService` globaal geconfigureerd worden via `appsettings.json`, of moet deze per call overschrijfbaar zijn via een `CancellationToken`?
+
+## Volgende Stappen
+Na goedkeuring van dit plan (of beantwoording van de vragen), worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/core-base/nfr-design/`.
@@ -0,0 +1,58 @@
+# NFR Requirements Plan — Unit 01: Core Base
+
+Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor Unit 01 en bevat vragen voor de gebruiker om de technische keuzes te verfijnen.
+
+## NFR Assessment Stappen
+- [x] Analyseren van de complexiteit van de module discovery en registration.
+- [x] Vaststellen van performance targets voor cross-cutting concerns (logging, exception handling).
+- [x] Definiëren van security constraints voor de API shell en module isolatie.
+- [x] Keuze van de tech stack componenten voor Unit 01.
+
+## NFR Vragen voor Unit 01
+
+### 1. Performance & Schaalbaarheid
+**Vraag 1.1**: Hoeveel modules verwacht je dat het systeem maximaal zal bevatten in de nabije toekomst?
+- A) Kleinschalig (1-5 modules)
+- B) Middelgroot (5-20 modules)
+- C) Grootschalig (20+ modules)
+- D) Dynamisch/Onbekend
+[Answer]:  D
+
+**Vraag 1.2**: Wat is de acceptabele overhead voor de globale exception handling middleware?
+- A) Minimaal ( < 10ms extra per request)
+- B) Gemiddeld (10-50ms)
+- C) Niet kritisch ( > 50ms)
+[Answer]: C
+
+### 2. Security
+**Vraag 2.1**: Welke informatie mag ABSOLUUT NIET in de `Details` dictionary van de `ApiErrorResponse` verschijnen in productie?
+- A) Alleen stacktraces
+- B) Stacktraces en interne server IP-adressen/paden
+- C) Alles wat niet expliciet als 'veilig' is gemarkeerd (White-listing benadering)
+[Answer]: B
+
+### 3. Availability & Reliability
+**Vraag 3.1**: Wat moet de timeout zijn voor de `IAvailabilityService.IsAvailableAsync()` check?
+- A) Zeer strikt ( < 500ms)
+- B) Standaard (1-2 seconden)
+- C) Relaxed ( > 2 seconden)
+[Answer]: B
+
+### 4. Tech Stack Keuzes
+**Vraag 4.1**: Heb je een voorkeur voor een specifieke logging library?
+- A) Microsoft.Extensions.Logging (Standaard .NET)
+- B) Serilog (met Structured Logging focus)
+- C) NLog
+- D) Geen voorkeur
+[Answer]: D
+
+**Vraag 4.2**: Hoe moeten we omgaan met Dependency Injection voor de modules?
+- A) Alleen de standaard .NET DI container
+- B) Een krachtigere container zoals Autofac (indien complexe module-overschrijvingen nodig zijn)
+[Answer]: A
+
+**Vraag 4.3**: Voor de Unit Tests en Property-Based Testing (PBT), welke libraries wil je gebruiken? (Merk op: PBT is gedeeltelijk ingeschakeld)
+- A) xUnit + FluentAssertions + FsCheck (voor PBT)
+- B) xUnit + FluentAssertions + AutoFixture
+- C) xUnit + Shouldly
+[Answer]: B
@@ -0,0 +1,33 @@
+# Code Generation Plan — Unit 02: Identity & RBAC
+
+Dit plan beschrijft de stappen voor de implementatie van de Identity & RBAC module in `SlpModularCms.Core`.
+
+## Implementatie Stappen
+
+### 1. Voorbereiding
+- [x] Toevoegen van NuGet packages:
+    - `Microsoft.AspNetCore.Identity.EntityFrameworkCore`
+    - `Microsoft.EntityFrameworkCore.SqlServer`
+    - `Microsoft.AspNetCore.Authentication.JwtBearer`
+
+### 2. Domein Model
+- [x] Implementeren van `ApplicationUser` (erft van `IdentityUser<Guid>`).
+- [x] Implementeren van `ApplicationRole` (erft van `IdentityRole<Guid>`).
+- [x] Implementeren van `RefreshToken`, `Invitation`, en `ModulePermission` entiteiten.
+
+### 3. Data Toegang
+- [x] Implementeren van `ApplicationDbContext` met de geconfigureerde tabelnamen (Users, Roles, etc.).
+
+### 4. Services
+- [x] Implementeren van `IAuthService` voor login en token refresh.
+- [x] Implementeren van `IInvitationService` voor het uitnodigingsproces.
+
+### 5. Autorisatie
+- [x] Implementeren van `HierarchicalRoleRequirement` en `HierarchicalRoleHandler`.
+
+### 6. Testing
+- [x] Toevoegen van unit tests voor de Auth en Invitation services.
+- [x] Toevoegen van tests voor de hiërarchische autorisatie logica.
+
+## Volgende Stappen
+Na de implementatie worden alle tests uitgevoerd om de correctheid te verifiëren.
@@ -0,0 +1,37 @@
+# Functional Design Plan — Unit 02: Identity & RBAC
+
+Dit plan beschrijft de stappen voor het functioneel ontwerpen van de Identity & Role-Based Access Control (RBAC) module (Unit 02).
+
+## Functional Design Stappen
+- [x] Analyseren van de hiërarchische rollen logica (Eigenaar > Beheerder > Gebruiker).
+- [x] Ontwerpen van de gebruikersbeheer workflows (aanmaken, wijzigen, verwijderen).
+- [x] Definiëren van de JWT authenticatie flow (login, token refresh).
+- [x] Uitwerken van de autorisatie regels voor module-specifieke rechten.
+- [x] Opstellen van de domein entiteiten (User, Role, Token).
+
+## Vragen voor Functional Design (Unit 02)
+
+### 1. Initiële Gebruiker (Bootstrapping)
+**Vraag 1.1**: Hoe moet de allereerste "Eigenaar" (Owner) van het systeem worden aangemaakt?
+- A) Via een database seed script bij de eerste start.
+- B) Via een specifieke configuratie in `appsettings.json`.
+- C) Via een verborgen/tijdelijk endpoint dat na eerste gebruik wordt gedeactiveerd.
+
+### 2. Gebruikersuitnodiging (FR-03)
+**Vraag 2.1**: Voor de creatie van nieuwe gebruikers: welke methode heeft de voorkeur voor de MVP?
+- A) **Direct**: Beheerder vult e-mail, rol én wachtwoord in. Account is direct actief.
+- B) **Uitnodiging**: Beheerder vult e-mail en rol in; systeem genereert een tijdelijk token/link waarmee de gebruiker zelf een wachtwoord instelt.
+
+### 3. Hiërarchie Handhaving
+**Vraag 3.1**: Waar moet de hiërarchie-controle (bijv. Beheerder mag Eigenaar niet wijzigen) primair plaatsvinden?
+- A) **Service Layer**: In de `IUserService` wordt bij elke actie gecontroleerd of de uitvoerder voldoende rechten heeft t.o.v. de doelgebruiker.
+- B) **Authorization Policies**: Gebruikmaken van custom `RequirementHandlers` die de hiërarchie valideren voordat de controller actie wordt aangeroepen.
+
+### 4. Refresh Tokens
+**Vraag 4.1**: Hoe moeten Refresh Tokens worden opgeslagen?
+- A) In de SQL database (gekoppeld aan de Gebruiker).
+- B) In-memory (alleen geschikt voor single-instance, gaat verloren bij restart).
+- C) Geen refresh tokens in de eerste versie van de MVP (alleen access tokens).
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de artifacts (`business-rules.md`, `logic-model.md`, `entities.md`) gegenereerd in `aidlc-docs/construction/identity-rbac/functional-design/`.
@@ -0,0 +1,33 @@
+# NFR Design Plan — Unit 02: Identity & RBAC
+
+Dit plan beschrijft de stappen voor het technisch ontwerpen van de non-functional requirements voor Unit 02.
+
+## NFR Design Stappen
+- [x] Uitwerken van de `ApplicationDbContext` configuratie voor schone tabelnamen.
+- [x] Ontwerpen van de `HierarchicalRoleRequirement` en bijbehorende `Handler`.
+- [x] Definiëren van de `IAuthService` contracten voor JWT en Refresh Token management.
+- [x] Uitwerken van het beveiligingsmechanisme voor het eenmalige Setup endpoint.
+- [x] Vastleggen van de database schema voor de `RefreshToken` en `Invitation` entiteiten.
+
+## Vragen voor NFR Design (Unit 02)
+
+### 1. Setup Endpoint Beveiliging
+**Vraag 1.1**: Hoe moeten we garanderen dat het `POST /api/setup/init` endpoint echt maar één keer bruikbaar is?
+- A) **Database Check**: Controleer of er al een gebruiker met de rol `Owner` bestaat. Zo ja, retourneer 403 Forbidden.
+- B) **Feature Flag/Config**: Gebruik een vlag in de database `IsSystemInitialized`.
+- C) **File System**: Controleer op de aanwezigheid van een lock-file (minder geschikt voor cloud/docker).
+
+### 2. JWT Signing
+**Vraag 2.1**: Waar moeten de JWT signing keys worden opgeslagen voor de MVP?
+- A) In `appsettings.json` (niet aanbevolen voor productie, maar eenvoudig voor dev).
+- B) In Environment Variables.
+- C) Gebruik van een lokaal gegenereerd certificaat/key file (voorbereiding op KeyVault).
+
+### 3. Invitation Token
+**Vraag 3.1**: Wat voor soort token moeten we gebruiken voor de uitnodigingen?
+- A) Een cryptografisch veilige random string (bijv. 32 bytes Base64).
+- B) Een GUID.
+- C) Een kort JWT token (self-contained, maar vereist key management).
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de technische ontwerpen gegenereerd in `aidlc-docs/construction/identity-rbac/nfr-design/`.
@@ -0,0 +1,38 @@
+# NFR Requirements Plan — Unit 02: Identity & RBAC
+
+Dit plan beschrijft de stappen voor het vaststellen van de non-functional requirements (NFR) voor de Identity & RBAC module (Unit 02).
+
+## NFR Assessment Stappen
+- [x] Vaststellen van de security baseline voor wachtwoordopslag en complexiteit.
+- [x] Definiëren van de token lifecycle (Access vs Refresh token duur).
+- [x] Bepalen van de audit-logging vereisten voor gevoelige acties (bijv. rolwijzigingen).
+- [x] Keuze van de database provider en ORM configuratie voor Identity.
+- [x] Performance overwegingen voor JWT validatie bij elk request.
+
+## NFR Vragen voor Unit 02
+
+### 1. Beveiliging & Wachtwoorden
+**Vraag 1.1**: Welke wachtwoord-complexiteit regels moeten we afdwingen?
+- A) **Standaard .NET Identity**: Minimaal 6 tekens, kleine letter, hoofdletter, cijfer en speciaal teken.
+- B) **Strikt**: Minimaal 12 tekens, verplichte variatie, geen bekende zwakke wachtwoorden.
+- C) **Eenvoudig**: Alleen minimale lengte (bijv. 8 tekens), geen complexiteitseisen.
+
+### 2. Token Lifecycle
+**Vraag 2.1**: Wat moeten de standaard geldigheidsduren zijn voor de tokens?
+- A) **Standaard**: Access Token: 1 uur, Refresh Token: 7 dagen.
+- B) **Kort/Veilig**: Access Token: 15 minuten, Refresh Token: 24 uur.
+- C) **Lang**: Access Token: 12 uur, Refresh Token: 30 dagen.
+
+### 3. Auditing
+**Vraag 3.1**: Welke acties moeten verplicht worden gelogd in een audit-trail (database)?
+- A) Alleen mislukte login pogingen.
+- B) Alle mutaties: Rolwijzigingen, gebruikerscreatie, en (de)activatie.
+- C) Alles inclusief succesvolle logins en token refreshes.
+
+### 4. Database & ORM
+**Vraag 4.1**: Gaan we voor Identity gebruik maken van Entity Framework Core met SQL Server (conform NFR-01)?
+- A) Ja, gebruik de standaard `AspNetIdentity` tabellen in de SQL database.
+- B) Ja, maar met een aangepast schema/tabelnamen om de "AspNet" prefix te vermijden.
+
+## Volgende Stappen
+Na beantwoording van deze vragen worden de artifacts (`nfr-requirements.md`, `tech-stack-decisions.md`) gegenereerd in `aidlc-docs/construction/identity-rbac/nfr-requirements/`.