Desktop: launch a secure macOS session shell

[qwen-code-dev-bot]

Goal

Create the Electron desktop session shell for Oh My CLI, with a macOS-first presentation and a secure project/session workbench that becomes the shared foundation for later Desktop issues.

Load-bearing execution contract

• This issue intentionally starts from a repository with no Electron dependency. Adding the first minimal Electron dependency, main process, secure preload boundary, renderer shell, build/test configuration, and required CI is the deliverable; their current absence is not a blocker.
• The development host is Linux. Implement and interact with the real Electron BrowserWindow under Linux Xvfb, and use the GitHub Actions macOS runner for native macOS launch and screenshot validation. No separately provisioned local Mac is required.
• Evidence is three head-SHA-bound artifacts, not one local-host capture: (1) the trusted tmux terminal receipt, (2) Linux Xvfb Electron interaction coverage, and (3) a screenshot artifact produced by the macOS CI job for the same head.
• Maintainer authorization explicitly covers the minimal package, build, test, packaging, and governed workflow changes required for this first Electron slice.

Scope

• Add the Electron application shell with a macOS-first layout, native window lifecycle, and secure preload IPC boundary.
• Provide a project/session rail, main workbench region, inspector region, and a fixed composer shell.
• Keep desktop state session-oriented and compatible with existing CLI workspace/session concepts; do not introduce a parallel settings or workflow authority.
• Include keyboard-accessible navigation, empty/loading/error states, and a built-in desktop diagnostics view.
• Add focused tests and the complete three-part head-SHA-bound evidence set defined above.

Maintainer implementation decision

• Use Electron and the existing Node.js/TypeScript toolchain for this issue.
• Minimal Electron build, test, packaging configuration, and required CI are in scope.
• Do not block on a local macOS host: Linux Xvfb provides implementation interaction coverage and the required macOS CI runner provides native-window validation.
• Keep the secure preload allowlist narrow; do not introduce a second settings or workflow authority.

Acceptance criteria

• A real Electron BrowserWindow launches under Linux Xvfb and renders the project/session workbench; the macOS CI job launches the same head natively and publishes its window screenshot artifact.
• IPC exposes only allowlisted operations; there is no renderer-side Node access or unrestricted filesystem/process bridge.
• Project/session selection and composer focus are keyboard reachable.
• Empty, loading, and recoverable error states are explicit and visually coherent.
• Tests cover shell lifecycle, IPC validation, and primary navigation states.
• The PR includes a trusted tmux terminal receipt, Linux Xvfb interaction evidence, and a macOS runner screenshot artifact, all bound to the tested head SHA.

Blocked by

• Fix workspace path validation rejecting normal local files and directories #112 (closed; dependency satisfied)

Source

• source:user

Out of scope

• Session command execution and PTY wiring (Desktop: connect a real local session and Terminal view #107).
• Live agent transcript/tool/diff rendering (Desktop: render the live agent workbench #108).
• Approval and Dynamic Workflow checkpoint controls (Desktop: inspect approvals and Dynamic Workflow checkpoints #109).
• Settings/provider editing (Desktop: integrate safe settings and provider references #110).
• Packaging/signing and final smoke coverage (Desktop: package, diagnose, and prove the full local workflow #111).

[qwen-code-dev-bot]

⚠️ Blocked — requires product/governance decision (escalated to maintainer).

This issue (the foundational macOS desktop session shell for roadmap #105) cannot be implemented or merged through the current autonomous pipeline:

1. Desktop framework — none is chosen (Electron vs Tauri vs other). This is a major architectural and dependency decision.
2. Pipeline toolchain — .autonomy/product.yml declares type: cli with only tsc/vitest commands. Adding a desktop build/test/package toolchain requires amending product.yml and .github/workflows/**, which are protected governance paths the development Bot cannot modify.
3. Evidence gate — the merge gate is the trusted tmux-terminal e2e-evidence capture, which records terminal text and cannot capture a native macOS GUI window. The host is headless Linux, and macOS-native code cannot run here at all.

No independently-valuable, mergeable slice exists that satisfies the GUI-centric acceptance criteria without these decisions.

To unblock: a maintainer to (a) select the desktop framework, (b) amend the governance config to add a desktop toolchain, and (c) define a GUI-appropriate evidence gate — or re-scope #106 into headless-testable slices with an explicit framework choice. The agent-blocked label is applied; remove it once resolved.

[qwen-code-dev-bot]

Maintainer decision: desktop implementation is authorized

• Framework: Electron, selected to reuse the existing Node.js/TypeScript stack and keep the native shell, preload boundary, and CLI integration in one runtime.
• Toolchain: the implementation may add the minimal Electron build, test, and packaging configuration required for this desktop slice, including the necessary governed CI definitions.
• Evidence: every desktop PR must retain the head-bound tmux terminal receipt and add a real Electron-window verification. Linux CI may use Xvfb for deterministic interaction coverage; the macOS runner must publish a native-window screenshot artifact for the tested head.
• Scope guard: keep the first slice focused on the secure shell, project/session rail, workbench frame, inspector, fixed composer, and diagnostics. Do not duplicate Settings or Dynamic Workflow authority.

This resolves the prior framework, pipeline, and GUI-evidence blockers. Please proceed through the normal lease → PR → E2E → checks → merge → post-merge flow.