# Infrastructure Design — Unit: SlpSoftware Client Setup

## Production / Test Infrastructure — No Change Now, Documented Target for the Future Cutover

Sourced directly from `aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md` (the authoritative, existing deploy documentation, owned by that feature):

| Aspect | Current (`Api`) | Target after D-15 cutover (`Api.SlpSoftware`) |
|---|---|---|
| Host | Single Raspberry Pi ("pi-main") | **Same Pi** — no new host |
| TLS termination | Separate "proxy Pi", reverse-proxies to pi-main | **Unchanged** |
| Process manager | `systemd --user`, units `slpsoftware-test.service` / `slpsoftware-production.service` | **Same unit names** — only the `ExecStart` line's `.dll` filename changes |
| Ports | 5100 (test), 5101 (production) | **Unchanged** |
| Database | MariaDB on pi-main, `SlpSoftwareTest` / `SlpSoftwareProduction` | **Unchanged** — same instance, same database names (this is a cutover of which binary runs, not a new environment) |
| Monitoring | Shared Sentry project, distinguished by `Observability__Environment` | **Unchanged** |
| Reverse proxy config | nginx on the proxy Pi, `proxy_pass` to pi-main's port | **Unchanged** — nginx doesn't know or care which `.dll` is listening (D-6/NFR-1) |

**What actually changes at cutover time** (Operations phase, D-7/D-15 — explicitly **not** this Construction stage or this unit's Code Generation):
- The systemd unit's `ExecStart` line: `SlpModularCms.Api.dll` → `SlpModularCms.Api.SlpSoftware.dll`
- The CI/CD pipeline's publish/artifact step, to build and ship `Api.SlpSoftware` instead of `Api`

**Why this matters for Code Generation (this unit, now)**: `SlpModularCms.Api.SlpSoftware` must be structurally deployable into this exact same shape without modification — same `wwwroot/web` symlink convention, same `/health` endpoint contract, same `ASPNETCORE_URLS=http://0.0.0.0:<port>` binding pattern, same environment-file-based configuration approach. This is already satisfied by design, since `Api.SlpSoftware` consumes the same `CmsHost` composition as `Api` (Unit 1's own FR-3) — there is nothing extra to build here, only something to avoid accidentally breaking.

## No Changes to CI/CD or Gitea Actions Configuration in This Stage

`.gitea/workflows/continuous_integration.yaml`, `deploy-scp.yaml`, and the Gitea Actions variables/secrets listed in deployment-instructions.md § 1.9 are **not** touched by this unit or this Construction phase. That retarget is explicitly Operations-phase scope (D-7, D-15) and belongs to a later stage of this feature, coordinated with the `gitea-deployment-workflow` feature that owns those files.

## Local Development Database (Decision Q1 = B)

`Api.SlpSoftware` uses its **own, isolated local development database**, separate from `Api`'s local dev database. Rationale: developing and testing the Offerings module (Unit 2) against `Api.SlpSoftware` should not risk touching or corrupting whatever local data `Api` already has, and vice versa.

**Implication for Code Generation**: `Api.SlpSoftware`'s `appsettings.Development.json` gets its own `ConnectionStrings:DefaultConnection` pointing at a distinct local database name (e.g. a `SlpModularCmsSlpSoftwareDev`-style name — exact naming is a Code Generation Planning detail, not decided here), following the same `dotnet-appsettings` pattern already used by `Api`.

## Shared Infrastructure

None applicable — single-tenant deployment (per deployment-instructions.md's explicit note that a future second customer would get an entirely separate instance, not shared infrastructure within this one).