feat(doctor): catch a Touch Bar module that failed to load

[phmatray]

Why

A Touch Bar module that fails to load is the one macarchy breakage nothing reports. The daemon logs module <id> failed to load: <exc> once, then runs happily without that widget: the unit stays active, macarchy-doctor.service fires no toast, and the bar simply lacks a button.

It is what a rename in macarchy-touchbar costs every other repo that ships a module. Installed modules are COPIES, so the macarchy-dfr → macarchy-touchbar rename left ~/.config/omarchy/plugins/macarchy.jarvis/touchbar.py importing macarchy_dfr:

22:29:40  module macarchy.jarvis failed to load: ModuleNotFoundError("No module named 'macarchy_dfr'")

Jarvis was off the bar for an hour with every other check green.

Why not in migrate_legacy

The obvious fix — re-run the owning repo's install.sh after a migration — does not belong here. jarvis is not in REPOS; this script neither clones nor manages it, and reinstalling a repo it does not own would be an inverted dependency that still only covered Jarvis. The doctor reports it instead: by module id, from any repo, for every future rename.

The subtle part

The daemon hot-reloads on the file change, so a failure can be repaired later in the same boot — only the last word on each module counts. Otherwise the doctor would still be crying about a module that came back at 23:30:05. That is case (b) of the new suite, and it is the assertion that matters.

Test

tests/test_doctor_touchbar_modules.sh, hermetic (temp HOME + PATH stubs, journalctl replays a fixture):

• (a) failed and never repaired → MISS naming the module, pointing at the fix
• (b) failed then hot-reloaded in the same boot → not a miss
• (c) healthy boot, including a module with no widgets → loaded
• (d) empty journal → not a miss

Full suite 3/3, bash -n clean on install.sh / boot.sh / doctor.sh, and the real doctor on the affected laptop now prints ok Touch Bar modules loaded.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SYBhT1xfp3MQ1w3687F4Mp

[phmatray]

install (clean machine) is red — pre-existing, not from this PR

Identical failure on main, byte for byte:

MISS failed user units: macarchy-auto-appearance.service macarchy-bar-contrast.service macos-dynamic-wallpaper.service
MISS dynamic wallpaper config: macos-dynamic-wallpaper: wallpaper not found: .../apple-glass/26-tahoe-beach-day.jpg

The workflow has failed on the last 5 runs of main (6a931b1, 1510f6d, 4f10635, 8fdab67, b6ee2ad) — it was already red before this branch existed.

This PR's own check never runs on CI: it sits inside the WAYLAND_DISPLAY block, which the runner reports as skip running-now checks (no Hyprland session). The tests workflow, which does cover it, is green.

Worth its own issue: clean machine has been red long enough to stop being a gate.