[jay23606]

Fixes #87

What

Adds a Show in folder control beside the debug bundle's Copy path. It opens the archive's folder in the file manager:

• Windows: explorer /select,<archive>
• macOS: open -R <archive>
• Linux: xdg-open <folder> (no launcher selects a file there)

It reuses the platform dispatch in folder_panel.rs: reveal_command() picks the program and arguments, and spawn_reaped() starts the child and reaps it off-thread, the same as open_in_file_manager(). The control writes nothing to the clipboard and shows no confirmation, as the issue asks. Copy path is unchanged.

Base

Based on integration/kit-surface, as the issue asks, because the diagnostics surface was rewritten by #80 and #82. It will need a rebase if main moves before that stack merges.

Tests

• New unit test reveal_selects_the_archive_or_opens_its_folder_per_platform: written first and red (reveal_command missing), then green. Each platform branch is checked by its own CI job.
• cargo fmt --all -- --check: clean
• cargo clippy -p immich-sync --all-targets -- -D warnings: clean
• cargo test -p immich-sync: all passing (Windows)

Not covered by a headless test: the button click itself. A test would open a real file manager, so the click path is not exercised automatically.

🤖 Generated with Claude Code

[elementalvoid]

Thanks — this is close, and the shape is right: based on integration/kit-surface, no clipboard
write, no confirmation, Copy path untouched, and the row only exists in the Ready arm so "absent
until an archive exists" is structural. One detail shows real care: adding spawn_reaped and
leaving open_in_file_manager's signature alone matters, because dashboard.rs:88 uses it as a
FolderOpener closure — changing it would have rippled into the dashboard.

Review note: this review was done by an AI agent on the maintainer's behalf, so treat it as
the maintainer's review with one caveat — no file manager was actually launched on any platform
from this side. The reasoning below is from the code.

Three things before merge

1. The click is untestable for a reason the repo already solved. reveal_bundle calls
crate::folder_panel::reveal_in_file_manager directly, so the only way to exercise the click is to
launch a real file manager — hence "not covered by a headless test". But #43 hit exactly this and
fixed it with an injectable seam: pub type FolderOpener = Arc<dyn Fn(&str) -> std::io::Result<()>>
(folder_panel.rs:58), defaulting to the real implementation and swapped out in tests
(dashboard.rs:140). Mirroring that here — one field, one with_revealer constructor — turns the
click into an ordinary test.

2. It fails silently. On error the view only does tracing::warn!. #43's precedent is
self.problem = Some(format!("The folder could not be opened: {error}"))
(folder_panel.rs:623-626), rendered as the panel's error notice. A button that visibly does
nothing when it fails is worse than no button. This is a Notice (Severity::Error), not the
confirmation the issue rules out — a failure is a refusal, not feedback.

3. The view-level criteria aren't pinned. The unit test covers the platform table nicely, but
not: the control is absent when there is no archive, present and named when Ready, and keyboard
reachable. That is the normal shape in tests/diagnostics.rs, and it is cheap once the seam from
(1) exists.

Nice to have, not required

Windows path with spaces. You are building on Windows, and the debug bundle lands in the user
profile's Downloads, so C:\Users\Jane Doe\Downloads\… is a realistic path. explorer /select,<path>
should survive Rust's argument quoting, but that is the one thing I cannot check from Linux. If you
can try it once with a space in the path, that would close the last unknown here. Not a blocker if
you would rather not.

[jay23606]

Show in folder now goes through an injectable opener (DiagnosticsView::with_revealer), so the click is exercised by a headless test instead of launching a real file manager. A refused launch now shows an error notice beside the control as well as logging it, and the new test checks the control's name, its keyboard reach, its absence before an archive exists, and that notice. I have not tried a Windows path with spaces in Explorer, so that case is still unchecked.

[elementalvoid]

Thanks @jay23606!