update: go back to the running release; docs for the first update from v0.0.2

docs/admin-guide/maintenance.md

@@ -39,6 +39,10 @@ The script:
 
 Each run is logged in `data/update-logs/`, with one line per update in `data/update-logs/history`.
 
+A folder from before the script existed (v0.0.2 and older) gets it with the release: run
+`git fetch --tags && git checkout v0.0.3` first (with the release you want), then
+`sudo scripts/update.sh v0.0.3`. The running version stays up until the script restarts it.
+
 ### Portainer, or another setup with pulled images
 
 1. **Settings → Backups → Back up now**, and download the backup.

docs/spec/08-security-ops.md

@@ -99,9 +99,21 @@ get the proxy's address only (below). The setting is on Settings → Security, w
 
 ### 3.1 Install / update
 - `scripts/install.sh` (01 §1.3).
-- `scripts/update.sh`: `git pull --ff-only`, `docker compose build`, `docker compose up -d`. Migrations run automatically on api start. Print the new version.
-  Not built yet (owner, 2026-10-20): nothing has shipped, so there is nothing to update. Before v1.0
-  ships it must be written, reviewed and thoroughly tested (see the v1.0 definition of done, 09).
+- Docker only (owner, 2026-10-21): SelfPhoneNG never supports a bare-metal install.
+- Database changes ship in the image: the api runs pending migrations as it starts. Before it does,
+  it backs up (`backupBeforeMigrate`: database, voicemail, custom sounds, MOH; no recordings; prunes
+  nothing) and stops, leaving the database alone, if that fails; `SKIP_BACKUP_BEFORE_MIGRATE=true`
+  overrides. Any other one-off upgrade step goes in the image the same way, so pulling the new
+  image is the whole update for every install. What can't (a PostgreSQL major version, a new stack
+  setting) goes in the changelog under the version that needs it.
+- `scripts/update.sh`, for compose installs (the folder `install.sh` set up) only: checks (clean
+  checkout, 3 GB free, no calls, the changelog, new `.env.example` keys), a backup
+  (`node dist/backup-cli.js` in the running api), Asterisk logs gzipped (kept 90 days), the
+  release's images built while the old ones run, `up -d`, then a check (healthz, `/app/VERSION`,
+  Asterisk fully booted, trunks registered before still are). On a failed check: the previous
+  commit rebuilt and, if the migration count changed, `restore.sh` with the api's pre-migration
+  backup. Logs in `data/update-logs/`. Image-based installs (Portainer) change the tag and redeploy
+  (admin guide, maintenance.md).
 - Version: `package.json` version at the root, exposed at `/api/system/status`. Semver. `CHANGELOG.md` kept by hand.
 - Releases (owner, 2026-10-20; first one v0.0.1): container images are built only when a release
   is published, by `.github/workflows/release.yml`, which runs on Gitea and on the GitHub mirror,

docs/spec/09-roadmap.md

@@ -274,6 +274,6 @@ Each one checked against a real account before it's called supported (06's verif
 ## Definition of done for v1.0
 Tracked box by box in [`docs/v1-checklist.md`](../v1-checklist.md).
 All of M0–M11 done (including the open real voip.ms checks under M3), plus: 7 days running on the owner's server handling real calls with
-no crash/restart of the api or Asterisk, and nightly backups restoring cleanly. Also `scripts/update.sh` (08 §3.1) written,
-reviewed and thoroughly tested on a real server (updating a running install, with calls, backups and the bundled Caddy), with
-the admin guide's "Updating" section to match.
+no crash/restart of the api or Asterisk, and nightly backups restoring cleanly. Also updating (08 §3.1, Docker only): the api's
+backup before migrating, `scripts/update.sh` for compose installs, and the admin guide's "Updating" section, tested by
+updating a real running install (compose with the bundled Caddy, and the owner's Portainer stack) with calls and backups.

docs/v1-checklist.md

@@ -46,9 +46,14 @@ In progress on the owner's server (v0.0.2, from 2026-10-21).
 
 ## Updating
 
-- [ ] `scripts/update.sh` written, reviewed and tested on a real server: updating a running
-      install, with calls, backups and the bundled Caddy.
-- [ ] The admin guide's "Updating" section matches it.
+Docker only, never bare metal (owner, 2026-10-21).
+
+- [x] The api backs up before it changes the database, and stops if it can't (2026-10-21).
+- [x] `scripts/update.sh` for compose installs, and the admin guide's "Updating" section for
+      compose and Portainer (2026-10-21).
+- [ ] A real compose install with the bundled Caddy updated with `scripts/update.sh`, with calls
+      and backups.
+- [ ] The owner's Portainer stack updated to a release that changes the database.
 
 ## Security leftovers (08 §6)