SluijsensandClaude Sonnet 5
fa389e42ee
Unit 1 of the slpsoftware-api feature (FR-1/FR-2/FR-3): a new Client project in the Clients solution folder, intended to eventually become the deployed API for test.slpsoftware.nl/slpsoftware.nl, hosting the same four modules as SlpModularCms.Api plus a future Offerings module. - Extracts SlpModularCms.Api/Program.cs's hosting-pipeline composition into SlpModularCms.Core.Hosting.CmsHost (ConfigureServices/ConfigurePipeline), shared by both Client projects so they cannot drift apart - Moves StaticContentExtensions.cs + WebsitePlaceholder.html from Api into Core, since CmsHost cannot live in Api but Core cannot depend on Api - Adds SlpModularCms.Api.SlpSoftware with its own isolated local dev database and dev ports (5286/7223, distinct from Api's and Api.Slave's) - Adds SlpModularCms.Api.Tests with WebApplicationFactory-based pipeline regression tests (security headers, health check, SPA fallback, rate limiting), scoped to Api per NFR Design - Adds a frontend dev:slpsoftware pnpm script mirroring dev:slave - Fixes GlobalExceptionHandler logging routine 401s (e.g. an expired/missing refresh token) as unhandled errors -- pre-existing, unrelated to this feature's own scope, found while testing the new instance Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN
4.3 KiB
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
- Stap A — Persona's definiëren (
personas.md): Site Visitor (anonieme bezoeker marketingsite) en CMS Administrator (Administrator-rol, beheert offerings via/admin) - Stap B — Stories voor de Site Visitor-persona (consumptie van
GET /api/v1/offerings, incl. leeg-resultaat-scenario) - Stap C — Stories voor de CMS Administrator-persona (aanmaken, bewerken, verwijderen, herordenen van offerings, incl. de "featured"-regel)
- Stap D — Acceptatiecriteria per story toevoegen (Given/When/Then, zie Vraag 2)
- Stap E — Persona's koppelen aan bijbehorende stories
- Stap F — Zelfcontrole: elke story voldoet aan INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)
- Stap G —
stories.mdenpersonas.mdopslaan onderaidlc-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)
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)
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)
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)
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