[dtg01100]

Summary for newcomers

On a fresh Bluefin install on Framework hardware, the OEM brew hook should pull in the Framework wallpapers and write a Framework logo into the top-left menu. After the 1e552aa refactor moved that work into the data-driven 20-oem-brew.sh, it stopped working for anyone on a Framework chassis: brew bundle fails on a typo in the OEM Brewfile, and the rest of the hook body (the logo write, the version stamp) never runs. This PR fixes the typo and adds bats coverage so a future edit to those OEM Brewfiles cannot regress the same way again.

Problem

system_files/shared/usr/share/ublue-os/oem/Framework/packages.Brewfile listed the Framework system tool as cask "ublue-os/tap/framework_tool" (underscore). The actual cask in ublue-os/homebrew-tap is framework-tool (hyphen), so brew bundle exits non-zero on every Framework chassis.

20-oem-brew.sh runs under set -euo pipefail. When brew bundle exits non-zero, the hook aborts before the dconf custom-command-list logo write and before version-script-commit "oem-Framework". The version-script-check gate added in #1196 means the hook retries on the next login, but every retry hits the same missing cask and never records a stamp, so the dconf logo and the wallpapers never land. Users who rebooted, retried, or re-ran the hook manually all saw the same blank OEM state. This is the regression from the old 10-theming.sh layout that #1449 reports: the wallpapers are not installed and the custom menu does not show a Framework logo on a fresh install.

Change

• Rename cask "ublue-os/tap/framework_tool" to cask "ublue-os/tap/framework-tool" in the Framework OEM Brewfile so the bundle resolves.
• Update the matching documentation in docs/skills/oem-hardware-hooks/references/oem-brew.md (the OEM directories table) and docs/skills/brew-lifecycle/references/placement-rules.md (the ublue-os/tap cask list).
• Add two bats tests under tests/test_oem_brew.bats that pin the shipped Framework and ASUS OEM Brewfile cask tokens against the upstream tap, including a negative assertion that no underscore variant (framework_tool) appears in the Framework Brewfile.

The scripts/validate-brewfiles.sh Brewfile validator only walks system_files/shared/usr/share/ublue-os/homebrew/, not the oem/ tree, so a targeted test is the right place to lock the OEM tokens.

Tests

tests/test_oem_brew.bats now has 15 cases (up from 13). The two new cases assert the exact upstream cask tokens in the shipped Framework and ASUS OEM Brewfiles and reject the underscore variant that caused this regression. All 15 cases pass locally:

$ bats tests/test_oem_brew.bats
ok 1  oem-brew: unknown vendor exits without invoking any OEM command
ok 2  oem-brew: Framework chassis vendor selects Framework Brewfile
ok 3  oem-brew: ASUS sys vendor selects ASUS Brewfile for ASUSTeK
ok 4  oem-brew: ASUS sys vendor accepts the short ASUS form
ok 5  oem-brew: vendor text in sys_vendor does not spoof Framework detection
ok 6  oem-brew: vendor text in chassis_vendor does not spoof ASUS detection
ok 7  oem-brew: missing brew exits cleanly and requests a retry
ok 8  oem-brew: ASUS enables asusd-user.service with exact arguments
ok 9  oem-brew: Framework does not enable the ASUS user service
ok 10 oem-brew: logo writes the exact dconf command arguments
ok 11 oem-brew: Framework Desktop installs its exact WirePlumber payload
ok 12 oem-brew: non-Desktop Framework skips the WirePlumber payload
ok 13 oem-brew: missing OEM directory exits without invoking brew
ok 14 oem-brew: shipped Framework Brewfile references upstream cask tokens
ok 15 oem-brew: shipped ASUS Brewfile references upstream cask tokens

The new Framework test fails against the pre-fix Brewfile (verified by hand against a fixture) and passes against the fixed Brewfile.

Verification

• bats tests/test_oem_brew.bats passes (all 15 cases)
• New Framework test fails against a fixture with the old framework_tool token, passes against the fixed framework-tool token
• shellcheck clean on the modified test file
• No other Brewfile in the repo references the underscore variant

Closes #1449.

— hive: backend=omp model=minimax-code/MiniMax-M3

---

🐝 Hive Agent: contributor | SHA: 3220360

[github-actions]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign ahmedadan after the PR has been reviewed.
You can assign the PR to them by writing /assign @ahmedadan in a comment when ready.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hivecommons-hive]

Read the hook and the tree at 3220360; the diff is consistent with the mechanism described, with one fact I could not verify from this repository.

Verified

• system_files/shared/usr/share/ublue-os/user-setup.hooks.d/20-oem-brew.sh:32-34 — set -xeuo pipefail precedes brew bundle, so a non-zero bundle exit aborts before the dconf logo write (line 42) and before version-script-commit (line 49). The failure mode in the body matches the code.
• grep -rn 'framework[-_]tool' across the repo: the only three underscore occurrences are the three the diff rewrites; no other Brewfile or recipe references either spelling.
• tests/test_oem_brew.bats uses run !, which tests/test_brew_preinstall.bats:412 already relies on, so the bats version CI installs (unit-tests.yml:38) supports it.
• ASUS/packages.Brewfile contents match the new ASUS assertions exactly.

Open question for a maintainer — the whole fix turns on ublue-os/tap publishing the cask as framework-tool (hyphen). That tap is outside what I can read; please confirm with brew info ublue-os/tap/framework-tool before merging. If the token is wrong the hook fails identically to today, so the downside is bounded.

Minor (low) — tests/test_oem_brew.bats:208-210 comment says the failure "permanently skip[s]" the logo write. The hook's own comment at 20-oem-brew.sh:47-48 and your PR body both say the opposite: because version-script-commit never runs, the hook retries every login. Suggest "skipping ... on every login" so the test comment doesn't contradict the hook it guards.

I have not approved or changed anything.

Confidence: 3/5 (needs attention) — 1 medium finding; 1 perspective requires a human decision

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[Danathar]

Approving at 3220360. ublue-os/homebrew-tap has Casks/framework-tool.rb, which answers the open question. The new bats case is a real guard: a read-only helper saw it pass at this head and fail with the old Brewfile restored. Small nit: tests/test_oem_brew.bats:210-211 says "permanently skipping", but the hook retries on every login.

[castrojo]

The ublue-os/tap cask token is framework-tool; framework_tool made brew bundle exit non-zero under set -euo pipefail in 20-oem-brew.sh, skipping the logo write and version stamp. The Brewfile fix is correct, the doc references are updated to match, and the new bats checks pin both OEM Brewfiles to the published tokens. test/validate/builds green.