Parent tracking issue: #141. Phase 2 of 11.
Objective
Establish and test the desktop window and per-user controller foundation on macOS, Windows and Linux before credential and execution integration depend on it.
Scope
Deliver a minimal reusable Wails v2 shell, React/TypeScript fixture UI and independent Go controller with no live SSH actions or real credentials. Pin a reviewed stable v2 patch and its Go/frontend toolchain. Build on native runners; record supported OS versions, CPU architectures, Linux distributions, X11/Wayland sessions and required WebView runtimes. Separate developer build tools from installed-user dependencies. Missing runtimes or graphical sessions must produce actionable states. Verify package installation and launch on clean supported systems; release signing/notarization and uninstall behavior belong to #148.
The window runs in the logged-in graphical user's session. The controller is a separate process owned by that user, not a privileged service that tries to show UI from Windows session zero. Specify start-on-demand and termination policy, window close versus explicit controller stop, logout, sleep/resume and restart. No guarantee that a controller stays alive through OS logout or sleep. Later reconciliation recovers the same request identity without re-dispatch. One controller owns mutable local state. Protect Unix sockets and Windows named pipes with OS identity/ACL checks, verify the expected server identity, bound frames, version the IPC handshake, and reject incompatible app/controller versions. Prevent another user or session from stealing the endpoint or focus target. Existing Atenea IPC/build constraints must be handled explicitly without porting the whole daemon by assumption.
Audit the COMPLETE JS-to-native surface of the pinned Wails build: framework runtime calls, generated Go bindings, events, navigation, external URL schemes, clipboard, downloads and file drops. A small Bind list or omitted JS wrapper is not evidence that a native operation is unreachable. Restrict the host-side dispatcher or other proven enforcement points where necessary, and test direct bridge calls that bypass UI controls. Never expose arbitrary shell or filesystem operations. Document any framework capability that cannot be restricted and resolve the required boundary before passing this gate; do not silently switch frameworks or claim a capability sandbox that was not implemented. Use packaged local assets, compatible CSP, bounded input validation and no production browser control endpoint. Development servers only use synthetic fixture data.
Provide a reference UI with sidebar, searchable host list, detail and history fixtures. Record design tokens, typography/icon assets licensed for all three platforms, light/dark states and keyboard/focus behavior. SwiftUI is the visual reference, not an actual runtime or a promise of pixel-identical font rasterization. Layout, controls and interactions are shared; window chrome and platform shortcuts follow the OS. Check scaling, reduced motion and accessibility using actual WebViews. #148 owns the complete feature UI.
Acceptance criteria
Validation and evidence level
Native builds and rendered WebView checks on all three systems, focused Go IPC/lifecycle tests plus vet/lint/race, frontend check/build and hostile navigation/bridge probes. Cite exact Wails/toolchain versions. Useful primary references: https://wails.io/docs/gettingstarted/installation/ and https://wails.io/docs/guides/frontend/ . Source checks or cross-compilation alone do not establish desktop readiness.
Dependencies and risks
Depends on #142. This foundation precedes #144 and #148. #143 inventory parsing can proceed independently after #142. If a required platform or bridge restriction fails, dependent integration remains blocked on a scoped fix with explicit evidence.
Out of scope
Production SSH/vault/history behavior, final product UI, restoration of the retired remote coordinator, automatic controller updates or a production browser fallback.
Delivery boundary
One implementation branch/PR closes this issue only. Parent #141 remains open until all required phases pass. No secrets, real prompts or private device logs in GitHub evidence.
Parent tracking issue: #141. Phase 2 of 11.
Objective
Establish and test the desktop window and per-user controller foundation on macOS, Windows and Linux before credential and execution integration depend on it.
Scope
Deliver a minimal reusable Wails v2 shell, React/TypeScript fixture UI and independent Go controller with no live SSH actions or real credentials. Pin a reviewed stable v2 patch and its Go/frontend toolchain. Build on native runners; record supported OS versions, CPU architectures, Linux distributions, X11/Wayland sessions and required WebView runtimes. Separate developer build tools from installed-user dependencies. Missing runtimes or graphical sessions must produce actionable states. Verify package installation and launch on clean supported systems; release signing/notarization and uninstall behavior belong to #148.
The window runs in the logged-in graphical user's session. The controller is a separate process owned by that user, not a privileged service that tries to show UI from Windows session zero. Specify start-on-demand and termination policy, window close versus explicit controller stop, logout, sleep/resume and restart. No guarantee that a controller stays alive through OS logout or sleep. Later reconciliation recovers the same request identity without re-dispatch. One controller owns mutable local state. Protect Unix sockets and Windows named pipes with OS identity/ACL checks, verify the expected server identity, bound frames, version the IPC handshake, and reject incompatible app/controller versions. Prevent another user or session from stealing the endpoint or focus target. Existing Atenea IPC/build constraints must be handled explicitly without porting the whole daemon by assumption.
Audit the COMPLETE JS-to-native surface of the pinned Wails build: framework runtime calls, generated Go bindings, events, navigation, external URL schemes, clipboard, downloads and file drops. A small Bind list or omitted JS wrapper is not evidence that a native operation is unreachable. Restrict the host-side dispatcher or other proven enforcement points where necessary, and test direct bridge calls that bypass UI controls. Never expose arbitrary shell or filesystem operations. Document any framework capability that cannot be restricted and resolve the required boundary before passing this gate; do not silently switch frameworks or claim a capability sandbox that was not implemented. Use packaged local assets, compatible CSP, bounded input validation and no production browser control endpoint. Development servers only use synthetic fixture data.
Provide a reference UI with sidebar, searchable host list, detail and history fixtures. Record design tokens, typography/icon assets licensed for all three platforms, light/dark states and keyboard/focus behavior. SwiftUI is the visual reference, not an actual runtime or a promise of pixel-identical font rasterization. Layout, controls and interactions are shared; window chrome and platform shortcuts follow the OS. Check scaling, reduced motion and accessibility using actual WebViews. #148 owns the complete feature UI.
Acceptance criteria
Validation and evidence level
Native builds and rendered WebView checks on all three systems, focused Go IPC/lifecycle tests plus vet/lint/race, frontend check/build and hostile navigation/bridge probes. Cite exact Wails/toolchain versions. Useful primary references: https://wails.io/docs/gettingstarted/installation/ and https://wails.io/docs/guides/frontend/ . Source checks or cross-compilation alone do not establish desktop readiness.
Dependencies and risks
Depends on #142. This foundation precedes #144 and #148. #143 inventory parsing can proceed independently after #142. If a required platform or bridge restriction fails, dependent integration remains blocked on a scoped fix with explicit evidence.
Out of scope
Production SSH/vault/history behavior, final product UI, restoration of the retired remote coordinator, automatic controller updates or a production browser fallback.
Delivery boundary
One implementation branch/PR closes this issue only. Parent #141 remains open until all required phases pass. No secrets, real prompts or private device logs in GitHub evidence.