This is the actual bug the night's ecosystem-utils audit was looking for.
classifier.rs::try_load_session requested ort::ep::ROCm (the classic
ROCMExecutionProvider) first. Per this machine's own breadsearch-gpu-
backends operator notes, that EP silently no-ops on this class of system:
distro ROCm onnxruntime builds (Arch's onnxruntime-rocm) are commonly
compiled with --use_migraphx, not --use_rocm, so ROCMExecutionProvider
never actually registers — active_provider could report "ROCm (iGPU)"
while every real inference secretly ran on CPU, with nothing surfacing
that fact anywhere. Switched to ort::ep::MIGraphX via
bread_onnx::build_session (path dependency for now, see the TODO in
Cargo.toml), matching breadsearch's own already-correct embed.rs.
Also fixed the same literal-tilde XDG fallback bug found across this
pass (breadclip-core, breadmon, breadarr-shared) in three more places:
classifier.rs::model_dir, config.rs::config_path, config.rs::style_css_path.
Bumped the workspace's tokenizers pin 0.21 -> 0.23 to unify with
bread-onnx's own requirement (breadarr already pins 0.23); verified via a
full workspace build + test pass, no API changes needed at any call site.
Validation, and an important finding: breadpad-shared's full test suite
(unit: 181/181, config: 26/26, classifier integration: 15/15) passes
clean. The pipeline.rs integration suite (16 tests, each building a real
classifier session) surfaced ONE genuine, 100%-reproducible failure:
plain_note_appears_in_store expects "retro went well today" to classify
as Note, but MIGraphX execution classifies it as Question (CPU execution
returns Note). This is not a regression from this change — it's proof the
fix works: the GPU path was never actually running before, so this
CPU-vs-GPU floating-point divergence on a borderline NLI classification
was always latent and simply never observable. Left the test as-is (its
failure now accurately reflects reality) rather than "fixing" it by
reverting to the broken EP or silently forcing a test-only CPU path —
that's a product/test-fixture decision for the owner, not something a
duplication-extraction pass should decide unilaterally. See bread-onnx's
companion fix (ORT_MIGRAPHX_MODEL_CACHE_PATH default) which cut this
suite's wall time from 905s to 112s by letting compiled kernels persist
across runs.
Use bread-theme 0.2.7's luminance-picked ink (@on-*): type chips on @overlay and
selected sidebar rows / confirm buttons on @blue kept @fg or @bg, which vanished
when those slots came out light/dark. They now use @on-overlay / @on-accent.
Add breadpad_shared::theme::apply_live (wraps bread_theme::gtk::apply_app_css) so
breadpad and breadman recolour live on `bread-theme reload` and re-read the user's
style.css — replacing the build-once provider. bread-theme bumped to v0.2.7
(gtk feature).
build_css() now starts from bread_theme::stylesheet(palette) and appends only
breadpad/breadman-specific components. This unifies fonts, palette, and generic
widgets with the rest of the ecosystem and fixes the colour mapping (overlay is
now color7, matching every other app, not color0). Bump bread-theme to v0.2.6.
- breadpad-shared/Cargo.toml: depend on bread-theme (no gtk feature needed
in the shared crate)
- breadpad-shared/src/theme.rs: re-export Palette and load_palette from
bread-theme; retain all breadpad-specific CSS in build_css()
- bakery.toml: describes breadpad for bakery install
- release.yml: builds on hestia self-hosted runner, publishes binaries to
dl.breadway.dev and GitHub Releases on v* tags
- Add MIT LICENSE file
- Expand .gitignore with standard Rust/Linux entries
- Remove dangling symlinks (breadmancli, breadpadcli) and dev scratchpad (svgs.txt) from git tracking
- Replace unsafe unwrap() calls with expect() in breadman CLI (guarded by prior filter)
