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
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
3.6 KiB
Application Design — SlpSoftware Production API
Consolidated summary. See the companion documents for full detail:
- components.md — component identification and responsibilities
- component-methods.md — method signatures per component
- services.md — service-layer orchestration patterns
- component-dependency.md — dependency matrix and data-flow diagrams
Design Decisions (traced to application-design-plan.md)
| # | Decision | Source |
|---|---|---|
| AD-1 | CmsHost exposes two granular methods (ConfigureServices, ConfigurePipeline) rather than one all-owning entrypoint — each Client project keeps a visible, thin Program.cs. |
Q1 = B |
| AD-2 | The Offerings module follows the Repository+Service pattern, consistent with Modules.Master, even though the module itself is simple CRUD. |
Q2 = A |
| AD-3 | OfferingsController is a single controller with per-action authorization ([AllowAnonymous] on the public GET, AdminOnly on everything else), not split into two controllers. |
Q3 = B |
| AD-4 | New offerings get a system-generated Guid Id, not an admin-provided slug. |
Q4 = A |
| AD-5 | Deleting an offering is a soft delete (IsDeleted/DeletedAt), filtered out of all reads — a partial, lightweight answer to the SECURITY-13 open item from requirements.md, without introducing a full audit-log mechanism. |
Q5 = B |
Component Overview
8 components: the shared CmsHost composition helper, the new SlpModularCms.Api.SlpSoftware Client project, and 6 components making up SlpModularCms.Modules.Offerings (Offering entity, OfferingsDbContext, IOfferingRepository/OfferingRepository, IOfferingsService/OfferingsService, OfferingsController, OfferingsModule).
Consistency Check Against Requirements and Stories
| Requirement / Story | Covered By |
|---|---|
| FR-1 (new Client project) | SlpModularCms.Api.SlpSoftware component |
| FR-2 (module composition) | Component-dependency.md — project-reference-driven module discovery |
| FR-3 (shared hosting extraction) | CmsHost component + methods |
| FR-4 (new module) | OfferingsModule + all Offerings sub-components |
FR-5 (Offering entity) |
Offering entity component |
| FR-6 (public endpoint) | OfferingsController.GetOfferings, IOfferingsService.GetPublicOfferingsAsync |
| FR-7 (admin CRUD) | OfferingsController admin actions, IOfferingsService Create/Update/Delete/Reorder/MoveUp/MoveDown |
| FR-8 (reference content) | No new component — content stays documented in requirements.md; entered manually by the user through the admin CRUD once built |
| FR-9 (CI/CD retarget) | Out of scope for Application Design — Operations phase |
| US-01/US-02/US-03 | GetPublicOfferingsAsync + OfferingDto shape (featured flag, empty-array-safe) |
| US-04/US-05 | CreateAsync/UpdateAsync |
| US-06/US-07 | DeleteAsync (soft delete, always allowed) |
| US-08 | ReorderAsync |
| US-09 | MoveUpAsync/MoveDownAsync |
| US-10 | Featured-exclusivity orchestration in IOfferingsService (services.md pattern 1) |
| US-11 | Validation is a OfferingsController/request-model concern (SECURITY-05) — detailed in Functional Design |
| US-12 | AdminOnly policy on all mutating actions (AD-3) |
No gaps found: every functional requirement and user story maps to at least one component or method defined above. Detailed business-rule logic (exact exclusivity transaction handling, reorder boundary behavior, field-level validation rules) is intentionally deferred to Functional Design for the Offerings unit, per Application Design's scope.