Add Claude Code memory snapshot and restore instructions

claude-memory/project-cloud-migration.md

@@ -0,0 +1,28 @@
+---
+name: project-cloud-migration
+description: "KiteStacks server migration plan — Phase 1 (Forgejo backup, restore to new desktop) and Phase 2 (Oracle Cloud VPS, always-on)"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 1d92780e-77c5-41ac-8887-daca0ea55e8b
+---
+
+**Phase 1 — STATUS: backup pushed & verified, restore not yet performed**
+
+Goal: be able to pull the backup repo onto a new (desktop) machine and physically relaunch the homelab from it.
+
+- Full server backup lives in Forgejo repo `kenpat/kitestacks-cloud-migration` (private), clone url `http://100.90.13.55:3006/kenpat/kitestacks-cloud-migration.git` (also reachable at `gitforge.kitestacks.com` for small files).
+- Source backup: `/home/kenpat/kitestacks-cloud` (git repo, 1 commit `6ffcbea`, ~4.3GB). Contains `archives/*.tar.gz` (docker bind-data, syncthing-shared, scripts, host /etc subset), `volume-exports/*.tar.gz` (named Docker volumes), `inventory/`, `restore/RESTORE.md`, `SHA256SUMS`.
+- 14 large files (~2.3GB) are tracked via **Git LFS** — required `apt-get install git-lfs` (no passwordless sudo on this host, user ran it manually) and `git lfs migrate import --include="archives/*.tar.gz,volume-exports/*.tar.gz"`.
+- **Known gotcha**: Forgejo's public hostname `gitforge.kitestacks.com` (Cloudflare Tunnel) returns HTTP 413 for any LFS object >~100MB. The 3 big files (docker-bind-data.tar.gz ~967MB, kite-ai_open-webui.tar.gz ~963MB, syncthing-shared.tar.gz ~165MB) had to be PUT directly to `http://100.90.13.55:3006/kenpat/kitestacks-cloud-migration.git/info/lfs/objects/<oid>/<size>` (local Tailscale IP, bypasses Cloudflare). `git lfs pull` for these 3 files will need the same workaround — clone/pull via the local IP, not the public hostname.
+- Verified: local HEAD == remote HEAD, all 15/15 LFS objects present server-side with sizes matching `SHA256SUMS` OIDs.
+- Documented in `/home/kenpat/forgejo-repos/kitestacks-homelab/docs/KiteStacks-Homelab-Documentation-v1.3.922.md`.
+
+**Phase 1 remaining work**: actual restore-to-new-desktop has NOT been done/tested yet. When the user pulls a Claude session in on the new desktop, the workflow is: clone `kitestacks-cloud-migration` (via local IP for LFS), follow `restore/RESTORE.md`, restore Docker volumes from `volume-exports/`, restore bind-mounts from `archives/docker-bind-data.tar.gz`, bring stacks up via the compose files, re-point Cloudflare Tunnel.
+
+**Why**: User wants to migrate the KiteStacks homelab off the current desktop onto new hardware first (Phase 1), then to an always-on Oracle Cloud VPS (Phase 2) so services don't go down when the desktop sleeps/is off.
+
+**How to apply**: When the user says they're moving to a new desktop / starting the restore, walk through `restore/RESTORE.md` using this memory's notes (especially the LFS/Cloudflare gotcha). Once services are confirmed running on the new desktop, mark Phase 1 complete in this file, notify the user explicitly, and begin Phase 2 (Oracle Cloud VPS setup) — update this file with Phase 2 progress the same way.
+
+**Phase 2 — STATUS: not started**
+Plan: provision an Oracle Cloud VPS, migrate the same stack there for always-on hosting (independent of desktop power state). No infra details yet — to be filled in once started.