SluijsensandClaude Opus 5
8568ca43c6
Adds the AI-DLC inception record for deploying the CMS as a single .NET application on hosting where no server configuration is possible. The reverse-engineering artifacts were regenerated: the previous set predated the Master module, the Slave host, the solution reorganisation and single-host serving, all of which matter for deployment. Findings were verified by running the build, both test suites and the linter rather than inferred, which surfaced two facts the plan depends on: the frontend lint gate currently fails (5 errors), and two transitive packages carry high-severity advisories. Records 24 functional requirements, 32 traced decisions and a seven-unit decomposition whose ordering is load-bearing: durability work must land before the first automated deploy, or the very first deploy is the one that silently breaks master/slave trust. Two conflicts found while designing and carried into the units: - Both modules call AddDataProtection(), which runs after the host and would override a persistent key store while still passing any registration test. - The availability gate runs before authentication, so its admin bypass cannot read HttpContext.User. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HHoJpxYXzHACSQguHrC5fw
7.9 KiB
Unit of Work Plan — Gitea Deployment Workflow
Stage: INCEPTION — Units Generation (Part 1: Planning)
The execution plan proposed a 7-unit decomposition. This plan confirms or adjusts those boundaries before generating the unit artifacts.
Part 1 — Decomposition Steps
Step 1: Context analysis
- Read
requirements.md(24 FRs, 10 NFRs after FR-24 was added) - Read
execution-plan.md§ 5 (proposed unit sequence) - Read all five Application Design artifacts, including the two composition conflicts
Step 2: Confirm unit boundaries
- Confirm or adjust the proposed 7-unit split — see Questions 1, 2, 3
- Assign every component (C-01…C-16) to exactly one unit
- Assign every functional requirement (FR-01…FR-24) to exactly one unit
- Verify no requirement or component is orphaned or duplicated
Step 3: Establish dependencies and sequencing
- Build the inter-unit dependency matrix
- Confirm the ordering constraints that make the sequence non-arbitrary
- Identify any units that could run in parallel — see Question 4
Step 4: Define per-unit completion criteria
- Define what "done" means per unit — see Question 5
- Assign the two Application Design conflicts to their units
- Assign the remaining open items (OPEN-01, OPEN-03, ASM-01) to their units
Step 5: Version control strategy
- Establish commit and review granularity — see Question 6
Step 6: Mandatory unit artifacts
- Generate
unit-of-work.md— unit definitions and responsibilities - Generate
unit-of-work-dependency.md— dependency matrix - Generate
unit-of-work-story-map.md— requirement-to-unit mapping (see Question 7) - Validate unit boundaries and dependencies
- Ensure all requirements are assigned to units
Part 2 — Decomposition Questions
Vul je keuze in achter elke [Answer]:-tag. Kies de laatste optie (Anders) als niets past.
Question 1 — Klopt de opdeling in 7 units?
Context: dit is de voorgestelde indeling uit het uitvoeringsplan.
| # | Unit | Bevat |
|---|---|---|
| 1 | Quality Gate Prerequisites | 5 lint-fixes, 2 packages pinnen |
| 2 | Hosting Layout & Data Durability | wwwroot/web, /health, auto-migratie, key ring, gate-fix |
| 3 | HTTP Security Headers & CSP | middleware, policies, configuratie |
| 4 | Observability Integration | Sentry backend + frontend, Umami, same-origin config |
| 5 | CI Workflow | continuous_integration.yaml |
| 6 | Deploy Workflow | deploy-scp.yaml, atomaire switch, backup |
| 7 | Repository Documentation | website-contract, README, .env.example |
A) Ja, 7 units zoals voorgesteld B) Minder units — voeg samen wat bij elkaar hoort (zie ook vraag 2 en 3) C) Meer units — unit 2 is te groot en moet gesplitst (zie vraag 3) X) Anders (beschrijf hieronder na de Answer:-tag)
Question 2 — Moet unit 1 een eigen unit zijn?
Context: unit 1 is klein — 5 lint-errors oplossen en 2 packages pinnen. Het staat los van al het andere. De reden om het apart en als eerste te doen: unit 5 zet blokkerende gates aan, en als deze fixes er dan nog niet zijn, is de pipeline meteen rood.
A) Ja, eigen unit en als eerste — de fixes zijn onafhankelijk, en een aparte commit maakt duidelijk wat pre-existente schuld was en wat nieuw werk is B) Voeg samen met unit 5 (CI Workflow) — de fixes bestaan alleen omdat de gates komen, dus hoort het bij elkaar C) Voeg samen met unit 2 — gewoon alle applicatiewijzigingen bij elkaar X) Anders (beschrijf hieronder na de Answer:-tag)
Question 3 — Is unit 2 te groot?
Context: unit 2 bevat vier losse dingen die alleen gemeen hebben dat ze vóór de eerste deploy klaar moeten zijn:
wwwroot/web-herindeling en SPA-fallbacks (FR-07, FR-08)/health-endpoint plus bypass (FR-10)- Automatische Core-migratie (FR-11)
- Data Protection key ring (FR-12) — inclusief het conflict met de dubbele
AddDataProtection() - De gate-fix uit FR-24
Punt 1 gaat over serveren; punt 3 en 4 over dataduurzaamheid; punt 2 en 5 raken dezelfde middleware.
A) Laat unit 2 heel — alles moet toch vóór de eerste deploy klaar zijn, en opsplitsen levert units op die je nooit los oplevert
B) Splits in twee: 2a Hosting & Serving (wwwroot/web, SPA-fallbacks, /health, gate-fix) en 2b Data Durability (auto-migratie, key ring, AddDataProtection-conflict, discriminator)
C) Splits in drie: serveren, health/gate, dataduurzaamheid
X) Anders (beschrijf hieronder na de Answer:-tag)
Question 4 — Volgorde: strikt serieel of waar mogelijk parallel?
Context: sommige units hebben een echte afhankelijkheid (unit 3's CSP heeft de origins uit unit 4 nodig; unit 6 heeft alles nodig). Andere niet: unit 1 en unit 7 staan vrijwel los.
Omdat elke unit een eigen goedkeuringsmoment heeft, is "parallel" hier vooral: mag ik in één ronde meerdere units afronden?
A) Strikt serieel — één unit per keer, elk met een eigen goedkeuring. Meeste controle, meeste rondes B) Serieel waar afhankelijk, gegroepeerd waar onafhankelijk — bijvoorbeeld unit 1 en 2 in één ronde, en 5 en 6 in één ronde C) Groepeer per laag: eerst alle applicatiewijzigingen (1–4), dan alle workflow-werk (5–6), dan documentatie (7) — drie rondes X) Anders (beschrijf hieronder na de Answer:-tag)
Question 5 — Wat betekent "klaar" per unit?
Context: de workflow bouwt en test elke unit automatisch vóór afronding. De vraag is hoe streng dat is.
A) Bouwt en alle bestaande tests slagen — nieuwe tests alleen waar de unit nieuw gedrag toevoegt dat te testen valt B) Zoals A, plus verplicht nieuwe tests voor elk nieuw gedrag, ook als dat een registratietest is C) Zoals B, plus een coverage-drempel per unit (let op: bij vraag 9 van de requirements koos je géén coverage-gate) X) Anders (beschrijf hieronder na de Answer:-tag)
Question 6 — Commit- en reviewstrategie
Context: we werken op feature/gitea-deployment-workflow. Er is nog niets gecommit — alle aidlc-documentatie tot nu toe staat als werkmap-wijziging klaar.
A) Eén commit per unit, alles op deze ene branch, één pull request aan het eind B) Eén commit per unit, en een pull request per unit — kleinere reviews, maar meer PR's C) Vrij committen tijdens het werk, één samengevoegde commit per unit aan het eind (squash) X) Anders (beschrijf hieronder na de Answer:-tag)
Question 7 — Er zijn geen user stories; waar mapt de story map naar?
Context: de User Stories-fase is overgeslagen (infrastructuurwerk zonder eindgebruikersfunctionaliteit). Het artefact unit-of-work-story-map.md is verplicht, maar er zijn geen stories om te mappen.
A) Map de 24 functionele requirements (FR-01…FR-24) naar units — dat is hier het equivalent van stories en geeft volledige dekkingscontrole B) Map zowel de requirements als de 16 ontwerpcomponenten (C-01…C-16) naar units — dubbele controle op volledigheid C) Genereer het bestand met een notitie dat het niet van toepassing is X) Anders (beschrijf hieronder na de Answer:-tag)
Question 8 — Hoort documentatie (unit 7) hier of in de Operations-fase?
Context: unit 7 bevat het website-workspace-contract (FR-09), README-updates en .env.example. De Operations-fase levert daarnaast al deployment-instructies, rollback-plan, monitoring-setup en de readiness-checklist op.
A) Unit 7 blijft in Construction voor repo-documentatie (README, .env.example, website-contract); Operations levert de operationele documenten — duidelijke scheiding tussen "wat in de repo hoort" en "hoe je het draait"
B) Verplaats alles naar de Operations-fase — één plek voor alle documentatie
C) Unit 7 vervalt; verdeel de documentatie over de units die de wijziging maken (README-stuk over wwwroot bij unit 2, enzovoort)
X) Anders (beschrijf hieronder na de Answer:-tag)