Monorepo for Aesthetic.Computer aesthetic.computer

menuband: 1.5.4 (155) — five bugs found by running the shipped store build master

First post-launch patch. Notably, three of these exist ONLY in the sandboxed build, so testing the direct-download app would never have surfaced them. 1. It never came back after a reboot. There was no login-item code at all: the DMG build auto-starts from a LaunchAgent install.sh writes, and a sandboxed app cannot install one. New MenuBandLoginItem (#if MAC_APP_STORE) uses SMAppService.mainApp, reconciled every launch, default on (parity with the LaunchAgent) with an 'Open at Login' toggle in About. SMAppService is 13+, so it's #available-gated and the toggle hides on macOS 11-12. 2. The instrument-palette 'down arrow' was never a control — a 11pt/55%-alpha 'v' CHARACTER in the readout's attributed title. And the button IS a HoverLinkButton, but its hover colors were never set and it isn't layer-backed, so applyState(hovered:) ran and did nothing: hover was a dead code path. Chevron to 15pt, brighter on hover, plus an onHoverChange hook and a separate rounded backdrop that fades in behind the name — a real hover pill WITHOUT layer-backing the text, which would rasterize away its 1px Riso shadow. 3. Haptics is trackpad Force Touch, not controller haptics — but its switch was wedged into the keymap overlay's instrument title row, so foreign there that a constraint width-matched the instrument NUMBER label to it just to keep the name optically centered. Switch, label, info button and the width hack are all gone; haptics is simply always on, gated by MenuBandHaptics.isAvailable. 4. The expanded keymap opened top-left on a fresh install: expandedFrame resolved savedExpandedOrigin ?? fallbackOrigin ?? centeredOrigin, and with no saved origin it fell to the freshly-built panel's origin and never reached centering. Opening now always centers; an in-place refit keeps its position (hence the explicit origin parameter). 5. Tips opened the menuband.app website. install.sh copies+indexes+signs MenuBand.help for the DMG, but project.yml never copied it — so in the store build TipsWindow's local-book lookup missed and hit its web fallback. Both plists already declared CFBundleHelpBookFolder/Name, pointing at a folder that wasn't there. The book is now a MAS resource with an 'Index Help Book' postBuildScript running hiutil (verified: runs before CodeSign, so the index is signed in), and openTips() prefers the real Help Viewer, falling back to the in-app window only if Help Viewer doesn't come up — it can silently no-op for an LSUIElement app and showHelp reports nothing back. The web fallback is gone. Verified: swift build (direct-download) and xcodebuild Release (MAS) both compile clean; the built .app carries 1.5.4 (155) with Contents/Resources/MenuBand.help and a generated search.helpindex. Not yet verified (needs a signed/installed build): that Help Viewer actually opens for this LSUIElement app, that SMAppService survives a real reboot, and the visual result of the hover/centering changes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>