Suriyakumarvijayanayagam
9521cb986b
`wails build` had never been executed against this project - CLAUDE.md says so plainly - so every screen the shop floor actually touches was unreviewed. Running it found why nobody had. fyne.io/systray's nativeLoop must own the main thread on macOS, a Cocoa requirement, and Wails already holds it. Starting both kills the process with a SIGTRAP inside cgo before a single pixel is drawn. On Windows, which is what ships, a tray on its own goroutine is fine - so the one platform the whole team develops on was the one platform that could not open the app, and the UI went unlooked-at as a result. BEHAVISION_NO_TRAY runs the window without the tray, the same escape hatch BEHAVISION_ALLOW_PLAINTEXT_MQTT already is for the broker. Deliberately an environment variable and NOT a GOOS check: a build that quietly drops the tray is how a shop PC ends up with no control surface at all, and it would fail where nobody is watching. The guard is on stop() as well, because systray.Quit() on a systray that never started is not a no-op in v1.12.2 - it would turn closing the window into a crash on exit, the failure most likely to be shrugged off as "it closed, fine". go.mod gains the indirect dependencies the darwin build pulls in. No version moved: the committed list was written by a windows-only build, which never resolves that part of the Wails tree. Verified: GOOS=windows build, go vet, and the agent suite all still pass, and the packaged .app runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qiy5iKfz4L8S4vRaYPBdaU
Behavision desktop
The store-facing app: a tray icon, a window, and the supervisor for the Python recognition engine.
Why one process, not three
The tray, the window and the supervisor all need the same state, and a user who quits the tray expects recognition to stop. Splitting them means two things can disagree about whether the engine is running.
It is deliberately not a Windows service. A service runs in session 0 and cannot draw a tray icon — that is Windows session isolation, not a library limitation. Spawning a child process also needs no elevation, while controlling a service does, so this design never triggers UAC at runtime.
Layout
main.go wails.Run, window options
app.go the methods bound to the frontend
tray.go fyne.io/systray — wails v2 has no tray of its own
icons.go tray icons generated at run time, not embedded
internal/local client for the engine on 127.0.0.1:8010
internal/cloud client for https://mcp.loyaly.ai
frontend/ React + Vite
The supervisor, durable spool, broker client and path resolution come from
../agent/pkg/* — the same tested code the headless agent runs, imported
rather than copied.
Build
cd frontend && npm install && npm run build # then, from this directory:
wails build -platform windows/amd64
wails build needs the Wails CLI:
go install github.com/wailsapp/wails/v2/cmd/wails@v2.9.2
Without it, go build still type-checks everything provided
frontend/dist exists — the embed directive requires it.
What the frontend talks to
Nothing is imported from generated bindings. src/bridge.js calls
window.go.main.App.* directly, so npm run build works without running
wails generate, and there is one place that handles "the engine is not
running yet" — the state every screen has to survive on a fresh install.