slp-modular-cms/aidlc-docs/features/slpsoftware-api/operations/plans/deployment-setup-plan.md

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

• Update continuous_integration.yaml: SlpModularCms.Api → SlpModularCms.Api.SlpSoftware in the 6 identified lines (3 in publish-test, 3 in publish-production) — nowhere else
• 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
• 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
• 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)