# Requirements Clarification Questions — Local Dev Master/Slave Setup

Context found while investigating the codebase: `SlpModularCms.Api` discovers modules by scanning its own build output folder for `SlpModularCms.Modules.*.dll` (`ModuleOrchestrator.DiscoverModules`) and loads every module DLL it finds — there is currently no config-driven way to load the API without `SlpModularCms.Modules.Master`. To run a "slave-only" instance locally, `ModuleOrchestrator` needs a small change: skip registering/activating a module if it's named in a new config setting (e.g. `Modules:Disabled`), so the same build output can serve both an instance with the Master module active and one without.

Please answer each question below by filling in your choice after the `[Answer]:` tag.

## Question 1
How should the "master" vs "slave" instance be toggled?

A) Config-driven module disable list read from `appsettings`/`appsettings.local.json` (e.g. `"Modules": { "Disabled": ["Master"] }`), checked by `ModuleOrchestrator` before registering/activating a module. One shared build; two different config files/launch profiles select the mode.
B) Separate ASP.NET Core launch profiles only, no code change — accepting that both profiles will always load the Master module since it's a project reference (this would NOT actually give you a Master-less slave).
C) A separate host project (`SlpModularCms.Api.Slave`) with its own `.csproj` that simply omits the `SlpModularCms.Modules.Master` project reference.
X) Other (please describe after [Answer]: tag below)

[Answer]: X, For testing purposes a separate project will suffice, but when building the production builds later I want to be able to build the base version of the API and add the modules as DLL-files. Can we make that happen here as well? 

## Question 2
Should the master and slave instance use separate local databases (so slave-side data like registrations/users doesn't collide with master-side data)?

A) Yes — separate connection strings/database names (e.g. `SlpModularCmsLocal_Master` and `SlpModularCmsLocal_Slave`), same SQL Server instance, via `appsettings.local.json` per profile.
B) No — both instances share the exact same local database.
C) Use SQLite per instance instead of SQL Server, to make the setup fully self-contained without a shared SQL Server.
X) Other (please describe after [Answer]: tag below)

[Answer]: A

## Question 3
Which ports should the two instances use?

A) Master keeps the existing ports (`http://localhost:5284`, `https://localhost:7221`); slave gets a new pair (`http://localhost:5285`, `https://localhost:7222`).
B) Let me specify custom ports (describe after [Answer]: tag below).
X) Other (please describe after [Answer]: tag below)

[Answer]: A

## Question 4
How do you want to start both instances locally?

A) Two named `dotnet run --launch-profile <name>` invocations (one per terminal) — profiles added to the existing `SlpModularCms.Api/Properties/launchSettings.json`.
B) A helper script (e.g. PowerShell) that launches both in the background with one command.
C) Both A and B — launch profiles for IDE debugging (e.g. Rider/VS "Multiple startup projects" or `dotnet run`), plus a convenience script for quick CLI use.
X) Other (please describe after [Answer]: tag below)

[Answer]: A

## Question 5
Should the frontend (React app) also be runnable against the slave instance, or is the slave purely a backend API target (no need to browse it via the CMS frontend)?

A) Backend-only — slave just needs to be reachable over HTTP for the master-to-slave connection (registration + polling/push); Scalar/OpenAPI at the slave's own URL is enough to poke it manually if needed.
B) The frontend should also be runnable against the slave (e.g. via a `.env.slave` or a second Vite dev server config), so its admin UI is separately reachable too.
X) Other (please describe after [Answer]: tag below)

[Answer]: B

## Question 6
Once both instances are running, do you want a documented/scripted way to actually register the slave under the master (so the "connection" is set up end-to-end), or is wiring that up manually through the existing "Add CMS Instance" UI flow sufficient?

A) Manual is fine — document the steps (start both, open master frontend, use the existing Add CMS Instance dialog with the slave's local URL) in a short README/runbook.
B) Provide a scripted/seeded way (e.g. a dev-only endpoint or seed data) to pre-register the slave automatically on startup, skipping the manual UI step.
X) Other (please describe after [Answer]: tag below)

[Answer]: A, because I want to test the functionality of the "Add CMS Instance" UI flow.