`get-ivim.sh --uninstall` reverts symlinks before the `~/.ivim` dirty guard → half-uninstalled state

[chiro-hiro]

Severity: low · Category: robustness
Location: get-ivim.sh — uninstall(), lines 202-251

What's wrong

Uninstall removes the ~/.vim and ~/.vimrc symlinks and restores their backups (lines 202-230) BEFORE it reaches the ~/.ivim dirty/unpushed-work guard (lines 235-246). If that guard trips (exit 1 at line 243), the user's config has already been reverted to the old backup and the symlinks are gone, but ~/.ivim still exists — a partial-uninstall state. After the user commits/pushes and re-runs --uninstall, the symlink branches now hit the 'is not a symlink' / 'does not point to iVim' skip paths, so the previously restored backup is not re-restored and no second restore happens. Work is preserved (the guard's main goal), but the machine is left in an inconsistent intermediate state with no clear recovery message.

Evidence

Symlink teardown + restore happens first (line 203 rm "$VIM_DIR" ... line 208 mv "$backup" "$VIM_DIR"), then only afterwards line 242-246:

if [ -n "$dirty" ]; then
  err "$IVIM_DIR has $dirty — not removing."
  err "Commit or push your work, or delete $IVIM_DIR manually."
  exit 1
fi

The exit 1 is reached only after the symlinks have already been removed and backups restored.

Suggested fix

Perform the ~/.ivim dirty/unpushed-work check up front (before touching any symlinks). If it would block removal, either exit early before tearing down the symlinks, or proceed with symlink removal but clearly state that ~/.ivim was intentionally left and config has been reverted, so the resulting state is documented rather than surprising.

---

_{Filed from an automated multi-agent source review (2026-05-29); finding adversarially verified at high confidence. Line numbers reflect the audit-fixes-2026-05 working tree.}