# 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