leonarski_fandClaude Opus 5
aa6073d41f
The Smargon at the SLS 2.0 MX beamlines reports its own axis positions with readout noise, so a chi parked at zero comes back as about -1e-7 degrees. The schema bounded chi_deg to [0, 90], so an ordinary "chi is at zero" setup was refused - and the same holds at the other end of the arc, where a chi parked at 90 reads just above it. Both end-stops are exactly where a static positioner is left, so widening the range would only move the problem. The bound bought nothing. Chi never enters any computation: OpenAPIConvert puts it in SmargonPosition, DiffractionExperiment::BuildTransformationChain hands it to a rotation transformation verbatim, HDF5NXmx writes it and HDF5MetadataSource reads it back. No downstream reads its sign, and a rotation is defined for any angle. phi, the sibling angle in the same object with the same semantics, has never been bounded. What was left was a restatement of a hardware travel limit that the goniometer enforces itself, and its only observable effect was to refuse a value the instrument genuinely reported. It was also not enforced where a server-side check would matter: the cpp-pistache-server generator does not recurse into a nested object model, so Dataset_settings::validate never calls the Smargon model's. The rejection was raised by the generated python and TypeScript clients, which do check. Regenerated the C++ server model, the TypeScript client and redoc-static.html; python-client is gitignored and comes from gen_python_client.sh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EFEJG6WBQv8th4UJFNe53N
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.