Lesson 16 — Electron shell and secure renderer

Outcome

Turn the desktop scaffold into a safe shell that starts/stops the Go core and renders a basic Forge window.

Why this comes now

We intentionally bring UI in now instead of waiting until every backend feature exists. This validates whether the architecture maps naturally to real usage.

Understand

Electron has privileged main-process capabilities and an untrusted-style renderer boundary. The renderer should behave like a web client: no direct local command/filesystem access. Main starts the Go core, monitors it, and supplies only the narrow connection/bootstrap information needed by the renderer.

Build the real project

1. Configure BrowserWindow with context isolation, no Node integration, and sandbox.
2. Implement main-process Go core lifecycle for development (or connect to a separately started core if that is simpler first).
3. Generate/hand off a random local session credential securely.
4. Add preload only for narrowly required desktop features; RPC can remain normal loopback HTTP from renderer when policy permits.
5. Show server/core status in the app.
6. Handle core startup failure visibly.

Completion gate

Electron security settings are asserted/reviewed. The renderer cannot import Node filesystem/process APIs. Close/reopen starts/stops or reconnects to core predictably.

Pitfalls to avoid

Do not put Task business rules in Electron main. Do not add a generic IPC “run command” bridge. Do not enable Node integration to save five minutes.

References

Required: Electron security, Electron process model. Read SECURITY.md.

Checkpoint

Note any Linux/Wayland/AppImage lifecycle issue in the Learning Log; desktop platform behavior is evidence-driven.