refactor: drop in-repo dotfiles/, move stow tooling to the dotfiles repo

Since the installer clones DOTFILES_REPO into ~/.dotfiles and stows from there, the in-repo dotfiles/ tree was dead weight. Nothing reads it at install time. I removed it (831 files) now that both machines are migrated.

The Makefile's stow / restow / reset / unstow / import targets and the dotfile-script unit suites moved to the dotfiles repo. They sit alongside the scripts they manage and run standalone (cd ~/.dotfiles && make ...). This Makefile keeps the VM-integration targets and the installer-helper suite (safe-rm-rf).

I updated CLAUDE.md and README.md so stow operations run from ~/.dotfiles, and the dotfile-management, theme, and unit-test sections point at the standalone repo. The README was already describing the old in-repo model from before the installer switched to cloning. This brings it in line.

1 files changed, 27 insertions, 33 deletions

diff --git a/README.md b/README.md
index 18b2b86..b55906d 100644
--- a/README.md
+++ b/README.md
@@ -11,8 +11,8 @@ Automated Arch Linux installation, dotfile management, and machine maintenance f
 archsetup turns a freshly installed Arch Linux box into a working desktop. It does three things:
 
 1. **Provisions the system.** The `archsetup` script installs packages, creates the primary user, builds suckless tools and an Emacs config from source, enables systemd services, sets up an AUR helper, configures the firewall, and installs a desktop environment (DWM on Xorg, or Hyprland on Wayland).
-2. **Manages dotfiles.** Configuration lives under `dotfiles/`, symlinked into `$HOME` by GNU Stow. A `Makefile` wraps the common Stow operations and adds an `fzf`-driven importer for new app configs.
-3. **Provides maintenance scripts.** Small utilities under `scripts/` and `dotfiles/*/.local/bin/` for VPN setup, post-install repo cloning, disk wiping, ZFS replication, and similar chores.
+2. **Manages dotfiles.** Configuration lives in a separate dotfiles repo (`git.cjennings.net/dotfiles.git`), cloned to `~/.dotfiles` and symlinked into `$HOME` by GNU Stow. That repo carries its own `Makefile` wrapping the common Stow operations plus an `fzf`-driven importer for new app configs. The installer clones and stows it for you.
+3. **Provides maintenance scripts.** Small utilities under `scripts/` here, and under `~/.dotfiles/*/.local/bin/`, for VPN setup, post-install repo cloning, disk wiping, ZFS replication, and similar chores.
 
 The provisioning step is resumable: it records progress as marker files, so an interrupted run picks up where it left off. `archsetup --status` shows what's done; `archsetup --fresh` starts over.
 
@@ -25,8 +25,8 @@ The provisioning step is resumable: it records progress as marker files, so an i
 - GPU driver auto-detection (skippable)
 - Optional automatic console login for encrypted-root systems
 - Builds suckless tools (dwm, dmenu, st, slock) and an Emacs config from configurable Git repos, compiled on a tmpfs RAM disk
-- Stow-managed dotfiles split into `common/`, `dwm/`, and `hyprland/` trees
-- `Makefile` targets for stow / restow / reset / unstow / import
+- Stow-managed dotfiles in a separate repo, split into `common/`, `dwm/`, `hyprland/`, and `minimal/` trees
+- That repo's `Makefile` carries the stow / restow / reset / unstow / import targets; the installer clones and stows it automatically
 - Two-theme system (`dupre`, `hudson`) switchable with the `set-theme` script
 - VM-based integration test harness (QEMU/KVM) that installs into a throwaway VM and validates the result
 - Logs everything to `/var/log/archsetup-*.log`
@@ -77,12 +77,12 @@ Usage: ./archsetup [OPTIONS]
   --help, -h            Show this help message
 ```
 
-### 3. Link the dotfiles
+### 3. Dotfiles (handled automatically)
+
+`archsetup` clones the dotfiles repo to `~/.dotfiles` and stows the right trees for your `DESKTOP_ENV`, so there's nothing to do by hand. To re-link later (after a `git pull` in `~/.dotfiles`), use that repo's Makefile:
 
 ```sh
-make stow dwm         # Xorg + DWM
-# or
-make stow hyprland    # Wayland + Hyprland
+cd ~/.dotfiles && make stow hyprland     # or: make restow hyprland
 ```
 
 ## Configuration
@@ -107,39 +107,39 @@ Every field has a default. Set only what you want to change. The config covers:
 
 ## Dotfile Management
 
-Dotfiles live under `dotfiles/` and are stowed into `$HOME` with GNU Stow. The tree splits three ways:
+Dotfiles live in their own repo (`git.cjennings.net/dotfiles.git`), cloned to `~/.dotfiles` and stowed into `$HOME` with GNU Stow. The tree splits four ways:
 
-- `dotfiles/common/` — shared by every setup (shell config, `~/.local/bin` scripts, app configs that don't depend on the display server)
-- `dotfiles/dwm/` — Xorg/DWM-specific configs and scripts
-- `dotfiles/hyprland/` — Wayland/Hyprland-specific configs and scripts
+- `common/` — shared by every setup (shell config, `~/.local/bin` scripts, app configs that don't depend on the display server)
+- `dwm/` — Xorg/DWM-specific configs and scripts
+- `hyprland/` — Wayland/Hyprland-specific configs and scripts
+- `minimal/` — a standalone headless tree (stowed alone for `DESKTOP_ENV=none`, not layered on `common/`)
 
-`make stow <de>` links `common` plus the chosen DE tree. The `Makefile` drives all of it:
+The installer clones and stows the right trees for you. The dotfiles repo carries its own `Makefile` for managing them afterwards — run these from `~/.dotfiles`:
 
 ```
