fix(tests): src-tauri's unit tests start on Windows

[WynandVStaden]

What?

On Windows, cargo test -p atlas --lib now starts and runs src-tauri's unit tests. Before, the test executable exited with 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND before running anything.

Why?

The guess in #332 is right, and I confirmed it on the failing binary:

• The test executable imports TaskDialogIndirect from comctl32.dll (pulled in by Tauri's dialog code). Only comctl32 v6 exports it.
• The executable had no RT_MANIFEST resource, so Windows bound it to comctl32 v5 and the loader refused to start the process.

tauri-build does embed the manifest, but through the app's resource file, which is linked with cargo:rustc-link-arg-bins. That reaches [[bin]] targets only, so atlas.exe got a manifest and the --lib test executable did not.

How?

src-tauri/build.rs, on windows + msvc only:

• Embed the manifest with the linker for every target the package links: cargo:rustc-link-arg=/MANIFEST:EMBED and /MANIFESTINPUT:<src-tauri/windows-app-manifest.xml>.
• Build with WindowsAttributes::new_without_app_manifest(), so tauri-build does not add a second copy to the app's resource file.

windows-app-manifest.xml has the same content as tauri-build's default manifest (the Common-Controls v6 dependency), so atlas.exe ends up with the same manifest it had before, just embedded by a different route. macOS, Linux and windows-gnu builds take the old path unchanged.

Two things I tried first, in case they come up in review:

• cargo:rustc-link-arg-tests is rejected for this package (does not have a test target). It covers integration tests, not the unit-test executable.
• cargo:rustc-link-arg on its own, keeping tauri-build's manifest, makes the unit tests run but breaks the app link: CVTRES : fatal error CVT1100: duplicate resource. type:MANIFEST. That is why the two changes go together.

Verification (Windows 11, MSVC, Rust 1.99.0, on top of 0.4.1)

	Before	After
cargo test -p atlas --lib	exits 0xc0000139 before any test	1011 tests run: 991 passed, 14 failed, 6 ignored
manifest in the test executable	none	one, Common-Controls v6
cargo build -p atlas --bin atlas	links	links
manifest in atlas.exe	(not inspected)	exactly one, Common-Controls v6

I also started the built atlas.exe and it came up normally (it logged its agent host, memory server and notifier start-up). I did not use the UI beyond that, and the frontend was a stub dist/, so I have left the third checklist box unticked.

The 14 failures are real Windows failures that were hidden because the binary never started. They are not caused by this change and I have not touched them here:

• 12 in commands::skills (symlink handling)
• 1 in state::atlas_config (an_absolute_xdg_config_home_wins: /elsewhere/cfg is not an absolute path on Windows)
• 1 in commands::save_guard (ordinary_save_targets_pass)

I can open a follow-up issue listing them if that is useful.

Not run: bun run ci:local and the frontend checks; this PR only touches src-tauri/build.rs and adds the manifest file. cargo clippy -p atlas --all-targets -- -D warnings stops on Windows at an existing lint in vendor/atlas-engine/utils/path-uri (chunks_exact with a constant chunk size), with or without this change; plain cargo clippy -p atlas --lib reports nothing for build.rs. I could not test macOS or Linux; the new code returns early there.

Fixes #332

Checklist

• Targets the current version branch, unless it's a small standalone fix
• New behaviour has a test; a bug fix has a test that fails without it — there is no test to add for "the test binary starts"; the evidence is the before/after table above.
• You've run the app and used the change in a window — started it only, see above.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 07bb7355-3ec0-44bd-b1f8-64c11bd71aec

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[emirhanyesilgul]

Approving from the Windows side. Tested on Windows 11 (MSVC, Rust 1.99), at 2e8d51f.

	Before (a 0.4.x test binary built 2026-10-05)	With this PR
cargo test -p atlas --lib	exits 0xC0000139 before any test	1011 tests run: 991 passed, 14 failed, 6 ignored
manifest in the test binary	none	exactly one, Common-Controls v6
manifest in atlas.exe (debug and release)	—	exactly one, Common-Controls v6

• The 14 failures match your list exactly (12 in commands::skills, plus save_guard::ordinary_save_targets_pass and atlas_config::an_absolute_xdg_config_home_wins).
• windows-app-manifest.xml is byte-for-byte tauri-build 2.6.1's src/windows-app-manifest.xml.
• Native window (bun run dev:app, real frontend): the app starts. Add project → Open Folder and the channel composer's attach button both open the modern Windows 11 pickers, and cancel cleanly.
• Release: bun run build:app:win builds and bundles Atlas_0.4.1_x64_en-US.msi; its atlas.exe carries exactly one manifest. I didn't install or run the release build.
• CI is green on this run, including app (src-tauri, Windows).

Two small notes, neither blocking:

• The embedded manifest isn't quite identical to before. The linker adds its default <trustInfo> with requestedExecutionLevel level="asInvoker", which the resource-file route (and 0.3.4's atlas.exe) didn't have. It's harmless: a 64-bit app runs as invoker either way. Worth a line in the description, or /MANIFESTUAC:NO if you want it identical.
• std::env::var("CARGO_MANIFEST_DIR") would say what's meant more directly than current_dir(). It's the same directory for build scripts today.

Thanks for tracking this down. I'll pick up the 14 Windows failures it uncovered in a follow-up.