Files
slp-modular-cms/aidlc-docs/features/slpsoftware-api/construction/slpsoftware-client-setup/nfr-requirements/tech-stack-decisions.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.3 KiB

Tech Stack Decisions — Unit: SlpSoftware Client Setup

No New Technology Introduced

This unit re-composes existing infrastructure (ASP.NET Core hosting, the existing Core.Hosting.* extension methods, the existing ModuleOrchestrator). No new package, framework, or external service is introduced.

Decision: CmsHostOptions (new, minimal)

Per NFR-CS-02 (Q2 = B), CmsHost.ConfigureServices/ConfigurePipeline will accept a CmsHostOptions parameter.

What it must NOT contain: anything affecting the Data Protection application discriminator (DataProtectionExtensions.ApplicationDiscriminator, hardcoded "SlpModularCms"). That constant is deliberately not configurable — an existing code comment explains that a mismatched discriminator between instances silently breaks previously-encrypted values with no visible error. CmsHostOptions must not reopen that risk.

Exact shape: left open for Code Generation Planning for this unit — both current call sites (Api, Api.SlpSoftware) pass equivalent values today, so there is no concrete divergence yet to model. Introducing the parameter now (rather than later) is purely about not having to touch both Program.cs call sites' method signatures again the first time a real difference appears.

Decision: New Integration Test Project/Location for Pipeline Tests (NFR-CS-01)

No dedicated Api.Tests project exists today (only module/Core test projects). For the new WebApplicationFactory-based pipeline tests:

  • Exact project placement (a new shared test project vs. extending SlpModularCms.Core.Tests) is a Code Generation Planning decision, not decided here — this is implementation planning, not a technology choice. Either way, Microsoft.AspNetCore.Mvc.Testing (the standard WebApplicationFactory package) is the technology being introduced; it is Microsoft's own first-party integration-testing package for ASP.NET Core, already implied by the framework version this solution targets — no new external dependency risk.

Database

No change. Both Api and Api.SlpSoftware connect to MariaDB via UseMySQL, using their own environment-specific connection string per the existing dotnet-appsettings pattern (already the case for Api/Api.Slave). No new decision required for this unit.