# Unit of Work Dependencies — Master CMS Module

## Dependency Matrix

| Unit | Depends On | Reason |
|------|-----------|--------|
| Unit 1 — master-backend | `SlpModularCms.Core` only | No unit dependencies; builds the API contract that others consume |
| Unit 2 — slave-availability-extension | Unit 1 (API contract) | Slave endpoints must match what `ISlaveApiClient` calls; registration endpoint schema defined in Unit 1 |
| Unit 3 — frontend-cms-page | Unit 1 (REST API) | Frontend hooks call `/api/v1/CmsInstances`; endpoint shapes must be finalized |
| Unit 4 — documentation | Units 1, 2, 3 | Documents final patterns after all code is complete |

## Implementation Sequence

```mermaid
graph LR
    U1["Unit 1\nmaster-backend"]
    U2["Unit 2\nslave-availability-extension"]
    U3["Unit 3\nfrontend-cms-page"]
    U4["Unit 4\ndocumentation"]

    U1 --> U2
    U1 --> U3
    U2 --> U4
    U3 --> U4

    classDef unit1 fill:#9ae6b4,stroke:#2f855a,stroke-width:2px,color:#000
    classDef unit2 fill:#63b3ed,stroke:#2b6cb0,stroke-width:2px,color:#000
    classDef unit3 fill:#FFC107,stroke:#F57F17,stroke-width:2px,color:#000
    classDef unit4 fill:#CE93D8,stroke:#6A1B9A,stroke-width:2px,color:#000
    class U1 unit1
    class U2 unit2
    class U3 unit3
    class U4 unit4
```

Text alternative: Unit 1 (master-backend) must complete first; Unit 2 and Unit 3 both depend on Unit 1 and can be worked on in parallel after Unit 1 is done; Unit 4 (documentation) depends on all three.

## Package Change Sequence

```mermaid
graph TD
    Core["SlpModularCms.Core\n(no changes)"]
    MasterMod["SlpModularCms.Modules.Master\nUnit 1 — new project"]
    AvailMod["SlpModularCms.Modules.Availability\nUnit 2 — extended"]
    Api["SlpModularCms.Api\nregisters Master module"]
    Frontend["frontend/\nUnit 3 — /cms page"]
    Docs["README.md\nfrontend/README.md\nUnit 4"]
    MasterTests["SlpModularCms.Modules.Master.Tests\nUnit 1 — new test project"]
    AvailMasterTests["SlpModularCms.Modules.Availability.Master.Tests\nUnit 2 — new test project"]

    Core --> MasterMod
    Core --> AvailMod
    MasterMod --> AvailMod
    MasterMod --> Api
    AvailMod --> Api
    Api --> Frontend
    Frontend --> Docs
    MasterMod --> MasterTests
    AvailMod --> AvailMasterTests

    classDef unchanged fill:#B0BEC5,stroke:#546E7A,stroke-width:1px,color:#000
    classDef unit1 fill:#9ae6b4,stroke:#2f855a,stroke-width:2px,color:#000
    classDef unit2 fill:#63b3ed,stroke:#2b6cb0,stroke-width:2px,color:#000
    classDef unit3 fill:#FFC107,stroke:#F57F17,stroke-width:2px,color:#000
    classDef unit4 fill:#CE93D8,stroke:#6A1B9A,stroke-width:2px,color:#000
    classDef tests fill:#FC8181,stroke:#C53030,stroke-width:1px,color:#000
    class Core,Api unchanged
    class MasterMod unit1
    class AvailMod unit2
    class Frontend unit3
    class Docs unit4
    class MasterTests,AvailMasterTests tests
```

Text alternative: Core unchanged; Unit 1 (Modules.Master) created first; Unit 2 (Availability extended) and Unit 3 (frontend) build on top; Api shell registers new module; Unit 4 docs come last; two new test projects created.

## Inter-Unit API Contracts

The following interfaces form the boundary between units. These must be finalized during Unit 1 before Unit 2 and Unit 3 can proceed.

| Contract | Defined In | Consumed By |
|----------|-----------|-------------|
| `POST /api/internal/master/register` | Unit 2 (slave exposes it) | Unit 1 (`SlaveApiClient` calls it) |
| `GET /api/internal/master/registration` | Unit 2 (slave exposes it) | Unit 1 (`SlaveApiClient` calls it for integrity check) |
| `PUT /api/v1/Availability/admin/status` | Unit 2 (existing, unchanged) | Unit 1 (`SlaveApiClient` reuses it for status push) |
| `GET /api/v1/CmsInstances` | Unit 1 (master exposes it) | Unit 3 (`useCmsInstances` hook) |
| `POST /api/v1/CmsInstances` | Unit 1 (master exposes it) | Unit 3 (`useAddCmsInstance` hook) |
| `PUT /api/v1/CmsInstances/{id}/status` | Unit 1 (master exposes it) | Unit 3 (`useUpdateCmsInstanceStatus` hook) |

## Parallel Development Opportunities

After Unit 1 is complete and its API contracts are finalized:

- **Unit 2 and Unit 3 can be developed in parallel** — they share no direct dependency on each other; both only depend on Unit 1's REST API contract
- **Unit 4** must wait for all three units to be complete

## Risk Notes

| Risk | Unit | Mitigation |
|------|------|-----------|
| Slave endpoint schema changes after Unit 2 starts | 2 | Finalize `ISlaveApiClient` method signatures in Unit 1 before Unit 2 construction begins |
| Frontend type drift from actual API response shape | 3 | Generate TypeScript types from Unit 1 `CmsInstanceDto` definition; keep in sync during code generation |
| Per-module migration pattern new to codebase | 1, 2 | Apply pattern in Unit 1 first; Unit 2 follows the same pattern |