What
README.md and CHANGELOG.md both state that open -a Lumen, or double-clicking the app in /Applications, reveals the main window. That path is wired to tauri::RunEvent::Reopen in the .run() closure of lumenator/src-tauri/src/lib.rs, which comes from AppKit's applicationShouldHandleReopen:hasVisibleWindows:. It was never hand-verified, and the approved implementation plan for the feature said explicitly that it had to be. It is not established that AppKit delivers a reopen event to a process running under ActivationPolicy::Accessory, which Lumen sets at startup, so it has no Dock icon and is absent from the app switcher. Until someone runs it, the docs assert a recovery path that may not exist — and this is the path a user takes precisely when the tray has already failed them.
Evidence
grep -rn "Reopen\|REOPEN" --exclude-dir=node_modules --exclude-dir=target . returns 3 hits, all in lumenator/src-tauri/src/lib.rs (lines 523, 526, 527). No test, fixture, or harness references the variant.grep -n "ActivationPolicy" lumenator/src-tauri/src/lib.rs → line 219 sets Accessory at startup; line 556 switches to Regular inside reveal_main_window.grep -n "open -a Lumen" README.md CHANGELOG.md → README.md:805 and CHANGELOG.md:47, both asserting the behaviour as working.- The arm is
#[cfg(target_os = "macos")] gated; the variant does not exist on other platforms, so removing the gate fails to compile on Linux rather than merely never firing.
- Verification requires an app bundle:
open -a cannot target a bare binary, so pnpm tauri dev cannot exercise this.
Acceptance criteria
How to test
# 1. Build a real app bundle — `open -a` cannot target a bare binary.
cd lumenator
./build-sidecar.sh
pnpm install
pnpm tauri build # src-tauri is a workspace member, so the bundle lands in the
# workspace-root target/release/bundle/macos/, not under lumenator/
# 2. Quit any running Lumen, then replace the installed copy outright: `cp -R` into an
# existing /Applications/Lumen.app nests a second bundle inside it instead of
# replacing it. Quit a `pnpm tauri dev` instance by hand — it does not match this pattern.
pkill -f Lumen.app || true
rm -rf /Applications/Lumen.app
cp -R ../target/release/bundle/macos/Lumen.app /Applications/
# 3. Launch once. Prove the logger registered before trusting the log's silence.
open -a Lumen
sleep 3
grep -c "STARTUP: Lumen" ~/Library/Logs/io.speedata.lumen/Lumen.log
# 4. The test: re-activate the already-running app.
open -a Lumen
sleep 2
grep -n "REOPEN: the app was re-activated" ~/Library/Logs/io.speedata.lumen/Lumen.log
# 5. Repeat step 4 by double-clicking Lumen in /Applications.Expect one of two outcomes, both of them results. Either grep prints REOPEN: the app was re-activated and the main window comes forward — the documented claim holds. Or grep exits 1 with no output and no window appears — AppKit does not deliver reopen under Accessory, and the fallback plus the doc edits are required. A grep miss only counts if step 3 printed a nonzero count; a build whose logger is not registered produces the same silence for an unrelated reason. For more detail, relaunch with open --env LUMEN_LOG=debug -a Lumen, which sets the variable for the launched app explicitly.
What
README.md and CHANGELOG.md both state that
open -a Lumen, or double-clicking the app in /Applications, reveals the main window. That path is wired totauri::RunEvent::Reopenin the.run()closure oflumenator/src-tauri/src/lib.rs, which comes from AppKit'sapplicationShouldHandleReopen:hasVisibleWindows:. It was never hand-verified, and the approved implementation plan for the feature said explicitly that it had to be. It is not established that AppKit delivers a reopen event to a process running underActivationPolicy::Accessory, which Lumen sets at startup, so it has no Dock icon and is absent from the app switcher. Until someone runs it, the docs assert a recovery path that may not exist — and this is the path a user takes precisely when the tray has already failed them.Evidence
grep -rn "Reopen\|REOPEN" --exclude-dir=node_modules --exclude-dir=target .returns 3 hits, all inlumenator/src-tauri/src/lib.rs(lines 523, 526, 527). No test, fixture, or harness references the variant.grep -n "ActivationPolicy" lumenator/src-tauri/src/lib.rs→ line 219 setsAccessoryat startup; line 556 switches toRegularinsidereveal_main_window.grep -n "open -a Lumen" README.md CHANGELOG.md→ README.md:805 and CHANGELOG.md:47, both asserting the behaviour as working.#[cfg(target_os = "macos")]gated; the variant does not exist on other platforms, so removing the gate fails to compile on Linux rather than merely never firing.open -acannot target a bare binary, sopnpm tauri devcannot exercise this.Acceptance criteria
open -a Lumenagainst an installed bundle: the matching log line pasted, or an explicit statement that the log contains noREOPEN:line.Accessory: a file signal (e.g.~/.claude/lumen/show.request) polled at 1 Hz only while the tray is not Present, so a healthy launch does no polling at all — demonstrated by log or test, not asserted.#[cfg(target_os = "macos")]gate intact.How to test
Expect one of two outcomes, both of them results. Either
grepprintsREOPEN: the app was re-activatedand the main window comes forward — the documented claim holds. Orgrepexits 1 with no output and no window appears — AppKit does not deliver reopen underAccessory, and the fallback plus the doc edits are required. Agrepmiss only counts if step 3 printed a nonzero count; a build whose logger is not registered produces the same silence for an unrelated reason. For more detail, relaunch withopen --env LUMEN_LOG=debug -a Lumen, which sets the variable for the launched app explicitly.