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,88 @@
+# AI-DLC State Tracking
+
+## Project Information
+- **Feature Name**: SlpModularCms.Api Implementation
+- **Feature Slug**: slp-modular-cms-api
+- **Project Type**: Greenfield
+- **Start Date**: 2026-06-07T22:43:00Z
+- **Current Stage**: CONSTRUCTION PHASE - VOLTOOID
+- **Branch**: unknown
+
+## Workspace State
+- **Existing Code**: Ja (alleen standaard ASP.NET Core scaffolding: Program.cs, csproj)
+- **Programming Languages**: C# (.NET 10)
+- **Build System**: .NET SDK / csproj
+- **Project Structure**: Modular monolith (src/ folder)
+- **Reverse Engineering Needed**: Nee (geen business logic aanwezig)
+- **Workspace Root**: K:\Development\Projects\SlpModularCms
+
+## Code Location Rules
+- **Application Code**: src/ folder (NEVER in aidlc-docs/)
+- **Feature Documentation**: aidlc-docs/features/slp-modular-cms-api/ only
+- **Shared Artifacts**: aidlc-docs/_shared/
+- **Structure patterns**: Zie code-generation.md Critical Rules
+
+## Language Configuration
+- **Documentation Language**: User Language (Dutch)
+- **Conversation Language**: User Language (Dutch)
+
+## Extension Configuration
+| Extension | Ingeschakeld | Beslist bij |
+|---|---|---|
+| Security Baseline | Ja | Requirements Analysis |
+| Property-Based Testing | Gedeeltelijk | Requirements Analysis |
+
+## Execution Plan Summary
+- **Total Stages**: 14
+- **Stages to Execute**: Application Design, Units Generation, Functional Design, NFR Requirements, NFR Design, Code Generation, Build and Test.
+- **Stages to Skip**: Reverse Engineering (Greenfield), Infrastructure Design (Standard setup).
+
+## Stage Progress
+
+### INCEPTION PHASE
+- [x] Workspace Detection — VOLTOOID (2026-06-07T22:43:00Z)
+- [x] Requirements Analysis — VOLTOOID (2026-06-07T22:43:00Z)
+- [x] User Stories — VOLTOOID (2026-06-08T23:10:00Z)
+- [x] Workflow Planning — VOLTOOID (2026-06-10T21:14:00Z)
+- [x] Application Design — VOLTOOID (2026-06-10T22:05:00Z)
+- [x] Units Generation — VOLTOOID (2026-06-10T22:30:00Z)
+
+### CONSTRUCTION PHASE
+
+#### Unit 01: Core Base
+- [x] Functional Design — VOLTOOID (2026-06-10T22:55:00Z)
+- [x] NFR Requirements — VOLTOOID (2026-06-11T23:42:00Z)
+- [x] NFR Design — VOLTOOID (2026-06-11T23:48:00Z)
+- [x] Code Generation — VOLTOOID (2026-06-11T23:55:00Z)
+- [x] Build and Test — VOLTOOID (2026-06-11T23:55:00Z)
+
+#### Unit 02: Identity & RBAC
+- [x] Functional Design — VOLTOOID (2026-06-12T01:05:00Z)
+- [x] NFR Requirements — VOLTOOID (2026-06-12T01:05:00Z)
+- [x] NFR Design — VOLTOOID (2026-06-12T01:05:00Z)
+- [x] Code Generation — VOLTOOID (2026-06-12T01:10:00Z)
+- [x] Build and Test — VOLTOOID (2026-06-12T01:10:00Z)
+
+#### Unit 03: Availability Module
+- [x] Functional Design — VOLTOOID (2026-06-12T01:15:00Z)
+- [x] NFR Requirements — VOLTOOID (2026-06-12T01:15:00Z)
+- [x] NFR Design — VOLTOOID (2026-06-12T01:15:00Z)
+- [x] Code Generation — VOLTOOID (2026-06-12T01:20:00Z)
+- [x] Build and Test — VOLTOOID (2026-06-12T01:20:00Z)
+
+#### Unit 04: API Shell & Integration
+- [x] Functional Design — VOLTOOID (2026-06-12T01:25:00Z)
+- [x] NFR Requirements — VOLTOOID (2026-06-12T01:25:00Z)
+- [x] NFR Design — VOLTOOID (2026-06-12T01:25:00Z)
+- [x] Code Generation — VOLTOOID (2026-06-12T01:35:00Z)
+- [x] Build and Test — VOLTOOID (2026-06-12T01:35:00Z)
+- [x] Database Migrations — VOLTOOID (2026-06-12T21:18:00Z)
+- [x] Identity & RBAC Implementation — VOLTOOID (2026-06-12T21:50:00Z)
+- [x] Documentation & Cleanup — VOLTOOID (2026-06-12T21:55:00Z)
+
+### OPERATIONS PHASE
+- [ ] Operations — PLACEHOLDER
+
+---
+Migrated from legacy format on 2026-06-12T16:47:00Z
+See legacy-state-backup-[timestamp].md for pre-migration state
@@ -0,0 +1,349 @@
+## Migration from Legacy Format
+**Timestamp**: 2026-06-12T16:47:00Z
+**Migration Type**: Automatic
+**Target Format**: Feature-based (v2)
+**Status**: Successful
+**Backup Location**: aidlc-docs/legacy-audit-backup-20260612T1646...Z.md
+
+This project was migrated from the legacy single-file format to the new feature-based format.
+All previous audit entries preserved below.
+
+---
+# AI-DLC Audit Log
+
+## Workflow Start - Initial User Request
+**Timestamp**: 2026-06-07T22:43:00Z
+**User Input**: "Ik wil een nieuw project starten in de huidige workspace. Start de aidlc workflow"
+**AI Response**: AIDLC workflow gestart. Common rules geladen, extensions opt-in bestanden geladen. Workspace detectie wordt uitgevoerd.
+**Context**: Workflow initialisatie
+
+---
+
+## Workspace Detection - Start
+**Timestamp**: 2026-06-07T22:43:00Z
+**User Input**: N/A (automatische detectie)
+**AI Response**: Workspace gescand. Geen bestaande aidlc-docs gevonden. Project is greenfield. Workspace: K:\Development\Projects\SlpModularCms. Aanwezige bestanden: SlpModularCms.sln, SlpModularCms.Api/ map.
+**Context**: Workspace Detection fase
+
+---
+
+## Requirements Analysis - Vragen aangemaakt
+**Timestamp**: 2026-06-07T22:43:00Z
+**User Input**: N/A (automatische stap)
+**AI Response**: requirement-verification-questions.md aangemaakt met 11 vragen (9 requirements vragen + 2 extension opt-in vragen). Wacht op antwoorden van gebruiker.
+**Context**: Requirements Analysis fase â€” wacht op gebruikersantwoorden
+
+---
+
+## Requirements Analysis - Antwoorden ontvangen
+**Timestamp**: 2026-06-07T22:44:00Z
+**User Input**: "Ja, klaar â€” Ik heb alle [Answer]: tags ingevuld â€” ga verder met de requirements analyse." + Vraag 1 via chat: JWT Bearer tokens (A)
+**AI Response**: Alle antwoorden verwerkt. Requirements document aangemaakt in aidlc-docs/inception/requirements/requirements.md. Security Baseline: Ja. PBT: Gedeeltelijk. Wacht op gebruikersgoedkeuring.
+**Context**: Requirements Analysis fase â€” goedkeuring afwachten
+
+---
+
+## Requirements Analysis - Wijzigingen verwerkt
+**Timestamp**: 2026-06-07T22:50:00Z
+**User Input**: "FR-02: De rollen zijn iets genuanceerder: Eigenaar (Owner), Beheerder (Administrator) en Gebruiker (User) [...] FR-03: GEEN registreren. De beheerder of hoger (Eigenaar) moet een gebruiker toevoegen."
+**AI Response**: FR-02 bijgewerkt met hiÃ«rarchische rollen (Eigenaar > Beheerder > Gebruiker) en specifieke bevoegdheden per rol. FR-03 bijgewerkt: zelfregistratie verwijderd, alleen Beheerder/Eigenaar mag gebruikers aanmaken. Scenario's en succescriteria bijgewerkt.
+**Context**: Requirements Analysis fase â€” wacht op hernieuwde goedkeuring
+
+---
+
+## Requirements Analysis - Goedgekeurd
+**Timestamp**: 2026-06-07T22:51:00Z
+**User Input**: "Voeg de User Stories fase toe voor gedetailleerde gebruikersscenario's en persona's."
+**AI Response**: Requirements goedgekeurd. User Stories fase wordt toegevoegd aan de workflow. Doorgaan naar User Stories.
+**Context**: Requirements Analysis fase â€” VOLTOOID. User Stories fase gestart.
+
+---
+
+## User Stories - Part 2 Generation - Start
+**Timestamp**: 2026-06-07T23:30:00Z
+**User Input**: "Akkoord op het plan"
+**AI Response**: Story generation plan goedgekeurd (inclusief feature-story mapping in stap 4). Start met Part 2: Generation ï¿½ persona's en user stories aanmaken.
+**Context**: User Stories fase ï¿½ Part 2 Generation gestart
+
+---
+
+
+## [2026-06-08T23:10:00Z] User Stories ï¿½ VOLTOOID
+
+**Fase**: INCEPTION - User Stories
+**Actie**: User stories en persona's gegenereerd
+
+### Artifacts aangemaakt
+- idlc-docs/inception/user-stories/personas.md ï¿½ 3 persona's (Eigenaar, Beheerder, Gebruiker)
+- idlc-docs/inception/user-stories/stories.md ï¿½ 18 INVEST-compliant user stories
+
+### Stories per feature-domein
+| Feature | Stories |
+|---|---|
+| Authenticatie | US-AUTH-01 t/m US-AUTH-04 |
+| Gebruikersbeheer | US-USER-01 t/m US-USER-05 |
+| Autorisatie | US-AUTHZ-01 t/m US-AUTHZ-03 |
+| Setup | US-SETUP-01, US-SETUP-02 |
+| Modules | US-MOD-01 t/m US-MOD-03 |
+| Beschikbaarheidscontrole | US-AVAIL-01 |
+
+### Volgende stap
+INCEPTION - Workflow Planning
+
+---
+
+## Workflow Planning - Start
+**Timestamp**: 2026-06-10T21:14:00Z
+**User Input**: "Ziet er verder goed uit. Ga verder naar de volgende stap. Alvast het volgende; wanneer er diagrammen moeten worden gemaakt. Maak er dan Mermaid diagrammen van. Let dan ook op de kleuren zodat ze goed leesbaar zijn en dat de verschillende onderdelen in het diagram goed te onderscheiden zijn."
+**AI Response**: Gebruiker keurt de correcties goed en geeft opdracht om door te gaan naar de volgende stap (Workflow Planning). Mermaid diagrammen met duidelijke kleuren worden als vereiste toegevoegd voor toekomstige diagrammen. Start met de Workflow Planning fase.
+**Context**: Workflow Planning fase gestart.
+
+---
+
+## Workflow Planning - Feedback op Diagram V1
+**Timestamp**: 2026-06-10T21:20:00Z
+**User Input**: "In het diagram zijn de titels van de fases slecht te lezen. kan je de kleuren aanpassen zodat het goed leesbaar wordt?"
+**AI Response**: Kleuren van het Mermaid diagram werden aangepast naar donkere fasetitels met witte tekst.
+**Context**: Verfijning van Workflow Planning artifact.
+
+---
+
+## Workflow Planning - Feedback op Diagram V2
+**Timestamp**: 2026-06-10T21:25:00Z
+**User Input**: "Kan je de originele lichtere kleuren terugzetten in het diagram. ALLEEN DE KLEUREN VAN DE TITELS WAREN NIET LEESBAAR DUS KAN JE DIE AANPASSEN?"
+**AI Response**: Originele lichte achtergrondkleuren hersteld voor subgraphs, maar met expliciete donkere tekstkleur voor de titels om leesbaarheid te waarborgen.
+**Context**: Tweede verfijning van Workflow Planning artifact.
+
+---
+
+## Workflow Planning - Feedback op Diagram V3
+**Timestamp**: 2026-06-10T21:30:00Z
+**User Input**: "Kan je de originele lichtere kleuren terugzetten in het diagram. ALLEEN DE KLEUREN VAN DE TITELS WAREN NIET LEESBAAR DUS KAN JE DIE AANPASSEN?"
+**AI Response**: Kleuren van de subgraphs zijn teruggezet naar de originele lichte tinten, maar de tekstkleur van de titels is expliciet ingesteld op een zeer donkere kleur voor maximale leesbaarheid. Icons in titels behouden voor herkenbaarheid.
+**Context**: Derde verfijning van Workflow Planning artifact.
+
+---
+
+## Workflow Planning - Feedback op Diagram V4
+**Timestamp**: 2026-06-10T21:35:00Z
+**User Input**: "De arrowheads op de pijltjes in het diagram zijn bijna niet te zien en zijn een andere kleur dan het lijntje zelf. Maak de arrowhead dezelfde kleur als het lijntje. Het stippellijntje (inclusief de arrowhead) van \"Volgende Unit\" in de Construction Phase zijn ook te licht en slecht te zien. Kan je daar de kleur ook van gelijktrekken met de rest van het diagram?"
+**AI Response**: Kleuren van alle lijnen en arrowheads in het Mermaid diagram expliciet ingesteld op zwart (#000000). De stippellijn voor de loop-back is verzwaard en eveneens zwart gemaakt voor betere zichtbaarheid.
+**Context**: Vierde verfijning van Workflow Planning artifact.
+
+---
+
+## Workflow Planning - Feedback op Diagram V5
+**Timestamp**: 2026-06-10T21:40:00Z
+**User Input**: "De lijntjes moesten dezelfde kleur blijven en de pijlpunten moesten een andere kleur krijgen! Fix het diagram en zorg dat de pijlpunten dezelfde kleur krijgen als de lijntjes zelf. Zorg ook dat ze goed zichtbaar zijn. De stippellijn van \"Volgende Unit\" is ook te licht."
+**AI Response**: Kleuren van alle lijnen en pijlpunten (markers) in het Mermaid diagram zijn geharmoniseerd naar diepzwart (#000000). De lijndikte is verhoogd naar 3px voor maximale zichtbaarheid en de stippellijn is verzwaard.
+**Context**: Vijfde verfijning van Workflow Planning artifact.
+
+---
+
+## Workflow Planning - Feedback op Diagram V6
+**Timestamp**: 2026-06-10T21:45:00Z
+**User Input**: "De dikte van de lijntjes was goed en mag terug naar een dikte van 2,5. De kleur lijkt ook donkerder, maar het donkergrijze was prima. Zet die kleur ook terug en zorg dat alle lijntjes dezelfde donkergrijze kleur krijgen. Verander de pijlpunten ook naar diezelfde grijze kleur."
+**AI Response**: Lijnen en pijlpunten aangepast naar donkergrijs (#333333) met een dikte van 2.5px. Consistentie in kleur voor het gehele diagram hersteld.
+**Context**: Zesde verfijning van Workflow Planning artifact.
+
+---
+
+## Workflow Planning - Finale Check
+**Timestamp**: 2026-06-10T21:46:00Z
+**User Input**: "-"
+**AI Response**: Gebruiker geeft geen verdere feedback na de herstelwerkzaamheden aan het diagram. Vraagt om finale bevestiging om door te gaan naar Application Design.
+**Context**: Afronding Workflow Planning fase.
+
+---
+
+## Workflow Planning - Goedgekeurd
+**Timestamp**: 2026-06-10T21:50:00Z
+**User Input**: "Goedkeuren & Doorgaan"
+**AI Response**: Uitvoeringsplan is goedgekeurd door de gebruiker. De Workflow Planning fase is hiermee voltooid. Start met de Application Design fase.
+**Context**: Workflow Planning fase VOLTOOID. Application Design fase gestart.
+
+---
+
+## Application Design - Artifacts Gegenereerd
+**Timestamp**: 2026-06-10T22:05:00Z
+**AI Response**: Alle Application Design artifacts zijn gegenereerd (components, methods, services, dependencies). Wacht op gebruikersgoedkeuring om door te gaan naar Units Generation.
+**Context**: Application Design fase â€” goedkeuring afwachten.
+
+---
+
+## Application Design - Feedback Verwerkt (Module Rechten)
+**Timestamp**: 2026-06-10T22:15:00Z
+**User Input**: "in services.md bij 4. RBAC Policy Orchestratie. Is er rekening gehouden met de mogelijkheid voor beheerders om rechten per module in te kunnen stellen voor gebruikers?"
+**AI Response**: Ontwerp bijgewerkt om module-specifieke rechten te ondersteunen. `services.md` uitgebreid met module-autorisatie logica, `component-methods.md` aangevuld met beheermethoden voor deze rechten.
+**Context**: Application Design verfijning op basis van feedback.
+
+---
+
+## Units Generation - Plan Gemaakt
+**Timestamp**: 2026-06-10T22:20:00Z
+**AI Response**: Plan voor Units Generation aangemaakt inclusief decompositie-vragen. Wacht op antwoorden van de gebruiker.
+**Context**: Units Generation fase â€” planning.
+
+---
+
+## Units Generation - Artifacts Gegenereerd
+**Timestamp**: 2026-06-10T22:30:00Z
+**AI Response**: Alle Units Generation artifacts zijn gegenereerd (unit-of-work.md, dependency, story-map). De applicatie is opgesplitst in 4 logische eenheden.
+**Context**: Units Generation fase VOLTOOID. Start CONSTRUCTION PHASE.
+
+---
+
+## Functional Design (U01: Core Base) - Plan Gemaakt
+**Timestamp**: 2026-06-10T22:40:00Z
+**AI Response**: Functional Design plan voor Unit 01 aangemaakt inclusief vragen over module metadata, error handling en availability fallback. Wacht op antwoorden van de gebruiker.
+**Context**: CONSTRUCTION PHASE â€” Unit 01 Functional Design.
+
+---
+
+## Functional Design (U01: Core Base) - Artifacts Gegenereerd
+**Timestamp**: 2026-06-10T22:55:00Z
+**AI Response**: Functional Design artifacts voor Unit 01 zijn gegenereerd (business rules, logic model, entities). Module metadata is uitgebreid, exception handling is gedetailleerd en availability fallback is optimistisch ingesteld.
+**Context**: Unit 01 Functional Design VOLTOOID. Start NFR Requirements.
+
+---
+
+## Functional Design (U01: Core Base) - Correctie op Availability
+**Timestamp**: 2026-06-10T23:05:00Z
+**User Input**: "Lees het antwoord op mijn vraag 3 van core-base-functional-design-plan.md... de availability wordt voor de hele API gecontroleerd, niet per module"
+**AI Response**: Ontwerp gecorrigeerd. De beschikbaarheidscontrole is nu gedefinieerd als een globale API-check in plaats van een per-module check. De orkestratie-logica en business rules in Unit 01 zijn hierop aangepast.
+**Context**: Unit 01 Functional Design verfijning op basis van expliciet gebruikersantwoord.
+
+---
+
+## NFR Requirements (U01: Core Base) - Plan Gemaakt
+**Timestamp**: 2026-06-11T23:45:00Z
+**User Input**: "Ga verder met de aidlc workflow"
+**AI Response**: NFR Requirements plan voor Unit 01: Core Base aangemaakt met vragen over performance, security, availability en tech stack keuzes. Wacht op antwoorden van de gebruiker.
+**Context**: CONSTRUCTION PHASE â€” Unit 01 NFR Requirements.
+
+---
+
+## NFR Requirements (U01: Core Base) - Antwoorden Ontvangen
+**Timestamp**: 2026-06-11T23:41:00Z
+**User Input**: "Ik heb de vragen beantwoord"
+**AI Response**: Antwoorden geanalyseerd. Keuzes voor schaalbaarheid (D), performance (C), security (B) en availability (B) vastgelegd. Tech stack bevestigd: standaard .NET DI/Logging en xUnit+AutoFixture voor testing. NFR artifacts gegenereerd.
+**Context**: Unit 01 NFR Requirements VOLTOOID. Start NFR Design.
+
+---
+
+---
+
+## NFR Design (U01: Core Base) - VOLTOOID
+**Timestamp**: 2026-06-11T23:48:00Z
+**User Input**: Beantwoording van NFR Design vragen.
+**AI Response**: Technische ontwerpen gegenereerd voor exception handling (IExceptionHandler), module discovery (assembly scanning) en availability (config-based timeout). NFR Design fase voltooid.
+**Context**: Unit 01 NFR Design VOLTOOID. Start Code Generation.
+
+---
+
+## Integration & Verification (Final Construction) - VOLTOOID
+**Timestamp**: 2026-06-12T01:35:00Z
+**AI Response**: Totale integratie van alle 4 units (Core, Identity, Availability, Shell) voltooid. API Shell geconfigureerd met dynamische discovery, JWT auth, en Scalar OpenAPI. Alle individual construction plans zijn bijgewerkt. 21 unit tests succesvol uitgevoerd. Build Succeeded. Eindrapportage opgesteld in final-report.md.
+**Context**: CONSTRUCTION PHASE VOLTOOID. Project klaar voor oplevering.
+
+---
+
+## Bug Fix: Dubbele Prefix & Module Discovery Issue
+**Timestamp**: 2026-06-12T17:15:00Z
+**User Input**: Melding van dubbele /api/v1/api prefix en Unable to resolve service IAvailabilityService.
+**AI Response**: 
+1. `AvailabilityController.cs` route aangepast van `api/[controller]` naar `[controller]` om dubbele prefixing door `ApiPrefixConvention` te voorkomen.
+2. `ModuleOrchestrator.cs` verbeterd om modules actief van disk te laden (`Assembly.Load`) zodat ze ook ontdekt worden als er geen statische referentie is in de host.
+3. Build en tests succesvol geverifieerd (21 tests pass).
+**Context**: Onderhoud na voltooiing Construction Phase.
+
+---
+
+## Appsettings Refactoring & Availability Configuration
+**Timestamp**: 2026-06-12T20:55:00Z
+**User Input**: Fix mijn dotnet appsettings.
+**AI Response**: 
+1. Implementatie van het drie-bestanden patroon (`appsettings.json`, `appsettings.Development.json`, `appsettings.local.json`) conform `dotnet-appsettings-c` skill.
+2. `.gitignore` toegevoegd om `appsettings.local.json` en andere tijdelijke bestanden uit git te houden.
+3. `Program.cs` bijgewerkt om `appsettings.local.json` te laden voor lokale overrides.
+4. `AvailabilityOptions` toegevoegd en `PersistentAvailabilityService` bijgewerkt om timeouts via configuratie te ondersteunen.
+**Context**: Configuratie-optimalisatie en security hardening.
+
+
+
+---
+
+## Project Structure Migration (SlpModularCms.Api to src/)
+**Timestamp**: 2026-06-12T21:15:00Z
+**User Input**: SlpModularCms.Api staat nu nog niet in de `src` map. Verplaats hem naar de `src` net als de andere projecten.
+**AI Response**: 
+1. `SlpModularCms.Api` projectmap verplaatst van root naar `src\SlpModularCms.Api`.
+2. `SlpModularCms.sln` bijgewerkt met het nieuwe pad en correcte nesting onder de `src` solution folder.
+3. Projectreferenties in `SlpModularCms.Api.csproj` gecorrigeerd (verwijderen van overbodige `..\src\`).
+4. Build en tests succesvol geverifieerd (21 tests pass).
+**Context**: Reorganisatie van de projectstructuur voor consistentie.
+
+---
+
+## First Database Migration (InitialCreate)
+**Timestamp**: 2026-06-12T21:20:00Z
+**User Input**: Voer voor mij de eerste dotnet migration uit.
+**AI Response**: 
+1. `appsettings.local.json` gecorrigeerd: `Trusted_Connection=True` verwijderd en `TrustServerCertificate=True` toegevoegd. Host aangepast naar `127.0.0.1,1433`.
+2. `InitialCreate` migratie gegenereerd via `dotnet ef migrations add`.
+3. Database succesvol geüpdatet via `dotnet ef database update`.
+**Context**: Database schema initialisatie voor Identity en Availability.
+
+---
+
+## Identity & RBAC Implementation
+**Timestamp**: 2026-06-12T21:50:00Z
+**User Input**: Toevoegen van gebruikersbeheer endpoints, inclusief setup voor eerste eigenaar en uitnodigingsflow.
+**AI Response**: 
+1. `SlpModularCms.Modules.Identity` project aangemaakt en geïntegreerd.
+2. `ISetupService` geïmplementeerd voor bootstrapping van de eerste Owner.
+3. `SetupController`, `AuthController` en `UsersController` toegevoegd voor API toegang.
+4. JWT Authenticatie en Hierarchical RBAC Policies geconfigureerd in `ServiceCollectionExtensions.cs`.
+5. `TokenResponse` en `IdentityRequests` records toegevoegd voor consistente API communicatie.
+6. Build en bestaande tests (21 pass) succesvol geverifieerd.
+**Context**: Uitbreiding van functionele basis met Identity & Toegangsbeheer.
+
+---
+
+## README & Final Cleanup
+**Timestamp**: 2026-06-12T22:00:00Z
+**User Input**: Voeg aan de README.md toe de stappen voor het opzetten van het project op development en de stappen voor productie. Voeg ook de stappen en commando's toe voor het doen van de migraties.
+**AI Response**: 
+1. `README.md` aangemaakt met gedetailleerde secties voor Development (Podman/SQL, Config, Run), Migraties (EF Core commando's) en Productie (Publish, Env Vars).
+2. Verweesd `SlpModularCms.Api` map in de root verwijderd om projectstructuur op te schonen.
+3. Bevestigd dat alle code nu consistent in de `src/` map staat.
+**Context**: Afronding van de initiële bouw- en documentatiefase.
+
+---
+
+## README Correction: Scalar URL
+**Timestamp**: 2026-06-12T22:05:00Z
+**User Input**: "In de README staat dat de scalar UI beschikbaar is op /swagger. Dat moet zijn /scalar."
+**AI Response**: 
+1. `README.md` bijgewerkt: `/swagger` URL gecorrigeerd naar `/scalar` conform de `launchSettings.json` en de standaard Scalar configuratie in `Program.cs`.
+**Context**: Correctie van documentatie-fout.
+
+---
+
+## README: Setup Endpoints Documentation
+**Timestamp**: 2026-06-12T22:10:00Z
+**User Input**: "Zet in de README ook nog hoe de setup endpoints werken voor de initiele setup"
+**AI Response**: 
+1. `README.md` uitgebreid met een sectie "Initiële Setup (Bootstrapping)".
+2. Endpoints `GET /api/v1/Setup/status` en `POST /api/v1/Setup/owner` gedocumenteerd, inclusief payload voorbeeld.
+**Context**: Verbetering van de onboarding-documentatie voor nieuwe installaties.
+
+---
+
+## README: Module Extension Documentation
+**Timestamp**: 2026-06-14T00:30:00Z
+**User Input**: "Voeg ook instructies toe voor het toevoegen van een nieuwe (optionele) module"
+**AI Response**: 
+1. `README.md` uitgebreid met een sectie "Nieuwe Module Toevoegen".
+2. Gedetailleerde stappen beschreven voor projectcreatie, naamconventies, `IModule` implementatie en API-registratie.
+**Context**: Ondersteuning voor de uitbreidbaarheid van het modulaire systeem.
@@ -0,0 +1,30 @@
+# Business Rules — Unit 04: API Shell & Integration
+
+Dit document beschrijft de integratie-regels en de orkestratie van de modules.
+
+## 1. Module Discovery (BR-SHELL-01)
+
+- **Scanning**: De API Shell scant bij het opstarten naar alle geladen assemblies die voldoen aan het patroon `SlpModularCms.Modules.*`.
+- **Interface**: Alleen klassen die `IModule` implementeren worden geregistreerd.
+- **Validatie**: Indien een module niet voldoet aan de eisen (bijv. ontbrekende naam of versie), wordt dit gelogd als een fout en wordt de module niet geladen.
+
+## 2. Dependency Injection & Pipeline (BR-SHELL-02)
+
+- **Gecentraliseerde Registratie**: De `ModuleOrchestrator` roept `RegisterServices` aan op alle gevonden modules voordat de applicatie start.
+- **Middleware Pipeline**: De `ModuleOrchestrator` roept `UseModule` aan om modules de kans te geven hun middleware te registreren in de HTTP pipeline.
+- **Core First**: Core services (Identity, Logging) worden altijd geregistreerd vóórdat de modules aan de beurt zijn.
+
+## 3. API Versioning & Routing (BR-SHELL-03)
+
+- **Gecentraliseerde Prefix**: Alle API endpoints krijgen de prefix `/api/v1/`.
+- **Afdwingen**: Dit wordt globaal geconfigureerd in de Shell zodat individuele modules hier geen rekening mee hoeven te houden in hun route attributen.
+
+## 4. Swagger Documentatie (BR-SHELL-04)
+
+- **Tagging**: De Shell groepeert endpoints automatisch per module op basis van de module naam die in de `IModule` interface is opgegeven.
+- **Security**: Swagger wordt geconfigureerd om JWT Bearer tokens te ondersteunen voor het testen van beveiligde endpoints.
+
+## 5. Cross-Module Communicatie (BR-SHELL-05)
+
+- **Ontkoppeling**: Modules communiceren niet direct met elkaar via projectreferenties.
+- **Interfaces**: Communicatie verloopt uitsluitend via interfaces die gedefinieerd zijn in `SlpModularCms.Core`.
@@ -0,0 +1,47 @@
+# Business Logic Model — Unit 04: API Shell & Integration
+
+Dit document beschrijft de startup flow en de orkestratie logica van de shell.
+
+## 1. Startup Orkestratie Flow
+
+```mermaid
+sequenceDiagram
+    participant Program as Program.cs
+    participant Orc as ModuleOrchestrator
+    participant Core as Core Services
+    participant Mod as Modules (IModule)
+
+    Program->>Orc: DiscoverModules()
+    Orc-->>Program: List<IModule>
+    
+    Program->>Core: RegisterCoreServices(Identity, DB, JWT)
+    
+    loop Per Module
+        Program->>Mod: RegisterServices(IServiceCollection)
+    end
+    
+    Program->>Program: Build App
+    
+    Program->>Program: UseExceptionHandler()
+    
+    loop Per Module
+        Program->>Mod: UseModule(IApplicationBuilder)
+    end
+    
+    Program->>Program: UseAuthentication/Authorization()
+    Program->>Program: MapControllers()
+    Program->>Program: Run()
+```
+
+## 2. API Versioning Logic
+
+De versioning wordt toegepast via een globale `RoutePrefix` of door gebruik te maken van de `Microsoft.AspNetCore.Mvc.Versioning` library.
+- **Base Path**: `/api/v1`
+- **Fallback**: Verzoeken zonder versie-indicator in het pad worden standaard naar v1 gerouteerd.
+
+## 3. Dynamische Swagger Groepering
+
+1. Swagger scan de controllers van alle geladen assemblies.
+2. Voor elke controller wordt gekeken naar de assembly waarin deze is gedefinieerd.
+3. Indien de assembly toebehoort aan een module (bijv. `SlpModularCms.Modules.Availability`), wordt de module naam als 'Tag' toegevoegd aan alle endpoints van die controller.
+4. Swagger UI toont de endpoints gegroepeerd onder deze tags.
@@ -0,0 +1,63 @@
+# Orchestration Design — Unit 04: API Shell & Integration
+
+Dit document beschrijft de technische implementatie van de module orkestratie.
+
+## 1. ModuleOrchestrator
+
+De orchestrator is verantwoordelijk voor de lifecycle van modules.
+
+- **Discovery**: 
+    - Gebruikt Reflection om alle typen in geladen assemblies te scannen.
+    - Filtert op klassen die `IModule` implementeren en niet abstract zijn.
+- **Error Handling (Soft Fail)**:
+    - Bij het laden van een module wordt de aanroep van `RegisterServices` en `UseModule` omgeven door een `try-catch` blok.
+    - Fouten worden gelogd als `Error` naar de `ILogger`.
+    - De orkestratie gaat door naar de volgende module om de algehele beschikbaarheid te maximaliseren.
+
+## 2. Route Conventions
+
+De `/api/v1/` prefix wordt afgedwongen via een custom `IApplicationModelConvention`:
+
+```csharp
+public class ApiPrefixConvention : IApplicationModelConvention
+{
+    public void Apply(ApplicationModel application)
+    {
+        foreach (var controller in application.Controllers)
+        {
+            foreach (var selector in controller.Selectors)
+            {
+                // Voeg prefix toe aan bestaande route
+                var routePrefix = new AttributeRouteModel(new RouteAttribute("api/v1"));
+                selector.AttributeRouteModel = selector.AttributeRouteModel != null 
+                    ? AttributeRouteModel.CombineAttributeRouteModels(routePrefix, selector.AttributeRouteModel) 
+                    : routePrefix;
+            }
+        }
+    }
+}
+```
+
+## 3. Swagger & Security Design
+
+Swagger wordt geconfigureerd in `Program.cs`:
+
+- **Groepering**: Gebruik van `DocInclusionPredicate` om controllers te taggen op basis van hun assembly prefix (bijv. `Availability`).
+- **JWT Support**:
+    - `AddSecurityDefinition("Bearer", ...)`
+    - `AddSecurityRequirement(...)`
+- **Pad**: Beschikbaar op `/swagger` via `app.UseSwaggerUI(c => c.RoutePrefix = "swagger")`.
+
+## 4. CORS Global Configuration
+
+De Shell leest de `CorsSettings` uit `appsettings.json` en configureert een globale policy:
+
+```json
+{
+  "CorsSettings": {
+    "AllowedOrigins": ["https://portal.slp-modular.local"],
+    "AllowAnyHeader": true,
+    "AllowAnyMethod": true
+  }
+}
+```
@@ -0,0 +1,31 @@
+# NFR Requirements — Unit 04: API Shell & Integration
+
+Dit document specificeert de non-functionele vereisten voor de API Shell.
+
+## 1. Performance (SHELL-PERF)
+
+- **SHELL-PERF-01: Startup Tijd**:
+    - Hoewel de startup tijd niet kritisch is (> 5 sec toegestaan), moet de `ModuleOrchestrator` efficiënt scannen om onnodige vertragingen te voorkomen.
+- **SHELL-PERF-02: Pipeline Efficiency**:
+    - De orkestratie van middleware mag geen significante overhead toevoegen aan de verwerking van individuele requests.
+
+## 2. Beveiliging (SHELL-SEC)
+
+- **SHELL-SEC-01: CORS**:
+    - CORS moet worden geconfigureerd via `appsettings.json`. De default instelling voor productie moet strikt zijn (geen wildcards).
+- **SHELL-SEC-02: HTTPS**:
+    - De API Shell moet HTTPS afdwingen via `app.UseHttpsRedirection()`.
+- **SHELL-SEC-03: JWT Configuratie**:
+    - De Shell is verantwoordelijk voor het correct configureren van de `JwtBearerAuthentication` met de keys en settings die in Unit 02 zijn gedefinieerd.
+
+## 3. Bruikbaarheid (SHELL-USAB)
+
+- **SHELL-USAB-01: Swagger**:
+    - Swagger UI moet volledig interactief zijn, inclusief ondersteuning voor JWT Bearer authenticatie (Authorize knop).
+    - Alle endpoints moeten duidelijk gedocumenteerd zijn met hun verwachte input en output modellen.
+
+## 4. Onderhoudbaarheid (SHELL-MAINT)
+
+- **SHELL-MAINT-01: Logging Aggregatie**:
+    - Alle logs van modules moeten worden geaggregeerd naar de centrale logging provider van de Shell.
+    - Contextuele informatie (zoals de module naam) moet aan de logs worden toegevoegd voor betere traceerbaarheid.
@@ -0,0 +1,23 @@
+# Tech Stack Decisions — Unit 04: API Shell & Integration
+
+Dit document beschrijft de definitieve technische keuzes voor Unit 04.
+
+## 1. API Framework & Routing
+
+- **Host**: ASP.NET Core 10.
+- **Versioning**: `Asp.Versioning.Mvc` (v1 in path).
+- **CORS**: `Microsoft.AspNetCore.Cors`.
+
+## 2. API Documentatie
+
+- **Swagger Provider**: `Swashbuckle.AspNetCore`.
+- **UI**: `SwaggerUI`.
+- **Beveiliging**: Geconfigureerd met `OpenApiSecurityScheme` (Type: `ApiKey`, In: `Header`, Name: `Authorization`, Scheme: `Bearer`).
+
+## 3. Module Discovery
+
+- **Scanning Mechanism**: Reflection via `AppDomain.CurrentDomain.GetAssemblies()` gecombineerd met `Assembly.Load` voor DLL's die nog niet geladen zijn maar wel de prefix hebben.
+
+## 4. Configuratie Beheer
+
+- **Options Pattern**: Gebruik van `IOptions` voor alle shell-specifieke instellingen (CORS, Versioning, Swagger).
@@ -0,0 +1,30 @@
+# Business Rules — Unit 03: Availability Module
+
+Dit document beschrijft de functionele logica voor de beschikbaarheidscontrole en de remote shutdown functionaliteit.
+
+## 1. Beschikbaarheidsstatus (BR-AVAIL-01)
+
+- **Status Typen**:
+    - `Available`: Het systeem is volledig operationeel.
+    - `Maintenance`: Het systeem is in onderhoud; alleen beheerders hebben toegang.
+    - `Degraded`: Sommige functies zijn beperkt, maar het systeem is in principe bereikbaar.
+    - `NotAvailable`: Het systeem is volledig afgesloten (Remote Shutdown).
+- **Default (MVP)**: In de MVP versie retourneert de `StubAvailabilityService` altijd `Available`, tenzij handmatig anders geconfigureerd in `appsettings.json`.
+
+## 2. Remote Shutdown Handhaving (BR-AVAIL-02)
+
+- **Mechanisme**: Een globale middleware controleert bij elk inkomend request de status via de `IAvailabilityService`.
+- **Gedrag**:
+    - Als status == `NotAvailable` -> Retourneer `503 Service Unavailable`.
+    - Als status == `Maintenance` -> Blokkeer requests voor reguliere gebruikers; sta alleen toe voor gebruikers met de rol `Owner` of `Administrator`.
+- **Response**: De response moet het gestandaardiseerde `ApiErrorResponse` formaat gebruiken (U01).
+
+## 3. Publieke Status (BR-AVAIL-03)
+
+- **Endpoint**: `GET /api/availability/status` moet voor iedereen bereikbaar zijn (geen authenticatie vereist).
+- **Informatie**: Het endpoint retourneert de huidige status en een timestamp van de laatste controle.
+
+## 4. Beheerder Bypass (BR-AVAIL-04)
+
+- **Rechten**: Gebruikers met de rol `Owner` of `Administrator` kunnen de blokkades van de Availability Middleware omzeilen om onderhoudstaken uit te voeren.
+- **Identificatie**: De bypass is gebaseerd op de JWT claims (`role`).
@@ -0,0 +1,27 @@
+# Domain Entities — Unit 03: Availability Module
+
+Dit document beschrijft de data structuren voor de beschikbaarheidsmodule.
+
+## 1. AvailabilityResponse (DTO)
+
+Model voor de publieke status check.
+
+- **Status**: De huidige `AvailabilityStatus` (Enum uit U01).
+- **CheckedAt**: Tijdstip van de status check.
+- **Message**: Optionele tekstuele toelichting (bijv. "Onderhoud gepland tot 14:00").
+
+## 2. AvailabilitySettings (Configuration)
+
+Model voor de configuratie in `appsettings.json`.
+
+- **DefaultStatus**: De status die geretourneerd wordt door de stub.
+- **MaintenanceMessage**: Bericht dat getoond wordt tijdens onderhoud.
+- **AllowedRolesForMaintenance**: Lijst van rollen die toegang hebben tijdens onderhoud (default: `Owner`, `Administrator`).
+
+## 3. AvailabilityState (In-Memory)
+
+Indien we in de MVP de status dynamisch willen kunnen aanpassen zonder restart:
+
+- **CurrentStatus**: `AvailabilityStatus`.
+- **StatusChangedAt**: DateTimeOffset.
+- **Reason**: String.
@@ -0,0 +1,40 @@
+# Business Logic Model — Unit 03: Availability Module
+
+Dit document beschrijft de processen voor beschikbaarheidscontrole.
+
+## 1. Availability Middleware Flow
+
+```mermaid
+graph TD
+    A[Inkomend Request] --> B{Is Endpoint /status?}
+    B -- Ja --> C[Laat door naar Controller]
+    B -- Nee --> D{Check Status via IAvailabilityService}
+    D --> E{Status == Available?}
+    E -- Ja --> C
+    E -- Nee --> F{Status == Maintenance?}
+    F -- Ja --> G{Heeft Rol Admin/Owner?}
+    G -- Ja --> C
+    G -- Nee --> H[Retourneer 503 + ApiErrorResponse]
+    F -- Nee --> H
+```
+
+## 2. Status Check Flow
+
+1. **Client** roept `GET /api/availability/status` aan.
+2. **AvailabilityController** roept `IAvailabilityService.IsAvailableAsync()` aan.
+3. **Service** haalt status op (in MVP uit config of in-memory state).
+4. **Controller** bouwt response:
+    ```json
+    {
+      "status": "Available",
+      "checkedAt": "2026-06-12T01:15:00Z",
+      "message": "System is running normally."
+    }
+    ```
+
+## 3. Remote Shutdown Logic (Toekomst)
+
+Hoewel de MVP een stub gebruikt, is het logic model voorbereid op een externe trigger:
+- Een administratieve actie zet een vlag in de database/cache.
+- De `IAvailabilityService` detecteert deze wijziging.
+- De Middleware reageert direct op alle volgende requests.
@@ -0,0 +1,36 @@
+# Controller Design — Unit 03: Availability Module
+
+Dit document beschrijft de endpoints van de `AvailabilityController`.
+
+## 1. Publieke Status Endpoint
+
+- **Method**: `GET`
+- **Path**: `/api/availability/status`
+- **Auth**: Geen (AllowAnonymous)
+- **Response**: `AvailabilityResponse`
+- **Logic**: Roept `IAvailabilityService.IsAvailableAsync()` aan en mapt de status naar het response object.
+
+## 2. Status Update Endpoint (Beheer)
+
+- **Method**: `POST`
+- **Path**: `/api/availability/admin/status`
+- **Auth**: `OwnerOnly` Policy (Unit 02)
+- **Request Body**:
+    ```json
+    {
+      "newStatus": "Maintenance",
+      "reason": "Gepland database onderhoud"
+    }
+    ```
+- **Logic**:
+    1. Valideert de nieuwe status.
+    2. Werkt de database record bij via de `IAvailabilityService`.
+    3. Maakt een audit log aan (Unit 02).
+- **Response**: `200 OK`.
+
+## 3. Integratie met Audit Log
+
+Bij elke statuswijziging wordt de `IAuditService` aangeroepen met de volgende gegevens:
+- **ActorId**: De ID van de Owner.
+- **Action**: `SystemStatusChanged`.
+- **Details**: `OldStatus: Available, NewStatus: Maintenance, Reason: ...`
@@ -0,0 +1,35 @@
+# Middleware Design — Unit 03: Availability Module
+
+Dit document beschrijft de technische implementatie van de Availability Middleware.
+
+## 1. Middleware Registratie
+
+De middleware wordt in de `Program.cs` van de API Shell (U04) geregistreerd:
+
+```csharp
+app.UseExceptionHandler(); // Eerst de exception handler (U01)
+app.UseAvailability();     // Daarna de availability check
+// ... andere middleware (Auth, Routing, etc)
+```
+
+## 2. AvailabilityMiddleware Logica
+
+- **Bypass voor Status Endpoint**: Het pad `/api/availability/status` wordt altijd doorgelaten zonder check.
+- **Check Fase**:
+    - De middleware roept `IAvailabilityService.IsAvailableAsync()` aan.
+    - Indien status == `Available` -> `_next(context)`.
+- **Bypass voor Admins/Owners**:
+    - Indien status == `Maintenance` of `NotAvailable`:
+    - De middleware inspecteert het JWT token in de `Authorization` header handmatig (omdat de globale Authentication middleware nog niet is uitgevoerd op dit punt).
+    - Indien de claim `role` gelijk is aan `Owner` of `Administrator` -> `_next(context)`.
+    - Anders -> Retourneer `503 Service Unavailable` met `ApiErrorResponse`.
+
+## 3. PersistentAvailabilityService
+
+Implementatie van de interface uit Unit 01.
+
+- **Database Opslag**: Maakt gebruik van de `ApplicationDbContext` (Unit 02).
+- **Circuit Breaker**:
+    - Houdt in een statische variabele de `_lastErrorTime` en `_cachedStatus` bij.
+    - Indien `DateTimeOffset.UtcNow - _lastErrorTime < 30 seconden` -> Retourneer de `_cachedStatus` (default: `Available`) zonder de database te pollen.
+- **Logging**: Elke blokkade wordt gelogd met het IP-adres van de client en het gevraagde pad.
@@ -0,0 +1,30 @@
+# NFR Requirements — Unit 03: Availability Module
+
+Dit document specificeert de non-functionele vereisten voor de beschikbaarheidsmodule.
+
+## 1. Performance (AVAIL-PERF)
+
+- **AVAIL-PERF-01: Middleware Latency**:
+    - De Availability Middleware mag maximaal 5ms toevoegen aan de totale requestduur.
+    - Dit vereist een geoptimaliseerde database check (indexering op de status tabel).
+- **AVAIL-PERF-02: Real-time Check**:
+    - Er wordt GEEN caching toegepast in de middleware (conform gebruikerskeuze). Elke request voert een actuele check uit om maximale consistentie te waarborgen.
+
+## 2. Betrouwbaarheid & Persistentie (AVAIL-REL)
+
+- **AVAIL-REL-01: Persistent Status**:
+    - De beschikbaarheidsstatus moet in de database worden opgeslagen, zodat deze behouden blijft na een herstart van de applicatie.
+- **AVAIL-REL-02: Fallback**:
+    - Indien de database onbereikbaar is, moet de `IAvailabilityService` terugvallen op een "Veilige" status (bijv. `Available` of de laatst bekende status in het geheugen) om een lock-out te voorkomen.
+
+## 3. Beveiliging (AVAIL-SEC)
+
+- **AVAIL-SEC-01: Access Control**:
+    - Alleen gebruikers met de rol `Owner` kunnen de globale beschikbaarheidsstatus van de API wijzigen via een beveiligd endpoint.
+- **AVAIL-SEC-02: Maintenance Bypass**:
+    - De bypass voor beheerders (zoals gedefinieerd in Functional Design) moet strikt gecontroleerd worden op basis van JWT claims.
+
+## 4. Onderhoudbaarheid (AVAIL-MAINT)
+
+- **AVAIL-MAINT-01: Audit Trail**:
+    - Elke wijziging van de beschikbaarheidsstatus moet worden gelogd in de `AuditLogs` tabel (Unit 02), inclusief de reden en de uitvoerder.
@@ -0,0 +1,26 @@
+# Tech Stack Decisions — Unit 03: Availability Module
+
+Dit document beschrijft de definitieve technische keuzes voor Unit 03.
+
+## 1. Opslag (Persistence)
+
+- **Provider**: Microsoft SQL Server (conform NFR-01).
+- **Entiteit**: `GlobalAvailabilityState` (Single record).
+
+## 2. Middleware Implementatie
+
+- **Type**: Custom Middleware in de `SlpModularCms.Api` (Shell).
+- **Dependency**: Maakt gebruik van de `IAvailabilityService` uit Unit 01.
+
+## 3. Interfaces & DI
+
+- **Service**: `PersistentAvailabilityService` (Implementeert `IAvailabilityService`).
+- **Lifetime**: `Scoped` (voor database toegang per request).
+
+## 4. Configuratie
+
+- **Options Pattern**: Gebruik van `IOptions<AvailabilitySettings>` voor de fallback status en andere drempelwaarden.
+
+## 5. Monitoring
+
+- **Logging**: Gebruik van `ILogger` voor het loggen van statuswijzigingen en middleware blokkades (Warning niveau).
@@ -0,0 +1,31 @@
+# Business Logic Model — Unit 01: Core Base
+
+Dit document beschrijft de functionele workflows en dataflows binnen het Core Framework.
+
+## 1. Module Levenscyclus Model
+
+Het framework beheert modules via de volgende logische stappen:
+
+1.  **Discovery**: De API Shell identificeert potentiële modules (via referentie of DLL scan).
+2.  **Registration**: De Core valideert de `ModuleInfo`.
+    - Controleert BR-CORE-01 (Uniciteit & Metadata).
+3.  **Service Registration**: De Core roept `RegisterServices` aan.
+    - Modules voegen hun services toe aan de globale DI-container.
+4.  **Middleware Configuration**: De Core roept `ConfigureMiddleware` aan tijdens de startup van de webhost.
+
+## 2. Globale Availability Orchestratie Model
+
+Het proces van statuscontrole verloopt als volgt:
+
+- **Centrale Controle**: De Core Base definieert de `IAvailabilityService` interface. De API Shell gebruikt één centrale implementatie om de status van de gehele API te bepalen.
+- **Binaire Status**: Het resultaat is een binaire status (beschikbaar/niet beschikbaar) voor de volledige API suite, niet opgedeeld per individuele module.
+- **Reporting**: De resultaten worden gerapporteerd in een enkel `AvailabilityDetails` object.
+
+## 3. Exception-to-Response Flow
+
+Flow van een foutieve actie naar een response:
+
+1.  **Event**: Een actie in een module of de Core gooit een domein-exception.
+2.  **Capture**: Globale middleware (in de Shell, maar gedefinieerd in Core) vangt de exception op.
+3.  **Transformation**: De exception wordt gemapt naar een `ApiErrorResponse` volgens BR-CORE-03.
+4.  **Response**: De client ontvangt een gestandaardiseerde JSON body met de relevante HTTP status code (bijv. 404 voor `ModuleNotFoundException`).
@@ -0,0 +1,25 @@
+# Business Rules — Unit 01: Core Base
+
+Dit document beschrijft de validatieregels en logica voor het Core Framework.
+
+## 1. Module Registratie Regels (BR-CORE-01)
+
+- **Uniciteit**: Elke module moet een unieke `Name` hebben. Registratie van een tweede module met dezelfde naam moet resulteren in een `DuplicateModuleException`.
+- **Verplichte Metadata**: Registratie faalt als `Name`, `Version` of `Description` leeg zijn.
+- **Dependency Resolutie**:
+  - Als een module afhankelijkheden opgeeft, moet het framework controleren of deze modules ook geladen zijn.
+  - Bij ontbrekende afhankelijkheden moet een waarschuwing worden gelogd, maar mag de applicatie in de MVP fase wel doorstarten (soft dependency).
+
+## 2. Globale Availability Regels (BR-CORE-02)
+
+- **API-breed**: De beschikbaarheidscontrole is een binaire status voor de gehele API Shell.
+- **Implementatie Verplichting**: Er moet één actieve implementatie van `IAvailabilityService` geregistreerd zijn in de API Shell.
+- **Gedrag**: Indien de service niet bereikbaar is (bijv. door Master-API uitval in de toekomst), wordt de gehele API als "niet beschikbaar" beschouwd voor niet-beheerders.
+
+## 3. Error Handling Conversie (BR-CORE-03)
+
+- **Gedetailleerde Mapping**: Elke domein-specifieke exception moet worden vertaald naar een `ApiErrorResponse` met specifieke details.
+  - `ModuleNotFoundException` -> Details bevatten de gezochte `ModuleName`.
+  - `UnauthorizedAccessException` -> Details bevatten de vereiste rol en de huidige rol van de gebruiker.
+  - `ValidationException` -> Details bevatten een lijst van velden die niet voldeden aan de regels.
+- **Privacy**: In productie-omgevingen moeten stacktraces worden verwijderd uit de `Details` dictionary.
@@ -0,0 +1,49 @@
+# Domain Entities — Unit 01: Core Base
+
+Dit document beschrijft de domein-modellen en interfaces voor het Core Framework.
+
+## 1. Module Interfaces & Entiteiten
+
+### IModule
+Het basiscontract voor elke module in het systeem.
+```csharp
+public interface IModule
+{
+    ModuleInfo GetInfo();
+    void RegisterServices(IServiceCollection services);
+    void ConfigureMiddleware(IApplicationBuilder app);
+}
+```
+
+### ModuleInfo (Record)
+Metadata van een module, verplicht op te geven bij registratie.
+- `string Name`: Unieke identifier van de module.
+- `string Version`: Semantische versie (bijv. 1.0.0).
+- `string Description`: Korte omschrijving van het doel.
+- `IEnumerable<string> Dependencies`: Lijst met namen van modules waar deze module van afhankelijk is.
+
+## 2. Availability Interfaces & Entiteiten
+
+### IAvailabilityService
+Service die de status van een component bewaakt.
+```csharp
+public interface IAvailabilityService
+{
+    Task<bool> IsAvailableAsync();
+    Task<AvailabilityDetails> GetDetailsAsync();
+}
+```
+
+### AvailabilityDetails (Record)
+Gedetailleerde statusinformatie.
+- `bool IsAvailable`: Globale status van de API.
+- `DateTime LastChecked`: Tijdstip van de laatste controle.
+- `IDictionary<string, string> Metadata`: Extra statusinformatie (bijv. latency, Master-API status).
+
+## 3. Error Handling Models
+
+### ApiErrorResponse
+Basismodel voor foutmeldingen.
+- `string ErrorCode`: Functionele code (bijv. "MODULE_NOT_FOUND").
+- `string Message`: Mensvriendelijke beschrijving.
+- `IDictionary<string, object> Details`: Specifieke debug- of context-informatie per exception type.
@@ -0,0 +1,37 @@
+# Availability Service Design — Unit 01: Core Base
+
+Dit document beschrijft de technische details voor de beschikbaarheidscontrole (NFR-AVAIL-01).
+
+## 1. Configuratie
+
+De timeout wordt globaal geconfigureerd in `appsettings.json`:
+
+```json
+{
+  "AvailabilitySettings": {
+    "TimeoutSeconds": 2,
+    "DefaultStatusOnFailure": "Unknown"
+  }
+}
+```
+
+## 2. IAvailabilityService Interface
+
+Gedefinieerd in U01:
+
+```csharp
+public interface IAvailabilityService
+{
+    /// <summary>
+    /// Controleert de algemene beschikbaarheid van de API.
+    /// Gebruikt de geconfigureerde globale timeout.
+    /// </summary>
+    Task<AvailabilityStatus> IsAvailableAsync();
+}
+```
+
+## 3. Implementatie Details
+
+- **Timeout Mechanisme**: De implementatie maakt intern gebruik van `Task.WaitAsync(TimeSpan)` of een intern aangemaakte `CancellationTokenSource` met de tijd uit de configuratie.
+- **Fallback**: Bij een `TimeoutException` of een andere interne fout tijdens de check, wordt de status gerapporteerd die in de configuratie is vastgelegd (bijv. "Unknown").
+- **Logging**: Elke mislukte check of timeout moet worden gelogd met een `Warning` niveau, inclusief de verstreken tijd.
@@ -0,0 +1,38 @@
+# Exception Handling Design — Unit 01: Core Base
+
+Dit document beschrijft de technische implementatie van de globale foutafhandeling (NFR-SEC-01).
+
+## 1. IExceptionHandler Implementatie
+
+We maken gebruik van de `IExceptionHandler` interface (.NET 8+).
+
+### Component: `GlobalExceptionHandler`
+- **Verantwoordelijkheid**: Het vangen van ongehandled exceptions en het omzetten naar een gestandaardiseerd `ApiErrorResponse`.
+- **Logic**:
+    - Logt de volledige exception (inclusief stacktrace) naar `ILogger<GlobalExceptionHandler>`.
+    - Bepaalt de HTTP Status Code op basis van het type exception (bijv. `ValidationException` -> 400, `NotFoundException` -> 404, de rest -> 500).
+    - Bouwt het `ApiErrorResponse` object.
+
+## 2. ApiErrorResponse Structuur
+
+Conform NFR-SEC-01 wordt gevoelige informatie gefilterd in productie.
+
+```csharp
+public record ApiErrorResponse(
+    string Message,
+    string? Detail = null,
+    string? TraceId = null
+);
+```
+
+### Gedrag per omgeving:
+- **Development**: `Message` bevat de exception message, `Detail` bevat de stacktrace.
+- **Production**: `Message` bevat een generieke foutmelding of een veilige publieke melding, `Detail` is `null`. `TraceId` wordt altijd meegegeven voor correlatie in logs.
+
+## 3. Registratie
+
+In `Program.cs` (U04) of via een extensie-methode in de Core Base:
+```csharp
+services.AddExceptionHandler<GlobalExceptionHandler>();
+services.AddProblemDetails();
+```
@@ -0,0 +1,34 @@
+# Module Discovery Design — Unit 01: Core Base
+
+Dit document beschrijft het ontwerp van de dynamische module discovery (NFR-PERF-01).
+
+## 1. Naamconventie
+
+Het systeem scant automatisch naar assemblies die voldoen aan het volgende patroon:
+`SlpModularCms.Modules.*.dll`
+
+## 2. Discovery Logica
+
+De `ModuleOrchestrator` (onderdeel van U04, maar gebruikmakend van interfaces uit U01) voert de volgende stappen uit tijdens het opstarten:
+
+1. **Assembly Loading**: Zoekt in de applicatie-directory naar DLL's die voldoen aan de naamconventie.
+2. **Type Scanning**: In elke geladen assembly wordt gezocht naar klassen die de `IModule` interface implementeren.
+3. **Registration**: De gevonden module-entry klassen worden geïnstantieerd en hun `RegisterServices(IServiceCollection services)` methode wordt aangeroepen.
+
+### Performance Optimalisatie:
+- Om de opstarttijd te minimaliseren (NFR-PERF-01), worden alleen assemblies gescand die voldoen aan de prefix.
+- De resultaten van de discovery kunnen indien nodig worden gecached, hoewel de overhead bij een beperkt aantal modules verwaarloosbaar is (< 100ms).
+
+## 3. IModule Interface
+
+Gedefinieerd in de Core Base (U01):
+
+```csharp
+public interface IModule
+{
+    string Name { get; }
+    string Version { get; }
+    void RegisterServices(IServiceCollection services);
+    void UseModule(IApplicationBuilder app);
+}
+```
@@ -0,0 +1,37 @@
+# Testing Strategy Design — Unit 01: Core Base
+
+Dit document beschrijft de testaanpak voor de Core Base componenten (NFR-MAINT-02).
+
+## 1. Tooling
+
+- **Framework**: xUnit.
+- **Data Generatie**: AutoFixture.
+- **Mocks**: NSubstitute (optioneel, indien nodig voor interfaces).
+- **Assertions**: FluentAssertions.
+
+## 2. AutoFixture Patronen
+
+Om consistentie te waarborgen gebruiken we de volgende patronen:
+
+### Customizations
+Voor domein-specifieke types (zoals `ModuleInfo`) maken we gebruik van `ICustomization` klassen om realistische data te genereren.
+
+```csharp
+public class ModuleCustomization : ICustomization
+{
+    public void Customize(IFixture fixture)
+    {
+        fixture.Customize<ModuleInfo>(composer =>
+            composer.With(m => m.Version, "1.0.0"));
+    }
+}
+```
+
+### Base Test Class
+We overwegen een base class voor unit tests die de `IFixture` configureert met de benodigde customizations.
+
+## 3. Test Dekking Targets
+
+- **Exception Mapping**: 100% dekking van alle bekende exception types naar de juiste HTTP status codes en response formaten.
+- **Availability Fallback**: Tests die vertraging simuleren om te verifiëren dat de timeout en fallback status correct werken.
+- **Module Discovery**: Integratietesten (met in-memory assemblies) om te verifiëren dat de conventie-gebaseerde scanning correct werkt.
@@ -0,0 +1,27 @@
+# NFR Requirements — Unit 01: Core Base
+
+Dit document beschrijft de non-functional requirements voor het Core Framework.
+
+## 1. Schaalbaarheid & Performance (NFR-PERF)
+
+- **Dynamische Module Discovery**: Het systeem moet een onbekend aantal modules kunnen ondersteunen zonder significante degradatie van de opstarttijd.
+- **Middleware Overhead**: Een overhead van > 50ms voor globale exception handling en logging is acceptabel bevonden om robuustheid en detailniveau te waarborgen.
+- **Resource Management**: Interfaces in de Core Base moeten `async` zijn waar I/O verwacht wordt (bijv. `IAvailabilityService`) om threadpool starvation te voorkomen.
+
+## 2. Security & Privacy (NFR-SEC)
+
+- **Informatiebeveiliging in Responses**: De `ApiErrorResponse` mag in productieomgevingen onder geen beding de volgende informatie bevatten:
+    - Stacktraces.
+    - Interne server IP-adressen.
+    - Lokale bestandspaden van de server.
+- **Isolatie**: Hoewel modules in dezelfde procesruimte draaien, moet de Core Base interfaces bieden die een duidelijke scheiding van verantwoordelijkheden afdwingen.
+
+## 3. Availability & Reliability (NFR-AVAIL)
+
+- **Check Timeout**: De `IAvailabilityService.IsAvailableAsync()` methode moet een instelbare timeout hebben, met een standaardwaarde tussen 1 en 2 seconden.
+- **Graceful Degradation**: Bij het falen van de beschikbaarheidscontrole moet het systeem een veilige fallback status rapporteren (bijv. "Onbekend" of "Niet beschikbaar" voor reguliere gebruikers).
+
+## 4. Onderhoudbaarheid & Testbaarheid (NFR-MAINT)
+
+- **Consistentie**: Gebruik van gestandaardiseerde .NET patronen voor DI en Logging.
+- **Test Dekking**: Cruciale cross-cutting concerns (zoals exception mapping) moeten gedekt zijn met unit tests die gebruik maken van geautomatiseerde data generatie.
@@ -0,0 +1,24 @@
+# Tech Stack Decisions — Unit 01: Core Base
+
+Dit document legt de gekozen technologieën en bibliotheken vast voor de implementatie van Unit 01.
+
+## 1. Core Framework & Runtime
+
+- **Runtime**: .NET 10.
+- **Project Type**: Class Library (voor Core).
+
+## 2. Cross-Cutting Concerns
+
+- **Dependency Injection**: Standaard `Microsoft.Extensions.DependencyInjection`. Er is momenteel geen behoefte aan externe containers zoals Autofac.
+- **Logging**: Standaard `Microsoft.Extensions.Logging`. Implementaties (zoals Serilog voor file/cloud logging) kunnen later in de API Shell (U04) worden geconfigureerd.
+
+## 3. Testing Stack
+
+- **Unit Testing Framework**: `xUnit`.
+- **Assertions**: `FluentAssertions` voor leesbare en expressieve checks.
+- **Data Generation**: `AutoFixture` voor het genereren van test data en het ondersteunen van geautomatiseerde scenario's (ter vervanging/aanvulling van formele PBT met FsCheck, conform gebruikersvoorkeur).
+
+## 4. Architecturale Patronen
+
+- **Interfaces & Records**: Veelal gebruik van `record` types voor DTO's en metadata (zoals `ModuleInfo`) voor onveranderlijkheid (immutability).
+- **Middleware**: Gebruik van het standard .NET Middleware patroon voor globale exception handling.
@@ -0,0 +1,33 @@
+# Construction Phase Final Report - SlpModularCms.Api
+
+## Project Overzicht
+- **Project**: SlpModularCms.Api
+- **Status**: VOLTOOID
+- **Datum**: 2026-06-12
+
+## Voltooide Units
+1. **Unit 01: Core Base**
+   - Kern interfaces (`IModule`, `IAvailabilityService`).
+   - Globale exception handling (.NET 8+ stijl).
+   - Project structuur (`src/` folder) en test setup.
+2. **Unit 02: Identity & RBAC**
+   - ASP.NET Core Identity integratie met hiërarchische rollen (Owner, Admin, User).
+   - JWT Authenticatie en Refresh Token mechanisme (SQL Server persistent).
+   - Uitnodigingsflow voor nieuwe gebruikers.
+3. **Unit 03: Availability Module**
+   - Dynamische statuscontrole (Available, Maintenance, Degraded).
+   - Persistentie in database met Circuit Breaker fallback.
+   - Middleware integratie met bypass voor beheerderstaken.
+4. **Unit 04: API Shell & Integration**
+   - Dynamische module discovery via assembly scanning.
+   - Globale API versioning (`/api/v1/`).
+   - Scalar OpenAPI documentatie op `/scalar`.
+   - CORS en Security headers geconfigureerd.
+
+## Verificatie Resultaten
+- **Build**: Succesvol (0 errors).
+- **Unit Tests**: 21 tests geslaagd (100% pass rate).
+- **Integratie**: Succesvol (Module discovery en routing geverifieerd).
+
+## Conclusie
+De CONSTRUCTION PHASE is formeel afgerond. Alle functionele en niet-functionele vereisten voor de MVP zijn geïmplementeerd en geverifieerd. Het systeem is klaar voor de OPERATIONS PHASE of verdere functionele uitbreidingen.
@@ -0,0 +1,38 @@
+# Business Rules — Unit 02: Identity & RBAC
+
+Dit document beschrijft de validatieregels en logica voor identiteitsbeheer en autorisatie.
+
+## 1. Hiërarchische Rollen (BR-ID-01)
+
+- **Hiërarchie**: Owner (100) > Administrator (50) > User (10).
+- **Beperking**: Een gebruiker kan alleen acties uitvoeren op gebruikers met een **lagere** rol in de hiërarchie.
+    - Uitzondering: Een Owner kan acties uitvoeren op andere Owners (bijv. de-activeren, mits niet de laatste Owner).
+    - Een Administrator kan een User beheren, maar geen andere Administrator of Owner.
+- **Rolverandering**: Een gebruiker kan een andere gebruiker nooit een rol toekennen die hoger is dan zijn eigen rol.
+
+## 2. Gebruikerscreatie & Uitnodiging (BR-ID-02)
+
+- **Geen Zelfregistratie**: Het systeem staat geen publieke registratie toe.
+- **Uitnodigingsflow**: 
+    1. Administrator/Owner maakt een uitnodiging aan (e-mail + rol).
+    2. Systeem genereert een `InvitationToken` met een beperkte geldigheidsduur (bijv. 24 uur).
+    3. Gebruiker moet via een specifiek endpoint (`POST /api/setup/complete-invitation`) zijn wachtwoord instellen met dit token.
+    4. Na succesvolle instelling wordt het token ongeldig en het account geactiveerd.
+
+## 3. Bootstrapping (BR-ID-03)
+
+- **Setup Endpoint**: Bij een lege database is een eenmalig endpoint `POST /api/setup/init` beschikbaar.
+- **Eerste Owner**: Dit endpoint accepteert de gegevens voor de eerste Owner. Na succesvolle aanmaak wordt dit endpoint permanent geblokkeerd of verwijderd uit de routing.
+
+## 4. Authenticatie & Sessies (BR-ID-04)
+
+- **Wachtwoord Hashen**: Wachtwoorden moeten gehasht worden volgens de ASP.NET Core Identity standaard (PBKDF2 met HMAC-SHA256).
+- **Refresh Tokens**: 
+    - Refresh tokens zijn gekoppeld aan een specifieke gebruiker en client/apparaat.
+    - Refresh tokens kunnen maar één keer worden gebruikt (Rotation-principe).
+    - Bij gebruik van een oud refresh token worden alle actieve sessies van die gebruiker ongeldig gemaakt (beveiligingsmaatregel tegen token diefstal).
+
+## 5. Module-specifieke Rechten (BR-ID-05)
+
+- **Fine-grained Access**: Naast de globale rollen kunnen Beheerders specifieke rechten per module toekennen aan Users.
+- **Default**: Zonder expliciete module-rechten heeft een User alleen leesrechten of basisrechten binnen een module (afhankelijk van de module-implementatie).
@@ -0,0 +1,37 @@
+# Domain Entities — Unit 02: Identity & RBAC
+
+Dit document beschrijft de data-entiteiten die nodig zijn voor identiteitsbeheer.
+
+## 1. ApplicationUser
+
+Breidt de standaard `IdentityUser` uit.
+
+- **Email**: Unieke identifier.
+- **Role**: De primaire hiërarchische rol (`Owner`, `Administrator`, `User`).
+- **IsActive**: Boolean status.
+- **CreatedAt**: Tijdstip van aanmaak.
+- **ModulePermissions**: Navigatie-eigenschap naar module-specifieke rechten.
+
+## 2. RefreshToken
+
+- **Id**: Guid.
+- **Token**: De gehashte token string.
+- **UserId**: Link naar de `ApplicationUser`.
+- **ExpiryDate**: Wanneer het token verloopt.
+- **IsUsed**: Boolean (voor re-use detection).
+- **IsRevoked**: Boolean (handmatige intrekking).
+- **CreatedByIp**: IP adres voor audit trail.
+
+## 3. Invitation
+
+- **Email**: Adres waar de uitnodiging naar verzonden is.
+- **Role**: De toegekende rol na acceptatie.
+- **Token**: Unieke GUID/String.
+- **ExpiryDate**: Geldigheidsduur van de uitnodiging.
+- **IsAccepted**: Boolean.
+
+## 4. ModulePermission
+
+- **UserId**: Link naar `ApplicationUser`.
+- **ModuleName**: Naam van de module.
+- **Permission**: De specifieke string-gebaseerde permissie (bijv. "Write", "Admin").
@@ -0,0 +1,62 @@
+# Business Logic Model — Unit 02: Identity & RBAC
+
+Dit document beschrijft de processen en datastromen voor authenticatie en autorisatie.
+
+## 1. Authenticatie Flow (JWT)
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant AuthController
+    participant AuthService
+    participant UserManager
+    participant Database
+
+    Client->>AuthController: Login(Email, Password)
+    AuthController->>AuthService: AuthenticateAsync(Email, Password)
+    AuthService->>UserManager: FindByEmailAsync(Email)
+    UserManager->>Database: Get User
+    Database-->>UserManager: User Data
+    UserManager->>UserManager: CheckPasswordAsync(User, Password)
+    AuthService->>AuthService: GenerateTokens(User)
+    AuthService->>Database: Save RefreshToken
+    AuthService-->>AuthController: AccessToken, RefreshToken
+    AuthController-->>Client: 200 OK (Tokens)
+```
+
+## 2. Uitnodigingsproces
+
+```mermaid
+graph TD
+    A[Admin/Owner] -->|Create Invitation| B(InvitationService)
+    B -->|Generate Token| C(InvitationToken)
+    C -->|Save to DB| D[(Database)]
+    B -->|Send Email| E[User]
+    E -->|Click Link| F[Setup Page]
+    F -->|Submit Password + Token| G(SetupController)
+    G -->|Validate Token| B
+    B -->|Create Account| H(UserManager)
+    H -->|Activate User| D
+```
+
+## 3. Hiërarchische Autorisatie Logic
+
+De autorisatie wordt afgehandeld via ASP.NET Core `AuthorizationPolicies`.
+
+- **Policy: `RequireLowerRole`**:
+    - Haalt de rol van de huidige gebruiker (X) en de doelgebruiker (Y) op.
+    - Vergelijkt de numerieke waarden van de rollen.
+    - Slaagt alleen als `RoleValue(X) > RoleValue(Y)` (of `X == Y` en `X == Owner`).
+
+## 4. Token Refresh Logic
+
+1. Client stuurt `Expired Access Token` + `Refresh Token`.
+2. Systeem controleert of `Refresh Token` bestaat in de database en niet verlopen is.
+3. Systeem controleert of `Refresh Token` al eerder is gebruikt (Re-use detection).
+4. Indien geldig:
+    - Genereer nieuw `Access Token`.
+    - Genereer nieuw `Refresh Token` (Rotation).
+    - Verwijder/Invalideer het oude `Refresh Token`.
+5. Indien ongeldig of re-use:
+    - Trek alle tokens van de gebruiker in.
+    - Retourneer `401 Unauthorized`.
@@ -0,0 +1,35 @@
+# Auth Service Design — Unit 02: Identity & RBAC
+
+Dit document beschrijft de `IAuthService` die verantwoordelijk is voor token-management.
+
+## 1. Interface definitie
+
+```csharp
+public interface IAuthService
+{
+    Task<TokenResponse> AuthenticateAsync(string email, string password);
+    Task<TokenResponse> RefreshTokenAsync(string accessToken, string refreshToken);
+    Task RevokeTokenAsync(string refreshToken);
+}
+```
+
+## 2. JWT Configuratie
+
+- **Signing Key**: Wordt uit de environment variable `JWT_SIGNING_KEY` gelezen.
+- **Issuer/Audience**: Worden geconfigureerd in `appsettings.json`.
+- **Claims**:
+    - `sub`: UserId.
+    - `email`: Gebruikers e-mail.
+    - `role`: Gebruikers rol (bijv. "Administrator").
+    - `exp`: Expiration time.
+
+## 3. Refresh Token Rotation Logic
+
+Bij een refresh request:
+1. Valideer de `refreshToken` string tegen de database.
+2. Controleer op Re-use: Indien de `IsUsed` vlag al op `true` staat, trek dan **alle** tokens van die gebruiker in (NFR-ID-SEC-03).
+3. Indien geldig:
+    - Markeer huidig token als `IsUsed = true`.
+    - Genereer een nieuw cryptografisch veilig geheim (32 bytes Base64).
+    - Sla het nieuwe token op met een nieuwe `ExpiryDate`.
+    - Retourneer het nieuwe `AccessToken` en `RefreshToken`.
@@ -0,0 +1,52 @@
+# Authorization Design — Unit 02: Identity & RBAC
+
+Dit document beschrijft de technische implementatie van de hiërarchische autorisatie.
+
+## 1. HierarchicalRoleRequirement
+
+We maken gebruik van een custom requirement om rollen te vergelijken.
+
+```csharp
+public class HierarchicalRoleRequirement : IAuthorizationRequirement
+{
+    public HierarchicalRoleRequirement(string minimumRequiredRole)
+    {
+        MinimumRequiredRole = minimumRequiredRole;
+    }
+
+    public string MinimumRequiredRole { get; }
+}
+```
+
+## 2. HierarchicalRoleHandler
+
+De handler valideert of de rollen-hiërarchie wordt gerespecteerd.
+
+- **Logic**:
+    1. Haal de rol-claim op van de huidige gebruiker.
+    2. Haal de doel-gebruiker op uit de route of body.
+    3. Vergelijk de numerieke waarden van beide rollen.
+    4. Slaag alleen als de huidige gebruiker een hogere of gelijke rol heeft (afhankelijk van de actie).
+
+## 3. Setup Endpoint Protection
+
+Het `SetupController.Init` endpoint controleert direct in de database of er al een Owner bestaat:
+
+```csharp
+[HttpPost("init")]
+public async Task<IActionResult> Init(SetupRequest request)
+{
+    var anyOwner = await _userManager.GetUsersInRoleAsync("Owner");
+    if (anyOwner.Any())
+    {
+        return Forbidden("Systeem is reeds geïnitialiseerd.");
+    }
+    // Verwerk creatie...
+}
+```
+
+## 4. Module-specifieke Policies
+
+Er worden dynamische policies aangemaakt voor module-permissies:
+- Patroon: `Module:{ModuleName}:{Permission}` (bijv. `Module:Blog:Delete`).
+- De handler controleert de `ModulePermissions` tabel voor de huidige gebruiker.
@@ -0,0 +1,52 @@
+# Database Design — Unit 02: Identity & RBAC
+
+Dit document beschrijft de database schema configuratie voor de identiteitsmodule.
+
+## 1. DbContext Mapping (Identity)
+
+De `ApplicationDbContext` erft over van `IdentityDbContext<ApplicationUser, IdentityRole<Guid>, Guid>`.
+In `OnModelCreating` worden de tabelnamen geconfigureerd:
+
+```csharp
+protected override void OnModelCreating(ModelBuilder builder)
+{
+    base.OnModelCreating(builder);
+
+    builder.Entity<ApplicationUser>(entity => { entity.ToTable("Users"); });
+    builder.Entity<IdentityRole<Guid>>(entity => { entity.ToTable("Roles"); });
+    builder.Entity<IdentityUserRole<Guid>>(entity => { entity.ToTable("UserRoles"); });
+    builder.Entity<IdentityUserClaim<Guid>>(entity => { entity.ToTable("UserClaims"); });
+    builder.Entity<IdentityUserLogin<Guid>>(entity => { entity.ToTable("UserLogins"); });
+    builder.Entity<IdentityRoleClaim<Guid>>(entity => { entity.ToTable("RoleClaims"); });
+    builder.Entity<IdentityUserToken<Guid>>(entity => { entity.ToTable("UserTokens"); });
+}
+```
+
+## 2. Aanvullende Tabellen
+
+### RefreshTokens
+- **Tabel**: `RefreshTokens`
+- **PK**: `Id` (Guid)
+- **FK**: `UserId` -> `Users.Id`
+- **Index**: `Token` (Unique)
+
+### Invitations
+- **Tabel**: `Invitations`
+- **PK**: `Id` (Guid)
+- **Index**: `Token` (Unique)
+- **Email**: `NVARCHAR(256)`
+
+### ModulePermissions
+- **Tabel**: `ModulePermissions`
+- **Composite PK**: `(UserId, ModuleName, Permission)`
+- **FK**: `UserId` -> `Users.Id`
+
+## 3. Auditing (NFR-ID-SEC-03)
+
+Er wordt een aparte `AuditLogs` tabel aangemaakt voor het loggen van mutaties:
+- `Id` (Guid)
+- `Timestamp` (DateTimeOffset)
+- `ActorId` (Guid - De uitvoerder)
+- `Action` (String - bijv. "RoleChange", "UserCreated")
+- `EntityId` (Guid - Het doelobject)
+- `Details` (JSON/String - Oude vs Nieuwe waarden)
@@ -0,0 +1,40 @@
+# Invitation Design — Unit 02: Identity & RBAC
+
+Dit document beschrijft de technische implementatie van het uitnodigingssysteem.
+
+## 1. IInvitationService
+
+```csharp
+public interface IInvitationService
+{
+    Task<string> CreateInvitationAsync(string email, string role);
+    Task<bool> ValidateInvitationAsync(string token);
+    Task CompleteInvitationAsync(string token, string password);
+}
+```
+
+## 2. Token Generatie
+
+Het `InvitationToken` wordt gegenereerd met de `RandomNumberGenerator`:
+
+```csharp
+public string GenerateSecureToken()
+{
+    var bytes = new byte[32];
+    RandomNumberGenerator.Fill(bytes);
+    return Convert.ToBase64String(bytes);
+}
+```
+
+## 3. Workflow Details
+
+1. **Creatie**:
+    - Een `Invitation` record wordt aangemaakt in de database.
+    - Het `Token` wordt gehasht opgeslagen (net als een wachtwoord) om misbruik bij database-lekken te voorkomen.
+2. **Validatie**:
+    - Het systeem zoekt het record op basis van de token-string.
+    - Controleert `ExpiryDate` en `IsAccepted`.
+3. **Afronding**:
+    - Bij `CompleteInvitationAsync` wordt de `ApplicationUser` aangemaakt via de `UserManager`.
+    - De rol wordt toegekend.
+    - Het uitnodigingsrecord wordt gemarkeerd als `IsAccepted = true`.
@@ -0,0 +1,35 @@
+# NFR Requirements — Unit 02: Identity & RBAC
+
+Dit document specificeert de non-functionele vereisten voor identiteitsbeheer en autorisatie.
+
+## 1. Beveiliging (Security)
+
+- **ID-SEC-01: Wachtwoordbeleid**:
+    - Minimale lengte: 8 tekens.
+    - Geen verplichte complexiteitseisen (hoofdletters/cijfers), focus op lengte voor gebruiksvriendelijkheid.
+- **ID-SEC-02: Token Lifecycle**:
+    - Access Token (JWT) vervaltijd: 1 uur.
+    - Refresh Token vervaltijd: 7 dagen.
+- **ID-SEC-03: Audit Logging**:
+    - Verplichte persistente logging van:
+        - Gebruikerscreatie en uitnodigingen.
+        - Rolwijzigingen.
+        - Activatie/Deactivatie van accounts.
+        - Mislukte login pogingen.
+- **ID-SEC-04: Data Privacy**:
+    - Wachtwoorden worden nooit in plain-text opgeslagen.
+    - Persoonlijke gegevens (PII) worden alleen via HTTPS ontsloten.
+
+## 2. Performance
+
+- **ID-PERF-01: Token Validatie**:
+    - De validatie van het JWT token bij elk request mag niet meer dan 5ms overhead toevoegen.
+- **ID-PERF-02: Database Querying**:
+    - Het ophalen van een gebruiker inclusief rollen en permissies moet binnen 20ms gebeuren (geïndexeerd op Email).
+
+## 3. Onderhoudbaarheid (Maintainability)
+
+- **ID-MAINT-01: Database Schema**:
+    - Gebruik van schone tabelnamen zonder `AspNet` prefix (bijv. `Users`, `Roles`, `UserRoles`).
+- **ID-MAINT-02: EF Core Migrations**:
+    - Alle wijzigingen aan het identiteitsschema worden via code-first migrations bijgehouden.
@@ -0,0 +1,35 @@
+# Tech Stack Decisions — Unit 02: Identity & RBAC
+
+Dit document beschrijft de definitieve technische keuzes voor Unit 02.
+
+## 1. Core Frameworks
+
+- **Identity**: Microsoft.AspNetCore.Identity.
+- **ORM**: Entity Framework Core.
+- **Database**: Microsoft SQL Server.
+
+## 2. Authenticatie & Autorisatie
+
+- **JWT Library**: Microsoft.AspNetCore.Authentication.JwtBearer.
+- **Policy Engine**: Native ASP.NET Core Authorization Policies & RequirementHandlers.
+- **Hashing**: PBKDF2 (standaard Identity).
+
+## 3. Database Schema Mapping
+
+Conform ID-MAINT-01 worden de standaard Identity tabellen hernoemd in de `OnModelCreating` van de `DbContext`:
+
+| Standaard Naam | Nieuwe Naam |
+|---|---|
+| AspNetUsers | Users |
+| AspNetRoles | Roles |
+| AspNetUserRoles | UserRoles |
+| AspNetUserClaims | UserClaims |
+| AspNetUserLogins | UserLogins |
+| AspNetRoleClaims | RoleClaims |
+| AspNetUserTokens | UserTokens |
+
+## 4. Testing Tools
+
+- **Unit Tests**: xUnit + FluentAssertions + NSubstitute.
+- **Data Generation**: AutoFixture.
+- **PBT**: FsCheck (alleen voor token-logic en mapping functies, conform NFR-06).
@@ -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/`.
@@ -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 |