`processing.rs:532` writes `calibration.json` into the sample output directory by spelling the filename inline. `artifacts.rs` holds every other per-sample artifact name as a constant (`RESULTS_PARQUET`, `RUN_REPORT`, `CONFIG_USED`, ...) and `PER_SAMPLE_ARTIFACTS` is what the sink finalizes and uploads, so the calibration file sits outside the list that defines what a sample output is.
Two consequences:
- Anything that enumerates a sample's artifacts (upload, cleanup, a future reduce stage) does not know the file exists.
- The name can drift from the reader in `calib_dash` and `rt_calibration.rs`, which is the failure mode `artifacts.rs` exists to prevent.
Fix: add a `CALIBRATION_JSON` constant, use it at the write site and in `PER_SAMPLE_ARTIFACTS`, and have `calib_dash` read the same constant or a re-export of it.
Context: a cross-run reduce stage will need each run's calibration curve to push observed RT back into library space, so this file becomes part of the per-run contract rather than a debugging aid.
`processing.rs:532` writes `calibration.json` into the sample output directory by spelling the filename inline. `artifacts.rs` holds every other per-sample artifact name as a constant (`RESULTS_PARQUET`, `RUN_REPORT`, `CONFIG_USED`, ...) and `PER_SAMPLE_ARTIFACTS` is what the sink finalizes and uploads, so the calibration file sits outside the list that defines what a sample output is.
Two consequences:
Fix: add a `CALIBRATION_JSON` constant, use it at the write site and in `PER_SAMPLE_ARTIFACTS`, and have `calib_dash` read the same constant or a re-export of it.
Context: a cross-run reduce stage will need each run's calibration curve to push observed RT back into library space, so this file becomes part of the per-run contract rather than a debugging aid.