RFC: unified launcher (single entry + device start/stop) — initial design [idea: Magdalena]

[pskeshu]

Unified launcher — initial design (RFC)

Idea: Magdalena — make launch_gently.py the single unified launcher.

This is initial work, not a finished feature. It's a design + mockup to build on —
no implementation yet, and it's meant to be iterated on, not merged-and-done. Opening
it as a PR so the direction is visible and others can fold more into it.

What it proposes

Today you run two commands in two terminals (start_device_layer.py, then
launch_gently.py) and gently can't start/stop the device layer. This makes
launch_gently the single entry point:

• A bare-basic launch gate — exactly two questions: microscope hardware on/off and
  AI agent (API) on/off → Let's go. Everything else (organism, hardware module,
  port, SAM device, session) is a default behind "Advanced options"/Settings — if you're
  not using hardware, you're never asked which hardware.
• A managed child subprocess (DeviceLayerSupervisor): gently spawns and owns
  start_device_layer.py, so it can start/stop it, and it shuts down when gently exits.
• Graceful stop with a mid-run guard (confirm if hardware is active) + SIGKILL fallback.

Design: docs/superpowers/specs/2026-07-02-unified-launcher-design.md
Mockup (dark/sharp/sleek): docs/superpowers/mockups/2026-07-02-launcher-gate.html

Open questions to fold in (help wanted)

These are deliberately unresolved — the next round of work:

• Background startup — after "Let's go", the device layer should boot in the
  background (non-blocking) while gently proceeds to the dashboard. Confirm + design
  the progress signalling.
• Usable during startup — gently stays usable while the device boots (software
  features immediately; hardware actions gated behind a "device starting…" state).
• On-demand startup-sequence screen — where do you watch the device startup
  sequence (live boot log + per-stage progress) on demand? Likely a device console in
  the Devices panel.
• Shutdown from that same screen — the console is also the shutdown control.
• Guided shutdown housekeeping — shutdown is a sequence, not just a kill, e.g. it
  can prompt the operator to reset the F drive as a step.

Status

Parked design/RFC — no code, safe to leave open for discussion; implementation is a
future session. Base: development.

[pskeshu]

Added a future direction: Windows desktop app (Electron) — Electron could be the launcher shell: own/spawn the Python backend + device-layer child, render the existing web UI natively (launch gate as the first screen), native process lifecycle (kill children on quit), tray + installer + auto-update. Web UI stays the single source of truth (Electron = thin shell); pywebview/Tauri as lighter fallbacks. Not required for the first cut, but the managed-child process model in this RFC is exactly what the shell would take over. Captured in the spec.