chore(tasks): close the velox reinstall drill and the lock-clock bug

The reinstall drill finished on 2026-08-14 and every finding it surfaced already has its own task, so what remained was the record. I filed its working-dir artifacts into permanent homes. The runbook went to docs/ with an Outcome section, since the checklist was never ticked as it ran. The UEFI boot-entry reference went to docs/ too. The three reinstall-gap reports went to docs/design/. The rescued wttrin bundle moved into its own working dir under the task that owns it. Every inbound link is repointed and working/velox-reinstall/ is gone.

The lock-screen clock bug is closed because it no longer happens on velox. I couldn't identify the commit that fixed it from the dotfiles or archsetup logs, and the note says so. Its manual-testing check retires with it.

1 files changed, 36 insertions, 46 deletions

diff --git a/todo.org b/todo.org
index 598ed47..a54ff66 100644
--- a/todo.org
+++ b/todo.org
@@ -223,8 +223,8 @@ to read file" on stderr and nothing on stdout; piped into =grep -c=, that
 empty stdout reads as 0 and looks like a missing module. The gate has to
 run as root and check the exit status, not just the count.
 
-** TODO [#A] Lock-screen clock stale after a real sleep :bug:hyprland:dotfiles:velox:
-SCHEDULED: <2026-08-25 Tue>
+** DONE [#A] Lock-screen clock stale after a real sleep :bug:hyprland:dotfiles:velox:
+CLOSED: [2026-09-13 Sun] SCHEDULED: <2026-08-25 Tue>
 :PROPERTIES:
 :CREATED: [2026-08-25 Tue]
 :LAST_REVIEWED: 2026-08-25
@@ -248,6 +248,13 @@ different fix: stale-then-corrects → repaint interval; frozen with live input
 → clock rendering; frozen with dead input → hyprlock hung, a crash/hang
 recovery bug the =screen-lock= watchdog doesn't cover.
 
+*** 2026-09-13 Sun @ 07:57:04 -0500 Closed: fixed, per Craig
+Craig confirmed on 2026-09-13 Sun that the stale clock after a real sleep is fixed on
+velox. I could not identify the commit from here (nothing in the dotfiles
+or archsetup log since 2026-08-24 names hyprlock, the lock clock, sleep or
+resume), so this closes on his report rather than a cited change; the
+manual-testing check for it is retired with it.
+
 ** TODO [#C] post-rebuild-check: probe that Emacs frames come up Wayland-native :feature:emacs:velox:solo:quick:
 :PROPERTIES:
 :CREATED: [2026-08-25 Tue]
@@ -495,8 +502,8 @@ Alternatives if it drags on: change Signal's tray setting so it keeps a
 window (=~/.config/Signal/ephemeral.json= =system-tray-setting=), or run a
 waybar carrying the #5240 fallback.
 
-** DOING [#A] Velox reinstall — DR test of archangel + archsetup :velox:chore:
-DEADLINE: <2026-08-15 Sat>
+** DONE [#A] Velox reinstall — DR test of archangel + archsetup :velox:chore:
+CLOSED: [2026-09-13 Sun] DEADLINE: <2026-08-15 Sat>
 :PROPERTIES:
 :CREATED: [2026-08-13 Thu]
 :LAST_REVIEWED: 2026-08-13
@@ -504,7 +511,7 @@ DEADLINE: <2026-08-15 Sat>
 Mainboard swapped Intel→AMD (Ryzen AI 9 HX 370); new NVRAM has no boot entry.
 Decision: full reinstall via archangel+archsetup, run deliberately as a
 disaster-recovery drill before the Sunday flight. Runbook (live checklist):
-[[file:working/velox-reinstall/velox-reinstall-runbook.org][working/velox-reinstall/velox-reinstall-runbook.org]]
+[[file:docs/2026-08-13-velox-reinstall-runbook.org][docs/2026-08-13-velox-reinstall-runbook.org]]
 Done 2026-08-13: ISO rebuilt (archangel-2026-08-13, archsetup baked with AMD
 microcode detection, velox profiles at /root/, .ai/inbox excluded — build.sh
 edits pending commit in archangel), contents verified, dotfiles swept clean of
@@ -526,6 +533,17 @@ listeners on 5357 and 27500. Same pass fast-forwarded velox's dotfiles to
 f56fd1a and archsetup to dc00a62, and confirmed the headless Proton Bridge
 service is still disabled there.
 
+*** 2026-09-13 Sun @ 07:56:37 -0500 Closed the drill and filed its working-dir artifacts
+The reinstall itself finished on 2026-08-14; every finding it surfaced is
+its own task, and the live convergence steps landed on 2026-09-13, so nothing
+was left in this task but the record. Filed per the working-files
+convention: the runbook to docs/2026-08-13-velox-reinstall-runbook.org (with
+an Outcome section, since the checklist was never ticked during the run),
+the boot-entry reference to docs/2026-08-15-velox-uefi-boot-entry-reference.org,
+the three gap reports to docs/design/2026-08-14-velox-reinstall-gaps-1 to 3,
+and the wttrin bundle to working/emacs-wttrin-rescue/ under the task that
+owns it. working/velox-reinstall/ is gone and every inbound link repointed.
+
 ** TODO [#B] Truenas session-host VM for long-running agent sessions :feature:tooling:
 :PROPERTIES:
 :CREATED: [2026-08-13 Thu]
@@ -791,9 +809,9 @@ paging, and because the flight is Sunday.
 
 *** 2026-09-13 Sun @ 07:14:54 -0500 Moved the three gap reports into the reinstall working dir
 The 2026-08-14 reports that define the five gaps moved out of inbox/ into
-[[file:working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-1.org][gaps 1-4]],
-[[file:working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-2.org][gap 5]] and
-[[file:working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-3.org][the two email-side gaps]] (the Bridge cert and the Bridge password).
+[[file:docs/design/2026-08-14-velox-reinstall-gaps-1.org][gaps 1-4]],
+[[file:docs/design/2026-08-14-velox-reinstall-gaps-2.org][gap 5]] and
+[[file:docs/design/2026-08-14-velox-reinstall-gaps-3.org][the two email-side gaps]] (the Bridge cert and the Bridge password).
 They file with the rest of the reinstall artifacts when that task closes.
 
 ** TODO [#B] Restoring a git repo from backup can resurrect a dangerous diff :bug:
@@ -864,7 +882,7 @@ bf0457f "feat: add wttrin-hide-follow-line to hide the wttr.in follow line"
 (2026-06-24) was the only genuinely unpushed commit anywhere on the old
 velox — 3 files, 103 insertions, with a test file. Rescued as a verified
 git bundle before the disk was wiped:
-[[file:working/velox-reinstall/wttrin-bf0457f.bundle][working/velox-reinstall/wttrin-bf0457f.bundle]]
+[[file:working/emacs-wttrin-rescue/wttrin-bf0457f.bundle][working/emacs-wttrin-rescue/wttrin-bf0457f.bundle]]
 To land it: clone emacs-wttrin, =git fetch <bundle> --branches=, review the
 commit, then push to git@cjennings.net:emacs-wttrin.git. Delete the bundle
 once it's on the remote.
@@ -874,11 +892,11 @@ Cloned the remote bare and asked it for the object directly: =git cat-file -t
 bf0457f= returns "Not a valid object name", so the commit has never reached
 =git@cjennings.net:emacs-wttrin.git=. Remote =main= is =ee8fdeb=.
 
-That makes =working/velox-reinstall/wttrin-bf0457f.bundle= the sole surviving
+That makes =working/emacs-wttrin-rescue/wttrin-bf0457f.bundle= (moved there 2026-09-13 when the reinstall task filed its artifacts) the sole surviving
 copy of 103 insertions across three files, on one laptop that is travelling.
-Worth doing sooner than its =[#B]= suggests for that reason alone, and it also
-pins the working directory open — the reinstall task cannot file its artifacts
-away while this bundle is still load-bearing.
+Worth doing sooner than its =[#B]= suggests for that reason alone. It also
+pinned the reinstall working directory open until 2026-09-13, when the bundle
+moved into its own working dir here and the reinstall task closed.
 ** TODO [#B] archsetup doesn't clone rulesets :bug:velox:
 DEADLINE: <2026-08-15 Sat>
 :PROPERTIES:
@@ -2375,38 +2393,10 @@ fi
 Expected: "stays gone". If it regenerates, Hyprland is still resolving its config
 to the .conf path and the port is not actually live — stop and investigate.
 
-*** Lock screen after a real sleep: is the clock frozen, or is all of hyprlock frozen?
-What we're verifying: which of two very different faults produces the stale
-lock-screen clock Craig sees after waking the machine. Three isolated tests on
-2026-08-24 all failed to reproduce it — hyprlock v0.9.6 repainted correctly
-within one second of a display power-cycle, of a three-minute SIGSTOP, and of
-both together with the =path = screenshot= background. So the cause needs a real
-suspend on real AMD hardware, which only Craig can run.
-
-The distinguishing question is whether *anything* on the lock screen is alive.
-A frozen clock with live input is a rendering bug in the clock. A frozen clock
-with dead input means hyprlock is hung and the compositor is simply holding its
-last pre-suspend frame — a different bug, in the crash/hang recovery layer.
-
-Run this the next time the machine has actually slept (30 min idle, or a lid
-close), not on a screen you just locked by hand.
-
-- Wake the machine and do NOT type your password yet.
-- Read the clock. Note the time it shows and the real time.
-- Type one character into the password field.
-Expected (record which): either the dots appear normally — input is alive, only
-the clock is stale — or nothing appears at all, in which case hyprlock is hung.
-- Keep watching for a full 90 seconds without touching anything else.
-Expected (record which): the clock corrects itself to the current time within a
-minute, or it never changes at all.
-- Note whether the blurred background looks like your desktop or like a
-  previous lock screen (a lock screen photographed behind a lock screen means a
-  second hyprlock was started on top of the first).
-
-Expected: enough to pick one of three — stale-then-corrects (a repaint-interval
-fix), frozen-with-live-input (a rendering fix), or frozen-with-dead-input
-(hyprlock hung; the =screen-lock= watchdog only catches a hyprlock that
-*exits*, and its own header says it is blind to one that hangs).
+*** 2026-09-13 Sun @ 07:57:32 -0500 Retired the lock-screen clock check: fixed, per Craig
+Craig reported on 2026-09-13 Sun that the stale clock after a real sleep no longer
+happens on velox, so the three-outcome check never needed running. The
+parent bug task is closed with the same note.
 
 *** Lock keybind has no crash or hang recovery
 What we're verifying: that a hand-lock is as recoverable as an idle lock.
@@ -3659,7 +3649,7 @@ than it looked when it was filed sight-unseen; still worth doing (unlisted
 fixes happen, and ACPI tables change), just no longer the front-runner.
 Deliberately deferred past the flight — a cleared NVRAM is the failure that
 started this whole rebuild. Boot-entry recovery reference captured at
-[[file:working/velox-reinstall/velox-uefi-boot-entry-reference.org][working/velox-reinstall/velox-uefi-boot-entry-reference.org]].
+[[file:docs/2026-08-15-velox-uefi-boot-entry-reference.org][docs/2026-08-15-velox-uefi-boot-entry-reference.org]].
 
 Order of attack on return, cheapest first: reseat the touchpad's *own* press
 connector at the mainboard (free, untried) → BIOS 04.02 → fit the replacement