[Astro-Han]

Summary

Maka.app cannot be opened from Finder or the Dock. Opened directly, the desktop shell has none of the MAKA_HOST_* variables that maka desktop supplies, so it exits at once:

maka-desktop-shell: MAKA_HOST_ROOT is not set; start the desktop with `maka desktop`

With this change, a shell started with none of those variables runs maka desktop from the directory the launcher stages it in and exits. On macOS that is the directory holding Maka.app; on other platforms it is the shell's own directory. This is the layout of both just build and the native npm packages. The launcher then initializes or reopens the default Root and opens the window exactly as it does from a terminal, so first-run initialization, admission and reconnection still have a single path. A partial set of variables still fails as before.

On Windows the launcher is started with CREATE_NO_WINDOW, so no console window appears behind the desktop.

Maka.app still has to stay beside maka. A self-contained bundle that can be dragged into /Applications on its own is a packaging change and is not part of this PR.

Verification

• cargo nextest run -p maka-desktop-shell: 8 passed. The new open_directly test copies the shell into a Maka.app layout beside a stub maka, starts it without the variables, and checks that maka desktop ran. It fails on the old code with the error above.
• Manual check on macOS arm64 with a debug build: open -n --env HOME=<temp> target/debug/Maka.app (the path Finder and the Dock take) started the launcher, which initialized <temp>/.maka/application/host and opened the Maka window. Stopping the launcher left no shell or Host process.
• cargo fmt --all -- --check, Biome format and scripts/asf-license-headers.mjs check pass. cargo clippy -p maka-desktop-shell --all-targets --no-deps -- -D warnings reports nothing in this crate. I did not run just check, and I could not run Windows or Linux.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code found the gap while dogfooding, wrote the change, the test and the README notes, and ran the checks above.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

I reviewed all four changed files at 8e17a02276e6b645e7c270883d28b11f72b82f82, the existing Target::from/help path, the CLI desktop launcher, and the build/native-package staging code. The reported prerequisite is present in the old source: an ordinary shell start immediately requires the launcher-supplied variables. The new fallback is limited to all four variables being absent; partial or empty supplied values still go through existing validation, and help/version are answered first.

I found no confirmed P0–P2 in this source review. The absolute launcher path derived from the canonical shell matches the staged layouts: Maka.app/Contents/MacOS/maka-desktop-shell beside maka on macOS, sibling executables elsewhere. It spawns that launcher with the single argument desktop, preserving the existing default-Root initialization/admission/reconnection path. Windows adds CREATE_NO_WINDOW. The changed documentation correctly retains the requirement to keep Maka.app beside maka; it does not make the bundle independently movable into Applications.

I inspected the new Unix stub-launcher test, but this machine has no Rust toolchain and I did not execute the shell or a GUI launch. The eight Rust tests and macOS manual result in the PR description are author-reported; Windows/Linux process behavior, child lifetime, and an installed npm package were not independently exercised here. git diff --check passed. No Host wire-format or database migration changes.

The actual merge with rust-preview at 0d5e27d381086c5b9b374775878e3202afaffc4a is clean; this PR's CI is still running. The completed Rust-base run at 3100eeecd failed on an unchanged Computer Use Clippy warning, so it supplies no successful full-suite result for this change.

---

Automated review notice: This comment was posted by an automated review agent operated by Astro-Han. It is not an independent human review and does not replace one.