chore(tasks): close the fn-lock bug and file the speedtest cancelHEADmain

The F row issuing media actions was the Framework EC's Fn Lock. One
Fn+Esc toggle fixed it, confirmed live, so the task closes with no code
change. The F9 video-recording unbind turned out to be Emacs config,
not Hyprland, and went to that repo as a handoff. Also filed the net
panel speedtest-cancel capture as a task and archived three finished
tasks.

1 files changed, 45 insertions, 90 deletions

diff --git a/todo.org b/todo.org
index eade66e..3f0dd5f 100644
--- a/todo.org
+++ b/todo.org
@@ -45,6 +45,24 @@ below):
   input-side-spec.org (DRAFT, four decisions open).
 
 * Archsetup Open Work
+** TODO [#B] Speedtest button cancels an in-flight run :feature:dotfiles:network:
+:PROPERTIES:
+:CREATED: [2026-09-01 Tue]
+:LAST_REVIEWED: 2026-09-01
+:END:
+
+From the roam inbox (routed 2026-09-01), Craig's words: "pressing the
+speedtest button on network admin panel when speedtest is already running
+should cancel the speedtest. However, we should leave any numbers on the
+display as if the speedtest completed successfully."
+
+Net panel work lives in ~/.dotfiles; archsetup owns it end-to-end per the
+standing rule in notes.org. Distinct from the [#C] speedtest-history task
+(that one persists results over time; this one is in-flight cancel
+semantics). Behavior is fully specified: second press kills the running
+test, display keeps whatever numbers are already shown as a completed
+result. [#B]: real improvement to the active panel family, no hard date.
+
 ** TODO [#B] gcalcli in the installer, token carried from the other daily driver :feature:velox:tooling:solo:
 :PROPERTIES:
 :CREATED: [2026-08-25 Tue]
@@ -285,26 +303,6 @@ The cursor entry in the same file records this identical failure a third time:
 compositor's scale." Three instances of one mistake in one file, two previously
 fixed in isolation without anyone naming the pattern.
 
-** TODO [#B] Function keys issue media actions instead of F-keys :bug:velox:
-:PROPERTIES:
-:CREATED: [2026-08-19 Wed]
-:LAST_REVIEWED: 2026-08-19
-:END:
-
-From the roam inbox, Craig's words: "function keys should issue F+number
-functionality rather than their media functionality when the button is hit.
-currently it's reversed and I have to hit function and the f button for F+number
-functionality."
-
-Check first whether this belongs to archsetup at all. On a Framework the Fn-lock
-is a firmware-level toggle held in the keyboard itself (Fn+Esc on most
-revisions), not something the OS sets, in which case this is one keystroke
-rather than a change here. If it is instead a hid/keyboard-module quirk, it is
-ours.
-
-Grading: Minor severity (the keys work, they are on the wrong layer, and there
-is a workaround) x every user every time (every F-key press) = P2 = [#B].
-
 ** TODO [#C] Waybar panels launch expanded instead of collapsed :bug:dotfiles:waybar:
 :PROPERTIES:
 :CREATED: [2026-08-19 Wed]
@@ -3541,76 +3539,6 @@ carry a date and Craig's return date isn't known yet — date it and raise it to
 Workaround in the meantime: Bluetooth mouse, already in use.
 
 
-** DONE [#B] Two agent sessions sharing one git repo :chore:tooling:
-CLOSED: [2026-07-26 Sun]
-Craig approved the shared-rules-layer solution on 2026-07-26.
-
-Use one repository-scoped publish lock for every session and worktree sharing a clone. Derive the lock name from the real Git common-directory path; hold it across reconcile, stage, staged review, and commit; track the owning session and reviewed staged-tree fingerprint; refresh it after conversational waits; and repeat the staged review if ownership or the fingerprint changed. Ordinary working-tree edits remain concurrent.
-
-An approval waiver never waives the staged review, because that review is the gate that reads the actual hunks entering the commit. Rulesets owns the implementation in =commits.md=, =agent-lock=, and its Bats coverage; archsetup sent the approved implementation package through the rulesets inbox.
-** DONE [#A] Reboot ratio to activate amdgpu.runpm=0 :bug:hyprland:ratio:
-CLOSED: [2026-07-28 Tue] DEADLINE: <2026-07-28 Tue>
-:PROPERTIES:
-:CREATED: [2026-07-28 Tue]
-:LAST_REVIEWED: 2026-07-28
-:END:
-Craig's plan: close everything down, run topgrade, then reboot. Alarm set for 08:00 (=at= job 56, persistent desktop notify).
-
-=amdgpu.runpm=0= sits in =/etc/default/grub= and in the generated =/boot/grub/grub.cfg= (5 occurrences, so the reboot will actually apply it) but is absent from =/proc/cmdline=. The box has been up since 2026-07-22 21:10 and the fix landed 2026-07-24, so the running kernel predates it. The GPU is AMD Strix Halo (Radeon 8060S, =1002:1586=), exactly what the parameter targets: runtime power management invalidates the GPU resources hyprlock holds across a display power-cycle, so hyprlock exits without unlocking.
-
-That is the root cause under the 2026-07-27 lockdead screen. The screen-lock flock fix (dotfiles =ec18fd7=) stops one dead client from becoming a lockdead screen, but it treats the symptom -- this reboot treats the cause.
-
-Not :solo: — Craig closes his own session and runs topgrade first.
-
-Rebooted 2026-07-28 08:59. =amdgpu.runpm=0= confirmed present in =/proc/cmdline= afterward, so the parameter is finally live.
-
-Correction, 2026-07-29: the claim above and in the body that this is "the root cause under the 2026-07-27 lockdead screen" is wrong, and superseded. hyprlock was never crashing. Every logged exit is =rc=143=, SIGTERM, from =settings-watch= killing it by design. See =[#B] Night watch and the lock watchdog fight each other=. The reboot was still worth doing (the parameter is a genuine mitigation for a real AMD defect) but it did not fix this, and the lockdead screens continued after it.
-** DONE [#B] Caffeine state is unreadable on both surfaces :bug:dotfiles:design:solo:
-CLOSED: [2026-07-28 Tue]
-:PROPERTIES:
-:CREATED: [2026-07-28 Tue]
-:LAST_REVIEWED: 2026-07-28
-:END:
-Neither surface that reports caffeine tells the truth reliably, so there is no way to know at a glance whether the screen will lock. Found while investigating the 2026-07-27 lockout, where Craig believed caffeine was on and the screen locked anyway.
-
-Defect 1 — the settings panel shows a frozen value. =gui.py= calls =_refresh_async()= once during window construction (line 454) and again only after the user's own actions (=_after_matrix=, line 663). The only two =GLib.timeout_add= calls are one-shots (the 2400ms toast hide and a 350ms fire), so nothing re-reads state on a timer. An open panel therefore displays the caffeine value from the moment it opened, forever. Any external flip -- the waybar click, Super+I, the =caffeine-toggle= script -- leaves it stale with no self-correction. The panel is the only surface in the repo carrying a caffeine control (=panel.py:25=); maint has none and does not embed these toggles, so this is the display Craig read.
-
-Defect 2 — there is no caffeine indicator on the bar at all. =custom/caffeine= appears in neither the stowed =hyprland/.config/waybar/config= nor the live generated =/run/user/1000/waybar/config=, and no =custom/caffeine= block is defined anywhere in the waybar config dir. The =waybar-caffeine= script exists, works, and has its own passing test suite, but nothing displays it. So the bar has never been a source of caffeine state, and the keybind and script have been signalling (=pkill -RTMIN+8 waybar=) a module that isn't there.
-
-(An earlier read of this task said the bar showed two near-identical glyphs. That was wrong: the module is absent, not merely unstyled. The script's class names are still backwards -- =active= when caffeine is OFF, =inhibited= when ON -- and neither class is styled, but both points are moot until the module is actually in the bar.)
-
-Grading: Major severity (the panel reports state wrongly while it is open, and the only other surface does not exist, so there is no reliable source for a setting Craig actively manages) x most-of-the-time (any external toggle while the panel is open; the bar never shows it) = P2 = [#B].
-
-Fix all three. Wire =custom/caffeine= into the bar, rename its classes so they describe caffeine rather than idle, and style them from the existing palette. Give the panel's toggle row a re-read on a timer or on focus-in. Solo -- buildable and testable, and the direction is settled by the defects rather than a taste call, though the bar color is worth a glance from Craig once it renders.
-
-All three shipped as dotfiles =033076c=, pushed. =custom/caffeine= now sits in the bar between DND and settings on =interval: 2=; classes renamed =on=/=off= and both styled, caffeine-ON in the theme's gold =#dab53d=; the panel re-reads live state every 3s while visible. Verified live in the stowed config and the generated =/run/user/1000/waybar/config=. The full suite caught a theme-copy regression (=themes/dupre/waybar.css= out of sync with =waybar/style.css=) that the focused suites missed.
-** DONE [#B] hyprlock still exits mid-lock; the watchdog relaunch is silent :bug:hyprland:dotfiles:
-CLOSED: [2026-07-29 Wed]
-:PROPERTIES:
-:CREATED: [2026-07-28 Tue]
-:LAST_REVIEWED: 2026-07-28
-:END:
-Craig, 2026-07-28 ~15:00: saw the Hyprland lockdead/error text blurred *behind* a working lock screen; it vanished when he authenticated.
-
-That ordering is the diagnosis. hyprlock's blur samples what the compositor is currently rendering, so the compositor was already showing lockdead when the new hyprlock attached. Sequence: hyprlock exits non-zero (no coredump, so it exits rather than crashing), Hyprland renders lockdead because the client is gone while the session stays locked, =screen-lock='s watchdog relaunches within =LOCK_RELAUNCH_DELAY= (0.5s), and the new client draws over the lockdead frame and blurs it.
-
-*The recovery worked.* On 2026-07-27 this same hyprlock exit produced two contending clients and a session recoverable only from another console. It now self-heals in half a second, and the residue is cosmetic. Both the flock guard (dotfiles =ec18fd7=) and the watchdog did their jobs — verified in this session's compositor log, where all four lock events created exactly one =sessionLock= and one =sessionLockSurface= each, against two of each on 2026-07-27.
-
-Two things remain.
-
-*Why hyprlock exits.* The wrapper's header blames GPU-resource invalidation across a display power-cycle (hyprlock#953), which =amdgpu.runpm=0= targets — and that parameter is live as of the 2026-07-28 08:59 reboot, confirmed in =/proc/cmdline=. There is also no DPMS idle rule any more (=e900903=), so idling never power-cycles the display. Yet hyprlock still exited. Strongest untested candidate: a screen recording (=wf-recorder= into =~/sync/recordings/2026-07-28-12-53-57.mkv=, running 12:53 until Craig killed it) held screencopy sessions on DP-4 across the lock. The compositor log carries 2454 screenshare sessions and a =CScreencopyProtocol= bind in the window between the last two locks. A screencopy client churning dmabufs alongside hyprlock's own is a plausible way to invalidate them, and it was the one large new variable that day.
-
-*The relaunch is silent.* The watchdog loop re-runs hyprlock and logs nothing, so there is no record of how often this fires, when, or with what exit code — which is exactly why the frequency couldn't be established from the logs. Log the exit code and a timestamp on each relaunch.
-
-Grading: Major severity (the lock client dies mid-lock, and the pre-fix version of this wedged a session unrecoverably) x most users frequently (twice in three days, and this is a single-user machine, so every occurrence lands on the only user) = P2 = [#B]. Downgraded from the 2026-07-27 [#A] because the wedge is fixed and the failure now self-heals.
-
-An earlier draft of this grading said "some users sometimes", which the matrix maps to P3 = [#C], not the [#B] written beside it. The frequency row was the wrong input rather than the letter: on a one-user machine a fault hitting twice in three days is frequent, not occasional. Corrected the input per the rule that a disputed grade is fixed at its inputs.
-
-Solo for the instrumentation half only: adding the relaunch logging is buildable, testable against the existing =tests/screen-lock= suite, and needs no decision. Diagnosing the exit is not solo — it needs a reproduction, and the likely trigger is Craig recording his screen.
-
-Next step when picked up: land the relaunch logging first so the next occurrence produces evidence, then try to reproduce by locking with =wf-recorder= running.
-
-Superseded 2026-07-29 by =[#A] Night watch and the lock watchdog fight each other=. The logging landed (dotfiles =5bbe2c3=) and answered it within hours: three =rc=143= entries, SIGTERM, from =settings-watch= killing hyprlock by design. Nothing was crashing, so both the AMD-iGPU and the screen-recorder hypotheses in this task are wrong. Kept closed rather than deleted because the reasoning that led here is worth the record.
 ** DONE [#A] Idle commits silently drop the screen-lock wrapper :bug:hyprland:dotfiles:security:
 CLOSED: [2026-08-04 Tue] DEADLINE: <2026-07-29 Wed>
 :PROPERTIES:
@@ -4491,3 +4419,30 @@ systemd user environment, and probed from a throwaway frame:
 =(pgtk-backend-display-class)= → =GdkWaylandDisplay=, =*Warnings*= alive.
 Ratio still wants a reboot for =linux 7.1.9=. Pacnews to review there:
 =/etc/ssh/sshd_config.pacnew= and two =/etc/tpm2-tss/fapi-profiles/*.json=.
+** DONE [#B] Function keys issue media actions instead of F-keys :bug:velox:
+CLOSED: [2026-09-01 Tue]
+:PROPERTIES:
+:CREATED: [2026-08-19 Wed]
+:LAST_REVIEWED: 2026-08-19
+:END:
+
+From the roam inbox, Craig's words: "function keys should issue F+number
+functionality rather than their media functionality when the button is hit.
+currently it's reversed and I have to hit function and the f button for F+number
+functionality."
+
+Check first whether this belongs to archsetup at all. On a Framework the Fn-lock
+is a firmware-level toggle held in the keyboard itself (Fn+Esc on most
+revisions), not something the OS sets, in which case this is one keystroke
+rather than a change here. If it is instead a hid/keyboard-module quirk, it is
+ours.
+
+Grading: Minor severity (the keys work, they are on the wrong layer, and there
+is a workaround) x every user every time (every F-key press) = P2 = [#B].
+
+Resolved 2026-09-01: not ours, as the body suspected. The Fn layer is decided
+in the EC (the keyboard reaches Linux as a plain AT keyboard on i8042), so no
+OS-side knob exists. One keystroke: Fn+Esc toggles Fn Lock; Craig confirmed
+F1-F12 now send F-keys by default. The EC holds the state across reboots; it
+reverts only if the EC loses power (battery disconnect or mainboard reset),
+which is likely why it flipped around the August reinstall.