### FEATURE-4: Onboarding loading screen with progress (IN PROGRESS)
**Priority**: P1 — High
**Status**: IN PROGRESS (2026-03-17)
Users hit the onboarding screen before the backend is ready, resulting in "Server is still starting up" errors that block identity creation. The onboarding flow should not begin until the server is fully operational.
**Solution**: Show the existing screensaver as a loading/boot screen with server startup progress. Swap the inner logo for animated pixel art icons (smiley face, Bitcoin logo, etc.) that cycle while services come online. Show progress indicators for each backend service (identity store, container runtime, LND, etc.). Only transition to onboarding once `/health` returns ready.
**Key considerations**:
- Reuse the existing screensaver component as the boot screen
- Animated pixel art icons rotate in the center (smiley, BTC, lightning bolt, etc.)
- Progress bar or status checklist showing which services are ready
- Poll `/health` endpoint for service readiness
- Smooth transition from boot screen → onboarding once all critical services are up
- First-boot vs normal boot: first boot shows onboarding after, normal boot goes to dashboard
**Key files**:
-`neode-ui/src/views/Onboarding.vue` — current onboarding flow
-`neode-ui/src/components/Screensaver.vue` — existing screensaver to repurpose
-`core/archipelago/src/api/rpc/mod.rs` — health endpoint
-`core/archipelago/src/server.rs` — startup sequence and service initialization
**Tasks**:
- [ ] Investigate current health endpoint — what services does it check, what's missing
Run through the complete `docs/BETA-RELEASE-CHECKLIST.md` app matrix on a fresh ISO install. Every app: install, launch, UI loads, uninstall. Every dependency chain: correct errors when deps missing.
### TASK-17: Alpha version tags + rollback strategy (PLANNED)
**Priority**: P2 — Medium
**Status**: PLANNED (2026-03-18)
Tag every significant alpha version with git tags for easy rollback. Each tag should correspond to a deployable state. Maintain a version log so any alpha can be rebuilt and deployed.
**Tasks**:
- [ ] Tag current state as `v1.2.0-alpha.1` (pre-rootless-podman)
### TASK-42: LUKS2 full-partition encryption for /var/lib/archipelago/ (PLANNED)
**Priority**: P1 — High
**Status**: PLANNED (2026-03-19)
Encrypt all Archipelago app data at rest using LUKS2 full-partition encryption. Protects Bitcoin wallet data, LND macaroons, FileBrowser files, Vaultwarden vault, secrets, and everything else from physical disk seizure. Seamless UX — user never interacts with encryption directly.
**Design**:
- LUKS2 partition for `/var/lib/archipelago/` created during ISO install
- Cipher: AES-256-XTS (hardware AES-NI on x86_64, ChaCha20 fallback on ARM without AES-NI)
- Key derived from setup password via Argon2id + hardware salt (`/sys/class/dmi/id/product_uuid`)
- Key file stored at `/root/.luks-archipelago.key` (root:600, on boot partition)
- Auto-unlock via `/etc/crypttab` on every boot — no passphrase prompt
- Password change in Settings re-derives key and rotates LUKS keyslot
**Threat model**:
- Disk removed from machine = fully encrypted, unreadable
- Running machine with login = transparent (same as today)
- Forgot password = cannot decrypt (correct sovereign behavior)
**Tasks**:
- [ ] ISO installer: create LUKS2 partition, format + mount at `/var/lib/archipelago/`
- [ ] First-boot: derive LUKS key from setup password via Argon2id + hardware salt
- [ ] Store key file at `/root/.luks-archipelago.key` with 600 perms
- [ ] Configure `/etc/crypttab` for auto-unlock at boot
- [ ] Settings password change: re-derive LUKS key, add new keyslot, remove old
- [ ] Detect AES-NI availability, fall back to ChaCha20 on ARM without it
