Preserve RRD preview frames and clarify onboard K1 status

This commit is contained in:
DCCONSTRUCTIONS
2026-09-07 15:27:13 +03:00
parent 67398fef10
commit 92b60de945
19 changed files with 516 additions and 94 deletions
@@ -0,0 +1,90 @@
# Node K1 preview R10
The owner installed R9 and physically confirmed START and STOP. Installed
readback is Node 0.8.7 / optional K1 0.1.6+private.1, both services running
without restarts. The actual service now reports application_authority_available
true. This closes the R9 credential-loading gate, not the live-preview gate.
Private screenshots, Fleet state and timestamps are retained under
private/acceptance/k1-node087-20260907-preview-r10. The owner reported malformed
RRD notifications, absent camera, misplaced loading feedback and a failed
state check after STOP. Cache clearing for these owner attempts was not
independently confirmed. The agent issued no hardware actions.
## Proven defects
NodeMediaPeers split each binary_stream.read() into 16384-byte SCTP messages.
The browser passed each message directly to send_rrd. Installed Rerun SDK
0.36.3 documents send_rrd as accepting an RRD file in a byte array, also
described by the [upstream LogChannel reference](https://ref.rerun.io/docs/js/0.36.2/web-viewer/classes/LogChannel.html).
Native Python reproduction produces a complete RRF2 recording per read;
fragments after the first lack that header. The previous transport test used
a tiny fake payload and could not expose this defect.
The journal separately reports missing local camera FFmpeg after first PCL.
FFmpeg 6.1.1 is installed at /usr/bin/ffmpeg and is already a declared Debian
dependency, but the reviewed resolver requires an explicit configured path
outside its macOS development fallbacks. The systemd unit now supplies that
path. No resolver fallback, archive ownership or camera activation fence changed.
The viewer formerly closed the camera channel if an offer preceded camera
activation. It now waits up to 45 seconds for the existing producer and sends
the MIME metadata immediately before opening its bounded delivery. It does not
select or restart a camera and never issues a physical START.
## Transport and presentation
missioncore.node-preview/v1 preserves independent payload boundaries with an
MCF1 + big-endian length envelope and ordered fragments of at most 16384 bytes.
Both sides retain the 8 MiB payload bound. The browser assembles exactly one
payload before passing it to the RRD or MSE decoder; incomplete, overflowing
or unframed payloads cannot reach Rerun. The peer response must advertise the
protocol. Backpressure, two-peer admission, private-only ICE and lease cleanup
remain in place. Delivery failures log only channel and exception class.
The existing vendor contribution remains inside the Fleet/Node sensor slot.
The owner's approved composition is control card, centered compact Status
card, then a full-width Rerun card with its own expand/restore action. A
half-width spatial viewport alongside an empty camera was rejected because
it obscured the primary evidence. A camera companion is displayed below the
full-width spatial view only after decoded frames arrive. This is domain
composition using SettingsCard, Button, IconButton, ActivityIndicator and
existing theme tokens; it introduces no generic visual entity or navigation.
Pending acquisition feedback stays inside the one pending action. Preview
messages go to the single Status card. Preview reconnect retries only the
disposable media peer, with backoff capped at 30 seconds while the owner keeps
the active view open. It never repeats START/STOP or Wi-Fi provisioning.
The live-acquisition settings, blueprint, LAB and recorded Rerun profiles are
unchanged; shared recorded-viewer host code is unchanged.
## Follow-up: STOP and read-only verification
The journal identifies a vanished BlueZ object at add_device_watcher during
the owner's explicit Verify. A retained Python BLEDevice is not proof that
the native BlueZ object still exists. Before the single read-only GATT connect,
Linux now checks its native cache and, only for a vanished object, obtains one
fresh advertisement for the same exact address inside the existing status-read
arbiter lease (maximum eight seconds). Public scan generations and the selected
target remain unchanged. This is a pre-connect refresh, not a retry of a failed
connect or write. macOS behavior and provisioning paths are unchanged. Failure
to recover that exact address remains fail-closed.
The completed control phase remains visible as Device stopped while the next
control check is pending. Actual state supersedes stale START/STOP command
feedback once capture or completion is observed. The initial START journal
exception was the existing physical reconciliation fence; it is not relaxed.
## Validation and remaining gates
100 Python checks cover real loopback WebRTC transporting a native RRD larger
than one fragment without byte loss, delayed camera metadata, Node projection,
package lifecycle and existing Bluetooth/status/provisioning regressions. The
new explicit read test proves a vanished handle is refreshed before exactly
one connect and no GATT write. Native RRD reassembly is also tested in the
actual TypeScript decoder boundary, including malformed/oversized/partial input.
All 801 frontend tests, Core TypeScript and production build pass. Release
hashes, installation readback and owner fresh-cache UI acceptance are recorded
below when observed. Local synthetic
checks do not establish camera decoding or live stream recovery on the BK.