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

@@ -1279,3 +1279,14 @@ by Infrastructure Design. U5 carries REF-U3-01's Umami origin gate plus FR-21 an
 **Context**: OPERATIONS — Deployment Setup artifacts corrected before final approval
 
 ---
+## Deployment Setup — Generic Deploy Account
+
+**Timestamp**: 2026-07-28T04:00:00Z
+
+**User Input**: "het deploy/pipeline-account mag een generieke zijn voor op de pi. die hoeft niet specifiek voor dit project"
+
+**AI Response**: "Renamed the suggested account from project-specific (slpmodularcms-deploy) to generic/host-wide (pi-deploy), noting it should serve multiple projects' deploy pipelines and that the reference project's existing account should be checked and reused if it already has SSH shell access, rather than creating a duplicate. Deploy paths stay namespaced per project under that shared account's home directory, so this doesn't change the directory layout, only the account's identity/scope."
+
+**Context**: OPERATIONS — Deployment Setup, small correction before final approval
+
+---

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

@@ -25,21 +25,27 @@ role) — it cannot SSH in, and should **stay** SFTP-only. `deploy-scp.yaml` nee
 (for `mkdir`, `ln -sfn`, `systemctl --user restart`, the backup script), which is a different kind
 of access than FileZilla uses.
 
-**Preferred**: create a separate, dedicated account for the deploy pipeline — e.g.
-`slpmodularcms-deploy` (rename freely; nothing in the workflow hardcodes this name, it only reads
-`PI_MAIN_USERNAME`). This keeps the two roles cleanly apart, matching your stated preference.
+**Preferred**: a separate account for the deploy pipeline, but a **generic, host-wide** one — not
+named after this project, since it may end up deploying other projects on this Pi too (the reference
+`SlpSoftware` project's own pipeline may already have exactly this kind of account; check its
+`PI_MAIN_USERNAME` secret first and reuse it directly if it already has SSH shell access, rather than
+creating a second one). Example name: `pi-deploy`.
 ```bash
-sudo useradd -m -s /bin/bash slpmodularcms-deploy
-sudo passwd slpmodularcms-deploy
+sudo useradd -m -s /bin/bash pi-deploy
+sudo passwd pi-deploy
 ```
-**Fallback, only if a new account genuinely isn't feasible** (e.g. a hosting provider that doesn't
-allow arbitrary new system accounts): grant `webadmin` SSH shell access instead
-(`sudo usermod -s /bin/bash webadmin`, plus enabling SSH password/key auth for it if currently
-blocked at the `sshd_config` level). This merges the two roles onto one account — acceptable as a
-fallback, but worth revisiting later, since it means a website-workspace author's FTP credential
-would also be able to run shell commands on the Pi.
+Each project deploying through this account gets its own subdirectory under its home (§ 1.4 already
+namespaces by project: `~/apps/slpmodularcms-<env>/`), so one generic account can serve multiple
+projects without their release trees colliding.
 
-The rest of this document uses `<deploy-user>` — substitute whichever of the two you actually use.
+**Fallback, only if no SSH-capable account exists at all and creating one genuinely isn't feasible**
+(e.g. a hosting provider that doesn't allow arbitrary new system accounts): grant `webadmin` SSH
+shell access instead (`sudo usermod -s /bin/bash webadmin`, plus enabling SSH password/key auth for
+it if currently blocked at the `sshd_config` level). This merges the FTP and deploy roles onto one
+account — acceptable as a fallback, but worth revisiting later, since it means a website-workspace
+author's FTP credential would also be able to run shell commands on the Pi.
+
+The rest of this document uses `<deploy-user>` — substitute the generic account's actual name.
 
 ### 1.3 Enable Lingering (INFRA-U6-01 — do this first, easy to forget)
 ```bash
@@ -193,7 +199,7 @@ change:
 |---|---|---|
 | `PI_MAIN_ADDRESS` | secret | the Pi's address |
 | `PI_MAIN_PORT` | secret | SSH port |
-| `PI_MAIN_USERNAME` | secret | `<deploy-user>` — the new dedicated account (§ 1.2), **not** `webadmin` |
+| `PI_MAIN_USERNAME` | secret | `<deploy-user>` — the generic, host-wide deploy account (§ 1.2), **not** `webadmin`; reuse the reference project's if it already has one |
 | `PI_MAIN_PASSWORD` | secret | `<deploy-user>`'s password |
 | `DEPLOY_PATH_TEST` | variable | `/home/<deploy-user>/apps/slpmodularcms-test` |
 | `DEPLOY_PATH_PRODUCTION` | variable | `/home/<deploy-user>/apps/slpmodularcms-production` |

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

@@ -28,10 +28,12 @@ Same physical host for both (per `infrastructure-design.md` § 1) — separated
 **Account model (revised at Deployment Setup)**: the Pi's existing `webadmin` account is FileZilla/
 SFTP-only, used by website-workspace authors uploading customer sites under
 `/mnt/storage1/www/html/` (`WEBSITE_WORKSPACE.md`'s role) — it cannot SSH in and stays that way. The
-deploy pipeline uses a **separate, dedicated** SSH-capable account instead
-(`deployment-instructions.md` § 1.2), so the two roles never overlap on one credential. Deploy paths
-live under that account's own home directory, not under `html/` — this was a deliberate choice to
-avoid the CMS's release/current/shared structure interfering with the other websites hosted there.
+deploy pipeline uses a **separate, generic, host-wide** SSH-capable account instead
+(`deployment-instructions.md` § 1.2) — not one created specifically for this project, since it may
+serve other projects' deploy pipelines on the same Pi too (reuse the reference project's existing
+account if it already has SSH access). Deploy paths live under that account's own home directory,
+namespaced per project, not under `html/` — this was a deliberate choice to avoid the CMS's
+release/current/shared structure interfering with the other websites hosted there.
 
 ## Rationale for What's Documented Here vs. Already Decided