chore(todo): velox reinstall runbook and the tasks it surfaced

The runbook drove today's rebuild: preflight, a required salvage pass, the install, and post-install verification. It stays as the working record until velox is settled.

Filed from the rebuild: reseating the input-cover ribbon, which is [#A] for tomorrow because phantom power-button presses have killed the machine four times and the last one cut power below systemd, where no setting can catch it. The rest are hibernate in the settings dial, a truenas VM for long-running sessions, the keyboard-backlight binding, and the screen-lock suite that fails 21 of 23 on ratio.

1 files changed, 120 insertions, 1 deletions

diff --git a/todo.org b/todo.org
index d9629ba..1757a38 100644
--- a/todo.org
+++ b/todo.org
@@ -45,7 +45,126 @@ below):
   input-side-spec.org (DRAFT, four decisions open).
 
 * Archsetup Open Work
-** TODO [#A] Move secrets out of public dotfiles → private repo + combined personal ISO :feature:security:dotfiles:
+** TODO [#A] Reseat velox input-cover ribbon — phantom power button :bug:velox:hardware:
+DEADLINE: <2026-08-14 Fri>
+:PROPERTIES:
+:CREATED: [2026-08-13 Thu]
+:LAST_REVIEWED: 2026-08-13
+:END:
+Machine off, lift the input cover (Framework QR-guided procedure, 5
+fasteners), reseat its ribbon connector to the mainboard — disturbed in the
+2026-08-13 board swap. Root cause of every "mystery reboot" that day:
+chassis flex (flash-drive touch, ethernet bump, lid partially lowered)
+fired phantom power-button presses — journalctl -b -1 showed "Power key
+pressed short." → orderly logind poweroff, then the glitching button
+powered it back on. While in there, reseat the USB expansion cards too —
+the flaky slot (two hard resets, one no-enumeration) is likely the same
+flex problem.
+THIRD SYMPTOM (2026-08-13 evening): touchpad delivers ZERO input events —
+15s synchronized libinput debug-events capture while swiping caught
+nothing, though i2c enumeration and a driver rebind handshake are clean.
+Signature of a dead interrupt line on the same ribbon. Keyboard + power
+LED lines work; BT mouse is the interim pointer.
+ESCALATED 2026-08-13 21:00: a fourth event killed the machine THROUGH the
+shield. Previous boot's journal ends mid-line (tailscaled chatter) with no
+shutdown sequence at all — a hard power cut, not logind acting. So the
+glitch now reaches the EC/hardware power path, which no software setting
+can intercept. The reseat is the only fix, and this is a
+lose-work-without-warning failure mode, not an inconvenience.
+Interim shield (already live): /etc/systemd/logind.conf.d/powerkey.conf
+sets HandlePowerKey=ignore — phantom presses log but do nothing; EC-level
+10s hold still force-cuts. Consider keeping it even after the repair.
+Verify after reseat: flex the chassis edges + partially lower the lid, then
+grep the journal for new "Power key pressed" lines — zero means fixed.
+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.
+** DOING [#A] Velox reinstall — DR test of archangel + archsetup :velox:chore:
+DEADLINE: <2026-08-15 Sat>
+:PROPERTIES:
+:CREATED: [2026-08-13 Thu]
+:LAST_REVIEWED: 2026-08-13
+:END:
+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]]
+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
+Intel assumptions.
+Finding folded in: velox's truenas backups silently stopped ~Jul 6 (newest is
+DAILY.0 Jul 6; wolf.conf.gpg from Jul 29 is in NO backup). Salvage pass in the
+runbook is therefore REQUIRED before partitioning, and the fresh install must
+fix + verify the backup timer (runbook Phase 5).
+** TODO [#B] Truenas session-host VM for long-running agent sessions :feature:tooling:
+:PROPERTIES:
+:CREATED: [2026-08-13 Thu]
+:LAST_REVIEWED: 2026-08-13
+:END:
+A small VM on truenas (TrueNAS SCALE KVM) as the home for long-running /
+away-mode agent sessions. The case, per Craig 2026-08-13: truenas is the
+only machine on ethernet, so network recovery after an outage is automatic
+(wifi hosts may never reassociate unattended); it's UPS-backed through
+blip-to-hours outages; it has the Comet KVM for out-of-band recovery; and
+appliance uptime discipline means it doesn't reboot for workstation
+reasons. Tonight's live demonstration of anchor-staleness risk (39 min
+unlogged during a bare-metal recovery) is the motivating incident — the
+session's durability equals the anchor's lag at interruption, so a host
+that doesn't get interrupted is worth real money.
+Costs to engineer around: a third environment to keep synced (repos,
+rulesets, tailnet identity); credential provisioning — GATED on the
+secrets-repo work (the [#A] secrets task above): the VM should be the
+secrets bundle's second consumer after the personal ISO, not another
+hand-copied key sprawl; a firm RAM carve-out so builds don't fight the
+ZFS ARC; headless only — desktop-coupled sessions stay on ratio/velox.
+Build deliberately AFTER the vacation, not before Sunday.
+Companion idea (cheaper, complementary): put ratio on the UPS.
+** TODO [#C] screen-lock test suite red on ratio :bug:test:dotfiles:
+:PROPERTIES:
+:CREATED: [2026-08-13 Thu]
+:LAST_REVIEWED: 2026-08-13
+:END:
+tests.screen-lock.test_screen_lock fails 21 of 23 (+1 error) on ratio,
+verified pre-existing with unrelated changes stashed (2026-08-13). Breaks
+the make test green bar for every dotfiles commit until triaged. Suspect
+environmental (the suite exercises hyprlock/relaunch behavior that may
+need session state this shell lacks) or a regression from a recent
+screen-lock commit — diagnose, then fix or mark/skip with a reason.
+Grading: Major severity (blinds the pre-commit gate for the whole repo) ×
+every-commit frequency on this machine, but test-infra only, no user
+impact = [#C] judgment call rather than matrix-dictated.
+** TODO [#C] Keyboard backlight binding + boot default :feature:dotfiles:velox:
+:PROPERTIES:
+:CREATED: [2026-08-13 Thu]
+:LAST_REVIEWED: 2026-08-13
+:END:
+Velox's kbd backlight (chromeos::kbd_backlight since the AMD board) boots
+at 0 and the dotfiles carry no keyboard-brightness keybinding at all (swept
+2026-08-13 — never existed). Add: Hyprland binds (XF86KbdBrightness* or a
+chord) driving brightnessctl -d "chromeos::kbd_backlight", a sane boot
+default, and a udev rule granting the video/input group write access so it
+works without sudo (a bare ssh session got EPERM). Check whether Fn+Space
+(EC-handled on Frameworks) already cycles it — if so the bind is a
+complement, not the only path. Ratio: n/a (desktop).
+** TODO [#B] Hibernate in the settings dial power actions :feature:dotfiles:
+:PROPERTIES:
+:CREATED: [2026-08-13 Thu]
+:LAST_REVIEWED: 2026-08-13
+:END:
+Add hibernate alongside suspend/lock in the settings module's dial power
+actions. Sequencing (Craig confirmed the dial placement 2026-08-13):
+1. Prove hibernate on velox first — systemctl hibernate through a real
+   resume; the chain (LUKS swap p3, keyfile-in-initramfs, encrypt+resume
+   hooks, resume= on the ZBM cmdline) went live with the 2026-08-13
+   reinstall but is untested on this AMD board.
+2. Then consider suspend-then-hibernate as the default lid behavior
+   (systemd sleep.conf HibernateDelaySec) — hibernate's savings with no
+   button at all; possibly a "deep sleep" toggle in the module.
+3. Then the dial action itself.
+Note: ratio has no swap partition, so hibernate stays velox-only until
+ratio gets one; the dial entry should degrade gracefully where there's no
+resume target.
 :PROPERTIES:
 :CREATED: [2026-08-11 Tue]
 :LAST_REVIEWED: 2026-08-11