# Infrastructure Design Plan — Unit: SlpSoftware Client Setup

Voordat ik vragen stelde, heb ik `aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md` (de bestaande, gedetailleerde deploy-documentatie van de feature die de huidige pipeline bezit) volledig gelezen. Dat geeft keihard bewijs voor bijna elke categorie hieronder — vandaar dat er maar één echte vraag overblijft.

## Al opgelost via bestaand bewijs (geen vraag nodig)

- **Deployment Environment / Compute**: één Raspberry Pi ("pi-main"), test en productie gescheiden per directory/systemd-unit/poort (5100/5101). Een aparte proxy-Pi regelt TLS-terminatie. Dit verandert niet door deze feature — D-15 is een **cutover**, geen nieuwe, aparte deploy-slot. Zodra de Operations-fase de pipeline omzet, draait `Api.SlpSoftware` **op precies dezelfde plek** als `Api` nu draait: zelfde Pi, zelfde systemd-unitnamen (`slpsoftware-test.service`/`slpsoftware-production.service`), zelfde poorten, zelfde domeinen. Het enige wat verandert is de ExecStart-regel (`SlpModularCms.Api.dll` → `SlpModularCms.Api.SlpSoftware.dll`) en het CI-publish-artefact — en dat is expliciet Operations-werk (D-7), niet iets wat deze Construction-stage of deze unit's Code Generation al hoeft aan te passen.
- **Networking**: geen nginx-wijziging nodig (al vastgelegd als D-6/NFR-1) — de bestaande proxy-Pi-configuratie blijft ongewijzigd, hij proxied gewoon naar dezelfde poort, ongeacht welke `.dll` daar luistert.
- **Storage (productie/test)**: zelfde MariaDB-instantie op pi-main, zelfde databasenamen (`SlpSoftwareTest`/`SlpSoftwareProduction`) — logisch gevolg van "cutover, geen nieuwe aparte app".
- **Monitoring**: zelfde Sentry-project/DSN, onderscheiden via de bestaande `Observability__Environment`-tag — geen wijziging nodig.
- **Shared Infrastructure/multi-tenancy**: N/A — single-tenant deployment, geen wijziging.
- **Geen wijzigingen aan `.gitea/workflows/*.yaml` of Gitea Actions-variabelen in deze stage** — dat is expliciet Operations-fase-werk (D-7/D-15). Deze stage documenteert alleen de doelvorm, zodat Code Generation niets bouwt wat daar niet in past.

## Uitvoeringschecklist

- [x] Stap A — `infrastructure-design.md`: bovenstaande bevindingen + antwoord op Vraag 1 vastleggen
- [x] Stap B — `deployment-architecture.md`: doelarchitectuur voor `Api.SlpSoftware` na de toekomstige cutover (referentie, geen wijziging nu)

---

## Vragen

### Vraag 1 — Lokale ontwikkeldatabase voor `Api.SlpSoftware`
Voor productie/test is de databasekeuze al duidelijk (hierboven). Voor **lokale ontwikkeling** (jouw eigen machine) is dat nog niet vastgelegd: moet `Api.SlpSoftware` lokaal dezelfde database gebruiken als `Api` vandaag, of een eigen, aparte lokale database?

A) Dezelfde lokale database als `Api` — handig als je makkelijk wilt wisselen tussen beide projecten met dezelfde testdata; risico op onderlinge beïnvloeding tijdens ontwikkeling van de Offerings-module (Unit 2)
B) Eigen, aparte lokale database voor `Api.SlpSoftware` — geïsoleerde ontwikkelomgeving, geen kans dat het testen van de Offerings-module `Api`'s lokale data raakt; wel een aparte lokale database aanmaken
X) Anders (beschrijf hieronder na de [Answer]:-tag)

[Answer]:B