# ArchForge 11.3.8 · Desktop 1.5.5 · External Status 1.0.8

## Purpose

This is a **visible terminology and branding update**, not a replacement for the Git engine. Public websites and the Desktop UI use ArchForge branding. The system still uses real `git` commands, Git protocols, `.git` directories, `.gitignore` files, commit references, and existing internal service IDs. Existing `.archforge` clone URLs remain canonical, and **this release does not change the configured legacy `.git` transport policy**. No repository or database migration is needed.

## 1. Back up the main website

Back up the current website tree, `.env`, MySQL, bare repositories under `data/`, Desktop release assets, and any persistent uploads before deployment. Keep the current release available for rollback.

Apply **ArchForge-v11.3.8-UPDATE-FROM-11.3.7.zip** over an existing ArchForge 11.3.7 source tree or deploy the full website ZIP. Restart the Node.js server using your normal hosting control panel. Do not replace `.env`, database files, live repository storage or other runtime state.

### Legal notices

Branding changes in `legal/drafts/` are **unpublished drafts**. Already published policies stored in MySQL are **not** automatically rewritten. Review all legal changes and republish through the Legal Center only after confirming their accuracy and required approvals. Historical incident descriptions and user-created text in the database are intentionally not rewritten.

The website now publishes `https://archforge.nl/desktop/releases/latest.json` for **Desktop 1.5.5** with an exact downloadable ZIP and SHA-256. Make sure this endpoint is reachable without login or redirect. The release ZIP is included with both the full website project and the update.

## 2. ArchForge Desktop 1.5.5 — Arch Linux / KDE

Extract **ArchForge-Desktop-v1.5.5-FULL.zip** and, as your normal desktop user, run:

```bash
chmod +x install.sh
./install.sh
```

The ZIP contains the properly built `packaging/archforge-desktop-1.5.5.tar.gz`; do not install as root. You can also apply **ArchForge-Desktop-v1.5.5-UPDATE-FROM-1.5.4.zip** over the 1.5.4 source checkout; after applying it, run `./install.sh` normally.

The Desktop UI, first-run wizard, menu entries and user-visible error copy are rebranded. **The Git binary dependency remains mandatory**, because it is how ArchForge implements version control. Local `.git` directories, credentials, KDE Wallet and repository locations are untouched. All previously migrated `.archforge` URLs continue to work.

## 3. External Status 1.0.8 — Debian 13

Commit and push the full project or apply **ArchForge-External-Status-v1.0.8-UPDATE-FROM-1.0.7.zip** to the existing Git repository, then on Debian 13:

```bash
cd ~/archforge-external-status
git pull --ff-only
sudo bash scripts/deploy.sh "$PWD"
```

`git pull` uses your existing Git checkout; the command name is intentionally unchanged. If the checkout is owned by a non-root user, pull as that user. The deploy step runs as root after you have reviewed the checked-out source. Deployment backs up the existing SQLite database and previous app release, executes its tests and restarts the status service with rollback on launch failure.

**Do not rerun `install.sh` and do not erase `/var/lib/archforge-status/status.db` or `/etc/archforge-status/status.env`.** No changes to Caddy/DNS/SSL are needed. Current uptime samples, incidents, administrator credentials and confirmation tokens remain intact. Service names are updated automatically in the existing SQLite `services` table at service initialization, without resetting history.

## 4. Validation

- Website navigation, repository pages, maintenance notices, security pages and status center: ArchForge branding.
- Desktop menu, project inspector, setup wizard and alerts: ArchForge branding.
- Independent status public and admin screens: **ArchForge HTTPS** and **ArchForge SSH**.
- Browser repository code examples still contain real `git clone`, `git push` etc. **These are required external command names, not product labels.**
- Website Git Smart HTTP/SSH and existing transport authentication, hooks and permission checks are unchanged.
- `.git` directories and internal `git_*` database keys remain unchanged to prevent breaking existing data.

The archives are source releases; you must still verify the services on your live hosts and check that all user-generated content and previously published policies are correct.
