# Unit of Work — Local Dev Master/Slave Setup

## Unit 1 — Backend Dual-Instance Hosting

**Responsibility**: Make it possible to run a Master-less slave backend locally alongside the existing master backend, on separate ports and databases, without duplicating bootstrap code.

**Scope**:
- Relocate `ModuleOrchestrator`, `ServiceCollectionExtensions`, `ApiPrefixConvention` from `SlpModularCms.Api` into `SlpModularCms.Core` (new `SlpModularCms.Core.Hosting` namespace); add `Asp.Versioning.Mvc` and `Microsoft.AspNetCore.OpenApi` package references to `Core`.
- Update `SlpModularCms.Api/Program.cs` to use the relocated classes (no behavior change); delete the old files from `SlpModularCms.Api`.
- Add new `SlpModularCms.Api.Slave` project: references `Core`, `Modules.Availability`, `Modules.Identity` (no `Modules.Master`); own `Program.cs` mirroring `SlpModularCms.Api`'s bootstrap.
- Add `SlpModularCms.Api.Slave`'s `appsettings.json` / `appsettings.Development.json` / `appsettings.local.json` (gitignored) with its own `ConnectionStrings:DefaultConnection` (separate database) and `Cors:AllowedOrigins`.
- Add `SlpModularCms.Api.Slave/Properties/launchSettings.json` with profiles on port 5285 (HTTP) / 7222 (HTTPS).
- Add `SlpModularCms.Api.Slave.csproj` to the solution file.
- No dedicated test project (Q3 = A) — mirrors `SlpModularCms.Api`'s current pattern.

**Depends On**: Application Design decisions (already approved).

**Completion Criteria**: Both `SlpModularCms.Api` (master) and `SlpModularCms.Api.Slave` build and start successfully via `dotnet run --launch-profile <name>`; existing test suites (`Modules.Master.Tests`, `Modules.Availability.Tests`, `Modules.Identity.Tests`, `Core.Tests`) still pass unchanged; the slave instance's Scalar/OpenAPI page loads and shows no Master-related endpoints.

## Unit 2 — Frontend Dual-Instance Tooling & Runbook

**Responsibility**: Let the existing frontend point at either the master or slave backend, and document the manual workflow for connecting them.

**Scope**:
- Add `.env.slave.local` (gitignored, mirrors `.env.local`) with `VITE_API_BASE_URL=https://localhost:7222`.
- Update `.env.example` to document both `.env.local` (master) and `.env.slave.local` (slave) modes.
- Add an npm script `dev:slave` (e.g. `vite --mode slave --port 5174`) to `frontend/package.json`; introduce a `.env.slave` (non-local, checked-in) mode file if needed for Vite's mode-based env loading, or rely on `--mode slave` reading `.env.slave.local`.
- Add a runbook section (in `frontend/README.md` and/or a new `docs/local-master-slave-setup.md` referenced from the root README) with step-by-step instructions: start master backend, start slave backend, start master frontend, (optionally) start slave frontend, use the existing "Add CMS Instance" dialog to register the local slave, confirm connected status.

**Depends On**: Unit 1 must be complete and verified working (Q2 = A) — the runbook's steps assume a working slave backend to point at and to actually exercise end-to-end.

**Completion Criteria**: Frontend can be started against either instance via the documented commands; the runbook has been manually followed once to confirm the "Add CMS Instance" flow successfully connects the local master to the local slave.

## Sequencing

Unit 1 → Unit 2 (strictly sequential; Unit 2's runbook and manual verification require Unit 1's working slave backend).