chore(tasks): claim the roam captures and record the scaling diagnosis

Four items claimed from the shared roam inbox:

- Qt apps oversized on velox
- function keys issuing media actions instead of F-keys
- waybar panels launching expanded
- a question about the analog clock avoiding being dragged

The last is a VERIFY, since the capture asks for a conversation rather than describing a defect. Two unowned product links stay in the shared inbox.

The Qt one is diagnosed and fixed in dotfiles ec8e9a8, recorded here with the measurement. A VERIFY rides along on whether the calibre DPI pin is still needed, because it looks like the same double-scaling worked around per-app. The cursor comment in that file records it a third time.

Also closes the net-scenarios timeout, which predates today by a month. It guessed at a larger timeout or a real hang in the script and it was neither. The stubbed ssh drains stdin, so the tests hung whenever the runner had a live one.

1 files changed, 174 insertions, 45 deletions

diff --git a/todo.org b/todo.org
index 4a34798..6f16129 100644
--- a/todo.org
+++ b/todo.org
@@ -45,38 +45,133 @@ below):
   input-side-spec.org (DRAFT, four decisions open).
 
 * Archsetup Open Work
-** TODO [#B] agent-text relay reports success for a message that went nowhere :bug:blocked:
+** TODO [#B] Qt apps render oversized on velox :bug:velox:solo:
 :PROPERTIES:
 :CREATED: [2026-08-19 Wed]
 :LAST_REVIEWED: 2026-08-19
 :END:
 
-rulesets accepted the relay-fallback change I sent on 2026-08-16 and parked it
-for Craig's approval, since =agent-text= is a synced shared asset and does not
-self-apply. Their review named a case neither side tested, and it is a real
-defect in the shape I proposed: the relay loop breaks on rc 0, so a host that is
-reachable but has no registered signal-cli account reports success for a message
-that was never delivered. Paging is the one thing that must not fail silently,
-because the whole point is reaching Craig when he is not watching.
+From the roam inbox, Craig's words: "qt apps look huge on velox. how do we make
+it look better on this particular machine, and not change ratio. it seems they
+should have different QT configs."
+
+The shape is per-machine Qt scaling. velox is a high-DPI Framework panel and
+ratio drives ordinary-DPI monitors, so one global Qt scale factor cannot suit
+both. The fix has to be host-scoped rather than a value written into the shared
+config, which is the same tier split the dotfiles already use.
+
+Grading: Minor severity (apps work, they are just the wrong size) x every user
+every time (every Qt app launch on velox) = P2 = [#B].
+
+*** 2026-08-19 Wed @ 15:05:00 -0700 Root cause found and fixed; needs a logout to take effect
+velox's =conf.d/local.conf= scaled the panel twice. The monitor line sets
+=1.566667= and the same file exported =QT_SCALE_FACTOR,1.5= and =GDK_SCALE,1.5=,
+and Qt 6 on Wayland already takes its scale from the compositor, so the two
+multiplied. Measured rather than reasoned: with the override Qt reports a
+960x640 logical screen, without it 1440x960, and 2256/1.566667 is exactly 1440.
+That is 1.5x too large, which matches "huge" precisely.
+
+Those env lines were not careless. The comment above them explains they existed
+to compensate for =xwayland:force_zero_scaling = true= in the shared
+hyprland.conf, which makes XWayland clients render unscaled and tiny. The
+approach was what failed: an env var reaches every app, so fixing XWayland broke
+every native Wayland client. Removing the vars alone would have traded "Qt huge"
+for "Zoom tiny", so velox now turns =force_zero_scaling= off for itself instead.
+XWayland scales through the compositor there, coming out correctly sized and
+slightly soft. ratio is untouched and needs nothing, its monitor being scale 1.
+
+=force_zero_scaling= took effect on =hyprctl reload=. The env removal will not:
+Hyprland applies =env== lines with setenv at parse time and never unsets them,
+so the running compositor still hands 1.5 to everything it spawns. Craig has to
+log out and back in.
+
+*** VERIFY Is CALIBRE_OVERRIDE_DPI still needed after the scaling fix?
+The same file pins =CALIBRE_OVERRIDE_DPI,96= with the comment "calibre renders
+oversized at the 1.57 compositor scale". Calibre is a Qt app, so that was almost
+certainly this same double-scaling seen through one application and worked
+around per-app rather than at the root. With the multiplier gone, the pin is
+probably redundant and may now render calibre too small.
+
+Left in place rather than removed on a guess, since it was validated at 96 on
+2026-06-27 and calibre has its own DPI handling. Worth opening calibre after the
+next login and deciding by eye.
+
+The cursor entry in the same file records this identical failure a third time:
+"Pre-scaling it (the old 36 = 24 x 1.5) double-applied on top of the
+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]
+:LAST_REVIEWED: 2026-08-19
+:END:
 
-The fix is to verify delivery rather than trust the exit code, most likely by
-checking =signal-cli listAccounts= on the relay host before sending, or by
-treating an empty account store as a failure and continuing down the list.
+From the roam inbox, Craig's words: "waybar panels should start up collapsed.
+currently both the left and the right waybar panels launch expanded."
 
-=:blocked:= on rulesets: the change is parked awaiting Craig's approval there,
-and this defect should be corrected in the same apply rather than landing broken
-and being patched after. Their prepared diff and review are in rulesets
-=working/agent-text-relay-fallback/=.
+Panel source is =~/.dotfiles=. Its heading in the roam inbox read "archsetup."
+with a period rather than a colon, so the routing prefix did not match cleanly;
+claimed on the plain reading of the text.
 
-Two conditions from their review are theirs to carry, not mine:
-=agent-text.bats= test 2 is written for the old single-host behavior and needs a
-self-relay-skip case, and =protocols.org= "Reaching Craig" repeats the stale
-primary-on-velox claim.
+Grading: Cosmetic severity (presentation only, nothing is lost) x every user
+every time (every session start) = P3 = [#C].
 
-Grading: Major severity (a page that silently does not arrive is worse than one
-that fails loudly, and it is the channel used when Craig is away) x some users
-sometimes (only when a relay host is up but unregistered, which is exactly
-velox's current state) = P2 = [#B].
+** VERIFY [#C] The visible analog clock avoids being dragged :velox:
+:PROPERTIES:
+:CREATED: [2026-08-19 Wed]
+:LAST_REVIEWED: 2026-08-19
+:END:
+
+From the roam inbox, captured verbatim: "the visible analog clock avoids being
+dragged. ask me about this."
+
+Filed as a VERIFY because the capture asks for a conversation rather than
+describing a defect. What is the clock avoiding being dragged by, and is the
+avoidance the bug or the intended behaviour?
+
+** CANCELLED [#B] agent-text relay reports success for a message that went nowhere :bug:
+CLOSED: [2026-08-19 Wed]
+:PROPERTIES:
+:CREATED: [2026-08-19 Wed]
+:LAST_REVIEWED: 2026-08-19
+:END:
+
+Not a defect. rulesets refuted it with measurements and I reproduced theirs
+before accepting: on velox, whose account store is empty,
+=signal-cli -a +15550000000 send= exits 1 with "User +15550000000 is not
+registered", and =ssh 100.71.182.1 'exit 7'= returns 7, so a non-zero code
+propagates faithfully back through the relay. The loop's
+=[ "$rc" -eq 0 ] && break= therefore advances to the next host exactly as
+intended. signal-cli fails closed.
+
+I filed this off a conditional in their handoff — ".emacs.d raised a case
+neither of you tested ... *if* signal-cli send exits zero against an empty
+account store" — and turned the "if" into a graded [#B] with a =:blocked:= tag
+on another project, without running the one command that settles it. The
+machine that proves it was in front of me the whole time. Their ask is fair and
+I am recording it rather than the outcome alone: verify before filing a defect
+against someone else's work, especially one carrying a blocking tag.
 
 ** TODO [#C] A failed hostname lookup takes seven seconds :bug:
 :PROPERTIES:
@@ -289,27 +384,42 @@ Must be done before the Sunday flight — a phantom press mid-travel with the
 shield on is survivable, but the connector should not be trusted at 30,000
 feet on the loose setting.
 
-*** 2026-08-19 Wed @ 12:45:00 -0700 This is what stranded the machine, and the failure got worse
-The 2026-08-19 network outage traces back here. Boot -3 ended at 01:33:18 with
-no shutdown sequence at all: no power-off target, no unmounting, just a
-coredump backtrace and then nothing. The next boot's kernel line reads
-=rtc_cmos 00:01: setting system clock to 2025-01-01T00:00:16 UTC=. The RTC was
-reset to a firmware default, not drifted, and no firmware update was applied
-(=fwupdmgr get-history= is empty).
-
-That is a different and worse symptom than the phantom short-press logged
-before. Those produced =Power key pressed short= and an orderly poweroff. This
-one logged no button event and no shutdown, which reads as the board losing
-power outright rather than being asked to stop. Whether it is the same
-connector, I can't prove from the journal, but it is the same machine with a
-known loose input-cover ribbon and a battery that was not flat (100% now).
-
-Consequence, which is the part that makes this worth the [#A]: the RTC reset
-put the clock at 2025-01-01, systemd advanced it to its own build epoch of
-2026-07-23, DNSSEC rejected every signature as out-of-window, and the machine
-lost DNS entirely. Craig had to diagnose it from his phone. The NTP drop-in
-landed today makes a recurrence self-healing, but it treats the symptom. This
-task is the cause, and it is still open.
+*** 2026-08-19 Wed @ 14:40:00 -0700 Retracted: the RTC reset is not this task's, and I should not have filed it here
+I attributed the 2026-08-19 network outage to this ribbon earlier today. Craig
+pushed back — he reseated it before the trip to get the touchpad working — and
+he is right. The evidence does not support the attribution and some of it points
+the other way.
+
+What actually holds. Boot -3 ended at 01:33:18 with no shutdown sequence: no
+power-off target, no unmounting. The next boot's kernel line reads =rtc_cmos
+00:01: setting system clock to 2025-01-01T00:00:16 UTC=, a firmware default, so
+the RTC was reset rather than drifted. No firmware update was applied
+(=fwupdmgr get-history= is empty) and the battery is fine.
+
+What refutes the ribbon. This boot logged *zero* =Power key pressed= events, and
+so did the four boots before it. The phantom-press symptom had genuinely stopped
+after 08-15, exactly as the 08-16 session recorded. The earlier events logged a
+power-key press and an orderly poweroff; this logged neither, which makes it a
+different signature, not a worse version of the same one.
+
+What I got wrong methodologically: I anchored on the most salient open hardware
+task and read association as evidence. I even wrote "I can't prove it is the
+same connector" and then filed it here anyway, which is the tell.
+
+Two things I checked and can rule out. There were no OOM kills — the 3,433
+matching lines are a systemd unit named "Periodically re-score Claude Code
+processes for the OOM-killer" firing on a timer, not memory pressure, and there
+is not a single "Killed process" line. Thermal is clean; the only mentions are
+boot-time zone registration at 34C and 45C.
+
+One real thing the same window did surface, tracked separately: a python3 crash
+loop, 251 core dumps in the final ten minutes, SIGABRT with =XFreeThreads= and
+=PyEval_RestoreThread= in the trace. It does not explain the RTC, because
+software cannot clear it, but it is its own problem.
+
+The open question that would settle the RTC is for Craig, not the journal: a
+long power-button hold on a Framework triggers an EC-level reset that clears the
+RTC, which fits a wedged machine being forced off. A 4-second hold would not.
 
 *** 2026-08-17 Mon @ 19:57:42 -0700 Not done, and the two symptoms now disagree
 The reseat did not happen before the flight, and velox is travelling. The
@@ -1029,7 +1139,8 @@ Handoff from home (2026-07-25), originally combining the 2026-06-07 stale-compos
 2. On =Upgrade= of =fontconfig=, =freetype2=, or =harfbuzz=, run =/usr/bin/fc-cache -f= after the transaction. The fontconfig 2.17→2.18 cache-format change left stale cache-9 files that crashed Qt6 apps in =FcCharSetHasChar= until the system font cache was rebuilt.
 
 Acceptance: hook files are source-controlled and installed by archsetup; package/operation/action fields are asserted from the generated hook text; the reminder is print-only and exits successfully; the font hook runs only after successful matching upgrades and invokes the absolute =fc-cache= path. Validate with the fast installer tests plus a disposable pacman-hook parser/install check when practical.
-** TODO [#D] net-scenarios harness times out under back-to-back suite runs :test:tooling:
+** DONE [#D] net-scenarios harness times out under back-to-back suite runs :test:tooling:
+CLOSED: [2026-08-19 Wed]
 :PROPERTIES:
 :LAST_REVIEWED: 2026-07-24
 :END:
@@ -1046,6 +1157,24 @@ Standalone immediately after: 0.095s, all pass; the following quiet-machine
 full run was clean. Confirms the load-sensitivity read — reproduce under
 deliberate load before choosing between a bigger budget and a real hang.
 
+
+*** 2026-08-19 Wed @ 14:50:00 -0700 Root-caused and fixed: inherited stdin, not load
+Not load, and not the network. The harness stubs ssh as =cat >/dev/null=, which
+drains stdin to EOF. With no explicit stdin the stub inherits whatever the test
+runner had, so it returned instantly when stdin was redirected and blocked
+forever when it was a terminal or a live pipe. All five tests then burned their
+20-second budget.
+
+That is why it looked like a load effect: a run launched immediately after
+another inherited a different stdin than a standalone invocation. A/B measured
+today — =make test-unit </dev/null= exits 0, the same target with an open pipe
+on stdin hangs on all five. The note above guessed at "a larger timeout or a
+real hang in the script" and it was neither.
+
+Fixed by pinning =stdin=subprocess.DEVNULL= in =run_script=. Verified both ways:
+the previously-failing open-pipe case and the redirected case both pass in
+0.08s, and a full =make test-unit= under a live pipe is clean across 50 suites.
+
 ** VERIFY Should coredump entries group as one journal-digest row per binary? :maint:
 :PROPERTIES:
 :LAST_REVIEWED: 2026-07-24