Refuse a run with no output folder, say where results went, quieten the log

[adulbrich]

Three faults from one report against the 5.0.0 build, plus the cause of the first.

A run wrote nowhere, and only said so afterwards

The configured output folder pointed at a temporary directory that no longer existed. The pipeline ran every stage, then failed on the first write:

Failed
failed to open file at path: /var/folders/.../T/hdricalibrationtool-e2e-BIYaSd/JPEG_2026-08-07_11-37-06.hdr
with error: No such file or directory (os error 2)

Thirty seconds of work discarded, and nothing said about which folder was wrong or where to change it. The folder is now checked before the run starts, and the message names the folder and points at Settings.

Folders go stale for ordinary reasons: an unmounted drive, a deleted directory, a path restored from a backup. The setting is persistent, so a wrong value fails every run until someone notices.

Neither host said where the results went

A browser announced its download. The desktop said nothing at all, which is why a wrong folder could stay invisible indefinitely. Both now report the destination:

Saved JPEG_2026-08-07_11-37-06.hdr to /Users/…/Documents/LumiLab/…

Every run carried diagnostics nobody asked for

#263 reported a per-tool breakdown whenever an invocation passed one second, on the reasoning that "a whole merge is around fifteen seconds and no single invocation should approach that". That was simply wrong: the merge is a single invocation, so hdrgen tripped it on every run, along with evalglare and pcomb.

The breakdown moves to console.debug — still there for whoever needs it, in front of nobody who does not. The JIT warning stays in the run log, because that one is actionable.

The cause of the stale folder

The desktop end-to-end suite writes an output path into hdr-settings, which is the same key the real app uses, because both share one Tauri identifier. That sharing is deliberate and must stay: renaming the identifier would orphan every user's presets and history. But the suite never put the value back, so a temporary directory from a run predating the LumiLab rename was still in a released build's settings months later.

It now restores what it found, in an after hook so a failed run cleans up too — which is exactly when it matters, since nothing later in the suite would.

Verification

435 tests (4 new, covering the missing folder, the not-yet-chosen folder, the browser case, and blocker precedence), tsc clean in all three projects, lint clean, and the full browser end-to-end suite passing.

Note for anyone hitting this on an existing install: changing the output folder in Settings fixes it immediately; this PR is about the app telling you rather than failing silently.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lumilab	Ready	Preview	Aug 7, 2026 9:55am