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

## Investigation (Before Drafting Anything)

Read `.gitea/workflows/continuous_integration.yaml`, `.gitea/workflows/deploy-scp.yaml`, and
`gitea-deployment-workflow/operations/deployment/{deployment-instructions.md,rollback-plan.md}` in
full before touching anything, per D-7's "extend, don't duplicate" instruction.

- **`deploy-scp.yaml` needs zero changes.** It never hardcodes an entry-point `.dll` name anywhere —
  it uploads whatever the publish artifact contains and restarts a `service_name` input (a plain
  string). The cutover is invisible to this file.
- **`continuous_integration.yaml` hardcodes `SlpModularCms.Api` in exactly 6 lines**, all inside
  `publish-test`/`publish-production` (3 each): the "Build admin frontend" step's
  `mkdir -p ../src/SlpModularCms.Api/wwwroot/admin` + `cp -r dist/. ../src/SlpModularCms.Api/wwwroot/admin/`,
  and the "Publish" step's `working-directory: src/SlpModularCms.Api`. Every other `SlpModularCms.Api`
  reference in the file is `SlpModularCms.Api.Tests` (the `backend-test` job) — Unit 1's own pipeline
  regression suite, deliberately scoped to `Api` only (NFR-CS-01), and correctly untouched here: `Api`
  keeps existing as the local dev host (D-8), so its own regression tests still make sense to run.
- **`deployment-instructions.md` § 1.6**'s systemd unit `ExecStart` lines reference
  `SlpModularCms.Api.dll` explicitly — this is **host configuration**, per the doc's own framing
  ("everything here is host configuration the workflow assumes already exists — `deploy-scp.yaml`
  never creates any of it"). Updating the *documented* command is this feature's job; applying it to
  the *actual, already-running* systemd units on the Pi is the user's own manual step, same as every
  other host-side item in that document — this session has no access to the Pi.
- **No nginx changes** (D-6, already decided) — the proxy Pi's server blocks point at pi-main's port,
  not at a specific executable; whichever `.dll` is running behind that port is invisible to nginx.
- **No database change** — same customer/instance, same domain, same `DB_NAME` (`SlpSoftware<Env>`);
  the cutover only changes which project's compiled output the existing systemd units execute.
- **No Gitea Actions variables/secrets change** — `DEPLOY_PATH_*`, `SERVICE_NAME_*`,
  `HEALTH_CHECK_URL_*`, and every other `vars.*`/`secrets.*` already describe the *target* (paths,
  service names, domains), none of which change in a same-host, same-service-name cutover.
- **`rollback-plan.md` needs zero changes** — it operates entirely at the release-directory/symlink
  level (`current` → `releases/<timestamp>`), never referencing a specific `.dll` name.

## Why No Questions This Time

Every decision this stage would normally ask about is already made and traced in `requirements.md`:
D-6 (no nginx change), D-7 (extend the existing pipeline, don't fork it), D-8 (`Api` stays as local
dev host, unaffected), D-15 (this is a cutover, not side-by-side). This stage is mechanical execution
of already-approved decisions, not new design — flagging that explicitly rather than manufacturing a
question with no real alternative to weigh.

## Checklist

- [x] Update `continuous_integration.yaml`: `SlpModularCms.Api` → `SlpModularCms.Api.SlpSoftware` in
      the 6 identified lines (3 in `publish-test`, 3 in `publish-production`) — nowhere else
- [x] Update `gitea-deployment-workflow/operations/deployment/deployment-instructions.md` § 1.6:
      systemd unit `ExecStart` lines → `SlpModularCms.Api.SlpSoftware.dll`, with an explicit note
      that this is a **cutover the user must apply by hand** to the Pi's already-existing
      `slpsoftware-test.service`/`slpsoftware-production.service` unit files (this session cannot
      reach the Pi) — directly answering the user's earlier question about whether those two unit
      files need editing
- [x] Create `aidlc-docs/features/slpsoftware-api/operations/deployment/deployment-instructions.md`
      as a short feature-local pointer document: this feature does not own a separate deployment
      pipeline, it extends `gitea-deployment-workflow`'s — record that relationship plus exactly what
      changed and why, rather than duplicating the full instructions
- [x] Verify no other file in the repo hardcodes `SlpModularCms.Api` in a way that's actually about
      *this pipeline's deploy target* (as opposed to `Api`'s own continued existence as local dev
      host, or `Api.Tests`, both of which are correctly unaffected)