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
3.6 KiB
Infrastructure Design — Unit: SlpSoftware Client Setup
Production / Test Infrastructure — No Change Now, Documented Target for the Future Cutover
Sourced directly from aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md (the authoritative, existing deploy documentation, owned by that feature):
| Aspect | Current (Api) |
Target after D-15 cutover (Api.SlpSoftware) |
|---|---|---|
| Host | Single Raspberry Pi ("pi-main") | Same Pi — no new host |
| TLS termination | Separate "proxy Pi", reverse-proxies to pi-main | Unchanged |
| Process manager | systemd --user, units slpsoftware-test.service / slpsoftware-production.service |
Same unit names — only the ExecStart line's .dll filename changes |
| Ports | 5100 (test), 5101 (production) | Unchanged |
| Database | MariaDB on pi-main, SlpSoftwareTest / SlpSoftwareProduction |
Unchanged — same instance, same database names (this is a cutover of which binary runs, not a new environment) |
| Monitoring | Shared Sentry project, distinguished by Observability__Environment |
Unchanged |
| Reverse proxy config | nginx on the proxy Pi, proxy_pass to pi-main's port |
Unchanged — nginx doesn't know or care which .dll is listening (D-6/NFR-1) |
What actually changes at cutover time (Operations phase, D-7/D-15 — explicitly not this Construction stage or this unit's Code Generation):
- The systemd unit's
ExecStartline:SlpModularCms.Api.dll→SlpModularCms.Api.SlpSoftware.dll - The CI/CD pipeline's publish/artifact step, to build and ship
Api.SlpSoftwareinstead ofApi
Why this matters for Code Generation (this unit, now): SlpModularCms.Api.SlpSoftware must be structurally deployable into this exact same shape without modification — same wwwroot/web symlink convention, same /health endpoint contract, same ASPNETCORE_URLS=http://0.0.0.0:<port> binding pattern, same environment-file-based configuration approach. This is already satisfied by design, since Api.SlpSoftware consumes the same CmsHost composition as Api (Unit 1's own FR-3) — there is nothing extra to build here, only something to avoid accidentally breaking.
No Changes to CI/CD or Gitea Actions Configuration in This Stage
.gitea/workflows/continuous_integration.yaml, deploy-scp.yaml, and the Gitea Actions variables/secrets listed in deployment-instructions.md § 1.9 are not touched by this unit or this Construction phase. That retarget is explicitly Operations-phase scope (D-7, D-15) and belongs to a later stage of this feature, coordinated with the gitea-deployment-workflow feature that owns those files.
Local Development Database (Decision Q1 = B)
Api.SlpSoftware uses its own, isolated local development database, separate from Api's local dev database. Rationale: developing and testing the Offerings module (Unit 2) against Api.SlpSoftware should not risk touching or corrupting whatever local data Api already has, and vice versa.
Implication for Code Generation: Api.SlpSoftware's appsettings.Development.json gets its own ConnectionStrings:DefaultConnection pointing at a distinct local database name (e.g. a SlpModularCmsSlpSoftwareDev-style name — exact naming is a Code Generation Planning detail, not decided here), following the same dotnet-appsettings pattern already used by Api.
Shared Infrastructure
None applicable — single-tenant deployment (per deployment-instructions.md's explicit note that a future second customer would get an entirely separate instance, not shared infrastructure within this one).