Files

Suriyakumarvijayanayagam 719ba2c7f5 Recognition starts with the app, not with a button

The engine only ever started when somebody pressed Start. So a till
that rebooted overnight came back with the window open, the tray icon
showing, the session restored - and recognition off until a shop
assistant noticed. That is the failure the tray colours exist to catch,
and it should not be the default state every morning.

Guarded on the interpreter actually existing: on a PC where setup has
not run yet, the supervisor would loop on a missing executable with
nothing useful to say. Start and Stop remain for the case where somebody
has deliberately stopped it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj

2026-09-11 12:49:56 +05:30

frontend

The shop PC's avatar had the same V1 collision

2026-09-07 12:45:38 +05:30

internal

A customer number people can say out loud

2026-09-07 11:52:32 +05:30

app.go

Recognition starts with the app, not with a button

2026-09-11 12:49:56 +05:30

env.go

Behavision: face recognition for retail, edge to head office

2026-09-04 11:14:18 +05:30

go.mod

The shop PC's UI had never once been run

2026-09-09 13:06:51 +05:30

go.sum

The shop PC's UI had never once been run

2026-09-09 13:06:51 +05:30

icons_test.go

Behavision: face recognition for retail, edge to head office

2026-09-04 11:14:18 +05:30

icons.go

Behavision: face recognition for retail, edge to head office

2026-09-04 11:14:18 +05:30

main.go

The camera tiles put a password in the page, and loaded nothing

2026-09-10 19:53:28 +05:30

README.md

Behavision: face recognition for retail, edge to head office

2026-09-04 11:14:18 +05:30

standalone_test.go

The schema applies itself, and the setup script stops hiding failures

2026-09-04 12:06:52 +05:30

stream_proxy_test.go

The camera tiles put a password in the page, and loaded nothing

2026-09-10 19:53:28 +05:30

stream_proxy.go

The camera tiles put a password in the page, and loaded nothing

2026-09-10 19:53:28 +05:30

tray.go

The shop PC's UI had never once been run

2026-09-09 13:06:51 +05:30

wails.json

Behavision: face recognition for retail, edge to head office

2026-09-04 11:14:18 +05:30

README.md

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.