leonarski_fandClaude Opus 5
6fe3f30ab4
The JSON a calibration writes was a shape invented at its writer, described only by the comments around it. That is enough for a file somebody reads with jq and not enough for anything else: a client cannot type it, and an endpoint returning it later would have to declare the shape a second time and keep the two in step by hand. So declare it where every other shape in this system is declared. calibration_output holds dataset_settings and a calibration member; the latter is calibration_quality, which nests calibration_fit_sigma and calibration_spot_check. The descriptions carry what a reader has to know to use the numbers rather than only what they are named - that beam_x_pxl is the PONI and the direct beam is elsewhere, that the rotations travel together because a body omitting them states a flat detector, that a tilt below about three sigma was declined and pinned, and that the two correlations approach 1 as the tilt stops being separable from the beam centre. Nothing references it yet. It is declared now because /powder_calibration will return exactly this, and because the file rugnux already writes is decodable today: jfjoch_client's CalibrationOutput.from_dict reads it as it stands, with o.calibration.fit_sigma.correlation_beam_x_rot1 and the rest typed. Generated clients regenerated from the spec, as the spec requires: the C++ server model (four new pairs under broker/gen/model), the TypeScript frontend client, and broker/redoc-static.html. Both regenerations are purely additive - no existing generated file changed except to export the new names. The python client regenerates from the same spec and is gitignored. The test now validates the WHOLE file against the generated Calibration_output rather than only its geometry member against Dataset_settings, so the quality block is under the same contract: a field renamed or newly required in jfjoch_api.yaml fails here rather than at a client. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NfuDvf5ipV3Hi8TiCUKD27
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.