-make stow dwm          # Fresh install: link common + dwm
-make stow hyprland     # Fresh install: link common + hyprland
-make restow dwm        # Refresh links after a git pull (prompts on conflicts)
+make stow hyprland     # Link common + hyprland (or: dwm)
+make restow hyprland   # Refresh links after a git pull (prompts on conflicts)
 make reset hyprland    # Resolve conflicts by keeping the repo version
-make unstow dwm        # Remove all symlinks
-make import common     # fzf-pick app configs and import them into dotfiles/common/
-make import dwm        # ...into dotfiles/dwm/
-make import hyprland   # ...into dotfiles/hyprland/
-make deps              # Install stow, fzf, and the VM-test toolchain
+make unstow hyprland   # Remove all symlinks
+make import common     # fzf-pick app configs and import them into common/
+make test              # Run the dotfile-script unit suites
 make help              # Full target list
 ```
 
 `make import` scans `~`, `~/.config`, and `~/.local` for config directories not yet in the repo, lets you multi-select with `fzf`, moves them into the chosen tree, and re-stows so the originals become symlinks. It reminds you to commit afterwards.
 
+This `archsetup` repo no longer carries the dotfiles itself — the in-repo `dotfiles/` tree was extracted to the standalone repo so it can be developed, tested, and published on its own.
+
 ### Theme system
 
-Two themes ship in the repo, `dupre` (default) and `hudson`. Switch with the `set-theme` script (installed via the `common` dotfiles). Theme files live under `dotfiles/hyprland/.config/themes/<theme>/` and cover foot, fuzzel, waybar, dunst, hyprlock, and Xresources.
+Two themes ship in the dotfiles repo, `dupre` (default) and `hudson`. Switch with the `set-theme` script (installed via the `common` dotfiles). Theme files live under `~/.dotfiles/hyprland/.config/themes/<theme>/` and cover foot, fuzzel, waybar, dunst, hyprlock, and Xresources.
 
 ## Desktop Environments
 
 - **DWM (Xorg).** The `dwm` desktop env builds dwm, dmenu, st, and slock from the configured Git repos and links the `dwm` dotfile tree. DWM keybindings live in that fork's `config.def.h`.
 - **Hyprland (Wayland).** The `hyprland` desktop env installs Hyprland and links the `hyprland` dotfile tree, including a waybar/foot/fuzzel/dunst/hyprlock stack themed to match.
 
-Pick the desktop env at install time with `DESKTOP_ENV` in the config file (or accept the prompt/default), then link the matching dotfiles with `make stow dwm` or `make stow hyprland`.
+Pick the desktop env at install time with `DESKTOP_ENV` in the config file (or accept the prompt/default); the installer links the matching dotfiles for you. To re-link later, run `make stow dwm` or `make stow hyprland` from `~/.dotfiles`.
 
 ## Testing
 
@@ -147,21 +147,15 @@ archsetup has two test layers: fast unit tests for the standalone helper scripts
 
 ### Unit tests
 
-The helper scripts under `dotfiles/*/.local/bin/` that shell out to other tools (`tmux`, `hyprctl`) have Python `unittest` suites under `tests/`, one directory per script. Each suite runs the real script with fake binaries placed on `PATH` — the fakes serve canned state and log every call, so the tests assert on behavior (what the script tells `tmux`/`hyprctl` to do) rather than implementation. No VM, root, or network needed; the whole set runs in under a second.
-
-```sh
-make test-unit         # Run every unit suite
-```
-
-To run a single suite directly:
+Installer helpers (such as the `safe_rm_rf` guard) have Python `unittest` suites under `tests/`, one directory per helper, sourcing the real function out of the `archsetup` script and exercising it with fakes on `PATH`. No VM, root, or network needed; they run in under a second.
 
 ```sh
-python3 -m unittest tests.tmux-util.test_tmux_util
+make test-unit         # Run every installer-helper suite
 ```
 
-(`unittest discover` skips these because the per-script directory names are hyphenated, so `make test-unit` runs each suite explicitly.)
+(`unittest discover` skips these because the per-helper directory names are hyphenated, so `make test-unit` runs each suite explicitly.)
 
-**Adding a suite for a new script.** Create `tests/<script-name>/`, add a `fake-<tool>` executable for each external command the script calls (have it read canned state and append a line to a call log), then write `test_<script_name>.py` driving the real script with those fakes on `PATH`. Mirror the existing `tests/tmux-util/` layout. `make test-unit` picks up any `tests/*/test_*.py` automatically.
+The standalone dotfile scripts (the ones that shell out to `tmux`, `hyprctl`, `iw`, and friends) have their own suites in the dotfiles repo, run with `make test` from `~/.dotfiles`. They moved there to live alongside the scripts they exercise.
 
 ### Integration tests (VM harness)