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

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

Workspace Detection — COMPLETED
Reverse Engineering — SKIPPED (shared artifacts already exist in aidlc-docs/_shared/)
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.
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

8.5 KiB Raw Blame History Unescape Escape