# Application Design — Clarification

## Contradiction: Q1 (file-linking) vs Q2 (move into Core)

You answered Q1 with **C** (MSBuild file-linking: keep the `.cs` files physically in one project, link them into the other so there's no new project) and Q2 with **B** (put the code directly into the existing `SlpModularCms.Core` project instead of a new project).

These two answers solve the same problem in different, mutually exclusive ways:
- **C (file-linking)** implies the source files stay in `SlpModularCms.Api` (or wherever) and get *linked* (not copied) into `SlpModularCms.Api.Slave` — two projects compiling the same files, still no single shared assembly.
- **B (move into Core)** means the files move into `SlpModularCms.Core`, which is *already* referenced by every project (both host projects, all modules) — no linking needed at all, because it becomes a normal shared dependency like everything else in Core.

Given your stated goal — "1 buildable project for production, no overhead for testing" — **B fully supersedes C**: moving the three classes (`ModuleOrchestrator`, `ServiceCollectionExtensions`, `ApiPrefixConvention`) into `SlpModularCms.Core` gives you exactly one copy of the code, compiled once, already available to both `SlpModularCms.Api` and `SlpModularCms.Api.Slave` via the existing `Core` reference — no new project, no file-linking, no extra overhead. File-linking would only be needed if you wanted to avoid touching `Core`, which contradicts choosing B.

Checked `SlpModularCms.Core.csproj`: it already has a `FrameworkReference` to `Microsoft.AspNetCore.App` (covers MVC, rate limiting, etc.) and already references `Microsoft.AspNetCore.Authentication.JwtBearer` and `Microsoft.AspNetCore.Identity.EntityFrameworkCore`. Moving the code in would require adding exactly two more package references to `Core`: `Asp.Versioning.Mvc` (for `AddApiVersioning`) and `Microsoft.AspNetCore.OpenApi` (for `AddOpenApi`) — both already used today, just currently referenced at the `Api` project level instead of `Core`.

### Clarification Question 1
Confirm the resolution:

A) Yes — go with **B**: move `ModuleOrchestrator`, `ServiceCollectionExtensions`, and `ApiPrefixConvention` into `SlpModularCms.Core` (namespaces become `SlpModularCms.Core.Hosting.*` or similar). No new project, no file-linking. `Core` gains two package references (`Asp.Versioning.Mvc`, `Microsoft.AspNetCore.OpenApi`) it doesn't currently have. Both `SlpModularCms.Api` and `SlpModularCms.Api.Slave` call the same code via their existing `Core` reference.
B) No — actually use file-linking (**C**) instead, and leave `Core` untouched; the three classes stay physically in `SlpModularCms.Api` and get linked into `SlpModularCms.Api.Slave`'s `.csproj` via `<Compile Include="..." Link="..." />`.
X) Other (please describe after [Answer]: tag below)

[Answer]: A