# Unit of Work Plan — SlpSoftware Production API

Dit plan beschrijft hoe het systeem wordt opgedeeld in units of work voor de Construction-fase. Beantwoord eerst de vragen; na goedkeuring wordt het plan uitgevoerd.

**Al besliste punten, hier niet opnieuw bevraagd** (met onderbouwing waarom een vraag overbodig zou zijn):
- **Volgorde tussen units**: al vastgelegd in `inception/plans/execution-plan.md` (Module Update Strategy) — de Foundation-unit (Core-extractie + `Api.SlpSoftware`-skelet) moet eerst landen en geverifieerd worden tegen `Api`'s bestaande gedrag, vóórdat de Offerings-unit erbovenop gebouwd wordt. Geen nieuwe ambiguïteit sinds die analyse.
- **Wie voegt de project-reference naar `Modules.Offerings` toe aan `Api.SlpSoftware.csproj`**: dit moet de Offerings-unit zelf doen (niet de Foundation-unit), simpelweg omdat die referentie niet kan compileren vóórdat het Offerings-project bestaat. Geen keuzevraag, een logische noodzaak.
- **Teamafstemming (Team Alignment-categorie)**: N/A — dit is een solo-project (jij bent de enige ontwikkelaar/reviewer), er zijn geen team-ownership-grenzen te bepalen.
- **Code-organisatiestrategie (greenfield-only categorie)**: N/A — dit is een brownfield-feature; de mapstructuur ligt al vast via `CLAUDE.md`/`AGENTS.md` (Application/Modules, Tests/Modules, Clients).

## Uitvoeringschecklist

- [x] Stap A — `unit-of-work.md`: unit-definities en verantwoordelijkheden
- [x] Stap B — `unit-of-work-dependency.md`: afhankelijkheidsmatrix tussen units
- [x] Stap C — `unit-of-work-story-map.md`: koppeling van elke user story (US-01..US-12) en relevante FR's aan een unit
- [x] Stap D — Valideren: zijn alle stories toegewezen, kloppen de grenzen met application-design.md?

---

## Vragen

### Vraag 1 — Unit-indeling
Op basis van requirements.md en application-design.md stel ik twee units voor: **Foundation** (`CmsHost`-extractie in Core + het `Api.SlpSoftware`-projectskelet, FR-1/FR-2/FR-3) en **Offerings** (de volledige nieuwe module, FR-4 t/m FR-8, alle 12 user stories). Dit sluit aan bij de Module Update Strategy uit Workflow Planning: Foundation moet eerst en heeft het meeste regressierisico op de bestaande `Api`; Offerings is de nieuwe, op zichzelf staande module.

Welke indeling heeft je voorkeur?

A) Twee units (aanbevolen) — Foundation en Offerings, zoals hierboven beschreven
B) Eén gecombineerde unit — alles in één keer (Core-extractie, nieuw project, nieuwe module) als één ontwerp/codegeneratie-traject
C) Drie units — Foundation opsplitsen in "Core-extractie" en "Api.SlpSoftware-projectskelet" als aparte units
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]: A

### Vraag 2 — Naamgeving van de units
Bij optie A of C hierboven, welke namen passen het best?

A) "Client Hosting Foundation" en "Offerings Module" (technisch, beschrijft wat de unit doet)
B) "SlpSoftware Client Setup" en "Offerings" (korter, gekoppeld aan het eindresultaat)
X) Anders (geef zelf namen op na de [Answer]:-tag)

[Answer]: B

### Vraag 3 — Unit zonder eigen user stories
De Foundation-unit host geen enkele van de 12 user stories rechtstreeks (die horen allemaal bij de Offerings-functionaliteit) — Foundation bestaat puur om FR-1/FR-2/FR-3 (nieuw project + gedeelde hosting-extractie) te realiseren, zonder zichtbaar persona-voordeel op zich.

Is het acceptabel dat een unit in `unit-of-work-story-map.md` geen enkele story toegewezen krijgt (wel FR's), of geef je de voorkeur aan een andere aanpak?

A) Ja, prima — Foundation krijgt FR-1/FR-2/FR-3 toegewezen in de story-map, geen user stories; dat is een geldige, verwachte situatie voor een puur technische enabling-unit
B) Nee — voeg Foundation samen met Offerings tot één unit, zodat elke unit minstens één user story heeft (impliceert antwoord B bij Vraag 1)
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]:A