The SSL fix shipped and did not reach the machine it was written for. That log said so, one line above the tick: behavision is already installed with the same version as the provided wheel. Use --force-reinstall to force an installation of the wheel. [ok] Engine and dependencies installed and the traceback below it still pointed at model_assets.py line 59, urllib.request.urlretrieve - code the fix had deleted. Two frozen literals caused it: version = "1.1.0" in pyproject.toml and __version__ = "1.0.0" in behavision/__init__.py. They disagreed with each other and neither tracked a release, so every release built behavision-1.1.0-py3-none-any.whl and pip install --upgrade on a machine that already had 1.1.0 is a no-op. The comment beside that call claimed the opposite. The shape of the damage is what makes it bad. The Go binaries - app, agent, setup tool - are rebuilt every release and updated normally. So a shop PC ran a current app supervising an engine several releases old, and nothing said which: /api/health reported the model, the paths, the cameras and the gallery, and no version at all. - One version, in the package, read by pyproject through [tool.setuptools.dynamic]. In a checkout it reads 0.0.0+dev: a plausible-looking number on a developer's /api/health is worse than none. - pip install --force-reinstall --no-deps <wheel>, after the ordinary --upgrade. --upgrade settles the dependencies; the second call guarantees our own code is the code in the folder. --no-deps keeps it cheap - forcing the dependencies too would re-download ~300 MB every run. A rebuild at an unchanged version is the ordinary case while developing, so this must not rely on the version moving. - release.sh stamps the tag: v0.5.6-demo -> 0.5.6+demo, valid PEP 440. Into a copy of the line, reverted in a trap, so the tree is never left dirty. /api/health reports version now. Without it there is no way to tell a shop PC three releases behind from a current one, which is how this survived several releases. Reproduced end to end before fixing, against real wheels on Python 3.12: two builds of the same version, --upgrade leaves the old code in place and prints the same sentence the colleague's Mac printed, --force-reinstall --no-deps replaces it. 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