# ArchForge External Status 1.0.9 — Persistent Branding Fix

**Purpose:** Stop `Git SSH` and `Git Smart HTTP` from reappearing on `status.archforge.nl` after a service restart or Git deployment.

## Changes

- Persist canonical service labels `ArchForge SSH` and `ArchForge HTTPS` for existing internal IDs `git_ssh` and `git_http`.
- Add guarded SQLite triggers that undo attempts by older program versions to overwrite these two labels or their category. Existing service IDs, uptime history, incidents, administrators, and monitor settings are untouched.
- Render canonical names on the public status page, service detail pages, admin panel, and public status API, even if a stale in-memory record is encountered.
- Add `fix-status-branding.sh` for a **Git-based** Debian 13 repair. It checks the checkout version **before** changing the installed app, deploys with existing backup/rollback behavior, then verifies the running `/healthz` version and persisted database names.
- Add automated tests for stale database writers, restarts/reopening SQLite, history retention, and public HTML presentation.

No changes to ArchForge 11.3.9.1 or ArchForge Desktop are required.

## Install (existing VPS 2, from Git)

Update/commit the **full 1.0.9 project** or apply the 1.0.8→1.0.9 update to your source repository. Push to ArchForge, then from your Debian 13 VPS:

```bash
cd ~/archforge-external-status
git pull --ff-only
bash ./fix-status-branding.sh
```

Run the repair script as `root`, as in your previous PuTTY session. If you log in as a normal user instead, use `sudo bash ./fix-status-branding.sh` for the last line. The installer is **not** rerun; do not delete your existing SQLite DB or `status.env`.

The repair script is a standalone `bash` process. A failure returns to your shell and prints `[ERROR]`, rather than containing a pasted `exit` in your PuTTY session.

## Troubleshooting

If the script reports that `/healthz` is still on an older version, a different service, install path, or process may be running. Do not manually change the DB again; send the exact `[ERROR]` line instead. If the script confirms version 1.0.9 and names, hard-refresh the public status page (Ctrl+F5).