Files
slp-modular-cms/aidlc-docs/_shared/reverse-engineering/component-inventory.md
T
SluijsensandClaude Opus 5 8568ca43c6 Plans the Gitea deployment feature and refreshes the codebase analysis
Adds the AI-DLC inception record for deploying the CMS as a single .NET
application on hosting where no server configuration is possible.

The reverse-engineering artifacts were regenerated: the previous set
predated the Master module, the Slave host, the solution reorganisation
and single-host serving, all of which matter for deployment. Findings
were verified by running the build, both test suites and the linter
rather than inferred, which surfaced two facts the plan depends on:
the frontend lint gate currently fails (5 errors), and two transitive
packages carry high-severity advisories.

Records 24 functional requirements, 32 traced decisions and a
seven-unit decomposition whose ordering is load-bearing: durability
work must land before the first automated deploy, or the very first
deploy is the one that silently breaks master/slave trust.

Two conflicts found while designing and carried into the units:
- Both modules call AddDataProtection(), which runs after the host and
  would override a persistent key store while still passing any
  registration test.
- The availability gate runs before authentication, so its admin
  bypass cannot read HttpContext.User.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HHoJpxYXzHACSQguHrC5fw
2026-07-27 23:59:30 +02:00

4.0 KiB
Raw Blame History

Component Inventory

Solution folders in SlpModularCms.sln follow the layout mandated by CLAUDE.md / AGENTS.md: Application (with nested Modules), Tests (mirroring Application, also with nested Modules), and Clients (the deployable projects).

Clients (deployable hosts)

  • src/SlpModularCms.Api — The production host. Serves the public website (/), the admin SPA (/admin) and the API (/api/v1) from one process. References Core plus all three modules. Its .csproj builds and embeds the admin SPA on publish.
  • src/SlpModularCms.Api.Slave — Second host used locally to represent an instance without the Master module (Core + Identity + Availability only). Runs on port 7222 against its own database.

Application Packages

  • src/SlpModularCms.Core — Shared foundation: Identity entities and services, hierarchical authorization, IModule + ModuleOrchestrator, ApiPrefixConvention, GlobalExceptionHandler and typed exceptions, the availability contract, SystemController, and ApplicationDbContext with 5 migrations (applied manually only).

Modules (nested under Application)

  • src/SlpModularCms.Modules.Identity — Auth, setup, invitation and user controllers. No persistence of its own.
  • src/SlpModularCms.Modules.Availability — The availability gate: AvailabilityMiddleware, PersistentAvailabilityService, AvailabilityDbContext (MasterRegistration, 5 migrations, self-applied), master registration/status endpoints, MasterStatusPollingBackgroundService with fail-open, Data Protectionencrypted master API key.
  • src/SlpModularCms.Modules.Master — Central control of other instances: MasterDbContext (CmsInstance, 3 migrations, self-applied), Owner-only CmsInstanceController, anonymous SlaveStatusController, SlaveApiClient with retry/timeout resilience, ApiKeyProtector, IntegrityCheckBackgroundService.

Frontend Packages

  • frontend/ — The CMS admin SPA (Vite 8, React 19, TypeScript, TanStack Router/Query, Tailwind v4, shadcn-style components on Radix, react-i18next NL/EN, MSW). Deliberately outside src/ so it stays out of the .NET solution. Built with base: '/admin/' and copied into the API's wwwroot/admin/ at publish time. Not a solution project.

Infrastructure Packages

None. There are no CDK, Terraform, CloudFormation, Docker or Kubernetes artifacts in the repository, and no CI/CD pipeline definitions (.gitea/ does not exist). This is intentional: the deployment target is shared hosting where no server configuration is possible, so the application is designed to need none.

Test Packages

  • src/SlpModularCms.Core.Tests — Unit (7 files): Exceptions, Hosting, Identity.
  • src/SlpModularCms.Modules.Identity.Tests — Unit (4 files): Controllers.
  • src/SlpModularCms.Modules.Availability.Tests — Unit (10 files): Controllers, Services, Repositories, BackgroundServices.
  • src/SlpModularCms.Modules.Master.Tests — Unit (7 files): Controllers, Services, Repositories, BackgroundServices.
  • frontend/src/**/*.test.ts(x) — 34 Vitest files colocated with the code under test, using Testing Library and MSW. Not a separate package.

SlpModularCms.Api.Slave has no test project by design (documented in CLAUDE.md). SlpModularCms.Api has no test project either — its Program.cs is composition only, with a Program.Coverage.cs partial supporting coverage collection.

Total Count

  • Total .NET projects in the solution: 10
  • Clients (deployable): 2 — Api, Api.Slave
  • Application: 4 — Core, Modules.Identity, Modules.Availability, Modules.Master
  • Test: 4 — Core.Tests, Modules.Identity.Tests, Modules.Availability.Tests, Modules.Master.Tests
  • Infrastructure: 0
  • Non-solution packages: 1 — frontend/ (admin SPA)

Approximate Size

  • C# source files (excluding bin/obj): 122
  • Of which EF Core migration files: 13 (5 Core, 5 Availability, 3 Master)
  • TypeScript/TSX files under frontend/src: 111, of which 34 are tests