# Unit of Work Plan — Local Dev Master/Slave Setup

## Plan

- [ ] Generate `unit-of-work.md` with unit definitions and responsibilities
- [ ] Generate `unit-of-work-dependency.md` with dependency matrix between units
- [ ] Generate `unit-of-work-story-map.md` mapping requirements (no user stories exist for this feature — User Stories stage was skipped) to units
- [ ] Validate unit boundaries and dependencies

## Context

No user stories exist for this feature (skipped as pure dev tooling). Units are mapped directly from the Functional Requirements in `requirements.md` and the components in `application-design/`. `SlpModularCms.Api` has no dedicated test project today (it's thin bootstrap code, exercised indirectly via module test suites and manual verification) — the same pattern is expected to apply to `SlpModularCms.Api.Slave`.

## Questions

### Question 1
Confirm the two-unit split proposed in the execution plan:

A) **Unit 1 — Backend dual-instance hosting**: relocate `ModuleOrchestrator`/`ServiceCollectionExtensions`/`ApiPrefixConvention` into `SlpModularCms.Core.Hosting`; add `SlpModularCms.Api.Slave` project (no `Modules.Master` reference); add both projects' `launchSettings.json`/`appsettings*.json`; add to solution. **Unit 2 — Frontend dual-instance tooling & runbook**: `.env.slave.local` support, `dev:slave` npm script, runbook documentation.
B) Different split — describe after [Answer]: tag below.
X) Other (please describe after [Answer]: tag below)

[Answer]: A

### Question 2 (Dependencies)
Unit 2 (frontend) needs a running slave backend to be meaningfully tested against. Should Unit 2 still be generated even though Unit 1 must be functionally verified first?

A) Yes — generate Unit 1 fully (including a working build) before starting Unit 2's code, since Unit 2's manual verification depends on Unit 1 existing and running.
B) Generate both units' code in parallel/independently, verify together at the end during Build and Test.
X) Other (please describe after [Answer]: tag below)

[Answer]: A

### Question 3 (Technical Considerations)
Does `SlpModularCms.Api.Slave` need its own dedicated test project (mirroring `SlpModularCms.Api`, which currently has none)?

A) No — no dedicated test project, consistent with `SlpModularCms.Api` today (thin bootstrap code covered indirectly by module test suites; this feature adds no new business logic to unit test).
B) Yes — add a new `SlpModularCms.Api.Slave.Tests` project.
X) Other (please describe after [Answer]: tag below)

[Answer]: A