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
2.4 KiB
NFR Design Plan — Unit: SlpSoftware Client Setup
Categorieën die niet van toepassing zijn (met onderbouwing, niet zomaar overgeslagen):
- Scalability Patterns: N/A — deze unit voegt geen belasting toe, ze hercomponeert bestaande middleware. Geen nieuwe schaal-grenzen.
- Performance Patterns: N/A — zelfde reden; geen nieuwe latency/throughput-doelen, alleen reproductie van bestaand gedrag.
- Security Patterns: al besloten in NFR Requirements (NFR-CS-03) — "identiek gedrag, geverifieerd door de nieuwe regressietests" is het patroon; er is geen los ontwerp nodig bovenop wat NFR-CS-01 al vastlegt.
Uitvoeringschecklist
- Stap A —
nfr-design-patterns.md: testpatroon en observability-patroon vastleggen - Stap B —
logical-components.md: de nieuwe testproject-structuur enCmsHostOptionsals logische componenten beschrijven
Vragen
Vraag 1 — Tegen welk(e) project(en) draaien de nieuwe pipeline-tests?
NFR-CS-01 vereist nieuwe WebApplicationFactory-gebaseerde tests die het pipeline-gedrag verifiëren. Ze kunnen tegen Api, tegen Api.SlpSoftware, of tegen beide draaien.
A) Tegen beide Client-projecten — één gedeelde/geparametriseerde testsuite die tegen zowel Api als Api.SlpSoftware draait; sterkste garantie dat CmsHost zich op beide identiek gedraagt, iets meer testtijd
B) Alleen tegen Api.SlpSoftware — het project waar het écht om gaat (toekomstige productie-host); Api blijft ongetest op pipeline-niveau maar heeft z'n bestaande (unit-niveau) testsuite nog
C) Alleen tegen Api — bestaat al, sneller op te zetten; Api.SlpSoftware erft het vertrouwen via de gedeelde CmsHost-code
X) Anders (beschrijf hieronder na de Answer:-tag)
Vraag 2 — Inhoud van CmsHostOptions
Tech-stack-decisions.md liet de exacte vorm van CmsHostOptions open. Voor het NFR-ontwerp: moet de klasse nu al één concreet, direct nuttig veld krijgen, of blijft het een lege plaatshouder?
A) Eén concreet veld nu: bijv. HostLabel/ApplicationName (string) — gebruikt voor observability-tagging (logs/Sentry), zodat je straks in gedeelde logging kunt onderscheiden of een entry van Api of Api.SlpSoftware komt. Direct nuttig, geen giswerk over toekomstige velden.
B) Volledig lege plaatshouderklasse — puur een uitbreidingspunt zonder velden, tot er een concrete behoefte is
X) Anders (beschrijf hieronder na de Answer:-tag)