161 lines
8.5 KiB
Markdown
161 lines
8.5 KiB
Markdown
# Execution Plan — Master CMS Module
|
||
|
||
## Detailed Analysis Summary
|
||
|
||
### Transformation Scope
|
||
- **Transformation Type**: Multi-component addition — new module + slave-side middleware extension + frontend page + documentation
|
||
- **Primary Changes**: New `SlpModularCms.Modules.Master` project; extended `SlpModularCms.Modules.Availability`; updated `/cms` frontend page
|
||
- **Related Components**: Core (new entity), Api shell (module registration), Availability module (middleware extension), Frontend (CMS page)
|
||
|
||
### Change Impact Assessment
|
||
- **User-facing changes**: Yes — `/cms` page gets a full slave management UI; slave CMS users see a disable message on 503
|
||
- **Structural changes**: Yes — new module project, per-module DbContext pattern introduced
|
||
- **Data model changes**: Yes — new `CmsInstance` entity (master), new `MasterRegistration` entity (slave)
|
||
- **API changes**: Yes — new Master module endpoints; new internal slave registration endpoint; extended 503 response body
|
||
- **NFR impact**: Yes — API key security, availability caching strategy, background service, fail-open design
|
||
|
||
### Component Relationships
|
||
|
||
**Primary new component**: `SlpModularCms.Modules.Master`
|
||
- Depends on: `SlpModularCms.Core` (shared DbContext base, IModule), `SlpModularCms.Api` (module registration)
|
||
|
||
**Modified component**: `SlpModularCms.Modules.Availability`
|
||
- Extended with: master registration endpoint, two-phase availability check, `MasterAvailabilityService`, slave-side `MasterDbContext`
|
||
- Depends on: `SlpModularCms.Core`
|
||
|
||
**Modified component**: `SlpModularCms.Frontend`
|
||
- Extended with: CMS page slave management UI, new TanStack Query hooks, new API types
|
||
|
||
### Risk Assessment
|
||
- **Risk Level**: Medium-High
|
||
- **Rollback Complexity**: Moderate — new module can be unregistered from Api; slave-side changes are additive; frontend changes are isolated to one route
|
||
- **Testing Complexity**: Complex — involves network calls between Master and Slave, background service timing, cache behavior, fallback logic
|
||
|
||
---
|
||
|
||
## Workflow Visualization
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
Start(["Master CMS Module Request"])
|
||
|
||
subgraph INCEPTION["🔵 INCEPTION PHASE"]
|
||
WD["Workspace Detection\nCOMPLETED"]
|
||
RE["Reverse Engineering\nSKIPPED (artifacts exist)"]
|
||
RA["Requirements Analysis\nCOMPLETED"]
|
||
US["User Stories\nSKIPPED"]
|
||
WP["Workflow Planning\nIN PROGRESS"]
|
||
AD["Application Design\nEXECUTE"]
|
||
UG["Units Generation\nEXECUTE"]
|
||
end
|
||
|
||
subgraph CONSTRUCTION["🟢 CONSTRUCTION PHASE — Per Unit"]
|
||
FD["Functional Design\nEXECUTE"]
|
||
NFRA["NFR Requirements\nEXECUTE"]
|
||
NFRD["NFR Design\nEXECUTE"]
|
||
ID["Infrastructure Design\nSKIPPED"]
|
||
CG["Code Generation\nEXECUTE"]
|
||
BT["Build and Test\nEXECUTE"]
|
||
end
|
||
|
||
subgraph OPERATIONS["🟡 OPERATIONS PHASE"]
|
||
OPS["Operations\nPLACEHOLDER"]
|
||
end
|
||
|
||
Start --> WD --> RA --> WP --> AD --> UG
|
||
UG --> FD --> NFRA --> NFRD --> CG
|
||
ID -.->|skipped| CG
|
||
CG -->|repeat per unit| FD
|
||
CG --> BT --> OPS --> End(["Complete"])
|
||
|
||
style WD fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||
style RA fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||
style WP fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||
style CG fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||
style BT fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||
style RE fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray:5 5,color:#000
|
||
style US fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray:5 5,color:#000
|
||
style ID fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray:5 5,color:#000
|
||
style AD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray:5 5,color:#000
|
||
style UG fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray:5 5,color:#000
|
||
style FD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray:5 5,color:#000
|
||
style NFRA fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray:5 5,color:#000
|
||
style NFRD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray:5 5,color:#000
|
||
style OPS fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray:5 5,color:#000
|
||
style Start fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
|
||
style End fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
|
||
style INCEPTION fill:#BBDEFB,stroke:#1565C0,stroke-width:3px,color:#000
|
||
style CONSTRUCTION fill:#C8E6C9,stroke:#2E7D32,stroke-width:3px,color:#000
|
||
style OPERATIONS fill:#FFF59D,stroke:#F57F17,stroke-width:3px,color:#000
|
||
linkStyle default stroke:#333,stroke-width:2px
|
||
```
|
||
|
||
Text alternative: Inception (WD→RA→WP→AD→UG completed/executing), Construction per-unit loop (FD→NFR Req→NFR Design→CodeGen, Infrastructure skipped), Build & Test, Operations placeholder.
|
||
|
||
---
|
||
|
||
## Phases to Execute
|
||
|
||
### 🔵 INCEPTION PHASE
|
||
- [x] Workspace Detection — COMPLETED
|
||
- [x] Reverse Engineering — SKIPPED (shared artifacts already exist in `aidlc-docs/_shared/`)
|
||
- [x] Requirements Analysis — COMPLETED
|
||
- [ ] User Stories — **SKIP**
|
||
- *Rationale*: Feature is owner-operated and technical in nature. Requirements are clear and detailed. No multiple personas or acceptance criteria gaps.
|
||
- [x] Workflow Planning — IN PROGRESS
|
||
- [ ] Application Design — **EXECUTE**
|
||
- *Rationale*: New module project, new services, new controller, background service, new frontend components — all need component definition and dependency mapping before code generation.
|
||
- [ ] Units Generation — **EXECUTE**
|
||
- *Rationale*: 4 distinct units spanning backend (master), backend (slave extension), frontend, and documentation. Sequencing and dependencies must be planned.
|
||
|
||
### 🟢 CONSTRUCTION PHASE (per unit)
|
||
- [ ] Functional Design — **EXECUTE**
|
||
- *Rationale*: Complex business logic per unit (registration handshake, two-phase middleware, background integrity check, cache + fallback)
|
||
- [ ] NFR Requirements — **EXECUTE**
|
||
- *Rationale*: New security concerns (API key handling), caching strategy, fail-open requirements, test coverage targets
|
||
- [ ] NFR Design — **EXECUTE**
|
||
- *Rationale*: Design patterns for background service, per-module DbContext, middleware extension, client-side caching
|
||
- [ ] Infrastructure Design — **SKIP**
|
||
- *Rationale*: No new cloud/infrastructure resources. Same deployment model (single .NET process + React SPA). Module registration is code-level, not infrastructure-level.
|
||
- [ ] Code Generation — **EXECUTE** (always)
|
||
- [ ] Build and Test — **EXECUTE** (always)
|
||
|
||
### 🟡 OPERATIONS PHASE
|
||
- [ ] Operations — PLACEHOLDER
|
||
|
||
---
|
||
|
||
## Unit Decomposition (Proposed)
|
||
|
||
| # | Unit Name | Scope | Depends On |
|
||
|---|-----------|-------|------------|
|
||
| 1 | master-backend | New `SlpModularCms.Modules.Master` project: `CmsInstance` entity, `MasterDbContext`, migrations, `CmsInstanceService`, `MasterController`, `IntegrityCheckBackgroundService`, `MasterModule : IModule`, test project | Core |
|
||
| 2 | slave-availability-extension | Extended `SlpModularCms.Modules.Availability`: `MasterRegistration` entity, slave `MasterDbContext`, migrations, `MasterAvailabilityService` (pull/cache/fallback), registration endpoint, two-phase `AvailabilityMiddleware` | Unit 1 (API contract) |
|
||
| 3 | frontend-cms-page | `/cms` page: `CmsInstanceList`, `AddCmsInstanceDialog`, `SetStatusDialog`, new TanStack Query hooks, API types | Unit 1 (REST API) |
|
||
| 4 | documentation | Update `README.md` (migrations section, module guide, prod env vars), replace `frontend/README.md` | Units 1–3 (documents final patterns) |
|
||
|
||
---
|
||
|
||
## Package Change Sequence
|
||
|
||
```
|
||
SlpModularCms.Core ← no changes (CmsInstance owned by Modules.Master)
|
||
↓
|
||
SlpModularCms.Modules.Master [Unit 1] ← new project
|
||
↓
|
||
SlpModularCms.Modules.Availability [Unit 2] ← extended
|
||
↓
|
||
SlpModularCms.Api ← registers new Master module
|
||
↓
|
||
frontend/ [Unit 3] ← CMS page updated
|
||
↓
|
||
README.md / frontend/README.md [Unit 4] ← documentation
|
||
```
|
||
|
||
---
|
||
|
||
## Success Criteria
|
||
- **Primary Goal**: Owner on the Master CMS can register slave CMSes and toggle their availability; slaves enforce the master-controlled status with a two-phase check
|
||
- **Key Deliverables**: `SlpModularCms.Modules.Master` project, extended Availability module, updated `/cms` frontend page, updated documentation
|
||
- **Quality Gates**: ≥80% test coverage on new backend code; fail-open behavior verified; API key not exposed in list responses; two-phase middleware verified for all status combinations
|