[BerryUIKI]

Windows CI has been red on every PR since 2026-11-12 18:34, including dev itself. This fixes the cause.

The failure

Every Windows job dies at Lint (clippy), before compiling a single line of this workspace:

error: failed to run custom build command for `ort-sys v2.0.0-rc.13`
  thread 'main' panicked at ort-sys-2.0.0-rc.13\build\dynamic_link.rs:42:52:
  called `Result::unwrap()` on an `Err` value:
  Os { code: 3, kind: NotFound, message: "The system cannot find the path specified." }

Line 42 is inside copy_dylibs:

if std::os::windows::fs::symlink_file(&lib_path, &out_path).is_err() {
    copy_fallback = true;
    fs::copy(&lib_path, &out_path).unwrap();   // <-- here
}

Root cause

ort's default feature set includes copy-dylibs:

default = ["std", "ndarray", "tracing", "download-binaries", "tls-native", "copy-dylibs", "api-27"]

Both omera-tagger and omera-clip declared ort = { version = "2.0.0-rc.13", features = ["download-binaries"] } without default-features = false, so copy-dylibs was always on.

On Windows, copy_dylibs symlinks the ONNX Runtime DLLs into the cargo target directory. Hosted runners run without Developer Mode, so symlinking is denied, and it falls back to fs::copy — into a directory that does not exist there. Panic.

Why dropping it is safe

Nothing in this workspace bundles those DLLs:

• Windows installs the ONNX runtime through the Wix prerequisite fragment (windows/generated/runtime-prerequisite.wxs), not by shipping DLLs beside the binary.
• tauri.conf.json declares no bundle.resources.
• CI never exercises the ONNX paths against real models — the tagger and CLIP tests use fixtures, not model downloads.

copy-dylibs only controls whether cargo test / cargo run invoked from the target directory can resolve the DLLs at runtime. Dropping it costs nothing here.

The change

Both crates now take the default set apart and name what they use:

ort = { version = "2.0.0-rc.13", default-features = false, features = [
  "std", "ndarray", "tracing", "download-binaries", "tls-native", "api-27",
] }

That is the default minus copy-dylibs. The crate's actual API surface is unchanged — Session, Tensor, inputs! and GraphOptimizationLevel are all still available, and cargo check confirms it.

Cargo.lock is untouched; feature flags do not alter the dependency graph.

Verification

• cargo check --workspace --all-targets — clean.
• cargo clippy --workspace --all-targets -- -D warnings — clean.
• cargo test --workspace — all green.

The real proof is the Windows job on this PR: it is the first one in two days that can get past Lint (clippy).

Scope

Build configuration only. No source, schema, IPC, UI or behavior change.

🤖 Generated with Claude Code