Behavision: face recognition for retail, edge to head office

Five components that ship as one product:

- behavision/  the recognition engine. RTSP ingest, YuNet detection, IoU
               tracking, ArcFace embeddings, a FAISS/SQLite gallery, and a
               FastAPI dashboard. Identity is decided once per TRACK from an
               average of at least three embeddings, never per frame.
- agent/       the Go edge agent: supervises the engine, holds a durable
               spool, and drains it to MQTT. Nothing is acked before the
               broker confirms.
- desktop/     the shop PC application (Wails + React + tray).
- server/      the cloud API, MQTT consumer, reports and assistant.
- web/         platform.loyaly.ai, the head-office app, embedded in the
               server binary.

The gallery stores 512-float embeddings and timestamps - no images unless
`app.store_faces` is switched on. Those embeddings are biometric personal
data under GDPR and India's DPDP: template inversion reconstructs a
recognisable face from an ArcFace vector, so data/behavision.db is treated
as a biometric database and DELETE /api/visitors/{id} is a real erasure.

CLAUDE.md carries the reasoning behind every non-obvious decision here,
including the ones that were measured and the ones that were wrong first.

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

agent/README.md

@@ -0,0 +1,44 @@
+# 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