Files
slp-modular-cms/aidlc-docs/features/slpsoftware-api/inception/application-design/unit-of-work-dependency.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.0 KiB

Unit of Work Dependency — SlpSoftware Production API

Dependency Matrix

Unit Depends On Nature of Dependency Blocking?
1. SlpSoftware Client Setup Existing SlpModularCms.Api (must not regress), existing Core.Hosting.* extension methods Behavior-preservation constraint: the extraction must reproduce Api's current pipeline exactly N/A (this unit is the starting point)
2. Offerings Unit 1 (SlpModularCms.Api.SlpSoftware project must exist) Structural: Unit 2 adds its own <ProjectReference> into Api.SlpSoftware.csproj, which requires that project to already exist Yes — Unit 2 cannot start its Code Generation until Unit 1's Api.SlpSoftware project shell exists

Sequencing

graph LR
    U1["Unit 1: SlpSoftware Client Setup<br/>(FR-1, FR-2, FR-3)"]
    U2["Unit 2: Offerings<br/>(FR-4..FR-8, US-01..US-12)"]
    U1 -->|"Api.SlpSoftware project must exist first"| U2

    classDef foundation fill:#63b3ed,stroke:#2b6cb0,stroke-width:1px,color:#000;
    classDef feature fill:#f6e05e,stroke:#c05621,stroke-width:1px,color:#000;

    class U1 foundation;
    class U2 feature;

Text alternative: Unit 1 (SlpSoftware Client Setup, blue) must complete before Unit 2 (Offerings, yellow) can start, because Unit 2's project reference requires Unit 1's Api.SlpSoftware project to already exist.

Shared / Cross-Cutting Concerns

  • SlpModularCms.Core: modified only by Unit 1 (the CmsHost addition). Unit 2 does not modify Core.
  • Security Baseline compliance: both units must satisfy their applicable rules from requirements.md's Security Compliance table independently — Unit 1 for the hosting/pipeline rules (SECURITY-03, 04, 09, 10, 14, 15 continuity), Unit 2 for the new-surface rules (SECURITY-05, 06, 08, 11, 13).
  • No shared mutable state or runtime coupling between the two units beyond the one-time structural dependency above — at runtime, Offerings is just another module discovered by ModuleOrchestrator inside the process Unit 1 built.