#+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.