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,57 @@
+# Application Design — SlpModularCms.Api
+
+Dit document consolideert het volledige applicatie-ontwerp voor de modulaire CMS API.
+
+## 1. Architectuur Overzicht
+De applicatie volgt een modulaire Clean Architecture structuur waarbij het **Core Framework** de centrale spil is. Modules zijn onafhankelijke projecten (.csproj) of DLL's die via een hybride laad-strategie worden geïntegreerd.
+
+- **Kleurgecodeerd Diagram**:
+```mermaid
+graph LR
+    subgraph "Core Phase"
+        Core[Core Framework]
+        ID[Identity Subsysteem]
+    end
+    
+    subgraph "Module Phase"
+        Avail[Availability Module]
+        Other[External Modules]
+    end
+    
+    Shell[API Shell]
+    
+    Shell --> Core
+    Shell --> Avail
+    Shell -.-> Other
+    
+    Avail --> Core
+    Other -.-> Core
+    
+    style Core fill:#BBDEFB,stroke:#1565C0,color:#000
+    style ID fill:#E3F2FD,stroke:#1565C0,color:#000
+    style Shell fill:#C8E6C9,stroke:#2E7D32,color:#000
+    style Avail fill:#FFF59D,stroke:#F57F17,color:#000
+```
+
+## 2. Belangrijkste Componenten
+Zie de gedetailleerde beschrijvingen in [components.md](./components.md).
+
+- **Core**: Gedeelde logica, Identity en interfaces.
+- **Availability Module**: MVP placeholder voor statuscontrole.
+- **API Shell**: Host en orchestrator.
+
+## 3. Interfaces & Services
+Zie [component-methods.md](./component-methods.md) en [services.md](./services.md).
+
+- **IModule**: Het contract voor module-integratie.
+- **IAuthService / IUserService**: Beheer van identiteit en hiërarchische RBAC.
+- **IAvailabilityService**: Controleert of de API of specifieke modules operationeel zijn.
+
+## 4. Ontwerpbeslissingen (Besloten in Plan)
+1. **Hybride Module Loading**: Core modules worden statisch geladen voor performance en type-safety; optionele modules kunnen dynamisch worden toegevoegd.
+2. **Identity in Core**: Voor de MVP is Identity een integraal onderdeel van het framework om complexe autorisatie-hiërarchieën (Owner > Admin > User) eenvoudiger te borgen.
+3. **Eenvoudige Projectstructuur**: Per module wordt één project gebruikt om de complexiteit laag te houden, met interne folders voor separation of concerns.
+4. **Policy-Based RBAC**: Gebruik van standaard ASP.NET Core `AuthorizationPolicy` voor het afdwingen van de rol-hiërarchie.
+
+## 5. Volgende Stappen
+Op basis van dit ontwerp wordt de applicatie opgesplitst in **Units of Work** in de volgende fase (Units Generation).
@@ -0,0 +1,37 @@
+# Component Dependencies — SlpModularCms.Api
+
+Dit document beschrijft de relaties en communicatiepatronen tussen de componenten.
+
+## 1. Dependency Diagram
+
+```mermaid
+graph TD
+    API[Web API Shell] --> Core[Core Framework / Identity]
+    API --> Avail[Availability Module]
+    Avail --> Core
+    
+    subgraph "External Modules (Optional)"
+        Mod[External Module DLL] -.-> Core
+    end
+    
+    API -.-> Mod
+```
+
+### Tekstuele Toelichting:
+- **Core Framework**: Is de centrale afhankelijkheid. Alle modules refereren naar de Core voor interfaces en Identity modellen. De Core mag zelf NOOIT refereren naar een module (Dependency Inversion).
+- **Web API Shell**: Heeft een harde referentie naar de Core en de Availability Module (voor de MVP stub).
+- **Modules**: Implementeren interfaces uit de Core. Worden door de API Shell geladen en geregistreerd in de DI container.
+
+## 2. Communicatiepatronen
+
+- **In-Process DI**: Alle communicatie tussen modules en het framework verloopt via de Dependency Injection container van ASP.NET Core.
+- **Shared Domain Models**: Modules gebruiken de gedeelde `User` en `Role` modellen uit de Core voor autorisatie-checks.
+- **Events (Toekomstig)**: Gebruik van een `IMediator` of intern event-systeem voor ontkoppelde communicatie tussen modules.
+
+## 3. Data Flow
+
+1. **Client Request**: Komt binnen bij de API Shell.
+2. **Availability Check**: Middleware roept `IAvailabilityService` (Availability Module) aan.
+3. **Authentication**: Middleware valideert JWT via Identity logica (Core).
+4. **Authorization**: Policy-based checks valideren de rol-hiërarchie (Core).
+5. **Execution**: Het request wordt afgehandeld door de relevante Module Controller.
@@ -0,0 +1,47 @@
+# Component Methods — SlpModularCms.Api
+
+Dit document specificeert de belangrijkste methoden en interfaces per component.
+
+## 1. IModule Interface (Core)
+Alle modules moeten deze interface implementeren om geregistreerd te kunnen worden.
+
+- `void RegisterServices(IServiceCollection services)`
+  - Registreert module-specifieke services in de DI container.
+- `void ConfigureMiddleware(IApplicationBuilder app)`
+  - Configureert module-specifieke middleware (optioneel).
+
+## 2. IAvailabilityService (Core Interface, Availability Implementatie)
+Interface voor de beschikbaarheidscontrole.
+
+- `Task<bool> IsAvailableAsync()`
+  - Retourneert of het systeem/module beschikbaar is.
+- `Task<AvailabilityDetails> GetDetailsAsync()`
+  - Geeft gedetailleerde statusinformatie terug (toekomstig).
+
+## 3. IAuthService (Identity - Core)
+Afhandeling van authenticatie.
+
+- `Task<AuthResult> LoginAsync(LoginRequest request)`
+  - Valideert credentials en geeft tokens terug.
+- `Task<AuthResult> RefreshTokenAsync(RefreshRequest request)`
+  - Vernieuwt een sessie met een refresh token.
+
+## 4. IUserService (Identity - Core)
+Beheer van gebruikers accounts.
+
+- `Task<UserDto> CreateUserAsync(CreateUserRequest request)`
+  - Maakt een nieuwe gebruiker aan (alleen voor Admin/Owner).
+- `Task<IEnumerable<UserDto>> GetAllUsersAsync()`
+  - Lijst met alle gebruikers (alleen voor Admin/Owner).
+- `Task UpdateUserRoleAsync(Guid userId, string newRole)`
+  - Wijzigt een rol (met hiërarchische validatie).
+- `Task DeleteUserAsync(Guid userId)`
+  - Verwijdert een gebruiker (voorkomt verwijdering Owner).
+- `Task SetModulePermissionAsync(Guid userId, string moduleName, bool hasAccess)`
+  - Kent module-specifieke rechten toe aan een gebruiker.
+
+## 5. Authorization Handlers (Identity - Core)
+Technisch mechanisme voor RBAC.
+
+- `HandleRequirementAsync(AuthorizationHandlerContext context, HierarchyRequirement requirement)`
+  - Valideert of de gebruiker de vereiste rol heeft op basis van de hiërarchie (Owner > Admin > User).
@@ -0,0 +1,40 @@
+# Components — SlpModularCms.Api
+
+Dit document beschrijft de belangrijkste functionele componenten van de CMS API en hun verantwoordelijkheden.
+
+## 1. Core Framework (SlpModularCms.Core)
+Het fundament van de applicatie. Bevat de gedeelde logica, interfaces en infrastructuur-configuratie.
+
+- **Verantwoordelijkheden**:
+  - Definiëren van basis-interfaces (`IModule`, `IAvailabilityService`).
+  - Cross-cutting concerns (logging, exception handling, validatie).
+  - Infrastructuur abstracties (Unit of Work, Repository interfaces).
+  - Bevat de **Identity** kernfunctionaliteit (Gebruikers, Rollen, JWT).
+
+## 2. Availability Module (SlpModularCms.Modules.Availability)
+Een specifieke module voor de beschikbaarheidscontrole.
+
+- **Verantwoordelijkheden**:
+  - Implementatie van `IAvailabilityService`.
+  - Stub-functionaliteit voor de MVP (retourneert altijd "beschikbaar").
+  - Toekomstige integratie met de Master-API.
+
+## 3. Web API Shell (SlpModularCms.Api)
+De host-applicatie (ASP.NET Core Web API).
+
+- **Verantwoordelijkheden**:
+  - Dependency Injection registratie van de Core en statisch gekoppelde modules.
+  - Dynamisch laden van optionele modules via Assembly loading (Hybride strategie).
+  - Hosting van Swagger/OpenAPI documentatie.
+  - Middleware configuratie (Auth, HTTPS, CORS).
+  - Routeerlaag naar module-controllers.
+
+## 4. Identity Component (Binnen Core)
+Hoewel onderdeel van de Core, fungeert dit als een onderscheidbaar subsysteem.
+
+- **Verantwoordelijkheden**:
+  - Inloggen en JWT generatie.
+  - Refresh token beheer.
+  - CRUD operaties op Gebruikers.
+  - Beheer van module-specifieke permissies voor Gebruikers.
+  - Hiërarchische RBAC handhaving via Authorization Policies.
@@ -0,0 +1,43 @@
+# Services — SlpModularCms.Api
+
+Dit document beschrijft de service-laag en de orkestratie van componenten.
+
+## 1. Module Orchestrator (Binnen API Shell)
+Verantwoordelijk voor het ontdekken en laden van modules bij het opstarten.
+
+- **Proces**:
+  1. Identificeer statisch gerefereerde projecten die `IModule` implementeren.
+  2. Scan de geconfigureerde "Modules" directory voor DLL's (dynamisch laden).
+  3. Roep `RegisterServices` aan op alle gevonden module-instanties.
+  4. Voeg de controllers van de modules toe aan de MVC-pipeline via `AddApplicationPart`.
+
+## 2. Identity Service Orchestratie
+De `IAuthService` maakt gebruik van ASP.NET Core Identity onder water om authenticatie te regelen.
+
+- **Workflow Login**:
+  - `AuthService` roept `UserManager` aan voor validatie.
+  - Bij succes genereert `TokenService` een JWT met claims (ID, Rol).
+  - Refresh token wordt opgeslagen in de database.
+
+## 3. Availability Check Flow
+Cross-cutting concern dat door de hele applicatie heen loopt.
+
+- **Interceptors/Middleware**:
+  - Elk inkomend request kan worden gecontroleerd tegen de `IAvailabilityService`.
+  - Als `IAvailabilityService.IsAvailableAsync()` false retourneert, stopt de pipeline met een `503 Service Unavailable`.
+
+## 4. RBAC Policy Orchestratie
+Het framework configureert globale policies op basis van de rollenhiërarchie.
+
+- **Policies**:
+  - `RequireOwnerRole`: Vereist expliciet de Owner claim.
+  - `RequireAdminRole`: Vereist Admin OF Owner claim.
+  - `RequireUserRole`: Vereist User, Admin OF Owner claim.
+
+## 5. Module-Specifieke Autorisatie
+Naast de globale rollen kunnen Beheerders en Eigenaars rechten per module toekennen aan Gebruikers.
+
+- **Mechanisme**:
+  - Het systeem houdt een koppeling bij tussen `User` en `Module` met bijbehorende permissies (bijv. `HasAccess`).
+  - **Custom Requirement**: Er wordt een `ModuleAccessRequirement` gedefinieerd die controleert of de huidige gebruiker expliciete toegang heeft tot de module die hij probeert te benaderen.
+  - **Override**: Eigenaars en Beheerders hebben standaard toegang tot alle modules (hiërarchie bypass).
@@ -0,0 +1,35 @@
+# Unit of Work Dependency Matrix — SlpModularCms.Api
+
+Dit document beschrijft de afhankelijkheden tussen de Units of Work.
+
+## Dependency Matrix
+
+| Unit | Afhankelijk van | Type | Reden |
+|---|---|---|---|
+| **U01: Core Base** | - | - | Fundament zonder externe afhankelijkheden binnen de solution. |
+| **U02: Identity** | U01 | Hard | Gebruikt interfaces en modellen uit Core Base. |
+| **U03: Availability** | U01 | Hard | Implementeert `IAvailabilityService` uit Core Base. |
+| **U04: API Shell** | U01, U02, U03 | Hard / Soft | Host alle componenten; orkestreert Identity en Modules. |
+
+## Visualisatie
+
+```mermaid
+graph TD
+    U04[U04: API Shell] --> U01[U01: Core Base]
+    U04 --> U02[U02: Identity]
+    U04 --> U03[U03: Availability]
+    
+    U02 --> U01
+    U03 --> U01
+    
+    style U01 fill:#BBDEFB,stroke:#1565C0,color:#000
+    style U02 fill:#E3F2FD,stroke:#1565C0,color:#000
+    style U03 fill:#FFF59D,stroke:#F57F17,color:#000
+    style U04 fill:#C8E6C9,stroke:#2E7D32,color:#000
+```
+
+## Update Strategie
+We volgen de natuurlijke hiërarchie:
+1. **U01** moet volledig functioneel zijn (interfaces) voordat we aan U02/U03 kunnen beginnen.
+2. **U02** en **U03** kunnen in theorie parallel ontwikkeld worden, maar we kiezen voor sequentieel (eerst Identity).
+3. **U04** integreert alles en wordt als laatste voltooid.
@@ -0,0 +1,38 @@
+# Unit of Work Story Map — SlpModularCms.Api
+
+Dit document mapt de User Stories naar de specifieke Units of Work voor de implementatie. Vanwege de 'Split Story' strategie worden sommige stories over meerdere units verdeeld (bijv. Interface in U01, Implementatie in U02/U03).
+
+## Story Mapping
+
+| Story ID | Titel | Primary Unit | Secundaire Unit(s) |
+|---|---|---|---|
+| **Authenticatie** | | | |
+| US-AUTH-01 | JWT Authenticatie | **U02** | U01 (Interfaces), U04 (Middleware) |
+| US-AUTH-02 | Inloggen via API | **U02** | U04 (Endpoint) |
+| US-AUTH-03 | Token vervaltijd | **U02** | |
+| US-AUTH-04 | Refresh tokens | **U02** | |
+| **Gebruikersbeheer** | | | |
+| US-USER-01 | Gebruiker aanmaken | **U02** | U04 (Endpoint) |
+| US-USER-02 | Gebruikerslijst raadplegen | **U02** | U04 (Endpoint) |
+| US-USER-03 | Gebruiker bijwerken | **U02** | U04 (Endpoint) |
+| US-USER-04 | Gebruiker verwijderen | **U02** | U04 (Endpoint) |
+| US-USER-05 | Geen zelfregistratie | **U02** | U04 (Logic) |
+| **Autorisatie** | | | |
+| US-AUTHZ-01 | Role-Based Access Control | **U02** | U04 (Policy Config) |
+| US-AUTHZ-02 | Eigenaarschap overdragen | **U02** | |
+| US-AUTHZ-03 | Hiërarchische bevoegdheden | **U02** | |
+| **Setup** | | | |
+| US-SETUP-01 | Eerste Eigenaar seeden | **U02** | |
+| US-SETUP-02 | Setup endpoint | **U04** | U02 (Identity logic) |
+| **Modules** | | | |
+| US-MOD-01 | Module laden bij applicatiestart | **U04** | U01 (Interfaces) |
+| US-MOD-02 | Module uitschakelen | **U04** | U01 (Logic) |
+| US-MOD-03 | Module-specifieke rechten | **U02** | U04 (Enforcement) |
+| **Beschikbaarheid** | | | |
+| US-AVAIL-01 | Beschikbaarheid controleren | **U03** | U01 (Interface), U04 (Middleware) |
+
+## Samenvatting per Unit
+- **U01 (Core Base)**: Legt de fundamenten voor US-MOD-01, US-AVAIL-01 en US-AUTH-01 (Interfaces).
+- **U02 (Identity)**: Bevat de hoofdbuik van de logica voor Authenticatie, Gebruikersbeheer en Autorisatie.
+- **U03 (Availability)**: Specifieke implementatie voor US-AVAIL-01.
+- **U04 (API Shell)**: De integratie-laag voor alle stories, specifiek de setup (US-SETUP-02) en module loading (US-MOD-01).
@@ -0,0 +1,25 @@
+# Unit of Work — SlpModularCms.Api
+
+Dit document beschrijft de decompositie van de API in ontwikkel-eenheden (Units of Work).
+
+## Overzicht van Units
+
+| Unit ID | Naam | Beschrijving | Belangrijkste Componenten |
+|---|---|---|---|
+| **U01** | **Core Base** | Het fundament: interfaces, cross-cutting concerns en basis framework logica. | `IModule`, `IAvailabilityService`, Exceptions, Logging setup. |
+| **U02** | **Identity & RBAC** | Het identiteitssysteem: Gebruikers, Rollen, JWT en de hiërarchische autorisatie logica. | `UserManager`, `RoleManager`, `IAuthService`, `IUserService`, Authorization Handlers. |
+| **U03** | **Availability Module** | De implementatie van de beschikbaarheidscontrole (stub). | `StubAvailabilityService`, `AvailabilityController`. |
+| **U04** | **API Shell & Integration** | De host applicatie die alles samenbrengt en modules laadt. | `Program.cs`, `ModuleOrchestrator`, Middleware, Swagger. |
+
+## Greenfield Code Organisatie Strategie
+
+We gebruiken een **Just-in-Time** project creatie strategie. De projecten worden aangemaakt wanneer de betreffende Unit aan de beurt is.
+
+### Mappenstructuur (Verwacht)
+- `src/SlpModularCms.Core/` (U01 & U02)
+- `src/SlpModularCms.Modules.Availability/` (U03)
+- `src/SlpModularCms.Api/` (U04 - Reeds aanwezig als scaffolding)
+
+### Project Type
+- Class Libraries voor Core en Modules.
+- ASP.NET Core Web API voor de Shell.
@@ -0,0 +1,69 @@
+# Application Design Plan — SlpModularCms.Api
+
+## Stap 1: Analyse & Voorbereiding
+- [x] Requirements en User Stories analyseren op component-grenzen.
+- [x] Architecturale stijl (Clean Architecture) vertalen naar componenten.
+
+## Stap 2: Ontwerp van Componenten & Verantwoordelijkheden
+- [x] **Core Framework Component**: Verantwoordelijk voor module-registratie, gedeelde interfaces en cross-cutting concerns.
+- [x] **Identity Module**: Gebruikersbeheer, authenticatie en de hiërarchische RBAC logica.
+- [x] **Availability Module**: De stub implementatie voor beschikbaarheidscontrole.
+- [x] **Web API Shell**: Het startpunt dat alles samenbrengt en Swagger host.
+- [x] Genereer `aidlc-docs/inception/application-design/components.md`.
+
+## Stap 3: Interface & Method Design
+- [x] Definieer `IModule` contract voor module-initialisatie.
+- [x] Definieer `IAvailabilityService` contract.
+- [x] Definieer Identity services (bijv. `IUserService`, `IAuthService`).
+- [x] Genereer `aidlc-docs/inception/application-design/component-methods.md`.
+
+## Stap 4: Service Orchestratie & Dependency Mapping
+- [x] Ontwerp het mechanisme voor het laden van modules (Dependency Injection patronen).
+- [x] Map de afhankelijkheden tussen Core, Modules en de API Shell.
+- [x] Genereer `aidlc-docs/inception/application-design/services.md`.
+- [x] Genereer `aidlc-docs/inception/application-design/component-dependency.md`.
+
+## Stap 5: Consolidatie
+- [x] Genereer `aidlc-docs/inception/application-design/application-design.md`.
+- [x] Valideer op consistentie met de hiërarchische rollen (RBAC) en modulaire eisen.
+
+---
+
+## Vragen voor Application Design
+
+Beantwoord de volgende vragen om het ontwerp te verfijnen. Vul je keuze in na de `[Answer]:` tag.
+
+### Vraag 1: Module Loading Strategie
+Hoe moeten modules technisch geladen worden door het raamwerk?
+A) Statische referentie: Modules zijn project-referenties in de API Shell (.csproj references).
+B) Dynamisch laden: Modules worden als DLL's uit een folder geladen bij opstarten.
+C) Hybride: Statische referentie voor core modules, dynamisch voor optionele modules.
+X) Anders: ...
+
+[Answer]: C
+
+### Vraag 2: Identity Locatie
+Wordt Identity gezien als een kernonderdeel van het framework of als een uitwisselbare module?
+A) Kernonderdeel (Core): Altijd aanwezig, diep geïntegreerd.
+B) Module: Een aparte .csproj die optioneel/vervangbaar is.
+X) Anders: ...
+
+[Answer]: A
+
+### Vraag 3: Clean Architecture Diepte
+Welke project-structuur heeft de voorkeur voor de modules?
+A) Eenvoudig: Eén project per module met interne folderstructuur (API, Logic, Data).
+B) Volledige Clean Architecture: Meerdere projecten per module (bijv. Identity.Domain, Identity.Application, Identity.Infrastructure).
+C) API-First: Modules bevatten alleen Controllers en Application logica, maken gebruik van gedeelde Core Data laag.
+X) Anders: ...
+
+[Answer]: A
+
+### Vraag 4: RBAC Implementatie
+Hoe moet de hiërarchische RBAC (Owner > Admin > User) technisch worden afgedwongen?
+A) ASP.NET Core Policies: Gebruik maken van `AuthorizationPolicy` die de hiërarchie controleert.
+B) Custom Middleware: Een interceptor die bij elk request de rollen en hiërarchie valideert.
+C) Service-level checks: De logica wordt handmatig in de services aangeroepen voor elke actie.
+X) Anders: ...
+
+[Answer]: A
@@ -0,0 +1,142 @@
+# Execution Plan
+
+## Detailed Analysis Summary
+
+### Project Context
+- **Project Type**: Greenfield
+- **Primary Objective**: Bouwen van een modulaire CMS API met hiërarchische RBAC en beschikbaarheidscontrole stub.
+- **Architectuur**: Modulair (.csproj per module), Clean Architecture / Gelaagde architectuur.
+
+### Change Impact Assessment
+- **User-facing changes**: Ja — RESTful endpoints voor authenticatie, gebruikersbeheer en modulebeheer.
+- **Structural changes**: Ja — Opzetten van het module-laad-mechanisme en de core framework structuur.
+- **Data model changes**: Ja — Identity modellen (User, Role) en module-registraties.
+- **API changes**: Ja — REST contracten voor alle MVP functionaliteit.
+- **NFR impact**: Ja — Security (JWT), Modulairiteit (DI), Onderhoudbaarheid (PBT).
+
+### Risk Assessment
+- **Risk Level**: Medium
+- **Rollback Complexity**: Easy (Git-based development)
+- **Testing Complexity**: Moderate (Vereist integratietesten voor de hiërarchische rollen en module isolatie)
+
+## Workflow Visualization
+
+```mermaid
+flowchart TD
+    Start(["User Request"])
+    
+    subgraph INCEPTION["<font color='#000000'>🔵 INCEPTION PHASE</font>"]
+        WD["Workspace Detection<br/><b>COMPLETED</b>"]
+        RE["Reverse Engineering<br/><b>SKIPPED (Greenfield)</b>"]
+        RA["Requirements Analysis<br/><b>COMPLETED</b>"]
+        US["User Stories<br/><b>COMPLETED</b>"]
+        WP["Workflow Planning<br/><b>COMPLETED</b>"]
+        AD["Application Design<br/><b>EXECUTE</b>"]
+        UG["Units Generation<br/><b>EXECUTE</b>"]
+    end
+    
+    subgraph CONSTRUCTION["<font color='#000000'>🟢 CONSTRUCTION PHASE</font>"]
+        FD["Functional Design<br/>(per unit)<br/><b>EXECUTE</b>"]
+        NFRA["NFR Requirements<br/>(per unit)<br/><b>EXECUTE</b>"]
+        NFRD["NFR Design<br/>(per unit)<br/><b>EXECUTE</b>"]
+        ID["Infrastructure Design<br/>(per unit)<br/><b>SKIP</b>"]
+        CG["Code Generation<br/>(Planning + Generation)<br/><b>EXECUTE</b>"]
+        BT["Build and Test<br/><b>EXECUTE</b>"]
+    end
+    
+    subgraph OPERATIONS["<font color='#000000'>🟡 OPERATIONS PHASE</font>"]
+        OPS["Operations<br/><b>PLACEHOLDER</b>"]
+    end
+    
+    Start --> WD
+    WD --> RA
+    RA --> US
+    US --> WP
+    WP --> AD
+    AD --> UG
+    UG --> FD
+    FD --> NFRA
+    NFRA --> NFRD
+    NFRD --> CG
+    CG -.->|Volgende Unit| FD
+    CG --> BT
+    BT --> End(["Complete"])
+
+    style WD fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
+    style RA fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
+    style US fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
+    style WP fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
+    style AD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
+    style UG fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
+    style FD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
+    style NFRA fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
+    style NFRD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
+    style ID fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
+    style CG fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
+    style BT fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
+    style OPS fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
+    style RE fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
+    style Start fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
+    style End fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
+    style INCEPTION fill:#BBDEFB,stroke:#1565C0,stroke-width:2px,color:#000000
+    style CONSTRUCTION fill:#C8E6C9,stroke:#2E7D32,stroke-width:2px,color:#000000
+    style OPERATIONS fill:#FFF59D,stroke:#F57F17,stroke-width:2px,color:#000000
+
+    linkStyle default stroke:#333333,stroke-width:2.5px
+    linkStyle 10 stroke:#333333,stroke-width:2.5px,stroke-dasharray: 5 5
+```
+
+### Text Alternative
+Phase 1: INCEPTION
+- Stage 1: Workspace Detection (COMPLETED)
+- Stage 2: Reverse Engineering (SKIPPED)
+- Stage 3: Requirements Analysis (COMPLETED)
+- Stage 4: User Stories (COMPLETED)
+- Stage 5: Workflow Planning (COMPLETED)
+- Stage 6: Application Design (EXECUTE)
+- Stage 7: Units Generation (EXECUTE)
+
+Phase 2: CONSTRUCTION
+- Stage 8: Functional Design (EXECUTE per unit)
+- Stage 9: NFR Requirements (EXECUTE per unit)
+- Stage 10: NFR Design (EXECUTE per unit)
+- Stage 11: Infrastructure Design (SKIP)
+- Stage 12: Code Generation (EXECUTE per unit)
+- Stage 13: Build and Test (EXECUTE)
+
+Phase 3: OPERATIONS
+- Stage 14: Operations (PLACEHOLDER)
+
+## Phases to Execute
+
+### 🔵 INCEPTION PHASE
+- [x] Workspace Detection (COMPLETED)
+- [x] Requirements Analysis (COMPLETED)
+- [x] User Stories (COMPLETED)
+- [x] Workflow Planning (COMPLETED)
+- [x] Application Design - VOLTOOID
+- [x] Units Generation - VOLTOOID
+
+### 🟢 CONSTRUCTION PHASE
+- [x] Functional Design — VOLTOOID
+- [x] NFR Requirements — VOLTOOID
+- [x] NFR Design — VOLTOOID
+- [ ] Infrastructure Design - SKIP
+- [x] Code Generation — VOLTOOID
+- [x] Build and Test — VOLTOOID
+
+### 🟡 OPERATIONS PHASE
+- [ ] Operations - PLACEHOLDER
+  - **Rationale**: Toekomstige uitbreiding voor deployment en monitoring.
+
+## Success Criteria
+- **Primary Goal**: Een functioneel raamwerk met een modulaire architectuur en werkend gebruikersbeheer.
+- **Key Deliverables**:
+  - API Framework met module loading.
+  - Identity/Auth module met hiërarchische rollen.
+  - Beschikbaarheidscontrole stub.
+  - Swagger documentatie.
+- **Quality Gates**:
+  - Alle unit tests passeren.
+  - Security baseline regels zijn toegepast.
+  - PBT tests voor token/mapping logica zijn succesvol.
@@ -0,0 +1,131 @@
+# Story Generation Plan — SlpModularCms.Api
+
+## Uitvoeringsplan
+
+### Stap 1: Persona's definiëren
+- [x] Eigenaar (Owner) persona aanmaken
+- [x] Beheerder (Administrator) persona aanmaken
+- [x] Gebruiker (User) persona aanmaken
+
+### Stap 2: User Stories genereren per domein
+- [x] Authenticatie stories (login, token refresh, logout)
+- [x] Gebruikersbeheer stories (aanmaken, bewerken, verwijderen gebruikers)
+- [x] Autorisatie stories (rolbeheer, bevoegdheidsgrenzen)
+- [x] Module stories (module laden, module uitschakelen)
+- [x] Beschikbaarheidscontrole stories (placeholder/stub interactie)
+
+### Stap 3: Acceptatiecriteria toevoegen
+- [x] Acceptatiecriteria per story definiëren (INVEST-compliant)
+
+### Stap 4: Feature-story mapping
+- [x] Elke story koppelen aan het relevante feature-domein (Authenticatie, Gebruikersbeheer, Autorisatie, Setup, Modules, Beschikbaarheidscontrole)
+
+### Stap 5: Persona-story mapping
+- [x] Elke story koppelen aan relevante persona('s) (Eigenaar, Beheerder, Gebruiker)
+
+### Stap 6: Artifacts opslaan
+- [x] `aidlc-docs/inception/user-stories/stories.md` aanmaken
+- [x] `aidlc-docs/inception/user-stories/personas.md` aanmaken
+
+---
+
+## Vragen voor Story Planning
+
+Beantwoord elke vraag door de letter van jouw keuze in te vullen na de `[Answer]:` tag.
+
+---
+
+### Vraag 1: Story breakdown aanpak
+Hoe moeten de user stories worden georganiseerd?
+
+A) Feature-gebaseerd — stories gegroepeerd per systeemfunctionaliteit (authenticatie, gebruikersbeheer, modules)
+B) Persona-gebaseerd — stories gegroepeerd per gebruikerstype (Eigenaar, Beheerder, Gebruiker)
+C) User Journey-gebaseerd — stories volgen de workflow van een gebruiker van begin tot eind
+D) Epic-gebaseerd — hiërarchische structuur met epics en sub-stories
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+### Vraag 2: Story granulariteit
+Hoe gedetailleerd moeten de user stories zijn?
+
+A) Hoog niveau — epics met globale beschrijvingen, details komen later
+B) Standaard — "Als [rol] wil ik [actie] zodat [doel]" met basisacceptatiecriteria
+C) Gedetailleerd — uitgebreide acceptatiecriteria met edge cases en foutscenario's
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: B
+
+---
+
+### Vraag 3: Gebruiker (User) rol — specifieke rechten
+De requirements vermelden dat Gebruikers "configureerbare rechten per klant" hebben. Welke standaard rechten moet een Gebruiker hebben in de MVP (voordat een Beheerder iets aanpast)?
+
+A) Alleen lezen — Gebruiker kan alleen content bekijken, niets aanpassen
+B) Beperkt bewerken — Gebruiker kan eigen profiel en toegewezen content bewerken
+C) Geen rechten — Gebruiker heeft standaard geen rechten totdat een Beheerder ze instelt
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: X, Alleen lezen en eigen profiel bewerken.
+
+---
+
+### Vraag 4: Eigenaarschap overdracht
+Hoe moet eigenaarschap overdracht werken?
+
+A) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar wordt automatisch Beheerder
+B) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar behoudt ook de Eigenaar rol (meerdere eigenaars mogelijk)
+C) Eigenaar wijst een andere gebruiker aan als nieuwe Eigenaar — de huidige Eigenaar kiest zelf welke rol hij behoudt
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: B
+
+---
+
+### Vraag 5: Wachtwoord reset / initieel wachtwoord
+Hoe wordt het initiële wachtwoord van een nieuwe gebruiker ingesteld?
+
+A) Beheerder/Eigenaar stelt een tijdelijk wachtwoord in — gebruiker moet dit wijzigen bij eerste login
+B) Beheerder/Eigenaar stelt een permanent wachtwoord in — geen verplichte wijziging
+C) Systeem stuurt een uitnodigingslink per e-mail — gebruiker stelt zelf wachtwoord in
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: C
+
+---
+
+### Vraag 6: Refresh token gedrag
+Hoe moeten refresh tokens werken?
+
+A) Refresh token is eenmalig bruikbaar — na gebruik wordt een nieuw refresh token uitgegeven (rotation)
+B) Refresh token is herbruikbaar tot vervaldatum — geen rotation
+C) Refresh token vervalt bij uitloggen en bij inactiviteit na een configureerbare periode
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+### Vraag 7: Eerste Eigenaar aanmaken
+Hoe wordt de eerste Eigenaar van een nieuwe installatie aangemaakt? (Er is geen andere Eigenaar/Beheerder om dit te doen)
+
+A) Via een seed/migratie script dat bij eerste deployment wordt uitgevoerd
+B) Via een speciaal setup-endpoint dat alleen beschikbaar is als er nog geen Eigenaar bestaat
+C) Via configuratie in appsettings (e-mail + wachtwoord bij eerste start)
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: X, Optie A of B, wat is het handigste? Optie A zou ook kunnen als directe aanpassing in database en dan een Wachtwoord vergeten optie
+
+---
+
+### Vraag 8: Module rechten voor Gebruikers
+Kunnen Gebruikers rechten krijgen die specifiek zijn per module?
+
+A) Ja — modules kunnen eigen rechten definiëren die een Beheerder/Eigenaar aan Gebruikers kan toekennen
+B) Nee — rechten zijn globaal voor de hele API, niet per module
+C) Nog niet in MVP — architectuur moet het later mogelijk maken
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
@@ -0,0 +1,58 @@
+# Story Planning Verduidelijkingsvragen — SlpModularCms.Api
+
+Er zijn twee antwoorden die verdere verduidelijking nodig hebben voordat we kunnen doorgaan.
+
+---
+
+## Verduidelijking 1: Gebruiker (User) standaard rechten (Vraag 3)
+
+Je antwoordde: *"Alleen lezen en eigen profiel bewerken"*
+
+Dit combineert twee aspecten: leesrechten voor content én het bewerken van het eigen profiel.
+Om de user stories correct te kunnen schrijven, moet ik weten hoe dit precies werkt.
+
+### Verduidelijkingsvraag 1a
+Wat mag een Gebruiker standaard lezen (zonder dat een Beheerder iets instelt)?
+
+A) Alle content die beschikbaar is in de API (publieke en beveiligde content)
+B) Alleen content die expliciet aan de gebruiker is toegewezen door een Beheerder
+C) Alleen publieke content — beveiligde content vereist expliciete toewijzing
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: C
+
+---
+
+### Verduidelijkingsvraag 1b
+Wat mag een Gebruiker bewerken aan zijn eigen profiel?
+
+A) Alleen wachtwoord wijzigen
+B) Wachtwoord + weergavenaam / profielinformatie
+C) Wachtwoord + alle profielgegevens behalve e-mailadres en rol
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: C
+
+---
+
+## Verduidelijking 2: Eerste Eigenaar aanmaken (Vraag 7)
+
+Je vroeg: *"Optie A of B, wat is het handigste?"*
+
+Hier is mijn advies:
+
+**Optie A (seed/migratie script)** is het meest gebruikelijk bij .NET projecten met EF Core. Het wordt automatisch uitgevoerd bij `dotnet ef database update` of bij de eerste start van de applicatie. Nadeel: de credentials staan in configuratie of code.
+
+**Optie B (setup-endpoint)** is gebruiksvriendelijker — je navigeert naar `/api/setup` en vult de gegevens in via een API call. Het endpoint verdwijnt automatisch zodra er een Eigenaar bestaat. Dit is veiliger omdat er geen credentials in configuratiebestanden staan.
+
+**Mijn aanbeveling**: Optie B — het setup-endpoint is veiliger, gebruiksvriendelijker en past beter bij een API-first aanpak.
+
+### Verduidelijkingsvraag 2
+Welke aanpak kies je voor het aanmaken van de eerste Eigenaar?
+
+A) Seed/migratie script (Optie A) — automatisch bij eerste deployment via EF Core seed
+B) Setup-endpoint (Optie B) — speciaal `/api/setup` endpoint, alleen beschikbaar als er nog geen Eigenaar bestaat (aanbevolen)
+C) Combinatie — seed script voor development/testing, setup-endpoint voor productie
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: C
@@ -0,0 +1,56 @@
+# Units of Work Plan — SlpModularCms.Api
+
+Dit plan beschrijft hoe we de CMS API gaan opsplitsen in logische eenheden (Units of Work) voor de implementatie.
+
+## Stap 1: Systeem Decompositie
+- [x] Analyseer `application-design.md` om de eenheden te identificeren.
+- [x] Definieer de grenzen tussen het Core framework en de modules.
+
+## Stap 2: Genereren van Unit Artifacts
+- [x] Genereer `aidlc-docs/inception/application-design/unit-of-work.md`.
+- [x] Genereer `aidlc-docs/inception/application-design/unit-of-work-dependency.md`.
+- [x] Genereer `aidlc-docs/inception/application-design/unit-of-work-story-map.md`.
+- [x] Documenteer de mappenstructuur en project-indeling (Greenfield).
+
+## Stap 3: Validatie
+- [x] Controleer of alle User Stories zijn toegewezen aan een unit.
+- [x] Valideer de afhankelijkheden (geen circulaire afhankelijkheden).
+
+---
+
+## Vragen voor Units Generation
+
+Beantwoord de volgende vragen om de decompositie te verfijnen. Vul je keuze in na de `[Answer]:` tag.
+
+### Vraag 1: Ontwikkelvolgorde
+In welke volgorde wil je de eenheden ontwikkelen?
+A) Sequentieel: Eerst de volledige Core, dan de Availability module, dan de API Shell.
+B) Incrementeel: Een minimale Core, direct gevolgd door de Availability module om de orkestratie te testen.
+C) Parallel: (Niet aanbevolen voor solo-ontwikkeling, maar mogelijk voor de opzet).
+X) Anders: ...
+
+[Answer]: A
+
+### Vraag 2: Unit Granulariteit
+Hoe fijnmazig moeten de eenheden zijn voor de "Construction Phase"?
+A) Grofmazig: Eén unit voor de hele Core (inclusief Identity en RBAC).
+B) Fijnmazig: Identity apart van de Core Base (interfaces/cross-cutting).
+X) Anders: ...
+
+[Answer]: B
+
+### Vraag 3: Story Mapping Strategie
+Sommige stories overspannen meerdere technische lagen. Hoe moeten we deze mappen?
+A) Primary Unit: Map de story naar de unit waar de meeste logica zit (bijv. US-USER-01 naar Identity).
+B) Split Story: Deel de story op in technische sub-taken per unit (verhoogt administratie).
+X) Anders: ...
+
+[Answer]: B
+
+### Vraag 4: Project Creatie (Greenfield)
+Moeten alle .csproj bestanden in één keer worden aangemaakt in de eerste unit, of pas wanneer de unit aan de beurt is?
+A) Alles vooraf: Creëer de hele solution structuur in Unit 1.
+B) Just-in-time: Creëer projecten alleen wanneer de betreffende unit wordt geïmplementeerd.
+X) Anders: ...
+
+[Answer]: B
@@ -0,0 +1,27 @@
+# User Stories Assessment — SlpModularCms.Api
+
+## Request Analyse
+- **Origineel verzoek**: Een modulaire CMS API bouwen met authenticatie, autorisatie (hiërarchische rollen) en gebruikersbeheer als MVP
+- **Gebruikersimpact**: Direct — meerdere gebruikerstypes (Eigenaar, Beheerder, Gebruiker) met verschillende rechten en workflows
+- **Complexiteitsniveau**: Complex — hiërarchische rollen, modulaire architectuur, beschikbaarheidscontrole placeholder
+- **Stakeholders**: Ontwikkelaar (API-bouwer), klanten (eindgebruikers van de CMS), toekomstige module-ontwikkelaars
+
+## Assessment Criteria Voldaan
+
+- [x] **High Priority**: Nieuwe gebruikersgerichte functionaliteit (authenticatie, gebruikersbeheer)
+- [x] **High Priority**: Multi-persona systeem (Eigenaar, Beheerder, Gebruiker met verschillende rechten)
+- [x] **High Priority**: Customer-facing API (klanten gebruiken deze API voor websites/applicaties)
+- [x] **High Priority**: Complexe business logica (hiërarchische rollen, bevoegdheidsgrenzen)
+- [x] **Medium Priority**: Meerdere componenten en gebruikerstouchpoints
+- [x] **Medium Priority**: Hoge business impact en risico op misverstand bij rolhiërarchie
+
+## Beslissing
+**User Stories uitvoeren**: Ja
+
+**Redenering**: Het project heeft meerdere duidelijk onderscheiden gebruikerstypes met complexe, hiërarchische bevoegdheden. User stories zullen helpen om de exacte grenzen van elke rol te verduidelijken, acceptatiecriteria te definiëren voor de rolhiërarchie, en een gedeeld begrip te creëren van wat elke gebruiker wel en niet mag doen.
+
+## Verwachte Uitkomsten
+- Duidelijke acceptatiecriteria per rol (Eigenaar, Beheerder, Gebruiker)
+- Concrete testspecificaties voor autorisatielogica
+- Helder overzicht van gebruikersworkflows (login, gebruikersbeheer, module-interactie)
+- Betere basis voor implementatie van de hiërarchische RBAC
@@ -0,0 +1,141 @@
+# Requirements Verificatie Vragen — SlpModularCms.Api
+
+Beantwoord elke vraag door de letter van jouw keuze in te vullen na de `[Answer]:` tag.
+Kies de laatste optie (X/Other) als geen van de opties past, en beschrijf je voorkeur.
+
+---
+
+## Vraag 1: MVP Scope — Authenticatie methode
+Welke authenticatiemethode moet het raamwerk ondersteunen voor de MVP?
+
+A) JWT Bearer tokens (stateless, geschikt voor API's)
+B) ASP.NET Core Identity met cookies (stateful, geschikt voor web apps)
+C) Beide: JWT én cookie-authenticatie
+D) OAuth2 / OpenID Connect (externe identity provider zoals Azure AD, Google)
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 2: Gebruikersbeheer — Rollen en rechten
+Welk autorisatiemodel moet worden gebruikt voor gebruikersbeheer?
+
+A) Eenvoudige rollen (bijv. Admin, User, Guest)
+B) Claims-based autorisatie (flexibele claims per gebruiker)
+C) Role-based + Claims-based gecombineerd
+D) Policy-based autorisatie (complexe regels via policies)
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 3: Database technologie
+Welke database technologie moet worden gebruikt?
+
+A) SQL Server (Microsoft, goed geïntegreerd met .NET)
+B) PostgreSQL (open-source, krachtig)
+C) SQLite (lichtgewicht, goed voor development/kleine projecten)
+D) MySQL / MariaDB
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 4: ORM / Data Access
+Welke data access strategie moet worden gebruikt?
+
+A) Entity Framework Core (code-first, migrations)
+B) Dapper (lichtgewicht micro-ORM, SQL-first)
+C) Entity Framework Core + Dapper gecombineerd
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 5: Module architectuur
+Hoe moeten modules worden geïmplementeerd in de API?
+
+A) Als aparte class libraries (.csproj) die worden gerefereerd in het hoofdproject
+B) Als feature folders binnen één project (verticale slice architectuur)
+C) Als aparte microservices / API's
+D) Als NuGet packages die dynamisch worden geladen
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 6: "Master"-API beschikbaarheidscontrole (MVP scope)
+De README beschrijft een "master"-API voor beschikbaarheids/toegangscontrole. Wat moet er in de MVP worden opgenomen?
+
+A) Alleen een placeholder / stub — de echte implementatie komt later
+B) Een eenvoudige lokale configuratie-check (bijv. een beschikbaarheidssleutel in appsettings)
+C) Een volledige basis-implementatie van de master-API connectie
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 7: API stijl
+Welke API stijl moet worden gebruikt?
+
+A) REST (standaard HTTP endpoints)
+B) REST + minimale API's (ASP.NET Core Minimal APIs)
+C) GraphQL
+D) gRPC
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 8: Multi-tenancy
+Moeten meerdere klanten (tenants) in dezelfde instantie kunnen draaien?
+
+A) Ja — multi-tenant vanaf het begin (één instantie, meerdere klanten)
+B) Nee — één instantie per klant (single-tenant)
+C) Nog niet besloten, maar architectuur moet het later mogelijk maken
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: B
+
+---
+
+## Vraag 9: Deployment omgeving
+Waar wordt de API gedeployed?
+
+A) Azure (App Service, Container Apps, etc.)
+B) On-premises / eigen server
+C) Docker containers (cloud-agnostisch)
+D) Nog niet bepaald
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: B
+
+---
+
+## Vraag 10: Security extensie
+Moeten security-baseline regels worden afgedwongen voor dit project?
+
+A) Ja — dwing alle SECURITY regels af als harde constraints (aanbevolen voor productie-applicaties)
+B) Nee — sla alle SECURITY regels over (geschikt voor PoC's, prototypes en experimentele projecten)
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: A
+
+---
+
+## Vraag 11: Property-Based Testing extensie
+Moeten property-based testing (PBT) regels worden afgedwongen voor dit project?
+
+A) Ja — dwing alle PBT regels af als harde constraints (aanbevolen voor projecten met business logic, datatransformaties of stateful componenten)
+B) Gedeeltelijk — dwing PBT regels alleen af voor pure functies en serialisatie round-trips
+C) Nee — sla alle PBT regels over (geschikt voor eenvoudige CRUD applicaties)
+X) Andere (beschrijf na [Answer]: tag)
+
+[Answer]: B
@@ -0,0 +1,156 @@
+# Requirements Document — SlpModularCms.Api
+
+## Intent Analyse
+
+- **Gebruikersverzoek**: Een modulaire CMS API bouwen als raamwerk voor klantprojecten, met authenticatie, autorisatie en gebruikersbeheer als MVP, uitbreidbaar via modules.
+- **Request Type**: Nieuw project (Greenfield)
+- **Scope Schatting**: Systeem-breed — meerdere componenten (raamwerk + modules architectuur)
+- **Complexiteit Schatting**: Complex — meerdere lagen, modulaire architectuur, beschikbaarheidscontrole mechanisme
+
+---
+
+## Functionele Requirements
+
+### FR-01: Authenticatie
+- Het systeem MOET JWT Bearer token authenticatie ondersteunen
+- Tokens MOETEN een configureerbare vervaltijd hebben
+- Het systeem MOET refresh tokens ondersteunen voor het vernieuwen van sessies
+- Tokens MOETEN gebruikersidentiteit en rollen bevatten als claims
+
+### FR-02: Autorisatie
+- Het systeem MOET role-based access control (RBAC) ondersteunen
+- Standaard rollen (hiërarchie hoog → laag): **Eigenaar (Owner)**, **Beheerder (Administrator)**, **Gebruiker (User)**
+- Endpoints MOETEN beveiligd kunnen worden op basis van rollen
+- **Eigenaar**:
+  - Heeft alle rechten zonder uitzondering
+  - Kan NIET worden verwijderd door andere rollen
+  - Kan een andere gebruiker als Eigenaar instellen (eigenaarschap overdragen)
+  - Kan rollen van alle gebruikers wijzigen inclusief Beheerders
+- **Beheerder**:
+  - Heeft dezelfde rechten als Eigenaar, behalve:
+    - Kan de Eigenaar GEEN andere rol geven
+    - Kan GEEN nieuwe Eigenaar instellen
+  - Kan Gebruikers en andere Beheerders (lager in hiërarchie) beheren
+  - Kan content beheren
+- **Gebruiker**:
+  - Heeft beperkte rechten die per klant/tenant configureerbaar zijn
+  - Specifieke rechten worden ingesteld door een Beheerder of Eigenaar
+- Een gebruiker kan nooit een hogere rol aan zichzelf of anderen toekennen dan zijn eigen rol
+
+### FR-03: Gebruikersbeheer
+- Het systeem MOET CRUD-operaties bieden voor gebruikers (aanmaken, lezen, bijwerken, verwijderen)
+- Gebruikers MOETEN een e-mailadres, wachtwoord en rol hebben
+- Wachtwoorden MOETEN veilig worden opgeslagen (gehasht)
+- **GEEN zelfregistratie**: Gebruikers kunnen zich NIET zelf registreren via een publiek endpoint
+- Alleen een **Beheerder** of **Eigenaar** mag nieuwe gebruikers aanmaken
+- Het systeem MOET een login endpoint bieden (`POST /api/auth/login`)
+- Beheerders en Eigenaars MOETEN gebruikersrollen kunnen wijzigen (binnen hun hiërarchische bevoegdheid)
+- Bij aanmaken van een gebruiker stelt de Beheerder/Eigenaar het initiële wachtwoord in of wordt een uitnodigingsflow gebruikt
+
+### FR-04: Module Architectuur
+- Modules MOETEN worden geïmplementeerd als aparte class libraries (.csproj)
+- Het raamwerk MOET een mechanisme bieden om modules te registreren en te laden
+- Modules MOETEN onafhankelijk van elkaar kunnen worden toegevoegd of verwijderd
+- Het raamwerk MOET een standaard interface/contract definiëren waaraan modules moeten voldoen
+
+### FR-05: Beschikbaarheidscontrole (Master-API — MVP Placeholder)
+- Het raamwerk MOET een placeholder/stub bevatten voor de toekomstige master-API beschikbaarheidscontrole
+- De stub MOET een interface definiëren (`IAvailabilityService` of vergelijkbaar) zodat de echte implementatie later eenvoudig kan worden ingeplugd
+- De stub MOET standaard altijd "beschikbaar" retourneren in de MVP
+- De architectuur MOET het mogelijk maken om modules op afstand uit te zetten (via de interface, implementatie later)
+
+### FR-06: API Endpoints
+- De API MOET RESTful endpoints bieden (standaard HTTP verbs: GET, POST, PUT, DELETE)
+- De API MOET Swagger/OpenAPI documentatie bieden
+- Alle beveiligde endpoints MOETEN een geldig JWT token vereisen
+
+---
+
+## Niet-Functionele Requirements
+
+### NFR-01: Technologie Stack
+- **Runtime**: .NET 10 (ASP.NET Core)
+- **Database**: SQL Server
+- **ORM**: Entity Framework Core (code-first met migrations)
+- **Authenticatie**: ASP.NET Core Identity + JWT Bearer
+- **API Stijl**: REST (Controllers)
+- **Documentatie**: Swagger / OpenAPI (Swashbuckle)
+
+### NFR-02: Architectuur
+- **Patroon**: Single-tenant (één instantie per klant)
+- **Module systeem**: Aparte class libraries (.csproj) per module
+- **Deployment**: On-premises / eigen server
+- **Structuur**: Clean Architecture of gelaagde architectuur (API → Application → Domain → Infrastructure)
+
+### NFR-03: Beveiliging (Security Baseline — INGESCHAKELD)
+- Wachtwoorden MOETEN worden gehasht met een veilig algoritme (bcrypt of ASP.NET Core Identity standaard)
+- JWT tokens MOETEN worden ondertekend met een sterke sleutel (minimaal 256-bit)
+- De API MOET HTTPS afdwingen
+- Gevoelige configuratie (connection strings, JWT secrets) MOETEN via environment variables of secrets management worden beheerd
+- Input validatie MOET worden toegepast op alle endpoints
+- SQL injection MOET worden voorkomen (via EF Core parameterisatie)
+- CORS MOET expliciet worden geconfigureerd
+
+### NFR-04: Onderhoudbaarheid
+- Code MOET goed gestructureerd en leesbaar zijn
+- Modules MOETEN een duidelijk contract/interface volgen
+- Het project MOET unit tests bevatten voor business logic
+- Migrations MOETEN worden bijgehouden in versiebeheer
+
+### NFR-05: Schaalbaarheid
+- De architectuur MOET het eenvoudig maken om nieuwe modules toe te voegen zonder het raamwerk te wijzigen
+- De beschikbaarheidscontrole interface MOET later kunnen worden vervangen door een echte implementatie zonder grote refactoring
+
+### NFR-06: Property-Based Testing (GEDEELTELIJK INGESCHAKELD)
+- Property-based testing MOET worden toegepast voor pure functies en serialisatie round-trips
+- Specifiek: token generatie/validatie logica en data mapping functies
+
+---
+
+## Gebruikersscenario's
+
+### Scenario 1: Beheerder voegt gebruiker toe
+Een Beheerder of Eigenaar maakt een nieuwe gebruiker aan via `POST /api/users` met e-mail, wachtwoord en rol. Het systeem maakt het account aan en retourneert een bevestiging. Zelfregistratie is niet mogelijk.
+
+### Scenario 2: Gebruiker logt in
+Een gebruiker logt in via `POST /api/auth/login` met e-mail en wachtwoord. Het systeem valideert de credentials en retourneert een JWT access token en refresh token.
+
+### Scenario 3: Beheerder/Eigenaar beheert gebruikers
+Een Beheerder of Eigenaar raadpleegt alle gebruikers via `GET /api/users`, wijzigt een rol via `PUT /api/users/{id}/role` (binnen hiërarchische bevoegdheid), of verwijdert een gebruiker via `DELETE /api/users/{id}`. Een Eigenaar kan niet worden verwijderd door een Beheerder.
+
+### Scenario 4: Beveiligd endpoint benaderen
+Een client stuurt een request naar een beveiligd endpoint met een JWT token in de Authorization header. Het systeem valideert het token en verleent of weigert toegang op basis van de rol.
+
+### Scenario 5: Module wordt geladen
+Bij het opstarten van de API worden alle geregistreerde modules automatisch geladen en hun endpoints/services geregistreerd in de DI container.
+
+---
+
+## Technische Context
+
+- **Workspace Root**: `K:\Development\Projects\SlpModularCms`
+- **Hoofdproject**: `SlpModularCms.Api` (ASP.NET Core Web API)
+- **Solution**: `SlpModularCms.sln`
+- **Toekomstige uitbreiding**: Master-API module voor beschikbaarheidscontrole (buiten MVP scope)
+
+---
+
+## Extension Configuratie
+
+| Extension | Ingeschakeld | Beslist bij |
+|---|---|---|
+| Security Baseline | Ja | Requirements Analysis |
+| Property-Based Testing | Gedeeltelijk | Requirements Analysis |
+
+---
+
+## Succescriteria MVP
+
+- [ ] Gebruikers kunnen inloggen via JWT (geen zelfregistratie)
+- [ ] Rollen (Eigenaar, Beheerder, Gebruiker) zijn geïmplementeerd met hiërarchische bevoegdheden
+- [ ] CRUD voor gebruikers is beschikbaar voor Beheerders en Eigenaars
+- [ ] Eigenaar kan niet worden verwijderd en kan eigenaarschap overdragen
+- [ ] Module architectuur is opgezet met minimaal één voorbeeldmodule
+- [ ] Beschikbaarheidscontrole placeholder/stub is aanwezig
+- [ ] Swagger documentatie is beschikbaar
+- [ ] Alle beveiligingsvereisten zijn geïmplementeerd
@@ -0,0 +1,105 @@
+# Persona's — SlpModularCms.Api
+
+## Overzicht
+
+Dit document beschrijft de drie persona's die gebruikt worden in de user stories voor SlpModularCms.Api. Elke persona vertegenwoordigt een gebruikerstype met specifieke rechten, verantwoordelijkheden en doelen.
+
+---
+
+## Persona 1: Eigenaar (Owner)
+
+**Naam**: Erik de Eigenaar  
+**Rol**: Eigenaar  
+**Omschrijving**: Erik is de primaire beheerder en eigenaar van het CMS-systeem. Hij heeft volledige controle over het systeem en kan niet worden verwijderd. Hij is verantwoordelijk voor de initiële setup en het beheer van de hoogste bevoegdheden.
+
+### Kenmerken
+- Heeft alle rechten in het systeem
+- Kan niet worden verwijderd door andere gebruikers
+- Kan eigenaarschap overdragen aan andere gebruikers (nieuwe Eigenaar aanwijzen)
+- Kan Beheerders en Gebruikers aanmaken, bewerken en verwijderen
+- Kan modules laden, uitschakelen en configureren
+- Kan module-specifieke rechten instellen per Gebruiker
+
+### Doelen
+- Het systeem stabiel en veilig houden
+- Juiste gebruikers de juiste toegang geven
+- Modules activeren die de klant nodig heeft
+- Eigenaarschap kunnen overdragen bij organisatiewijzigingen
+
+### Frustraties
+- Onbedoeld zichzelf kunnen uitsluiten van het systeem
+- Geen overzicht hebben van wie welke rechten heeft
+
+---
+
+## Persona 2: Beheerder (Administrator)
+
+**Naam**: Bas de Beheerder  
+**Rol**: Beheerder  
+**Omschrijving**: Bas is een vertrouwde medewerker die het dagelijkse beheer van het CMS uitvoert. Hij kan bijna alles wat een Eigenaar kan, maar heeft geen bevoegdheid over eigenaarsbeheer.
+
+### Kenmerken
+- Kan Gebruikers aanmaken, bewerken en verwijderen
+- Kan rollen toewijzen aan Gebruikers (maar niet de Eigenaar-rol)
+- Kan module-specifieke rechten instellen per Gebruiker
+- Kan modules uitschakelen (afhankelijk van configuratie)
+- Kan **geen** eigenaarschap overdragen of nieuwe Eigenaar aanwijzen
+- Kan **geen** andere Beheerders of Eigenaars verwijderen
+
+### Doelen
+- Nieuwe medewerkers snel toegang geven tot het systeem
+- Gebruikersrechten aanpassen op basis van functiewijzigingen
+- Overzicht houden over wie toegang heeft tot welke modules
+
+### Frustraties
+- Niet kunnen ingrijpen bij problemen met Eigenaar-accounts
+- Onduidelijkheid over welke acties hij wel/niet mag uitvoeren
+
+---
+
+## Persona 3: Gebruiker (User)
+
+**Naam**: Ursula de Gebruiker  
+**Rol**: Gebruiker  
+**Omschrijving**: Ursula is een eindgebruiker van het CMS. Ze heeft beperkte rechten die door een Beheerder of Eigenaar zijn ingesteld. Haar rechten kunnen per klant/tenant verschillen.
+
+### Kenmerken
+- Kan publieke content lezen (standaard leesrechten)
+- Kan eigen profielgegevens bewerken (naam, wachtwoord — maar niet e-mail of rol)
+- Heeft module-specifieke rechten die per klant worden ingesteld door Beheerder/Eigenaar
+- Kan **geen** andere gebruikers aanmaken of beheren
+- Kan **geen** rollen toewijzen of wijzigen
+
+### Doelen
+- Toegang krijgen tot de content en functionaliteit die ze nodig heeft
+- Eigen profiel up-to-date houden
+- Efficiënt werken binnen de toegewezen rechten
+
+### Frustraties
+- Geen toegang hebben tot functionaliteit die ze nodig heeft
+- Onduidelijkheid over wat ze wel/niet mag doen in het systeem
+
+---
+
+## Rolhiërarchie
+
+```
+Eigenaar (Owner)
+    └── Beheerder (Administrator)
+            └── Gebruiker (User)
+```
+
+| Bevoegdheid | Eigenaar | Beheerder | Gebruiker |
+|---|:---:|:---:|:---:|
+| Eigen profiel bewerken (naam/wachtwoord) | ✅ | ✅ | ✅ |
+| Publieke content lezen | ✅ | ✅ | ✅ |
+| Gebruikers aanmaken (via uitnodiging) | ✅ | ✅ | ❌ |
+| Gebruikers bewerken | ✅ | ✅ | ❌ |
+| Gebruikers verwijderen | ✅ | ✅* | ❌ |
+| Rollen toewijzen (Beheerder/Gebruiker) | ✅ | ✅ | ❌ |
+| Eigenaar aanwijzen / eigenaarschap overdragen | ✅ | ❌ | ❌ |
+| Modules laden/uitschakelen | ✅ | ✅ | ❌ |
+| Module-rechten instellen per Gebruiker | ✅ | ✅ | ❌ |
+| Systeem setup (eerste Eigenaar) | ✅ | ❌ | ❌ |
+
+*Beheerder kan geen Eigenaars of andere Beheerders verwijderen.
@@ -0,0 +1,353 @@
+# User Stories — SlpModularCms.Api
+
+## Overzicht
+
+Dit document bevat alle INVEST-compliant user stories voor SlpModularCms.Api, georganiseerd per feature-domein. Elke story is getagd met het feature-domein en gekoppeld aan de relevante persona('s).
+
+**Formaat per story:**
+- Story: "Als [rol] wil ik [actie] zodat [doel]"
+- `[Feature: ...]` — feature-domein tag
+- `[Personas: ...]` — gekoppelde persona('s)
+- Acceptatiecriteria (bullet-stijl of Given/When/Then)
+
+---
+
+## Feature: Authenticatie
+
+### US-AUTH-01: Inloggen met e-mail en wachtwoord
+
+**Story**: Als een geregistreerde gebruiker wil ik kunnen inloggen met mijn e-mailadres en wachtwoord zodat ik toegang krijg tot het systeem.
+
+`[Feature: Authenticatie]` `[Personas: Eigenaar, Beheerder, Gebruiker]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een geregistreerde gebruiker met geldig e-mailadres en wachtwoord  
+  **Wanneer** de gebruiker `POST /api/auth/login` aanroept met correcte credentials  
+  **Dan** ontvangt de gebruiker een JWT access token en een refresh token
+- **Gegeven** een gebruiker met een ongeldig wachtwoord  
+  **Wanneer** de gebruiker probeert in te loggen  
+  **Dan** ontvangt de gebruiker een `401 Unauthorized` response
+- **Gegeven** een niet-bestaand e-mailadres  
+  **Wanneer** de gebruiker probeert in te loggen  
+  **Dan** ontvangt de gebruiker een `401 Unauthorized` response (geen onderscheid voor security)
+- Het JWT access token bevat de gebruikersrol als claim
+- Het access token heeft een beperkte geldigheidsduur (bijv. 15 minuten)
+
+---
+
+### US-AUTH-02: Access token vernieuwen (refresh token rotation)
+
+**Story**: Als een ingelogde gebruiker wil ik mijn access token kunnen vernieuwen via een refresh token zodat ik ingelogd blijf zonder opnieuw mijn wachtwoord in te voeren.
+
+`[Feature: Authenticatie]` `[Personas: Eigenaar, Beheerder, Gebruiker]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een gebruiker met een geldig refresh token  
+  **Wanneer** de gebruiker `POST /api/auth/refresh` aanroept  
+  **Dan** ontvangt de gebruiker een nieuw access token én een nieuw refresh token (rotation)
+- Het oude refresh token is na gebruik ongeldig (eenmalig bruikbaar)
+- **Gegeven** een al gebruikt of verlopen refresh token  
+  **Wanneer** de gebruiker probeert te refreshen  
+  **Dan** ontvangt de gebruiker een `401 Unauthorized` response
+- Bij hergebruik van een al gebruikt refresh token worden alle tokens van de gebruiker ingetrokken (token reuse detection)
+
+---
+
+### US-AUTH-03: Uitloggen
+
+**Story**: Als een ingelogde gebruiker wil ik kunnen uitloggen zodat mijn sessie veilig wordt beëindigd.
+
+`[Feature: Authenticatie]` `[Personas: Eigenaar, Beheerder, Gebruiker]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een ingelogde gebruiker  
+  **Wanneer** de gebruiker `POST /api/auth/logout` aanroept  
+  **Dan** wordt het refresh token ingetrokken en is het niet meer bruikbaar
+- Na uitloggen geeft het ingetrokken refresh token een `401 Unauthorized` bij gebruik
+- Het access token verloopt op zijn eigen geldigheidsduur (stateless JWT)
+
+---
+
+### US-AUTH-04: Wachtwoord instellen via uitnodigingslink
+
+**Story**: Als een uitgenodigde gebruiker wil ik mijn wachtwoord instellen via de uitnodigingslink die ik per e-mail heb ontvangen zodat ik toegang krijg tot het systeem zonder dat een beheerder een wachtwoord voor mij instelt.
+
+`[Feature: Authenticatie]` `[Personas: Eigenaar, Beheerder, Gebruiker]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een uitnodigingstoken dat per e-mail is verstuurd  
+  **Wanneer** de gebruiker `POST /api/auth/accept-invitation` aanroept met het token en een nieuw wachtwoord  
+  **Dan** wordt het wachtwoord ingesteld en is de gebruiker actief
+- Het uitnodigingstoken is eenmalig bruikbaar en heeft een vervaldatum
+- **Gegeven** een verlopen of al gebruikt uitnodigingstoken  
+  **Wanneer** de gebruiker probeert het wachtwoord in te stellen  
+  **Dan** ontvangt de gebruiker een `400 Bad Request` met een duidelijke foutmelding
+- Het wachtwoord moet voldoen aan de wachtwoordvereisten (minimale lengte, complexiteit)
+- Na het instellen van het wachtwoord kan de gebruiker direct inloggen
+
+---
+
+## Feature: Gebruikersbeheer
+
+### US-USER-01: Gebruiker uitnodigen via e-mail
+
+**Story**: Als Eigenaar of Beheerder wil ik een nieuwe gebruiker kunnen uitnodigen via e-mail zodat de gebruiker zelf zijn wachtwoord kan instellen en toegang krijgt tot het systeem.
+
+`[Feature: Gebruikersbeheer]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar of Beheerder  
+  **Wanneer** `POST /api/users/invite` wordt aangeroepen met naam, e-mailadres en rol  
+  **Dan** wordt een uitnodigingslink per e-mail verstuurd en wordt de gebruiker aangemaakt met status "Uitgenodigd"
+- De uitnodigingslink bevat een uniek, tijdelijk token
+- **Gegeven** een e-mailadres dat al in gebruik is  
+  **Wanneer** een uitnodiging wordt verstuurd  
+  **Dan** ontvangt de aanroeper een `409 Conflict` response
+- Een Beheerder kan alleen de rol "Gebruiker" of "Beheerder" toewijzen (niet "Eigenaar")
+- Een Eigenaar kan alle rollen toewijzen behalve een tweede Eigenaar via deze route (zie US-AUTHZ-02)
+- Niet-geauthenticeerde gebruikers ontvangen `401 Unauthorized`
+- Een Gebruiker die dit endpoint aanroept ontvangt `403 Forbidden`
+
+---
+
+### US-USER-02: Gebruikersgegevens bewerken
+
+**Story**: Als Eigenaar of Beheerder wil ik de gegevens van een gebruiker kunnen bewerken zodat ik naam, e-mail of rol kan aanpassen bij functiewijzigingen.
+
+`[Feature: Gebruikersbeheer]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar of Beheerder  
+  **Wanneer** `PUT /api/users/{id}` wordt aangeroepen met gewijzigde gegevens  
+  **Dan** worden de gegevens bijgewerkt en wordt `200 OK` teruggegeven
+- Een Beheerder kan de rol van een Eigenaar niet wijzigen
+- Een Beheerder kan geen andere Beheerder degraderen naar Gebruiker (alleen Eigenaar mag dit)
+- **Gegeven** een niet-bestaande gebruiker-ID  
+  **Dan** ontvangt de aanroeper `404 Not Found`
+- Een Gebruiker die dit endpoint aanroept ontvangt `403 Forbidden`
+
+---
+
+### US-USER-03: Gebruiker verwijderen
+
+**Story**: Als Eigenaar of Beheerder wil ik een gebruiker kunnen verwijderen zodat voormalige medewerkers geen toegang meer hebben tot het systeem.
+
+`[Feature: Gebruikersbeheer]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar  
+  **Wanneer** `DELETE /api/users/{id}` wordt aangeroepen voor een Beheerder of Gebruiker  
+  **Dan** wordt de gebruiker verwijderd en ontvangt de aanroeper `204 No Content`
+- Een Eigenaar kan niet worden verwijderd (ook niet door een andere Eigenaar via dit endpoint)
+- Een Beheerder kan alleen Gebruikers verwijderen, niet andere Beheerders of Eigenaars
+- **Gegeven** een Beheerder die probeert een andere Beheerder te verwijderen  
+  **Dan** ontvangt de aanroeper `403 Forbidden`
+- Alle actieve tokens van de verwijderde gebruiker worden ingetrokken
+
+---
+
+### US-USER-04: Lijst van gebruikers opvragen
+
+**Story**: Als Eigenaar of Beheerder wil ik een overzicht van alle gebruikers kunnen opvragen zodat ik inzicht heb in wie toegang heeft tot het systeem.
+
+`[Feature: Gebruikersbeheer]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar of Beheerder  
+  **Wanneer** `GET /api/users` wordt aangeroepen  
+  **Dan** ontvangt de aanroeper een lijst van alle gebruikers met naam, e-mail, rol en status
+- De lijst bevat geen wachtwoorden of token-informatie
+- Een Gebruiker die dit endpoint aanroept ontvangt `403 Forbidden`
+
+---
+
+### US-USER-05: Eigen profiel bewerken
+
+**Story**: Als ingelogde gebruiker wil ik mijn eigen profielgegevens kunnen bewerken zodat mijn naam en wachtwoord up-to-date zijn.
+
+`[Feature: Gebruikersbeheer]` `[Personas: Eigenaar, Beheerder, Gebruiker]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een ingelogde gebruiker  
+  **Wanneer** `PUT /api/users/me` wordt aangeroepen met gewijzigde naam of wachtwoord  
+  **Dan** worden de gegevens bijgewerkt en wordt `200 OK` teruggegeven
+- Een gebruiker kan zijn eigen e-mailadres **niet** wijzigen via dit endpoint
+- Een gebruiker kan zijn eigen rol **niet** wijzigen via dit endpoint
+- Bij wachtwoordwijziging moet het huidige wachtwoord worden meegegeven ter verificatie
+- Het nieuwe wachtwoord moet voldoen aan de wachtwoordvereisten
+
+---
+
+## Feature: Autorisatie
+
+### US-AUTHZ-01: Rol toewijzen aan gebruiker
+
+**Story**: Als Eigenaar of Beheerder wil ik de rol van een gebruiker kunnen wijzigen zodat ik bevoegdheden kan aanpassen bij functiewijzigingen.
+
+`[Feature: Autorisatie]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar  
+  **Wanneer** `PATCH /api/users/{id}/role` wordt aangeroepen met een nieuwe rol  
+  **Dan** wordt de rol bijgewerkt voor alle rollen (Beheerder, Gebruiker)
+- Een Beheerder kan alleen de rol "Gebruiker" toewijzen aan een bestaande Gebruiker
+- Een Beheerder kan **geen** Eigenaar-rol toewijzen of afnemen
+- Een Beheerder kan **geen** andere Beheerder degraderen
+- **Gegeven** een ongeldige rolwaarde  
+  **Dan** ontvangt de aanroeper `400 Bad Request`
+
+---
+
+### US-AUTHZ-02: Eigenaarschap overdragen
+
+**Story**: Als Eigenaar wil ik eigenaarschap kunnen overdragen aan een andere gebruiker zodat de organisatie een nieuwe primaire beheerder kan aanwijzen.
+
+`[Feature: Autorisatie]` `[Personas: Eigenaar]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar  
+  **Wanneer** `POST /api/users/{id}/make-owner` wordt aangeroepen  
+  **Dan** krijgt de doelgebruiker de Eigenaar-rol en behoudt de huidige Eigenaar ook zijn Eigenaar-rol
+- Het systeem kan meerdere Eigenaars hebben
+- De doelgebruiker moet een bestaande actieve gebruiker zijn
+- Een Beheerder die dit endpoint aanroept ontvangt `403 Forbidden`
+- **Gegeven** een niet-bestaande gebruiker-ID  
+  **Dan** ontvangt de aanroeper `404 Not Found`
+
+---
+
+### US-AUTHZ-03: Hiërarchische bevoegdheidsgrenzen handhaven
+
+**Story**: Als systeembeheerder wil ik dat het systeem automatisch hiërarchische bevoegdheidsgrenzen handhaaft zodat gebruikers nooit meer rechten kunnen toewijzen dan ze zelf hebben.
+
+`[Feature: Autorisatie]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- Een Beheerder kan geen acties uitvoeren op gebruikers met een hogere of gelijke rol (Eigenaar, andere Beheerder)
+- Een Gebruiker kan geen beheersacties uitvoeren
+- Pogingen om boven de eigen bevoegdheid te handelen resulteren in `403 Forbidden`
+- De rolhiërarchie is: Eigenaar > Beheerder > Gebruiker
+
+---
+
+## Feature: Setup
+
+### US-SETUP-01: Eerste Eigenaar aanmaken via seed script (development)
+
+**Story**: Als ontwikkelaar wil ik een seed script kunnen uitvoeren zodat er automatisch een eerste Eigenaar-account wordt aangemaakt in de development-omgeving.
+
+`[Feature: Setup]` `[Personas: Eigenaar]`
+
+**Acceptatiecriteria:**
+- Het seed script maakt een Eigenaar-account aan als er nog geen Eigenaar bestaat
+- De seed-gegevens (e-mail, wachtwoord) zijn configureerbaar via omgevingsvariabelen of appsettings
+- Het script is idempotent: meerdere uitvoeringen maken geen duplicaten
+- Het script is alleen beschikbaar/uitvoerbaar in de development-omgeving
+
+---
+
+### US-SETUP-02: Eerste Eigenaar aanmaken via setup-endpoint (productie)
+
+**Story**: Als systeembeheerder wil ik een beveiligd setup-endpoint kunnen aanroepen zodat ik de eerste Eigenaar kan aanmaken bij de initiële productie-installatie.
+
+`[Feature: Setup]` `[Personas: Eigenaar]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een systeem zonder bestaande Eigenaar  
+  **Wanneer** `POST /api/setup/initialize` wordt aangeroepen met naam, e-mail en wachtwoord  
+  **Dan** wordt de eerste Eigenaar aangemaakt en wordt `201 Created` teruggegeven
+- **Gegeven** een systeem waar al een Eigenaar bestaat  
+  **Wanneer** het setup-endpoint wordt aangeroepen  
+  **Dan** ontvangt de aanroeper `409 Conflict` (setup al voltooid)
+- Het endpoint is na de eerste succesvolle aanroep permanent uitgeschakeld
+- Het endpoint vereist geen authenticatie (het systeem heeft immers nog geen gebruikers)
+
+---
+
+## Feature: Modules
+
+### US-MOD-01: Module laden bij applicatiestart
+
+**Story**: Als systeembeheerder wil ik dat modules automatisch worden geladen bij het opstarten van de applicatie zodat de geconfigureerde functionaliteit direct beschikbaar is.
+
+`[Feature: Modules]` `[Personas: Eigenaar]`
+
+**Acceptatiecriteria:**
+- Bij applicatiestart worden alle geconfigureerde modules automatisch geladen
+- Modules worden geregistreerd als aparte class libraries (.csproj)
+- Als een module niet geladen kan worden, wordt dit gelogd en start de applicatie zonder die module
+- De applicatie start ook als er geen modules zijn geconfigureerd
+
+---
+
+### US-MOD-02: Module uitschakelen
+
+**Story**: Als Eigenaar of Beheerder wil ik een module kunnen uitschakelen zodat de functionaliteit van die module niet meer beschikbaar is voor gebruikers.
+
+`[Feature: Modules]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar of Beheerder  
+  **Wanneer** `POST /api/modules/{moduleId}/disable` wordt aangeroepen  
+  **Dan** is de module uitgeschakeld en zijn de endpoints van die module niet meer bereikbaar
+- Uitgeschakelde module-endpoints geven `503 Service Unavailable` of `404 Not Found`
+- Een Gebruiker die dit endpoint aanroept ontvangt `403 Forbidden`
+- De modulestatus wordt opgeslagen zodat deze na herstart behouden blijft
+
+---
+
+### US-MOD-03: Module-specifieke rechten instellen per Gebruiker
+
+**Story**: Als Eigenaar of Beheerder wil ik module-specifieke rechten kunnen instellen per Gebruiker zodat ik per klant/tenant kan bepalen welke functionaliteit een Gebruiker mag gebruiken.
+
+`[Feature: Modules]` `[Personas: Eigenaar, Beheerder]`
+
+**Acceptatiecriteria:**
+- **Gegeven** een Eigenaar of Beheerder  
+  **Wanneer** `PUT /api/users/{id}/module-permissions` wordt aangeroepen met module-rechten  
+  **Dan** worden de module-specifieke rechten opgeslagen voor die gebruiker
+- Modules kunnen eigen rechten definiëren die via dit endpoint worden ingesteld
+- Een Gebruiker zonder specifiek module-recht heeft standaard geen toegang tot die module-functionaliteit
+- Een Gebruiker die dit endpoint aanroept ontvangt `403 Forbidden`
+
+---
+
+## Feature: Beschikbaarheidscontrole
+
+### US-AVAIL-01: Beschikbaarheid controleren via placeholder service
+
+**Story**: Als systeembeheerder wil ik dat het systeem een beschikbaarheidscontrole uitvoert via een placeholder service zodat de architectuur klaar is voor toekomstige integratie met een externe availability-API of master-API.
+
+`[Feature: Beschikbaarheidscontrole]` `[Personas: Eigenaar]`
+
+**Acceptatiecriteria:**
+- Het systeem bevat een `IAvailabilityService` interface als placeholder
+- De standaard implementatie (`StubAvailabilityService`) retourneert altijd "beschikbaar" (stub)
+- De stub-implementatie is vervangbaar door een echte implementatie via dependency injection
+- De beschikbaarheidscontrole wordt niet geblokkeerd in de MVP (stub retourneert altijd succes)
+- De interface is gedocumenteerd met de verwachte toekomstige contracten
+
+---
+
+## Story Overzicht
+
+| Story ID | Omschrijving | Feature | Personas |
+|---|---|---|---|
+| US-AUTH-01 | Inloggen met e-mail en wachtwoord | Authenticatie | Eigenaar, Beheerder, Gebruiker |
+| US-AUTH-02 | Access token vernieuwen (refresh rotation) | Authenticatie | Eigenaar, Beheerder, Gebruiker |
+| US-AUTH-03 | Uitloggen | Authenticatie | Eigenaar, Beheerder, Gebruiker |
+| US-AUTH-04 | Wachtwoord instellen via uitnodigingslink | Authenticatie | Eigenaar, Beheerder, Gebruiker |
+| US-USER-01 | Gebruiker uitnodigen via e-mail | Gebruikersbeheer | Eigenaar, Beheerder |
+| US-USER-02 | Gebruikersgegevens bewerken | Gebruikersbeheer | Eigenaar, Beheerder |
+| US-USER-03 | Gebruiker verwijderen | Gebruikersbeheer | Eigenaar, Beheerder |
+| US-USER-04 | Lijst van gebruikers opvragen | Gebruikersbeheer | Eigenaar, Beheerder |
+| US-USER-05 | Eigen profiel bewerken | Gebruikersbeheer | Eigenaar, Beheerder, Gebruiker |
+| US-AUTHZ-01 | Rol toewijzen aan gebruiker | Autorisatie | Eigenaar, Beheerder |
+| US-AUTHZ-02 | Eigenaarschap overdragen | Autorisatie | Eigenaar |
+| US-AUTHZ-03 | Hiërarchische bevoegdheidsgrenzen handhaven | Autorisatie | Eigenaar, Beheerder |
+| US-SETUP-01 | Eerste Eigenaar via seed script (dev) | Setup | Eigenaar |
+| US-SETUP-02 | Eerste Eigenaar via setup-endpoint (productie) | Setup | Eigenaar |
+| US-MOD-01 | Module laden bij applicatiestart | Modules | Eigenaar |
+| US-MOD-02 | Module uitschakelen | Modules | Eigenaar, Beheerder |
+| US-MOD-03 | Module-specifieke rechten instellen per Gebruiker | Modules | Eigenaar, Beheerder |
+| US-AVAIL-01 | Beschikbaarheid controleren via placeholder service | Beschikbaarheidscontrole | Eigenaar |