Files
Behavision/desktop
Suriyakumarvijayanayagam 7021d5d2f5 The shop app gets its help panel, and its last two old screens catch up
Ask Behavision: a panel beside any screen that talks to the head-office
assistant as the signed-in user - setup questions and 'is my shop
working' answered by the same thing, without leaving the app. The
assistant's prompt now knows how the product is set up (installation
codes, adding a camera, what a placement verdict means, the model
download on first run), so it is the help and not only the analyst. A
PC running on its own has nobody to ask and gets the essentials as text.

Cameras and Customers were still on the pre-redesign markup - the add
camera drawer ran off the right edge of the window because it used a
class the new stylesheet never sized. Both are rebuilt: cameras as
picture-led cards with connection and 'proven' as two separate claims
and a placement check laid out as the two steps it is; the customer
record as a proper sheet.

mock.js renders the app in a browser with fake bindings
(?mock=fresh|standalone|claimed, dev server only), so a screen can be
put in front of somebody without a Windows build. It is how these were
reviewed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
2026-09-19 13:22:16 +05:30
..

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.