mempalace-boot-repair-always-runslisted

## When to use - HEALTHCHECK reports `mempalace-hnsw-drift` or HNSW = 0 - A `mempalace-repair-now.sh` process is already running (check `ps aux | grep repair`) - The system rebooted recently (`uptime` or `who -b` confirms it) - SQLite drawer count is large and intact (not a wipe — the data is fine) - The pattern repeats: HNSW is rebuilt, works fine, but is 0 again after the next reboot Do NOT use `mempalace-hnsw-corruption-fix` for this pattern — that skill targets `link_lists.bin` bloat from the Rust binding bug. This pattern is a scheduling problem, not corruption. ## Diagnosis ### Step 1 — Confirm repair is already running ```bash ps aux | grep mempalace-repair | grep -v grep # PID, elapsed time, RSS, CPU ``` If it shows >1 GB RSS and elapsed >5 min after reboot, it started from `@reboot`. ### Step 2 — Check the repair log ```bash tail -50 /opt/proj/Uncle-J-s-Refinery/state/mempalace-repair.log ``` Look for timestamp near last boot. If it matches, `@reboot` triggered it. ### Step 3 — Confirm the cron entry ```bash crontab -l | grep -E "@reboot|mempalace-repair" ``` The smoking-gun entry: ``` @reboot sleep 120 && flock -n /tmp/mempalace-repair.lock bash mempalace-repair-now.sh >> ... ``` This runs **unconditionally on every boot** — even when HNSW was healthy at shutdown. ### Step 4 — Estimate time remaining ~89 min for 235 K rows, scales linearly. Check current count: ```bash sqlite3 ~/.mempalace/palace/chroma.sqlite3 \ "SELECT count(*) FROM embeddings;"