Renames the backup script to match the instance, not the software

backup-slpmodularcms-db.sh named the CMS; this backs up slpsoftware
specifically, same as every other instance-scoped path already does.
Hardcoded in deploy-scp.yaml itself, so this is the actual pipeline
code, not just docs describing it.

.gitea/workflows/deploy-scp.yaml

@@ -64,7 +64,7 @@ jobs:
             -p ${{ secrets.PI_MAIN_PORT }} \
             -o StrictHostKeyChecking=no \
             ${{ secrets.PI_MAIN_USERNAME }}@${{ secrets.PI_MAIN_ADDRESS }} \
-            "bash ~/scripts/backup-slpmodularcms-db.sh ${{ inputs.environment }}"
+            "bash ~/scripts/backup-slpsoftware-db.sh ${{ inputs.environment }}"
 
       # Uploads the published output to a fresh, timestamped release directory rather than
       # overwriting the live one (FR-06, D-27) — the atomic switch happens in a later step, once

aidlc-docs/features/gitea-deployment-workflow/audit.md

@@ -1419,3 +1419,13 @@ by Infrastructure Design. U5 carries REF-U3-01's Umami origin gate plus FR-21 an
 
 **Context**: OPERATIONS — Deployment Setup, clarity pass across the whole instructions document
 ---
+## Deployment Setup — Backup Script Renamed for Instance Consistency
+
+**Timestamp**: 2026-07-29T01:10:00Z
+
+**User Input**: "Het database backupbestand ~/scripts/backup-slpmodularcms-db.sh heeft nog slp modular cms als naam, maar we backuppen hier specifiek slpsoftware dus het script mag hernoemd worden naar: ~/scripts/backup-slpsoftware-db.sh"
+
+**AI Response**: "This filename is hardcoded in the already-committed .gitea/workflows/deploy-scp.yaml, so this is a real code change, not just documentation. Renamed the reference in deploy-scp.yaml, deployment-instructions.md, generation-summary.md, and infrastructure-design.md. Left the historical plan/question files (u6-deploy-workflow-code-generation-plan.md, deployment-setup-plan.md) untouched as point-in-time records. Validated deploy-scp.yaml is still syntactically correct."
+
+**Context**: OPERATIONS — Deployment Setup naming correction that required a small Construction-phase code change (deploy-scp.yaml)
+---

aidlc-docs/features/gitea-deployment-workflow/construction/u6-deploy-workflow/code/generation-summary.md

@@ -57,7 +57,7 @@ the documented boundary between Construction and Operations for this specific un
 
 ## Deferred to Operations (not built here, by design)
 
-- `~/scripts/backup-slpmodularcms-db.sh` on the host (referenced, not created — a host-side script
+- `~/scripts/backup-slpsoftware-db.sh` on the host (referenced, not created — a host-side script
   is out of this repository's scope)
 - `loginctl enable-linger` for the deploy user (**INFRA-U6-01**, carried from Infrastructure Design)
 - Actual values for `DEPLOY_PATH_*`, `SERVICE_NAME_*`, `HEALTH_CHECK_URL_*` Gitea variables and the

aidlc-docs/features/gitea-deployment-workflow/construction/u6-deploy-workflow/infrastructure-design/infrastructure-design.md

@@ -99,7 +99,7 @@ Per-environment sequence (test runs steps 1, 3–7; production additionally runs
 
 1. Download the build artifact (`actions/download-artifact`, unchanged from the reference project)
 2. **Production only** (Q8 = A): trigger a database backup over the existing SSH connection —
-   `ssh {user}@{host} 'bash ~/scripts/backup-slpmodularcms-db.sh'`. The backup script itself lives
+   `ssh {user}@{host} 'bash ~/scripts/backup-slpsoftware-db.sh'`. The backup script itself lives
    on the Pi and is created once during host setup (Operations, FR-23); the workflow never
    transmits or references database credentials, keeping D-16's "runtime secrets live in host
    environment variables, the workflow does not manage them" intact. This satisfies FR-20's

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

@@ -431,7 +431,7 @@ Already built (U5/U6) — this is the read-only walkthrough for whoever operates
 
 ## 4. Database Backup Script
 
-👤 **pi-main / `gitea-workflow`** — create `~/scripts/backup-slpmodularcms-db.sh` on the Pi (this
+👤 **pi-main / `gitea-workflow`** — create `~/scripts/backup-slpsoftware-db.sh` on the Pi (this
 script is host-side by design — never part of this repository, so no DB credential ever reaches
 Gitea):
 
@@ -439,7 +439,7 @@ Gitea):
 #!/usr/bin/env bash
 set -euo pipefail
 
-ENVIRONMENT="${1:?Usage: backup-slpmodularcms-db.sh <environment>}"
+ENVIRONMENT="${1:?Usage: backup-slpsoftware-db.sh <environment>}"
 CREDENTIALS_FILE="$HOME/.config/slpsoftware-db-backup.env"
 
 if [[ ! -f "$CREDENTIALS_FILE" ]]; then
@@ -473,13 +473,13 @@ has the older `mysqldump` name, substitute it — same tool, same flags.
 
 👤 **pi-main / `gitea-workflow`:**
 ```bash
-chmod +x ~/scripts/backup-slpmodularcms-db.sh
+chmod +x ~/scripts/backup-slpsoftware-db.sh
 ```
 
 **Verify once, manually**, before relying on it in a real deploy — 👤 **pi-main / `gitea-workflow`**
 (this matches exactly how `deploy-scp.yaml` itself invokes the script over SSH):
 ```bash
-~/scripts/backup-slpmodularcms-db.sh production
+~/scripts/backup-slpsoftware-db.sh production
 ```
 Confirm a `.sql.gz` file appears under `~/backups/slpsoftware/production/` and that the dump didn't
 silently fail (the script uses `set -euo pipefail`, so a real error does propagate as a non-zero