fix(velox): trace the dead touchpad to its own connector, and repair two lost todo headings

The touchpad fault was an interrupt line that never fired: the device
enumerated, hid-multitouch bound, and the handler sat correctly on amd_gpio
pin 8, but the count stayed at zero across all 24 CPUs under active use and
the i2c-HID reset timed out at every boot. A live USB reproduced it exactly,
which ruled out software. The fix was the touchpad's own connector — the
input-cover ribbon I reseated first fixed the phantom power button and left
this untouched, and the 4-pin connector beside the silkscreen is GND and VCC
only, so it could never have carried i2c. Both faults from the mainboard swap
are now closed.

Two task headings had been overwritten by inserts at the top of Open Work, and
I recovered both verbatim from the commits that introduced them. One displaced
task had ridden an archived parent into Resolved, so an open bug had been
sitting outside Open Work for weeks.

Filed the install placeholder passwords still live on this laptop as an [#A],
graded on severity alone rather than the frequency matrix: full-disk encryption
protected by a dictionary word does no work at all on a machine that travels.

Corrected the ARCHSETUP_DIR line in the reinstall runbook. It carried a tilde on
the right-hand side of an assignment, which zsh does not expand, so following it
would have produced an ISO with the installer silently absent.

3 files changed, 83 insertions, 1 deletions

diff --git a/working/velox-reinstall/velox-reinstall-runbook.org b/working/velox-reinstall/velox-reinstall-runbook.org
index 02671e2..0c14946 100644
--- a/working/velox-reinstall/velox-reinstall-runbook.org
+++ b/working/velox-reinstall/velox-reinstall-runbook.org
@@ -22,8 +22,15 @@ Fallback ordering if the test finds a real gap:
   the microcode vendor-detection fix (archsetup, 2026-08-08) and was built
   without ARCHSETUP_DIR at all.
   #+begin_src sh
-  cd ~/code/archangel && sudo ARCHSETUP_DIR=~/code/archsetup ./build.sh
+  cd ~/code/archangel && sudo ARCHSETUP_DIR="$HOME/code/archsetup" ./build.sh
   #+end_src
+  Two traps in that one line, and either alone silently produces a bare ISO
+  with archsetup absent (archangel, 2026-08-20). The =VAR=value= form is
+  required because sudo's =env_reset= discards an exported variable. And
+  =$HOME= is required because zsh does not expand a tilde on the right-hand
+  side of an assignment — the earlier =ARCHSETUP_DIR=~/code/archsetup= here
+  passed the literal string. build.sh now warns and reports baked/not-baked
+  in its closing summary, so the failure is visible rather than silent.
 - [ ] build.sh fixes before the final rebuild (archangel repo):
   - rsync exclude for =.ai= (keeps =archsetup/.ai/private-design/= — the
     credential audit — off the portable USB stick).
diff --git a/working/velox-reinstall/velox-uefi-boot-entry-reference.org b/working/velox-reinstall/velox-uefi-boot-entry-reference.org
new file mode 100644
index 0000000..8d677da
--- /dev/null
+++ b/working/velox-reinstall/velox-uefi-boot-entry-reference.org
@@ -0,0 +1,75 @@
+#+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.
+
+* 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.
diff --git a/working/velox-touchpad-interrupt/touchpad-module-underside-2026-08-15.jpg b/working/velox-touchpad-interrupt/touchpad-module-underside-2026-08-15.jpg
new file mode 100644
index 0000000..40c71af
--- /dev/null
+++ b/working/velox-touchpad-interrupt/touchpad-module-underside-2026-08-15.jpg