Publish v0.2.11 and document the host disk limit

- Pruned the superseded v0.2.0 and v0.2.9 releases through the API (~565 MB of
  assets) after the host root filesystem hit 100%, which blocked release uploads
  (HTTP 500 "no space left on device") and even git push ("unpacker error").
- Published v0.2.11 locally with the fixed script: all five artifacts verified on
  the release (Linux/Windows/macOS ports, NSIS installer, AppImage).
- TODO records the remaining ~150 MB headroom and the exact host cleanup commands;
  MEMORY and RELEASING describe the disk failure mode and the pruning.

MEMORY.md

@@ -151,13 +151,14 @@ Session memory for durable decisions, state, and gotchas. Keep concise, remove o
   are published**; v0.2.4–v0.2.8 tags have no artifacts. Verify the CI path on the next tag.
 - **Host disk full (2026-10-31):** the v0.2.11 tag build created release id 27 and logged the
   uploads, but they failed with `HTTP 500 Attachments.Save: write … no space left on device`
-  (`/dev/mapper/pve-vm--500--disk--0`, 7.8G, 100%, 0 free). The empty v0.2.11 release was
+  (`/dev/mapper/pve-vm--500--disk--0`, 7.8G, 100%, 0 free). `git push` then failed too
-  deleted so "latest" is v0.2.10 (5 assets). `publish_release.sh` now checks the HTTP code and
+  ("unpacker error"). Unblocked by deleting the superseded **v0.2.0** and **v0.2.9** releases
-  verifies the asset count, so this cannot look successful again. Host cleanup needs root on
+  via the API (~565 MB of assets), then publishing v0.2.11 locally with the fixed script
-  192.168.88.30: `sudo journalctl --vacuum-size=100M` (journal is 837 MB), `sudo apt-get clean`
+  (verified 5 assets). Remaining ~150 MB is tight — the next release needs host cleanup on
-  (91 MB), clear `/var/lib/gitea/data/attachments/tmp`. SSH works as `zwitschi` but `sudo -n`
+  192.168.88.30: `sudo journalctl --vacuum-size=100M` (journal 837 MB), `sudo apt-get clean`
-  requires a password. v0.2.11 artifacts are built locally in `build/` and can be uploaded by
+  (91 MB), clear `/var/lib/gitea/data/attachments/tmp`. SSH works as `zwitschi`; `sudo -n`
-  running `./tools/publish_release.sh 0.2.11` once space is available. PLAN.md + ADRs 0007–0010 still describe the intended UX.
+  needs a password. **Releases now:** v0.2.11, v0.2.10, v0.2.1 (5 assets each); v0.2.0 and
+  v0.2.9 entries were pruned. PLAN.md + ADRs 0007–0010 still describe the intended UX.
 - **Release v0.2.1 is LIVE** (2026-10-31): CI run 1110 built the NSIS installer + AppImage
   and published — installers/AppImage are on the releases page. Releasing = bump version → tag → push.
 - NSIS gotchas (validated in a local ubuntu:24.04 docker repro): makensis uses `-D` defines

TODO.md

@@ -35,11 +35,11 @@ Verified via API+host credentials (2026-10-31):
       Gitea runner does not expose `github.token`).
 - [x] Uploads now fail loudly and the release is verified to carry every artifact
       (a silent HTTP 4xx used to leave an empty release with a green job).
-- [ ] **Host disk is full** (`/` 7.8G, 100%, 0 bytes free) so release uploads fail with
+- [x] Unblocked by pruning the superseded v0.2.0 and v0.2.9 releases (~565 MB) and
-      HTTP 500 `Attachments.Save: no space left on device`. Root-owned data is using the
+      publishing v0.2.11 locally; all five artifacts are on the release.
-      space; `sudo journalctl --vacuum-size=100M` (~700 MB in `/var/log/journal`),
+- [ ] **Host disk is still tight** (`/` 7.8G, ~150 MB free). Before the next release, run
-      `sudo apt-get clean` (~90 MB), and clearing `attachments/tmp` would unblock it.
+      on 192.168.88.30 as root: `journalctl --vacuum-size=100M` (journal is 837 MB),
-      Alternative: prune superseded releases (v0.2.0 + v0.2.9 assets ≈ 565 MB).
+      `apt-get clean` (91 MB), and clear `/var/lib/gitea/data/attachments/tmp`.
 - [ ] Verify the fallback on the next tag push produces a release automatically (the
       v0.2.11 tag build reached the publish step and created the release; only the
       upload failed on disk space).

docs/RELEASING.md

@@ -49,6 +49,11 @@ already injects basic-auth credentials for the checkout, and the script reuses t
 header for the API (same server). `github.token` is *not* available in this Gitea
 setup, so do not rely on it.
 
+> **Disk space:** Gitea stores release assets under `/var/lib/gitea/data/attachments` on
+> the host root filesystem (7.8 GB here). When it is full, asset uploads fail with
+> `HTTP 500 … no space left on device` and even `git push` can fail with "unpacker error".
+> `publish_release.sh` now verifies the asset count and exits non-zero, so this is visible.
+>
 > **Incident (2026-10-31):** `tools/publish_release.sh` never set `AUTH` in its
 > `~/.git-credentials` branch, so every API call failed silently (`AUTH[@]` was
 > unbound under `set -u`). Combined with no `GITEA_TOKEN` secret on the repo, tag