slp-modular-cms/aidlc-docs/features/gitea-deployment-workflow/inception/application-design/unit-of-work-dependency.md

Unit of Work Dependencies

---

Dependency Diagram

graph TD
    u1["U1 Hosting and Serving"]
    u2["U2 Data Durability"]
    u3["U3 Security Headers and CSP"]
    u4["U4 Observability"]
    u5["U5 CI Workflow and Gates"]
    u6["U6 Deploy Workflow"]
    u7["U7 Documentation"]
    ops["Operations Phase"]

    u1 -->|"path layout for CSP scoping"| u3
    u4 -->|"Umami and Sentry origins"| u3
    u4 -->|"env-specific Vite variables"| u5
    u1 --> u6
    u2 -->|"durability must precede first deploy"| u6
    u3 --> u5
    u5 -->|"invokes"| u6
    u6 -->|"settled host layout"| u7
    u6 --> ops
    u7 --> ops

    classDef r1 fill:#9ae6b4,stroke:#2f855a,stroke-width:1px,color:#000;
    classDef r2 fill:#90cdf4,stroke:#2b6cb0,stroke-width:1px,color:#000;
    classDef r3 fill:#fbd38d,stroke:#c05621,stroke-width:1px,color:#000;
    classDef r4 fill:#d6bcfa,stroke:#6b46c1,stroke-width:1px,color:#000;
    classDef opsphase fill:#f6e05e,stroke:#c05621,stroke-width:1px,color:#000;
    class u1,u2 r1;
    class u3,u4 r2;
    class u5,u6 r3;
    class u7 r4;
    class ops opsphase;

Text alternative: U1 and U2 are independent and run first; U3 needs U1's path layout and U4's origins; U5 and U6 need the application work complete; U7 needs U6's settled host layout; the Operations phase follows.

---

Dependency Matrix

Unit	Depends on	Depended on by	Nature of dependency
U1 Hosting & Serving	—	U3, U6	Establishes the path layout that U3's CSP scopes against and U6 deploys into
U2 Data Durability	—	U6	Must land before any automated deploy, or the first atomic switch destroys the key ring
U3 Security Headers	U1, U4	U5	Needs U1's final paths and U4's external origins
U4 Observability	—	U3, U5	Introduces the origins U3 must permit and the build variables U5 must supply
U5 CI Workflow	U3, U4	U6	Gates must pass against the finished application; the two builds need U4's variables
U6 Deploy Workflow	U1, U2, U5	U7, Operations	Deploys what the application units produced, invoked by U5
U7 Documentation	U6	Operations	Documents the layout U6 settles

---

Ordering Constraints That Are Load-Bearing

These are not preferences. Reordering any of them produces a broken or dangerous result.

1. U2 before U6 — otherwise the first deploy is the dangerous one

The atomic release switch (U6) changes the content root path on every deploy. Until U2 configures a database-backed key ring with an explicit application discriminator, that switch discards the Data Protection keys and makes every stored slave API key undecryptable. The symptom presents as a network fault between master and slave, so it would be misdiagnosed.

Deploying first and hardening afterwards means the very first production deploy carries the failure.

2. U4 before or with U3 — otherwise the CSP is written blind

U3's Strict policy must permit the Umami script origin and the Sentry ingest origin. Those origins are introduced by U4. Writing U3 first means either guessing them or shipping a CSP that blocks the observability U4 then adds — a failure that appears only in a real browser.

This is why R2 groups them rather than running them in sequence.

3. U1 before U3 — otherwise path scoping is provisional

U3 assigns policies by path prefix. Until U1 settles which paths exist and where they are served from, that assignment is written against a layout still in flux.

4. U3 and U4 before U5 — otherwise the gates fail on incomplete work

U5's six gates run against the whole application. Switching them on before the application units are complete produces failures that reflect unfinished work rather than defects.

5. U5 with U6 — one interface, two files

U6 is a reusable workflow invoked by U5 with a fixed input set. Designing them apart risks an interface mismatch that only surfaces on the first real run.

6. U6 before U7 — documentation cannot precede the layout it documents

U7's website contract states target paths, reserved paths and the persistent-directory arrangement. U6 settles those in its Infrastructure Design.

---

What Is Not Dependent

Worth stating explicitly, because it justifies the grouping:

• U1 and U2 do not touch each other. U1 changes serving and middleware; U2 changes persistence and startup. They share Program.cs as a file, but not as logic — U1 adds pipeline and endpoint registrations, U2 adds service registration and a startup call. A merge conflict is possible; a behavioural conflict is not.
• U4 does not depend on U1, U2 or U3. Observability can be added to the application as it stands today.
• U7 does not depend on U3, U4 or U5 beyond describing their results.

---

Shared Resources and Coordination Points

Resource	Touched by	Coordination needed
SlpModularCms.Api/Program.cs	U1, U2, U3, U4	Four units modify the same file in different places. Registration and pipeline order is specified in services.md § S-01, so each unit inserts at a defined position rather than appending
SlpModularCms.Api.Slave/Program.cs	U1 (health only), U2, U3, U4	Same, minus the static mounts. The Slave is a reference instance (Q2 of Application Design = A) and must keep working; it has no test project, so it is verified by starting it
SlpModularCms.Core	U1, U2, U3, U4	Each unit adds its own subfolder under Hosting/ — Health/, Security/, Observability/ — so files do not collide
AvailabilityModule.cs / MasterModule.cs	U2	Removing AddDataProtection() from both. No other unit touches them
appsettings.json	U2, U3, U4	Three new sections. Additive, no overlap
frontend/	U4 (features), U5 (lint fixes)	U5's lint fixes touch AddCmsInstanceDialog.tsx, InviteUserDialog.tsx, SettingsPage.tsx and SetStatusDialog.tsx; U4 touches main.tsx, config.ts and adds a Umami component. No overlapping files
.gitea/workflows/	U5, U6	Separate files sharing one input contract

---

Consequence of Merging the Quality Gates into U5

Q2 = B moved the lint fixes and package pins from a standalone first unit into U5. This is coherent — gates and their prerequisites land in one commit, so the pipeline is never red on arrival — but it has one side effect worth managing:

pnpm run lint stays failing through U3 and U4, and U4 changes frontend files. New violations introduced during U4 would therefore hide among the five pre-existing ones.

Mitigation: run lint on the changed files during U4 rather than the whole tree. The blocking gate still arrives with U5, but nothing new accumulates in the meantime.

The overlap is limited: U5's fixes and U4's changes touch disjoint files, so there is no merge risk — only a detection gap.

---

Rollback Between Units

Every unit is a self-contained commit on feature/gitea-deployment-workflow, with a single pull request at the end (Q6 = A).

Unit	Revertible independently?	Notes
U1	Yes	Pipeline and endpoint registrations
U2	Yes, with care	The Core migration adds a table; reverting the code leaves the table in place, which is harmless
U3	Yes	Additive middleware plus one config section
U4	Yes	Additive
U5	Yes	New file plus lint and package changes
U6	Yes	New file only
U7	Yes	Documentation only

Nothing is deployed to any environment until U6 is complete and explicitly triggered, so a mid-sequence failure cannot affect a running environment.