# Deployment Setup — slpsoftware-api (D-15 Cutover)

This feature does not own a separate deployment pipeline. Per D-7, its Operations phase **extends**
the pipeline owned by `gitea-deployment-workflow` rather than duplicating it. Full instructions
(host setup, systemd units, TLS, Gitea variables, database backup, rollback) remain at:

- `aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md`
- `aidlc-docs/features/gitea-deployment-workflow/operations/deployment/rollback-plan.md`

## What This Feature Changed

Per D-15 (cutover, not side-by-side): `SlpModularCms.Api.SlpSoftware` replaces `SlpModularCms.Api`
as the artifact built, tested, and deployed to `test.slpsoftware.nl` / `slpsoftware.nl`.

| File | Change |
|---|---|
| `.gitea/workflows/continuous_integration.yaml` | `publish-test`/`publish-production`'s "Build admin frontend" and "Publish" steps retargeted from `src/SlpModularCms.Api` to `src/SlpModularCms.Api.SlpSoftware` (6 lines). Everything else — the six CI gates, `deploy-scp.yaml` calls, Gitea variables/secrets, `SlpModularCms.Api.Tests` (Unit 1's own regression suite, scoped to `Api` per NFR-CS-01) — is unchanged. |
| `deploy-scp.yaml` | **No change.** It never hardcodes an entry-point `.dll` name; it uploads whatever the artifact contains and restarts a `service_name` input string. |
| `gitea-deployment-workflow/operations/deployment/deployment-instructions.md` § 1.6 | systemd unit `ExecStart` documentation updated to `SlpModularCms.Api.SlpSoftware.dll`, with an explicit note that this is a manual, host-side edit for already-existing units — this session cannot reach the Pi to apply it. |
| `rollback-plan.md` | **No change.** Operates on the release-directory/symlink level, not a specific `.dll` name. |
| nginx (proxy Pi) | **No change** (D-6) — the proxy forwards to a port, not a named executable. |
| Database, Gitea Actions variables/secrets | **No change** — same customer, same domain, same paths, same service names. |

## Action Required From You

The Pi's `slpsoftware-test.service`/`slpsoftware-production.service` unit files (created during the
original `gitea-deployment-workflow` setup) still point at `SlpModularCms.Api.dll`. **Edit both by
hand** on the Pi (see the updated § 1.6 above for the exact `ExecStart` line and login-shell caveat),
then `systemctl --user daemon-reload` and restart both services — the CI pipeline deploys the new
`SlpModularCms.Api.SlpSoftware` build correctly starting with the next run regardless, but the
*existing* systemd unit will keep launching the old `SlpModularCms.Api.dll` from that release
directory until you make this edit.

`SlpModularCms.Api` itself is not removed from the repository or decommissioned (D-8) — it remains
the local development host, same role as `Api.Slave` today. Only its production/test deployment for
the `slpsoftware` customer instance is retired, per this cutover.