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, 0 insertions, 108 deletions

diff --git a/working/velox-reinstall/velox-uefi-boot-entry-reference.org b/working/velox-reinstall/velox-uefi-boot-entry-reference.org
deleted file mode 100644
index 53e6511..0000000
--- a/working/velox-reinstall/velox-uefi-boot-entry-reference.org
+++ /dev/null
@@ -1,108 +0,0 @@
-#+TITLE: Velox UEFI Boot Entry — Recovery Reference
-#+AUTHOR: Craig Jennings
-#+DATE: 2026-08-15
-
-Captured 2026-08-15 before a BIOS update (03.05 → 04.02) as insurance against
-the update clearing NVRAM. Velox's mainboard swap on 2026-08-13 left exactly
-this kind of empty NVRAM, which is what forced the reinstall — so a cleared
-boot entry is the specific failure worth being able to undo in one command
-rather than reconstruct.
-
-* Before recreating anything: check Secure Boot first
-
-The 04.02 update landed on 2026-09-12 (staged via fwupd, flashed on the next
-reboot). It did NOT clear NVRAM: Boot0001 survived with its command line
-intact. What it did was re-enable Secure Boot (Enforce Secure Boot =
-Enabled), so the unsigned ZBM loader was rejected and the Framework BIOS
-reported it as "Default Boot Device Missing / no bootable drive" rather than
-a security violation. The symptom is indistinguishable from the NVRAM wipe
-this document was written for.
-
-The tell: booting the Ventoy stick shows shim's MOK management screen.
-
-Fix: F2 → Security → Secure Boot → Enforce Secure Boot = Disabled, F10. The
-machine then boots straight into ZBM. No efibootmgr needed.
-
-So when velox says no bootable device after a firmware update, check Secure
-Boot before touching the boot entries. Only if Secure Boot is already off
-and =efibootmgr -v= (from the stick) shows Boot0001 gone does the recreate
-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]]
-(Phase 3) carries the steps.
-
-Still open: velox's ESP has no removable-media fallback (=/efi/EFI/BOOT=
-does not exist), so a real NVRAM wipe would still need the stick. Copying
-=zfsbootmenu.efi= to =/efi/EFI/BOOT/BOOTX64.EFI= would let it boot unaided.
-That belongs to archangel's ZBM install, where it is filed as [#C]
-"Installed systems have no removable-media boot fallback on the ESP"
-(2026-09-12) and ships with the next ISO rebuild after it lands.
-
-* State at capture
-
-- BIOS: 03.05 (2025-10-30)
-- BootCurrent: 0001
-- BootOrder: 2001,0001,2002,2003  (USB ahead of ZBM — why the Ventoy stick
-  boots when it's inserted)
-- Timeout: 0 seconds
-
-* The entry that matters
-
-=Boot0001* ZFSBootMenu=
-
-| field          | value                                        |
-|----------------+----------------------------------------------|
-| ESP part GUID  | 8e51b680-f90a-444f-8da5-7e4f93625775          |
-|----------------+----------------------------------------------|
-| partition      | 1 (GPT), start 0x800, size 0x100000           |
-|----------------+----------------------------------------------|
-| loader path    | =\EFI\ZBM\zfsbootmenu.efi=                    |
-|----------------+----------------------------------------------|
-| cmdline (data) | =spl_hostid=0x22f8a7a1 zbm.timeout=3=         |
-|                | =zbm.prefer=zroot zbm.import_policy=hostid=   |
-|----------------+----------------------------------------------|
-
-The =data= field is that command line in UTF-16LE, which is how efibootmgr
-passes it as optional data. Recreate with =-u= and the plain string; efibootmgr
-does the encoding.
-
-* Recreating it
-
-From a booted system (or the archangel ISO), with the ESP identified as
-=/dev/nvme0n1p1= or whatever it enumerates as:
-
-#+begin_src bash
-efibootmgr --create \
-  --disk /dev/nvme0n1 --part 1 \
-  --label "ZFSBootMenu" \
-  --loader '\EFI\ZBM\zfsbootmenu.efi' \
-  --unicode 'spl_hostid=0x22f8a7a1 zbm.timeout=3 zbm.prefer=zroot zbm.import_policy=hostid'
-#+end_src
-
-Confirm the disk/part against =lsblk -o NAME,PARTUUID,PARTTYPENAME= first —
-the partition GUID above is the authoritative identifier, not the device name,
-which can enumerate differently.
-
-Then set the order so ZBM is reachable:
-
-#+begin_src bash
-efibootmgr --bootorder 0001,2001,2002,2003
-#+end_src
-
-(The original order put USB first. Keep whichever you prefer; what matters is
-that the ZBM entry exists and is in the list.)
-
-* Other entries (firmware-generated, recreate themselves)
-
-| Boot2001 | EFI USB Device |
-|----------+----------------|
-| Boot2002 | EFI DVD/CDROM  |
-|----------+----------------|
-| Boot2003 | EFI Network    |
-|----------+----------------|
-
-These are stock firmware entries and come back on their own. Only Boot0001
-carries anything unique.