8f07dee04827b31cbd3e393d0cfff0915deda85b
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 8f07dee048 |
The engine stopped updating, and said "installed" every time
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 |
|||
| ff4f95c3b0 |
Four silent failures a demo on somebody else's Mac walked straight into
Three reported from a colleague's machine, plus one the fixing uncovered. Every one produced a message that was true and useless. ## behavision-setup chose the Python least likely to work findPython walked 3.14, 3.13, 3.12, 3.11, 3.10 and took the first hit - a floor with NO ceiling, which is exactly backwards. The newest Python on a machine is the one least likely to have binary wheels. It picked 3.14, pip found no numpy wheel for cp314, fell back to building numpy from source and produced "Unknown compiler(s)"; once the operator had installed Xcode's command line tools to get past that, ten minutes of compiling ended in "<arm_neon.h> is intended only for ARM and AArch64 targets". maxMinor refuses in one line before anything is downloaded, and "too new" is a different message from "too old" - telling somebody holding Python 3.14 that no Python was found sends them to install a newer one, which is the direction that just failed. ## numpy<2.0 was the cap; OpenCV was the hazard Widening it needed proof, and the proof found something else. Nine runs of the detector guard per combination, one machine, one sitting: numpy 1.26 / cv2 4.11 9 passed, 0 crashed numpy 2.0 / cv2 4.11 8 passed, 1 crashed numpy 1.26 / cv2 4.14 3 passed, 6 crashed numpy 2.0 / cv2 4.14 2 passed, 7 crashed numpy is not the variable; OpenCV is - the third row is numpy 1.26. The crash was test_a_shared_detector_really_does_race, which races a shared cv2.FaceDetectorYN on purpose. That is undefined behaviour in C++: 4.11 usually turned it into an exception, 4.14 usually turns it into a segfault, and 4.11 crashing once says the hazard was always there. It never reached the product - Engine._build_worker builds a detector per camera. It reached the suite: two runs in three died with no failing assertion in them. The race runs in a subprocess now, and one clean attempt proves nothing, so the premise holds if any of several attempts misbehaves. 226 passed / 2 skipped on numpy 2.0.2, five runs of five. opencv stays capped below 5: everything above was measured on 4.x, and an uncapped >=4.8.1 gives every NEW install a major release this project has never run a real camera through. ## One MQTT client id for a whole shop, so two PCs fought over it behavision-<client>-<site> is the same string on every computer claimed to one site. MQTT requires unique client ids and a broker enforces it by disconnecting the older session, so the colleague's Mac and the shop's own till took turns kicking each other off: broker connected / broker connection lost: EOF / broker connected / EOF ... The damage is not confined to the new machine. The till is the other half of that loop, so signing in on a laptop to look at the product stops a live shop delivering visits - and from each end it reads as an unstable network. MQTTClientID() appends a per-installation id, minted on first load and written back so an existing install gets one without anybody doing anything. The site stays in the name because that is what a broker log is read by. An unwritable config falls back to a per-run id rather than a shared one. ## "no such file or directory" for an engine nobody had installed Pressing Start went straight to the supervisor, which reported what exec reported: a 200-character path ending in "no such file or directory". Every word true, none of it saying "run the setup tool" - the startup path had that sentence, in a log file nobody on a shop counter opens. engineMissing() is the one function the startup path, the Start button and the status panel all consult. It also names App Translocation, which was in that path and is unguessable: macOS runs a downloaded unsigned app from a random read-only copy, so relative paths resolve inside it and an install there would not survive a restart. The product is unsigned, so that is the normal first-run state on every Mac, not an edge case. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj |
|||
| 4c62fc0ef3 |
The Loyaly mark everywhere a person sees the product
Brand assets in brand/ (the 512px mark, sizes for each surface, a multi-size .ico). Windows executables carry it as a compiled-in resource (rsrc_windows_amd64.syso from go-winres) so Explorer, the taskbar and the installer show it; installer/build.ps1 therefore uses a plain go build rather than wails build, which would add a second copy and fail the link. The tray icon is the mark with a state dot over its corner - a plain coloured circle read as a generic status light among other icons - rendered from the embedded PNG at 32px so it survives 150% scaling. The desktop app's login, setup and sidebar marks, the head-office web app's mark and favicon, and the engine dashboard's favicon are the same file. Also found while packaging: no wheel so far shipped static/, so the engine's own dashboard at :8010 on a Windows source install would have failed with a missing file. package-data now includes it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj |
|||
| e262fc8482 |
The live picture was chained to the recognition pipeline
Reported from the first Windows install: the camera feed lags. It did, and not because of the network, the proxy or the webview. The MJPEG stream served _annotated_jpeg - the frame the pipeline had most recently FINISHED with, encoded after detection, quality scoring, tracking and identification had all run on it. On a modest shop PC that is a few frames a second, and every picture was already as old as that processing. It looked like lag because it was lag. On the fast machine it was developed on the pipeline kept up with the stream's own 10 fps cap, which is why nobody here ever saw it. Two more things compounded it. Every processed frame was JPEG-encoded whether or not a viewer existed - CPU spent on precisely the machine short of it. And ffmpeg ran its RTSP demuxer with default buffering, which holds a comfortable queue of frames before handing over the first: half a second to two seconds a live view can never recover. Now the picture and the boxes are decoupled. latest_jpeg_since takes the capture thread's freshest frame at the camera's own rate and draws the boxes from the last processed frame over it - encoded on demand, per request, so a camera nobody watches costs no encode at all. The stream sends a frame only when the camera has a newer one, capped at 15 fps; nothing is sent twice. Boxes older than a second are not drawn, so a stalled pipeline cannot leave one floating over an empty spot. _publish_annotated becomes _remember_tracks: a handful of tuples under the lock, no copy, no encode. ffmpeg gets nobuffer / low_delay / max_delay. Measured on cam2's sub-stream, same machine, ten seconds each: before 99 frames sent, 98 distinct 9.8 new pictures/s after 141 frames sent, 141 distinct 14.0 new pictures/s against a 15 fps camera, with the pipeline still processing 166 of 181 captured frames alongside - and engine CPU DOWN from 90% with no viewer to 62% with one attached. Engine version 1.0.0 -> 1.1.0 so a re-run of setup reinstalls it rather than pip deciding the requirement is already satisfied. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj |
|||
| b59e667a68 |
A demo release with the office cameras sealed inside it
Wanted: install it and the two office cameras are already there - but without the release carrying their admin password where anyone with the zip can read it. "Encode it" does not achieve that; anything the installer can decode, anyone holding the installer can decode. pkg/demo seals the camera list with AES-256-GCM under a key that is NOT in the package: a 120-bit unlock code minted when the bundle is sealed, given to whoever runs setup by voice or message, typed once. The code is random, so it is key material directly through SHA-256; a human- chosen passphrase would need a KDF and a dependency, 120 random bits do not. The sealed file contains the format marker and noise. Tested: the password and the host do not appear in it, a wrong code and a flipped byte are both refused as ErrWrongCode, every seal differs. behavision-demo-pack seals; it runs on the build machine and is never shipped. The code is printed once and stored nowhere. behavision-setup, on finding demo-cameras.enc beside the engine source, asks for the code BEFORE the ten-minute download so a mistyped one costs seconds, and adds the cameras at the end - through the running engine's own Add Camera endpoint, not by writing its file. The store's save() is what applies DPAPI to the password on Windows, so this is how the credential ends up encrypted and machine-bound on the demo PC rather than in cameras.json for anyone who can read ProgramData. It then marks the PC standalone, so the app opens on Live instead of asking for an installation code it will never get. Which found the gap that DPAPI only works if pywin32 is importable, and nothing had ever pulled it in - every Windows install to date would have logged the warning and written camera passwords in the clear. Added as a Windows-only dependency. Verified in a clean container: a wrong code refused, the right one unlocks two cameras, every install step passes, both cameras added through the API, standalone set. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj |
|||
| dad04e8cda |
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
|
