F11.8: native macOS desktop shell for the local fleet IDE

[gnanirahulnutakki]

Goal

Ship a native, local-only macOS application for the Sith fleet IDE so the existing browser UI can be launched as an app, with native folder selection and a dockable desktop workflow. This follows F11.7 #162; it does not claim complete Lens parity.

Architecture decision boundary

The desktop shell must reuse the existing Go fleet engine, fleet.Source seams, directory importer, and web UI model. It must not create a second Kubernetes client, resource model, auth store, or remote control plane.

Evaluate and document the wrapper choice in an ADR before implementation. The preferred starting candidate is Wails v2 because Sith is Go-first and Wails supports Go plus web assets, native dialogs, macOS .app packaging, and code-signing workflows. Do not start on Wails v3 while its production support policy is not explicitly accepted. Primary references: https://wails.io/docs/introduction/ and https://wails.io/docs/guides/signing.

First shippable slice

• sith desktop opens a native macOS arm64 .app window containing the existing local fleet IDE; normal sith ui remains supported and unchanged.
• A native directory picker feeds the same bounded kubeconfig importer used by sith ui --kubeconfig-dir; no browser filesystem permission, directory contents, or credentials are persisted or uploaded.
• The app opens no externally reachable listener. If a loopback transport remains necessary during the first implementation, bind a random loopback port, enforce an unguessable per-process capability, and document why direct in-process binding cannot be used.
• All existing local operation boundaries remain unchanged: logs, exec, YAML, edit, and port-forward use the users current Kubernetes identity against a selected context. No telemetry, account, analytics SDK, or background updater.
• Native window lifecycle, error display, and quit behavior are explicit. A launch failure must show safe diagnostics without absolute paths, kubeconfig payloads, bearer tokens, or credential data.

Security and packaging acceptance

• macOS arm64 build is reproducible and produces a .app bundle plus a checksum manifest. Unsigned developer builds are clearly marked; release artifacts require Developer ID signing, notarization, and stapling before public distribution.
• Signing/notarization secrets exist only in protected release CI and are never required by PR CI, local tests, logs, or rendered artifacts.
• Release CI verifies bundle identifier, hardened runtime/entitlements, signature, notarization/stapling, and that no listener binds to non-loopback interfaces.
• Dependency additions receive license, provenance, vulnerability, and macOS-arm64 compatibility review. No auto-update channel in this slice.

Verification

• Unit tests prove the desktop adapter passes the selected directory through the existing importer and preserves source/context isolation.
• macOS integration smoke test launches the app against two disposable kind-backed kubeconfig sources, selects each source, and reads a fixture pod through the shared model.
• Negative tests cover canceled picker, unsafe/missing directory, importer limits, no credential data in view models or diagnostics, and no non-loopback listener.
• Run race, CI, release-check, real multi-cluster kind, package/reproducibility, signature/notarization release gates, peer/red-team review, and exact post-merge CI before closing.

Non-goals

• Complete Lens feature parity, Electron migration, Windows/Linux support, remote SaaS, auto-update, telemetry, browser-based file picking, writing kubeconfigs, or a separate authentication product.

Part of E11 #29 and Phase L. Follow-up to #162.

[gnanirahulnutakki]

Implemented by PR #167 (merged as 7f9302d). Exact post-merge dev CI run 29381529839 passed its full matrix, including race tests, tenant isolation, reproducible archives/SBOM, immutable image/Helm contracts, and the real two-cluster fan-out test.