Files
slp-modular-cms/aidlc-docs/features/slpsoftware-api/construction/plans/slpsoftware-client-setup-nfr-requirements-plan.md
T
SluijsensandClaude Sonnet 5 fa389e42ee
Continuous Integration / config (pull_request) Successful in 11s
Continuous Integration / changes (pull_request) Successful in 21s
Continuous Integration / backend-build (pull_request) Successful in 6m10s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m59s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m27s
Continuous Integration / backend-test (pull_request) Failing after 7m48s
Continuous Integration / frontend-build (pull_request) Successful in 2m5s
Continuous Integration / frontend-test (pull_request) Successful in 4m24s
Continuous Integration / frontend-lint (pull_request) Successful in 2m0s
Continuous Integration / publish-test (pull_request) Skipped
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-test (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Adds SlpModularCms.Api.SlpSoftware and extracts shared CmsHost composition
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
2026-08-02 01:28:39 +02:00

2.9 KiB

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

  • Stap A — nfr-requirements.md: NFR's voor deze unit vastleggen (reliability/testability, maintainability)
  • 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)