Update plan and add release README

PLAN.md

@@ -61,17 +61,21 @@
 - If apply fails, auto rollback.
 - Skip overwriting user-edited config? For v1 assume assets/api are managed; nginx site left unchanged.
 
-## Implementation steps
-1) Add current version markers (maybe file in repo, read by UI).
-2) Implement updater helper script with check/apply/rollback + state.
-3) Add systemd service/timer units template (install script TBD, for now keep files in repo).
-4) Extend `pikit-api.py` with new endpoints calling updater functions.
-5) Extend UI (status chip + modal) and wire to API.
-6) Add mock responses for dev (mock-update-status.json).
-7) Test locally (mock) and on device (manual apply pointing to a dummy URL or skip download logic for now).
+## Current status (2025-12-11)
+- Version markers and mock update status in place.
+- UI has release chip + modal; buttons call real `/api/update/*`.
+- API implements check/apply/rollback with staging, SHA256 verify, backup, deploy, restart, rollback.
+- Release tooling: `tools/release/make-release.sh` + README; SHA256 baked into manifest.
+- Missing: auto-check timer, lockfile, backup pruning, real release publishing.
+
+## Remaining work
+- Publish real release bundles + manifest to Gitea.
+- Add lock around apply/check to prevent overlap.
+- Add backup pruning (keep last N).
+- Add systemd timer/service to run check daily and surface status.
+- Optional: protect nginx/site overrides; add disk-space preflight.
 
 ## Open questions / assumptions
 - Release hosting: use Gitea releases at `https://git.44r0n.cc/44r0n7/pi-kit/releases/latest` (JSON API? or static URLs). For v1, hardcode base URL env var or config.
 - Services to restart: assume `dietpi-dashboard-frontend` and `pikit-api` (if we add a service file). Need to verify actual service names on device.
 - Device perms: updater runs as root (via sudo from API). Ensure API endpoint requires auth (existing login).
-