docs: adopt Conventional Commits for commit messages

Vendor the v1.0.0 specification as docs/conventional-commits.md and record the convention in CLAUDE.md: type and optional scope, where the scope names the module or host, and no Gitea-specific references, since this repository is mirrored to GitHub where issue and pull-request numbers resolve to unrelated things.
chore!: remove the pre-NixOS dotfiles tree
2026-07-19 08:24:54 -04:00 · 2026-07-19 08:01:49 -04:00 · 2026-07-19 07:57:44 -04:00 · 2026-07-19 07:57:44 -04:00 · 2026-07-19 07:57:44 -04:00 · 2026-07-19 07:57:43 -04:00
122 changed files with 1846 additions and 4209 deletions
--- a/.claude/CONTEXT.md
+++ b/.claude/CONTEXT.md
@@ -0,0 +1,33 @@
 # NixOS Dotfiles
 A single flake that builds every machine the user owns — laptop, desktop, and three servers — from one shared, modular configuration.
 ## Language
 **Host**:
 One physical machine the flake builds a NixOS configuration for. Each Host has a directory under `hosts/` holding its machine-specific `hardware-configuration.nix` and its choice of enabled Modules.
 _Avoid_: machine, node, system, box
 **Module**:
 A single `.nix` feature file under `modules/` that declares an `enable` option and the configuration it turns on. Every Module is always imported but stays inert until a Host enables it.
 _Avoid_: component, package, plugin
 **Skeleton**:
 The flake's plumbing — the Auto-loader, the helper lib, the flake inputs/overlays, and the shared base config — as distinct from the Modules that sit on top of it.
 _Avoid_: framework, core, base, scaffolding
 **Auto-loader**:
 The lib code that recursively discovers and imports every Module under `modules/` (and every Host under `hosts/`) so new files wire themselves in without manual `imports` edits.
 _Avoid_: loader, importer, scanner
 **Enable convention**:
 The rule that every Module is imported unconditionally and guards its own body with `mkIf config.modules.<path>.enable`, so a Host reads as a checklist of `enable = true` flags.
 _Avoid_: feature flag, toggle, opt-in
 **unstable overlay**:
 The overlay exposing `nixpkgs-unstable` packages as `unstable.<name>`, used to pull an individual package fresher than the `nixos-unstable` base.
 _Avoid_: bleeding-edge, latest
 **stable overlay**:
 The overlay exposing the latest stable release (`nixos-26.05`) as `stable.<name>`, used to pin an individual package to the rock-solid release from the `nixos-unstable` base.
 _Avoid_: LTS, release channel
--- a/.claude/adr/0001-sops-nix-for-secrets.md
+++ b/.claude/adr/0001-sops-nix-for-secrets.md
@@ -0,0 +1,10 @@
 # Use sops-nix for secrets
 The repo is public, so no secret — including password hashes and the WireGuard/ProtonVPN key — may be committed in plaintext. We manage all secrets with **sops-nix**: encrypted into the repo and decrypted per-host at activation via an age key derived from each machine's SSH host key.
 We chose sops-nix over agenix for its multi-recipient encryption (one secret readable by both a host and the admin laptop) and its grouped-file editing workflow, which scale better across the planned five hosts with a mix of shared and per-host secrets. The cost is slightly more upfront machinery than agenix's one-file-per-secret model.
 ## Consequences
 - User/root passwords use `hashedPasswordFile` backed by a sops secret, never a committed hash.
 - Each new host must have its SSH host public key registered as a recipient before it can decrypt its secrets.
--- a/.claude/settings.json
+++ b/.claude/settings.json
@@ -1,36 +0,0 @@
 {
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/attention-bell.sh"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/attention-bell.sh"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // empty'); printf '%s' \"$f\" | grep -Eq '(\\.(test|spec)\\.[cm]?[jt]sx?$)|/__tests__/' && jq -n '{hookSpecificOutput:{hookEventName:\"PreToolUse\",additionalContext:\"test-driven-development skill: the MAIN agent must not author test files. Each test is written by a test-writer sub-agent (via the Agent tool) from the public interface alone. If you are running /implement or any TDD flow and have not loaded /test-driven-development, load it now and delegate this test to the sub-agent. If you ARE the test-writer sub-agent, disregard this reminder.\"}}' || true"
          }
        ]
      }
    ]
  },
  "model": "opus"
 }
--- a/.claude/spec/laptop-mvi.md
+++ b/.claude/spec/laptop-mvi.md
@@ -0,0 +1,92 @@
 ## Problem Statement
 I'm returning to NixOS after ~2 years away, and I want to start by moving my laptop (`neogaia`, a Dell XPS 13 9380 currently running CachyOS) onto it. My old config still exists but is stale and written in a style I no longer want to copy verbatim. Eventually this same config has to grow to cover my desktop and three servers, so whatever I build for the laptop has to be a clean, scalable foundation — not a throwaway.
 Reimaging the laptop is destructive and I only get one machine, so I need a tightly-scoped, well-understood **minimum viable install (MVI)**: the smallest config that boots the laptop into a usable state I can then iterate on live, without risking a half-defined system that strands me at a dead console.
 ## Solution
 Rebuild the `Skeleton` and a single `neogaia` `Host` to the point where the laptop:
 - boots from an encrypted disk (LUKS + btrfs + zram),
 - comes up on wifi,
 - lets me log into a console as my user and run `nixos-rebuild switch`,
 - and already carries my core terminal tooling (fish, tmux, nvim, Claude Code).
 Everything graphical and everything multi-host is deliberately left for later iterative passes, which are safe because a mistake then is "edit and rebuild," not "reimage." The MVI is the one step that must be right *before* reimaging; the rest is reversible.
 The install itself is done from the NixOS live ISO by cloning the repo from my Gitea and running a single `disko-install` against the `neogaia` `Host`, then setting a bootstrap password by hand.
 ## User Stories
 1. As the operator, I want the `Skeleton` rewritten around my old scalable ideas (the `Auto-loader`, the `Enable convention`, per-`Host` layout), so that the config stays legible and shareable across all five future machines without me copying stale code.
 2. As the operator, I want the flake hand-rolled and cleaned up (no framework layer), so that the whole plumbing stays readable in one place for a config that only targets a handful of `x86_64-linux` machines.
 3. As the operator, I want every `Module` auto-discovered and imported but inert until a `Host` sets its `enable` flag, so that each `Host` reads as a checklist of features.
 4. As the operator, I want a `nixos-unstable` base with an `unstable overlay` and a `stable overlay`, so that I can run rolling by default but reach up to bleeding-edge or down to rock-solid on a per-package basis.
 5. As the operator, I want home-manager integrated as a NixOS module with global packages, so that one `nixos-rebuild switch` builds both the system and my user environment atomically.
 6. As the operator, I want my user modelled as an explicit option defaulting to `alexion` (no impure environment lookup), so that the config is reproducible and honest about who the user is.
 7. As the operator, I want the laptop's disk declared with `disko` as encrypted btrfs plus zram swap, so that the install is reproducible and the laptop is encrypted at rest.
 8. As the operator, I want the system to prompt for the LUKS passphrase at boot via systemd-boot and the initrd, so that the encrypted disk unlocks on a normal boot.
 9. As the operator, I want the CachyOS kernel from chaotic-nyx with the chaotic binary cache wired in from the first build, so that I get the performance/feel I'm used to without compiling the kernel from source.
 10. As the operator, I want Intel microcode and the redistributable firmware for the QCA6174 wifi included, so that the laptop's hardware works out of the box.
 11. As the operator, I want NetworkManager enabled, so that I can join wifi easily from the console.
 12. As the operator, I want an SSH daemon running, so that I can drive the rest of the setup remotely if the console is inconvenient.
 13. As the operator, I want my user in `wheel` with a manually-set bootstrap password, so that I can log in and use sudo on first boot without committing any secret to a public repo.
 14. As the operator, I want fish as my default login shell, configured natively via home-manager with my `cachyos-config.fish` translated (greeting, bat-manpager, `done` and bang-bang plugins, helper functions, eza/nav aliases) and all Arch/pacman-specific parts dropped or replaced with NixOS equivalents, so that my shell feels like home but is correct for NixOS.
 15. As the operator, I want tmux configured natively via home-manager using my exact existing `tmux.conf` text, so that my terminal multiplexer is identical to today with no plugin manager needed.
 16. As the operator, I want my nvim config brought in verbatim (lazy.nvim managing its own plugins) via a writable out-of-store symlink, with `git`/`gcc`/`ripgrep`/`fd` provided by Nix, so that my editor is identical to today and lazy.nvim can still update and write its lockfile.
 17. As the operator, I want Claude Code installed declaratively and authenticatable without a browser on the laptop, so that I can use it over the console/SSH via the paste-code flow or an API key.
 18. As the operator, I want timezone `America/New_York`, locale `en_GB.UTF-8`, and console keymap `us` set, so that the base system matches my locale preferences.
 19. As the operator, I want to install by cloning the repo from my Gitea onto the live ISO and running `disko-install` against `neogaia`, so that I avoid self-signed-TLS/auth problems with flake fetching during install.
 20. As the operator, I want the `Skeleton` designed so that per-`Host` disk layouts, per-`Host` kernels, and preserved ZFS pools are all expressible, so that the same foundation extends to the desktop and the three servers later without restructuring.
 ## Implementation Decisions
 **Skeleton**
 - Hand-rolled flake, rewritten and trimmed; no flake-parts.
 - `Auto-loader` rewritten: recursively discovers and imports every `Module` under the modules tree without the old null-placeholder traversal hack; a single discovery helper feeds the `Host` imports. The old `nixosModules` flake output is dropped.
 - Helper lib trimmed to the `Auto-loader`, the host-builder, and the script-from-file helper. `with lib.my` replaced by explicit `inherit`s throughout. `enable` flags use the stdlib enable-option helper rather than bespoke sugar.
 - `nixos-unstable` as the base channel. An `unstable overlay` exposes `nixpkgs-unstable` packages; a `stable overlay` exposes the latest stable release (`nixos-26.05`). chaotic-nyx added as an input with its overlay and binary cache from the start.
 - home-manager sourced from `nix-community`, tracking master with nixpkgs followed, integrated as a NixOS module with global packages and user packages.
 - User modelled as an explicit option defaulting to `alexion`, in `wheel`, driving the system user and the home-manager user in lockstep.
 **neogaia Host**
 - Disk declared via `disko`: LUKS-encrypted btrfs with subvolumes plus zram swap. systemd-boot on an EFI system partition; initrd LUKS unlock.
 - CachyOS kernel selected via a small per-`Host` kernel mechanism; chaotic substituter and trusted key in the Nix settings.
 - Intel microcode; redistributable firmware enabled for the QCA6174 wifi. NetworkManager for networking. A zram toggle `Module` enabled here.
 - SSH daemon enabled. Baseline CLI (git, editor, flakes) present. Claude Code installed declaratively.
 - fish `Module`: native home-manager configuration; translated aliases/functions/plugins/init; set as the default login shell. tmux `Module`: native home-manager, exact existing config text inlined. nvim `Module`: verbatim config placed as a writable out-of-store symlink with runtime dependencies provided by Nix.
 - Locale, timezone, and keymap set to the detected values.
 **Install flow**
 - Repo pushed to Gitea first. From the NixOS live ISO: join wifi, clone the repo locally, run `disko-install` against the `neogaia` `Host` with the chaotic substituter passed to the install-time daemon, set bootstrap passwords via `nixos-enter`, reboot.
 **Secrets (design only in MVI)**
 - Per ADR 0001, secrets use `sops-nix` with age keys derived from each `Host`'s SSH host key. The MVI does not wire any secret, because a `Host`'s age key does not exist until its first install generates the SSH host key. The bootstrap password is set by hand and never committed; moving passwords to a `hashedPasswordFile` backed by a sops secret is the first post-boot task, out of scope here.
 ## Testing Decisions
 - A good test here asserts externally-observable evaluation/build success of the whole `Host`, not the internals of any individual `Module`.
 - **Primary seam (required):** the `neogaia` `Host` evaluates and its system toplevel builds. Building the toplevel drives the entire `Skeleton` — the `Auto-loader` discovering every `Module`, all three overlays resolving, home-manager integration, and every enabled module's config merging without conflict — plus the `disko` layout, which builds from the same tree. Nearly all config-authoring errors surface at this seam short of booting real hardware.
 - No unit-level tests of individual modules; the config-merge model makes the whole-`Host` build the meaningful unit, and it is the highest available seam.
 - Prior art: none in this repo yet (it starts empty); this build-the-toplevel check is the pattern to reuse for every future `Host`.
 - The genuine end-to-end confirmation is the real reimage, which is manual and irreversible by nature and is not automated.
 ## Out of Scope
 - Any graphical environment: Wayland-vs-i3 choice, greeter/display manager, theming (Nord via Stylix or otherwise), fonts, terminal emulator, browser, general desktop apps, gaming (Steam/Lutris/proton-cachyos), emulation.
 - Full `sops-nix` wiring and moving passwords off the bootstrap value (immediate post-boot follow-up, but not MVI).
 - Migrating nvim to a native home-manager configuration with Nix-managed plugins.
 - chaotic-nyx packages beyond the kernel (`mesa-git`, `proton-cachyos`, `scx` schedulers).
 - Flatpak strategy (`nix-flatpak` vs dropping the old imperative helper).
 - The desktop `Host` (`zeus`), including Nvidia.
 - The three servers: deployment model, service migration (plex/arr/kavita/nfs/torrent-through-protonvpn), ZFS wiring and pool import, backups/monitoring, and per-server kernel/channel pinning.
 - VM-based CI (`nixosTest` boot assertions) — explicitly a future addition, not part of this deliverable.
 ## Further Notes
 - **Bootstrap ordering:** the flake must exist on Gitea before the install can consume it, and the manual password step keeps the public repo free of any secret while still yielding a login on first boot.
 - **Gitea is a bootstrap dependency:** every NixOS install pulls the config from self-hosted Gitea, so the Gitea host must stay reachable during any install — relevant when sequencing the servers so the migration never locks the operator out of their own configs.
 - **chaotic cache at install time:** the install-time Nix daemon on the live ISO must have the chaotic substituter configured, or it compiles the CachyOS kernel from source on the USB stick.
 - **Extends to future Hosts by construction:** disk layout, kernel, and channel are all per-`Host` concerns in the `Skeleton`, and existing ZFS pools are preserved by import rather than declared through `disko`. This is what lets the desktop and the three servers join later without reworking the foundation.
 - **Theme target is Nord** (the current CachyOS setup is Nord across terminal, tmux, and nvim), superseding the old repo's Dracula — relevant when the theming branch is grilled.
