The self-calibrating detection threshold was reachable from rugnux and the viewer but not online: spot_finding_settings carried no adaptive_threshold, so the receiver always ran the fixed-threshold finder and the fused GPU engine sat unused behind it. adaptive_threshold and false_pixels_per_frame are now part of the schema, both optional so an existing client that sends neither is unaffected, wired through OpenAPIConvert in both directions and surfaced in the frontend panel, where turning the mode on greys out the count threshold it replaces and reveals the operating point it uses instead. The C++ server model and the TypeScript client are regenerated from the spec; the Python client is generated but not tracked. Enabling it is REFUSED where spots are found on the FPGA - the JUNGFRAU and EIGER workflows - rather than accepted and ignored, because a detection setting that silently had no effect cannot be told apart from one that did. The DECTRIS/SIMPLON workflow, which analyses images in software, accepts it. Verified against a running broker: adaptive_threshold true is rejected with that message and leaves the stored settings untouched, while false and omitted both succeed. It stays off by default online, unlike rugnux and the viewer. The broker serves both workflows and the default has to be the one that works on either. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Jungfraujoch Frontend
Building
To build web interface:
cd frontend_ui
npm install
npm run openapi
npm run build
Available Scripts
In the project directory, you can run:
npm start
Runs the app in the development mode.
The page will reload if you make edits.
You will also see any lint errors in the console.
npm test
Launches the test runner in the interactive watch mode.
See the section about running tests for more information.
npm run build
Builds the app for production to the dist folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
npm run openapi
npm audit findings
npm audit currently reports 17 advisories (3 high, 13 moderate, 1 low). All of
them live in build-time tooling and never reach the production bundle
shipped to the browser. Summary of the chains:
| Source dep | Vulnerable transitives | When it runs |
|---|---|---|
@redocly/cli |
@opentelemetry/*, dompurify (via redoc), ws (via simple-websocket), js-yaml, protobufjs, @babel/core |
npm run redocly / redocly4broker — static OpenAPI HTML generation |
vite |
esbuild@0.27.x |
Dev server and dep pre-bundling. Production build uses Rollup. |
vite-plugin-svgr |
@babel/core, js-yaml (via cosmiconfig) |
Vite build plugin |
openapi-typescript-codegen |
js-yaml |
npm run openapi — TS client generation |
Notes on the high-severity items:
esbuildGHSA-gv7w-rqvm-qjhr is a Deno-specific RCE viaNPM_CONFIG_REGISTRY; GHSA-g7r4-m6w7-qqqr is an arbitrary-file-read in the dev server on Windows. Neither applies to a Linux build of the production bundle.wsGHSA-96hv-2xvq-fx4p only matters whensimple-websocketopens a socket, which happens during docs generation, not at runtime.
npm audit fix cannot resolve any of these without downgrading
@redocly/cli (no real fix) or jumping vite to a major that switches the
bundler to Rolldown.