Suriyakumarvijayanayagam
0b29dd4a50
Nothing ever set the child's working directory, so it took the parent's - and an app started by double-clicking its bundle is handed "/", not anywhere useful. On macOS the symptom was `python: No module named behavision` repeating forever, because the dev engine is invoked as `-m behavision` and that resolves against the working directory. The same app launched from a terminal inside the repo worked perfectly, which is exactly the shape of a bug that survives every test a developer runs. It only appeared when the app was started the way a user starts one. Config.EngineDir, empty meaning the install root, set by both launchers - the desktop app and the headless agent, which had identical code and the identical omission. It matters beyond this case: the shipped Windows engine is a one-folder PyInstaller build whose relative paths should resolve beside itself rather than beside Explorer's idea of a current directory. Verified by double-clicking the bundle with nothing in the environment: engine up on 8010 (401, gated), w600k_r50 on CoreML, gallery 5/5 embeddings usable and none stranded, both office cameras connected and streaming, and head office reporting cameras 2/2 one heartbeat later. Two things that showed up while proving it, both the product being honest rather than faults: - The camera at .121 was genuinely unreachable for several minutes, and last_error said so in words an installer can act on - "cannot reach 192.168.1.121:554 - No route" - rather than `connected: false`. That field was added yesterday for precisely this. - Head office briefly showed cameras 0/1 against a local 2/2. That is a 60-second heartbeat, not a disagreement; the next one read 2/2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj
Behavision agent (Go)
The half of the edge install that touches the network. The Python engine keeps the cameras and the models; this keeps the tray icon, the UI shell, the MQTT connection and the offline queue.
┌─ agent (Go) ───────────────────┐ ┌─ engine (Python) ────────┐
│ tray icon + WebView2 window │ │ RTSP capture │
│ supervises the engine process │───────▶│ YuNet / ArcFace / FAISS │
│ MQTT publish + offline spool │◀───────│ SQLite (biometric) │
│ S3 handoff, tenant config │ local │ localhost API + events │
└────────────────────────────────┘ HTTP └──────────────────────────┘
Why the split
Go cannot run ONNX, OpenCV or FAISS, so the engine stays Python and ships frozen. Go is here for what it is actually better at: a durable queue that survives a store's internet dropping, a supervised child process, and one language shared with the server so the MQTT contract has a single definition.
Why 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. Since the product is "user starts and stops it from the tray", the agent is a normal user-session process that spawns the engine as a child. That also means it never needs elevation at runtime: starting a child process does not, controlling a service does.
internal/engine is written so a service wrapper can be added later without
touching the supervision logic.
Layout
main.go entry point, mode dispatch
internal/engine start/stop/supervise the Python engine, health polling
internal/spool durable event queue (survives restart and outage)
internal/mqtt broker client, publishes from the spool
internal/config tenant identity, broker settings, credentials
frontend/ React UI served into the WebView
Build
go build ./... # agent alone
wails build # agent + frontend, once the UI is added