leonarski_fandClaude Opus 5.5
7349832309
The live panel showed ~80 Hz on a 100 Hz collection. Its clock started when the receiver had applied and forwarded the START message, so the START -> first image gap counted as collection time; the images were stamped when a forward thread dequeued them, and the last image only after END and the thread joins; and N images were divided by a span holding N-1 intervals. - ImagePullerOutput carries `received`, a steady_clock time set by the TCP and ZeroMQ pullers as the message comes off the socket, before it is queued or deserialised (TestImagePuller stamps it on Put when unset). - RugnuxLiveStatus takes those times: START's for its origin, each image's for the first and last image (min/max, as forward threads report out of order). last_image_s is the last data image's puller time. - Zero of every reported time (elapsed_s, steps' started_s, probe_s, last_image_s, cut_s) is now the FIRST IMAGE, as the frontend already said; before the first image arrives "now" is 0 and earlier steps are negative. The START -> first image time is recorded on its own as start_to_first_image_s (snapshot, OpenAPI rugnux_live_status, regenerated C++ model and frontend client, OpenAPIConvert). - The frontend rate is (images_received - 1) / (last - first image); the panel headers show "START -> first image X.X s". - The broker logs "rugnux live: START -> first image ..., N images in T s from the first to the last (R Hz)"; "done X s after the last image" and last_image_to_written_s run from the puller time of the last image. The deadline timer is unchanged (it still starts once the forward threads have joined). No analysis result changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PXc1zD1yxHqaR1DGdCTHL4
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.