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.

5 files changed, 245 insertions, 0 deletions

diff --git a/docs/2026-06-10-file-manager-evaluation.org b/docs/2026-06-10-file-manager-evaluation.org
new file mode 100644
index 0000000..da613fb
--- /dev/null
+++ b/docs/2026-06-10-file-manager-evaluation.org
@@ -0,0 +1,56 @@
+#+TITLE: File Manager Options for Wayland — 2026 Evaluation
+#+DATE: 2026-06-10
+#+DESCRIPTION: GUI + TUI file manager review. Verdict: keep nautilus; add yazi over porting ranger.
+
+* Current state
+Ratio + velox run Hyprland (pure Wayland). GUI: nautilus + nautilus-open-any-terminal. Most real file
+work happens in Emacs dired/dirvish (previews already wired). ranger exists only on the legacy X11 setup;
+the Wayland machines have no TUI file manager.
+
+* GUI field
+| Manager      | Toolkit / Wayland                          | Theme fit (Adwaita-dark GTK env)                     | Typed path / keyboard                          | Status mid-2026                                                 |
+|--------------+--------------------------------------------+------------------------------------------------------+------------------------------------------------+-----------------------------------------------------------------|
+| nautilus     | GTK4 + libadwaita, native Wayland          | Native — libadwaita dark is the house look           | C-l path entry, good type-ahead, sane defaults | Actively developed (GNOME core); Sushi previewer now GTK4       |
+| thunar       | GTK3, runs native Wayland                  | Good (GTK3 Adwaita-dark)                             | C-l toggleable path bar, light and quick       | Active (Xfce 4.20, Dec 2024); Xfce Wayland still experimental   |
+| dolphin      | Qt6/KF6, first-class Wayland (KDE primary) | Needs adwaita-qt shim; adwaita-qt itself is stagnant | Best-in-class: C-l, split view, terminal panel | Very active, but drags KDE Frameworks deps for one app          |
+| nemo         | GTK3, works on Wayland, X11-first heritage | Good (GTK3)                                          | C-l works; Nautilus-3 era ergonomics           | Maintained by Mint (6.4.x); Cinnamon Wayland still experimental |
+| pcmanfm-qt   | Qt6 (LXQt 2.x), Wayland OK                 | Same adwaita-qt caveat as dolphin                    | Basic; weakest keyboard story here             | Maintained, slow cadence, deliberately minimal                  |
+| cosmic-files | Rust/iced, Wayland-native                  | Own iced theming — ignores both GTK and Qt themes    | Decent shortcuts, still filling gaps           | First stable Dec 2025 (Pop 24.04); fast 1.0.x iteration, young  |
+
+* TUI field
+| Manager | Image preview in foot (sixel)                                   | Speed / footprint              | Plugins / zoxide                                     | Status mid-2026                                                |
+|---------+-----------------------------------------------------------------+--------------------------------+------------------------------------------------------+----------------------------------------------------------------|
+| yazi    | Built-in: auto-detects sixel/kitty/ueberzug++; video covers too | Rust, async I/O, fastest here  | Lua plugin system + ya pkg mgr; zoxide built in (z)  | Very active: v26.5.6 (May 2026), monthly releases              |
+| ranger  | ueberzug/w3m paths are X11-bound; sixel only via hacks          | Python, slowest of the set     | rifle/rc.conf ecosystem; zoxide via plugin           | Effectively frozen: still 1.9.4, 700+ open issues, no releases |
+| lf      | Sixel on by default since r38; you script the previewer         | Go single binary, very fast    | No plugin system — shell scripts; zoxide via wrapper | Active (r38+, 2025-2026 fixes for sixel/tmux)                  |
+| nnn     | Via preview-tui plugin + chafa; works but assembly required     | C, tiniest and fastest startup | Shell-script plugin dir; zoxide via plugin           | Active: 5.2 "Blue Hawaii", steady cadence                      |
+| broot   | Minimal image support; tree-nav tool, not a previewer           | Rust, fast                     | Verbs/config, not plugins; zoxide overlaps its role  | Maintained; different paradigm (fuzzy tree jump)               |
+
+* Verdict
+GUI: keep nautilus. It's the only candidate that is simultaneously native-Wayland, native to the
+Adwaita-dark look (libadwaita is the reference implementation of it), actively developed, and already
+integrated (open-any-terminal). Dolphin is the only functional upgrade, but it costs the KDE Frameworks
+dependency tree and leans on adwaita-qt, which is no longer meaningfully maintained — a bad trade for a
+secondary tool in a dired-centric workflow. cosmic-files is the one to re-check in a year: development
+pace is high, but it's young and its iced theming won't match the rest of the desktop.
+
+TUI: add yazi; don't port ranger to the Wayland machines. ranger is the clear loser here — frozen at
+1.9.4 with X11-bound preview machinery that doesn't work in foot. yazi previews images (and video
+covers) in foot via sixel with zero preview scripting, ships zoxide integration, and is the most
+actively developed tool in the set. Its role stays narrow — quick browsing and bulk ops in a terminal
+or over ssh when Emacs isn't at hand — so the cost is one pacman package. The one caveat: yazi still
+labels itself "heavy development, expect breaking changes," so config may need occasional touch-ups; if
+that churn grates, lf (sixel-on-by-default, near-zero config surface) is the stable fallback. Skipping
+a TUI entirely also remains defensible given dirvish covers previews, but at this price yazi earns the slot.
+
+* Sources
+- https://github.com/sxyazi/yazi/releases (v26.5.6, 2026-05-05)
+- https://yazi-rs.github.io/
+- https://github.com/ranger/ranger (no releases; Arch ships 1.9.4)
+- https://github.com/gokcehan/lf/releases (r38: sixel default-on)
+- https://github.com/jarun/nnn (5.2 "Blue Hawaii")
+- https://www.phoronix.com/news/GNOME-File-Previewer-GTK4
+- https://9to5linux.com/xfce-4-20-desktop-environment-released-with-experimental-wayland-support
+- https://en.wikipedia.org/wiki/COSMIC_desktop (Pop!_OS 24.04 LTS stable, 2025-12-11)
+- https://blog.system76.com/post/cosmic-epoch-2-and-3-roadmap/
+- https://github.com/linuxmint/nemo
diff --git a/docs/2026-06-10-modern-cli-tools-evaluation.org b/docs/2026-06-10-modern-cli-tools-evaluation.org
new file mode 100644
index 0000000..29031ad
--- /dev/null
+++ b/docs/2026-06-10-modern-cli-tools-evaluation.org
@@ -0,0 +1,73 @@
+#+TITLE: Modern CLI Tool Replacements — 2026 Evaluation
+#+DATE: 2026-06-10
+#+DESCRIPTION: Survey of modern Unix-tool replacements; what to adopt, what to skip. Adoption decisions pending.
+
+* Current state
+Arch + Hyprland/foot/zsh, Emacs-centric. Already adopted: eza, zoxide, ripgrep, fd,
+duf, difftastic, fzf, plus btop (installed already — counts as adopted). bat is in
+the repos but not installed. Nothing in the adopted set has been superseded as of
+mid-2026; no replacements recommended there.
+
+* Candidates
+| tool       | replaces        | verdict   | why                                                         | packaging     |
+|------------+-----------------+-----------+-------------------------------------------------------------+---------------|
+| bat        | cat/less-ish    | adopt     | syntax-highlit file views, git diff gutter, fzf previews    | extra 0.26.1  |
+| dust       | du              | adopt     | instant visual tree of what's eating disk                   | extra 1.2.4   |
+| dua-cli    | du/ncdu         | optional  | interactive variant of the same job; dust covers most of it | extra 2.34.0  |
+| hyperfine  | time loops      | adopt     | statistical benchmarking with warmup; ideal for scripts     | extra 1.20.0  |
+| tealdeer   | man (lookup)    | adopt     | <15ms tldr pages; active releases into 2026                 | extra 1.8.1   |
+| doggo      | dig/dog         | adopt     | DoH/DoT/DoQ, table output; dog itself is dead (2020)        | extra 1.1.7   |
+| xh         | curl/httpie     | optional  | httpie syntax, single fast binary; only if you do API work  | extra 0.25.3  |
+| jless      | less+jq viewing | optional  | great JSON pager; upstream quiet since ~2023 (fx is active) | extra 0.9.0   |
+| sd         | sed (simple)    | optional  | sane find/replace syntax; stable but low-activity upstream  | extra 1.1.0   |
+| bottom     | top             | skip      | btop already installed and more polished                    | extra 0.12.3  |
+| procs      | ps              | skip      | maintained, but btop + pgrep covers it                      | extra 0.14.11 |
+| yazi       | ranger/mc       | skip      | excellent and very active, but dired owns this workflow     | extra 26.5.6  |
+| broot      | tree/cd-nav     | skip      | overlaps dired + zoxide + eza --tree                        | extra 1.57.0  |
+| gping      | ping            | skip      | a graph adds little over ping/mtr                           | extra 1.20.1  |
+| choose     | cut/awk fields  | skip      | tiny win; awk muscle memory already there                   | extra 1.3.7   |
+| television | fzf             | skip      | active and interesting, but no reason to leave fzf          | extra 0.15.7  |
+| ouch       | tar/unzip/etc.  | optional  | one verb for all archive formats; small quality-of-life win | extra 0.8.0   |
+
+* Top recommendations
+- bat — the one gap in the current stack. Highlighted file views with line numbers
+  and git markers, and it slots straight into fzf preview windows and as a
+  MANPAGER/git pager. sharkdp maintains it actively (0.26.x, 2026). Works fine in
+  foot; set BAT_THEME to match the dupre palette once.
+- dust — answers "what filled this disk" in one command with a proportional tree,
+  where du -sh * | sort needs piping and rereading. Complements duf (filesystems)
+  exactly: duf for mounts, dust for directories.
+- hyperfine — statistically sound benchmarking (warmup runs, outlier detection,
+  comparison mode). Directly useful for timing archsetup script changes and shell
+  startup (hyperfine 'zsh -i -c exit').
+- tealdeer — tldr pages with ~15ms startup, so it's actually faster than recalling
+  a flag. Active through 2026 (1.8.1, fixes landing Jan 2026). Pairs with man
+  rather than replacing it.
+- doggo — dig with readable output plus DoH/DoT/DoQ support, useful when debugging
+  resolution across wireguard/tailscale where the resolver path is the question.
+  The Rust "dog" it descends from is unmaintained since 2020; doggo is the live one.
+
+* Skip list
+- bottom/procs — btop is already installed and covers both niches better.
+- yazi — superb tool, wrong user: file management lives in dired. (If ever adopted,
+  previews work in foot via sixel.)
+- broot — tree navigation already covered by zoxide + dired + eza --tree.
+- gping — novelty over ping/mtr, no daily win.
+- choose — not enough over cut/awk to earn a new habit.
+- television — fzf is adopted, deeply integrated (zoxide, shell widgets), and still
+  the ecosystem default; no migration payoff.
+- jless — fine to install ad hoc, but upstream is quiescent; fx (v39, active) is the
+  better bet if JSON browsing becomes frequent.
+- sd — works and is stable, but Emacs query-replace + sed cover the use case.
+
+* Sources
+- https://github.com/tealdeer-rs/tealdeer
+- https://github.com/mr-karan/doggo
+- https://github.com/ogham/dog
+- https://github.com/aristocratos/btop
+- https://github.com/chmln/sd
+- https://github.com/PaulJuliusMartinez/jless
+- https://github.com/alexpasmantier/television
+- https://itsfoss.com/rust-alternative-cli-tools/
+- https://sumguy.com/btop-vs-htop-vs-bottom-top-replacements/
+- Local verification: pacman -Si on all candidates (all in Arch extra, 2026-06-10)
diff --git a/docs/2026-06-10-paru-vs-yay-evaluation.org b/docs/2026-06-10-paru-vs-yay-evaluation.org
new file mode 100644
index 0000000..800b07a
--- /dev/null
+++ b/docs/2026-06-10-paru-vs-yay-evaluation.org
@@ -0,0 +1,42 @@
+#+TITLE: paru vs yay — 2026 Evaluation
+#+DATE: 2026-06-10
+#+DESCRIPTION: AUR helper comparison. Verdict: stay with yay; the maintenance picture inverted.
+
+* Question
+Should an Arch user running yay (interactively and in an unattended installer) switch to paru as of mid-2026?
+
+* Comparison
+| Dimension            | yay                                                        | paru                                                                  |
+|----------------------+------------------------------------------------------------+-----------------------------------------------------------------------|
+| Language             | Go                                                         | Rust                                                                  |
+| Last release         | v12.6.0, 2026-06-07 (days ago)                             | v2.1.0, 2025-07-08 (11 months ago)                                    |
+| Last repo push       | 2026-06-09                                                 | 2026-01-09 (5 months dormant; final commits were translation merges)  |
+| Commits, past 12 mo  | 104, ongoing through June 2026                             | 79, all before mid-January 2026                                       |
+| Maintainer health    | Jguer personally authoring/merging (11 of last 30 commits) | Morganamilo largely absent from the repo since January                |
+| Issue triage         | 182 open; active dependency + feature flow                 | 192 open; #1468 (stable fails vs libalpm 16.0.1) open 6 months, unfixed |
+| libalpm tracking     | Releases track pacman/libalpm promptly (June 2026 release) | Stable predates libalpm 16; source build broken, paru-bin breaks on soname bumps |
+| Review workflow      | Per-package Diff/Clean prompts (--answerdiff/--answerclean)| Single file-manager-style review step; stricter PKGBUILD review default |
+| News reading         | No                                                         | Reads Arch news before upgrade (interactive nicety)                   |
+| Devel handling       | development.json, -Sy --devel                              | devel.json, --devel; roughly equivalent                               |
+| Batch interaction    | All questions up front                                     | All questions up front; BatchInstall builds all, installs once        |
+| Performance          | Fast; recent search-ranking improvements                   | Marginally faster in some ops; irrelevant at this scale               |
+| Migration cost       | n/a                                                        | Low for hands; real cost is installer bootstrap + paru.conf + devel-db re-init |
+| Third options        | pikaur, aura, trizen exist; none has overtaken these two; pacman still has no AUR support | same |
+
+* Automation flags
+The installer line maps as follows, but note the asymmetry:
+- yay:  =yay -S --noconfirm --answerdiff None --answerclean None=
+- paru: =paru -S --noconfirm --skipreview=
+paru has no --answerdiff/--answerclean; its single review step replaces both prompts and --skipreview suppresses it entirely. --noconfirm passes through to pacman identically. Optional hardening: --nosudoloop/--sudoloop and --removemake behave as in yay. The mapping is clean — automation flags are not the blocker.
+
+* Verdict
+Don't switch. The deciding factor is the maintenance inversion: the old "paru is the actively developed successor" narrative is stale as of mid-2026. yay shipped v12.6.0 days ago with the maintainer personally committing, while paru has had no release in 11 months, no commit in 5, and its stable source has been unable to compile against current libalpm since December 2025 (issue #1468, still open). For an installer that must bootstrap the AUR helper unattended on a fresh system, paru is currently the one helper that can fail to build at install time; yay is the one that demonstrably keeps pace with pacman releases. Revisit only if Morganamilo resumes releases and paru regains a libalpm-current stable — even then the gain (nicer review UX, news reading) is interactive polish, not installer value.
+
+* Sources
+- https://github.com/Jguer/yay (releases: v12.6.0, 2026-06-07; GitHub API)
+- https://github.com/Morganamilo/paru (releases: v2.1.0, 2025-07-08; GitHub API)
+- https://github.com/Morganamilo/paru/issues/1468 (libalpm 16.0.1 compile failure, open)
+- https://raw.githubusercontent.com/Morganamilo/paru/master/man/paru.8 (flag verification)
+- https://www.slant.co/topics/1447/~best-aur-helpers-for-arch-based-linux-distributions
+- https://itsfoss.com/paru-aur-helper/
+- Repo stats pulled live via the GitHub API, 2026-06-10.
diff --git a/docs/2026-06-10-terminal-emulator-evaluation.org b/docs/2026-06-10-terminal-emulator-evaluation.org
new file mode 100644
index 0000000..a687b9b
--- /dev/null
+++ b/docs/2026-06-10-terminal-emulator-evaluation.org
@@ -0,0 +1,43 @@
+#+TITLE: Terminal Emulator Alternatives — 2026 Evaluation
+#+DATE: 2026-06-10
+#+DESCRIPTION: foot vs the 2026 field for pure-Wayland Hyprland. Verdict: stay with foot.
+
+* Current state
+foot 1.26.x daily driver on Hyprland (pure Wayland), themed via INI files in the dotfiles theme system, BerkeleyMono Nerd Font 13pt, tmux for sessions, vterm in Emacs for much of the shell work. ptyxis installed but secondary.
+
+* Field
+| terminal  | wayland-native          | graphics protocol               | config                  | maintenance 2026                                | notable                                                  |
+|-----------+-------------------------+---------------------------------+-------------------------+-------------------------------------------------+----------------------------------------------------------|
+| foot      | yes, Wayland-only       | sixel (no kitty gfx, no plans)  | INI                     | active; 1.26.0 Mar 2026, commits May 2026       | lowest latency in 2026 benchmarks; server mode           |
+| ghostty   | yes (GTK4, no XWayland) | kitty graphics + sixel          | flat key=value file     | very active; 1.3.0 Mar 2026, 6-mo cycle         | fastest-growing project; scrollback search landed in 1.3 |
+| kitty     | yes (native Wayland)    | kitty graphics (origin)         | INI-ish + remote control| very active; 0.47.2 Jun 2026                    | kitten ecosystem; kitty @ set-colors live theming        |
+| alacritty | yes (winit)             | none (rejected)                 | TOML, live reload       | maintained; 0.17.0 Apr 2026, maintenance mode   | speed-only scope; no images, no tabs by design           |
+| wezterm   | yes                     | kitty graphics + sixel + iTerm  | Lua (scripted)          | stagnant; last release Feb 2024, nightlies only | "is this abandoned?" issues open; spare-time project     |
+| ptyxis    | yes (GTK4/libadwaita)   | sixel only if VTE built with it | GSettings/GUI profiles  | active; v50 for GNOME 50 / Ubuntu 26.04         | container-focused; config not file-based, hard to stow   |
+| rio       | yes                     | sixel + iTerm images            | TOML                    | active; 0.4.5 May 2026, still pre-1.0           | WebGPU renderer; sixel bugs still being fixed in 2026    |
+
+* Analysis
+ghostty is the only contender with a real case. It's pure Wayland on Hyprland (explicitly no XWayland), adds kitty graphics on top of sixel, has a flat declarative config that would slot into the existing theme system, and reloads config at runtime (keybind or SIGUSR2 since 1.2 — scriptable from set-theme). Maintenance is the best in the field. Against it: measured input latency is still behind foot in 2026 Wayland benchmarks, a config-reload bug clobbers OSC 10/11-set colors (#2795), and with tmux + vterm absorbing most terminal time, its tab/window features go unused.
+
+kitty is the power-user option: kitty graphics protocol at the source, excellent font rendering, kitty @ set-colors is the best runtime theme-switching mechanism of the field. But it's heavier than foot, the single-maintainer style is opinionated, and most of its multiplexing features duplicate tmux. It earns its keep mainly if kitty-graphics-based file previews (yazi, etc.) become a daily need — sixel in foot already covers most of that.
+
+alacritty and rio don't clear the bar: alacritty is foot minus sixel with no feature direction, and rio is pre-1.0 with sixel correctness fixes still landing in May 2026. wezterm is disqualified on maintenance — no tagged release since Feb 2024 with open "is this maintained?" issues. ptyxis stays a utility terminal: GSettings-based config can't be stowed or theme-switched from the dotfiles system, and sixel depends on the distro's VTE build.
+
+foot itself stayed healthy: 1.26.0 in March 2026, steady commits, still the latency reference point for Wayland terminals. Colors swap at runtime via OSC 4/10/11 escapes, which is exactly the mechanism a set-theme script can drive across all live foot windows; new windows pick up the INI include.
+
+* Verdict
+Stay with foot. The workload (tmux + Emacs/vterm) uses a terminal as a thin, fast pty host, which is precisely what foot is optimized for — every contender's differentiators (tabs, splits, scripting, scrollback search) are already owned by tmux and Emacs. foot wins or ties on every dimension that matters here: latency (wins), Wayland purity (ties ghostty), INI theming (fits the existing system), maintenance (healthy). The one genuine gap is kitty graphics protocol, which dnkl has said foot won't grow. The answer changes if (a) kitty-graphics-dependent tooling (image-heavy file managers, plotting in-terminal) becomes daily workflow — then ghostty is the pick over kitty for its lighter config and Hyprland-native behavior — or (b) foot's maintenance lapses, which 2026 shows no sign of.
+
+* Sources
+- https://codeberg.org/dnkl/foot/releases
+- https://codeberg.org/dnkl/foot/issues/481 (kitty graphics: no plans)
+- https://ghostty.org/docs/install/release-notes
+- https://github.com/ghostty-org/ghostty/issues/2795 (reload clobbers OSC 10/11)
+- https://github.com/ghostty-org/ghostty/discussions/4280 (runtime theme switching)
+- https://sw.kovidgoyal.net/kitty/changelog/
+- https://github.com/alacritty/alacritty/releases
+- https://github.com/wezterm/wezterm/issues/7451 ("no longer updated?")
+- https://github.com/raphamorim/rio/releases
+- https://gitlab.gnome.org/chergert/ptyxis
+- https://github.com/moktavizen/terminal-benchmark (Wayland latency comparisons)
+- https://dev.to/shrsv/state-of-linux-terminal-emulators-in-2026-1gh5
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.