3.3 KiB
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
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
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
Execution Steps
After all questions above are answered, the following artifacts will be generated:
- Step 1 — Analyze all answers; flag any ambiguities
- Step 2 — Generate
unit-of-work.mdwith unit definitions, responsibilities, and construction cycle per unit - Step 3 — Generate
unit-of-work-dependency.mdwith dependency matrix and sequencing - Step 4 — Generate
unit-of-work-story-map.md(requirement-to-unit mapping; no user stories in this feature) - Step 5 — Validate unit boundaries and completeness
- Step 6 — Update
aidlc-state.mdto mark Units Generation as complete - Step 7 — Present completion message for user approval
Artifact path: aidlc-docs/features/master-cms-module/inception/plans/unit-of-work-plan.md