Adds 2 units and docs for unit 3. nfr-requirements plan

2026-06-29 22:18:37 +02:00
parent 0e01ca1e1c
commit c156107cb1
126 changed files with 15204 additions and 80199 deletions
@@ -0,0 +1,80 @@
+# 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`