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.