# NFR Requirements Plan — Unit: SlpSoftware Client Setup

**Waarom Functional Design is overgeslagen voor deze unit**: geen nieuw datamodel, geen nieuwe business rules — dit is een pure hosting-compositie-extractie (FR-1/FR-2/FR-3), zonder domeinlogica om te ontwerpen. Rechtstreeks door naar NFR Requirements.

**Al vastgelegd, hier niet opnieuw bevraagd**:
- **Security**: deze unit introduceert geen nieuw aanvalsoppervlak (geen nieuwe module, geen nieuwe business logic) — het enige vereiste is dat de bestaande Security Baseline-regels (SECURITY-03/04/09/10/14/15) na de extractie **exact** hetzelfde gedrag opleveren als vandaag. Zie Vraag 1 hieronder voor hoe dat geverifieerd wordt.
- **Database-scheiding**: `Api` en `Api.SlpSoftware` gebruiken elk hun eigen `appsettings.json`/`appsettings.local.json` (bestaand `dotnet-appsettings`-patroon, ook al toegepast tussen `Api` en `Api.Slave`) — dus per omgeving een eigen connection string. Geen wijziging t.o.v. vandaag, geen vraag nodig.

## Uitvoeringschecklist

- [x] Stap A — `nfr-requirements.md`: NFR's voor deze unit vastleggen (reliability/testability, maintainability)
- [x] Stap B — `tech-stack-decisions.md`: bevestigen dat geen nieuwe technologie nodig is; vastleggen of `CmsHost` parameterloos blijft

---

## Vragen

### Vraag 1 — Regressietest-strengheid voor de `CmsHost`-extractie
`Api/Program.cs` bevat vandaag gedrag dat niet mag veranderen: security headers, rate limiting, health checks, static content + SPA-fallback, Sentry-tunnel. Hoe streng moet geverifieerd worden dat `CmsHost` dat gedrag exact reproduceert?

A) Vertrouwen op `Api`'s bestaande testsuite die ongewijzigd groen blijft — voldoende signaal, geen nieuwe tests specifiek voor deze extractie
B) Nieuwe integratietests toevoegen die specifiek het pipeline-gedrag assert (headerwaarden aanwezig, health-endpoint bereikbaar, SPA-fallback lost op) — blijvende regressiebewaking voor beide Client-projecten, ook na deze feature
C) Alleen handmatige smoke-test (beide apps lokaal draaien, responses vergelijken), geen nieuwe geautomatiseerde tests
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]: A, als dit voldoende dekking geeft, anders B

### Vraag 2 — Uitbreidbaarheid van `CmsHost`
`CmsHost.ConfigureServices`/`ConfigurePipeline` (application-design/component-methods.md) hebben vandaag geen parameters buiten `WebApplicationBuilder`/`WebApplication` — beide Client-projecten roepen ze identiek aan.

Moet er nu al ruimte komen voor toekomstige verschillen tussen projecten (bijv. een `CmsHostOptions`-object), of pas toevoegen zodra er een echte reden voor is?

A) Parameterloos houden voor nu (YAGNI) — pas een parameter toevoegen zodra `Api` en `Api.SlpSoftware` daadwerkelijk moeten verschillen
B) Nu al een klein `CmsHostOptions`-object toevoegen, ook al geven beide aanroepen vandaag identieke waarden door
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]: B