fix(testing): key the portal-query skip on the compositor, close warning tasks

The 19:06 verification run showed the portal skip not firing: a socket-activated xdg-desktop-portal process exists even headless, so the process check was the wrong precondition. The skip now keys on a running Hyprland, same as the socket check. That run confirmed the other three skips live (warnings 5 to 2); the remaining counted warnings are this portal case and the lingering question, which stays open.

2 files changed, 39 insertions, 67 deletions

diff --git a/scripts/testing/lib/validation.sh b/scripts/testing/lib/validation.sh
index 2734aef..f6e7fbf 100644
--- a/scripts/testing/lib/validation.sh
+++ b/scripts/testing/lib/validation.sh
@@ -543,10 +543,12 @@ validate_portal_dark_mode() {
 
     if [ "$color_scheme" = "1" ]; then
         validation_pass "Settings portal returns dark mode (color-scheme=1)"
-    elif [ -z "$color_scheme" ] && ! ssh_cmd "pgrep -f xdg-desktop-portal >/dev/null 2>&1"; then
-        # No graphical login → no portal service → nothing to query. The
+    elif [ -z "$color_scheme" ] && ! ssh_cmd "pgrep -x Hyprland >/dev/null 2>&1"; then
+        # No compositor → no graphical session bus to query. A socket-activated
+        # xdg-desktop-portal process can exist even headless, so the compositor
+        # is the real precondition (same condition as the socket check). The
         # conf-file checks above already validated what install controls.
-        validation_skip "Settings portal not running (headless) — query not applicable"
+        validation_skip "No compositor running (headless) — portal query not applicable"
     elif [ -z "$color_scheme" ]; then
         validation_warn "Could not query Settings portal (portal may not be running)"
     else
diff --git a/todo.org b/todo.org
index 678528f..027dda5 100644
--- a/todo.org
+++ b/todo.org
@@ -569,29 +569,27 @@ Root cause was in =retry_install=: =last_exit_code=$?= ran AFTER =if eval ...; t
 
 ** TODO [#C] Investigate the 2026-05-11 VM-test warnings
 :PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
+:LAST_REVIEWED: 2026-06-10
 :END:
 The 18:36 =make test= run passed (52/0/5) but raised 5 validation warnings. Each is investigated below with a recommendation. Most look like headless-VM / QEMU-slirp false positives the test harness should skip rather than archsetup bugs — but a couple have a real archsetup angle worth checking. Source: =test-results/20260511-183643/test.log= (WARN lines) and =scripts/testing/lib/validation.sh=.
 
-*** TODO [#C] Warning: Hyprland socket not found (Hyprland may not be running)
-=validate_hyprland_socket()= (=validation.sh:495=) looks for the Hyprland IPC socket and warns when it's absent. In the test VM that's expected — it's headless, nobody logs in graphically, Hyprland never starts, so there's no socket. Not an archsetup bug.
-Recommendation: harness fix in =validate_hyprland_socket()= — detect "no graphical session" (no =$WAYLAND_DISPLAY=/=$DISPLAY=, no graphical user in =loginctl=) and emit =validation_skip=/=validation_info= instead of =validation_warn=. Spinning up a real Hyprland session in the VM just to validate the socket is not worth it.
+2026-06-10: four of five resolved as harness skips (=ced91c4=, verified in the 19:06 run — warnings 5 → 2, and one of the two is the portal case whose refined skip lands next run). Only the lingering investigation below remains open.
+
+*** 2026-06-10 Wed @ 19:07:54 -0500 Hyprland-socket warning converted to a skip
+Shipped in =ced91c4=: the check now passes when the socket exists, skips (uncounted) when no Hyprland process is running — the headless-VM state — and warns only in the genuinely odd case of a running compositor with no socket. Verified live: the skip fired in the 2026-06-10 19:06 run.
 
-*** TODO [#C] Warning: Could not query Settings portal (portal may not be running)
-=validate_portal_dark_mode()= (=validation.sh:506=) queries =org.freedesktop.portal.Desktop= for =color-scheme= and warns when it can't (portal not running). Two causes: (1) headless VM → =xdg-desktop-portal= isn't running; (2) the GNOME interface settings (=color-scheme=prefer-dark= etc.) didn't get written during install because =dconf write= failed (exit 1 — see the =[#B]= item above), so even with a portal there'd be nothing to read.
-Recommendation: (a) harness — skip the portal check in headless mode, same as the Hyprland-socket one; (b) the real fix is the =dconf write= exit-1 failure tracked in =[#B] Fix install errors= — once those writes succeed during install, the settings persist and the portal returns them on a real login (this is the "without these, portal-gtk waits ~50s for a settings proxy timeout" comment in =archsetup=).
+*** 2026-06-10 Wed @ 19:07:54 -0500 Portal-query warning converted to a skip
+Shipped in =ced91c4= + a follow-up refinement: the first condition (portal process absent) didn't fire because a socket-activated =xdg-desktop-portal= exists even headless; the precondition is really a running compositor, so the skip now keys on =pgrep -x Hyprland= like the socket check. The conf-file checks (the part install controls) still pass/fail normally. The dconf-write angle stays tracked under =[#B] Fix install errors=.
 
-*** TODO [#C] Warning: mDNS ping failed (avahi may need time to propagate)
-=validate_avahi()= (=validation.sh:577=) checks =systemctl is-enabled avahi-daemon= (passes), then pings =<hostname>.local= as a full-stack mDNS test (warns on failure). The VM uses QEMU user-mode networking (slirp, =10.0.2.x=), which doesn't pass multicast — so mDNS / =.local= resolution genuinely can't work there regardless of timing. The propagation-delay message is misleading.
-Recommendation: harness fix in =validate_avahi()= — when the VM is on slirp networking (detect the =10.0.2.x= address or the absence of multicast), skip the =.local= ping and keep only the =is-enabled= check; or downgrade the ping result to =validation_info=. Optionally also bump the ping timeout/retry for the bridged-networking case. Not an archsetup bug.
+*** 2026-06-10 Wed @ 19:07:54 -0500 mDNS-ping warning converted to a slirp-aware skip
+Shipped in =ced91c4=: when the VM is on QEMU slirp (a =10.0.2.x= address), the =.local= ping is skipped — multicast genuinely can't pass there — and the =is-enabled= check stands alone. On real networking the full ping test still runs and still warns on failure. Verified live: the skip fired in the 2026-06-10 19:06 run.
 
 *** TODO [#C] Warning: User lingering not enabled (syncthing may not autostart)
 =validation.sh:661= runs =loginctl show-user <user> -p Linger= and warns if it isn't =yes=. archsetup *does* call =loginctl enable-linger "$username"= (=archsetup:1438= and =:1741=), and the install log shows =...enabling user-services lingering for cjennings @ 18:40:28= ran with no error — yet the check still says lingering is off. Likely the =logind=-unhappy-in-the-VM issue (the log-diff shows =logind: Failed to start session scope … Permission denied=) — =loginctl enable-linger= may return 0 but not actually create =/var/lib/systemd/linger/<user>=, or the =show-user= query itself may be wrong while logind is degraded. Possibly a real concern *if* the same happens on bare metal; almost certainly a VM artifact otherwise.
 Recommendation: investigate with =make test-keep= — after a run, check =ls -l /var/lib/systemd/linger/cjennings= and =loginctl show-user cjennings -p Linger= on the VM. If the file exists but =loginctl= disagrees → logind/dbus health issue (cross-ref the logind errors in =[#B]=; the fix may be to ensure =systemd-logind= is healthy before =enable-linger=). If the file doesn't exist → =enable-linger= is silently no-op'ing in the VM; consider a fallback (=install -d /var/lib/systemd/linger && touch /var/lib/systemd/linger/$username=) or running it later in the install. Either way the =enable-linger= call in =archsetup= is wired correctly.
 
-*** TODO [#C] Warning: Docker enabled but not responding
-=validation.sh:791= does =systemctl is-enabled docker= (passes) then =docker info= (warns on failure). Root cause: =archsetup:1981= does =systemctl enable docker.service= — *enable*, not =enable --now= — so docker is enabled-on-boot but not started during install. The test runs validations immediately after archsetup with no reboot, so =docker info= fails because the daemon isn't running yet. That's expected, not a bug. (The =daemon.json= with =storage-driver: zfs= at =archsetup:1971-1979= is correctly gated on =is_zfs_root=, so on the btrfs test VM Docker auto-picks the =btrfs= driver — not the cause here.)
-Recommendation: harness fix in the docker check — treat "enabled, not running pre-reboot" as a pass/info, or =systemctl start docker= first and then run =docker info=. Separately, decide whether =archsetup= should =enable --now docker= for immediate use or keep enable-on-boot (most steps use =enable --now=; docker being the exception may be intentional given the daemon's weight — if so, leave it and just fix the validation).
+*** 2026-06-10 Wed @ 19:07:54 -0500 Docker warning converted to a pre-reboot skip
+Shipped in =ced91c4=: =docker info= success still passes; enabled-but-inactive (the deliberate enable-not-now install state, validated pre-reboot) now skips; active-but-unresponsive still warns — that's the real failure case. Verified live: the skip fired in the 2026-06-10 19:06 run. The enable vs enable-now question for archsetup itself was left as-is (the daemon's weight makes enable-on-boot defensible).
 
 Note: the run also logged two log-diff meta-warnings — "Found 4 new error lines after archsetup" and "New failed services detected (before: 1, after: 2)". Those correspond to the post-install systemd noise (pam_systemd / logind / Proton VPN) already captured under =[#B] Fix install errors= above; not duplicated here.
 
@@ -804,11 +802,12 @@ Packages installed with ~--noconfirm~ may skip signature checks
 AUR had issues previously requiring --noconfirm workaround - verify this doesn't compromise security
 Ensure package signatures are still verified despite --noconfirm flag
 
-** TODO [#B] Document evaluation criteria and trade-offs
+** DONE [#B] Document evaluation criteria and trade-offs
+CLOSED: [2026-06-10 Wed]
 :PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
+:LAST_REVIEWED: 2026-06-10
 :END:
-Establish clear process for tool evaluation decisions
+Written 2026-06-10: [[file:docs/2026-06-10-tool-evaluation-criteria.org][docs/2026-06-10-tool-evaluation-criteria.org]] — four gating criteria (Wayland-native, actively maintained with live verification, automation-compatible, stowable config), five weighting criteria, the process, and the trade-offs accepted in the 2026-06-10 evaluation round.
 
 ** TODO [#B] Test each modernization thoroughly before replacing
 :PROPERTIES:
@@ -825,32 +824,12 @@ Detect NVIDIA GPU and warn user about potential Wayland issues:
 - Document required env vars (LIBVA_DRIVER_NAME, GBM_BACKEND, etc.)
 - Prompt to continue or abort if NVIDIA detected
 
-** TODO [#B] Add org-capture popup frame on keyboard shortcut
+** DONE [#B] Add org-capture popup frame on keyboard shortcut
+CLOSED: [2026-06-10 Wed]
 :PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
+:LAST_REVIEWED: 2026-06-10
 :END:
-Set up a quick-capture popup using emacsclient that opens a small floating
-org-capture frame, with Hyprland window rules to float, size, and center it.
-Frame should auto-close on finalize (C-c C-c) or abort (C-c C-k).
-
-Implementation:
-1. Create =~/.local/bin/quick-capture= script:
-   - =emacsclient -c -F '((name . "org-capture") (width . 80) (height . 20))' -e '(org-capture)'=
-   - Requires Emacs daemon running (already configured via systemd)
-2. Add Hyprland window rules to =hyprland.conf=:
-   - =windowrulev2 = float, title:^(org-capture)$=
-   - =windowrulev2 = size 800 400, title:^(org-capture)$=
-   - =windowrulev2 = center, title:^(org-capture)$=
-   - =windowrulev2 = stayfocused, title:^(org-capture)$=
-3. Add keybind in =hyprland.conf= (choose available key combo)
-4. Add Elisp hook to auto-delete the frame after capture:
-   =(defun my/org-capture-delete-frame ()
-     (when (equal (frame-parameter nil 'name) "org-capture")
-       (delete-frame)))
-   (add-hook 'org-capture-after-finalize-hook #'my/org-capture-delete-frame)=
-5. Notes go directly into existing org capture templates — zero new infrastructure
-
-Reference: Protesilaos Stavrou's popup frame pattern for emacsclient.
+Shipped 2026-06-10, all five spec steps: =quick-capture= script (dotfiles =08ae188=, 3 unit tests, notify-on-failure when the daemon's down), Hyprland window rules in current 0.53+ syntax (float, 900x500, center, stay_focused on title org-capture) + Super+Shift+N bind (same commit), and the auto-close hook in =org-capture-config.el= (.emacs.d =1a25fada=, .elc recompiled, loaded live). Verified end-to-end on ratio: popup opens floating/centered with the template menu (screenshot), frame auto-deletes on org-capture-kill — finalize uses the same hook. Existing capture templates untouched.
 
 ** TODO [#C] Review theme config architecture for dunst/fuzzel
 :PROPERTIES:
@@ -908,36 +887,26 @@ Practical guidelines for working in public spaces
 :END:
 Single command shows: encryption status, firewall status, open ports, running services
 
-** TODO [#C] Evaluate modern CLI tool replacements
+** VERIFY [#C] Evaluate modern CLI tool replacements
 :PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
+:LAST_REVIEWED: 2026-06-10
 :END:
-bat, eza, zoxide, dust, ripgrep-all - only adopt if clear friction reduction
+Research done 2026-06-10, adoption decisions pending. Full report: [[file:docs/2026-06-10-modern-cli-tools-evaluation.org][docs/2026-06-10-modern-cli-tools-evaluation.org]]. Recommendation: adopt bat, dust, hyperfine, tealdeer, doggo (all in extra, all actively maintained); optional xh/jless/sd/ouch; nothing already-adopted has been superseded. Say which to install and I'll add them to archsetup + the machines.
 
-** TODO [#C] Consider paru instead of yay
-:PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
-:END:
-Evaluate if paru offers meaningful improvements for AUR management
+** 2026-06-10 Wed @ 18:25:11 -0500 paru vs yay — evaluated, staying with yay
+Research done 2026-06-10: [[file:docs/2026-06-10-paru-vs-yay-evaluation.org][docs/2026-06-10-paru-vs-yay-evaluation.org]]. The maintenance picture inverted since the task was filed: yay released v12.6.0 on 2026-06-07 with active triage, while paru has had no release in 11 months, no commit in 5, and a stable that fails to build against current libalpm (issue #1468 open 6 months). For an installer that bootstraps the AUR helper unattended, paru is the riskier choice on every axis that matters. No decision needed — the evidence closes this one; revisit only if paru's maintenance resumes.
 
-** TODO [#C] Evaluate terminal emulator alternatives
+** VERIFY [#C] Evaluate terminal emulator alternatives
 :PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
+:LAST_REVIEWED: 2026-06-10
 :END:
-ghostty for ligature support - addresses known deficiency
+Research done 2026-06-10, your read pending. Full report: [[file:docs/2026-06-10-terminal-emulator-evaluation.org][docs/2026-06-10-terminal-emulator-evaluation.org]]. Recommendation: stay with foot — it wins on latency, ties on Wayland purity, fits the theme system, and stays healthy (1.26.0, Mar 2026). ghostty is the only real challenger (and the original ligature motivation favors it — foot still doesn't do ligatures), so the open question is whether ligatures matter enough to trade foot's latency edge. wezterm is effectively unmaintained (no release since Feb 2024).
 
-** TODO [#C] Review file manager options for Wayland
+** VERIFY [#C] Review file manager options for Wayland
 :PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
+:LAST_REVIEWED: 2026-06-10
 :END:
-Ranger image previews don't work in foot terminal (Wayland). Ranger's kitty graphics
-method checks TERM for "kitty" string, and foot's kitty protocol implementation
-has subtle incompatibilities that cause hangs. ueberzug is X11-only.
-
-Tried yazi (2026-02) - theming/icon color customization was problematic.
-Revisit later when yazi matures or try lf with custom preview scripts.
-
-Keep ranger for DWM/X11 where ueberzug works fine.
+Research done 2026-06-10, adoption call pending. Full report: [[file:docs/2026-06-10-file-manager-evaluation.org][docs/2026-06-10-file-manager-evaluation.org]]. Recommendation: keep nautilus (only candidate that's Wayland-native, libadwaita-dark native, and actively developed); add yazi as the Wayland TUI (v26.5.6, monthly releases, sixel previews work in foot with zero scripting, zoxide built in — it has matured substantially since the problematic 2026-02 try). ranger upstream is effectively frozen (still 1.9.4, 700+ open issues), so porting it to the Wayland machines is the one option the evidence rules out. Original body's history preserved in git.
 
 ** TODO [#C] Review current tool pain points annually
 :PROPERTIES:
@@ -945,11 +914,12 @@ Keep ranger for DWM/X11 where ueberzug works fine.
 :END:
 Once-yearly systematic inventory of known deficiencies and friction points in current toolset
 
-** TODO [#C] Install Zoxide integration into Ranger :quick:
+** DONE [#C] Install Zoxide integration into Ranger :quick:
+CLOSED: [2026-06-10 Wed]
 :PROPERTIES:
-:LAST_REVIEWED: 2026-05-21
+:LAST_REVIEWED: 2026-06-10
 :END:
-https://github.com/jchook/ranger-zoxide - enables zoxide jumping within ranger file manager
+Shipped 2026-06-10 as dotfiles commit =220dde6=: jchook/ranger-zoxide vendored (with MIT license) into both =common/= and =minimal/= ranger plugin dirs — :z and :zi commands wherever ranger runs. Python syntax verified; live verification is yours (see Manual testing) and needs a machine with ranger installed — note neither Wayland box has it, and the same-day file-manager evaluation recommends yazi over porting ranger forward.
 
 ** TODO [#D] Consider Customizing Hyprland Animations
 Current: windows pop in, scratchpads slide from bottom.