# Unit of Work Plan — Master CMS Module

## Overview

The four units are pre-established from the execution plan and confirmed by the Application Design stage. This plan validates the decomposition and generates the formal unit artifacts.

**Pre-established units:**

| # | Unit | Scope | Depends On |
|---|------|-------|------------|
| 1 | `master-backend` | New `SlpModularCms.Modules.Master` project | Core |
| 2 | `slave-availability-extension` | Extended `SlpModularCms.Modules.Availability` | Unit 1 (API contract + ISlaveApiClient) |
| 3 | `frontend-cms-page` | `/cms` page in `frontend/` | Unit 1 (REST API endpoints) |
| 4 | `documentation` | README updates | Units 1–3 (documents final patterns) |

---

## Decomposition Questions

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

---

### Q1 — Construction Cycle for Unit 4 (Documentation)

Unit 4 covers README.md updates — no new code, entities, or services. How should it be handled in the Construction phase?

A) **Full cycle** — run Functional Design, NFR Requirements, NFR Design, and Code Generation for Unit 4 as for the other units. Consistent process; documentation gets explicit design attention.

B) **Code Generation only** — skip Functional Design, NFR Requirements, and NFR Design for Unit 4; go straight to Code Generation (which in this case means drafting the README content). More efficient for a documentation-only unit.

C) Other

[Answer]: B

---

### Q2 — Test Project for Unit 1

Unit 1 adds `SlpModularCms.Modules.Master` — a new project. How should tests be organized?

A) **New `SlpModularCms.Modules.Master.Tests` project** — separate test project for the new module, parallel to the existing `SlpModularCms.Modules.Availability.Tests`. Clean isolation; follows existing pattern.

B) **Single shared test project** — add master module tests to an existing test project to avoid creating a new project.

C) Other

[Answer]: A

---

### Q3 — Test Project for Unit 2

Unit 2 extends `SlpModularCms.Modules.Availability`. How should new slave-side tests be organized?

A) **Extend existing `SlpModularCms.Modules.Availability.Tests`** — add new test files for `MasterAvailabilityService`, extended `AvailabilityMiddleware`, and `AvailabilityController` registration endpoint. Minimal new project overhead.

B) **New `SlpModularCms.Modules.Availability.Master.Tests`** — separate test project for the master-related slave-side extensions. Cleaner isolation for cross-unit changes.

C) Other

[Answer]: B

---

## Execution Steps

After all questions above are answered, the following artifacts will be generated:

- [x] **Step 1** — Analyze all answers; flag any ambiguities
- [x] **Step 2** — Generate `unit-of-work.md` with unit definitions, responsibilities, and construction cycle per unit
- [x] **Step 3** — Generate `unit-of-work-dependency.md` with dependency matrix and sequencing
- [x] **Step 4** — Generate `unit-of-work-story-map.md` (requirement-to-unit mapping; no user stories in this feature)
- [x] **Step 5** — Validate unit boundaries and completeness
- [x] **Step 6** — Update `aidlc-state.md` to mark Units Generation as complete
- [x] **Step 7** — Present completion message for user approval

---

*Artifact path*: `aidlc-docs/features/master-cms-module/inception/plans/unit-of-work-plan.md`