fix(brew): replace invalid brew tap --trust with brew tap + brew trust

[castrojo]

Problem

brew tap --trust <owner>/<tap> is invalid syntax. --trust has never been a valid flag on brew tap. On Homebrew 6.0+, brew tap rejects the unknown flag and exits non-zero before doing anything, so ujust devmode and several app installers are broken as shipped.

The correct interface (docs.brew.sh/Tap-Trust) is two commands: brew tap then brew trust.

Changes

Five call sites fixed — one more than #814 listed:

File	Recipe
system_files/shared/.../just/apps.just:12	install-jetbrains-toolbox
system_files/shared/.../just/apps.just:63	install-asus (under set -euo pipefail)
system_files/bluefin/.../just/system.just:149,152	toggle-devmode
system_files/bluefin/usr/libexec/bazaar-hook:34	spawn_brew — not in the original report

bbrew/cncf were checked: no bbrew recipe exists in system_files/ anymore, and cncf uses brew bundle with trusted: true Brewfiles, which is already correct.

Docs: docs/skills/brew-lifecycle.md actively taught the bug in a diff block (+ brew tap --trust); reversed and corrected, along with a stale note in oem-hardware-hooks.md.

Tests

tests/test_brew_tap_trust.bats — 7 tests. The brew mock rejects unknown flags on tap exactly as Homebrew 6.0 does, and the real recipes are driven via just --justfile.

• Against this fix: 7/7 pass
• Against pre-fix code: 6/7 fail — genuine regression coverage, not tests fitted to the change

Reviewer note — one judgment call

bazaar-hook changed && to ; between tap and install. With &&, a user who already has the tap gets a non-zero exit from brew tap and the cask install silently never runs. This is a behavior change beyond the literal flag fix — say the word if you'd rather keep &&.

Blast radius

system_files/shared/ → bluefin + bluefin-lts + dakota.

Closes #814

---

Branch state

Merged main at 3de8c769 after #926 landed. The only collision was a
one-line conflict in the docs/TESTING.md test table — both PRs append a row.
Resolved by keeping both rows; Justfile auto-merged.

Re-verified after that merge: test_brew_tap_trust.bats 7/7 pass and
test_theming_hook.bats (from #926) 5/5 pass.

The 6/7-fail-on-pre-fix-code claim above was re-confirmed independently by
checking out origin/main's system_files/ under this branch's tests.

[clubanderson]

One concern: || true suppresses brew trust failures as well as idempotent tap errors. If trust fails, the recipe continues to install from an untrusted tap and hides the actionable error. Prefer guarding only the expected already-tapped case, or verify trust before continuing.

[hanthor]

Approving — the core fix is correct and I verified it against real Homebrew rather than from the docs alone. Two notes, one of which answers your reviewer question directly.

Premise confirmed. On Homebrew 6.0.15 locally:

• brew tap --trust → Usage: brew tap [options] [user/repo] [URL], i.e. a hard usage error before doing anything. The bug is real and exactly as described.
• brew trust exists, and bare brew trust <owner>/<tap> parses fine without needing --tap (matches docs.brew.sh/Tap-Trust). The two-command replacement is right.

Nice catch on the fifth call site in bazaar-hook — that one wasn't in #814.

---

Your judgment call on && → ; in bazaar-hook: I'd keep &&. The rationale in the PR body doesn't hold empirically. Re-tapping an already-tapped repo exits 0, not non-zero:

$ brew tap charmbracelet/tap   # already tapped
$ echo $?
0

brew trust is idempotent the same way — Already trusted tap: charmbracelet/tap, exit 0. So the "user who already has the tap gets a non-zero exit and the cask install silently never runs" failure mode doesn't occur, and && was never unsafe here.

Switching to ; costs something real: this runs detached in xdg-terminal-exec, so if the tap genuinely fails (network, renamed tap), ; marches on and the user gets a cascade of confusing errors in a terminal that may close before they can read it. && stops at the actual cause. Suggest reverting that hunk to:

f'{brew} tap ublue-os/tap && {brew} trust ublue-os/tap && {brew} install --cask {app}'

Same reasoning for 2>/dev/null || true in apps.just / system.just. Since both commands already exit 0 on the repeat-invocation path, the suppression isn't buying idempotency — it's only hiding genuine failures. In install-asus in particular, the recipe runs under set -euo pipefail specifically so failures surface, and || true opts these two lines out of that; the user then hits brew install --cask against an untrusted tap and gets an error that points at the wrong thing. I'd drop at least the 2>/dev/null so the real message survives:

brew tap ublue-os/tap
brew trust ublue-os/tap

Neither point is blocking — the PR is a strict improvement over shipped-and-broken either way, and the bats coverage (7/7 pass, 6/7 fail pre-fix) is genuinely load-bearing rather than fitted. Note the mock always exits 0 for a well-formed brew tap, so it happens to model the real semantics correctly and doesn't bake in the non-zero assumption.

One housekeeping item: this is currently DIRTY — it conflicts with main (and with #942/#943, which also touch Justfile and docs/TESTING.md). Needs a rebase before it can merge regardless of the above.