# Story Generation Plan — SlpSoftware Production API

Dit plan beschrijft hoe de user stories en persona's voor deze feature worden opgesteld. Beantwoord eerst de vragen hieronder; na jouw goedkeuring wordt dit plan stap voor stap uitgevoerd.

## Uitvoeringschecklist

- [x] Stap A — Persona's definiëren (`personas.md`): Site Visitor (anonieme bezoeker marketingsite) en CMS Administrator (Administrator-rol, beheert offerings via `/admin`)
- [x] Stap B — Stories voor de Site Visitor-persona (consumptie van `GET /api/v1/offerings`, incl. leeg-resultaat-scenario)
- [x] Stap C — Stories voor de CMS Administrator-persona (aanmaken, bewerken, verwijderen, herordenen van offerings, incl. de "featured"-regel)
- [x] Stap D — Acceptatiecriteria per story toevoegen (Given/When/Then, zie Vraag 2)
- [x] Stap E — Persona's koppelen aan bijbehorende stories
- [x] Stap F — Zelfcontrole: elke story voldoet aan INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)
- [x] Stap G — `stories.md` en `personas.md` opslaan onder `aidlc-docs/features/slpsoftware-api/inception/user-stories/`

## Aanpak-opties voor storyopbouw

- **Persona-based** (aanbevolen): stories gegroepeerd per persona (Site Visitor / CMS Administrator) — sluit direct aan op de twee duidelijk verschillende gebruikersrollen uit requirements.md.
- **Feature-based**: stories gegroepeerd per capability (lezen, aanmaken, bewerken, verwijderen, herordenen) ongeacht wie de actor is.
- **Hybride**: epics per persona, met feature-based sub-stories eronder.

---

## Vragen

### Vraag 1 — Storyopbouw
Welke aanpak voor het groeperen van de stories heeft je voorkeur?

A) Persona-based (aanbevolen) — twee groepen: Site Visitor en CMS Administrator
B) Feature-based — gegroepeerd per capability (lezen/aanmaken/bewerken/verwijderen/herordenen)
C) Hybride — epics per persona met feature-based sub-stories
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]: a

### Vraag 2 — Detailniveau acceptatiecriteria
Welk format voor acceptatiecriteria per story?

A) Given/When/Then (aanbevolen — direct bruikbaar als testscenario in latere fases)
B) Simpele bullet-checklist per story (sneller te lezen, minder gestructureerd)
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]: A

### Vraag 3 — "Exactly one featured" regel
De externe hand-off-doc noemt: "Exactly one package in the list should have `featured: true`" — maar de frontend handhaaft dit niet zelf. Moet de admin-CRUD (bij het aanmaken/bewerken) dit afdwingen?

A) Ja — bij het instellen van `featured` op een offering wordt automatisch de vorige featured-offering ontfeatured (systeem garandeert altijd precies 0 of 1 featured item)
B) Nee — geen afdwinging; de admin is zelf verantwoordelijk, het systeem staat 0, 1 of meerdere featured offerings toe
C) Waarschuwen, niet blokkeren — het systeem staat meerdere featured offerings toe maar toont een duidelijke waarschuwing in de admin-UI
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]: A

### Vraag 4 — Lege lijst op de publieke endpoint
Wat moet er gebeuren als de admin alle offerings verwijdert, zodat `GET /api/v1/offerings` een lege array `[]` teruggeeft?

A) Toestaan — een lege array is een geldige response; de marketingsite toont dan geen pakket-cards (frontend-verantwoordelijkheid, niet iets wat de API moet voorkomen)
B) Voorkomen — de admin kan de laatste overgebleven offering niet verwijderen (systeem blokkeert dit met een duidelijke foutmelding)
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]:A

### Vraag 5 — Herordenen (reorder)
Hoe moet de admin de volgorde van offerings (het `DisplayOrder`-veld uit FR-5) kunnen aanpassen?

A) Drag-and-drop in de lijst-view van de admin-UI
B) Expliciete "omhoog"/"omlaag"-knoppen per rij
C) Een numeriek volgorde-veld dat de admin direct invult bij het aanmaken/bewerken
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]: A en B

### Vraag 6 — Persona-naam voor de beheerder
Welke naam/omschrijving past het best bij de admin-persona, gezien de `AdminOnly`-policy (Administrator-rol) uit requirements.md?

A) "CMS Administrator" — generieke, rol-neutrale naam
B) "Site Owner" — benadrukt dat het (voorlopig) waarschijnlijk de eigenaar zelf is die dit gebruikt
X) Anders (geef zelf een naam op na de [Answer]:-tag)

[Answer]: CMS Beheerder, als we het nederlands willen houden