# 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