7.4 KiB
K1 live reference comparison and missing camera
Scope: operator-local K1 Bridge data acquisition on canonical Mission Core 8000. No new physical START, STOP, provisioning or RTSP request was sent during this investigation. The comparison uses the existing 6 September capture.
Authoritative references found in Ops
MISSIONCOR-3, “Mission Core. Lixel K1 / XGRIDS Integration”, block “Внутренние эталоны Mission Core” and its comment dated 22 August 2026 identify:
- Fast reference A:
eaad9de, 20260822T105904Z_viewer_live. START to calibration under 5 seconds; calibration 21 seconds; after calibration cloud 2 seconds, right camera 4 seconds; STOP to physical onset 1 second. - Recovery reference B:
1001a31, 20260822T130323Z_viewer_live. START 14 seconds; calibration 22 seconds; cloud +1 second, camera +8 seconds; STOP onset 7 seconds.
The linked canonical report is Lab 010. These are measured internal references for one K1 FW 3.0.2 and Bridge/direct LAN, not a transferable SLA or a standalone Rerun preset. A used a short physical ledger; B retained mature recovery history. Source quality was not reduced.
MISSIONCOR-66, “Mission Core. Канон интеграции Rerun”, and MISSIONCOR-74, “Additional Core · Переносимая кастомизация Rerun”, define the separate presentation contracts:
| Surface | Current profile | Clock and media |
|---|---|---|
| Live acquisition | live-acquisition | stream_time; upstream live Rerun; right camera through the independent RTSP → durable fMP4 → MSE path |
| Saved Sessions / Data | recorded-session | session_time; progressive recorded admission; RecordedFmp4Player follows the shared playback clock |
| Canonical LAB result | laboratory-result | session_time; result-specific settings; merged RRD with native AssetVideo/VideoFrameReference; separate presentation gate |
The live receiver does not inherit the LAB full-readiness gate. Changing point size, accumulation or blueprint cannot repair a camera producer that never started. The current live display settings include accumulation 47 seconds, point size 1 and height/viridis; no evidence identifies those visual values as part of the fast reference, so they were not arbitrarily reset.
Settings isolation limitation found during the audit
Distinct profile kinds, clocks and media admission do not prove complete settings isolation. App.tsx still owns one sceneSettings/displayDraft pair for live and Data, and useWorkspaceLayoutProfile() loads and saves one observation.spatial profile containing scene settings. The normal settings committer suppresses backend writes while recorded replay is presented, but it still updates the common in-memory settings. The persisted layout restore/apply path also has no profile-kind namespace. LAB uses its own resultId-scoped draft and durable view profile.
Therefore this audit confirms distinct presentation contracts and LAB settings ownership, not full live/Data settings isolation. No shared settings, layout, Rerun renderer or replay code was changed for this camera repair. The focused profile tests below do not cover the remaining live/Data settings coupling. Separating that storage and state requires its own transition/race and browser regression checks; it must not be folded into a camera-path fix implicitly.
Observed 6 September failure
Existing session 20260906T184240Z_viewer_live:
| Metric | Fast A | Recovery B | Recent run |
|---|---|---|---|
| MQTT callback → publication p50 | 23.839 ms | 83.934 ms | 93.151 ms |
| MQTT callback → publication p95 | 41.541 ms | 223.589 ms | 208.989 ms |
| Preview drops | 0 | 70 | 58 |
| Point decode errors | 0 | 0 | 0 |
| Camera archive | complete | complete | absent |
Run lengths differ; drop counts are not normalized performance rates. Device calibration onset and first visible pixels were not independently measured in the recent run, so the historical operator timings are not falsely compared to backend timestamps. The recent run published 1,028,061 points in 386 PCL frames.
At 18:43:15 UTC the browser admitted a Rerun store; this alone is not proof of visible point pixels. Between 18:43:20 and 18:43:50 the backend logged 22 failed post-authoritative-PCL camera activations. First-PCL admission took 4–34 ms. No camera producer activation success or camera media artifact exists in this session. The private formatter discarded exception details, preventing recovery of each historical exception stack from those records.
Reproduced storage defect and bounded repair
The running checkout is separate from MISSIONCORE_DATA_DIR. Acquisition uses resolve_missioncore_evidence_dir(), but XgridsK1CameraGateway previously confined session paths to repository_root. The actual session is outside the checkout. An offline call using the real existing session directory deterministically raised “camera recording root must stay inside the repository” before authority reservation, FFmpeg preparation or network I/O. Camera remained idle, matching the observed pre-producer failure. This mismatch necessarily blocks recording at the configured path even though the original exception stacks were lost.
The gateway now receives an explicit evidence_root from the existing service composition. It confines both acquisition-owned and selected-preview recording to that root after resolving paths. It rejects sibling directories and symlink escapes. The source checkout remains the FFmpeg-binary lookup root; the fallback for standalone gateway callers preserves their existing repository confinement. No RTSP arguments, video quality, stream choice, camera producer lifecycle, START/STOP, MQTT dialogue, Rerun blueprint or LAB/archive viewer policy changed.
Private exception diagnostics now retain only the exception class and final filename/line/function. They omit exception text, locals, source lines and absolute paths. This makes future failures attributable without leaking data.
Validation and remaining physical acceptance
- Camera gateway suite: 42 passed, including seven new external-root, composition-wiring and path-confinement cases. Synthetic FFmpeg produced and archived media in the configured external directory.
- Camera acquisition lifecycle: 37 passed.
- Persistent diagnostics suite: 8 passed, including exception-location redaction.
- Focused frontend profile, environment, LAB view profile and recorded-camera journal checks: 14 passed. These are contract-level checks, not physical playback acceptance or proof of complete settings isolation.
- Mypy on camera.py and runtime_diagnostics.py: passed.
- Ruff and git diff --check: passed.
- Protocol, BLE provisioning/AP, physical ledger/coordinator, MQTT,
connection supervisor, runtime and archive remain identical to
c041a56. - The broad frozen-contour guard also includes camera.py, so it now deliberately detects this narrow camera storage change. Its baseline was not advanced or weakened. This is not a claim that the full freeze check passes unchanged.
The canonical idle service was refreshed and its replacement was confirmed ready on port 8000 at 19:10:22 UTC; no frontend rebuild was required. A new operator-started physical run is still needed to verify right-camera appearance, durable media and browser playback. The existing failed session is preserved and is not retroactively repaired.
Ops was consulted read-only. This local report was not published to a card.