--- a/.claude/tasks/0001-skeleton-and-building-host.md
+++ b/.claude/tasks/0001-skeleton-and-building-host.md
@@ -0,0 +1,37 @@
 ---
 spec: laptop-mvi
 ---
 ## What to build
 Stand up the `Skeleton` and a minimal `neogaia` `Host` that evaluates and whose system toplevel builds — the walking skeleton every later slice extends and re-verifies against.
 The `Skeleton` is a hand-rolled flake (no flake-parts): `nixos-unstable` base channel, an `unstable overlay` exposing `nixpkgs-unstable` as `unstable.<name>`, a `stable overlay` exposing `nixos-26.05` as `stable.<name>`, and chaotic-nyx wired as an input with its overlay and binary cache.
 The helper lib is trimmed to three pieces: the `Auto-loader` (recursively discovers and imports every `Module` under `modules/` and every `Host` under `hosts/` with no null-placeholder traversal hack), the host-builder, and the script-from-file helper.
 `with lib.my` is not used — dependencies are `inherit`ed explicitly.
 The `Enable convention` uses the stdlib enable-option helper; every `Module` is imported unconditionally and guards its body with `mkIf config.modules.<path>.enable`.
 home-manager is sourced from `nix-community` (master, nixpkgs followed) and integrated as a NixOS module with global packages and user packages.
 The `user` is an explicit option defaulting to `alexion` (no impure environment lookup), placed in `wheel`, driving the system user and the home-manager user in lockstep.
 The `neogaia` `Host` carries only enough (placeholder `hardware-configuration.nix`, filesystems/bootloader stubs, `stateVersion`) to make `nixosConfigurations.neogaia.config.system.build.toplevel` evaluate and build; real disk/kernel/networking arrive in later slices.
 Design the per-`Host` layout so disk layout, kernel, and channel are all per-`Host` concerns from the start (story 20), so the desktop and servers extend this foundation without restructuring.
 ## Acceptance criteria
 - [x] `nix flake check` succeeds and the flake exposes `nixosConfigurations.neogaia`.
 - [x] `nixosConfigurations.neogaia.config.system.build.toplevel` builds.
 - [x] Adding a new `.nix` file under `modules/` is auto-discovered and imported without editing any `imports` list, and stays inert until its `enable` flag is set.
 - [x] All three overlays resolve: `unstable.<pkg>`, `stable.<pkg>`, and a chaotic-nyx package are each reachable in a `Host`.
 - [x] home-manager builds as part of the same `nixos-rebuild switch` toplevel (system + user environment atomic).
 - [x] The `user` option defaults to `alexion`, has no impure environment lookup, places the user in `wheel`, and drives both the system and home-manager user.
 - [x] The old `nixosModules` flake output and the `with lib.my` idiom are absent.
 ## Implementation Notes
 - **Verification.** `nix flake check` builds `checks.x86_64-linux.neogaia` = the Host toplevel (the spec's primary seam). Overlays confirmed via `nix eval` of `pkgs.unstable.hello` (2.12.3), `pkgs.stable.hello` (2.12.1), and `pkgs.linuxPackages_cachyos.kernel` (7.1.3, from chaotic). Auto-loader inertness confirmed both ways: the reference `modules/example.nix` is off by default, and `extendModules` with `modules.example.enable = true` activates its body.
 - **chaotic binary cache.** Wired via `inputs.chaotic.nixosModules.default`, which puts both the `nyx-cache.chaotic.cx` substituter and its trusted public key into the built config (verified by evaluating `config.nix.settings.substituters`/`trusted-public-keys`). chaotic deliberately does **not** follow our nixpkgs, so the cache stays usable. Making the substituter/key explicit is task 0003's concern; here it is inherited from the module.
 - **Shared base lives in `system/`.** The Skeleton's shared base config (overlays, `user`, flakes, home-manager wiring) is a `system/` module always imported by the host-builder, kept separate from the auto-loaded feature `Module`s under `modules/` so the base is never gated by an `enable` flag.
 - **`modules/example.nix` kept intentionally.** It is the Auto-loader / Enable-convention reference every real Module copies; remove it once a real Module supersedes its teaching value.
 - **`scriptFromFile` present but unused.** The task mandates the helper lib carry it ("the script-from-file helper"); its first caller lands with a later Module.
 - **Home-manager base user only.** The base sets `home.username`/`homeDirectory`/`stateVersion` for the `user`; `extraSpecialArgs` passes both `inputs` and `my` (the flake lib) so upcoming HM Modules (fish/tmux/nvim) can reach `scriptFromFile`.
 - **Deviations from plan.** Added an `options.user.description` (GECOS) alongside `user.name` — small and expected for a real account. Baseline `git` + global `allowUnfree` are set in the base (git is required for flakes; unfree is needed by chaotic/home-manager and later Claude Code). Placeholder `fileSystems`/bootloader and `hardware-configuration.nix` in `neogaia` are stubs that task 0002 (disko) replaces.
--- a/.claude/tasks/0002-neogaia-disk-and-boot.md
+++ b/.claude/tasks/0002-neogaia-disk-and-boot.md
@@ -0,0 +1,31 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Declare the `neogaia` laptop's disk with `disko` and make it unlock and boot on real hardware: a LUKS-encrypted btrfs volume with subvolumes plus zram swap, on an EFI system partition using systemd-boot, with the LUKS passphrase prompted at boot via the initrd.
 The layout must build from the same tree as the `Host` toplevel (so the whole-`Host` build exercises it), and must be expressed as a per-`Host` disk concern so other machines can declare their own layouts later.
 ## Acceptance criteria
 - [x] `neogaia` declares a `disko` layout: LUKS-encrypted btrfs with subvolumes plus zram swap on an EFI system partition.
 - [x] systemd-boot is the bootloader; the initrd prompts for the LUKS passphrase so a normal boot unlocks the encrypted disk.
 - [x] The `disko` layout builds as part of the `neogaia` toplevel build (no separate invocation needed to catch layout errors).
 - [x] The disk layout is a per-`Host` concern, expressible differently for future `Host`s without restructuring the `Skeleton`.
 ## Implementation Notes
 - **Layout.** One GPT disk at `/dev/nvme0n1`: a 512M EF00 ESP (vfat, `umask=0077`) mounted at `/boot`, and a 100%-fill LUKS partition (`cryptroot`, `allowDiscards`) holding a btrfs filesystem with three subvolumes — `@root` → `/`, `@home` → `/home`, `@nix` → `/nix` — each mounted `compress=zstd,noatime`.
  There is deliberately no on-disk swap partition; swap is RAM-backed zram.
 - **Skeleton vs. per-Host split.** The disko *module* (`inputs.disko.nixosModules.disko`) is wired into the host-builder in `lib/default.nix`, so every `Host` can interpret a `disko.devices` declaration; the *layout itself* lives in `hosts/neogaia/disk.nix`.
  A future `Host` declares a different layout, or none at all (an undeclared `disko.devices` is a no-op), so servers that preserve an existing pool by import need no `Skeleton` change.
 - **disko input follows nixpkgs.** Unlike chaotic (which must not), disko follows our `nixpkgs` so it builds against the same base.
 - **Boot unlock.** disko's `type = "luks"` (no key file) generates `boot.initrd.luks.devices.cryptroot`, so the classic initrd prompts for the passphrase on a normal boot; the `nvme` initrd module was already present in `hardware-configuration.nix`.
 - **zram enabled directly, not yet a Module.** Criterion 1 requires "plus zram swap," so `zramSwap.enable = true` is set on the `Host` now.
  Task 0003 owns the reusable zram toggle `Module` and will lift this line into it; the placeholder `fileSystems`/bootloader stubs from task 0001 are removed here since disko now derives `fileSystems`.
 - **Verification.** `nix flake check` (the `checks.x86_64-linux.neogaia` toplevel) builds green.
  Confirmed via `nix eval`: disko-derived `fileSystems` = `/`,`/home`,`/nix` on btrfs `/dev/mapper/cryptroot` + `/boot` on the ESP; `boot.initrd.luks.devices` = `["cryptroot"]`; `systemd-boot.enable` and `zramSwap.enable` both true; `swapDevices` empty.
  The genuine end-to-end confirmation is the manual `disko-install` reimage, which is irreversible by nature and not automated.
--- a/.claude/tasks/0003-kernel-and-hardware.md
+++ b/.claude/tasks/0003-kernel-and-hardware.md
@@ -0,0 +1,26 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Give `neogaia` the kernel and hardware enablement it needs to run well on the Dell XPS 13 9380: the CachyOS kernel pulled as a binary from chaotic-nyx (not compiled from source), Intel microcode, and the redistributable firmware for the QCA6174 wifi. Add a zram toggle `Module` and enable it here.
 The kernel is selected through a small per-`Host` kernel mechanism so other `Host`s can choose different kernels. The chaotic substituter and its trusted public key are added to the Nix settings so the kernel is fetched from the binary cache from the first build.
 ## Acceptance criteria
 - [x] `neogaia` runs the CachyOS kernel selected via a per-`Host` kernel mechanism, sourced from chaotic-nyx.
 - [x] The chaotic substituter and trusted public key are in the Nix settings, so the kernel is fetched from cache rather than compiled.
 - [x] Intel microcode is enabled.
 - [x] Redistributable firmware is enabled so the QCA6174 wifi hardware is available.
 - [-] A zram toggle `Module` exists (following the `Enable convention`) and is enabled on `neogaia`. — Module dropped in PR review; zram is enabled inline on `neogaia` instead (see notes).
 - [x] The `neogaia` toplevel still builds with all of the above.
 ## Implementation Notes
 - **Per-`Host` kernel mechanism = native `boot.kernelPackages`.** neogaia sets `boot.kernelPackages = pkgs.linuxPackages_cachyos` directly in its Host directory (`hosts/neogaia/default.nix`). No custom wrapper option was added: `boot.kernelPackages` is already a per-`Host` setting, so other `Host`s pick their own kernel the same way. A string→package wrapper would have been premature abstraction with one `Host` and one kernel, so it was deliberately left out; the "mechanism" is the per-`Host` placement of the native option.
 - **Substituter/key live in the shared base, via the `extra-` options.** They were added to `system/default.nix` (shared by every `Host`), not just neogaia, because the chaotic module is wired for all `Host`s and the cache is general plumbing. `nix.settings.extra-substituters` / `extra-trusted-public-keys` are used rather than the replacing `substituters` / `trusted-public-keys`, so `cache.nixos.org` (and any other substituter) is only appended to, never dropped. chaotic's own module also provides these entries; the explicit declaration is belt-and-suspenders and keeps the built system's cache config visible and independent of that module.
 - **Dev-host build needed a daemon-level cache.** Building the toplevel here first compiled the CachyOS kernel (and rustc bootstrap) from source, because the build daemon's `/etc/nix/nix.conf` had no `nyx-cache` substituter — the built system's `nix.settings` do not govern the daemon doing the build, and the dev user is a non-trusted client that cannot add substituters from the CLI. Adding `extra-substituters`/`extra-trusted-public-keys` for `nyx-cache` to `/etc/nix/nix.conf` (sudo) and restarting `nix-daemon` fixed it; the build then fetched the kernel (7.1.3) from the cache. Recorded as a gotcha in `CLAUDE.md`.
 - **zram is enabled inline, not as a `Module` (criterion 5 dropped).** The task asked for a zram toggle `Module`, and one was built first (`modules/zram.nix`), but PR review rejected it as a single-line abstraction that wraps the native `zramSwap.enable` toggle without adding anything. It was removed, and `neogaia` sets `zramSwap.enable = true` directly, as it did before task 0003. The `Enable convention` reference remains `modules/example.nix`; real feature `Module`s arrive with fish/tmux/nvim/Claude Code in later tasks.
--- a/.claude/tasks/0004-networking-and-base-system.md
+++ b/.claude/tasks/0004-networking-and-base-system.md
@@ -0,0 +1,28 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Make the booted laptop a usable console I can log into and reach remotely: NetworkManager for joining wifi, an SSH daemon for driving the rest of the setup over the network, and the base locale settings.
 Set timezone `America/New_York`, locale `en_GB.UTF-8`, and console keymap `us`.
 ## Acceptance criteria
 - [x] NetworkManager is enabled so wifi can be joined from the console.
 - [x] An SSH daemon is enabled so the machine can be driven remotely.
 - [x] Timezone is `America/New_York`, locale is `en_GB.UTF-8`, console keymap is `us`.
 - [x] The `neogaia` toplevel still builds with all of the above.
 ## Implementation Notes
 - **Placement in the Host, not a Module.** NetworkManager, the SSH daemon, and the locale/timezone/keymap settings all live directly in `hosts/neogaia/default.nix`, alongside the kernel/hardware/zram lines from task 0003.
  This follows the precedent set in that task, where a speculative enable-gated Module was dropped in review in favour of inlining for the single-Host MVI.
  A shared locale Module or a networking Module can be extracted later when a second Host actually needs the same settings; extracting now would be speculative generality.
 - **SSH left unhardened deliberately.** `services.openssh.enable = true` keeps NixOS's default password authentication on.
  This is required by the install flow: first-boot access is over SSH with the hand-set bootstrap password, and no SSH keys or sops-derived age key exist until the install generates the Host's SSH host key.
  Moving to key-only auth / `hashedPasswordFile` is the first post-boot follow-up per the spec's Secrets section, out of scope for the MVI.
 - **Locale/timezone mix is as specified.** `i18n.defaultLocale = "en_GB.UTF-8"` with `time.timeZone = "America/New_York"` and `console.keyMap = "us"` mixes region and locale; this matches the operator's stated preferences verbatim and is intentional.
 - **Verification.** Built the primary seam — `nix build .#checks.x86_64-linux.neogaia` (the Host toplevel) — to exit 0; the systemd units for `wpa_supplicant` (NetworkManager's backend) and openssh appear in the build. The five option values were also confirmed via `nix eval`.
--- a/.claude/tasks/0005-fish-shell-module.md
+++ b/.claude/tasks/0005-fish-shell-module.md
@@ -0,0 +1,44 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 A fish `Module`, configured natively via home-manager, that makes the shell feel like the current CachyOS setup but is correct for NixOS. Translate the existing `cachyos-config.fish` and the rest of the fish snapshot under `reference/home/.config/fish/`: the greeting, the bat-manpager, the `done` and bang-bang plugins, the helper functions, and the eza/nav aliases. Drop or replace every Arch/pacman-specific part with its NixOS equivalent. Set fish as the default login shell.
 Configure the plugins natively through home-manager rather than a fish plugin manager.
 ## Acceptance criteria
 - [x] A fish `Module` (following the `Enable convention`) is enabled on `neogaia` and configured natively via home-manager.
 - [x] The greeting, bat-manpager, `done` and bang-bang plugins, helper functions, and eza/nav aliases from the reference config are reproduced.
 - [x] All Arch/pacman-specific parts are dropped or replaced with NixOS equivalents.
 - [x] fish is the user's default login shell.
 - [x] The `neogaia` toplevel still builds with the fish `Module` enabled.
 ## Implementation Notes
 - **Plugins are native, not inlined.** `done` and `bang-bang` come from `pkgs.fishPlugins.*` via `programs.fish.plugins`; home-manager drops them into `~/.config/fish/conf.d/` where fish auto-sources them.
  The reference config inlined the bang-bang `__history_previous_command` functions and binds by hand; the plugin supplies those, so they are not re-inlined.
 - **`done` tuning uses `set -g`, not `set -U`.** The reference set `__done_min_cmd_duration`/`__done_notification_urgency_level` as universal variables, which persist to the universal-variable file and then ignore config changes.
  A declarative config must own these each session, so they are set global (`set -g`) in `interactiveShellInit`.
 - **Arch/pacman aliases dropped:** `grubup`, `fixpacman`, `mirror` (`cachyos-rate-mirrors`), `apt`/`apt-get` (`man pacman`), `big` (`expac`), `gitpkg`, `rip` (`expac`).
  **Replaced with NixOS equivalents:** `update` → `sudo nixos-rebuild switch` (was `pacman -Syu`), `cleanup` → `sudo nix-collect-garbage -d` (was `pacman -Rns`).
 - **Machine-specific PATH hacks dropped, per spec story 6 ("no impure environment lookup").** The hardcoded `BUN_INSTALL`, the `node-v24...` tarball path, and `~/Applications/depot_tools` from `config.fish` are absolute/impure and are not reproduced; such tooling should be Nix-provided when its own Module arrives.
  The portable bits are kept: `~/.local/bin` on PATH (guarded) and sourcing `~/.fish_profile`.
 - **`env.fish` and `rustup.fish` deliberately not carried over.** `ANDROID_HOME`/platform-tools (Android SDK) and `source ~/.cargo/env.fish` (rust) are dev-toolchain integrations outside the MVI's core tooling (fish/tmux/nvim/Claude Code); they belong to future per-toolchain Modules that provide those tools through Nix rather than sourcing an impure env file.
 - **`hw` (`hwinfo --short`) and `tb` (`nc termbin.com 9999`) dropped.** These are generic rather than pacman-specific, but each needs an extra package (`hwinfo`, a `netcat`) that the minimal install does not otherwise pull in; left out of the MVI and easy to add later.
 - **`copy` kept verbatim** (including the upstream `trim-right` call) to preserve exact parity with the current shell.
 - **Verification.** The `neogaia` system toplevel builds (the spec's primary seam).
  The rendered `~/.config/fish/` was inspected in the build output: aliases, the three helper functions, the `fastfetch` greeting, the bat manpager, the `done` tuning vars, and the `conf.d/plugin-done.fish` + `conf.d/plugin-bang-bang.fish` plugin files are all present; `users.users.alexion.shell` resolves to `pkgs.fish`.
 ### Post-review adjustments
 - **`defaultShell` option.** Setting fish as the login shell moved behind `modules.fish.defaultShell` (default `false`, gated with `mkIf`); `neogaia` opts in explicitly. Enabling the Module alone no longer changes the login shell.
 - **Abbreviation-first.** Every non-eza alias is now a `shellAbbr` (the eza `ls` family stays an alias), `preferAbbrs = true`, and `generateCompletions = true` is pinned rather than left to the upstream default.
 - **vi command-line editing.** `interactiveShellInit` sets `fish_key_bindings fish_vi_key_bindings`; the `bang-bang` plugin re-binds `!`/`$` in insert mode via its own `--on-variable fish_key_bindings` handler, so the switch keeps them working.
 - **Trimmed aliases.** Navigation capped at four dots (`.....`/`......` dropped); `psmem`, `psmem10`, `dir`, `vdir`, and `please` removed.
 - **Interactive init lives in a real fish file.** The Module lives at `modules/fish/fish.nix`; its `interactiveShellInit` is `builtins.readFile ./config.fish`, so the interactive init is written as one editable fish file (vi editing, `EDITOR`/`VISUAL`, the bat manpager, the done plugin tuning, and `~/.local/bin`/`~/.fish_profile`) that home-manager renders into `~/.config/fish/config.fish`. The file is small enough that splitting it into fragments was not worth the indirection; Nix inlines it at build time, so nothing of ours is autoloaded from a separate runtime file.
 - **`copy` stays a function file.** `functions/copy.fish` holds the non-trivial `copy` body, read into the `functions` option; fish autoloads function files lazily, so that is the idiomatic home for a function. Trivial one-liner functions stay inline in `fish.nix`.
 - The Auto-loader only collects `.nix`, so every `.fish` file under `modules/fish/` is inert to it.
--- a/.claude/tasks/0006-tmux-module.md
+++ b/.claude/tasks/0006-tmux-module.md
@@ -0,0 +1,43 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 A tmux `Module`, configured natively via home-manager, that reproduces the current terminal multiplexer exactly: the existing `tmux.conf` text (under `reference/home/.config/tmux/`) inlined verbatim, with no plugin manager needed.
 ## Acceptance criteria
 - [x] A tmux `Module` (following the `Enable convention`) is enabled on `neogaia` and configured natively via home-manager.
 - [x] The existing `tmux.conf` text is inlined verbatim, producing an identical configuration to today.
 - [x] No tmux plugin manager is used.
 - [x] The `neogaia` toplevel still builds with the tmux `Module` enabled.
 ## Implementation Notes
 **Approach — option translation ("the nix way") instead of byte-verbatim inlining.**
 On the operator's explicit call ("I would prefer to do things the nix way. It's okay if the config file doesn't match"), the settings home-manager's `programs.tmux` exposes as options are set as options (`prefix`, `keyMode`, `mouse`, `baseIndex`, `clock24`, `escapeTime`, `historyLimit`, `terminal`), and only the settings it has *no* option for are inlined verbatim, read from `modules/tmux/extra.conf` via `builtins.readFile`.
 The generated `~/.config/tmux/tmux.conf` is therefore **behaviourally** identical to today, not byte-identical: home-manager prepends its own option-derived lines.
 This was preferred over `xdg.configFile.source = ./tmux.conf` (which would have been byte-identical) after weighing both.
 Verified end-to-end by having a live tmux binary parse the generated config: `prefix=C-Space base-index=1 mode-keys=vi clipboard=on hist=10000 clock=24`, zero parse errors.
 **`clock24 = true` is required, not cosmetic.**
 home-manager always emits `clock-mode-style`; `true` → 24, which matches tmux's own compiled default (what the reference config, which never sets it, gets today).
 Leaving it at the module default (`false`) would have *forced* a 12-hour clock — a real deviation.
 **Pane navigation stays in `extra.conf`.**
 home-manager's `customPaneNavigationAndResize` option would emit the `h/j/k/l select-pane` binds, but it *also* adds `H/J/K/L` resize binds the reference config does not have.
 To stay faithful, the `h/j/k/l` binds are inlined in `extra.conf` and the option is left off.
 **`secureSocket` left at the home-manager default (`true`).**
 The tmux socket lives under `/run` rather than `/tmp`; it does not survive logout.
 This differs from stock tmux behaviour and was accepted deliberately.
 **Comments in `extra.conf` rewritten to the project convention.**
 The reference `tmux.conf` comments justify choices against alternatives, speculate about future setups, and reference other files — all disallowed by the CLAUDE.md comment convention.
 Since `extra.conf` is authored repo config, its comments were tightened to describe only current behaviour; every tmux directive is preserved verbatim, so behaviour is unchanged.
 **Version-sensitivity (not a defect today).**
 `programs.tmux.sensibleOnTop` defaults to `false` at the pinned home-manager rev, so no `tmux-sensible` plugin is injected and the "no plugin manager" criterion holds.
 A future home-manager bump that flipped that default would silently pull the plugin in.
--- a/.claude/tasks/0007-nvim-module.md
+++ b/.claude/tasks/0007-nvim-module.md
@@ -0,0 +1,24 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 An nvim `Module` that gives the primary user Neovim configured declaratively through **nixvim**, with **functional parity** to the operator's existing config.
 Parity is about the "what" — the same plugins, keymaps, options, colorscheme, and behaviour — not the "how".
 The mechanism is deliberately free to follow NixOS's declarative paradigm rather than transplanting the imperative lazy.nvim setup: plugins are managed by Nix (no plugin manager, no runtime cloning, no lockfile), and as much of the config as possible is expressed as typed Nix, with raw Lua kept only as an escape hatch.
 ## Acceptance criteria
 - [x] An nvim `Module` (following the `Enable convention`) is enabled on `neogaia`.
 - [x] Neovim is configured via **nixvim**, wired as a flake input (`nixvim.inputs.nixpkgs.follows = "nixpkgs"`), consumed as its home-manager module under `home-manager.users.<user>.programs.nixvim`.
 - [x] Functional parity with the previous config: the same plugins (neogit, diffview, gitsigns, oil, snacks, gbprod-nord, render-markdown, which-key, treesitter), keymaps, `vim` options, the `nord` colorscheme, the Neogit blame-toggle autocmd, and markdown concealment — verified headless against the generated config.
 - [x] Runtime dependencies `git`, `ripgrep`, and `fd` are provided by Nix; `gcc` is not needed because Nix builds the treesitter grammars.
 - [x] The `neogaia` toplevel still builds with the nvim `Module` enabled.
 ## Implementation Notes
 - **nixvim, typed Nix first.** `modules/nvim/nvim.nix` enables `programs.nixvim` with `opts`, `globals`, `keymaps`, and typed `plugins.*` settings. Treesitter uses `plugins.treesitter` (`highlight.enable`, `indent.enable`, `grammarPackages` from the module's own `builtGrammars`) covering nix, lua, bash, fish, markdown, rust, python, java, kotlin, c, cpp, html, css, javascript, typescript, go.
 - **The imperative remainder** — the `gbprod/nord.nvim` setup + colorscheme call, the markdown `conceallevel` autocmd, and the Neogit blame-toggle `BufUnload` autocmd — lives in `modules/nvim/config.lua`, pulled in via `extraConfigLua = builtins.readFile ./config.lua`. `gbprod-nord` comes in through `extraPlugins` because nixvim's `colorschemes.nord` is a different plugin.
 - **Verification.** `nix build .#…programs.nixvim.build.package` exits 0 and the whole toplevel evaluates. The generated config was exercised headless (launched with `-u` the generated init and a scratch `HOME`, since the wrapper otherwise loads the dev host's real `~/.config/nvim`): all options, keymaps, plugins, the `nord` colorscheme, treesitter highlight + indent, and markdown conceal load with no errors.
--- a/.claude/tasks/0008-claude-code-module.md
+++ b/.claude/tasks/0008-claude-code-module.md
@@ -0,0 +1,23 @@
 ---
 spec: laptop-mvi
 blocked-by: 0001-skeleton-and-building-host
 ---
 ## What to build
 Install Claude Code declaratively on `neogaia`, and make it authenticatable without a browser on the laptop so it can be used over the console/SSH via the paste-code flow or an API key.
 ## Acceptance criteria
 - [x] Claude Code is installed declaratively (following the `Enable convention` if expressed as a `Module`) and enabled on `neogaia`.
 - [x] The browserless authentication path (paste-code flow or API key) is documented so it works over console/SSH.
 - [x] The `neogaia` toplevel still builds with Claude Code included.
 ## Implementation Notes
 - **Native home-manager module, not a raw package.** Claude Code is enabled through home-manager's own `programs.claude-code` module (`home-manager.users.<user>.programs.claude-code.enable = true`), mirroring how `tmux`/`fish` use their native home-manager options rather than dropping a package into `home.packages`. The module ships within home-manager itself, so — unlike `nvim`/nixvim — no new flake input is needed. Per the invocation's steer to prefer the tmux/nvim conventions over the task wording, the feature `Module` at `modules/claude-code/claude-code.nix` is kept as thin as the `tmux` module: just the `enable` option and the delegation.
 - **No settings written.** The module manages no `~/.claude` contents and writes no `settings.json`, so login and first-run configuration stay interactive. This keeps auth material (subscription token or API key) out of the repo.
 - **Auth docs co-located with the module.** The browserless authentication guide lives at `modules/claude-code/authentication.md`, next to the module, following the repo pattern where each module directory holds its own supporting files. It covers both the paste-code OAuth flow (open the printed URL on another device, paste the code back — works unchanged over SSH) and the `ANTHROPIC_API_KEY` path. This is distinct from task 0009's OS-install docs, which cover `disko-install`, not the CLI login.
 - **Verification.** `nix build .#checks.x86_64-linux.neogaia` (the primary Host seam) builds the toplevel with `claude-code-2.1.209` included; `config.modules.claude-code.enable` and the home-manager `programs.claude-code.enable` both evaluate `true`.
 - **Note on flake evaluation.** The new module file had to be `git add`ed before the flake could see it — flakes evaluate the git tree, so an untracked Module is invisible to the Auto-loader and the host errors with "option does not exist".
 - **Personal config ported into the Module (beyond the acceptance criteria).** At the operator's request the declarative half of `~/.claude` now lives in the Module and is applied when it is enabled: the global agent instructions (`context = ./CLAUDE.md`), the skills tree (`skills = ./skills`, 15 skills), the attention-bell hook (`hooks."attention-bell.sh"`), and `settings.json` (`model = "opus"` plus the Stop/Notification/SessionStart hook wiring). Runtime state (`projects/`, `plugins/`, `cache/`, `history.jsonl`, sessions) and the `~/.claude/.credentials.json` secret are deliberately left out, so login survives rebuilds and no secret enters the repo. Stale `agents`/`commands` symlinks (into an outdated `~/wrk/claude`) were skipped. Verified against the built `home-files`: `~/.claude/{CLAUDE.md,settings.json,skills/,hooks/attention-bell.sh}` are all generated, with the hook executable. The `gitea-axi` SessionStart hook depends on that binary being on `PATH`; the flake does not yet provide it, so the hook is a no-op on a host until it is installed.
--- a/.claude/tasks/0009-install-flow-docs.md
+++ b/.claude/tasks/0009-install-flow-docs.md
@@ -0,0 +1,36 @@
 ---
 spec: laptop-mvi
 blocked-by: [0002-neogaia-disk-and-boot, 0003-kernel-and-hardware, 0004-networking-and-base-system, 0005-fish-shell-module, 0006-tmux-module, 0007-nvim-module, 0008-claude-code-module]
 ---
 ## What to build
 Document the one-shot install procedure that turns the completed `neogaia` `Host` into a running encrypted laptop from the NixOS live ISO — the capstone, written once every functional slice is in place so it describes the actually-complete `Host`.
 The procedure: push the repo to Gitea first; from the live ISO, join wifi, clone the repo locally (avoiding self-signed-TLS/auth problems with flake fetching during install), and run `disko-install` against the `neogaia` `Host` with the chaotic substituter passed to the install-time Nix daemon (or it compiles the CachyOS kernel from source on the USB stick). Then set the bootstrap password by hand via `nixos-enter` — never committed to the public repo — and reboot.
 Note the bootstrap ordering (the flake must exist on Gitea before the install can consume it) and that moving the password to a `hashedPasswordFile` backed by a sops secret is the first post-boot task, out of scope here (per ADR 0001, an age key does not exist until the first install generates the SSH host key).
 ## Acceptance criteria
 - [x] The install procedure is documented end to end: push to Gitea → join wifi on the live ISO → clone locally → `disko-install` against `neogaia` → set bootstrap password via `nixos-enter` → reboot.
 - [x] The docs state that the install-time Nix daemon must have the chaotic substituter configured, or the kernel compiles from source on the USB stick.
 - [x] The docs explain that the local clone avoids self-signed-TLS/auth problems with flake fetching during install.
 - [x] The bootstrap password is set by hand and never committed; the docs flag the sops-backed `hashedPasswordFile` migration as the first post-boot follow-up.
 ## Implementation Notes
 The runbook lives at `docs/install.md`.
 Every documented command was checked against the actual pinned tooling rather than written from memory:
 - The `disko-install` and `disko` flags (`--flake`, `--disk NAME DEVICE`, `--write-efi-boot-entries`, `--option`, `--mode mount`) were read out of the pinned disko revision's wrapped scripts (the disko rev in `flake.lock`).
 - A consequence surfaced there and shaped the doc: `disko-install` traps `EXIT` and **unmounts** the target, so the "set the bootstrap password" step must first remount with `disko --mode mount` before `nixos-enter`.
  A naive `nixos-enter --root /mnt` straight after the install would have found nothing mounted.
 - The chaotic substituter URL and trusted key are quoted verbatim from `system/default.nix`, and `--disk main /dev/nvme0n1` matches `hosts/neogaia/disk.nix`.
 Two secrets are set by hand at install time, not one: the doc distinguishes the **LUKS passphrase** (prompted by disko at format, typed at every boot) from the **bootstrap login password** (set via `nixos-enter passwd`).
 The task named only the login password; the LUKS passphrase is an unavoidable part of the same by-hand flow, so it is documented alongside for a complete runbook.
 Beyond the task's terse list, the doc adds: a minimal-vs-graphical ISO split for joining wifi, and — from review — an SSH-key caveat for the clone plus an HTTPS-with-`sslVerify=false` fallback (which also reinforces the "git can skip verification where the flake fetcher can't" point behind the local-clone requirement).
 No criteria were dropped.
--- a/.config/alacritty/alacritty.toml
+++ b/.config/alacritty/alacritty.toml
@@ -1,88 +0,0 @@
 [general]
 working_directory = "None"
 live_config_reload = true
 [env]
 TERM = "xterm-256color"
 WINIT_X11_SCALE_FACTOR = "1.0"
 [window]
 dimensions = { columns = 100, lines = 30 }
 dynamic_padding = true
 decorations = "Full"
 opacity = 0.8
 title = "Alacritty@CachyOS"
 class = { instance = "Alacritty", general = "Alacritty" }
 decorations_theme_variant = "Dark"
 [scrolling]
 history = 10000
 multiplier = 3
 [font]
 normal = { family = "MesloLGS Nerd Font Mono", style = "Regular" }
 bold = { family = "MesloLGS Nerd Font Mono", style = "Bold" }
 italic = { family = "MesloLGS Nerd Font Mono", style = "Italic" }
 bold_italic = { family = "MesloLGS Nerd Font Mono", style = "Bold Italic" }
 size = 12.0
 [colors]
 draw_bold_text_with_bright_colors = true
 [colors.primary]
 background = "0x2E3440"
 foreground = "0xD8DEE9"
 [colors.normal]
 black = "0x3B4252"
 red = "0xBF616A"
 green = "0xA3BE8C"
 yellow = "0xEBCB8B"
 blue = "0x81A1C1"
 magenta = "0xB48EAD"
 cyan = "0x88C0D0"
 white = "0xE5E9F0"
 [colors.bright]
 black = "0x4C566A"
 red = "0xBF616A"
 green = "0xA3BE8C"
 yellow = "0xEBCB8B"
 blue = "0x81A1C1"
 magenta = "0xB48EAD"
 cyan = "0x8FBCBB"
 white = "0xECEFF4"
 [selection]
 semantic_escape_chars = ",│`|:\"' ()[]{}<>\t"
 save_to_clipboard = true
 [cursor]
 style = { shape = "Underline", blinking = "Off" }
 unfocused_hollow = true
 thickness = 0.15
 [mouse]
 hide_when_typing = true
 bindings = [
 { mouse = "Middle", mods = "None", action = "PasteSelection" },
 ]
 [keyboard]
 bindings = [
 { key = "Paste", mods = "None", action = "Paste" },
 { key = "Copy", mods = "None", action = "Copy" },
 { key = "L", mods = "Control", action = "ClearLogNotice" },
 { key = "L", mods = "Control", mode = "~Vi", chars = "\f" },
 { key = "PageUp", mods = "Shift", mode = "~Alt", action = "ScrollPageUp" },
 { key = "PageDown", mods = "Shift", mode = "~Alt", action = "ScrollPageDown" },
 { key = "Home", mods = "Shift", mode = "~Alt", action = "ScrollToTop" },
 { key = "End", mods = "Shift", mode = "~Alt", action = "ScrollToBottom" },
 { key = "V", mods = "Control|Shift", action = "Paste" },
 { key = "C", mods = "Control|Shift", action = "Copy" },
 { key = "F", mods = "Control|Shift", action = "SearchForward" },
 { key = "B", mods = "Control|Shift", action = "SearchBackward" },
 { key = "C", mods = "Control|Shift", mode = "Vi", action = "ClearSelection" },
 { key = "Key0", mods = "Control", action = "ResetFontSize" },
 ]
--- a/.config/dot/.claude/scheduled_tasks.lock
+++ b/.config/dot/.claude/scheduled_tasks.lock
@@ -1 +0,0 @@
 {"sessionId":"d1732179-27b7-49fb-82af-6669b783a444","pid":45537,"procStart":"7266197","acquiredAt":1783288905666}
--- a/.config/dot/.claude/spec/dot-kde.md
+++ b/.config/dot/.claude/spec/dot-kde.md
@@ -1,76 +0,0 @@
 ## Problem Statement
 Several KDE settings on this machine have already been changed by hand away from their KDE/CachyOS defaults — the caps-lock/Escape swap is live right now, and screenshot-related keybind changes (Spectacle bindings, moving Lock Session off `Meta+L`) are planned next — but none of this is tracked anywhere in the dotfiles repo. If the machine were rebuilt today, these settings would silently revert to defaults with no record of what needs to be reapplied. There's also no way to notice *unexpected* drift (a setting that changed without the owner deliberately choosing to change it), and no tooling to bring a manually-tweaked setting under tracking without hand-writing one-off `kwriteconfig6`/D-Bus calls — exactly the accumulation of ad hoc scripts the dotfiles project has otherwise avoided.
 ## Solution
 Add a `dot kde` subcommand family with three verbs:
 - **`dot kde apply`** — pushes every setting declared in a tracked manifest onto the live KDE session (repo → system).
 - **`dot kde diff`** — a broad, read-only scan reporting every live KDE setting that differs from its default, tagging each mismatch as either already-declared (in the manifest) or undeclared (system → discovery, no write).
 - **`dot kde save`** — the write path into the manifest (system → repo). Run with no arguments, it refreshes every already-declared entry's stored value from the live system. Run with explicit coordinates, it begins tracking one new setting, seeded from its current live value.
 The manifest is a single flat, mechanism-agnostic file: opaque `identifier=value` lines. `dot kde` internally figures out *how* to read/write a given identifier (three different underlying mechanisms exist across KDE's config surface), so the manifest itself never needs to know or care how KDE happens to store that particular setting.
 ## User Stories
 1. As the machine owner, I want to declare that a KDE setting should have a specific value, so that a freshly-built machine ends up with the same intentional deviations from KDE's defaults without me re-discovering and re-typing the underlying `kwriteconfig6`/D-Bus incantations.
 2. As the machine owner, I want `dot kde apply` to push all declared settings onto a live session in one idempotent command, so that re-running it after a KDE update or on a new machine is safe and has no unintended side effects.
 3. As the machine owner, I want `dot kde diff` to show me every KDE setting currently different from default, so that I can catch drift I didn't intend, not just check the handful of settings I already know about.
 4. As the machine owner, I want `dot kde diff`'s output to distinguish "this is already declared and intentional" from "this is undeclared and I've never seen it before," so that the noise of broad scanning doesn't bury genuinely unexpected changes.
 5. As the machine owner, I want to run `dot kde save` with no arguments and have every already-tracked setting's manifest value refreshed from whatever is currently live, so that if I tweak a tracked setting by hand (e.g. change a keybind in System Settings) the manifest catches up without me re-typing its identifier.
 6. As the machine owner, I want to run `dot kde save` with an explicit identifier to begin tracking one specific setting I just noticed via `diff`, so that I control exactly what enters the manifest instead of everything non-default being swept in at once.
 7. As the machine owner, I want global keyboard shortcuts to be read and written through KDE's own shortcut-management service rather than by hand-editing `kglobalshortcutsrc`, so that changes take effect immediately in the running session and I never have to reconstruct KDE's internal triplet bookkeeping (current/default/friendly-name) myself.
 8. As the machine owner, I want KConfigXT-schema-backed settings to have their "default" value discovered automatically wherever KDE's schema declares it, so that broad drift-scanning covers as much of the KDE config surface as possible without me manually cataloguing every setting I might ever care about.
 9. As a future contributor to this dotfiles repo, I want `dot kde`'s subcommand files to live alongside its Python helper in one place, discoverable the same way every other `dot` subcommand is, so that adding this feature doesn't require bespoke wiring outside the established convention.
 ## Implementation Decisions
 - **Subcommand family**: `dot kde apply` / `dot kde diff` / `dot kde save`, following the project's existing nested-subcommand dispatch convention (each level checks for `help` as its first positional argument before `argparse`, calling its own usage function).
 - **`dot kde save` has two modes**:
  - No arguments: iterate every identifier already in the manifest, read its current live value via the appropriate mechanism, and rewrite the manifest with the refreshed value.
  - Explicit coordinates given: read the current live value for that one setting and add it to the manifest as a new declared entry. This is the only way new entries enter the manifest — there is no bulk/"track everything currently non-default" mode, by design, so that curation stays deliberate.
 - **`dot kde diff`**: enumerates every setting it knows how to check (see mechanisms below), compares live vs. default, and reports every mismatch. Each reported mismatch is tagged as declared (present in the manifest, i.e. an intentional, already-tracked deviation) or undeclared (never explicitly declared). Diff never writes anything.
 - **Manifest**:
  - Location: a flat file directly under `~/.config/dot/` (not nested in a subdirectory — no near-term plan for multiple KDE-like targets that would justify one), named to convey "the set of KDE settings intentionally different from default."
  - Format: plain text, one entry per line, `identifier=value`, split on the *first* `=` only (so values may themselves contain `=`).
  - Identifier scheme: `file.group.key`, split on the first two `.`s only (so the key portion may contain further dots, spaces, or other characters freely — relevant for `kglobalshortcutsrc` action names, which can contain spaces).
  - The manifest carries no mechanism/type discriminator field. It is a pure `identifier → value` map; `dot kde` decides internally how to resolve a given identifier.
 - **Three underlying mechanisms**, dispatched purely by inspecting the identifier (no stored metadata):
  1. **Shortcuts** (`kglobalshortcutsrc.<componentUnique>.<actionUnique>`) — resolved not by editing the rc file directly, but through KDE's `kglobalaccel` D-Bus service:
     - Read current value: `shortcut(actionId)`.
     - Read default value: `defaultShortcut(actionId)`.
     - Write: `setShortcut(actionId, keys, flags)` with `flags = NoAutoloading` (so the declared value always wins over any previously-saved shortcut; using the `Autoloading` flag would make `apply` a no-op after the first run).
     - `actionId` is a 4-element list: `[componentUniqueName, actionUniqueName, componentFriendlyName, actionFriendlyName]` (confirmed against KDE's own `actionIdFields` enum and verified live via `gdbus`). Only `componentUnique`/`actionUnique` are stored in the manifest; the two friendly-name fields (needed to actually place the D-Bus call) are resolved dynamically at call time by looking up the component's shortcut list, not stored.
     - No read-modify-write is needed for this mechanism — `setShortcut` only ever touches the live/current value, never the default, so there's no risk of clobbering KDE's own bookkeeping.
  2. **KConfigXT schema-backed settings** (most `kwinrc`, `kdeglobals`, etc. entries) — read/write via `kreadconfig6`/`kwriteconfig6`; the "default" value comes from the setting's `.kcfg` schema.
     - The `(rcfile → [kcfg files])` mapping table is auto-derived at runtime by scanning the system's `.kcfg` schema directory for files that statically declare their target rc file (`<kcfgfile name="...">`), plus a small hand-maintained list for the exceptions that declare `<kcfgfile arg="true">` (i.e. the target file is only known at runtime by the owning app, not in the schema — `kwin.kcfg` is a known example).
     - This mechanism is what enables `diff`'s broad-scan coverage: every entry reachable through the mapping table can be checked automatically, not just entries someone has already thought to add to the manifest.
  3. **Freeform/schema-less settings** (e.g. `kxkbrc`'s `Options=` line) — read/write via `kreadconfig6`/`kwriteconfig6`; there is no schema, so "default" is defined as "the key is absent." Because there's no schema to enumerate from, this mechanism cannot participate in broad undeclared-drift discovery the way schema-backed settings can — it can only be checked for settings that are already declared in the manifest.
  - Mechanism selection for a given identifier: if the rc file is `kglobalshortcutsrc`, use the shortcuts mechanism; otherwise, if the mapping table resolves the `(rcfile, group, key)` to a schema, use the schema-backed mechanism; otherwise, treat it as freeform.
 - **File/module layout**: the fish dispatcher and its Python helper live together in one subdirectory under the project's existing commands location, rather than the Python helper sitting as a same-directory sibling of a same-named fish file at the top level.
 - **Cross-cutting change to `dot` itself**: the subcommand-discovery mechanism (used both for help-listing and for dispatch) is extended to glob one additional directory level deep, not just the flat top level — required to support the subcommand-plus-helper layout above. This must be updated in both places the discovery logic currently exists (they are intentionally duplicated today rather than shared, for fish-autoload reasons), and applies to any future subcommand that wants a companion file, not just this one.
 ## Testing Decisions
 - **Guiding principle**: tests should exercise this feature's own logic (manifest parsing, identifier dispatch, mapping-table auto-derivation, mechanism selection), not re-verify that external dependencies (`kreadconfig6`, `kwriteconfig6`, the KDE session itself) work correctly.
 - **Primary seam**: full CLI invocation of `dot kde apply` / `dot kde diff` / `dot kde save`, run against a scratch `$HOME`, mirroring the existing project convention for testing `dot` subcommands (override `$HOME` per test case, no mocking of the real `kreadconfig6`/`kwriteconfig6` binaries — they run for real against fixture rc files under the scratch home). This covers the schema-backed and freeform mechanisms end-to-end: manifest read/write, identifier parsing, mechanism dispatch, and mapping-table-driven default lookup.
 - **New seam introduced for this feature**: the KConfigXT schema directory is normally a fixed system path outside `$HOME`. To make the auto-derivation logic testable without depending on (or mutating) the real system's schema files, the schema directory location must be overridable (e.g. via an environment variable), defaulting to the real system path in normal use and pointing at a small fixture directory of synthetic `.kcfg` files in tests.
 - **Deliberately not covered by automated tests**: the shortcuts mechanism (`kglobalaccel` D-Bus calls). It depends on a live, already-running session service that isn't practically substitutable without building dedicated mock infrastructure, which is disproportionate to what it would protect (three D-Bus calls). This path is verified manually against the real session instead.
 - **Prior art**: the existing test suite for `dot`'s other subcommands already establishes the scratch-`$HOME`-plus-`fishtape` pattern this feature reuses.
 ## Out of Scope
 - A `dot setup`-style subcommand for machine bootstrap tasks (extra groups, etc.) — considered during planning and set aside as not currently relevant.
 - Folder naming / XDG user-dirs conventions — a real, separate piece of planned work, but standalone from `dot kde` and not part of this spec.
 - Tracking Plasma's panel layout (`plasma-org.kde.plasma.desktop-appletsrc`) — previously decided this doesn't need tracking, since the current panel is CachyOS's own shipped default and reproduces automatically on a fresh install.
 - An "empirical fallback" mechanism (spinning up a scratch config environment to let an app generate its own default config for diffing) — not needed given the three mechanisms above cover everything currently in scope; noted only as a possible future extension if some setting fits none of them.
 - A bulk/`--all` mode for `dot kde save` — deliberately excluded so that every new manifest entry is a deliberate choice.
 - Interactive picker UX for `diff`/`save` (e.g. selecting an undeclared entry from a list rather than typing its identifier) — not part of this spec.
 - `dot voice` (hands-free dictation) — an unrelated, separately shelved piece of work, not touched by this feature.
 ## Further Notes
 - The caps-lock/Escape swap (`kxkbrc`'s `Options=caps:escape_shifted_capslock`) is already live on this machine by hand, unrecorded anywhere — it's a ready-made first real candidate for the explicit-coordinates form of `dot kde save` once built, and a natural first end-to-end smoke test beyond the automated suite.
 - The screenshot-related keybind work (Spectacle bindings, moving Lock Session off `Meta+L` to `Meta+X`, renaming Spectacle's save folder) was the original motivating case for this feature but is applied *through* `dot kde apply`/`save` rather than being separate work — once `dot kde` exists, those keybind changes are just manifest entries.
 - Per the project's own cross-cutting convention, once any keybind changes are actually applied via this feature, the corresponding rows in the project's keybindings reference document need to be added/updated in the same change.
--- a/.config/dot/.claude/spec/dot-setup-folders.md
+++ b/.config/dot/.claude/spec/dot-setup-folders.md
@@ -1,59 +0,0 @@
 ## Problem Statement
 The old `~/wrk/dotfiles` repo's `setup_folders` (part of its bash `bin/dot init`) renamed the standard XDG user folders to short names (`Documents→doc`, `Downloads→dwn`, etc.) for better fish shell-completion ergonomics — shorter shared prefixes are easier to disambiguate by typing fewer characters. That behavior has no equivalent in the new bare-repo `dot` CLI. Right now this machine's `user-dirs.dirs` is untracked and has drifted from even the old convention: it uses the full XDG default names, plus an ad hoc `XDG_PROJECTS_DIR=$HOME/Projects` line that never existed in the old repo at all. If this machine were rebuilt today, none of the short-name convention would be restored, and the current drifted state isn't recorded anywhere.
 ## Solution
 Add a `folders` task to a new `dot setup` subcommand family (the general home for idempotent, re-runnable machine-setup tasks, as opposed to `dot init`'s one-shot bootstrap). `dot setup folders` brings the 8 standard XDG user directories under the project's short-name convention, tracks the resulting `user-dirs.dirs` directly as a plain dotfile, and safely migrates any content sitting in the old, full-named folders into their short-named replacements.
 `~/wrk` (already in active use, e.g. `~/wrk/dotfiles`) replaces the old `Projects`-style folder as the general working-files location, but is treated as a plain convention-only directory, not a tracked XDG category.
 ## User Stories
 1. As the machine owner, I want the standard XDG user folders renamed to short names (`doc`, `dwn`, `mus`, `pic`, `vid`, `.desktop`), so that fish-completion on my home directory has shorter, easier-to-disambiguate shared prefixes than the full XDG default names.
 2. As the machine owner, I want `Templates` and `Public` (both unused) collapsed into a single hidden `.ignoreme` folder, so that apps respecting `XDG_TEMPLATES_DIR`/`XDG_PUBLICSHARE_DIR` don't scatter files directly into `$HOME`, without needing two separate unused folders.
 3. As the machine owner, I want the nested `Pictures/Screenshots` folder lowercased to `pic/screenshots` in the same pass as the `Pictures→pic` rename, so that the screenshot folder matches the rest of the short-folder naming convention without a separate migration step.
 4. As the machine owner, I want `~/wrk` to have no XDG variable pointing at it, so that a non-standard, barely-recognized XDG extension (`XDG_PROJECTS_DIR`) doesn't get tracked for a directory that already works fine as a plain convention.
 5. As the machine owner, I want `user-dirs.dirs` tracked directly in the bare dotfiles repo like any other plain dotfile, so that the desired short names are recorded and restorable on a fresh machine without needing a code-generation step.
 6. As the machine owner, I want `dot setup folders` to migrate content out of any legacy full-named folder into its short-named replacement automatically when the legacy folder is empty, so that re-running setup on a fresh install requires no manual folder shuffling.
 7. As the machine owner, I want `dot setup folders` to stop and ask for explicit confirmation before moving anything out of a legacy folder that actually has content in it, so that I never silently lose files to an automated migration I forgot was going to run.
 8. As the machine owner, I want confirmation to be satisfiable via a `--yes` flag rather than an interactive prompt, so that the same command works identically whether I'm running it by hand or from an automated/tested context.
 9. As the machine owner, I want a filename collision between a legacy folder and an already-populated short-named target to never be silently overwritten, so that re-running the migration after a partial/interrupted prior run can't destroy a file just because both sides happen to have a same-named entry.
 10. As the machine owner, I want to be told which files were skipped due to a collision and have the legacy folder left in place when that happens, so that I have a clear, actionable signal that something needs manual attention instead of silent partial data loss.
 11. As the machine owner, I want `dot setup folders` to notify running apps of the directory changes via `xdg-user-dirs-update` after migrating, so that session-long apps pick up the new paths without requiring a full logout/login.
 12. As the machine owner, I want to run `dot setup` with no arguments to perform every machine-setup task (folders plus future ones like extra groups) in one command, so that setting up a fresh machine doesn't require remembering and running each task individually.
 13. As the machine owner, I want to also be able to run `dot setup folders` on its own, so that I can re-run just this one task in isolation (e.g. after a confirmation was declined) without re-running unrelated setup tasks.
 ## Implementation Decisions
 - **Subcommand family**: `dot setup`, following the project's existing nested-subcommand dispatch convention (`help`-then-`argparse`, `_dot_<name>_usage`). Bare `dot setup` (no arguments) runs every machine-setup task unconditionally (folders, plus future tasks such as extra groups, mirroring the old bash `bin/dot init`'s dual-mode: no-args ran everything, an explicit keyword ran just one task). `dot setup folders` runs just the folders task.
 - **Folder mapping** (identical to the old repo's `setup_folders`, no changes): `Desktop→.desktop`, `Documents→doc`, `Downloads→dwn`, `Music→mus`, `Pictures→pic`, `Videos→vid`, `Templates→.ignoreme`, `Public→.ignoreme`. `Templates` and `Public` both point at the *same* `.ignoreme` folder, as before.
 - **Nested screenshots rename**: as part of the same `Pictures→pic` migration pass, the nested `Screenshots` folder (currently created empty by KDE/Spectacle defaults) is renamed to lowercase `screenshots`, so the result is `pic/screenshots`. This is folded into the folders task rather than deferred to the separate Spectacle-keybind work, since it's the same naming-convention concern and falls out for free once `Pictures/*` is moved into `pic/`.
 - **`wrk` is out of the XDG mapping**: no `XDG_PROJECTS_DIR` (or any other XDG variable) is written for it. It's a plain, convention-only directory. The currently-existing ad hoc `~/Projects` folder (created by this machine's diverged, untracked `user-dirs.dirs`) is left alone — out of scope for the folders task, since it was never one of the 8 standard XDG categories the task manages, and it's empty and harmless.
 - **`user-dirs.dirs` is tracked directly** as a plain dotfile in the bare repo (not generated/overwritten by `dot setup folders` from a hardcoded table each run) — unlike KDE's rc files (tracked via a separate declarative-manifest mechanism, see the `dot-kde` spec), `user-dirs.dirs` has no volatile/machine-specific fields, so it fits the same direct-tracking treatment as any other plain dotfile (`.bashrc`, etc.). The tracked file is the single source of truth for the desired short names.
 - **`dot setup folders` still needs a small hardcoded table** mapping each of the 8 standard XDG categories to its legacy default folder name (`Documents`, `Downloads`, etc.) — this is used purely to locate content left behind by a fresh XDG-defaults install and merge it into the already-tracked short-named target; it is not the source of truth for the target names themselves (that's the tracked `user-dirs.dirs`).
 - **Migration safety, per legacy folder**:
  - Empty (strict check: any file at all, including dotfiles/metadata like a stray KDE `.directory` file, counts as non-empty) → merge silently, no prompt.
  - Non-empty → print what would be moved and require an explicit `--yes` flag before proceeding. No interactive prompt.
  - Collisions (a same-named entry exists in both the legacy folder and its short-named target) → use no-clobber semantics (e.g. `mv -n`) so a colliding file is never silently overwritten; report which files were skipped; leave the legacy folder in place (don't remove it) if any collision occurred, rather than deleting a folder that still holds something that couldn't be merged.
 - **Post-migration step**: run `xdg-user-dirs-update` (no arguments) once folder moves are complete, to notify running apps/portals via its D-Bus signal. This is safe against the hand-tracked file — `user-dirs.dirs`'s own header documents that local edits are preserved across runs of the tool.
 ## Testing Decisions
 - **Guiding principle**: test the folders task's own logic (mapping, empty-vs-non-empty gating, `--yes` behavior, collision handling, idempotency) through the real CLI entry point, not the internals of `mv`/`mkdir` themselves.
 - **Primary seam**: full CLI invocation of `dot setup folders` (and bare `dot setup`), run against a scratch `$HOME` per test case — the existing project convention (see `dot install`'s tests). No new seam is introduced.
 - **External command handling**: `xdg-user-dirs-update` is faked out via a `PATH`-prepended fake binary that logs its invocation (and exit code), exactly mirroring how `sudo`/`pacman` are faked for `dot install`'s tests. Real `mkdir`/`mv`/`rmdir` run for real against the scratch `$HOME` — no need to fake filesystem operations themselves.
 - **Cases to cover**: fresh migration of empty legacy folders (no `--yes` needed); a legacy folder with real content refuses without `--yes` and proceeds with it; the nested `Pictures/Screenshots→pic/screenshots` rename; a stray dotfile (e.g. a fake `.directory`) in an otherwise-"empty" legacy folder still triggers the confirmation gate; a filename collision between legacy and target is skipped (not overwritten), reported, and leaves the legacy folder in place; re-running `dot setup folders` after a clean migration is a no-op (idempotency); bare `dot setup` runs the folders task as part of running everything; `dot setup folders help` prints usage and touches nothing.
 - **Prior art**: `tests/dot.fish`'s existing scratch-`$HOME`-plus-`fishtape` pattern, and specifically the fake-`sudo`/fake-`pacman`-via-`PATH` technique used for `dot install`.
 ## Out of Scope
 - The **extra groups** task (`dot setup groups` or similar, porting the old `.extra_groups`/`setup_users` behavior) — it will share the same `dot setup` dispatcher and dual-mode (bare-runs-everything vs. named-task) shape decided here, but its own design (group list format, idempotency, etc.) was not addressed in this spec.
 - Any KDE-side settings (caps-lock/Escape swap, screenshot keybinds, Lock Session rebind) — covered separately by the `dot-kde` spec/design.
 - Removing the currently-existing, now-orphaned `~/Projects` folder — explicitly left alone, not cleaned up by this feature.
 - Any `~/.github/README.md` command-table row or `~/.github/keybindings.md` update — not applicable here (no keybind changes), but the README row is still required by the project's standard "adding a subcommand" checklist at implementation time.
 ## Further Notes
 - The old bash `setup_folders`'s naive `mv $from/* $to` has a latent bug this design deliberately avoids: an unquoted glob against an empty directory can misbehave, and it has no collision protection at all. The no-clobber-plus-report behavior specified here is a deliberate improvement over the old script's behavior, not a straight port.
 - This spec covers only the `folders` task; `dot setup` itself (the dispatcher, `_dot_setup_usage`, wiring into `commands/`, the completions/help-glob duplication point noted in the project's `CLAUDE.md`) needs to exist as scaffolding for this task to attach to, even though its only other planned task (extra groups) is out of scope here.
--- a/.config/dot/.claude/spec/dot-setup-nvim.md
+++ b/.config/dot/.claude/spec/dot-setup-nvim.md
@@ -1,46 +0,0 @@
 ## Problem Statement
 On a freshly cloned dotfiles checkout (or any machine where `~/.local/share/nvim/lazy/` is empty or stale), `lazy.nvim` only discovers that plugins are missing when `nvim` is actually launched. The first interactive launch then silently spends a long time cloning `nord.nvim`, `nvim-treesitter`, and `render-markdown.nvim` and compiling every `nvim-treesitter` parser listed in `ensure_installed`, with no obvious progress indication in a normal terminal session — it reads as "nvim isn't starting" rather than "nvim is installing plugins." Nothing in `dot` proactively drives this sync, even though the exact plugin versions are already pinned and tracked in `~/.config/nvim/lazy-lock.json`.
 Separately, `nvim-treesitter`'s parser build step has a known race: concurrent parser installs can collide on a relative `tree-sitter-<lang>-tmp` directory, causing one parser (e.g. `bash`) to fail to compile. Because the compiled `.so` never lands in `~/.local/share/nvim/lazy/nvim-treesitter/parser/`, that parser gets retried (and can fail again) on every subsequent `nvim` launch until it eventually succeeds — a silent, recurring cost with no clear signal to the user that anything is wrong.
 ## Solution
 Add an `nvim` task to the `dot setup` family (introduced by the `dot-setup-folders` spec as the general home for idempotent, re-runnable machine-setup tasks). `dot setup nvim` drives a headless `nvim` session that syncs installed plugins to exactly what `lazy-lock.json` already pins, and verifies afterward that every pinned plugin actually landed on disk — turning a silent, ambiguous first-launch stall into an explicit, scriptable, pass/fail setup step. Bare `dot setup` (no task name) runs this alongside `folders` (and any future tasks).
 ## User Stories
 1. As the machine owner, I want `dot setup nvim` to install/sync every plugin pinned in `lazy-lock.json` before I ever open `nvim` interactively, so that my first real editing session isn't interrupted by an unexplained multi-second-to-multi-minute stall that looks like a hang.
 2. As the machine owner, I want `dot setup nvim` to use the already-tracked `lazy-lock.json` as the source of truth (not re-resolve latest versions), so that a fresh machine ends up with the exact plugin commits I've already vetted, not whatever is newest upstream that day.
 3. As the machine owner, I want `dot setup nvim` to exit non-zero and say clearly which plugin(s) failed to install, so that a partial/broken sync is an obvious, actionable failure rather than something I only notice later inside nvim.
 4. As the machine owner, I want re-running `dot setup nvim` when everything is already in sync to be a fast no-op that still exits 0, so that it's safe to include unconditionally in `dot setup`'s bare "run everything" mode without slowing down every re-run.
 5. As the machine owner, I want to be able to run `dot setup nvim` in isolation (not just as part of bare `dot setup`), so that I can re-sync plugins on their own after e.g. manually editing `lazy-lock.json` or clearing the plugin directory.
 6. As the machine owner, I want `dot setup nvim help` to print usage without touching any plugin state, so that it's consistent with every other `dot` subcommand's `help` behavior.
 ## Implementation Decisions
 - **Subcommand family**: lives under the `dot setup` dispatcher established by the `dot-setup-folders` spec — same nested-subcommand convention (`help`-then-`argparse`, `_dot_setup_nvim_usage`), same dual-mode shape (bare `dot setup` runs every task; `dot setup nvim` runs just this one). This spec does not re-describe the shared dispatcher scaffolding itself; see `dot-setup-folders.md` for that.
 - **Core action**: run `nvim --headless "+Lazy! restore" +qa`. `Lazy! restore` checks out every plugin in the spec to the exact commit recorded in `lazy-lock.json` (installing it first via clone if missing), so it both fixes "missing plugin" and "plugin present but on the wrong commit" in one call. No separate `TSUpdate`/`TSInstall` step is needed: because none of the current plugins (`nord.nvim`, `nvim-treesitter`, `render-markdown.nvim`) declare a lazy-loading trigger (`event`/`cmd`/`ft`), they load eagerly as part of this same headless session, which drives `nvim-treesitter`'s own `ensure_installed` parser-compilation step as a natural side effect — matching what was observed when reproducing the issue.
 - **Failure detection**: `nvim`'s process exit code from `--headless ... +qa` does not reliably reflect whether `Lazy! restore` itself succeeded (Lazy reports failures via its own UI/messages, not necessarily the process exit status). `dot setup nvim` must independently verify success after the headless run completes, by checking that every plugin name declared in `lazy-lock.json` has a corresponding directory under `~/.local/share/nvim/lazy/`. Any pinned plugin missing a directory is treated as a failure: print which plugin(s) didn't install and exit non-zero.
 - **Parser-compile failures are out of scope for pass/fail**: the `tree-sitter-<lang>-tmp` collision race affects `nvim-treesitter`'s internal parser build, not the plugin-directory check above (nvim-treesitter's own directory will exist regardless of whether an individual parser compiled). `dot setup nvim`'s success criterion is "all pinned plugins are present," not "all treesitter parsers compiled" — a parser-level compile flake is expected to self-heal on a later `nvim` launch or `:TSUpdate`, per the `Further Notes` in this spec's investigation. Detecting and retrying individual parser build failures is not attempted here.
 - **No package-list file**: unlike `dot install`, there's nothing to record — `lazy-lock.json` is already the tracked source of truth, so `dot setup nvim` never writes to it.
 ## Testing Decisions
 - **Guiding principle**: test `dot setup nvim`'s own logic (that it invokes `nvim` correctly, that it correctly detects success vs. a missing plugin) through the real CLI entry point, faking only the external `nvim` binary — not real plugin installs, real git clones, or real compilation, which would be slow and network-dependent in tests.
 - **Primary seam**: full CLI invocation of `dot setup nvim` (and bare `dot setup`), run against a scratch `$HOME` per test case — the existing project convention (see `dot install`'s and the planned `dot setup folders`' tests). No new seam is introduced.
 - **Faking `nvim`**: a `PATH`-prepended fake `nvim` binary, mirroring the fake-`pacman`/fake-`sudo`/fake-`xdg-user-dirs-update` technique already used/planned in `tests/dot.fish`. The fake logs its invocation args (so a test can assert `dot setup nvim` called it with `--headless "+Lazy! restore" +qa`) and, driven by an env var or scratch-`$HOME` fixture, can simulate "all plugins present" vs. "one plugin missing" by controlling whether it creates the expected directories under the scratch `~/.local/share/nvim/lazy/`.
 - **Cases to cover**: a successful sync (fake `nvim` creates all pinned plugin directories) exits 0; a plugin missing after the fake run exits non-zero and names the missing plugin; re-running against an already-fully-synced scratch `$HOME` is still a pass (idempotency) without requiring the fake to do anything different; bare `dot setup` runs the `nvim` task alongside `folders`; `dot setup nvim help` prints usage and never invokes the fake `nvim` at all.
 - **Prior art**: `tests/dot.fish`'s scratch-`$HOME`-plus-`fishtape` pattern, and specifically the fake-binary-via-`PATH` technique used for `dot install` (and planned for `dot setup folders`'s `xdg-user-dirs-update` fake).
 ## Out of Scope
 - The `dot setup` dispatcher scaffolding itself (bare-runs-everything, per-task dispatch, `_dot_setup_usage`) — already specified in `dot-setup-folders.md`; this spec only adds the `nvim` task onto it.
 - The `folders` and any future (e.g. `groups`) `dot setup` tasks — unaffected by this spec beyond now running alongside `nvim` in bare `dot setup`.
 - Fixing the underlying `nvim-treesitter` `tree-sitter-<lang>-tmp` race itself (an upstream plugin behavior) — `dot setup nvim` tolerates it rather than working around it.
 - Any change to `~/.config/nvim`'s plugin specs, `lazy-lock.json` contents, or which plugins/parsers are installed — this spec only adds a way to proactively sync to what's already pinned.
 - A `~/.github/README.md` command-table row — not written here, but required by the project's standard "adding a subcommand" checklist at implementation time.
 ## Further Notes
 - This spec grew out of debugging a real "nvim isn't starting" report: the actual cause was an empty `lazy.nvim` plugin directory triggering a full, slow reinstall on first launch, compounded by a `tree-sitter-bash-tmp` mkdir collision that made the `bash` parser fail and re-attempt on every subsequent launch until it happened to succeed. `dot setup nvim` addresses the first (silent first-launch stall) directly; the second (parser race) is a pre-existing upstream flake this spec does not attempt to fix.
--- a/.config/dot/.claude/spec/gitea-axi-integration.md
+++ b/.config/dot/.claude/spec/gitea-axi-integration.md
@@ -1,56 +0,0 @@
 ## Problem Statement
 Today, `to-spec`, `to-tasks`, and `implement` track specs and tasks as local files (`.claude/spec/<slug>.md`, `.claude/tasks/<NNNN>-<slug>.md`) scoped to a single git working tree.
 That means task state and context don't survive across the machine boundary — a spec or task can't be picked up from a different clone, referenced from a PR, or handed to a differently-scoped agent session without manually carrying the files over.
 There's also no natural place for `review-uncommitted`'s findings to live once produced, other than the terminal output, which the operator has to capture manually if they want it preserved as a record.
 ## Solution
 Once `gitea-axi` (see the companion `gitea-axi` spec) exists, replace the local-file storage in this project's skill-based task-management pipeline with Gitea issues and pull requests: specs and tasks become labeled issues, "readiness" becomes a label state, and implemented work becomes a pull request that `review-uncommitted` comments on directly.
 The workflow-specific semantics (label names, state transitions, PR-to-issue linking) live entirely in the skills' own prose, calling `gitea-axi`'s generic primitives — `gitea-axi` itself stays unaware of this project's conventions.
 ## User Stories
 1. As the operator, I want `to-spec` to open a Gitea issue containing the spec instead of writing a local file, so that the spec is visible and referenceable outside my local working tree.
 2. As the operator, I want the spec issue labeled to mark it ready for task breakdown, so that a later session can find it without me telling it the issue number.
 3. As the operator, I want a new session to be able to locate and read a spec issue by its readiness label, so that I can hand off spec-to-task work across sessions without manually passing context.
 4. As the operator, I want `to-tasks` to open one Gitea issue per task instead of writing local task files, so that each task is independently discoverable and referenceable the same way the spec is.
 5. As the operator, I want each task issue to retain a reference back to its parent spec issue, so that the `spec` traceability that today's local task-file frontmatter provides isn't lost in the move to issues.
 6. As the operator, I want `to-tasks` to remove the spec issue's readiness label once tasks are created from it, so that the state machine reflects "spec has already been broken down" and isn't reprocessed.
 7. As the operator, I want to ask a new session to implement "the next task" and have it find the right task issue by its readiness label, so that I don't have to look up and paste an issue number myself.
 8. As the operator, I want `implement` to read a task issue's full details before starting work, so that it has the same context a local task file would have given it.
 9. As the operator, I want `implement` to open a pull request (carrying the implementation commit) once work is done, instead of leaving only an uncommitted or committed local diff, so that the work is reviewable and mergeable through Gitea like any other PR.
 10. As the operator, I want `review-uncommitted` to fetch its diff and spec context from the pull request and its linked issue when run in this workflow, so that I don't need a local spec file for it to work against.
 11. As the operator, I want `review-uncommitted`'s three-axis findings posted as a comment on the pull request, so that they're visible as a permanent record on the PR itself, not just in my terminal.
 12. As the operator, I want the label taxonomy and state machine (spec/task readiness, PR-to-issue linking conventions) to be easy to change later, so that I can iterate on the workflow without touching `gitea-axi`'s code.
 13. As the operator, I want PR granularity (one commit vs. several, one task vs. several per PR) decided case-by-case between me and the agent at `implement` time, rather than fixed by a rule baked into the skill.
 ## Implementation Decisions
 - Depends on `gitea-axi` existing first (see the companion spec) — this spec only covers how this project's skills consume it, not the tool itself.
 - Affected skills: `to-spec`, `to-tasks`, `implement`, `review-uncommitted`. Each swaps its local-file I/O (`Read`/`Write`/`Edit` against `.claude/spec/` and `.claude/tasks/`) for calls to `gitea-axi`'s generic issue/PR primitives.
 - `to-spec` opens an issue (instead of writing `.claude/spec/<feature-slug>.md`) carrying the same spec content and format, labeled to mark it as newly created and ready for breakdown.
 - `to-tasks` reads the spec issue, opens one issue per task slice (instead of `.claude/tasks/<NNNN>-<slice-slug>.md`), each carrying a reference back to the parent spec issue (replacing the current `spec` frontmatter field), labels each task issue as ready for implementation, and removes the readiness label from the spec issue once done.
 - `implement` locates its target task issue (by number if given, or by readiness label/query if asked for "the next task"), reads it in place of a local task file, does the work, and opens a pull request carrying the implementation commit — in place of just staging locally and leaving the commit to the operator.
 - `review-uncommitted` gains a Gitea-aware path: when working against a PR, it fetches PR diff/metadata and the linked spec/task issue instead of `git diff HEAD` and a local spec file, and posts its aggregated Risk/Standards/Spec report as a single PR comment once done (per the companion spec's decision to keep this a single comment, not per-finding inline comments).
 - Label taxonomy and exact naming (today referred to provisionally as "spec"/"ready-for-agent") are explicitly left open — to be finalized when these skill updates are actually implemented, not fixed by this spec.
 - PR granularity (commits per PR, tasks per PR) is explicitly left as a case-by-case decision made between the operator and the agent at `implement` time — not a fixed rule this spec encodes.
 ## Testing Decisions
 - Skills are prose (`SKILL.md` files), not unit-testable code — there is no automated test seam for the skill updates themselves. Verification is behavioral: running each updated skill against a real (or disposable) Gitea instance end-to-end and confirming the resulting issues, PRs, labels, and comments match what the prose describes.
 - The one seam that is testable in the traditional sense is `gitea-axi` itself, already covered by the companion spec — these skill updates are downstream consumers of that seam, not a new one.
 - No prior art in this repo for testing prompt-based skills; `~/.config/dot/tests/dot.fish` (fishtape, end-to-end against fixtures) is the closest pattern, but it tests code, not prose, so it doesn't transfer directly.
 ## Out of Scope
 - Building `gitea-axi` itself (fully covered by the companion `gitea-axi` spec).
 - Deciding the actual label taxonomy and state machine names — deferred to implementation time.
 - Deciding PR granularity rules — deferred to case-by-case decisions at `implement` time.
 - Inline per-finding PR review comments for `review-uncommitted` (deferred enhancement, noted in the companion spec).
 - Any change to `codebase-design`, `domain-modeling`, `test-driven-development`, or other skills not in the four listed above.
 ## Further Notes
 - This spec assumes `gitea-axi`'s generic primitives (issue create/read/find-by-label/update-labels, PR create/get/comment) are sufficient for the four listed skills. If implementation reveals a missing primitive, it should be added to `gitea-axi` itself (kept generic) rather than special-cased here.
 - This is an opinionated, single-adopter view of `gitea-axi` — it intentionally isn't part of the `gitea-axi` spec itself, since that tool is meant to stay usable by others regardless of this project's specific workflow conventions.
--- a/.config/dot/.claude/spec/gitea-axi.md
+++ b/.config/dot/.claude/spec/gitea-axi.md
@@ -1,70 +0,0 @@
 ## Problem Statement
 Coding agents that need to drive a Gitea-hosted workflow (issues, pull requests, labels) today have two poor options.
 The official `tea` CLI is human-oriented: it has no token-efficiency, no contextual guidance, and no agent-facing error conventions.
 Gitea's MCP servers expose the full API surface (dozens of tools) rather than being tuned for token or turn efficiency.
 There is no Gitea-focused tool built to the same "agent ergonomics" standard that `gh-axi` established for GitHub.
 ## Solution
 Build `gitea-axi`: a thin, generic CLI wrapper around the official `tea` binary that reshapes its output according to the 10 AXI (Agent eXperience Interface) principles — token-efficient output, minimal default schemas, structured errors, contextual next-steps, and so on.
 It gives coding agents an ergonomic, low-token way to drive issues and pull requests on any Gitea instance.
 It ships both as an installable npm CLI and as an installable Agent Skill, so any agent session can adopt it with one install step.
 ## User Stories
 1. As a coding agent, I want to create a Gitea issue with a title, body, and labels, so that I can record work items for later retrieval.
 2. As a coding agent, I want to find issues by label (and other basic filters), so that I can locate relevant work without already knowing its issue number.
 3. As a coding agent, I want to read an issue's full body, labels, and comments, so that I can load its context into a session.
 4. As a coding agent, I want to add and remove labels on an existing issue, so that I can reflect state transitions as work progresses.
 5. As a coding agent, I want to create a pull request from the current branch, so that completed work becomes reviewable.
 6. As a coding agent, I want to fetch a pull request's metadata and diff, so that review tooling can operate on it without re-deriving it from git.
 7. As a coding agent, I want to post a comment on a pull request, so that findings or notes are visible as a permanent reference on the PR itself.
 8. As a coding agent, I want command output in a token-minimized format (TOON, minimal default fields, truncated large fields with an escape hatch), so that repeated calls across a long-running session don't consume excessive context.
 9. As a coding agent, I want pre-computed aggregates in list/read output, so that I don't need follow-up calls just to derive obvious derived fields.
 10. As a coding agent, I want explicit empty-state output when a query returns nothing, so that "no results" is never ambiguous with an error or a hang.
 11. As a coding agent, I want structured errors with actionable suggestions and meaningful exit codes instead of prose failures, so that I can self-correct without the operator's help.
 12. As a coding agent, I want mutations to be idempotent and to never prompt interactively, so that unattended, scripted use never stalls or double-applies.
 13. As a coding agent, I want contextual next-step suggestions appended after output, so that I know what to call next without being taught the tool from scratch every session.
 14. As a coding agent, I want a consistent per-subcommand `--help`, so that I can discover the interface on demand rather than needing it pre-loaded in context.
 15. As an operator, I want gitea-axi run with no arguments to show live, actionable repository state instead of a help screen, so that I get immediate value without memorizing flags.
 16. As an operator, I want gitea-axi to reuse my existing `tea` login configuration (including multi-instance profiles), so that I don't manage a second set of credentials.
 17. As an operator, I want gitea-axi's command surface to stay generic, with no workflow-specific behavior baked in, so that it's useful across different projects and label/workflow conventions without code changes.
 18. As an operator, I want gitea-axi published to npm and as an installable Agent Skill, so that I (and others) can adopt it with a single install step.
 ## Implementation Decisions
 - New standalone repository — not bundled into any other tool or CLI framework.
 - Developed against the operator's personal Gitea instance; push-mirrored to GitHub for npm publishing and public discoverability/contribution.
 - Language/runtime: TypeScript on Node, matching the `gh-axi` reference implementation this design is modeled on.
 - Implementation strategy: wrap the `tea` binary as a subprocess, invoking it with `--output json` (or the most structured format it supports) and reshaping that output — not a from-scratch Gitea API client. This reuses `tea`'s auth, multi-instance login, and full command coverage for free.
  - **Flagged risk**: subprocess-wrapping-a-CLI can become fragile or slow at higher call volumes or in edge cases (partial output, non-JSON error text, version drift in `tea`'s own output shape). If this proves to be a real problem in practice, the fallback is a direct Gitea HTTP API client (as Gitea's own MCP server already does) — noted here so it isn't re-litigated from scratch if revisited.
 - Auth: no independent credential handling. Every command shells out through `tea`, so it relies entirely on `tea login add` already being configured, including `tea`'s own `--login`/multi-instance profile resolution.
 - Command surface: generic Gitea primitives only — issue create/read/find-by-label/update-labels, PR create/get/comment (see User Stories above for the full list). No project-specific or workflow-specific commands (e.g. nothing that hardcodes a particular label taxonomy or state machine).
 - Output ergonomics follow the 10 AXI principles (https://axi.md/, https://github.com/kunchenguid/axi), grouped as:
  - Efficiency: TOON-formatted stdout (~40% fewer tokens than JSON), minimal default schemas (3-4 fields per list item), truncated large fields with size hints and an escape hatch to fetch full content.
  - Robustness: pre-computed aggregates to avoid round trips, explicit empty-state messages, structured errors and exit codes, idempotent mutations, no interactive prompts, fail loudly on unknown flags.
  - Discoverability: opt-in session integration plus an on-demand skill, no-args shows live data rather than help text, contextual next-step suggestions appended after output.
  - Help: consistent per-subcommand `--help`.
 - Distribution: published to npm as a global-installable CLI, and packaged as an installable Agent Skill (installable the same way as `gh-axi`'s, e.g. via `npx skills`) — both built together from the start, not phased.
 ## Testing Decisions
 - Good tests exercise the actual command-line interface (argv in, stdout/exit-code out) — the one seam every caller depends on — not internal functions, and not a mock of the `tea` subprocess call itself (that would only prove gitea-axi calls `tea` with certain arguments, not that the output is correctly reshaped).
 - Tests should run the real, built CLI against either a disposable/fixture Gitea instance or a recorded fixture of `tea`'s own JSON output.
 - Prior art: `~/.config/dot/tests/dot.fish` tests `dot`'s subcommands end-to-end with fishtape, building a throwaway bare-git remote fixture per scenario rather than mocking `git`. The equivalent here is a disposable Gitea fixture (or recorded `tea` output) rather than mocking `tea`.
 ## Out of Scope
 - Any workflow-specific commands or hardcoded label/state semantics (tracked separately — see the companion `gitea-axi-integration` spec for one concrete adopter's usage).
 - Inline per-line PR review comments (a possible future addition; the primitive here is a plain PR comment).
 - A from-scratch Gitea HTTP API client bypassing `tea` (deferred fallback if the subprocess-wrapping approach proves fragile — see flagged risk above).
 - Multi-instance orchestration beyond what `tea`'s own login profiles already provide.
 - A `dot` (or any other host CLI's) subcommand wrapping this tool — it is intentionally a standalone, independently distributed tool.
 ## Further Notes
 - AXI ("Agent eXperience Interface") is an existing framework: https://axi.md/ and https://github.com/kunchenguid/axi. Its reference implementation, `gh-axi` (https://github.com/kunchenguid/gh-axi), wraps GitHub's `gh` CLI the same way this spec proposes wrapping `tea`, and reports (its own benchmarks) 100% task success vs. 86% for raw `gh`, and 66% cheaper / 74% fewer input tokens / half the interaction turns vs. GitHub's official MCP server on the same 17-task benchmark.
 - The official Gitea MCP server (https://gitea.com/gitea/gitea-mcp) was evaluated and rejected as the primary approach: roughly 45 consolidated tools, actively maintained, but — by analogy to the gh-axi-vs-GitHub-MCP benchmark — generic MCP servers expose the full API surface rather than being tuned for token/turn efficiency, and using one directly would forfeit control over output shape.
 - Raw `tea` was also evaluated and rejected as the long-term approach (though it remains the dependency this tool wraps): it already supports `--output json/yaml/csv/tsv`, so it's scriptable, but its schemas are human-oriented, not agent-ergonomic (no truncation, no contextual next-steps, no token minimization).
 - Name collision check (as of this writing): `gitea-axi` is unclaimed on both npm and GitHub.
--- a/.config/dot/.claude/tasks/0000-nested-subcommand-discovery.md
+++ b/.config/dot/.claude/tasks/0000-nested-subcommand-discovery.md
@@ -1,31 +0,0 @@
 ---
 spec: dot-kde
 ---
 ## What to build
 Extend the subcommand-discovery mechanism to glob one directory level
 deeper, so a `dot` subcommand can live as `commands/<name>/<name>.fish`
 alongside a companion file (e.g. a Python helper), not just as a flat
 `commands/<name>.fish`. This mechanism exists in two places today
 (`dot.fish`'s `__dot_help` and `completions/dot.fish`'s
 `__dot_custom_subcommands`), intentionally duplicated rather than shared
 (fish autoload constraints) — both must be updated together and stay in
 sync. Existing flat-file subcommands must keep working unchanged.
 This is pure prefactoring: no KDE-specific behavior is introduced here.
 ## Acceptance criteria
 - [x] `dot help` lists a subcommand that lives at `commands/<name>/<name>.fish`
 - [x] `dot <name>` sources and dispatches to `commands/<name>/<name>.fish`'s `_dot_<name>` function
 - [x] Tab-completion (`__dot_custom_subcommands`) lists a nested-directory subcommand
 - [x] Existing flat-file subcommands (`dot install`) are still discovered and dispatched correctly
 - [x] `tests/dot.fish` covers a nested-directory dummy command dispatching correctly, alongside the existing flat-file dispatch case
 ## Implementation Notes
 - The dispatch check in `dot.fish` tries the flat file first, then falls back to `commands/<name>/<name>.fish` — a flat file always wins if both somehow exist for the same name.
 - The nested-directory scan requires the file basename to match its containing directory's name (`commands/foo/foo.fish`), not just any `.fish` file one level deep — this matches the acceptance criteria's exact convention and avoids misclassifying a stray companion file (e.g. a `.py` helper) as its own subcommand.
 - Tab-completion's nested-directory listing was verified manually (sourcing `completions/dot.fish` and calling `__dot_custom_subcommands` directly) rather than via an automated test — `tests/dot.fish` has no existing infrastructure for testing completions at all, even for pre-existing flat commands, so adding one here would be out of scope for this prefactoring task.
 - Updated `CLAUDE.md`'s "Architecture" and "Adding a subcommand" sections to document the new nested-directory convention, since it previously only described the flat-file dispatch contract.
--- a/.config/dot/.claude/tasks/0001-kde-schema-backed-save.md
+++ b/.config/dot/.claude/tasks/0001-kde-schema-backed-save.md
@@ -1,63 +0,0 @@
 ---
 spec: dot-kde
 blocked-by: 0000-nested-subcommand-discovery
 ---
 ## What to build
 Stand up `dot kde` itself: the fish dispatcher plus its Python helper,
 living together under `commands/kde/` per the nested-subcommand layout
 from the prior task. Establish the manifest file (flat text file directly
 under `~/.config/dot/`, one `identifier=value` line each, split on the
 first `=` only; identifier split on the first two `.`s into
 `file.group.key`, leaving the key free to contain further dots or spaces).
 Implement the KConfigXT schema-backed mechanism: reads and writes go
 through `kreadconfig6`/`kwriteconfig6`, and the "default" value for a
 setting comes from its `.kcfg` schema. Build the `(rcfile → [kcfg files])`
 mapping table by scanning the system's KConfigXT schema directory for
 files that statically declare their target rc file
 (`<kcfgfile name="...">`), plus a small hand-maintained list for the
 exceptions that only declare their target file at runtime
 (`<kcfgfile arg="true">` — `kwin.kcfg` is a known example). The schema
 directory location must be overridable (e.g. via an environment variable),
 defaulting to the real system path, so tests can point it at a fixture
 directory of synthetic `.kcfg` files instead.
 Structure identifier resolution as a dispatchable decision (rc file is
 `kglobalshortcutsrc` → shortcuts; else resolves via the mapping table →
 schema-backed; else → freeform) even though only the schema-backed branch
 is implemented yet — later tasks add the other two branches without
 restructuring this.
 Implement `dot kde save` for schema-backed settings, in both modes:
 run with no arguments, refresh every already-declared manifest entry's
 value from the live system; run with an explicit identifier, read its
 current live value and add it to the manifest as a new declared entry.
 Add `dot kde help` and `dot kde save help`, following the project's
 check-for-`help`-before-`argparse` convention at each dispatch level.
 Add README rows for `dot kde help`, `dot kde save <identifier>`, and
 `dot kde save` (no arguments).
 ## Acceptance criteria
 - [x] `dot kde` and `dot kde save` are discoverable via `dot help` and dispatch correctly
 - [x] Manifest parsing splits correctly on the first `=` (values may contain `=`) and the first two `.`s of the identifier (keys may contain dots/spaces)
 - [x] The `(rcfile → [kcfg files])` mapping table is derived by scanning a schema directory for `<kcfgfile name="...">`, plus the hand-maintained exceptions list for `arg="true">` schemas
 - [x] The schema directory is overridable via an environment variable, defaulting to the real system path
 - [x] `dot kde save <identifier>` reads the current live value via `kreadconfig6` and adds a new declared entry to the manifest
 - [x] `dot kde save` with no arguments refreshes every already-declared manifest entry's stored value from the live system, leaving undeclared settings untouched
 - [x] `dot kde help` and `dot kde save help` print usage without touching the manifest or invoking `kreadconfig6`/`kwriteconfig6`
 - [x] Tests run against a scratch `$HOME` and a fixture `.kcfg` schema directory, exercising manifest read/write, identifier parsing, and mapping-table-driven default lookup, per the project's scratch-`$HOME`-plus-`fishtape` convention
 - [x] README has rows for `dot kde help`, `dot kde save <identifier>`, and `dot kde save`
 ## Implementation Notes
 - File layout: `commands/kde/kde.fish` (thin dispatcher: help-before-dispatch at the `dot kde` level, then hands off to the Python helper) plus `commands/kde/kde.py` (manifest parsing, mapping-table derivation, mechanism resolution, `kreadconfig6` invocation, and `save`'s own help-before-work check).
 - Manifest location: `~/.config/dot/kde-manifest`, a flat file directly under `~/.config/dot/` as specified.
 - Mechanism dispatch (`resolve_mechanism`) implements all three branches described in the parent spec (shortcuts / schema / freeform) even though only `schema` is wired to real behavior; `shortcuts` and `freeform` both currently raise a clear "not yet supported" error from `save_one`, so later tasks can fill them in without restructuring the dispatch.
 - Test fixtures added under `tests/fixtures/kcfg/`: `testrc.kcfg` (a plain `<kcfgfile name="...">` schema, including an entry whose ini `key=` differs from its schema `name=`, and one entry whose key contains dots and spaces), `kwin.kcfg` (an `arg="true"` schema resolved only via the hand-maintained exceptions list), and `unmapped.kcfg` (an `arg="true"` schema absent from that list, proving it's never guessed at from its own filename).
 - Per the project's testing convention, `kreadconfig6` is never mocked for the tests exercising actual `save` behavior — it runs for real against fixture rc files under a scratch `$HOME`. It's faked (via a `$PATH`-prepended logging stub) only for the two tests asserting that `dot kde help` / `dot kde save help` never invoke it.
 - Applied two small cleanups surfaced by `/review-uncommitted`'s Standards pass before closing out: extracted a shared `_parse_kcfg` helper (was duplicated between `build_kcfg_map` and `find_schema_default`), and introduced a `Setting = namedtuple("Setting", ["file", "group", "key"])` to stop threading those three strings as separate parameters across `resolve_mechanism`/`find_schema_default`/`read_live_value`/`save_one`.
 - The Spec pass caught that the `unmapped.kcfg` fixture was created but never actually exercised by a test; added a case asserting `dot kde save unmapped.Whatever.Setting` resolves to freeform rather than schema-backed.
--- a/.config/dot/.claude/tasks/0002-kde-schema-backed-apply.md
+++ b/.config/dot/.claude/tasks/0002-kde-schema-backed-apply.md
@@ -1,32 +0,0 @@
 ---
 spec: dot-kde
 blocked-by: 0001-kde-schema-backed-save
 ---
 ## What to build
 Implement `dot kde apply` for schema-backed settings: read every entry in
 the manifest and write its declared value onto the live system via
 `kwriteconfig6`. Re-running it against an already-applied system must be a
 no-op with no unintended side effects — this is the idempotence the
 feature depends on for safe re-runs after a KDE update or on a freshly
 built machine. Add `dot kde apply help`, following the project's
 check-for-`help`-before-`argparse` convention.
 Add a README row for `dot kde apply`.
 ## Acceptance criteria
 - [x] `dot kde apply` pushes every manifest entry's declared value onto the live system via `kwriteconfig6`
 - [x] Re-running `dot kde apply` against a system already matching the manifest changes nothing (idempotent)
 - [x] `dot kde apply help` prints usage without writing anything
 - [x] Tests run against a scratch `$HOME`, exercising apply over a manifest with schema-backed entries, verifying resulting rc-file contents and idempotence on a second run
 - [x] README has a row for `dot kde apply`
 ## Implementation Notes
 - File layout mirrors `save`'s: `write_live_value` (the `kwriteconfig6` counterpart to `read_live_value`) and `apply_one` (mirroring `save_one`'s `parse_identifier` → `resolve_mechanism` → schema-only gate) added to `commands/kde/kde.py`; `cmd_apply` mirrors `cmd_save`'s help/argument/error-handling scaffold. `kde.fish` gained an `apply` dispatch case above `save`.
 - `apply` takes no arguments (unlike `save`, which supports an optional identifier) — the task only specifies pushing the whole manifest, and the parent spec's `apply` user story has no per-identifier mode, so `dot kde apply <extra-arg>` is rejected as misuse rather than silently ignored.
 - `write_live_value` passes the value positionally after a `--` separator (`kwriteconfig6 --file ... --group ... --key ... -- <value>`) rather than via a `--value` flag, since `kwriteconfig6` takes the value as a mandatory positional argument, not a flag; `--` guards against a value that itself looks like an option.
 - Non-schema (shortcuts/freeform) manifest entries are rejected with the same "not yet supported" error `save_one` already raises for those mechanisms, kept out of scope per this task's title ("...apply for schema-backed settings"); those mechanisms are added in later tasks (0004, 0005) without needing to restructure `cmd_apply`.
 - `/review-uncommitted` flagged two baseline duplication smells (`apply_one`/`cmd_apply` mirroring `save_one`/`cmd_save`'s shape) and one observation (a failing entry mid-manifest halts `apply` immediately, leaving earlier writes already applied — a partial-apply state, untested either way). Left as-is: the duplication mirrors an already-established local convention from task 0001 rather than introducing a new one, and the partial-apply behavior is consistent with `cmd_save`'s pre-existing control flow, not a new risk introduced by this task.
--- a/.config/dot/.claude/tasks/0003-kde-schema-backed-diff.md
+++ b/.config/dot/.claude/tasks/0003-kde-schema-backed-diff.md
@@ -1,35 +0,0 @@
 ---
 spec: dot-kde
 blocked-by: 0001-kde-schema-backed-save
 ---
 ## What to build
 Implement `dot kde diff`'s broad, read-only scan for schema-backed
 settings: walk every `(rcfile, group, key)` reachable through the
 mapping table built in the prior task, compare each live value
 (`kreadconfig6`) against its schema-declared default, and report every
 mismatch. Each reported mismatch is tagged as declared (its identifier is
 present in the manifest — an intentional, already-tracked deviation) or
 undeclared (never explicitly declared). `diff` never writes anything.
 Add `dot kde diff help`, following the project's
 check-for-`help`-before-`argparse` convention.
 Add a README row for `dot kde diff`.
 ## Acceptance criteria
 - [x] `dot kde diff` reports every schema-backed setting whose live value differs from its schema-declared default
 - [x] Each reported mismatch is tagged declared or undeclared based on manifest presence
 - [x] `dot kde diff` makes no writes under any circumstances
 - [x] `dot kde diff help` prints usage without scanning
 - [x] Tests run against a scratch `$HOME` and fixture `.kcfg` schema directory, covering: a declared mismatch, an undeclared mismatch, and a setting matching its default (not reported)
 - [x] README has a row for `dot kde diff`
 ## Implementation Notes
 - `cmd_diff` (in `commands/kde/kde.py`) reuses `build_kcfg_map`/`iter_schema_identifiers` (already built for `kde.py complete`) to walk every schema-backed `(rcfile, group, key)`, then `find_schema_default`/`read_live_value` (already built for `save`) to compare live vs. default. No new scanning machinery was needed — this task's whole job was wiring existing pieces together into a read-only report.
 - Output format: one line per mismatch, `<declared|undeclared> <identifier> = <live> (default: <default>)`. Not specified by the task, so chosen to read clearly and stay unambiguous under substring matching in tests (avoided bracketed tags like `[declared]`, since fish's `string match` glob treats `[...]` as a character class).
 - `/review-uncommitted`'s Spec pass caught that `cmd_diff` had no error handling around `read_live_value`, unlike `cmd_apply`/`cmd_save`'s `try/except (ValueError, RuntimeError)` — a single `kreadconfig6` failure would have aborted the entire broad scan with an uncaught traceback, contradicting `diff`'s "report every mismatch" framing. Fixed: `cmd_diff` now catches `RuntimeError` per-identifier, prints a warning to stderr, and continues scanning the rest.
 - The Standards pass flagged the "build map → iterate `sorted(set(iter_schema_identifiers(...)))`" shape as now duplicated between `cmd_diff` and `cmd_complete`, and the new test scenarios' fixture boilerplate as repeating the `apply` tests' shape almost verbatim. Left both as-is: the loop duplication is two call sites doing genuinely different things with the result, and the test boilerplate matches this file's already-established per-scenario convention (each scenario resets `$HOME` independently) rather than introducing a new pattern.
 - Post-closeout fix (user-reported): `~/.config/fish/completions/dot.fish`'s `dot kde` completion block only ever listed `save`/`help` as verbs — `apply` was never added when task 0002 built it, and this task initially repeated the same omission for `diff`. Fixed both by adding `apply` and `diff` to the top-level verb-offering line and to the post-subcommand `help` gating; verified manually via `complete -C"dot kde "` and `complete -C"dot kde apply "`/`complete -C"dot kde diff "`.
--- a/.config/dot/.claude/tasks/0004-kde-freeform-mechanism.md
+++ b/.config/dot/.claude/tasks/0004-kde-freeform-mechanism.md
@@ -1,41 +0,0 @@
 ---
 spec: dot-kde
 blocked-by: [0002-kde-schema-backed-apply, 0003-kde-schema-backed-diff]
 ---
 ## What to build
 Add the freeform mechanism as a dispatch branch across `save`, `apply`,
 and `diff`: for settings with no KConfigXT schema (e.g. `kxkbrc`'s
 `Options=` line), read and write via `kreadconfig6`/`kwriteconfig6`, with
 "default" defined as "the key is absent" rather than any schema-declared
 value. In the identifier-resolution decision from the first schema-backed
 task, this is the fallback branch: an identifier whose `(rcfile, group,
 key)` doesn't resolve through the mapping table is freeform. Because
 there's no schema to enumerate, freeform settings can only be checked by
 `diff` when already declared in the manifest — they never participate in
 undeclared broad-scan discovery.
 As the real-world validation for this task, bring the machine's live,
 already-hand-set `kxkbrc` caps-lock/Escape swap
 (`Options=caps:escape_shifted_capslock`) under tracking via
 `dot kde save`, and confirm `dot kde apply`/`dot kde diff` behave
 correctly against it.
 ## Acceptance criteria
 - [x] An identifier whose `(rcfile, group, key)` has no schema match is treated as freeform rather than erroring
 - [x] `dot kde save <identifier>` and `dot kde save` (refresh) work for freeform entries
 - [x] `dot kde apply` writes freeform entries via `kwriteconfig6`, idempotently
 - [x] `dot kde diff` reports a freeform mismatch when its identifier is already declared in the manifest, and never surfaces an undeclared freeform setting via broad scan
 - [x] Tests run against a scratch `$HOME`, covering freeform save/apply/diff using a fixture rc file with no corresponding schema
 - [x] The live `kxkbrc` caps-lock/Escape swap is tracked via `dot kde save` and the manifest committed to the dotfiles repo
 ## Implementation Notes
 - `save_one`/`apply_one`'s gate changed from `mechanism != "schema"` (reject everything but schema) to `mechanism == "shortcuts"` (reject only shortcuts) — freeform now flows through the same `read_live_value`/`write_live_value` calls schema-backed settings already use, since both mechanisms only differ in what "default" means, not in how the read/write itself happens.
 - `cmd_diff` gained a second pass after the existing schema broad-scan: it walks the manifest (not the kcfg mapping table, which freeform settings are absent from by definition), resolves each identifier's mechanism, and reports only those that resolve to `freeform` and whose live value is non-empty — structurally guaranteeing freeform can never surface via undeclared broad scan, since the loop never sees anything outside the manifest.
 - **Real-world validation surfaced a stale premise**: the task assumed the caps-lock/Escape swap was "already hand-set" and live, but the machine had no `kxkbrc` file and no active XKB option at all. Confirmed with the user before proceeding; with their approval, wrote the option live via `kwriteconfig6 --file kxkbrc --group Layout --key Options -- caps:escape_shifted_capslock` and applied it immediately via a live KWin reconfigure (`busctl --user call org.kde.KWin /KWin org.kde.KWin reconfigure`), then ran `dot kde save kxkbrc.Layout.Options` to bring it under tracking. `dot kde apply`/`dot kde diff` were both verified against the real entry (idempotent apply; diff reports `declared kxkbrc.Layout.Options = caps:escape_shifted_capslock (default: )`).
 - Added a `.github/keybindings.md` row for the swap (`CapsLock` → `Esc`, `Shift`+`CapsLock` → real Caps Lock toggle), per the project's cross-cutting keybindings convention.
 - Existing tests that previously asserted freeform saves/applies were *rejected* (written when freeform was still unimplemented, per task 0001/0002's "not yet supported" stopgap) were updated to assert success instead, using a new `somefreeform` fixture rc file with no corresponding `.kcfg` schema. Coverage for the still-unimplemented shortcuts mechanism (task 0005) was added in the same spots to keep the "not yet supported" rejection path tested now that freeform no longer exercises it.
 - `/review-uncommitted`'s Spec pass caught that `cmd_diff`'s new freeform loop called `parse_identifier` on raw manifest keys with no exception guard, unlike the rest of the function — a hand-edited manifest with a malformed identifier would have crashed the whole scan instead of reporting a clean per-identifier error. Fixed: the loop body is now wrapped in `try/except (ValueError, RuntimeError)`, matching the file's established per-identifier-failure-tolerant convention. The Standards pass also flagged threading a hardcoded `None`/blank literal through the freeform loop instead of the real `default` value returned by `resolve_mechanism`; fixed by reusing that variable directly (`default or ''` for display, since freeform's default is always `None`).
--- a/.config/dot/.claude/tasks/0005-kde-shortcuts-mechanism.md
+++ b/.config/dot/.claude/tasks/0005-kde-shortcuts-mechanism.md
@@ -1,57 +0,0 @@
 ---
 spec: dot-kde
 blocked-by: [0002-kde-schema-backed-apply, 0003-kde-schema-backed-diff]
 ---
 ## What to build
 Add the shortcuts mechanism as a dispatch branch across `save`, `apply`,
 and `diff`: identifiers rooted at `kglobalshortcutsrc` are resolved not by
 editing the rc file directly but through KDE's `kglobalaccel` D-Bus
 service — `shortcut(actionId)` for the current value, `defaultShortcut
 (actionId)` for the default, and `setShortcut(actionId, keys, flags)`
 with `flags = NoAutoloading` for writes (so a declared value always wins
 over any previously saved shortcut). `actionId` is the 4-element
 `[componentUnique, actionUnique, componentFriendly, actionFriendly]`
 tuple; only the two `Unique` fields are stored in the manifest, and the
 two friendly-name fields are resolved dynamically at call time by looking
 up the component's shortcut list.
 Per the spec's testing decisions, this mechanism is deliberately excluded
 from the automated test suite (it depends on a live, already-running
 session service that isn't practically substitutable without disproportionate
 mock infrastructure) — verify it manually against the real session instead.
 As the real-world validation, apply the planned screenshot/session-lock
 keybind changes (Spectacle bindings, moving Lock Session off `Meta+L` to
 `Meta+X`) through `dot kde save`/`dot kde apply`, and update the
 corresponding rows in `keybindings.md` in the same change, per the
 project's cross-cutting keybindings convention.
 ## Acceptance criteria
 - [x] An identifier whose rc file is `kglobalshortcutsrc` dispatches to the `kglobalaccel` D-Bus mechanism rather than the schema-backed or freeform paths
 - [x] `dot kde save <identifier>` and `dot kde save` (refresh) read a shortcut's current value via `shortcut(actionId)`, resolving the friendly-name fields dynamically
 - [x] `dot kde apply` writes a declared shortcut via `setShortcut(actionId, keys, NoAutoloading)`, verified manually to take effect immediately in the running session
 - [x] `dot kde diff` reports a declared shortcut mismatch by comparing against `defaultShortcut(actionId)`, verified manually
 - [-] The Spectacle and Lock-Session (`Meta+X`) keybind changes are applied through `dot kde save`/`apply` and tracked in the manifest
 - [x] `keybindings.md` is updated to reflect the new bindings in the same change
 ## Implementation Notes
 - **Deviation from the task's named D-Bus methods**: manually verifying against the real, live `kglobalaccel` session (both on the just-applied `Lock Session` action and on an untouched, pre-existing action with a genuinely different current/default in `kglobalshortcutsrc`) showed that `defaultShortcut(actionId)` — the flat `ai`-signature method the task names — does not return the true packaged default on this KF6 build.
  It just mirrors `shortcut(actionId)`.
  Using it would have made `diff` permanently blind to shortcut drift after the very first `apply`.
  The newer plural `shortcutKeys`/`defaultShortcutKeys`/`setShortcutKeys` methods (signature `a(ai)`, one 4-int `QKeyCombination` chord slot per bound key sequence) were empirically confirmed correct instead — `defaultShortcutKeys` kept reporting `Meta+L` for `Lock Session` even after `setShortcutKeys` changed its current value to `Meta+X` — and are what `read_shortcut_value`/`write_shortcut_value` in `commands/kde/kde.py` actually call.
  `NoAutoloading`'s value (`0x4`, from `KF6/KGlobalAccel/kglobalaccel.h`) is unchanged by this swap.
 - Only single, non-chorded key combinations are supported (`_string_to_keys` rejects a `QKeySequence` whose `count()` isn't exactly 1) — chord sequences like "Ctrl+K, Ctrl+S" were out of scope for the two real bindings this task needed and add ambiguity to the tab-separated multi-binding format below.
 - **Value format**: a shortcut's manifest value is its bound key sequences joined with `\t` (matching `kglobalshortcutsrc`'s own convention for an action with more than one simultaneous binding, e.g. `Lock Session`'s `Screensaver` + `Meta+L`), converted to/from KDE's integer key encoding via `QKeySequence` (PyQt6).
  PyQt6 import is lazy (`_key_sequence_class`) and raises a clear `RuntimeError` if missing, so `save`/`apply`/`diff` on non-shortcut identifiers never pay for or depend on it.
 - **Spectacle bindings dropped** from this change's real-world validation.
  Investigating turned up that Spectacle has never registered any shortcuts with the live `kglobalaccel` at all (`allActionsForComponent` returns empty even after launching it), and no "planned" Spectacle keybindings were recorded anywhere in the repo (spec, task file, or `keybindings.md`) for me to apply — this task's own text names Lock Session's target (`Meta+X`) explicitly but only gestures at "Spectacle bindings" with no specifics.
  Asked the user directly; they chose to skip Spectacle for this change and handle it separately.
  Only the Lock Session move is applied here.
  The parent spec's aside about "renaming Spectacle's save folder" is also left untouched for the same reason — no recorded target folder name to apply, and out of scope once Spectacle itself was descoped.
 - **Lock Session validation**: `dot kde save "kglobalshortcutsrc.ksmserver.Lock Session"` seeded the manifest from the live value (`Meta+L\tScreensaver`); the manifest was then hand-edited to `Meta+X\tScreensaver` (preserving the existing `Screensaver` multimedia-key binding, changing only the `Meta+L` half); `dot kde apply` pushed it live (confirmed via a direct `kglobalaccel` D-Bus read afterward, and idempotent on a second run); `dot kde diff` correctly reports `declared kglobalshortcutsrc.ksmserver.Lock Session = Meta+X\tScreensaver (default: Meta+L\tScreensaver)`.
  `Meta+X` is now live and tracked; `keybindings.md` has a row for it.
 - Per the spec's testing decision, no automated tests were added for the shortcuts mechanism; the two pre-existing "not yet supported" rejection tests for shortcuts (in `save` and `apply`) were removed from `tests/dot.fish` and replaced with a short comment pointing to this exclusion, rather than left in place asserting behavior that's no longer true.
--- a/.config/dot/.claude/tasks/0006-setup-dispatcher-and-folders-core.md
+++ b/.config/dot/.claude/tasks/0006-setup-dispatcher-and-folders-core.md
@@ -1,90 +0,0 @@
 ---
 spec: dot-setup-folders
 ---
 ## What to build
 A new `dot setup` subcommand family, following the project's existing
 nested-subcommand dispatch convention. Bare `dot setup` (no arguments) runs
 every machine-setup task unconditionally; `dot setup <task>` runs just that
 one task. The only task that exists yet is `folders`.
 `dot setup folders` brings the 8 standard XDG user directories under the
 project's short-name convention (`Desktop→.desktop`, `Documents→doc`,
 `Downloads→dwn`, `Music→mus`, `Pictures→pic`, `Videos→vid`, `Templates` and
 `Public` both →`.ignoreme`). The desired short names live in a tracked
 `user-dirs.dirs` file (a plain dotfile, not generated from a table each run).
 A separate small hardcoded table maps each of the 8 standard XDG categories
 to its legacy full-named folder, used only to locate content an XDG-defaults
 install would have left behind, and merge it into the already-tracked
 short-named target.
 This slice covers the core happy path: a legacy folder found empty (strictly:
 no entries at all, including dotfiles/metadata) is merged into its
 short-named target silently, with no confirmation needed. As part of the same
 `Pictures→pic` pass, a nested `Screenshots` folder is renamed to lowercase
 `screenshots`, landing at `pic/screenshots`. After all folder moves complete,
 run `xdg-user-dirs-update` (no arguments) once to notify running apps/portals.
 `~/wrk` gets no XDG variable of its own and is out of scope for any mapping;
 the existing ad hoc `~/Projects` folder is left alone.
 Non-empty legacy folders and filename collisions are out of scope for this
 slice (covered by later tasks) — for now it's acceptable for a non-empty
 legacy folder to be handled in whatever minimal way unblocks the empty-folder
 path (e.g. left untouched with a message), since the confirmation gate and
 collision safety are built out next.
 Wire the new command into the project's standard subcommand checklist: a
 `_dot_setup_usage` help function reachable via `dot setup help` (and
 `dot setup folders help` for the nested task), the completions/help-glob
 duplication point, and a README command-table row.
 ## Acceptance criteria
 - [x] `dot setup folders` on a fresh scratch `$HOME` (all 8 legacy folders
      present and empty) renames them to their short-name targets per the
      mapping table, including `Pictures/Screenshots→pic/screenshots`, and
      leaves the tracked `user-dirs.dirs` short names in place
 - [x] The fake `xdg-user-dirs-update` (PATH-prepended, logging its invocation
      per the project's existing fake-`sudo`/fake-`pacman` testing pattern)
      is invoked exactly once after a successful migration
 - [x] Bare `dot setup` on a fresh scratch `$HOME` runs the `folders` task as
      part of running everything
 - [x] `dot setup folders help` and `dot setup help` print usage and make no
      filesystem changes
 - [x] Re-running `dot setup folders` after a clean migration is a no-op
      (idempotent)
 - [x] `~/.github/README.md` has a command-table row for `dot setup`
      (and its `folders` task) with paths relative to `$HOME`
 - [x] `~/.config/dot/tests/dot.fish` covers the above cases and
      `fishtape ~/.config/dot/tests/dot.fish` passes
 ## Implementation Notes
 - The desired short names for `dot setup folders` are read directly from the
  tracked `~/.config/user-dirs.dirs` (parsed via `grep`/`string match`, not
  sourced as shell), per the parent spec's decision that this file is the
  single source of truth. This machine's real `user-dirs.dirs` was
  deliberately left untouched/untracked and no live migration was run against
  this machine's actual home directory — the user chose "code + tests only"
  scope for this task (a real rename of `~/Desktop`, `~/Documents`, etc. is a
  separate, explicit action to take later), so only the scratch-`$HOME`
  fishtape fixtures exercise the short-name `user-dirs.dirs` content.
  Tracking the real file and running the real migration remains open.
 - During `/review-uncommitted`, the spec-fidelity pass caught a real bug: the
  nested `Pictures/Screenshots→pic/screenshots` move ran unconditionally,
  before checking whether `Pictures` held other, unrelated content — so a
  `Pictures` folder with both `Screenshots/` and some other file got
  partially mutated (Screenshots pulled out) while still being reported as
  "left in place." Fixed by gating the Screenshots move on the rest of the
  folder being empty too; added a regression test for this case
  ("Screenshots is not peeled off... when Pictures still has other
  content").
 - Completions (`~/.config/fish/completions/dot.fish`) got a `dot setup`
  block mirroring `dot kde`'s per-subcommand completion entries, even though
  the task's required "completions/help-glob duplication point" is already
  satisfied automatically by the existing generic directory glob (no changes
  were needed there for `dot setup`/`dot help` to discover the new nested
  command). The added completions are a small polish addition beyond the
  strict letter of the acceptance criteria, consistent with the existing
  `kde` subcommand's treatment.
--- a/.config/dot/.claude/tasks/0007-folders-non-empty-confirmation.md
+++ b/.config/dot/.claude/tasks/0007-folders-non-empty-confirmation.md
@@ -1,52 +0,0 @@
 ---
 spec: dot-setup-folders
 blocked-by: 0006-setup-dispatcher-and-folders-core
 ---
 ## What to build
 Extend `dot setup folders`'s migration so a legacy folder found non-empty
 (any entry at all, including a stray dotfile or KDE metadata like a
 `.directory` file, counts as non-empty) stops and prints what would be moved,
 then refuses to proceed unless an explicit `--yes` flag was passed on the
 command line — no interactive prompt. With `--yes`, the migration proceeds
 for that folder the same way the empty-folder path already does.
 This applies uniformly across all 8 mapped categories, including the nested
 `Pictures/Screenshots→pic/screenshots` rename from the prior slice: a
 non-empty `Screenshots` folder is also gated behind the same confirmation
 rule.
 ## Acceptance criteria
 - [x] A legacy folder with real content (a real file, not just an empty
      directory) refuses to migrate without `--yes`, prints what would have
      been moved, and leaves the folder and its contents untouched
 - [x] The same legacy folder migrates successfully when `--yes` is passed
 - [x] A legacy folder containing only a stray dotfile/metadata file (e.g. a
      fake `.directory`) is still treated as non-empty and triggers the same
      confirmation gate
 - [x] `~/.config/dot/tests/dot.fish` covers the above cases and
      `fishtape ~/.config/dot/tests/dot.fish` passes
 ## Implementation Notes
 - `--yes`'s actual move reuses the exact same branch shape as the existing
  silent-empty path (rename `Screenshots` → `screenshots` when present, then
  `rmdir` the legacy folder), extended to also `mv` any remaining top-level
  entries into the target first. Screenshots is always moved as one atomic
  unit — its individual files are never mv'd/reported separately — so a
  non-empty `Screenshots` (own acceptance criterion in the parent spec) is
  gated and migrated the same way a non-empty top-level file would be.
 - Collision handling (no-clobber `mv -n`, reporting skipped files, leaving the
  legacy folder in place on a collision) is explicitly out of scope here —
  it's owned by 0008-folders-collision-handling.md, per that task's own
  frontmatter/spec section. The `--yes` path added here uses a plain `mv`.
 - `/review-uncommitted` flagged two minor issues, both fixed: a stale comment
  claiming a helper variable was used by both the silent-empty and `--yes`
  paths when it was only read by the latter, and a duplicated `find`
  invocation computing the same top-level listing twice under one condition
  (now computed once and reused). It also flagged the non-empty "would move"
  preview listing recursively-nested files individually instead of treating
  `Screenshots` as one unit like the real move does — fixed so the preview
  and the actual move share the same top-level-entries list.
--- a/.config/dot/.claude/tasks/0008-folders-collision-handling.md
+++ b/.config/dot/.claude/tasks/0008-folders-collision-handling.md
@@ -1,55 +0,0 @@
 ---
 spec: dot-setup-folders
 blocked-by: 0007-folders-non-empty-confirmation
 ---
 ## What to build
 Make the `--yes`-confirmed merge from the prior slice collision-safe: when a
 legacy folder and its short-named target both contain an entry with the same
 name, use no-clobber move semantics so the target's existing file is never
 silently overwritten. Report which files were skipped due to a collision, and
 leave the legacy folder in place (don't remove it) whenever any collision
 occurred during that folder's migration, rather than deleting a folder that
 still holds something that couldn't be merged.
 This closes the gap left by the old bash `setup_folders`'s naive `mv $from/*
 $to`, which had no collision protection at all.
 ## Acceptance criteria
 - [x] A filename collision between a legacy folder and its already-populated
      short-named target is skipped, not overwritten (the target's existing
      file is preserved byte-for-byte)
 - [x] The skipped collision is reported to the user
 - [x] The legacy folder is left in place (not removed) when a collision
      occurred, even though `--yes` was given and other non-colliding files
      in it were moved
 - [x] Re-running `dot setup folders` after a collision was reported and left
      in place behaves consistently (doesn't lose the previously-skipped
      file, doesn't re-move already-migrated files)
 - [x] `~/.config/dot/tests/dot.fish` covers the above cases and
      `fishtape ~/.config/dot/tests/dot.fish` passes
 ## Implementation Notes
 - The two prior branches (silent-empty merge vs. `--yes`-confirmed merge)
  were unified into one `if test (count $other_entries) -eq 0; or set -q
  _flag_yes` branch, since the collision-detection/no-clobber logic is
  identical either way. This has one side effect beyond the letter of the
  acceptance criteria (which frame collision handling around the `--yes`
  path): a legacy folder that's otherwise "empty" except for an emptyish
  nested `Screenshots` dir now also gets collision-checked against an
  already-populated `pic/screenshots` on the silent, no-`--yes` path. This
  closes the same unguarded-`mv` gap the spec calls out as the motivating
  problem (the old code's silent-path `mv $screenshots_path
  $target_path/screenshots` had no collision protection at all either), so
  it was kept rather than special-cased away. Covered by its own test
  ("a silent-path Screenshots collision ...").
 - Collision detection is a pre-check (`test -e $target_path/...`) before an
  actual `mv -n`, rather than relying on `mv -n`'s exit code alone, so each
  colliding entry can be individually identified and reported by path.
 - `/review-uncommitted` (risk: Medium, standards: 0 hard violations, spec:
  0 missing/wrong requirements) raised no changes needed; the one scope note
  it flagged (the silent-path Screenshots case above) was a deliberate,
  judged-correct decision rather than an oversight.
--- a/.config/dot/.claude/tasks/0009-kde-shortcut-completion.md
+++ b/.config/dot/.claude/tasks/0009-kde-shortcut-completion.md
@@ -1,51 +0,0 @@
 ---
 blocked-by: 0005-kde-shortcuts-mechanism
 ---
 ## What to build
 `dot kde save`'s tab-completion (`cmd_complete` in `commands/kde/kde.py`)
 currently only enumerates schema-backed identifiers via
 `iter_schema_identifiers` — it was built as a side effect of the `diff`
 task (0003) and never revisited when the shortcuts mechanism (0005)
 landed. Extend `cmd_complete` to also enumerate shortcut identifiers.
 Source the shortcut identifiers live via `kglobalaccel`, mirroring how
 schema identifiers are freshly parsed from `.kcfg` files on every call:
 call `allMainComponents()` to get every registered component's
 `componentUnique`, then `allActionsForComponent()` per component
 (already used by `_resolve_shortcut_action_id`) to get every
 `actionUnique`, yielding `kglobalshortcutsrc.<componentUnique>.<actionUnique>`
 candidates. No caching — walk fresh on every invocation.
 Print shortcut identifiers as their own block, after the existing
 schema-backed block — not merged into one interleaved sorted list.
 Keep them plain, with no friendly-name description text, matching the
 existing schema-identifier output style.
 If the D-Bus walk fails for any reason — a non-zero `busctl` exit
 (`RuntimeError`, already raised by `_kglobalaccel_call`) or `busctl`
 itself being missing (`OSError` from `subprocess.run`) — swallow it
 silently: omit the shortcuts block, still print the schema block, and
 emit no stderr diagnostic.
 Freeform identifiers (e.g. `kxkbrc.Layout.Options`) are explicitly out
 of scope for this task: there is no schema to enumerate them from, so
 this stays a permanent, accepted completion gap, not something to fix
 here.
 ## Acceptance criteria
 - [x] `python3 kde.py complete` includes every currently-registered `kglobalshortcutsrc.<componentUnique>.<actionUnique>` identifier, sourced live via `allMainComponents`/`allActionsForComponent`
 - [x] Schema-backed identifiers print first, followed by shortcut identifiers, as two distinct blocks — not interleaved into one merged sorted list
 - [x] Shortcut identifiers print plain, with no friendly-name description text
 - [x] If the D-Bus walk raises `RuntimeError` or `OSError`, the shortcuts block is omitted, the schema block still prints normally, and nothing is written to stderr
 - [x] Freeform identifiers remain unlisted by `cmd_complete` (unchanged, confirmed not a regression)
 - [x] Verified manually against a live session — no new automated tests, consistent with the existing shortcuts-mechanism test carve-out (spec's testing decisions, 0005's Implementation Notes)
 ## Implementation Notes
 - `iter_shortcut_identifiers` (new, `commands/kde/kde.py`) walks `allMainComponents()` then `allActionsForComponent()` per component, yielding `kglobalshortcutsrc.<componentUnique>.<actionUnique>`. `cmd_complete` wraps that walk in `sorted(set(...))` and appends it as a second print loop after the existing schema-backed one, inside a `try/except (RuntimeError, OSError)` that falls back to an empty list on any failure — so a missing `busctl` or an unreachable D-Bus session degrades completion instead of breaking it.
 - Manually verified both paths: live run on this machine prints 278 shortcut identifiers after 322 schema-backed ones; with `busctl` removed from `PATH` (simulating a non-KDE/minimal shell), `cmd_complete` still exits 0, prints only the 322 schema identifiers, and writes nothing to stderr.
 - `/review-uncommitted`'s Standards pass flagged two judgement-call smells: (1) the D-Bus call/unpack idiom for `allActionsForComponent` was duplicated between the new function and `_resolve_shortcut_action_id`; (2) the silent `except` swallow had no comment explaining why. Fixed both: extracted a shared `_actions_for_component(component_unique)` helper used by both call sites, and added a comment on the `try` explaining that fish invokes this on every TAB press in shells that may lack a live KDE session, so a broken shortcuts source must never cost the already-printed schema candidates. Re-ran the full test suite (101/101 pass) and both manual checks after the fix.
 - No automated tests added, per the task's own acceptance criterion and the shortcuts mechanism's existing test carve-out (0005's Implementation Notes: a live D-Bus session isn't practically substitutable without disproportionate mock infrastructure).
--- a/.config/dot/.claude/tasks/0010-kde-shortcuts-diff-broadscan.md
+++ b/.config/dot/.claude/tasks/0010-kde-shortcuts-diff-broadscan.md
@@ -1,102 +0,0 @@
 ---
 blocked-by: [0005-kde-shortcuts-mechanism, 0009-kde-shortcut-completion]
 ---
 ## What to build
 `dot kde diff`'s broad-scan (the pass that reports *undeclared* drift, not
 just already-declared entries) currently only walks schema-backed
 identifiers via `iter_schema_identifiers`. Shortcuts are treated the same
 as freeform in `cmd_diff` -- checked only when already present in the
 manifest -- per the code comment at the top of that loop. That comment is
 overstated for shortcuts: unlike freeform, which genuinely has no
 enumeration source, shortcuts *are* enumerable via `kglobalaccel`'s
 `allMainComponents`/`allActionsForComponent`, and `iter_shortcut_identifiers`
 (added in 0009 for tab-completion) already walks exactly that.
 Add a second broad-scan pass in `cmd_diff`, after the existing schema-backed
 one, over `sorted(set(iter_shortcut_identifiers()))`: for each identifier,
 compare `shortcutKeys` against `defaultShortcutKeys` (the same live/default
 read already used for declared shortcuts), and tag `declared`/`undeclared`
 exactly like the schema loop. Remove the shortcuts branch from the
 manifest-only loop below it (now redundant), leaving that loop for freeform
 only, since freeform is the only mechanism that still can't be enumerated.
 Tolerate two failure modes without aborting the whole command:
 - The enumeration call itself (`allMainComponents`) failing (no live
  session, no `busctl`) -- print one diagnostic to stderr and skip the
  shortcuts block entirely, same as any other reported problem in `diff`.
 - An individual action failing to resolve (`_resolve_shortcut_action_id`
  raising because its owning app hasn't registered with kglobalaccel this
  session) -- print that one identifier's error to stderr and continue,
  matching the schema loop's existing per-identifier tolerance.
 Update `DIFF_USAGE` to reflect that shortcuts now participate in broad-scan
 alongside schema-backed settings, leaving only freeform as declared-only.
 ## Acceptance criteria
 - [x] `dot kde diff` reports undeclared shortcut drift (a shortcut changed
      from its packaged default but never `dot kde save`d) without requiring
      it to be in the manifest first
 - [x] Already-declared shortcut drift is still reported, tagged `declared`,
      with no duplicate line from the old manifest-only loop
 - [x] A shortcut belonging to an app that hasn't registered with kglobalaccel
      this session produces one stderr diagnostic for that identifier and
      does not stop the rest of the scan (schema block, other shortcuts,
      freeform block) from completing
 - [x] If the `allMainComponents` enumeration itself fails (no `busctl`, no
      live session), `diff` prints one diagnostic, skips the shortcuts block,
      and still completes the schema and freeform passes, exiting 0
 - [x] Freeform remains declared-only (unchanged) -- only its loop comment and
      the removed shortcuts branch change
 - [x] `DIFF_USAGE` text updated to describe shortcuts as broad-scanned
 - [x] Verified manually against the real session (consistent with the
      shortcuts mechanism's existing test carve-out, 0005/0009) -- no new
      automated tests
 - [x] Full existing test suite still passes unchanged
 ## Implementation Notes
 - `cmd_diff` (`commands/kde/kde.py`) gained a second broad-scan pass between
  the existing schema-backed loop and the manifest-only loop: it walks
  `sorted(set(iter_shortcut_identifiers()))` (the same enumeration
  `cmd_complete` already uses), compares `shortcutKeys` against
  `defaultShortcutKeys` per identifier, and tags `declared`/`undeclared`
  exactly like the schema loop.
 - The manifest-only loop below it lost its `shortcuts` branch entirely
  (`resolve_mechanism` returning `"shortcuts"` now just falls through
  `if mechanism != "freeform": continue`), since the new broad-scan pass
  already reports every declared shortcut mismatch -- keeping the old branch
  would have double-printed them.
 - Two failure modes, handled at different granularity: `iter_shortcut_identifiers()`
  itself is wrapped in `try/except (RuntimeError, OSError)` -- a failure there
  (no live session, missing `busctl`) prints one diagnostic and skips the
  whole shortcuts block, letting the schema and freeform passes still run.
  Inside the per-identifier loop, `read_shortcut_value` raising `RuntimeError`
  (an app that hasn't registered with kglobalaccel this session yet) prints
  one diagnostic for that identifier and continues, matching the schema
  loop's existing per-identifier tolerance.
 - Real-world validation on this machine: manually ran the same enumeration in
  a throwaway script before implementing, confirming 29 of 278 registered
  shortcuts differed from default (the Meta+1-9 desktop-switch remap,
  Meta+Shift+1-9 window-to-desktop binds, and Meta+A/Meta+Shift+A activity
  switching) -- all 29 were `dot kde save`d into the manifest in the same
  session as a prerequisite for testing this cleanly. After implementing,
  `dot kde diff` reported all 30 shortcuts (29 plus the pre-existing
  `ksmserver.Lock Session`) as `declared` with correct default values, and
  ~34 unrelated `RuntimeError`s for apps not launched this session (Konsole,
  Spectacle, Dolphin, etc.) printed to stderr without aborting the scan.
  Removing one entry (`kwin.Switch to Desktop 1`) from the manifest and
  re-running confirmed it flips to `undeclared` with the same live/default
  values, then restoring the manifest flipped it back to `declared` --
  confirms both tags work and the manifest was left untouched by `diff`
  itself (read-only, as documented).
 - Full test suite re-run after the change: 101/101 pass, unchanged from
  before this task. No automated tests added for the new pass itself, per
  the shortcuts mechanism's existing carve-out (0005's Implementation Notes:
  a live `kglobalaccel` D-Bus session isn't practically substitutable without
  disproportionate mock infrastructure) -- the existing tests already
  exercise `dot kde diff` against the real live session and continued to
  pass with the new pass active, incidentally covering that it doesn't break
  anything even though it isn't asserting on the new pass's own output.
--- a/.config/dot/.claude/tasks/0011-folders-unconditional-merge.md
+++ b/.config/dot/.claude/tasks/0011-folders-unconditional-merge.md
@@ -1,79 +0,0 @@
 ---
 spec: dot-setup-folders
 blocked-by: 0008-folders-collision-handling
 ---
 ## What to build
 Remove the `--yes` confirmation gate that 0007/0008 built: a legacy folder
 with real content in it is migrated unconditionally now, the same as an
 empty one, since the collision handling from 0008 already makes the merge
 non-destructive on its own (a same-named entry is never overwritten, and the
 legacy folder is kept whenever any collision occurred). The `--yes` gate
 turned out to protect against a scenario collision handling already
 prevents, while making the everyday case — a machine that already has real
 files in `~/Documents`, `~/Pictures`, etc. — a silent no-op unless the flag
 was remembered, which defeats the point of the task.
 In its place:
 - `dot setup folders` always attempts the merge for every legacy folder,
  content or none.
 - A new `--dry-run` flag replaces `--yes` in the flag slot: it reports what
  would move and what would be skipped as a collision, without touching the
  filesystem at all (no `mkdir`, no `mv`/`rmdir`, no `xdg-user-dirs-update`).
 - A real (non-dry-run) run now reports what it moved per legacy folder
  (e.g. `moved 12 entries from ~/Documents to ~/doc`), instead of staying
  silent on success. A folder where nothing top-level moved (already empty,
  or everything in it collided) prints no such line — only non-trivial moves
  and collisions produce output.
 - `--yes` is removed outright (not kept as a silent no-op): passing it now
  fails with argparse's standard unknown-option error.
 ## Acceptance criteria
 - [x] A legacy folder with real content merges on a plain `dot setup
      folders`, with no flag required
 - [x] A real run prints `moved N entries from ~/<legacy> to ~/<target>` for a
      folder where top-level entries actually moved, and nothing for a
      folder where none did
 - [x] A real run prints a dedicated line when the nested Screenshots folder
      itself is moved (e.g. `moved ~/Pictures/Screenshots to ~/pic/screenshots`)
 - [x] Collision detection/reporting and the "leave the legacy folder in
      place when a collision occurred" behavior from 0008 are unchanged
      under the new unconditional default
 - [x] `--dry-run` reports the same would-move/would-skip information without
      creating any target directory, moving/removing anything, or invoking
      `xdg-user-dirs-update`
 - [x] `dot setup folders --yes` fails with an unknown-option error (argparse
      default), rather than being silently accepted or gated on
 - [x] `dot setup folders help` output no longer mentions `--yes` and
      documents `--dry-run` instead
 - [x] Idempotency holds: re-running after a clean merge, and re-running
      after a collision was reported, both behave the same as before
 - [x] `~/.config/dot/tests/dot.fish` is updated to exercise the above
      (replacing the old `--yes`-gated cases) and
      `fishtape ~/.config/dot/tests/dot.fish` passes
 ## Implementation Notes
 - The `--yes` gate and the `screenshots_emptyish`/`other_entries` machinery
  that computed it were deleted outright rather than special-cased away:
  once merging is unconditional, that machinery had no remaining purpose
  (it existed solely to decide "empty enough to skip the gate").
 - `mkdir -p $target_path` and the final `xdg-user-dirs-update` are both now
  guarded by `not set -q _flag_dry_run`, making `--dry-run` a true no-op
  rather than "no-op except for directory scaffolding."
 - Collision detection (`test -e $target_path/...`) runs identically in both
  modes; `--dry-run` only gates the actual `mv`/`rmdir`/`mkdir` calls, so the
  reported would-move/would-skip split is exactly what a real run would do.
 - Success reporting is per-legacy-folder and suppressed at zero: a folder
  that was already empty (or whose only entries all collided) prints
  nothing, so a routine re-run stays quiet like before.
 - All prior collision/idempotency/Screenshots test scenarios were kept,
  just re-pointed at the plain `dot setup folders` invocation instead of
  `--yes`; two scenarios that only differed by which code branch (`--yes`
  vs. silent-empty) they exercised now hit the same branch, but were both
  kept since they still cover distinct fixture shapes (Pictures with vs.
  without unrelated top-level content alongside a colliding Screenshots).
 - `fishtape ~/.config/dot/tests/dot.fish` passes (178 tests).
--- a/.config/dot/.claude/tasks/0012-folders-fixed-target-mapping.md
+++ b/.config/dot/.claude/tasks/0012-folders-fixed-target-mapping.md
@@ -1,64 +0,0 @@
 ---
 spec: dot-setup-folders
 blocked-by: 0011-folders-unconditional-merge
 ---
 ## What to build
 Stop reading the short-name target from `~/.config/user-dirs.dirs` and
 hardcode the legacy-name -> short-name mapping directly in
 `_dot_setup_folders`, dropping the dependency on that file entirely.
 The original design treated the tracked `user-dirs.dirs` as the single
 source of truth for target names, assuming someone would hand-edit it to
 the short names before ever running the command. On this machine that
 never happened: the tracked file still had the stock XDG defaults
 (`XDG_DOCUMENTS_DIR="$HOME/Documents"`, etc.), so `target_path` resolved to
 the exact same directory as `legacy_path` for every folder. The migration
 logic then reported every entry as a "collision" against itself instead of
 moving anything -- a confusing, silent-feeling failure rather than an
 actual migration.
 The short names are fixed (`.desktop`, `doc`, `dwn`, `mus`, `pic`, `vid`,
 `.ignoreme`) and not meant to be configurable, so there's nothing to read
 from a file in the first place. `user-dirs.dirs` remains a separate,
 manually tracked dotfile (edited and tracked by hand, like any other
 dotfile) for apps/`xdg-user-dirs-update` to consult -- `dot setup folders`
 itself no longer reads it, requires its presence, or writes to it.
 ## Acceptance criteria
 - [x] `_dot_setup_folders` no longer reads, parses, or requires
      `~/.config/user-dirs.dirs`; the legacy->short-name mapping is a fixed
      table in the function itself
 - [x] Migration works identically whether `user-dirs.dirs` is absent,
      empty, or declares stale/full-name values (the exact real-world case)
 - [x] `user-dirs.dirs` is left byte-for-byte untouched by `dot setup
      folders` when present, and no file is created when absent
 - [x] `dot setup folders help` no longer describes reading target names
      from `user-dirs.dirs`
 - [x] `~/.config/dot/tests/dot.fish` no longer seeds a `user-dirs.dirs`
      fixture as a migration precondition, and covers the stale/missing
      cases above; `fishtape ~/.config/dot/tests/dot.fish` passes
 ## Implementation Notes
 - Replaced the `xdg_vars`/`grep`/`string match` parsing of `user-dirs.dirs`
  with two parallel hardcoded arrays, `legacy_names` and `target_names`,
  indexed together -- same shape the code already used for `legacy_names`
  alone, just extended to cover the target side too.
 - The early `if not test -f $user_dirs; return 1` guard was deleted outright
  rather than kept as a soft check: there's nothing left for the function to
  read from that file, so requiring its existence would just be a
  vestigial, unjustifiable precondition.
 - Removed the `short_name_user_dirs` fixture and its seeding step from every
  test scenario (it was previously duplicated into ~15 scenarios as a
  migration precondition); added two new scenarios instead: one reproducing
  the exact real-machine bug (stale full-name `user-dirs.dirs` values) and
  one confirming migration works with no `user-dirs.dirs` file at all.
 - Verified against this machine's real, still-stale `~/.config/user-dirs.dirs`
  via `_dot_setup_folders --dry-run`: previously reported every entry in
  Desktop/Documents/Downloads/Pictures/Videos as a collision against
  itself; now correctly reports `would move N entries from ~/Documents to
  ~/doc` etc.
 - `fishtape ~/.config/dot/tests/dot.fish` passes (183 tests).
--- a/.config/dot/CLAUDE.md
+++ b/.config/dot/CLAUDE.md
@@ -1,167 +0,0 @@
 # Dotfiles
 This machine's dotfiles are a bare git repo at `~/.dotfiles`, checked out with
 `$HOME` as its work-tree. The `dot` fish function wraps that invocation
 (`git --git-dir=~/.dotfiles --work-tree=$HOME $argv`, declared with
 `--wraps=git`), so every git subcommand works through it: `dot status`,
 `dot add`, `dot commit`, `dot push`, etc.
 This directory (`~/.config/dot`) holds the `dot` CLI's custom subcommands,
 tests, and package lists, but the repo tracks files across `$HOME` — fish
 config, git identity, the `dot` function itself, and more. To see everything
 tracked, run `dot ls-tree -r --name-only HEAD` from `$HOME` (paths are shown
 relative to cwd, so running it from elsewhere silently truncates the list).
 For an agent driving this through separate tool calls: `cd ~` in one call does
 not reliably carry over to the next, since each call may reset to the
 project's working directory. Always `cd "$HOME"` and run the `ls-tree` (or any
 other cwd-sensitive `dot`/`git` command) in that *same* call — e.g.
 `cd "$HOME" && dot ls-tree -r --name-only HEAD` — rather than trusting a prior
 `cd` to have stuck. Getting this wrong silently narrows the listing to
 whatever the leftover cwd happens to be, which reads as "this file isn't
 tracked" when it actually is.
 ## Always add by explicit path
 `status.showUntrackedFiles=no` is set locally (see `dot init` below), and
 `.gitignore` only excludes `.dotfiles` itself plus OS/editor cruft — it is
 **not** a whitelist. That
 means virtually everything under `$HOME` reads as untracked, and `git status`
 deliberately hides all of it.
 **Always run `dot add <specific-path>`.** Never `dot add -A`, `dot add .`, or
 any wildcard add — that would try to stage the entire home directory (caches,
 secrets, everything).
 **Stage automatically after changes.** Once a tracked file is edited, run
 `dot add <specific-path>` for it right away rather than waiting to be asked —
 one explicit path per changed file, still never a wildcard. This does not
 extend to `dot commit` or `dot push`, which still require an explicit
 request.
 ## The dot CLI
 ### Architecture
 `dot` is defined in one file: `~/.config/fish/functions/dot.fish`. It holds
 three functions:
 - `dot` (`--wraps=git`) — dispatches `init`, `help`, and any file found under
  `~/.config/dot/commands/`, otherwise forwards everything to
  `git --git-dir=~/.dotfiles --work-tree=$HOME $argv` (full passthrough).
 - `__dot_init` — the bootstrap logic, inlined in the same file rather than
  autoloaded separately, because it's the one subcommand that must work
  before the dotfiles repo has ever been cloned onto a machine.
 - `__dot_help` — prints usage: the built-in commands plus whatever is
  currently found under `~/.config/dot/commands/`, generated by globbing that
  directory rather than a hardcoded list, so it can't drift from reality.
 `__dot_help`'s glob over `~/.config/dot/commands/*.fish` is duplicated in
 `~/.config/fish/completions/dot.fish`'s `__dot_custom_subcommands` rather than
 shared: fish only autoloads a function from a file named after that function,
 so a helper defined inside `dot.fish` would be undefined if tab-completion
 ran before `dot` had ever been sourced in the session. Keep both copies in
 sync when the listing logic changes.
 Both copies also glob one directory level deeper, matching `~/.config/dot/commands/<name>/<name>.fish`, so a subcommand's companion file (e.g. a Python helper) can live alongside it in its own directory.
 `dot init`:
 - refuses to run if `~/.dotfiles` already exists (no re-init support)
 - clones the bare repo from `--url` (default: the hardcoded Gitea remote) —
  if the clone fails, it errors out; it never falls back to `git init`
 - backs up any pre-existing file that checkout would clobber into
  `~/.dotfiles-backup/<timestamp>/`, then retries the checkout
 - explicitly sets `status.showUntrackedFiles=no` after cloning — this is a
  local-only git setting, so a fresh `git clone` never carries it over
 ### Adding a subcommand
 Beyond `init`, `dot` looks for `~/.config/dot/commands/<name>.fish`, sources
 it, and calls `_dot_<name>`.
 A subcommand needing a companion file can instead live nested one level deeper, as `~/.config/dot/commands/<name>/<name>.fish` — both layouts dispatch identically.
 These files are deliberately kept out of
 `~/.config/fish/functions/` (fish's autoload path) so they never become
 independently invokable top-level commands or clutter tab-completion outside
 of `dot` itself.
 1. Create `~/.config/dot/commands/<name>.fish` defining a `_dot_<name>`
   function.
 2. Confirm `dot <name>` dispatches to it. No other wiring is needed —
   `~/.config/fish/completions/dot.fish` and `__dot_help` both discover new
   command files by globbing that directory, and `--wraps=git` still covers
   raw git subcommands.
 3. Implement a `help` subcommand: check for `help` as `_dot_<name>`'s first
   positional argument before `argparse`, and call a `_dot_<name>_usage`
   function that prints usage and every flag. If `_dot_<name>` itself
   dispatches to nested subcommands, apply this same check-then-dispatch
   pattern at that level too — there's no central `--help` handling in
   `dot.fish` to lean on; each level is responsible for its own.
   `_dot_<name>_usage` should print its text as a single multi-line
   `echo "..."` string (fish preserves literal newlines inside double
   quotes) rather than one `echo` per line.
 4. Add a row to `~/.github/README.md`'s command table for it — one row per
   distinct use case, with paths written relative to `$HOME`
   (`~/.config/dot/...`), not relative to the README's own location.
 5. Add a case to `~/.config/dot/tests/dot.fish` covering it, including its
   `help` output, and run `fishtape ~/.config/dot/tests/dot.fish` until it
   passes.
 ### Testing
 Tests live at `~/.config/dot/tests/dot.fish`, run with
 `fishtape ~/.config/dot/tests/dot.fish`. Fishtape is installed via Fisher
 (`fisher install jorgebucaran/fishtape`) and tracked in
 `~/.config/fish/fish_plugins` — a real, restorable dependency for developing
 `dot`, but never required just to use it.
 - Each scenario overrides `$HOME` (`set -gx HOME (mktemp -d)`) before calling
  `dot`, so tests never touch the real `~/.dotfiles`.
 - Build a throwaway bare "remote" fixture with `git init --bare` plus a
  seeded commit, and explicitly set its `HEAD`
  (`git --git-dir=$remote symbolic-ref HEAD refs/heads/main`). Pushing with
  `git push origin HEAD:main` does **not** update the bare repo's `HEAD`
  symref — skip this and a clone of the fixture can end up "on a branch yet
  to be born."
 - Don't use `.gitconfig` as a fake pre-existing "conflict" file in a
  fixture — git parses `$HOME/.gitconfig` as its own global config on every
  invocation, and garbage content there spams "key does not contain a
  section" errors that drown out the real assertion. Use a harmless file
  like `.bashrc` instead.
 - `@test "description" <expr> <op> <expected>` mirrors fish's `test` builtin
  (`-eq`, `-ne`, `=`, `-e`, `-f`, `-d`, `-n`, `-z`); `-a`/`-o` combinators
  aren't supported.
 ## Gotchas
 - `~/.claude/` (Claude Code's own config: skills, agents, commands, etc.) is
  a plain directory, not a separate git repo of its own — plain `git` commands
  run from inside it report "not a git repository". It's tracked the same way
  as everything else under `$HOME`: through the `dot` bare repo. Use
  `dot add`/`dot status` on paths under `~/.claude/`, not a `git` invocation
  scoped to that directory, and don't assume an unrelated repo (e.g. a
  separate skills-source checkout elsewhere) is the tracked copy just because
  it also holds a copy of the same files.
 - `~/.claude/` and this project's own `.claude/` (e.g. `~/.config/dot/.claude/`)
  are two different directories that both happen to exist. Project-relative
  paths referenced in specs, task breakdowns, or other project docs — like
  `.claude/spec/<slug>.md` or `.claude/tasks/<NNNN>-<slug>.md` — are relative
  to this project directory (`~/.config/dot/.claude/...`), not to
  `$HOME/.claude/`. Writing to `$HOME/.claude/tasks/` instead of
  `~/.config/dot/.claude/tasks/` silently lands files in Claude Code's own
  global config dir instead of the project.
 - An agent's `Bash` tool runs commands through **zsh**, not fish, so the
  `dot` fish function (defined in `~/.config/fish/functions/dot.fish`) is
  not on that shell's autoload path. Typing `dot <subcommand>` there
  silently resolves to `/usr/bin/dot` (Graphviz) instead, producing
  confusing "can't open <arg>: No such file or directory" / "syntax error
  near '--'" errors rather than a clear "command not found". Either invoke
  it as `fish -c "dot <subcommand> ..."`, or bypass the wrapper and call
  `git --git-dir=$HOME/.dotfiles --work-tree=$HOME <args>` directly.
 ## Keybindings
 Whenever a keybind is added, changed, or removed in *any* config on this
 machine (tmux, KDE, neovim, fish, whatever), add or update its row in
 [`~/.github/keybindings.md`](../../.github/keybindings.md) in the same
 change. That file is the single reference for every keybind across tools —
 it drifts the moment a bind changes somewhere without a matching edit there.
--- a/.config/dot/commands/install.fish
+++ b/.config/dot/commands/install.fish
@@ -1,59 +0,0 @@
 function _dot_install_usage
    echo "usage: dot install [--restore] [--no-sync] [package ...]
  --restore   reinstall every package from the tracked list
  --no-sync   skip 'pacman -Sy' before installing"
 end
 function _dot_install
    if test "$argv[1]" = help
        _dot_install_usage
        return 0
    end
    argparse 'restore' 'no-sync' -- $argv
    or return 1
    set -l list_dir $HOME/.config/dot/packages
    set -l list_file $list_dir/pacman
    set -l packages
    if set -q _flag_restore
        if test (count $argv) -gt 0
            echo "dot install: --restore cannot be combined with package names" >&2
            return 1
        end
        if not test -s $list_file
            echo "dot install: no package list found at $list_file" >&2
            return 1
        end
        set packages (cat $list_file)
    else
        if test (count $argv) -eq 0
            echo "dot install: no packages given (use --restore to reinstall from the list)" >&2
            return 1
        end
        set packages $argv
    end
    if not set -q _flag_no_sync
        sudo pacman -Sy
        or return 1
    end
    sudo pacman -S --needed $packages
    or return 1
    if set -q _flag_restore
        return 0
    end
    mkdir -p $list_dir
    test -f $list_file
    or touch $list_file
    printf '%s\n' $packages >>$list_file
    sort -u -o $list_file $list_file
 end
--- a/.config/dot/commands/kde/kde.fish
+++ b/.config/dot/commands/kde/kde.fish
@@ -1,35 +0,0 @@
 function _dot_kde_usage
    echo "usage: dot kde <command>
 Commands:
  apply   push manifest entries onto the live system
  diff    scan for settings whose live value differs from its default
  save    write live KDE settings into the manifest
  help    show this message
 Run 'dot kde <command> help' for flags on a specific command."
 end
 function _dot_kde
    if test "$argv[1]" = help
        _dot_kde_usage
        return 0
    end
    set -l helper_dir (status dirname)
    switch "$argv[1]"
        case apply
            python3 $helper_dir/kde.py apply $argv[2..-1]
            return $status
        case diff
            python3 $helper_dir/kde.py diff $argv[2..-1]
            return $status
        case save
            python3 $helper_dir/kde.py save $argv[2..-1]
            return $status
        case '*'
            _dot_kde_usage
            return 1
    end
 end
--- a/.config/dot/commands/kde/kde.py
+++ b/.config/dot/commands/kde/kde.py
@@ -1,535 +0,0 @@
 #!/usr/bin/env python3
 import json
 import os
 import subprocess
 import sys
 import xml.etree.ElementTree as ET
 from collections import defaultdict, namedtuple
 from pathlib import Path
 KCFG_NS = "{http://www.kde.org/standards/kcfg/1.0}"
 DEFAULT_SCHEMA_DIR = "/usr/share/config.kcfg"
 KGLOBALACCEL_SERVICE = "org.kde.kglobalaccel"
 KGLOBALACCEL_PATH = "/kglobalaccel"
 KGLOBALACCEL_IFACE = "org.kde.KGlobalAccel"
 # KGlobalAccel::GlobalShortcutLoading::NoAutoloading, per KF6/KGlobalAccel/kglobalaccel.h --
 # makes a write always win over whatever shortcut was previously saved, rather than being
 # ignored in favor of it (the Autoloading=0x0 default).
 SHORTCUT_NO_AUTOLOADING = 0x4
 # .kcfg files that only declare their target rc file at runtime
 # (<kcfgfile arg="true">), so it can't be discovered by scanning.
 ARG_TRUE_RCFILES = {
    "kwin.kcfg": "kwinrc",
 }
 SAVE_USAGE = """usage: dot kde save [identifier]
  identifier   declare a new manifest entry, seeded from its current live value
  (no args)    refresh every already-declared manifest entry from the live system
  help         show this message"""
 APPLY_USAGE = """usage: dot kde apply
  Pushes every manifest entry's declared value onto the live system.
  help         show this message"""
 DIFF_USAGE = """usage: dot kde diff
  Scans every schema-backed setting reachable through the kcfg mapping
  table, and every shortcut registered with kglobalaccel, reporting each
  one whose live value differs from its default, tagged declared
  (present in the manifest) or undeclared. Also reports already-declared
  freeform settings whose live value differs from their default (no
  schema to broad-scan, so it's only checked when already declared).
  Read-only -- never writes the manifest or the live system.
  help         show this message"""
 Setting = namedtuple("Setting", ["file", "group", "key"])
 def _split_on_known_prefix(rest, candidates):
    matches = [c for c in candidates if rest == c or rest.startswith(c + ".")]
    if not matches:
        return None
    prefix = max(matches, key=len)
    remainder = rest[len(prefix):].lstrip(".")
    if not remainder:
        return None
    return prefix, remainder
 def _known_schema_groups(file, kcfg_map):
    groups = set()
    for path in kcfg_map.get(file, []):
        root = _parse_kcfg(path)
        if root is None:
            continue
        for group_elem in root.iter(f"{KCFG_NS}group"):
            name = group_elem.get("name")
            if name:
                groups.add(name)
    return groups
 def _split_schema_group_key(file, rest, kcfg_map):
    match = _split_on_known_prefix(rest, _known_schema_groups(file, kcfg_map))
    if match is not None:
        return match
    # No schema group matches -- freeform. Its group is never known to contain
    # a dot (there's no schema to have told us otherwise), so the boundary is
    # just the first remaining dot.
    group, _, key = rest.partition(".")
    if not key:
        raise ValueError(f"invalid identifier {file}.{rest!r} (expected file.group.key)")
    return group, key
 def _split_shortcut_group_key(rest):
    (components,) = _kglobalaccel_call("allMainComponents", None)
    match = _split_on_known_prefix(rest, [component[0] for component in components])
    if match is None:
        raise RuntimeError(
            f"no live kglobalaccel component matches {rest!r} "
            "(the owning application may need to run once to register its shortcuts with kglobalaccel)"
        )
    return match
 # Only the file segment is unambiguous (rc file names never contain a dot).
 # The group/key boundary can't be found by counting dots -- both KConfig group
 # names (e.g. "org.kde.kdecoration2") and kglobalaccel componentUnique names
 # (e.g. "org.kde.dolphin.desktop") routinely contain their own dots -- so it's
 # resolved against known-good data instead: the live kglobalaccel component
 # list for shortcuts, the kcfg schema's declared group names for everything
 # else (falling back to freeform's first-dot split when no schema matches).
 def parse_identifier(identifier, kcfg_map):
    file, sep, rest = identifier.partition(".")
    if not sep or not rest:
        raise ValueError(f"invalid identifier {identifier!r} (expected file.group.key)")
    if file == "kglobalshortcutsrc":
        group, key = _split_shortcut_group_key(rest)
    else:
        group, key = _split_schema_group_key(file, rest, kcfg_map)
    return Setting(file, group, key)
 def load_manifest(path):
    entries = {}
    if not path.exists():
        return entries
    for line in path.read_text().splitlines():
        if not line.strip():
            continue
        identifier, _, value = line.partition("=")
        entries[identifier] = value
    return entries
 def write_manifest(path, entries):
    lines = [f"{identifier}={value}" for identifier, value in entries.items()]
    path.write_text("".join(f"{line}\n" for line in lines))
 def _parse_kcfg(path):
    try:
        return ET.parse(path).getroot()
    except ET.ParseError:
        return None
 def _kcfgfile_name(root):
    elem = root.find(f"{KCFG_NS}kcfgfile")
    if elem is None:
        return None
    return elem.get("name")
 def build_kcfg_map(schema_dir):
    mapping = defaultdict(list)
    if not schema_dir.is_dir():
        return mapping
    for path in sorted(schema_dir.glob("*.kcfg")):
        root = _parse_kcfg(path)
        if root is None:
            continue
        rcfile = _kcfgfile_name(root) or ARG_TRUE_RCFILES.get(path.name)
        if rcfile:
            mapping[rcfile].append(path)
    return mapping
 def find_schema_default(kcfg_paths, setting):
    for path in kcfg_paths:
        root = _parse_kcfg(path)
        if root is None:
            continue
        for group_elem in root.iter(f"{KCFG_NS}group"):
            if group_elem.get("name") != setting.group:
                continue
            for entry in group_elem.findall(f"{KCFG_NS}entry"):
                if (entry.get("key") or entry.get("name")) != setting.key:
                    continue
                default_elem = entry.find(f"{KCFG_NS}default")
                return default_elem.text if default_elem is not None and default_elem.text else ""
    return None
 def iter_schema_identifiers(kcfg_map):
    for rcfile, paths in kcfg_map.items():
        for path in paths:
            root = _parse_kcfg(path)
            if root is None:
                continue
            for group_elem in root.iter(f"{KCFG_NS}group"):
                group = group_elem.get("name")
                if not group:
                    continue
                for entry in group_elem.findall(f"{KCFG_NS}entry"):
                    key = entry.get("key") or entry.get("name")
                    if key:
                        yield Setting(rcfile, group, key)
 def resolve_mechanism(setting, kcfg_map):
    if setting.file == "kglobalshortcutsrc":
        return "shortcuts", None
    default = find_schema_default(kcfg_map.get(setting.file, []), setting)
    if default is not None:
        return "schema", default
    return "freeform", None
 def read_live_value(setting, default):
    cmd = ["kreadconfig6", "--file", setting.file, "--group", setting.group, "--key", setting.key]
    if default is not None:
        cmd += ["--default", default]
    result = subprocess.run(cmd, capture_output=True, text=True)
    if result.returncode != 0:
        raise RuntimeError(
            f"kreadconfig6 failed for {setting.file}/{setting.group}/{setting.key}: {result.stderr.strip()}"
        )
    return result.stdout.rstrip("\n")
 def write_live_value(setting, value):
    cmd = [
        "kwriteconfig6",
        "--file", setting.file,
        "--group", setting.group,
        "--key", setting.key,
        "--",
        value,
    ]
    result = subprocess.run(cmd, capture_output=True, text=True)
    if result.returncode != 0:
        raise RuntimeError(
            f"kwriteconfig6 failed for {setting.file}/{setting.group}/{setting.key}: {result.stderr.strip()}"
        )
 def _key_sequence_class():
    try:
        from PyQt6.QtGui import QKeySequence
    except ImportError as e:
        raise RuntimeError(
            "the shortcuts mechanism requires PyQt6 (install python-pyqt6) to translate key names"
        ) from e
    return QKeySequence
 def _keys_to_string(key_ints):
    QKeySequence = _key_sequence_class()
    return "\t".join(QKeySequence(key).toString() for key in key_ints)
 def _string_to_keys(value):
    if not value:
        return []
    QKeySequence = _key_sequence_class()
    keys = []
    for part in value.split("\t"):
        part = part.strip()
        if not part or part.lower() == "none":
            continue
        sequence = QKeySequence(part)
        if sequence.count() != 1:
            raise RuntimeError(f"invalid key sequence {part!r} (expected exactly one key combination)")
        keys.append(int(sequence[0].toCombined()))
    return keys
 def _kglobalaccel_call(method, signature, *tokens):
    cmd = ["busctl", "--user", "--json=short", "call",
           KGLOBALACCEL_SERVICE, KGLOBALACCEL_PATH, KGLOBALACCEL_IFACE, method]
    if signature:
        cmd += [signature, *(str(token) for token in tokens)]
    result = subprocess.run(cmd, capture_output=True, text=True)
    if result.returncode != 0:
        raise RuntimeError(f"kglobalaccel {method} failed: {result.stderr.strip()}")
    return json.loads(result.stdout)["data"]
 def _actions_for_component(component_unique):
    (actions,) = _kglobalaccel_call("allActionsForComponent", "as", 1, component_unique)
    return actions
 def iter_shortcut_identifiers():
    (components,) = _kglobalaccel_call("allMainComponents", None)
    for component in components:
        for action in _actions_for_component(component[0]):
            yield Setting("kglobalshortcutsrc", action[0], action[1])
 def _resolve_shortcut_action_id(component_unique, action_unique):
    for action in _actions_for_component(component_unique):
        if action[0] == component_unique and action[1] == action_unique:
            return action
    raise RuntimeError(
        f"no shortcut action {action_unique!r} in component {component_unique!r} "
        "(the owning application may need to run once to register its shortcuts with kglobalaccel)"
    )
 # The plural *Keys methods (a(ai), one 4-int QKeyCombination chord slot per bound
 # key sequence) are used instead of the singular shortcut()/defaultShortcut()/
 # setShortcut() methods the flat ai signature suggests: on this KF6 build,
 # defaultShortcut() was empirically found to just mirror shortcut() -- returning
 # whatever the *current* value is rather than the true packaged default -- while
 # defaultShortcutKeys() correctly returns the untouched default even after
 # setShortcutKeys() has changed the current value. Only single, non-chorded key
 # combinations are supported (see _string_to_keys), so only the first of each
 # chord's 4 int slots is ever meaningful here; the rest are always 0.
 def _keys_from_chords(chords):
    return [chord[0][0] for chord in chords]
 def read_shortcut_value(component_unique, action_unique, method="shortcutKeys"):
    action_id = _resolve_shortcut_action_id(component_unique, action_unique)
    (chords,) = _kglobalaccel_call(method, "as", len(action_id), *action_id)
    return _keys_to_string(_keys_from_chords(chords))
 def write_shortcut_value(component_unique, action_unique, value):
    action_id = _resolve_shortcut_action_id(component_unique, action_unique)
    keys = _string_to_keys(value)
    tokens = [len(action_id), *action_id, len(keys)]
    for key in keys:
        tokens += [4, key, 0, 0, 0]
    tokens.append(SHORTCUT_NO_AUTOLOADING)
    _kglobalaccel_call("setShortcutKeys", "asa(ai)u", *tokens)
 def save_one(identifier, kcfg_map):
    setting = parse_identifier(identifier, kcfg_map)
    mechanism, default = resolve_mechanism(setting, kcfg_map)
    if mechanism == "shortcuts":
        return read_shortcut_value(setting.group, setting.key)
    return read_live_value(setting, default)
 def apply_one(identifier, value, kcfg_map):
    setting = parse_identifier(identifier, kcfg_map)
    mechanism, _default = resolve_mechanism(setting, kcfg_map)
    if mechanism == "shortcuts":
        write_shortcut_value(setting.group, setting.key, value)
        return
    write_live_value(setting, value)
 def cmd_save(args, manifest_path, schema_dir):
    if args and args[0] == "help":
        print(SAVE_USAGE)
        return 0
    if len(args) > 1:
        print("dot kde save: too many arguments", file=sys.stderr)
        return 1
    kcfg_map = build_kcfg_map(schema_dir)
    manifest = load_manifest(manifest_path)
    try:
        if args:
            manifest[args[0]] = save_one(args[0], kcfg_map)
        else:
            for identifier in manifest:
                manifest[identifier] = save_one(identifier, kcfg_map)
    except (ValueError, RuntimeError) as e:
        print(f"dot kde save: {e}", file=sys.stderr)
        return 1
    write_manifest(manifest_path, manifest)
    return 0
 def cmd_apply(args, manifest_path, schema_dir):
    if args and args[0] == "help":
        print(APPLY_USAGE)
        return 0
    if args:
        print("dot kde apply: too many arguments", file=sys.stderr)
        return 1
    kcfg_map = build_kcfg_map(schema_dir)
    manifest = load_manifest(manifest_path)
    try:
        for identifier, value in manifest.items():
            apply_one(identifier, value, kcfg_map)
    except (ValueError, RuntimeError) as e:
        print(f"dot kde apply: {e}", file=sys.stderr)
        return 1
    return 0
 def cmd_diff(args, manifest_path, schema_dir):
    if args and args[0] == "help":
        print(DIFF_USAGE)
        return 0
    if args:
        print("dot kde diff: too many arguments", file=sys.stderr)
        return 1
    kcfg_map = build_kcfg_map(schema_dir)
    manifest = load_manifest(manifest_path)
    for setting in sorted(set(iter_schema_identifiers(kcfg_map))):
        identifier = f"{setting.file}.{setting.group}.{setting.key}"
        default = find_schema_default(kcfg_map.get(setting.file, []), setting)
        try:
            live = read_live_value(setting, default)
        except RuntimeError as e:
            print(f"dot kde diff: {e}", file=sys.stderr)
            continue
        if live == default:
            continue
        tag = "declared" if identifier in manifest else "undeclared"
        print(f"{tag} {identifier} = {live} (default: {default})")
    # Shortcuts are enumerable via kglobalaccel's allMainComponents/
    # allActionsForComponent (the same source iter_shortcut_identifiers already
    # walks for tab-completion), so unlike freeform they can participate in
    # broad undeclared-drift discovery too.
    try:
        shortcut_settings = sorted(set(iter_shortcut_identifiers()))
    except (RuntimeError, OSError) as e:
        print(f"dot kde diff: shortcuts scan unavailable: {e}", file=sys.stderr)
        shortcut_settings = []
    for setting in shortcut_settings:
        identifier = f"{setting.file}.{setting.group}.{setting.key}"
        try:
            live = read_shortcut_value(setting.group, setting.key)
            default = read_shortcut_value(setting.group, setting.key, method="defaultShortcutKeys")
        except RuntimeError as e:
            print(f"dot kde diff: {e}", file=sys.stderr)
            continue
        if live == default:
            continue
        tag = "declared" if identifier in manifest else "undeclared"
        print(f"{tag} {identifier} = {live} (default: {default})")
    # Freeform settings have no schema to enumerate from, so unlike the
    # schema-backed and shortcuts scans above, they can only be checked by
    # walking identifiers already in the manifest -- they never surface an
    # undeclared setting via broad scan. Shortcuts entries are skipped here
    # (rather than re-parsed) since the broad-scan pass above already reports
    # every declared shortcut mismatch; parsing one here would also mean an
    # extra live kglobalaccel round-trip per entry for no benefit.
    for identifier in manifest:
        if identifier.split(".", 1)[0] == "kglobalshortcutsrc":
            continue
        try:
            setting = parse_identifier(identifier, kcfg_map)
            mechanism, default = resolve_mechanism(setting, kcfg_map)
            if mechanism != "freeform":
                continue
            live = read_live_value(setting, default)
            if live == "":
                continue
        except (ValueError, RuntimeError) as e:
            print(f"dot kde diff: {e}", file=sys.stderr)
            continue
        print(f"declared {identifier} = {live} (default: {default or ''})")
    return 0
 def cmd_complete(schema_dir):
    kcfg_map = build_kcfg_map(schema_dir)
    for setting in sorted(set(iter_schema_identifiers(kcfg_map))):
        print(f"{setting.file}.{setting.group}.{setting.key}")
    try:
        # Fish's completion runs this on every TAB press, in shells that may have no
        # live KDE session (or no busctl at all) -- a broken shortcuts source must
        # never cost the schema-backed candidates already printed above.
        shortcut_settings = sorted(set(iter_shortcut_identifiers()))
    except (RuntimeError, OSError):
        shortcut_settings = []
    for setting in shortcut_settings:
        print(f"{setting.file}.{setting.group}.{setting.key}")
    return 0
 def main(argv):
    if not argv:
        print("dot kde: no command given", file=sys.stderr)
        return 1
    command, rest = argv[0], argv[1:]
    schema_dir = Path(os.environ.get("DOT_KDE_KCFG_DIR", DEFAULT_SCHEMA_DIR))
    manifest_path = Path(os.environ["HOME"]) / ".config" / "dot" / "kde-manifest"
    if command == "save":
        return cmd_save(rest, manifest_path, schema_dir)
    if command == "apply":
        return cmd_apply(rest, manifest_path, schema_dir)
    if command == "diff":
        return cmd_diff(rest, manifest_path, schema_dir)
    # Internal, not a user-facing `dot kde` subcommand -- called directly by
    # completions/dot.fish to source candidates from the live schema, never
    # dispatched to via kde.fish.
    if command == "complete":
        return cmd_complete(schema_dir)
    print(f"dot kde: unknown command {command!r}", file=sys.stderr)
    return 1
 if __name__ == "__main__":
    sys.exit(main(sys.argv[1:]))
--- a/.config/dot/commands/setup/folders.fish
+++ b/.config/dot/commands/setup/folders.fish
@@ -1,134 +0,0 @@
 function _dot_setup_folders_usage
    echo "usage: dot setup folders [--dry-run]
 Brings the 8 standard XDG user directories under the project's fixed
 short-name convention (Desktop -> .desktop, Documents -> doc, Downloads ->
 dwn, Music -> mus, Pictures -> pic, Videos -> vid, Templates/Public ->
 .ignoreme). This mapping is fixed and does not depend on
 ~/.config/user-dirs.dirs, which is a separate, manually tracked dotfile
 this command never reads or writes.
 Content left behind in a legacy full-named folder (e.g. ~/Documents) by a
 fresh XDG-defaults install -- empty or not -- is merged into its short-named
 replacement. A nested Pictures/Screenshots folder is renamed to
 pic/screenshots as part of the same pass.
 An entry that collides by name with something already in the short-named
 target is never overwritten: it's skipped, reported, and its legacy folder is
 left in place (not removed) even when everything else in it migrated.
  --dry-run   report what would move and what would be skipped as a
              collision, without changing anything on disk
 Runs xdg-user-dirs-update once afterwards to notify running apps/portals
 (skipped under --dry-run)."
 end
 function _dot_setup_folders
    if test "$argv[1]" = help
        _dot_setup_folders_usage
        return 0
    end
    argparse 'dry-run' -- $argv
    or return 1
    # Fixed legacy-name -> short-name mapping. Deliberately hardcoded rather
    # than read from ~/.config/user-dirs.dirs: that file is a separate,
    # manually tracked dotfile whose XDG_*_DIR values can drift or go stale
    # (or never get edited to the short names at all), and this command's
    # own migration logic must not depend on it being correct.
    set -l legacy_names Desktop Documents Downloads Music Pictures Videos Templates Public
    set -l target_names .desktop doc dwn mus pic vid .ignoreme .ignoreme
    for i in (seq (count $legacy_names))
        set -l legacy_name $legacy_names[$i]
        set -l target_rel $target_names[$i]
        set -l target_path $HOME/$target_rel
        set -l legacy_path $HOME/$legacy_name
        if not set -q _flag_dry_run
            mkdir -p $target_path
        end
        if not test -d $legacy_path
            continue
        end
        # Screenshots is always moved as one atomic unit (renamed to
        # lowercase screenshots), so its individual files must never appear
        # as separate move/report entries.
        set -l screenshots_path $legacy_path/Screenshots
        set -l top_level_entries (find $legacy_path -mindepth 1 -maxdepth 1 -not -name Screenshots)
        # No-clobber: an entry whose name already exists in the target is
        # never moved over. It's collected here and reported below; its
        # legacy folder is left in place (not removed) if any collision
        # occurred, even though everything else in it migrated successfully.
        set -l collisions
        set -l movable_entries
        set -l screenshots_movable 0
        if test -d $screenshots_path
            if test -e $target_path/screenshots
                set -a collisions $screenshots_path
            else
                set screenshots_movable 1
            end
        end
        for entry in $top_level_entries
            if test -e $target_path/(path basename $entry)
                set -a collisions $entry
            else
                set -a movable_entries $entry
            end
        end
        set -l movable_count (count $movable_entries)
        set -l entry_word entries
        test $movable_count -eq 1
        and set entry_word entry
        if set -q _flag_dry_run
            if test $screenshots_movable -eq 1
                echo "dot setup folders: would move $screenshots_path to $target_path/screenshots"
            end
            if test $movable_count -gt 0
                echo "dot setup folders: would move $movable_count $entry_word from ~/$legacy_name to ~/$target_rel"
            end
            if test (count $collisions) -gt 0
                echo "dot setup folders: ~/$legacy_name has entries already present in ~/$target_rel, would skip (not overwritten):"
                for c in $collisions
                    echo "  $c"
                end
                echo "dot setup folders: ~/$legacy_name would remain in place due to the collision(s) above"
            end
            continue
        end
        if test $screenshots_movable -eq 1
            mv -n $screenshots_path $target_path/screenshots
            echo "dot setup folders: moved $screenshots_path to $target_path/screenshots"
        end
        if test $movable_count -gt 0
            mv -n $movable_entries $target_path/
            echo "dot setup folders: moved $movable_count $entry_word from ~/$legacy_name to ~/$target_rel"
        end
        if test (count $collisions) -gt 0
            echo "dot setup folders: ~/$legacy_name has entries already present in ~/$target_rel, skipping (not overwritten):"
            for c in $collisions
                echo "  $c"
            end
            echo "dot setup folders: leaving ~/$legacy_name in place due to the collision(s) above"
        else
            rmdir $legacy_path
        end
    end
    if not set -q _flag_dry_run
        xdg-user-dirs-update
    end
 end
--- a/.config/dot/commands/setup/setup.fish
+++ b/.config/dot/commands/setup/setup.fish
@@ -1,35 +0,0 @@
 function _dot_setup_usage
    echo "usage: dot setup [<task>]
 Tasks:
  folders   bring the 8 standard XDG user directories under the short-name convention
  help      show this message
 Run 'dot setup <task> help' for details on a specific task.
 With no task given, runs every setup task."
 end
 function _dot_setup
    if test "$argv[1]" = help
        _dot_setup_usage
        return 0
    end
    set -l helper_dir (status dirname)
    source $helper_dir/folders.fish
    if test -z "$argv[1]"
        _dot_setup_folders
        return $status
    end
    switch $argv[1]
        case folders
            _dot_setup_folders $argv[2..-1]
            return $status
        case '*'
            _dot_setup_usage
            return 1
    end
 end
--- a/.config/dot/commands/vpn.fish
+++ b/.config/dot/commands/vpn.fish
@@ -1,29 +0,0 @@
 function _dot_vpn_usage
    echo "usage: dot vpn <command>
 Commands:
  up      bring the UDM-PRO-Laptop WireGuard connection up
  down    bring the UDM-PRO-Laptop WireGuard connection down
  help    show this message"
 end
 function _dot_vpn
    if test "$argv[1]" = help
        _dot_vpn_usage
        return 0
    end
    set -l connection UDM-PRO-Laptop
    switch "$argv[1]"
        case up
            nmcli connection up $connection
            return $status
        case down
            nmcli connection down $connection
            return $status
        case '*'
            _dot_vpn_usage
            return 1
    end
 end
--- a/.config/dot/kde-manifest
+++ b/.config/dot/kde-manifest
@@ -1,32 +0,0 @@
 kxkbrc.Layout.Options=caps:escape_shifted_capslock
 kglobalshortcutsrc.ksmserver.Lock Session=Meta+L	Screensaver
 kglobalshortcutsrc.kwin.Window to Desktop 1=Meta+!
 kglobalshortcutsrc.kwin.Window to Desktop 2=Meta+@
 kglobalshortcutsrc.kwin.Window to Desktop 3=Meta+#
 kglobalshortcutsrc.kwin.Window to Desktop 4=Meta+$
 kglobalshortcutsrc.kwin.Window to Desktop 5=Meta+%
 kglobalshortcutsrc.kwin.Window to Desktop 6=Meta+^
 kglobalshortcutsrc.kwin.Window to Desktop 7=Meta+&
 kglobalshortcutsrc.kwin.Window to Desktop 8=Meta+*
 kglobalshortcutsrc.kwin.Window to Desktop 9=Meta+(
 kglobalshortcutsrc.kwin.Switch to Desktop 1=Meta+1
 kglobalshortcutsrc.kwin.Switch to Desktop 2=Meta+2
 kglobalshortcutsrc.kwin.Switch to Desktop 3=Meta+3
 kglobalshortcutsrc.kwin.Switch to Desktop 4=Meta+4
 kglobalshortcutsrc.kwin.Switch to Desktop 5=Meta+5
 kglobalshortcutsrc.kwin.Switch to Desktop 6=Meta+6
 kglobalshortcutsrc.kwin.Switch to Desktop 7=Meta+7
 kglobalshortcutsrc.kwin.Switch to Desktop 8=Meta+8
 kglobalshortcutsrc.kwin.Switch to Desktop 9=Meta+9
 kglobalshortcutsrc.plasmashell.activate task manager entry 1=
 kglobalshortcutsrc.plasmashell.activate task manager entry 2=
 kglobalshortcutsrc.plasmashell.activate task manager entry 3=
 kglobalshortcutsrc.plasmashell.activate task manager entry 4=
 kglobalshortcutsrc.plasmashell.activate task manager entry 5=
 kglobalshortcutsrc.plasmashell.activate task manager entry 6=
 kglobalshortcutsrc.plasmashell.activate task manager entry 7=
 kglobalshortcutsrc.plasmashell.activate task manager entry 8=
 kglobalshortcutsrc.plasmashell.activate task manager entry 9=
 kglobalshortcutsrc.Alacritty.desktop._launch=Meta+Return
 kglobalshortcutsrc.org.kde.konsole.desktop._launch=
 kglobalshortcutsrc.kwin.Window Close=Meta+Shift+Q
--- a/.config/dot/packages/pacman
+++ b/.config/dot/packages/pacman
@@ -1,2 +0,0 @@
 neovim
 tmux
--- a/.config/dot/tests/dot.fish
+++ b/.config/dot/tests/dot.fish
--- a/.config/dot/tests/fixtures/kcfg/kwin.kcfg
+++ b/.config/dot/tests/fixtures/kcfg/kwin.kcfg
@@ -1,9 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <kcfg xmlns="http://www.kde.org/standards/kcfg/1.0">
  <kcfgfile arg="true"/>
  <group name="Windows">
    <entry name="BorderSize" type="String">
      <default>Normal</default>
    </entry>
  </group>
 </kcfg>
--- a/.config/dot/tests/fixtures/kcfg/testrc.kcfg
+++ b/.config/dot/tests/fixtures/kcfg/testrc.kcfg
@@ -1,15 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <kcfg xmlns="http://www.kde.org/standards/kcfg/1.0">
  <kcfgfile name="testrc"/>
  <group name="General">
    <entry name="Greeting" type="String">
      <default>Hello</default>
    </entry>
    <entry name="AliasedKey" key="RealKey" type="String">
      <default>AliasDefault</default>
    </entry>
    <entry name="Some.Key With Spaces" type="String">
      <default>SpacedDefault</default>
    </entry>
  </group>
 </kcfg>
--- a/.config/dot/tests/fixtures/kcfg/unmapped.kcfg
+++ b/.config/dot/tests/fixtures/kcfg/unmapped.kcfg
@@ -1,9 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <kcfg xmlns="http://www.kde.org/standards/kcfg/1.0">
  <kcfgfile arg="true"/>
  <group name="Whatever">
    <entry name="Setting" type="String">
      <default>Unreachable</default>
    </entry>
  </group>
 </kcfg>
--- a/.config/fish/completions/bun.fish
+++ b/.config/fish/completions/bun.fish
@@ -1,196 +0,0 @@
 # This is terribly complicated
 # It's because:
 # 1. bun run has to have dynamic completions
 # 2. there are global options
 # 3. bun {install add remove} gets special options
 # 4. I don't know how to write fish completions well
 # Contributions very welcome!!
 function __fish__get_bun_bins
 	string split ' ' (bun getcompletes b)
 end
 function __fish__get_bun_scripts
 	set -lx SHELL bash
 	set -lx MAX_DESCRIPTION_LEN 40
 	string trim (string split '\n' (string split '\t' (bun getcompletes z)))
 end
 function __fish__get_bun_packages
 	if test (commandline -ct) != ""
 		set -lx SHELL fish
 		string split ' ' (bun getcompletes a (commandline -ct))
 	end
 end
 function __history_completions
 	set -l tokens (commandline --current-process --tokenize)
 	history --prefix (commandline) | string replace -r \^$tokens[1]\\s\* "" | string replace -r \^$tokens[2]\\s\* "" | string split ' '
 end
 function __fish__get_bun_bun_js_files
 	string split ' ' (bun getcompletes j)
 end
 set -l bun_install_boolean_flags yarn production optional development no-save dry-run force no-cache silent verbose global
 set -l bun_install_boolean_flags_descriptions "Write a yarn.lock file (yarn v1)" "Don't install devDependencies" "Add dependency to optionalDependencies" "Add dependency to devDependencies" "Don't update package.json or save a lockfile" "Don't install anything" "Always request the latest versions from the registry & reinstall all dependencies" "Ignore manifest cache entirely" "Don't output anything" "Excessively verbose logging" "Use global folder"
 set -l bun_builtin_cmds_without_run dev create help bun upgrade discord install remove add update init pm x repl
 set -l bun_builtin_cmds_accepting_flags create help bun upgrade discord run init link unlink pm x update
 function __bun_complete_bins_scripts --inherit-variable bun_builtin_cmds_without_run -d "Emit bun completions for bins and scripts"
    # Do nothing if we already have a builtin subcommand,
    # or any subcommand other than "run".
    if __fish_seen_subcommand_from $bun_builtin_cmds_without_run
    or not __fish_use_subcommand && not __fish_seen_subcommand_from run
        return
    end
    # Do we already have a bin or script subcommand?
    set -l bins (__fish__get_bun_bins)
    if __fish_seen_subcommand_from $bins
        return
    end
    # Scripts have descriptions appended with a tab separator.
    # Strip off descriptions for the purposes of subcommand testing.
    set -l scripts (__fish__get_bun_scripts)
    if __fish_seen_subcommand_from (string split \t -f 1 -- $scripts)
        return
    end
    # Emit scripts.
    for script in $scripts
        echo $script
    end
    # Emit binaries and JS files (but only if we're doing `bun run`).
    if __fish_seen_subcommand_from run
        for bin in $bins
            echo "$bin"\t"package bin"
        end
        for file in (__fish__get_bun_bun_js_files)
            echo "$file"\t"Bun.js"
        end
    end
 end
 # Clear existing completions
 complete -e -c bun
 # Dynamically emit scripts and binaries
 complete -c bun -f -a "(__bun_complete_bins_scripts)"
 # Complete flags if we have no subcommand or a flag-friendly one.
 set -l flag_applies "__fish_use_subcommand; or __fish_seen_subcommand_from $bun_builtin_cmds_accepting_flags"
 complete -c bun \
 	-n $flag_applies --no-files -s 'u' -l 'origin' -r -d 'Server URL. Rewrites import paths'
 complete -c bun \
 	-n $flag_applies --no-files  -s 'p' -l 'port' -r -d 'Port number to start server from'
 complete -c bun \
 	-n $flag_applies --no-files  -s 'd' -l 'define' -r -d 'Substitute K:V while parsing, e.g. --define process.env.NODE_ENV:\"development\"'
 complete -c bun \
 	-n $flag_applies --no-files  -s 'e' -l 'external' -r -d 'Exclude module from transpilation (can use * wildcards). ex: -e react'
 complete -c bun \
 	-n $flag_applies --no-files -l 'use' -r -d 'Use a framework (ex: next)'
 complete -c bun \
 	-n $flag_applies --no-files -l 'hot' -r -d 'Enable hot reloading in Bun\'s JavaScript runtime'
 # Complete dev and create as first subcommand.
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'dev' -d 'Start dev server'
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'create' -f -d 'Create a new project from a template'
 # Complete "next" and "react" if we've seen "create".
 complete -c bun \
 	-n "__fish_seen_subcommand_from create" -a 'next' -d 'new Next.js project'
 complete -c bun \
 	-n "__fish_seen_subcommand_from create" -a 'react' -d 'new React project'
 # Complete "upgrade" as first subcommand.
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'upgrade' -d 'Upgrade bun to the latest version' -x
 # Complete "-h/--help" unconditionally.
 complete -c bun \
 	-s "h" -l "help" -d 'See all commands and flags' -x
 # Complete "-v/--version" if we have no subcommand.
 complete -c bun \
 	-n "not __fish_use_subcommand" -l "version" -s "v" -d 'Bun\'s version' -x
 # Complete additional subcommands.
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'discord' -d 'Open bun\'s Discord server' -x
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'bun' -d 'Generate a new bundle'
 complete -c bun \
 	-n "__fish_seen_subcommand_from bun" -F -d 'Bundle this'
 complete -c bun \
 	-n "__fish_seen_subcommand_from create; and __fish_seen_subcommand_from react next" -F -d "Create in directory"
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'init' -F -d 'Start an empty Bun project'
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'install' -f -d 'Install packages from package.json'
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'add' -F -d 'Add a package to package.json'
 complete -c bun \
 	-n "__fish_use_subcommand" -a 'remove' -F -d 'Remove a package from package.json'
 for i in (seq (count $bun_install_boolean_flags))
 	complete -c bun \
 		-n "__fish_seen_subcommand_from install add remove update" -l "$bun_install_boolean_flags[$i]" -d "$bun_install_boolean_flags_descriptions[$i]"
 end
 complete -c bun \
 	-n "__fish_seen_subcommand_from install add remove update" -l 'cwd' -d 'Change working directory'
 complete -c bun \
 	-n "__fish_seen_subcommand_from install add remove update" -l 'cache-dir' -d 'Choose a cache directory (default: $HOME/.bun/install/cache)'
 complete -c bun \
 	-n "__fish_seen_subcommand_from add" -d 'Popular' -a '(__fish__get_bun_packages)'
 complete -c bun \
 	-n "__fish_seen_subcommand_from add" -d 'History' -a '(__history_completions)'
 complete -c bun \
 	-n "__fish_seen_subcommand_from pm; and not __fish_seen_subcommand_from (__fish__get_bun_bins) (__fish__get_bun_scripts) cache;" -a 'bin ls cache hash hash-print hash-string' -f
 complete -c bun \
 	-n "__fish_seen_subcommand_from pm; and __fish_seen_subcommand_from cache; and not __fish_seen_subcommand_from (__fish__get_bun_bins) (__fish__get_bun_scripts);" -a 'rm' -f
 # Add built-in subcommands with descriptions.
 complete -c bun -n "__fish_use_subcommand" -a "create" -f -d "Create a new project from a template"
 complete -c bun -n "__fish_use_subcommand" -a "build bun" --require-parameter -F -d "Transpile and bundle one or more files"
 complete -c bun -n "__fish_use_subcommand" -a "upgrade" -d "Upgrade Bun"
 complete -c bun -n "__fish_use_subcommand" -a "run" -d "Run a script or package binary"
 complete -c bun -n "__fish_use_subcommand" -a "install" -d "Install dependencies from package.json" -f
 complete -c bun -n "__fish_use_subcommand" -a "remove" -d "Remove a dependency from package.json" -f
 complete -c bun -n "__fish_use_subcommand" -a "add" -d "Add a dependency to package.json" -f
 complete -c bun -n "__fish_use_subcommand" -a "init" -d "Initialize a Bun project in this directory" -f
 complete -c bun -n "__fish_use_subcommand" -a "link" -d "Register or link a local npm package" -f
 complete -c bun -n "__fish_use_subcommand" -a "unlink" -d "Unregister a local npm package" -f
 complete -c bun -n "__fish_use_subcommand" -a "pm" -d "Additional package management utilities" -f
 complete -c bun -n "__fish_use_subcommand" -a "x" -d "Execute a package binary, installing if needed" -f
 complete -c bun -n "__fish_use_subcommand" -a "outdated" -d "Display the latest versions of outdated dependencies" -f
 complete -c bun -n "__fish_use_subcommand" -a "update" -d "Update dependencies to their latest versions" -f
 complete -c bun -n "__fish_use_subcommand" -a "publish" -d "Publish your package from local to npm" -f
 complete -c bun -n "__fish_use_subcommand" -a "repl" -d "Start a REPL session with Bun" -f
 complete -c bun -n "__fish_seen_subcommand_from repl" -s "e" -l "eval" -r -d "Evaluate argument as a script, then exit" -f
 complete -c bun -n "__fish_seen_subcommand_from repl" -s "p" -l "print" -r -d "Evaluate argument as a script, print the result, then exit" -f
 complete -c bun -n "__fish_seen_subcommand_from repl" -s "r" -l "preload" -r -d "Import a module before other modules are loaded"
 complete -c bun -n "__fish_seen_subcommand_from repl" -l "smol" -d "Use less memory, but run garbage collection more often" -f
 complete -c bun -n "__fish_seen_subcommand_from repl" -s "c" -l "config" -r -d "Specify path to Bun config file"
 complete -c bun -n "__fish_seen_subcommand_from repl" -l "cwd" -r -d "Absolute path to resolve files & entry points from"
 complete -c bun -n "__fish_seen_subcommand_from repl" -l "env-file" -r -d "Load environment variables from the specified file(s)"
 complete -c bun -n "__fish_seen_subcommand_from repl" -l "no-env-file" -d "Disable automatic loading of .env files" -f
--- a/.config/fish/completions/dot.fish
+++ b/.config/fish/completions/dot.fish
@@ -1,34 +0,0 @@
 function __dot_custom_subcommands
    echo init
    echo help
    path basename $HOME/.config/dot/commands/*.fish 2>/dev/null | path change-extension ''
    for d in $HOME/.config/dot/commands/*/
        test -d $d; or continue
        set -l name (path basename $d)
        test -f $d$name.fish; or continue
        echo $name
    end
 end
 complete -c dot -n __fish_use_subcommand -a "(__dot_custom_subcommands)"
 # --- dot install ---
 complete -c dot -n "__fish_seen_subcommand_from install; and not __fish_seen_argument -l restore" -l restore -d "reinstall every package from the saved list"
 complete -c dot -n "__fish_seen_subcommand_from install; and not __fish_seen_argument -l no-sync" -l no-sync -d "skip the pacman -Sy database refresh"
 complete -c dot -n "__fish_seen_subcommand_from install; and not __fish_seen_argument -l restore" -f -a "(__fish_print_pacman_packages)"
 # --- dot setup ---
 complete -c dot -n "__fish_seen_subcommand_from setup; and not __fish_seen_subcommand_from folders help" -f -a folders -d "bring the 8 standard XDG user directories under the short-name convention"
 complete -c dot -n "__fish_seen_subcommand_from setup; and not __fish_seen_subcommand_from folders help" -f -a help -d "show usage"
 complete -c dot -n "__fish_seen_subcommand_from setup; and __fish_seen_subcommand_from folders" -f -a help -d "show usage"
 # --- dot kde ---
 complete -c dot -n "__fish_seen_subcommand_from kde; and not __fish_seen_subcommand_from apply diff save help" -f -a apply -d "push manifest entries onto the live system"
 complete -c dot -n "__fish_seen_subcommand_from kde; and not __fish_seen_subcommand_from apply diff save help" -f -a diff -d "scan for settings whose live value differs from its default"
 complete -c dot -n "__fish_seen_subcommand_from kde; and not __fish_seen_subcommand_from apply diff save help" -f -a save -d "write live KDE settings into the manifest"
 complete -c dot -n "__fish_seen_subcommand_from kde; and not __fish_seen_subcommand_from apply diff save help" -f -a help -d "show usage"
 complete -c dot -n "__fish_seen_subcommand_from kde; and __fish_seen_subcommand_from apply diff save" -f -a help -d "show usage"
 # Sourced live from the schema mapping table (real .kcfg files), not a
 # hardcoded list -- same helper kde.py's own save/refresh logic builds from.
 complete -c dot -n "__fish_seen_subcommand_from kde; and __fish_seen_subcommand_from save" -f -a "(python3 $HOME/.config/dot/commands/kde/kde.py complete 2>/dev/null)"
--- a/.config/fish/completions/fishtape.fish
+++ b/.config/fish/completions/fishtape.fish
@@ -1,2 +0,0 @@
 complete --command fishtape --short v --long version --description "Print version"
 complete --command fishtape --short h --long help --description "Print help"
--- a/.config/fish/conf.d/aliases.fish
+++ b/.config/fish/conf.d/aliases.fish
@@ -1,4 +0,0 @@
 alias cp='cp -v'
 alias vi=nvim
 alias vim=nvim
 alias tmx='tmux new-session -A -s'
--- a/.config/fish/conf.d/env.fish
+++ b/.config/fish/conf.d/env.fish
@@ -1,4 +0,0 @@
 set -gx EDITOR nvim
 set -x ANDROID_HOME $HOME/Android/Sdk
 fish_add_path $ANDROID_HOME/platform-tools
 fish_add_path $ANDROID_HOME/tools/bin
--- a/.config/fish/conf.d/rustup.fish
+++ b/.config/fish/conf.d/rustup.fish
@@ -1 +0,0 @@
 test -f "$HOME/.cargo/env.fish"; and source "$HOME/.cargo/env.fish"
--- a/.config/fish/config.fish
+++ b/.config/fish/config.fish
@@ -1,15 +0,0 @@
 source /usr/share/cachyos-fish-config/cachyos-config.fish
 set -gx EDITOR nvim
 set -gx VISUAL nvim
 # overwrite greeting
 # potentially disabling fastfetch
 #function fish_greeting
 #    # smth smth
 #end
 # bun
 set --export BUN_INSTALL "$HOME/.bun"
 set --export PATH $BUN_INSTALL/bin $PATH
--- a/.config/fish/fish_plugins
+++ b/.config/fish/fish_plugins
@@ -1 +0,0 @@
 jorgebucaran/fishtape
--- a/.config/fish/fish_variables
+++ b/.config/fish/fish_variables
@@ -1,82 +0,0 @@
 # This file contains fish universal variable definitions.
 # VERSION: 3.0
 SETUVAR __done_min_cmd_duration:10000
 SETUVAR __done_notification_urgency_level:low
 SETUVAR __fish_initialized:4300
 SETUVAR _fisher_jorgebucaran_2F_fishtape_files:\x7e/\x2econfig/fish/functions/fishtape\x2efish\x1e\x7e/\x2econfig/fish/completions/fishtape\x2efish
 SETUVAR _fisher_plugins:jorgebucaran/fishtape
 SETUVAR _fisher_upgraded_to_4_4:\x1d
 SETUVAR fish_user_paths:/home/alexion/\x2elocal/bin\x1e/home/alexion/Android/Sdk/platform\x2dtools
 SETUVAR pure_begin_prompt_with_current_directory:true
 SETUVAR pure_check_for_new_release:false
 SETUVAR pure_color_at_sign:pure_color_mute
 SETUVAR pure_color_aws_profile:pure_color_warning
 SETUVAR pure_color_command_duration:pure_color_warning
 SETUVAR pure_color_current_directory:pure_color_primary
 SETUVAR pure_color_danger:red
 SETUVAR pure_color_dark:black
 SETUVAR pure_color_exit_status:pure_color_danger
 SETUVAR pure_color_git_branch:pure_color_mute
 SETUVAR pure_color_git_dirty:pure_color_mute
 SETUVAR pure_color_git_stash:pure_color_info
 SETUVAR pure_color_git_unpulled_commits:pure_color_info
 SETUVAR pure_color_git_unpushed_commits:pure_color_info
 SETUVAR pure_color_hostname:pure_color_mute
 SETUVAR pure_color_info:cyan
 SETUVAR pure_color_jobs:pure_color_normal
 SETUVAR pure_color_k8s_context:pure_color_success
 SETUVAR pure_color_k8s_namespace:pure_color_primary
 SETUVAR pure_color_k8s_prefix:pure_color_info
 SETUVAR pure_color_light:white
 SETUVAR pure_color_mute:brblack
 SETUVAR pure_color_nixdevshell_prefix:pure_color_info
 SETUVAR pure_color_nixdevshell_symbol:pure_color_mute
 SETUVAR pure_color_normal:normal
 SETUVAR pure_color_prefix_root_prompt:pure_color_danger
 SETUVAR pure_color_primary:blue
 SETUVAR pure_color_prompt_on_error:pure_color_danger
 SETUVAR pure_color_prompt_on_success:pure_color_success
 SETUVAR pure_color_success:magenta
 SETUVAR pure_color_system_time:pure_color_mute
 SETUVAR pure_color_username_normal:pure_color_mute
 SETUVAR pure_color_username_root:pure_color_light
 SETUVAR pure_color_virtualenv:pure_color_mute
 SETUVAR pure_color_warning:yellow
 SETUVAR pure_convert_exit_status_to_signal:false
 SETUVAR pure_enable_aws_profile:true
 SETUVAR pure_enable_container_detection:true
 SETUVAR pure_enable_git:true
 SETUVAR pure_enable_k8s:false
 SETUVAR pure_enable_nixdevshell:false
 SETUVAR pure_enable_single_line_prompt:false
 SETUVAR pure_enable_virtualenv:true
 SETUVAR pure_reverse_prompt_symbol_in_vimode:true
 SETUVAR pure_separate_prompt_on_error:false
 SETUVAR pure_shorten_prompt_current_directory_length:0
 SETUVAR pure_shorten_window_title_current_directory_length:0
 SETUVAR pure_show_exit_status:false
 SETUVAR pure_show_jobs:false
 SETUVAR pure_show_numbered_git_indicator:false
 SETUVAR pure_show_prefix_root_prompt:false
 SETUVAR pure_show_subsecond_command_duration:false
 SETUVAR pure_show_system_time:false
 SETUVAR pure_symbol_aws_profile_prefix:
 SETUVAR pure_symbol_container_prefix:
 SETUVAR pure_symbol_exit_status_prefix:\x7c
 SETUVAR pure_symbol_exit_status_separator:\x7c
 SETUVAR pure_symbol_git_dirty:\x2a
 SETUVAR pure_symbol_git_stash:\u2261
 SETUVAR pure_symbol_git_unpulled_commits:\u21e3
 SETUVAR pure_symbol_git_unpushed_commits:\u21e1
 SETUVAR pure_symbol_k8s_prefix:\u2638
 SETUVAR pure_symbol_nixdevshell_prefix:\u2744\ufe0f
 SETUVAR pure_symbol_prefix_root_prompt:\x23
 SETUVAR pure_symbol_prompt:\u276f
 SETUVAR pure_symbol_reverse_prompt:\u276e
 SETUVAR pure_symbol_ssh_prefix:
 SETUVAR pure_symbol_title_bar_separator:\x2d
 SETUVAR pure_symbol_virtualenv_prefix:
 SETUVAR pure_system_time_format:\x2b\x25T
 SETUVAR pure_threshold_command_duration:5
 SETUVAR pure_truncate_prompt_current_directory_keeps:\x2d1
 SETUVAR pure_truncate_window_title_current_directory_keeps:\x2d1
--- a/.config/fish/functions/dot.fish
+++ b/.config/fish/functions/dot.fish
@@ -1,130 +0,0 @@
 function dot --wraps=git --description 'Manage dotfiles via a bare repo checked out over $HOME'
    set -l dotfiles_dir $HOME/.dotfiles
    if test "$argv[1]" = init
        set -e argv[1]
        __dot_init $dotfiles_dir $argv
        return $status
    end
    if test "$argv[1]" = help
        __dot_help
        return $status
    end
    set -l commands_dir $HOME/.config/dot/commands
    set -l command_file $commands_dir/$argv[1].fish
    set -l nested_command_file $commands_dir/$argv[1]/$argv[1].fish
    if test -n "$argv[1]"
        if test -f "$command_file"
            source $command_file
            _dot_$argv[1] $argv[2..-1]
            return $status
        else if test -f "$nested_command_file"
            source $nested_command_file
            _dot_$argv[1] $argv[2..-1]
            return $status
        end
    end
    git --git-dir=$dotfiles_dir --work-tree=$HOME $argv
 end
 # Kept inline (not a separate autoloaded function file) because this is the
 # only subcommand that must work before the dotfiles repo has been cloned.
 function __dot_init
    set -l dotfiles_dir $argv[1]
    set -e argv[1]
    argparse 'url=' -- $argv
    or return 1
    set -l url $_flag_url
    test -n "$url"; or set url ssh://gitea@git.alexion.dev:2022/alexion/dotfiles.git
    if test -e $dotfiles_dir
        echo "dot init: $dotfiles_dir already exists, refusing to re-initialize" >&2
        return 1
    end
    git clone --bare $url $dotfiles_dir
    or begin
        echo "dot init: failed to clone $url" >&2
        return 1
    end
    git --git-dir=$dotfiles_dir config status.showUntrackedFiles no
    set -l checkout_output (git --git-dir=$dotfiles_dir --work-tree=$HOME checkout 2>&1)
    set -l checkout_status $status
    if test $checkout_status -ne 0
        set -l conflicts
        set -l in_block 0
        for line in $checkout_output
            if test $in_block -eq 1
                if string match -rq '^\s' -- $line
                    set -a conflicts (string trim -- $line)
                    continue
                else
                    set in_block 0
                end
            end
            string match -q '*would be overwritten by checkout:*' -- $line
            and set in_block 1
        end
        if test (count $conflicts) -eq 0
            echo "dot init: checkout failed and no recoverable conflicts were found:" >&2
            printf '%s\n' $checkout_output >&2
            return 1
        end
        set -l backup_dir $HOME/.dotfiles-backup/(date +%Y%m%dT%H%M%S)
        for f in $conflicts
            mkdir -p (path dirname $backup_dir/$f)
            mv $HOME/$f $backup_dir/$f
            echo "dot init: backed up ~/$f to $backup_dir/$f"
        end
        git --git-dir=$dotfiles_dir --work-tree=$HOME checkout
        or begin
            echo "dot init: checkout still failing after backing up conflicts, aborting" >&2
            return 1
        end
    end
    echo "dot init: bootstrapped $dotfiles_dir from $url"
 end
 # The custom-subcommand glob is duplicated (not shared with
 # completions/dot.fish) because fish only autoloads a function from a file
 # named after that function; a shared helper would go undefined if `dot help`
 # ran in a completion context before `dot` itself had ever been sourced.
 function __dot_help
    echo "dot: manage dotfiles via a bare repo checked out over \$HOME
 Commands:
  init    bootstrap the dotfiles repo on a new machine
  help    show this message"
    for f in $HOME/.config/dot/commands/*.fish
        test -e $f; or continue
        echo "  "(path basename $f | path change-extension '')
    end
    for d in $HOME/.config/dot/commands/*/
        test -d $d; or continue
        set -l name (path basename $d)
        test -f $d$name.fish; or continue
        echo "  $name"
    end
    echo "
 Run 'dot <command> help' for flags on a specific command.
 Any other command is passed through to git (dot status, dot add, dot commit, dot push, ...)."
 end
--- a/.config/fish/functions/fishtape.fish
+++ b/.config/fish/functions/fishtape.fish
@@ -1,116 +0,0 @@
 function fishtape --description "Test scripts, functions, and plugins in Fish"
    switch "$argv"
        case -v --version
            echo "fishtape, version 3.0.1"
        case "" -h --help
            echo "Usage: fishtape <files ...>  Run test files"
            echo "Options:"
            echo "       -v or --version  Print version"
            echo "       -h or --help     Print this help message"
        case \*
            set --local files (realpath $argv)
            for file in $files
                if test ! -f $file
                    echo "fishtape: Invalid file or file not found: \"$file\"" >&2
                    return 1
                end
            end
            set --local operators -{n,z,b,c,d,e,f,g,G,k,L,O,p,r,s,S,t,u,w,x}
            set --local expectations \
                "a non-zero length string" \
                "a zero length string" \
                "a block device" \
                "a character device" \
                "a directory" \
                "an existing file" \
                "a regular file" \
                "a file with the set-group-ID bit set" \
                "a file with same group ID as the current user" \
                "a file with the sticky bit set" \
                "a symbolic link" \
                "a file owned by the current user" \
                "a named pipe" \
                "a file marked as readable" \
                "a file of size greater than zero" \
                "a socket" \
                "a terminal tty file descriptor" \
                "a file with the set-user-ID bit set" \
                "a file marked as writable" \
                "a file marked as executable"
            set --universal _fishtape_test_number 0
            set --universal _fishtape_test_passed 0
            set --universal _fishtape_test_failed 0
            function @echo
                echo "# $argv"
            end
            function @test --argument-names name --inherit-variable operators --inherit-variable expectations
                set --erase argv[1]
                set --query argv[2] || set --append argv ""
                set _fishtape_test_number (math $_fishtape_test_number + 1)
                if test $argv
                    set _fishtape_test_passed (math $_fishtape_test_passed + 1)
                    echo "ok $_fishtape_test_number $name"
                else
                    if test $argv[1] = "!"
                        set operator "! "
                        set expected "not "
                        set --erase argv[1]
                    end
                    if set --query argv[3]
                        set operator "$operator"$argv[2]
                        set expected (string escape -- $argv[3])
                        set actual (string escape -- $argv[1])
                    else
                        set operator "$operator"$argv[1]
                        set expected "$expected"$expectations[(contains --index -- $argv[1] $operators)]
                        set actual (string escape -- $argv[2])
                    end
                    set _fishtape_test_failed (math $_fishtape_test_failed + 1)
                    status print-stack-trace |
                        string replace --filter --regex -- "\s+called on line (\d+) of file (.+)" '$2:$1' |
                        read --local at
                    echo "not ok $_fishtape_test_number $name"
                    echo "  ---"
                    echo "    operator: $operator"
                    echo "    expected: $expected"
                    echo "    actual: $actual"
                    echo "    at: $at"
                    echo "  ..."
                end
            end
            echo TAP version 13
            for file in $files
                fish --init-command=(functions @echo | string collect) --init-command=(functions @test | string collect) $file
            end
            echo
            echo "1..$_fishtape_test_number"
            echo "# pass $_fishtape_test_passed"
            test $_fishtape_test_failed -eq 0 &&
                echo "# ok" ||
                echo "# fail $_fishtape_test_failed"
            functions --erase @echo @test
            set --local failed $_fishtape_test_failed
            set --erase _fishtape_test_number
            set --erase _fishtape_test_passed
            set --erase _fishtape_test_failed
            test $failed -eq 0
    end
 end
--- a/.config/nvim/after/ftplugin/markdown.lua
+++ b/.config/nvim/after/ftplugin/markdown.lua
@@ -1 +0,0 @@
 vim.opt_local.conceallevel = 2
--- a/.config/nvim/init.lua
+++ b/.config/nvim/init.lua
@@ -1,3 +0,0 @@
 require("vim_options")
 require("keys")
 require("plugin")
--- a/.config/nvim/lazy-lock.json
+++ b/.config/nvim/lazy-lock.json
@@ -1,13 +0,0 @@
 {
  "diffview.nvim": { "branch": "main", "commit": "4516612fe98ff56ae0415a259ff6361a89419b0a" },
  "gitsigns.nvim": { "branch": "main", "commit": "eb60cc7b94c46005237fd34170d76f3a089a90aa" },
  "lazy.nvim": { "branch": "main", "commit": "306a05526ada86a7b30af95c5cc81ffba93fef97" },
  "neogit": { "branch": "master", "commit": "6fc2fa890bd2031ed999c074daab0fb4feff20a5" },
  "nord.nvim": { "branch": "main", "commit": "87394d4fc35c901bbe38326a78d31ab1ead826b6" },
  "nvim-treesitter": { "branch": "master", "commit": "cf12346a3414fa1b06af75c79faebe7f76df080a" },
  "oil.nvim": { "branch": "master", "commit": "b73018b75affd13fa38e2fc94ef753b465f770d7" },
  "plenary.nvim": { "branch": "master", "commit": "74b06c6c75e4eeb3108ec01852001636d85a932b" },
  "render-markdown.nvim": { "branch": "main", "commit": "f422cb5c6855f150e2ddcfaf44e7157b98b34f6a" },
  "snacks.nvim": { "branch": "main", "commit": "882c996cf28183f4d63640de0b4c02ec886d01f2" },
  "which-key.nvim": { "branch": "main", "commit": "3aab2147e74890957785941f0c1ad87d0a44c15a" }
 }
--- a/.config/nvim/lua/keys.lua
+++ b/.config/nvim/lua/keys.lua
@@ -1,8 +0,0 @@
 local map = vim.keymap.set
 map("n", "<C-h>", "<C-w>h", { desc = "Move focus left" })
 map("n", "<C-j>", "<C-w>j", { desc = "Move focus down" })
 map("n", "<C-k>", "<C-w>k", { desc = "Move focus up" })
 map("n", "<C-l>", "<C-w>l", { desc = "Move focus right" })
 map("n", "<Esc>", "<cmd>nohlsearch<CR>", { desc = "Clear search highlight" })
--- a/.config/nvim/lua/plugin.lua
+++ b/.config/nvim/lua/plugin.lua
@@ -1,23 +0,0 @@
 local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
 if not vim.uv.fs_stat(lazypath) then
  local lazyrepo = "https://github.com/folke/lazy.nvim.git"
  local out = vim.fn.system({ "git", "clone", "--filter=blob:none", "--branch=stable", lazyrepo, lazypath })
  if vim.v.shell_error ~= 0 then
    vim.api.nvim_echo({
      { "Failed to clone lazy.nvim:\n", "ErrorMsg" },
      { out, "WarningMsg" },
      { "\nPress any key to exit..." },
    }, true, {})
    vim.fn.getchar()
    os.exit(1)
  end
 end
 vim.opt.rtp:prepend(lazypath)
 require("lazy").setup({
  spec = {
    { import = "plugins" },
  },
  install = { colorscheme = { "nord" } },
  checker = { enabled = false },
 })
--- a/.config/nvim/lua/plugins/git.lua
+++ b/.config/nvim/lua/plugins/git.lua
@@ -1,36 +0,0 @@
 return {
  {
    "NeogitOrg/neogit",
    dependencies = {
      "nvim-lua/plenary.nvim",
      "sindrets/diffview.nvim",
    },
    keys = {
      {
        "<leader>g",
        function()
          require("gitsigns").toggle_current_line_blame(true)
          require("neogit").open()
        end,
        desc = "Open git (Neogit)",
      },
    },
    config = function()
      require("neogit").setup()
      vim.api.nvim_create_autocmd("BufUnload", {
        callback = function(args)
          if vim.bo[args.buf].filetype == "NeogitStatus" then
            require("gitsigns").toggle_current_line_blame(false)
          end
        end,
      })
    end,
  },
  {
    "lewis6991/gitsigns.nvim",
    event = "BufWinEnter",
    opts = {
      current_line_blame = false,
    },
  },
 }
--- a/.config/nvim/lua/plugins/navigation.lua
+++ b/.config/nvim/lua/plugins/navigation.lua
@@ -1,27 +0,0 @@
 return {
  {
    "stevearc/oil.nvim",
    lazy = false,
    opts = {
      view_options = { show_hidden = true },
    },
    keys = {
      { "<leader>e", "<cmd>Oil<CR>", desc = "Open file browser" },
    },
  },
  {
    "folke/snacks.nvim",
    priority = 1000,
    lazy = false,
    opts = {
      picker = { enabled = true },
      notifier = { enabled = true },
      input = { enabled = true },
    },
    keys = {
      { "<leader>f", function() require("snacks").picker.files() end, desc = "Find files" },
      { "<leader>s", function() require("snacks").picker.grep() end, desc = "Search text" },
      { "<leader>b", function() require("snacks").picker.buffers() end, desc = "Switch buffer" },
    },
  },
 }
--- a/.config/nvim/lua/plugins/ui.lua
+++ b/.config/nvim/lua/plugins/ui.lua
@@ -1,55 +0,0 @@
 return {
  {
    "gbprod/nord.nvim",
    lazy = false,
    priority = 1000,
    opts = {
      transparent = true,
    },
    config = function(_, opts)
      require("nord").setup(opts)
      vim.cmd.colorscheme("nord")
    end,
  },
  {
    "MeanderingProgrammer/render-markdown.nvim",
    ft = { "markdown" },
    dependencies = { "nvim-treesitter/nvim-treesitter" },
    opts = {},
  },
  {
    "folke/which-key.nvim",
    lazy = false,
    config = true,
  },
  {
    "nvim-treesitter/nvim-treesitter",
    branch = "master",
    build = ":TSUpdate",
    opts = {
      ensure_installed = {
        "markdown",
        "markdown_inline",
        "lua",
        "bash",
        "fish",
        "rust",
        "javascript",
        "typescript",
        "java",
        "kotlin",
        "c",
        "cpp",
        "html",
        "css",
        "python",
      },
      auto_install = false,
      highlight = { enable = true },
      indent = { enable = true },
    },
    config = function(_, opts)
      require("nvim-treesitter.configs").setup(opts)
    end,
  },
 }
--- a/.config/nvim/lua/vim_options.lua
+++ b/.config/nvim/lua/vim_options.lua
@@ -1,29 +0,0 @@
 vim.g.mapleader = " "
 local opt = vim.opt
 -- Clipboard: use neovim's built-in OSC 52 provider, no external binary needed.
 vim.g.clipboard = "osc52"
 opt.clipboard = "unnamedplus"
 opt.number = true
 opt.relativenumber = true
 opt.shiftwidth = 2
 opt.tabstop = 2
 opt.expandtab = true
 opt.mouse = "a"
 opt.undofile = true
 opt.ignorecase = true
 opt.smartcase = true
 opt.splitright = true
 opt.splitbelow = true
 opt.wrap = false
 opt.scrolloff = 8
 opt.cursorline = true
--- a/.config/tmux/tmux.conf
+++ b/.config/tmux/tmux.conf
@@ -1,74 +0,0 @@
 # Prefix: Ctrl-Space. Chosen over Ctrl-b (awkward reach) and Ctrl-a (collides
 # with readline's beginning-of-line, which fights editing text in shells and
 # in Claude Code's prompt). Verified clear of IME/KDE/Claude Code bindings.
 unbind C-b
 set -g prefix C-Space
 bind C-Space send-prefix
 set -g mouse on
 # OSC52 lets copy-mode selections land in the system clipboard via the
 # terminal itself (Alacritty supports it) -- no wl-copy/xclip needed, and it
 # still works over SSH later since the escape sequence travels with the data.
 set -g set-clipboard on
 set -g mode-keys vi
 set -g status-keys vi
 bind -T copy-mode-vi v send -X begin-selection
 bind -T copy-mode-vi y send -X copy-selection-and-cancel
 bind -T copy-mode-vi MouseDragEnd1Pane send -X copy-selection-and-cancel
 # tmux's -h/-v split flags name the *arrangement*, not the divider line, which
 # is backwards from how the divider looks -- so pick keys by what they draw:
 # \ draws a side-by-side split (vertical line), - draws a stacked split
 # (horizontal line). Unshifted versions of |/-  since splitting is frequent.
 unbind %
 unbind '"'
 bind \\ split-window -h -c "#{pane_current_path}"
 bind - split-window -v -c "#{pane_current_path}"
 bind c new-window -c "#{pane_current_path}"
 bind h select-pane -L
 bind j select-pane -D
 bind k select-pane -U
 bind l select-pane -R
 set -g base-index 1
 setw -g pane-base-index 1
 set -g renumber-windows on
 bind r source-file ~/.config/tmux/tmux.conf \; display-message "tmux.conf reloaded"
 # True color passthrough. ",*" (rather than naming Alacritty's xterm-256color
 # specifically) so this keeps working if the terminal emulator changes later.
 set -g default-terminal "tmux-256color"
 set -ag terminal-overrides ",*:RGB"
 # Default 500ms delay on Esc exists to disambiguate meta-key sequences; it
 # reads as noticeable lag exiting insert mode in neovim, so drop it.
 set -sg escape-time 10
 set -g history-limit 10000
 # Flag a background window in the status bar when its Claude Code session
 # rings the terminal bell (permission prompt / task done while unfocused).
 # bell-action=none stops tmux from ever passing the actual BEL through to
 # Alacritty (no beep, no flash) -- monitor-bell's per-window tracking for the
 # status-line highlight is independent of that and keeps working.
 setw -g monitor-bell on
 set -g bell-action none
 # Minimal status bar (session + window list only), styled to match the Nord
 # theme already used in alacritty.toml.
 set -g status-position bottom
 set -g status-style "bg=#2E3440,fg=#D8DEE9"
 set -g status-left " #S "
 set -g status-left-length 20
 set -g status-right ""
 setw -g window-status-current-style "bg=#88C0D0,fg=#2E3440,bold"
 setw -g window-status-current-format " #I:#W "
 setw -g window-status-format " #I:#W "
 setw -g window-status-style "fg=#4C566A"
 setw -g window-status-bell-style "bg=#BF616A,fg=#2E3440,bold"
 set -g pane-border-style "fg=#3B4252"
 set -g pane-active-border-style "fg=#88C0D0"
--- a/.config/user-dirs.dirs
+++ b/.config/user-dirs.dirs
@@ -1,16 +0,0 @@
 # This file is written by xdg-user-dirs-update
 # If you want to change or add directories, just edit the line you're
 # interested in. All local changes will be retained on the next run.
 # Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
 # homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
 # absolute path. No other format is supported.
 # 
 XDG_DESKTOP_DIR="$HOME/.desktop"
 XDG_DOWNLOAD_DIR="$HOME/dwn"
 XDG_TEMPLATES_DIR="$HOME/.ignoreme"
 XDG_PUBLICSHARE_DIR="$HOME/.ignoreme"
 XDG_DOCUMENTS_DIR="$HOME/doc"
 XDG_MUSIC_DIR="$HOME/mus"
 XDG_PICTURES_DIR="$HOME/pic"
 XDG_VIDEOS_DIR="$HOME/vid"
 XDG_PROJECTS_DIR="$HOME/wrk"
--- a/.gitconfig
+++ b/.gitconfig
@@ -1,3 +0,0 @@
 [user]
 	name = alexion
 	email = contact@alexion.dev
--- a/.github/README.md
+++ b/.github/README.md
@@ -1,40 +0,0 @@
 # dotfiles
 Dotfiles managed as a bare git repo checked out over `$HOME`, for machines
 running CachyOS with KDE Plasma. 
 ## Bootstrapping a new machine
 ```sh
 mkdir -p ~/.config/fish/functions
 curl -fsSL https://git.alexion.dev/alexion/dotfiles/raw/branch/main/.config/fish/functions/dot.fish \
    -o ~/.config/fish/functions/dot.fish
 fish -c 'dot init'
 ```
 ## Commands
 | Command                 | Description                                                                              |
 | ----------------------- | ----------------------------------------------------------------------------------------- |
 | `dot help`              | Lists available commands.                                                                |
 | `dot init`              | Bootstraps the dotfiles repo on a new machine.                                           |
 | `dot install <pkgs>`    | Installs the given pacman packages and appends them to the tracked list (`~/.config/dot/packages/pacman`). |
 | `dot install --restore` | Reinstalls every package from the tracked list.                                          |
 | `dot kde apply`         | Pushes every manifest entry's declared value onto the live system.                       |
 | `dot kde diff`          | Reports every schema-backed setting whose live value differs from its default, tagged declared or undeclared. |
 | `dot kde help`          | Lists `dot kde`'s subcommands.                                                           |
 | `dot kde save <identifier>` | Reads a KDE setting's current live value and declares it in the manifest (`~/.config/dot/kde-manifest`). |
 | `dot kde save`          | Refreshes every already-declared manifest entry's value from the live system.            |
 | `dot setup`             | Runs every machine-setup task (currently just `folders`).                                |
 | `dot setup folders`     | Brings the 8 standard XDG user directories (`~/Desktop`, `~/Documents`, ...) under a fixed short-name convention (`~/.desktop`, `~/doc`, ...). |
 | `dot vpn up`            | Brings the `UDM-PRO-Laptop` WireGuard connection up via NetworkManager.                  |
 | `dot vpn down`          | Brings the `UDM-PRO-Laptop` WireGuard connection down.                                   |
 | `dot <git>`             | Everything else is passed to `git`.                                                      |
 See [CLAUDE.md](../.config/dot/CLAUDE.md) for the `dot` tool's internal
 architecture, bootstrap logic, subcommand dispatch, and test suite.
 ## Keybindings
 See [keybindings.md](keybindings.md) for custom and useful default
 keybindings across configured tools (currently: tmux).
--- a/.github/keybindings.md
+++ b/.github/keybindings.md
@@ -1,42 +0,0 @@
 # Keybindings
 Quick reference for custom and useful default keybindings, so they don't have
 to be re-discovered or looked up per tool.
 Comma-separated keys are pressed in sequence, not together.
 | Key                                                   | Context | Action                                             |
 | ----------------------------------------------------- | ------- | -------------------------------------------------- |
 | `Ctrl` + `Space`, `\`                                 | tmux    | Split side-by-side, opens in current directory     |
 | `Ctrl` + `Space`, `-`                                 | tmux    | Split stacked, opens in current directory          |
 | `Ctrl` + `Space`, `h` / `j` / `k` / `l`               | tmux    | Move focus left / down / up / right                |
 | `Ctrl` + `Space`, `z`                                 | tmux    | Zoom/unzoom pane to fullscreen                     |
 | `Ctrl` + `Space`, `o`                                 | tmux    | Cycle focus to next pane                           |
 | `Ctrl` + `Space`, `x`                                 | tmux    | Kill current pane (asks to confirm)                |
 | `Ctrl` + `Space`, `Ctrl` + `Up`/`Down`/`Left`/`Right` | tmux    | Resize pane                                        |
 | `Ctrl` + `Space`, `c`                                 | tmux    | New window, opens in current directory             |
 | `Ctrl` + `Space`, `0`-`9`                             | tmux    | Jump to window by number                           |
 | `Ctrl` + `Space`, `n` / `p`                           | tmux    | Next / previous window                             |
 | `Ctrl` + `Space`, `w`                                 | tmux    | Interactive window list                            |
 | `Ctrl` + `Space`, `,`                                 | tmux    | Rename current window                              |
 | `Ctrl` + `Space`, `&`                                 | tmux    | Kill current window (asks to confirm)              |
 | `Ctrl` + `Space`, `[`                                 | tmux    | Enter copy mode                                    |
 | `Ctrl` + `Space`, `]`                                 | tmux    | Paste most recent copy                             |
 | `h` / `j` / `k` / `l`                                 | tmux    | Move cursor                                        |
 | `v`                                                   | tmux    | Begin selection                                    |
 | `y`                                                   | tmux    | Copy selection to system clipboard, exit copy mode |
 | `/` / `?`                                             | tmux    | Search forward / backward                          |
 | `q`                                                   | tmux    | Exit copy mode                                     |
 | `Ctrl` + `Space`, `d`                                 | tmux    | Detach from session                                |
 | `Ctrl` + `Space`, `$`                                 | tmux    | Rename session                                     |
 | `Ctrl` + `Space`, `s`                                 | tmux    | Interactive session list                           |
 | `Ctrl` + `Space`, `(` / `)`                           | tmux    | Switch to previous / next session                  |
 | `Ctrl` + `Space`, `r`                                 | tmux    | Reload `tmux.conf`                                 |
 | `Ctrl` + `h` / `j` / `k` / `l`                        | neovim  | Move focus between splits left / down / up / right |
 | `Esc`                                                  | neovim  | Clear search highlight                             |
 | `Space`, `e`                                           | neovim  | Toggle file explorer (netrw)                       |
 | `CapsLock`                                             | KDE     | Acts as `Esc` (`kxkbrc` `Options=caps:escape_shifted_capslock`) |
 | `Shift` + `CapsLock`                                   | KDE     | Toggles Caps Lock                                  |
 | `Meta` + `X`                                           | KDE     | Lock Session (moved off `Meta+L`, tracked via `dot kde`) |
 | `Meta` + `Shift` + `q` | KDE | Kill window |
--- a/.gitignore
+++ b/.gitignore
@@ -1,8 +1 @@
-.dotfiles
+/reference/
 .DS_Store
 *.swp
 *.swo
 *~
 Thumbs.db
 **/__pycache__
 .config/fish/conf.d/secrets.fish
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -0,0 +1,45 @@
 # dotfiles-nixos
 One flake that builds every machine the user owns.
 The domain model (Host, Module, Skeleton, Auto-loader, Enable convention, overlays) lives in `.claude/CONTEXT.md`; the current deliverable's spec is `.claude/spec/laptop-mvi.md`.
 ## Conventions
 - Write comments only where they earn their place, and keep them concise.
  Assume the reader can read code: comment the "why", not the "what", and explain "what" only when it is genuinely non-obvious.
  A comment must be self-contained to its file — accurate to a reader looking at that file alone.
  Do not write about history ("used to be X", "now moved here") or future state, about how a value is consumed elsewhere, or to justify the choice against alternatives; state the positive reason a thing exists, keeping any real stakes as a present-tense consequence.
  The only permitted cross-file mention is a bare pointer explaining why something is *absent* here (e.g. "disko derives `fileSystems`; none declared here"), never narrating what the other file or tool does.
  Do not use the domain model's capitalized terms (Host, Module, Skeleton, Auto-loader, Enable convention) as glossary references; describe things in plain language, using "host"/"module" only as ordinary lowercase nouns.
  Never reference agent-facing state (anything under `.claude/` or `CLAUDE.md`).
  A file-top header is one concise purpose line, added only where the filename or path does not already say it — never a feature inventory of the code below.
  For a placeholder, say so plainly plus any actionable present-tense directive ("Placeholder: regenerate with nixos-generate-config on the target machine"), never "placeholder for <missing feature>".
  Option `description`/`mkEnableOption` strings are user-facing documentation rather than comments, so they may describe behaviour more fully — but the self-contained rule and the bans on glossary terms and agent-state references still apply.
 - Comments posted to Gitea (pull requests, issues, reviews) go out under the operator's account, so sign every one to make clear the author is the agent, not the operator.
  End the comment with a `— Claude` sign-off.
  (A dedicated bot account may replace this later; until then, the sign-off is the only marker.)
 - Commit messages follow Conventional Commits, specified in `docs/conventional-commits.md`.
  Scope is the module or host the change belongs to (`fish`, `nvim`, `neogaia`), omitted for repo-wide changes.
  Keep messages free of Gitea-specific references: this repository is mirrored to GitHub, where issue and pull-request numbers resolve to unrelated things.
 ## Gotchas
 - Nix on the dev host needs experimental features passed per-command.
  This repo is developed on `neogaia` while it still runs **CachyOS** (the migration target), where Nix is the distro package at `/usr/bin/nix` in multi-user daemon mode.
  The system `/etc/nix/nix.conf` does not enable flakes, so export `NIX_CONFIG="experimental-features = nix-command flakes"` (or pass `--extra-experimental-features 'nix-command flakes'`) for every command.
 - The dev user is a non-trusted daemon client (`nix store info` reports `Trusted: 0`).
  You cannot add substituters from the CLI, so rely on what the flake/config declares (e.g. the chaotic cache is wired by the chaotic module, not a CLI flag).
  Caveat that bites when a Host actually selects the CachyOS kernel: the substituters a `nix build` fetches from are the **daemon's** (`/etc/nix/nix.conf`), *not* the `nix.settings` of the config being built — those only govern the built system.
  This dev host's `/etc/nix/nix.conf` has no `substituters`/`trusted-substituters` lines, so building a toplevel whose `boot.kernelPackages` is `linuxPackages_cachyos` compiles the kernel (and rustc bootstrap, etc.) from source instead of hitting `nyx-cache`.
  To build such a Host here, first add `extra-substituters = https://nyx-cache.chaotic.cx/` and `extra-trusted-public-keys = nyx-cache.chaotic.cx:dJxTrgMC3V3cFfyIiBQDQorG6k1LsqurH/srpMSq7qk=` to `/etc/nix/nix.conf` (sudo) and `sudo systemctl restart nix-daemon`.
  `nix eval` of the kernel version does *not* trigger this — only a real build does.
 - If `/nix/store` is missing or `nix-daemon` is inactive after a fresh Nix install, initialise it with `sudo systemd-tmpfiles --create nix-daemon.conf && sudo systemctl enable --now nix-daemon.socket`.
 - The primary build/verify seam for any Host is `nix flake check`, which builds `checks.x86_64-linux.<host>` (the system toplevel); cheap targeted checks use `nix eval .#nixosConfigurations.<host>.config...`.
 - chaotic-nyx must **not** follow our `nixpkgs`, and its packages are built against chaotic's own pinned nixpkgs (its overlay defaults to `onTopOf = "flake-nixpkgs"`, the cache-friendly path).
  That is what lets the `nyx-cache.chaotic.cx` binary cache hit instead of compiling the CachyOS kernel from source; the tradeoff is that chaotic packages do not see our `unstable`/`stable` overlays.
 - The remote is self-hosted Gitea (`git.alexion.dev`); the forge CLI is `tea` (login `axi`), and `gh` is not installed.
 - nixpkgs `vimPlugins.nord-nvim` is `shaunsingh/nord.nvim` (no `require("nord").setup()`); the config wants `gbprod/nord.nvim`, which is packaged as `vimPlugins.gbprod-nord`.
 - nixpkgs `vimPlugins.nvim-treesitter` tracks the rewritten `main` branch: there is no `require("nvim-treesitter.configs").setup{ensure_installed,highlight,indent}`. Under nixvim, use `plugins.treesitter` with `highlight.enable`/`indent.enable` and `grammarPackages = with config.programs.nixvim.plugins.treesitter.package.builtGrammars; [ ... ]` — the module's own `package.builtGrammars`, **not** `pkgs.vimPlugins.nvim-treesitter.*` (whose query files can mismatch). The module targets the main branch and enables features via neovim-native APIs (`vim.treesitter.start()`, `require'nvim-treesitter'.indentexpr()`).
 - Neovim is configured via **nixvim** (flake input `nixvim`, consumed as `inputs.nixvim.homeModules.nixvim` added to `home-manager.sharedModules`, config under `home-manager.users.<user>.programs.nixvim`). `nixvim.inputs.nixpkgs.follows = "nixpkgs"` is set; nixvim then emits a benign eval warning that its pinned nixpkgs differs from the followed one — builds and runs fine, do not "fix" it by dropping the follows.
 - To reference the nixvim-built package's own attrs (e.g. treesitter `builtGrammars`) inside our NixOS module, give `home-manager.users.<user>` the module-function form (`hm: { programs.nixvim = { ... hm.config.programs.nixvim... }; }`), since the outer `config` is the NixOS config, not the home-manager one.
 - **Verifying a nixvim change headless:** `programs.nixvim.build.package`'s wrapper has **no `-u`**, so running `$OUT/bin/nvim` loads the caller's `~/.config/nvim` (the dev host's real config), *not* the built config — silently. To exercise the built config, launch with `-u "$(nix build --no-link --print-out-paths .#…programs.nixvim.build.initFile)"` and a scratch `HOME`/`XDG_CONFIG_HOME`. `conceallevel` is window-local: set it with `opt_local`/`vim.wo`, never `vim.bo[buf]` (which errors).
--- a/docs/conventional-commits.md
+++ b/docs/conventional-commits.md
@@ -0,0 +1,57 @@
 # Conventional Commits
 > Sourced from [conventionalcommits.org/en/v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
 > by the Conventional Commits authors, licensed under
 > [CC BY 3.0](https://creativecommons.org/licenses/by/3.0/).
 ---
 ## Summary
 The Conventional Commits specification is a lightweight convention on top of commit messages.
 It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.
 This convention dovetails with [SemVer](http://semver.org), by describing the features, fixes, and breaking changes made in commit messages.
 The commit message should be structured as follows:
 ```
 <type>[optional scope]: <description>
 [optional body]
 [optional footer(s)]
 ```
 The commit contains the following structural elements, to communicate intent to the consumers of your library:
 1. **fix:** a commit of the _type_ `fix` patches a bug in your codebase (this correlates with `PATCH` in Semantic Versioning).
 2. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with `MINOR` in Semantic Versioning).
 3. **BREAKING CHANGE:** a commit that has a footer with a token `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with `MAJOR` in Semantic Versioning). A BREAKING CHANGE can be part of commits of any _type_.
 4. _types_ other than `fix:` and `feat:` are allowed, for example `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
 5. _footers_ other than `BREAKING CHANGE: <description>` may be provided and follow a convention similar to [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
 Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE).
 A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`.
 ---
 ## Specification
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space.
 2. The type `feat` MUST be used when a commit adds a new feature to your application or library.
 3. The type `fix` MUST be used when a commit represents a bug fix for your application.
 4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):`.
 5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_.
 6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
 7. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
 8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
 9. A footer's token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token.
 10. A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
 11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer section.
 12. If included as a footer, a breaking change MUST consist of the uppercase text `BREAKING CHANGE`, followed by a colon, space, and description, e.g., _BREAKING CHANGE: environment variables now take precedence over config files_.
 13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
 14. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: correct spelling of CHANGELOG_.
 15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
 16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
--- a/docs/install.md
+++ b/docs/install.md
@@ -0,0 +1,153 @@
 # Installing `neogaia`
 This is the one-shot procedure that turns the `neogaia` `Host` in this flake into a running, encrypted Dell XPS 13 laptop, installed from the NixOS live ISO.
 It is destructive: it formats `/dev/nvme0n1` in full.
 Read it end to end before starting, because the laptop is the only machine and the reimage is irreversible.
 The whole install is a single `disko-install` against the `neogaia` `Host`, followed by setting a bootstrap login password by hand.
 Everything the installed system needs — the LUKS layout, the CachyOS kernel, the wifi firmware, the user, and the terminal tooling — is already declared in the flake, so this document is only the mechanics of getting that flake onto the disk.
 ## Bootstrap ordering
 The install consumes the flake from Gitea, so **the flake must already be on Gitea before you start** — the repo cannot pull a config that hasn't been pushed.
 The bootstrap login password is likewise set by hand at the end and is **never committed**, which is what keeps the public repo free of any secret while still yielding a working login on first boot.
 Two secrets are set by hand during this install, both entered interactively and neither stored in the repo:
 1. The **LUKS passphrase** that encrypts the disk, entered when `disko-install` formats it and again at every boot.
 2. The **bootstrap login password** for the `alexion` user, set through `nixos-enter` just before the reboot.
 ## 0. Push the repo to Gitea
 From your working checkout, make sure `main` is committed and pushed to the Gitea remote:
 ```console
 $ git push origin main
 ```
 The install reads only committed, git-tracked content, so anything uncommitted will not make it onto the laptop.
 ## 1. Boot the live ISO and join wifi
 Boot the machine from a NixOS live ISO (the minimal installer is enough).
 The installer logs in as the `nixos` user, who has passwordless `sudo`.
 On the minimal ISO, bring up wifi with `wpa_supplicant`:
 ```console
 $ sudo systemctl start wpa_supplicant
 $ wpa_cli
 > add_network
 0
 > set_network 0 ssid "YOUR_SSID"
 > set_network 0 psk "YOUR_WIFI_PASSWORD"
 > enable_network 0
 > quit
 ```
 On the graphical ISO, which ships NetworkManager, use `nmcli` instead:
 ```console
 $ nmcli device wifi connect "YOUR_SSID" password "YOUR_WIFI_PASSWORD"
 ```
 Confirm you have connectivity (`ping -c1 github.com`) before continuing.
 ## 2. Clone the repo locally
 Clone this repo onto the live ISO and work from that local checkout:
 ```console
 $ git clone ssh://gitea@git.alexion.dev:2022/alexion/dotfiles-nixos.git
 $ cd dotfiles-nixos
 ```
 Cloning over SSH needs your Gitea SSH key present in the live session, since the ISO starts with none.
 If getting the key onto the ISO is inconvenient, clone over HTTPS instead and tell git to skip the self-signed certificate:
 ```console
 $ git -c http.sslVerify=false clone https://git.alexion.dev/alexion/dotfiles-nixos.git
 $ cd dotfiles-nixos
 ```
 Do **not** point `disko-install` straight at the Gitea flake URL.
 Gitea serves HTTPS with a self-signed certificate and expects authentication, and Nix's flake fetcher has no easy way to skip certificate verification or supply those credentials mid-install.
 A plain `git clone` sidesteps that entirely — over SSH there is no TLS, and over HTTPS git takes the `sslVerify=false` above that the flake fetcher won't — and then `disko-install` consumes the flake from a local path, where no fetch of our repo happens during the build.
 (The public flake inputs — `nixpkgs`, `chaotic`, `disko` — are still fetched from GitHub over ordinary, valid TLS; only our own repo is the problem the local clone solves.)
 ## 3. Run `disko-install`
 Run the install as root from inside the clone:
 ```console
 $ sudo nix --extra-experimental-features 'nix-command flakes' run \
    github:nix-community/disko/latest#disko-install -- \
    --flake .#neogaia \
    --disk main /dev/nvme0n1 \
    --write-efi-boot-entries \
    --option extra-substituters https://nyx-cache.chaotic.cx/ \
    --option extra-trusted-public-keys nyx-cache.chaotic.cx:dJxTrgMC3V3cFfyIiBQDQorG6k1LsqurH/srpMSq7qk=
 ```
 What each part does:
 - `--flake .#neogaia` installs the `neogaia` `Host` from the local clone.
 - `--disk main /dev/nvme0n1` maps disko's `main` disk to the NVMe device; it matches the device declared in `hosts/neogaia/disk.nix` and is stated explicitly so there is no doubt about the target.
 - `--write-efi-boot-entries` writes the systemd-boot entry into this machine's NVRAM, because the disk stays in the laptop it was installed from.
 - The two `--option` lines are the important part: they hand the **chaotic binary cache** to the install-time Nix daemon on the live ISO.
 The chaotic substituter must be passed here explicitly.
 The `nix.settings` in the flake configure the substituters of the *installed* system, not the live ISO's daemon that runs this build; the ISO's daemon has no `substituters` beyond `cache.nixos.org`.
 Without these two `--option` flags, the build cannot fetch the prebuilt CachyOS kernel and **compiles `linuxPackages_cachyos` (and its toolchain) from source on the USB stick** — a very long detour that the cache avoids.
 Because the install runs as root, and root is a trusted Nix user, the daemon honours these client-supplied substituter settings.
 Partway through, disko formats the LUKS container and **prompts for a disk-encryption passphrase**.
 This is the passphrase you will type at every boot to unlock the disk; choose it deliberately.
 When it finishes it prints `disko-install succeeded`.
 `disko-install` unmounts the target filesystem on exit, so nothing is mounted at this point — step 4 remounts it.
 ## 4. Set the bootstrap login password
 The installed system was written with no login password (`nixos-install --no-root-password`, and the flake sets none for `alexion`), so it cannot yet be logged into.
 Set a bootstrap password by hand before rebooting.
 First remount the just-installed system with disko, which reopens the LUKS container (prompting for the passphrase from step 3) and mounts the subvolumes under `/mnt`:
 ```console
 $ sudo nix --extra-experimental-features 'nix-command flakes' run \
    github:nix-community/disko/latest#disko -- \
    --mode mount --flake .#neogaia
 ```
 Then enter the installed system and set the password for your user:
 ```console
 $ sudo nixos-enter --root /mnt
 [nixos-enter]# passwd alexion
 [nixos-enter]# exit
 ```
 This password lives only on the laptop's disk; it is **never committed** anywhere.
 ## 5. Reboot
 Unmount and reboot into the installed system:
 ```console
 $ sudo umount -R /mnt
 $ sudo reboot
 ```
 Remove the USB stick.
 At boot you are prompted for the LUKS passphrase from step 3; after unlocking, log in at the console as `alexion` with the bootstrap password from step 4 and you have a working system with fish, tmux, nvim, and Claude Code.
 ## First post-boot task
 Setting the login password by hand is a bootstrap shortcut, not the end state.
 The first thing to do on the running laptop is to move that password to a `hashedPasswordFile` backed by a `sops-nix` secret, so it is declared and reproducible like everything else.
 This is deliberately out of scope for the install itself.
 Per ADR 0001, each `Host`'s secrets are encrypted to an age key derived from that `Host`'s SSH host key — and that host key does not exist until this first install generates it.
 So the sops wiring can only happen *after* the machine is up, which is exactly why it is the first follow-up rather than part of this procedure.
--- a/flake.lock
+++ b/flake.lock
@@ -0,0 +1,236 @@
 {
  "nodes": {
    "chaotic": {
      "inputs": {
        "flake-schemas": "flake-schemas",
        "home-manager": "home-manager",
        "nixpkgs": "nixpkgs"
      },
      "locked": {
        "lastModified": 1784318604,
        "narHash": "sha256-P/N5ZbGWITiTfmiWpE/1uyXdOCagpgw/YAZLZJSzx/I=",
        "owner": "chaotic-cx",
        "repo": "nyx",
        "rev": "21a8ef816f34558a438d778057a8809322ea2415",
        "type": "github"
      },
      "original": {
        "owner": "chaotic-cx",
        "ref": "nyxpkgs-unstable",
        "repo": "nyx",
        "type": "github"
      }
    },
    "disko": {
      "inputs": {
        "nixpkgs": [
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1781152676,
        "narHash": "sha256-RxWs5ND31KzTG7wvMM+PMfUjyNpmIEr999lqNARaM5o=",
        "owner": "nix-community",
        "repo": "disko",
        "rev": "ff8702b4de27f72b4c78573dfb89ec74e36abdf1",
        "type": "github"
      },
      "original": {
        "owner": "nix-community",
        "repo": "disko",
        "type": "github"
      }
    },
    "flake-parts": {
      "inputs": {
        "nixpkgs-lib": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1782949081,
        "narHash": "sha256-vp6Y/Grm98ESt6ceOkWiHWyZRDV3J1RID4w+6NWK9yA=",
        "owner": "hercules-ci",
        "repo": "flake-parts",
        "rev": "17c9d6cdfc60c64f4ee8d306f9bc0b4ccb51481e",
        "type": "github"
      },
      "original": {
        "owner": "hercules-ci",
        "repo": "flake-parts",
        "type": "github"
      }
    },
    "flake-schemas": {
      "locked": {
        "lastModified": 1780327564,
        "narHash": "sha256-HiRPtA0spK+Dkgbhz/1zW9glXxNVB+L4Rj2VYmdawb8=",
        "rev": "6cc9bd98891b1fc6bb2b8cb3277df8bc72799ca6",
        "revCount": 149,
        "type": "tarball",
        "url": "https://api.flakehub.com/f/pinned/DeterminateSystems/flake-schemas/0.5.0/019e83cf-9af3-78b1-ac5b-70e68ad1efe1/source.tar.gz"
      },
      "original": {
        "type": "tarball",
        "url": "https://flakehub.com/f/DeterminateSystems/flake-schemas/%3D0.5.0.tar.gz"
      }
    },
    "home-manager": {
      "inputs": {
        "nixpkgs": [
          "chaotic",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1784129366,
        "narHash": "sha256-N5JiyICSeQF14x+OQebNyPpYowOT9Rs1iKyeCylSzOA=",
        "owner": "nix-community",
        "repo": "home-manager",
        "rev": "165228b0efefc3e635e5174020c40ea64271dc25",
        "type": "github"
      },
      "original": {
        "owner": "nix-community",
        "repo": "home-manager",
        "type": "github"
      }
    },
    "home-manager_2": {
      "inputs": {
        "nixpkgs": [
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1784351324,
        "narHash": "sha256-By+kuRJZRqs2TuXgtR8vJ8cTKWXw33YG/Yollu5cO1U=",
        "owner": "nix-community",
        "repo": "home-manager",
        "rev": "460108009ca1ff69ca2ff19079ca2c838d6e3080",
        "type": "github"
      },
      "original": {
        "owner": "nix-community",
        "repo": "home-manager",
        "type": "github"
      }
    },
    "nixpkgs": {
      "locked": {
        "lastModified": 1784120854,
        "narHash": "sha256-KesHgItiZPgGX740axSiQLcIQ8D24MDqNpkKYWIek8k=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "753cc8a3a87467296ddd1fa93f0cc3e81120ee46",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-unstable",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "nixpkgs-stable": {
      "locked": {
        "lastModified": 1784280462,
        "narHash": "sha256-DtoqIqM7VkR6NxAkcLpMwmi02USwWb3JdmNGLyhthc0=",
        "owner": "nixos",
        "repo": "nixpkgs",
        "rev": "293d6abedf0478e681a4dfcfcb35b30fc796a32f",
        "type": "github"
      },
      "original": {
        "owner": "nixos",
        "ref": "nixos-26.05",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "nixpkgs-unstable": {
      "locked": {
        "lastModified": 1784347607,
        "narHash": "sha256-VI5cdo27nEZ3m1SlgB8RvBbrqFUO2/dUgrrLWe407oA=",
        "owner": "nixos",
        "repo": "nixpkgs",
        "rev": "31cd72fdba8fa052e437ce7e6879c4fe62def10f",
        "type": "github"
      },
      "original": {
        "owner": "nixos",
        "ref": "nixpkgs-unstable",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "nixpkgs_2": {
      "locked": {
        "lastModified": 1784120854,
        "narHash": "sha256-KesHgItiZPgGX740axSiQLcIQ8D24MDqNpkKYWIek8k=",
        "owner": "nixos",
        "repo": "nixpkgs",
        "rev": "753cc8a3a87467296ddd1fa93f0cc3e81120ee46",
        "type": "github"
      },
      "original": {
        "owner": "nixos",
        "ref": "nixos-unstable",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "nixvim": {
      "inputs": {
        "flake-parts": "flake-parts",
        "nixpkgs": [
          "nixpkgs"
        ],
        "systems": "systems"
      },
      "locked": {
        "lastModified": 1784057377,
        "narHash": "sha256-yycNej5//EsRbV10moBoh+/63vXEwZD1ZFEiRm6C9rQ=",
        "owner": "nix-community",
        "repo": "nixvim",
        "rev": "07180a087e4a00720dc0731cbcd8dec796974381",
        "type": "github"
      },
      "original": {
        "owner": "nix-community",
        "repo": "nixvim",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "chaotic": "chaotic",
        "disko": "disko",
        "home-manager": "home-manager_2",
        "nixpkgs": "nixpkgs_2",
        "nixpkgs-stable": "nixpkgs-stable",
        "nixpkgs-unstable": "nixpkgs-unstable",
        "nixvim": "nixvim"
      }
    },
    "systems": {
      "locked": {
        "lastModified": 1774449309,
        "narHash": "sha256-brhZ8DmuGtzkCYHJg4HEd602amKm89Y9ytsFZ5uWD1w=",
        "owner": "nix-systems",
        "repo": "default",
        "rev": "c29398b59d2048c4ab79345812849c9bd15e9150",
        "type": "github"
      },
      "original": {
        "owner": "nix-systems",
        "ref": "future-26.11",
        "repo": "default",
        "type": "github"
      }
    }
  },
  "root": "root",
  "version": 7
 }
--- a/flake.nix
+++ b/flake.nix
@@ -0,0 +1,54 @@
 {
  description = "Alexion's NixOS configuration — one flake for every host";
  inputs = {
    # Base channel.
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    # Fresher packages, reachable per-package as `unstable.<name>`.
    nixpkgs-unstable.url = "github:nixos/nixpkgs/nixpkgs-unstable";
    # Latest stable release, reachable per-package as `stable.<name>`.
    nixpkgs-stable.url = "github:nixos/nixpkgs/nixos-26.05";
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    # Follows our nixpkgs so its plugins build against the same package set.
    nixvim = {
      url = "github:nix-community/nixvim";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    # Declarative disk partitioning; each host declares its own layout.
    disko = {
      url = "github:nix-community/disko";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    # CachyOS kernel and binary cache. Pins its own nixpkgs so its cache stays
    # usable and the kernel is fetched from it.
    chaotic.url = "github:chaotic-cx/nyx/nyxpkgs-unstable";
  };
  outputs =
    { self, nixpkgs, ... }@inputs:
    let
      inherit (nixpkgs) lib;
      my = import ./lib { inherit lib inputs self; };
    in
    {
      # Helper functions for discovering and building hosts.
      lib = my;
      # Every host under hosts/ is discovered and built.
      nixosConfigurations = my.mkHosts (self + "/hosts");
      # `nix flake check` builds each host's toplevel.
      checks.x86_64-linux = lib.mapAttrs (
        _name: host: host.config.system.build.toplevel
      ) self.nixosConfigurations;
    };
 }
--- a/hosts/neogaia/default.nix
+++ b/hosts/neogaia/default.nix
@@ -0,0 +1,43 @@
 { pkgs, ... }:
 # neogaia — Dell XPS 13 9380 laptop.
 # Disk layout is in ./disk.nix; `fileSystems` are derived from it, none declared here.
 {
  imports = [
    ./hardware-configuration.nix
    ./disk.nix
  ];
  system.stateVersion = "26.05";
  # systemd-boot on the EFI system partition.
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;
  boot.kernelPackages = pkgs.linuxPackages_cachyos;
  hardware.cpu.intel.updateMicrocode = true;
  # Redistributable firmware for the QCA6174 wifi (ath10k blobs).
  hardware.enableRedistributableFirmware = true;
  # RAM-backed swap; no on-disk swap partition.
  zramSwap.enable = true;
  # So wifi can be joined from the console.
  networking.networkmanager.enable = true;
  # So setup can be driven over the network.
  services.openssh.enable = true;
  # fish as the login shell.
  modules.fish.enable = true;
  modules.fish.defaultShell = true;
  modules.tmux.enable = true;
  modules.nvim.enable = true;
  modules.claude-code.enable = true;
  time.timeZone = "America/New_York";
  i18n.defaultLocale = "en_GB.UTF-8";
  console.keyMap = "us";
 }
--- a/hosts/neogaia/disk.nix
+++ b/hosts/neogaia/disk.nix
@@ -0,0 +1,60 @@
 { ... }:
 # neogaia's disk layout for disko: one NVMe disk, GPT, with an EFI system
 # partition and a LUKS container holding btrfs subvolumes. No swap partition;
 # swap is zram. disko derives `fileSystems` and `boot.initrd.luks.devices` from this.
 {
  disko.devices.disk.main = {
    type = "disk";
    device = "/dev/nvme0n1";
    content = {
      type = "gpt";
      partitions = {
        ESP = {
          size = "512M";
          type = "EF00";
          content = {
            type = "filesystem";
            format = "vfat";
            mountpoint = "/boot";
            mountOptions = [ "umask=0077" ];
          };
        };
        luks = {
          size = "100%";
          content = {
            type = "luks";
            name = "cryptroot";
            settings.allowDiscards = true;
            content = {
              type = "btrfs";
              extraArgs = [ "-f" ];
              subvolumes = {
                "@root" = {
                  mountpoint = "/";
                  mountOptions = [
                    "compress=zstd"
                    "noatime"
                  ];
                };
                "@home" = {
                  mountpoint = "/home";
                  mountOptions = [
                    "compress=zstd"
                    "noatime"
                  ];
                };
                "@nix" = {
                  mountpoint = "/nix";
                  mountOptions = [
                    "compress=zstd"
                    "noatime"
                  ];
                };
              };
            };
          };
        };
      };
    };
  };
 }
--- a/hosts/neogaia/hardware-configuration.nix
+++ b/hosts/neogaia/hardware-configuration.nix
@@ -0,0 +1,18 @@
 { lib, modulesPath, ... }:
 # Placeholder: regenerate with nixos-generate-config on the target machine.
 {
  imports = [ (modulesPath + "/installer/scan/not-detected.nix") ];
  boot.initrd.availableKernelModules = [
    "xhci_pci"
    "thunderbolt"
    "nvme"
    "usb_storage"
    "sd_mod"
  ];
  boot.initrd.kernelModules = [ ];
  boot.kernelModules = [ "kvm-intel" ];
  boot.extraModulePackages = [ ];
  nixpkgs.hostPlatform = lib.mkDefault "x86_64-linux";
 }
--- a/lib/default.nix
+++ b/lib/default.nix
@@ -0,0 +1,75 @@
 {
  lib,
  inputs,
  self,
 }:
 let
  inherit (lib)
    attrNames
    filterAttrs
    genAttrs
    flatten
    hasSuffix
    mapAttrsToList
    ;
  # Recursively collect every `.nix` file under `dir` as a flat list, for a
  # module's `imports`.
  collectNixFiles =
    dir:
    flatten (
      mapAttrsToList (
        name: type:
        let
          path = dir + "/${name}";
        in
        if type == "directory" then
          collectNixFiles path
        else if type == "regular" && hasSuffix ".nix" name then
          [ path ]
        else
          [ ]
      ) (builtins.readDir dir)
    );
  # Build one host: every module is imported unconditionally (inert until its
  # `enable` flag is set), alongside home-manager, chaotic, the shared base, and
  # the host's own directory.
  mkHost =
    {
      hostName,
      system ? "x86_64-linux",
    }:
    inputs.nixpkgs.lib.nixosSystem {
      inherit system;
      specialArgs = {
        inherit inputs;
        my = self.lib;
      };
      modules =
        (collectNixFiles (self + "/modules"))
        ++ [
          inputs.home-manager.nixosModules.home-manager
          inputs.chaotic.nixosModules.default
          inputs.disko.nixosModules.disko
          (self + "/system")
          (self + "/hosts/${hostName}")
          { networking.hostName = hostName; }
        ];
    };
  # Discover every host (a subdirectory of `hostsDir`) and build each one.
  mkHosts =
    hostsDir:
    let
      hostNames = attrNames (filterAttrs (_name: type: type == "directory") (builtins.readDir hostsDir));
    in
    genAttrs hostNames (hostName: mkHost { inherit hostName; });
 in
 {
  inherit
    collectNixFiles
    mkHost
    mkHosts
    ;
 }
--- a/modules/claude-code/CLAUDE.md
+++ b/modules/claude-code/CLAUDE.md
--- a/modules/claude-code/authentication.md
+++ b/modules/claude-code/authentication.md
@@ -0,0 +1,32 @@
 # Authenticating Claude Code without a browser
 `neogaia` is driven from the console and over SSH, where no local browser can service Claude Code's default OAuth redirect.
 Either of the two paths below signs the CLI in from a bare terminal.
 Both are one-time actions per machine; the credentials land under `~/.claude`, which home-manager does not overwrite.
 ## Paste-code flow (Claude subscription or Console OAuth)
 Run `claude` and start the login with the `/login` command (the first run offers it automatically).
 On a machine with no browser it cannot open the authorization page itself, so it prints the authorization URL and waits.
 1. Copy the printed URL to a browser on any other device (phone, another laptop).
 2. Sign in and approve the request there.
 3. The page returns a short authorization code; paste it back at the `claude` prompt still waiting in the terminal.
 The session then completes and the token is stored, so later runs need no further login.
 Because the URL is opened on a *different* device, this works unchanged over SSH.
 ## API key
 For non-interactive use, set an Anthropic API key from <https://console.anthropic.com> in the environment before launching `claude`:
 ```console
 $ export ANTHROPIC_API_KEY=sk-ant-...
 $ claude
 ```
 Claude Code reads `ANTHROPIC_API_KEY` on startup and skips the interactive login entirely, so this path needs neither a browser nor the paste-code exchange.
 Usage is billed to the Console account that owns the key rather than to a Claude subscription.
 The key is a secret and is deliberately not baked into this configuration.
 Export it from the shell for a one-off, or source it from a secret store once one exists on the Host.
--- a/modules/claude-code/claude-code.nix
+++ b/modules/claude-code/claude-code.nix
@@ -0,0 +1,62 @@
 {
  config,
  lib,
  ...
 }:
 # Claude Code for the primary user, configured through home-manager, which ships
 # the package and manages ~/.claude. Login credentials are left unmanaged so they
 # survive rebuilds.
 let
  cfg = config.modules.claude-code;
  user = config.user.name;
  # Rings the terminal bell so tmux flags the background pane.
  bellHook = [
    {
      hooks = [
        {
          type = "command";
          command = "~/.claude/hooks/attention-bell.sh";
        }
      ];
    }
  ];
 in
 {
  options.modules.claude-code.enable = lib.mkEnableOption "Claude Code, Anthropic's CLI, configured via home-manager";
  config = lib.mkIf cfg.enable {
    home-manager.users.${user}.programs.claude-code = {
      enable = true;
      # Global agent instructions, rendered to ~/.claude/CLAUDE.md.
      context = ./CLAUDE.md;
      # One directory per skill, symlinked under ~/.claude/skills.
      skills = ./skills;
      # Installed at ~/.claude/hooks/attention-bell.sh, referenced by the settings below.
      hooks."attention-bell.sh" = builtins.readFile ./hooks/attention-bell.sh;
      settings = {
        model = "opus";
        hooks = {
          Stop = bellHook;
          Notification = bellHook;
          SessionStart = [
            {
              matcher = "";
              hooks = [
                {
                  type = "command";
                  command = "gitea-axi";
                  timeout = 10;
                }
              ];
            }
          ];
        };
      };
    };
  };
 }
--- a/modules/claude-code/hooks/attention-bell.sh
+++ b/modules/claude-code/hooks/attention-bell.sh
--- a/modules/claude-code/skills/codebase-design/DEEPENING.md
+++ b/modules/claude-code/skills/codebase-design/DEEPENING.md
--- a/modules/claude-code/skills/codebase-design/DESIGN-IT-TWICE.md
+++ b/modules/claude-code/skills/codebase-design/DESIGN-IT-TWICE.md
--- a/modules/claude-code/skills/codebase-design/SKILL.md
+++ b/modules/claude-code/skills/codebase-design/SKILL.md
--- a/modules/claude-code/skills/craft-skill/GLOSSARY.md
+++ b/modules/claude-code/skills/craft-skill/GLOSSARY.md
--- a/modules/claude-code/skills/craft-skill/SKILL.md
+++ b/modules/claude-code/skills/craft-skill/SKILL.md
--- a/modules/claude-code/skills/domain-modeling/ADR-FORMAT.md
+++ b/modules/claude-code/skills/domain-modeling/ADR-FORMAT.md
--- a/modules/claude-code/skills/domain-modeling/CONTEXT-FORMAT.md
+++ b/modules/claude-code/skills/domain-modeling/CONTEXT-FORMAT.md
--- a/modules/claude-code/skills/domain-modeling/SKILL.md
+++ b/modules/claude-code/skills/domain-modeling/SKILL.md
--- a/modules/claude-code/skills/gitea-axi/SKILL.md
+++ b/modules/claude-code/skills/gitea-axi/SKILL.md
@@ -0,0 +1,48 @@
 ---
 name: gitea-axi
 description: Use when working with a Gitea repository's issues, pull requests, labels, reviews, comments, or milestones — listing, viewing, creating, editing, commenting, reviewing, or merging on a Gitea host such as git.alexion.dev. Prefer this over the `tea` CLI, raw Gitea API calls, or improvised `git` commands for issue/PR/label work.
 ---
 # gitea-axi
 `gitea-axi` is an agent-ergonomic CLI for a Gitea repository's issues and pull requests.
 Its output is compact TOON built for another program to read, and its errors are structured with actionable suggestions.
 ## When to use it
 Reach for `gitea-axi` whenever a task touches a Gitea repository's issues, pull requests, labels, or reviews.
 - **Over `tea`:** `gitea-axi` returns structured output and typed errors instead of human-formatted tables, and it defaults the repository and login from the local checkout.
 - **Over raw Gitea API calls:** it handles auth, pagination, name-to-ID resolution, and review-decision aggregation for you, so you do not hand-roll HTTP.
 - **Over improvised `git`:** for anything about issues or pull requests as entities (state, reviews, labels, comments) rather than local commits and branches.
 ## Targeting and authentication
 Every command resolves two things: which repository to act on, and which credentials to authenticate with.
 Get both right on the first call — they are the usual reason a command fails and has to be retried.
 - **Repository.** Inside a Gitea checkout it is taken from the `origin` remote automatically.
  Outside a checkout you must name it: pass `-R OWNER/NAME` on every command (or set `GITEA_AXI_REPO=OWNER/NAME` once for the session).
 - **Credentials.** When the environment is pre-configured — `GITEA_AXI_TOKEN` together with `GITEA_AXI_API_URL` — authentication is automatic and you need nothing more.
  Otherwise credentials come from a `tea` login: pass `--login <name>` (or set `GITEA_AXI_LOGIN=<name>`) unless the checkout's remote already selects one.
 So outside a checkout with the token in the environment, `gitea-axi <command> -R OWNER/NAME …` is all you need; do not go hunting for a config file or a login profile.
 ## Command groups
 - `issue` — list, view, create, comment on, edit, close/reopen, pin, and link issues.
 - `pr` — create, view, comment on, edit, review, merge, check out, diff, and inspect the checks of pull requests.
 - `label` — list, create, edit, and delete labels.
 - `search` — full-text search; it takes a subcommand, so search issues with `search issues "<query>"` and pull requests with `search prs "<query>"` (a bare `search "<query>"` is not valid).
 - `setup` — install this skill (`setup`) and, opt-in, the SessionStart dashboard hook (`setup hooks`).
 To read one issue's fields, reach straight for `issue view <number>`: it shows labels and state by default, and takes `--fields assignees,milestone,…` for the rest.
 You rarely need `issue list` to answer a question about a single issue.
 ## Discovery
 This skill is a pointer, not a command reference — the CLI is the single source of truth for its own interface.
 - Run `gitea-axi` with no arguments for the repository dashboard (open issues and pull requests).
  Add `--full` for the open-PR table and issue counts by label.
 - Run `gitea-axi <command> --help` (or `gitea-axi <group> <command> --help`) for the exact flags of any command.
--- a/modules/claude-code/skills/grill/SKILL.md
+++ b/modules/claude-code/skills/grill/SKILL.md
--- a/modules/claude-code/skills/implement/SKILL.md
+++ b/modules/claude-code/skills/implement/SKILL.md
@@ -30,7 +30,7 @@ Always branch off `main`, never off a sibling task branch.
 ### 3. Implement
-Build the work described in the task's "What to build" section, satisfying its acceptance criteria. ALWAYS use `/test-driven-development`, at the seams already agreed when the spec or task was written.
+Build the work described in the task's "What to build" section, satisfying its acceptance criteria. Use `/test-driven-development` where possible, at the seams already agreed when the spec or task was written.
 Run typechecking regularly, single test files regularly, and the full test suite once at the end.
--- a/modules/claude-code/skills/improve-codebase/HTML-REPORT.md
+++ b/modules/claude-code/skills/improve-codebase/HTML-REPORT.md
--- a/modules/claude-code/skills/improve-codebase/SKILL.md
+++ b/modules/claude-code/skills/improve-codebase/SKILL.md
--- a/modules/claude-code/skills/library/nbdev/SKILL.md
+++ b/modules/claude-code/skills/library/nbdev/SKILL.md
--- a/modules/claude-code/skills/remove-skills/SKILL.md
+++ b/modules/claude-code/skills/remove-skills/SKILL.md
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
alexion	064971f601	docs: adopt Conventional Commits for commit messages Vendor the v1.0.0 specification as docs/conventional-commits.md and record the convention in CLAUDE.md: type and optional scope, where the scope names the module or host, and no Gitea-specific references, since this repository is mirrored to GitHub where issue and pull-request numbers resolve to unrelated things.	2026-07-19 08:24:54 -04:00
alexion	41709bb977	chore!: remove the pre-NixOS dotfiles tree The flake and its modules now own every config these files provided; they remain in history for reference while the migration finishes. BREAKING CHANGE: `.config/`, `.gitconfig`, and `.github/` no longer exist at the repository root. A checkout that deploys this tree into `$HOME` will delete the live configs it previously installed.	2026-07-19 08:01:49 -04:00
alexion	77e853ab49	docs: rewrite the in-file comment convention Encode the sharpened ruleset: why-over-what, self-containment, the absence-only cross-file exception, no domain-glossary terms, no against-alternative or future-state framing, one-line file headers, placeholder wording, and how option description strings differ.	2026-07-19 07:57:44 -04:00
alexion	6a10f760cf	refactor(lib): remove the unused scriptFromFile helper It had no callers; the built system's derivation is unchanged by its removal.	2026-07-19 07:57:44 -04:00
alexion	91d0a7d8e4	style: trim verbose comments to concise, self-contained notes Cut restated "what", domain-glossary framing, cross-file consumption narration, and against-alternative justification from in-file comments; keep only non-obvious "why" and load-bearing pointers. Drop the `generateCompletions` line (a no-op restatement of the upstream default) and its comment.	2026-07-19 07:57:44 -04:00
alexion	7810425849	docs(neogaia): document the one-shot install flow Add docs/install.md, the operator runbook that turns the completed neogaia Host into a running encrypted laptop from the NixOS live ISO: push the flake to its remote, join wifi, clone the repo locally, disko-install against neogaia with the chaotic substituter handed to the install-time daemon, set the bootstrap login password by hand via nixos-enter, and reboot.	2026-07-19 07:57:43 -04:00
alexion	b7363ed7e1	feat(claude-code): manage the user's global config in the Module Bring the declarative half of ~/.claude into modules/claude-code and apply it when the Module is enabled: the global agent instructions (context = ./CLAUDE.md), the skills tree (skills = ./skills), the attention-bell hook, and settings.json (model = opus plus the Stop/Notification/SessionStart hook wiring). Runtime state (projects, plugins, cache, history, sessions) and the .credentials.json secret are left out, so login survives rebuilds and no secret enters the repo. Verified against the built home-files that ~/.claude/{CLAUDE.md,settings.json,skills,hooks/attention-bell.sh} are generated, the hook executable.	2026-07-19 07:57:43 -04:00
alexion	505002bb2b	feat(claude-code): add a Module and enable it on neogaia Install Claude Code through home-manager's native programs.claude-code module, matching how the tmux and fish Modules use their home-manager options rather than a raw home.packages entry. The feature Module at modules/claude-code/claude-code.nix stays thin — just the enable option and the delegation — and writes no settings, so login and first-run configuration remain interactive and no auth material enters the repo. Signing in without a browser (needed over the console or SSH) is documented in modules/claude-code/authentication.md: the paste-code OAuth flow, where the printed URL is opened on another device and the code pasted back, and the ANTHROPIC_API_KEY path for non-interactive use. The neogaia toplevel builds with claude-code-2.1.209 included.	2026-07-19 07:57:43 -04:00
alexion	6f9309d329	feat(nvim): configure Neovim via nixvim with Nix-managed plugins Add an nvim Module that configures Neovim declaratively through nixvim, wired as a flake input and consumed as its home-manager module. Options, globals, keymaps, and plugin settings are typed Nix; the colorscheme call and two autocmds live in modules/nvim/config.lua via extraConfigLua. Plugins come from nixpkgs (no plugin manager, no runtime cloning); git, ripgrep, and fd are provided from Nix; treesitter grammars are built by Nix so no runtime compiler is needed. Functionally matches the previous config (plugins, keymaps, options, the nord colorscheme, markdown conceal, the Neogit blame toggle), verified headless against the generated init.	2026-07-19 07:57:43 -04:00
alexion	98fecc314f	chore: untrack the reference/ snapshot and gitignore it reference/ is a read-only snapshot of the pre-migration machine, kept locally for porting configs but not part of the flake. Stop tracking it and ignore it so migrations don't churn the repo.	2026-07-19 07:57:43 -04:00
alexion	80d1587189	feat(tmux): add a native Module and enable it on neogaia Configure tmux through home-manager's programs.tmux: the settings it exposes as options (prefix, keyMode, mouse, baseIndex, clock24, escapeTime, historyLimit, terminal) are set as options, and every setting it has no option for is read verbatim from modules/tmux/extra.conf. No tmux plugin manager is used. The generated config is behaviourally identical to the reference, verified by parsing it with a live tmux binary.	2026-07-19 07:57:21 -04:00
alexion	7e53ecd946	style(fish): split the plugin comment and drop a redundant one	2026-07-19 07:57:21 -04:00
alexion	2d6eb929d7	refactor(fish): merge the config fragments back into one config.fish The interactive init is small; four fragment files was over-splitting it. Keep the mechanic (a real fish file inlined by Nix into config.fish) but merge the fragments into a single modules/fish/config.fish read with builtins.readFile. Rendered config is unchanged.	2026-07-19 07:57:21 -04:00
alexion	f54d0460ad	refactor(fish): split config.fish into fragments concatenated by Nix Break the interactive init into concern-scoped fish files under modules/fish/config/ (bindings, env, done, path) and assemble them with lib.concatMapStringsSep + readFile into a single interactiveShellInit, so home-manager still writes one ~/.config/fish/config.fish. The pieces stay editable as separate fish files; the rendered file is unchanged.	2026-07-19 07:57:21 -04:00
alexion	95869fb11f	refactor(fish): assemble the interactive init in Nix, not at runtime Fold the done plugin tuning back into config.fish and drop the conf.d fragment: config.fish is read whole into interactiveShellInit, so Nix assembles the interactive init at build time instead of fish autoloading a separate conf.d file. functions/copy.fish stays a function file, the idiomatic home for a lazily-autoloaded function.	2026-07-19 07:57:21 -04:00
alexion	5a89d4addb	refactor(fish): lay the Module out like ~/.config/fish Move the Module to modules/fish/fish.nix and mirror a real fish config directory beside it: config.fish (interactive init), conf.d/done.fish (the done plugin tuning, now a real conf.d file), and functions/copy.fish. completions/ and themes/ are omitted as they have no content and git cannot track empty directories.	2026-07-19 07:57:21 -04:00
alexion	b91e434c87	docs(fish): record the file-extraction in the project notes	2026-07-19 07:57:21 -04:00
alexion	16f29bd64a	refactor(fish): read the non-trivial snippets from files Move the interactiveShellInit block and the copy function body into modules/fish/*.fish and pull them in with builtins.readFile, so the non-trivial fish lives in real fish files (highlighting, fish_indent) instead of inline Nix strings. The Auto-loader only collects .nix, so the new .fish files are ignored by it. Rendered config is unchanged.	2026-07-19 07:57:21 -04:00
alexion	9eb0fe797a	feat(fish): gate the default shell and prefer abbreviations Move the login-shell switch behind a new modules.fish.defaultShell option (default false; neogaia opts in). Convert every non-eza alias to an abbreviation, set preferAbbrs and pin generateCompletions, and switch the command line to vi-style editing. Cap navigation at four dots and drop psmem/psmem10/dir/vdir/please. Comment the installed packages.	2026-07-19 07:57:21 -04:00
alexion	8346d63e64	feat(fish): add a native Module and set it as neogaia's login shell Translate the CachyOS fish snapshot into a home-manager Module: the fastfetch greeting, the bat-backed manpager, the done and bang-bang plugins (from nixpkgs, not a plugin manager), the history/backup/copy helper functions, and the eza and navigation aliases. Pacman-specific aliases are dropped or replaced with NixOS equivalents (update -> nixos-rebuild switch, cleanup -> nix-collect-garbage). Enabling the Module also makes fish the user's default login shell.	2026-07-19 07:57:21 -04:00
alexion	20f5b33e00	feat(neogaia): enable networking and set the base locale Turn the booted laptop into a usable, remotely reachable console: enable NetworkManager so wifi can be joined from the console and an SSH daemon so the rest of the setup can be driven over the network. Set the base locale to timezone America/New_York, locale en_GB.UTF-8, and console keymap us. These live inline in the neogaia Host rather than behind enable Modules, matching the single-Host MVI precedent; a shared locale/networking Module can be extracted once a second Host needs the same settings. SSH keeps default password auth on, as first-boot access relies on the hand-set bootstrap password until key/sops-based auth lands post-install.	2026-07-19 07:57:21 -04:00
alexion	194d64dacd	docs: require an agent sign-off on Gitea comments Add a convention: comments posted to Gitea go out under the operator's account, so sign each with a — Claude sign-off to attribute them to the agent.	2026-07-19 07:57:21 -04:00
alexion	8f83c3ca8c	refactor(neogaia): drop the zram Module and enable zram inline modules/zram.nix only wrapped the native zramSwap.enable toggle without adding anything. Rewrite the touched comments to describe only the current file content, and record the in-file-comment convention in CLAUDE.md.	2026-07-19 07:57:21 -04:00
alexion	053c4de529	feat(neogaia): add the CachyOS kernel and hardware enablement Select the CachyOS kernel per-Host via boot.kernelPackages, enable Intel microcode and redistributable firmware (ath10k for the QCA6174 wifi), and move zram behind a toggle Module. Declare the chaotic binary cache in the base Nix settings (extra-substituters/keys) so the built system fetches the kernel from nyx-cache rather than compiling it.	2026-07-19 07:57:21 -04:00
alexion	bfc9e6f75b	style(neogaia): scope the hardware comments to the current file state	2026-07-19 07:57:21 -04:00
alexion	da30375413	feat(neogaia): declare the encrypted disk with disko Add disko as a flake input (following nixpkgs) and wire its NixOS module into the host-builder, so any Host can declare a disk layout while the layout itself stays a per-Host concern. neogaia's layout (hosts/neogaia/disk.nix): one GPT NVMe disk with a systemd-boot EFI system partition and a LUKS container holding btrfs with @root/@home/@nix subvolumes. The initrd prompts for the passphrase on a normal boot. Swap is RAM-backed zram, so there is no on-disk swap partition; zramSwap is enabled directly for now. The placeholder fileSystems are removed since disko now derives them.	2026-07-19 07:57:21 -04:00
alexion	cfe8d4ff9f	style: scope in-file comments to the current file state In-file comments should describe only what the file currently is, not task numbers, external tooling, or past/future states. - hosts/neogaia: drop the "replaced by disko" / "arrive later" framing; describe the filesystems and hardware profile as the placeholder values they are. - lib: drop the "no null-placeholder traversal hack" comparison to a prior implementation. - system: drop "no impure environment lookup" from the user.name description and the sops/post-boot roadmap from the user comment.	2026-07-19 07:57:21 -04:00
alexion	25e12f79de	build(deps): pin the stable overlay and stateVersion to 26.05 26.05 is the latest stable NixOS release as of now (26.11 is still the in-development branch that nixos-unstable reports); the previous 25.05 pin was a release behind. - flake.nix / flake.lock: stable overlay tracks nixos-26.05. - neogaia system.stateVersion and the base home.stateVersion set to 26.05 (fresh install, so aligning to the current stable release). - Refresh the "latest stable release" references in the project docs to match. Other inputs are rolling branches (nixos-unstable, nixpkgs-unstable, chaotic nyxpkgs-unstable) or master (home-manager, per spec), so they carry no version to bump.	2026-07-19 07:57:21 -04:00
alexion	9b36cfadd6	feat: build the Skeleton and a minimal neogaia Host Stand up the walking skeleton the rest of the laptop MVI extends and re-verifies against: the whole neogaia Host evaluates and its system toplevel builds (nix flake check green). - flake.nix: hand-rolled flake (no flake-parts). Base nixos-unstable, plus nixpkgs-unstable and nixos-25.05 for the per-package unstable/stable overlays, home-manager (nixpkgs followed), and chaotic-nyx (deliberately not following our nixpkgs, to keep its binary cache usable). checks build each Host toplevel. - lib/: trimmed helper lib — the Auto-loader (recursive .nix discovery, no null-placeholder hack), the host-builder, and the script-from-file helper. Deps inherited explicitly; no with lib.my, no nixosModules output. - system/: shared base config — the unstable/stable overlays, the user option (defaults to alexion, in wheel, drives system + home-manager user in lockstep), flakes, git, and home-manager as a NixOS module. - modules/example.nix: Auto-loader / Enable-convention reference Module, inert until enabled. - hosts/neogaia/: minimal laptop Host — placeholder filesystems, bootloader, and hardware profile. - CLAUDE.md: project agent instructions with a Gotchas section (nix on the CachyOS dev host, the chaotic overlay/cache behaviour, the Gitea CLI).	2026-07-19 07:57:21 -04:00
alexion	d5b67947f9	docs: establish domain model, MVI spec, and environment reference Capture the design work for the NixOS migration before any implementation: - .claude/CONTEXT.md: domain glossary (Host, Module, Skeleton, Auto-loader, Enable convention, unstable/stable overlay) - .claude/adr/0001-sops-nix-for-secrets.md: secrets tooling decision - .claude/spec/laptop-mvi.md: frozen minimum-viable-install spec for neogaia - reference/: read-only snapshot of the current CachyOS configs (secrets and state excluded), plus ENVIRONMENT.md profiling the live environment to guide replication	2026-07-19 07:57:21 -04:00
		`@@ -1 +0,0 @@`
			`{"sessionId":"d1732179-27b7-49fb-82af-6669b783a444","pid":45537,"procStart":"7266197","acquiredAt":1783288905666}`
		`@@ -1,2 +0,0 @@`
			`complete --command fishtape --short v --long version --description "Print version"`
			`complete --command fishtape --short h --long help --description "Print help"`
		`@@ -1 +0,0 @@`
			`test -f "$HOME/.cargo/env.fish"; and source "$HOME/.cargo/env.fish"`