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.

8 files changed, 64 insertions, 51 deletions

diff --git a/working/velox-reinstall/velox-reinstall-runbook.org b/docs/2026-08-13-velox-reinstall-runbook.org
index 0c14946..2d99fc9 100644
--- a/working/velox-reinstall/velox-reinstall-runbook.org
+++ b/docs/2026-08-13-velox-reinstall-runbook.org
@@ -9,6 +9,29 @@ pool. Decision: full reinstall via archangel + archsetup, run deliberately as
 a disaster-recovery test of the ISO and scripts before the Sunday flight.
 Recent backup in hand; ratio available as the working machine.
 
+* Outcome (recorded 2026-09-13 Sun)
+
+The drill ran on 2026-08-13 and 14 and velox came back as a working daily
+driver: fresh install from the archangel ISO, keys and data restored from
+the salvage backup, 23 repos re-cloned, rsyncshot reinstalled, hibernate
+proven end to end. The checklist below was the live plan; it was not ticked
+as the phases ran, so read it as the plan, not a log of each step.
+
+What the drill found, each filed as its own task rather than fixed in place:
+velox's truenas backups had silently stopped on 2026-07-06 (found on 08-13
+before partitioning, which is what made the salvage pass required); four phantom
+reboots were a ribbon disturbed by the board swap; a fresh install never
+clones rulesets, never links the .emacs.d systemd user units, ships no
+brightness udev rule, and loses gcalcli and the signal-cli registration.
+Those live in archsetup's todo as the post-rebuild verification pass and its
+siblings. The one commit that existed only on the old disk (emacs-wttrin
+bf0457f) was rescued as a bundle and has its own task.
+
+Companion documents: the UEFI boot-entry recovery reference
+([[file:2026-08-15-velox-uefi-boot-entry-reference.org][2026-08-15-velox-uefi-boot-entry-reference.org]])
+and the three gap reports under docs/design (2026-08-14-velox-reinstall-gaps-1
+to 3).
+
 Fallback ordering if the test finds a real gap:
 - Before partitioning starts: the old system is intact — the ZBM repair
   route (efibootmgr entry pointing at the ZBM loader on the ESP, then
diff --git a/working/velox-reinstall/velox-uefi-boot-entry-reference.org b/docs/2026-08-15-velox-uefi-boot-entry-reference.org
index 53e6511..1eacfe5 100644
--- a/working/velox-reinstall/velox-uefi-boot-entry-reference.org
+++ b/docs/2026-08-15-velox-uefi-boot-entry-reference.org
@@ -31,7 +31,7 @@ below apply.
 Before any future firmware update, record both =efibootmgr -v= and the
 Secure Boot state so the post-reboot diagnosis is a comparison, not a guess.
 The pre-firmware-update checklist in
-[[file:../../docs/workflows/system-health-check.org][docs/workflows/system-health-check.org]]
+[[file:workflows/system-health-check.org][docs/workflows/system-health-check.org]]
 (Phase 3) carries the steps.
 
 Still open: velox's ESP has no removable-media fallback (=/efi/EFI/BOOT=
diff --git a/working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-1.org b/docs/design/2026-08-14-velox-reinstall-gaps-1.org
index cf0d723..cf0d723 100644
--- a/working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-1.org
+++ b/docs/design/2026-08-14-velox-reinstall-gaps-1.org
diff --git a/working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-2.org b/docs/design/2026-08-14-velox-reinstall-gaps-2.org
index 27f0da8..95842ac 100644
--- a/working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-2.org
+++ b/docs/design/2026-08-14-velox-reinstall-gaps-2.org
@@ -4,7 +4,7 @@
 * Follow-up to this morning's handoff
 
 Sent you four gaps an hour ago
-([[file:2026-08-14-emacsd-velox-reinstall-gaps-1.org][the first report]]). Here is a fifth,
+([[file:2026-08-14-velox-reinstall-gaps-1.org][the first report]]). Here is a fifth,
 found straight afterwards when I noticed calendar sync was dead on velox.
 
 * What was broken
diff --git a/working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-3.org b/docs/design/2026-08-14-velox-reinstall-gaps-3.org
index 0df4d75..9675973 100644
--- a/working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-3.org
+++ b/docs/design/2026-08-14-velox-reinstall-gaps-3.org
@@ -4,8 +4,8 @@
 * Third handoff today
 
 Two earlier notes covered five gaps
-([[file:2026-08-14-emacsd-velox-reinstall-gaps-1.org][the first report]] and
-[[file:2026-08-14-emacsd-velox-reinstall-gaps-2.org][the follow-up]]).
+([[file:2026-08-14-velox-reinstall-gaps-1.org][the first report]] and
+[[file:2026-08-14-velox-reinstall-gaps-2.org][the follow-up]]).
 Email was the last thing broken on velox after the 2026-08-13 rebuild, and it
 turned up two more — both the same shape, and one of them with a property worth
 generalizing.
diff --git a/docs/workflows/system-health-check.org b/docs/workflows/system-health-check.org
index 37c1932..43aeff5 100644
--- a/docs/workflows/system-health-check.org
+++ b/docs/workflows/system-health-check.org
@@ -244,7 +244,7 @@ Firmware stays a manual step (=topgrade.toml= keeps =[firmware] upgrade = false=
 1. =sudo efibootmgr -v= — every boot entry with its loader path and command line, pasted into the session's context file.
 2. Secure Boot state — =bootctl status 2>/dev/null | grep -i 'secure boot'=.
 
-After the flash, if the machine reports no bootable device, check Secure Boot *first*. The Framework 04.02 update on velox re-enabled it, which rejects the unsigned ZFSBootMenu loader and reads as "Default Boot Device Missing" rather than a security violation; the boot entries were untouched (see the Known Issues Log, 2026-09-12). Only when Secure Boot is off and =efibootmgr -v= from a stick shows the entry gone does the boot-entry recreate apply (velox: =working/velox-reinstall/velox-uefi-boot-entry-reference.org= in archsetup).
+After the flash, if the machine reports no bootable device, check Secure Boot *first*. The Framework 04.02 update on velox re-enabled it, which rejects the unsigned ZFSBootMenu loader and reads as "Default Boot Device Missing" rather than a security violation; the boot entries were untouched (see the Known Issues Log, 2026-09-12). Only when Secure Boot is off and =efibootmgr -v= from a stick shows the entry gone does the boot-entry recreate apply (velox: =docs/2026-08-15-velox-uefi-boot-entry-reference.org= in archsetup).
 
 *** Two-Stage Reboot Pattern (MANDATORY if Phase 3 installed kernel / iproute2 / systemd / NetworkManager)
 
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
diff --git a/working/velox-reinstall/wttrin-bf0457f.bundle b/working/emacs-wttrin-rescue/wttrin-bf0457f.bundle
index 5921866..5921866 100644
--- a/working/velox-reinstall/wttrin-bf0457f.bundle
+++ b/working/emacs-wttrin-rescue/wttrin-bf0457f.bundle