docs: add 2026 tool evaluations — CLI replacements, AUR helper, terminals, file managers, criteria

Five evaluation reports: modern CLI tools (adopt bat/dust/hyperfine/tealdeer/doggo, all in extra), paru vs yay (stay with yay — paru dormant 11 months with a libalpm-broken stable), terminal emulators (stay with foot; ghostty the only challenger, wezterm effectively unmaintained), Wayland file managers (keep nautilus, add yazi over porting the frozen ranger), and the standing evaluation criteria distilled from the round. Maintenance claims verified against live repo data, not aggregator articles.

1 files changed, 31 insertions, 0 deletions

diff --git a/docs/2026-06-10-tool-evaluation-criteria.org b/docs/2026-06-10-tool-evaluation-criteria.org
new file mode 100644
index 0000000..f5fec34
--- /dev/null
+++ b/docs/2026-06-10-tool-evaluation-criteria.org
@@ -0,0 +1,31 @@
+#+TITLE: Tool Evaluation Criteria and Trade-offs
+#+DATE: 2026-06-10
+#+DESCRIPTION: The standing criteria for evaluating tool replacements in this setup, distilled from the 2026-06-10 evaluation round.
+
+* Purpose
+A replacement tool earns adoption only when it beats the incumbent on a dimension that matters here, without losing on a gating dimension. These criteria make that test explicit so future evaluations (and the annual pain-point review) apply the same bar instead of re-deriving it.
+
+* Gating criteria (fail any → reject)
+1. Wayland-native. No XWayland dependency, ever. X11-only preview/clipboard machinery counts as failure (see: ranger's ueberzug path).
+2. Actively maintained. A release or meaningful commit activity within the last ~12 months, and no open "is this abandoned?" signals. Verify with the repo, not aggregator articles — stale narratives persist for years (see: paru-vs-yay, where the 2021 story had fully inverted by 2026).
+3. Automation-compatible where the installer touches it. Anything archsetup provisions non-interactively must have working unattended flags (see: the --answerdiff/--skipreview mapping check).
+4. Stowable, declarative config. File-based config that lives in the dotfiles repo and survives a stow. GSettings/GUI-only config fails (see: ptyxis as a theming dead end).
+
+* Weighting criteria (compare on these)
+- Daily-use win: does it remove a real friction, or is it novelty? "Answers in one command what took a pipeline" (dust) beats "same answer, prettier" (gping).
+- Workflow fit: Emacs (dired, vterm, magit) and tmux already own many niches. A candidate duplicating them adds maintenance surface without adding capability (see: terminal tabs/splits, broot vs dired+zoxide).
+- Theme-system fit: can set-theme drive it (INI/TOML include, runtime color escape, reload signal)? Tools that can't follow dupre/hudson stay second-class.
+- Packaging: official repo > AUR > git build. Every step down adds update fragility to fresh installs.
+- Migration cost: config translation, muscle-memory retraining, installer changes. Cost scales with how load-bearing the incumbent is.
+
+* Process
+1. Re-verify maintenance claims live (repo releases/commits, not blog posts).
+2. Compare against the incumbent on the weighting criteria; the incumbent wins ties — switching costs are real and "not worth adopting" is a valid verdict.
+3. Adoption decisions are Craig's; evaluations produce a recommendation plus the condition that would change it ("revisit if X").
+4. Adopted tools get codified in archsetup the same cycle, so fresh installs match the live machines.
+5. Cadence: the annual pain-point review (todo) triggers re-evaluation; otherwise re-check only when an incumbent's maintenance lapses or a workflow change opens a gap.
+
+* Trade-offs accepted in the 2026-06-10 round
+- foot keeps its no-kitty-graphics stance; accepted because sixel covers current preview needs.
+- yay's weaker PKGBUILD-review UX accepted for its maintenance health and unattended-install reliability.
+- nautilus's modest keyboard ergonomics accepted for native libadwaita fit and zero extra dependency weight.