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
3.6 KiB
🔍 Feature Resolution
Ik vond een bestaande AI-DLC workspace met de volgende features:
| # | Feature | Status | Branch |
|---|---|---|---|
| 1 | SlpModularCms.Api Implementation (slp-modular-cms-api) |
✅ Complete | unknown |
| 2 | CMS Frontend (cms-frontend) |
✅ Complete | unknown |
| 3 | Master CMS Module (master-cms-module) |
✅ Complete | unknown |
| 4 | Tech Debt Backlog (tech-debt-backlog) |
🔵 Inception | unknown |
| 5 | Local Dev Master/Slave Setup (local-dev-master-slave-setup) |
✅ Complete | unknown |
Jouw verzoek (Gitea deployment-workflow voor de CMS, met omgevingen lokaal/test/productie, UptimeRobot + Umami + Sentry, en instructies over waar de publieke website-frontend komt) matcht geen van de bestaande features — dit lijkt nieuw werk.
Question 1
Wil je hiervoor een nieuwe feature starten of aansluiten op een bestaande?
A) Start een NIEUWE feature: gitea-deployment-workflow
B) Voortzetten op bestaande feature tech-debt-backlog (nog in Inception)
C) Voortzetten op een andere bestaande feature (geef het nummer)
X) Anders (beschrijf hieronder na de Answer:-tag)
Answer: A, maak ook een nieuwe feature-branch aan voor deze feature.
Question 2
Taalvoorkeur voor deze feature.
Alle documentatie-artefacten (requirements, designs, plannen, code-commentaar) worden standaard in Engels geschreven. Vragen, prompts en mijn antwoorden zijn in jouw taal (Nederlands).
Wil je dit wijzigen?
A) Engels voor documentatie, Nederlands voor de conversatie (standaard) B) Engels voor alles (documentatie en conversatie) C) Nederlands voor alles (documentatie en conversatie) X) Anders (beschrijf hieronder na de Answer:-tag)
Question 3
De reverse-engineering-artefacten in aidlc-docs/_shared/reverse-engineering/ zijn van 2026-06-16, maar de codebase is daarna significant gewijzigd — en juist op punten die voor deployment relevant zijn:
- Master CMS Module toegevoegd (eigen
DbContext/migraties, Data Protection key ring) SlpModularCms.Api.Slaveproject toegevoegd- Solution gereorganiseerd in Solution Folders (Application / Tests / Clients)
- Single-host serving (commit
3885703): één .NET-proces serveert/(publieke website),/admin(admin SPA) en/api/v1— dit is precies het deployment-model waar deze feature over gaat
Hoe wil je hiermee omgaan?
A) Doelgerichte refresh — werk alleen architecture.md, code-structure.md en technology-stack.md bij op de deployment-relevante punten (sneller, voldoende voor deze feature)
B) Volledige reverse engineering opnieuw uitvoeren — alle 8 artefacten van de hele codebase verversen (grondig, kost meer tijd)
C) Overslaan — gebruik de bestaande artefacten plus mijn eigen actuele analyse van de repo, en laat _shared/ ongewijzigd
X) Anders (beschrijf hieronder na de Answer:-tag)
Question 4
Ter verduidelijking van de scope van de publieke website. Uit de README begrijp ik dat de publieke website van de klant niet in deze repo zit en los in wwwroot/ wordt geplaatst. Wat moet deze feature daarover opleveren?
A) Alleen documentatie/instructies — waar de website-build terechtkomt, hoe die naast wwwroot/admin/ bestaat, en wat een website-workspace moet aanleveren; de website-workflow zelf blijft buiten scope
B) Documentatie + een reusable/callable Gitea-workflow in déze repo die een website-workspace kan aanroepen om zijn build te deployen (contract vastleggen, maar de website bouwt hij niet zelf)
C) Documentatie + een placeholder/voorbeeld-website in wwwroot/ zodat een verse deploy niet leeg is
X) Anders (beschrijf hieronder na de Answer:-tag)