Cross-check the capture-watch preflight against the live camera selection

[xmap]

Two independent commits, both prompted by the 2026-08-20 disk-full incident at APS 2-BM.

1. Camera-prefix cross-check in the capture-watch preflight.

capture_watch_pvs's full_file_name role is a hardcoded PV string carrying one camera's prefix, and nothing makes it follow 2bm:MCTOptics:CameraSelect. During the incident the operator switched from camera 2 to camera 1, which would leave that role reading the idle camera's stale filename readback. That value is exactly what RunWitnessRecorder vaults into run_capture_path as the Run's capture path, and it is personal data.

The preflight gains one report line, camera_prefix_check, emitted only when a code declares both full_file_name and a new optional camera_selected role. It reuses readings the existing sweep already took (no second control_port.read()) and never reports a clean match on anything it cannot confirm: an unreadable PV, an empty mapping table, and an unrecognized reading are each their own distinct bad verdict.

The reading-to-prefix mapping is a deployment-declared table (Settings.capture_camera_select_prefixes), not hardcoded. CORA does not know whether the live CameraSelected resolves to a bare index or an ENUM label, and must not guess. The camera-index-to-prefix fact itself is confirmed by deployments/2-bm/beamline.yaml (DET-11, operator-verified 2026-06-19); the wire format of the readback is left for beamline staff to confirm when they configure the role.

Live risk today is zero because run_witness_recording_enabled is off at 2-BM. That is precisely why this lands before it is turned on.

2. DATA-8 gains a third data point.

The row asks whether dropped frames are rare-and-alarming or routine. Its two existing data points are both files that closed cleanly. The 2026-08-20 scan is a different shape: the disk filled mid-acquisition, the saved-frame counter fell behind the collected-frame counter, and the file it left cannot be counted at all. It opens, but reading the frame-index dataset raises an HDF5 address-overflow error with end-of-allocation at 2048 bytes.

That matters for the answer the row is gathering evidence toward. A shortfall check modelled only on "fewer frames than commanded" cannot express this outcome, because there is no readable count to compare against.

Deliberately not touched: the storage-tier account in operations.md and the HOST-2 row. Both were already corrected on main (#684, #696), and their current text, that the write target is an operator-settable PV re-measured to /local1 on 2026-08-19 with older scans still on /local2, is better sourced than anything this incident adds. An operator recollection that both tiers are in concurrent use is worth confirming with the beamline before it is written down as fact.

Testing. 1,011 tests pass (preflight unit tests plus the full deployments tier, including the open-questions alignment guard). The camera tests were rewritten during review: all five originally configured a placeholder PV whose prefix matched nothing in the table, which made the match case fail and, worse, made the mismatch case pass regardless of which camera was selected. They now configure a real camera-prefixed PV so match and mismatch differ only in the camera reading.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
apps/api/src/cora/api
capture_watch_preflight.py					467
apps/api/src/cora/infrastructure
config.py
Project Total

This report was generated by python-coverage-comment-action