# Lab 004 — canonical K1 control and durable archive milestone

- Date: 2026-07-19
- Device scope: one owner-controlled LixelKity K1, platform `A4`, firmware `3.0.2`
- Topology: direct LAN after BLE Wi-Fi provisioning
- Result: **GO — Mission Core START/live/STOP/save and recorded replay accepted**

This milestone contains no device identity, application authority, Wi-Fi
credential, address, raw MQTT payload, image or project contents. Private raw
evidence remains in ignored runtime storage. Lab 003 retains the failed attempts
and the exact protocol corrections that preceded this result.

## Accepted operator path

The operator selected the BLE-visible K1, provisioned it onto the existing LAN,
and launched one project from the plugin UI. One continuously owned MQTT 3.1.1
session performed the staged 14-operation dialogue. Every required response was
correlated to its operation, session, device binding and authority. START was
sent exactly once with QoS 2 and retain false; automatic retry and reconnect were
disabled. K1 reached bound `SCANNING` with `init_ready=true`, and Mission Core
displayed real point-cloud and pose data.

The operator then selected **Остановить устройство и запись** exactly once. STOP
was sent on the same control session and its response was correlated. K1 blinked
while saving, stopped its live streams, cleared the project binding, reported
`READY`, and returned to stable green. No fallback or repeated device command
was sent. TEST008 repeated the complete product path after the earlier TEST007
acceptance and again produced a catalogued, viewable session.

The explicit STOP click remains a safety boundary. The former post-STOP button
“Индикатор постоянно зелёный — завершить запись” was redundant: it was rendered
only after the same bound K1 had already reported `READY` with no project. The
current lifecycle therefore finalizes local receiver, camera and capture clock
automatically on that protocol evidence. Stable green remains useful physical
corroboration, not a second source of application state.

## Durable TEST007 package

The accepted TEST007 session contains a `107,002,392`-byte digest-bound RRD and
two recorded-camera sources. The larger camera source contains `170,457,493`
bytes across two source epochs: approximately `5.497 s` and `206.073 s`, with
`2,117` committed media segments in total (`56 + 2,061`). The second camera
source contains `5,373,206` bytes over approximately `6.695 s`.

The browser admitted the RRD plus every declared camera as one generation. Real
frames from the large camera source were presented at shared-session positions
approximately `82.58 s` and `98.68 s`; the native player reported ready state 4
and the expected seekable ranges. This closes the earlier transport-only camera
qualification. Historical captures created before camera archival still cannot
acquire video retroactively.

## Archive lifecycle corrections

The saved-session catalog now lists the complete bounded page rather than three
hard-coded rows, refreshes while the menu is open, prepares cold recordings in a
single backend worker, and exposes the ready session without a manual server
repair. Deletion uses the standard Foundry confirmation modal and removes both
the catalog entry and server evidence/cache.

One launch lease originally remained pinned for a fixed 120 seconds after the
launch document. This caused a false “recording is open” conflict when the
operator opened TEST008, switched to another session, and immediately deleted
TEST008. The launch-to-GET lease is now consumed by the first matching RRD GET
after that response acquires its own lifetime pin. A completed transfer releases
the response pin normally; deletion may also release an unused launch lease.
An actually streaming response remains protected. Regression tests cover both
the manager pin handoff and the complete HTTP replay/open/delete sequence.

The session header now names the active archive, for example
`Пространственная сцена: CAM_REC_TEST`. Trash controls retain a transparent
background on hover/focus instead of a red pill. An intentional canonical STOP
is presented as a neutral disconnected source rather than a source error.

## Browser and memory finding

The first product attempt to open TEST007 rejected its valid 170 MB camera epoch
because the frontend had a 128 MiB per-source admission cap. The reviewed caps
are now 256 MiB per camera and 512 MiB per session, still bounded before fetch.
The complete epoch then exceeded practical Media Source Extensions buffering on
this browser. Because the archive is immutable and already fully digest-verified,
the player now presents it as one fMP4 Blob while keeping bounded admission and
generation checks. This is a local browser presentation decision, not a change
to captured evidence.

## Current supported choices

- Connection at the time of this acceptance: direct LAN only. ADR 0013 later
  enabled Bridge, Quick Connect and Direct Connect as distinct v0.6.0 paths;
  that later implementation does not retroactively add physical acceptance to
  this archived run.
- Mount/scan carrier: handheld is active. Ground UGV and aerial UAV choices are
  visible but disabled anchors.
- GNSS: no RTK is the active default. RTK is visible but disabled and optional;
  unanswered optional RTK reads do not authorize guessed configuration.
- Hardware: one K1/A4/FW 3.0.2 unit is physically accepted. Live DeviceInfo still
  binds vendor ID/serial dynamically so the implementation is not hard-coded to
  this unit, but a second scanner and other firmware remain unaccepted.
- Camera: one live camera producer is selected at a time. A recording may contain
  multiple camera sources or epochs after operator switching.
- Native vendor project reuse through LixelGO or USB remains an independent check.

## Verification boundary

Repository verification covers protocol correlation, no-retry safety, automatic
READY/unbound completion, expected RTSP end, archive sealing, digest/range
admission, launch-lease handoff, immediate deletion, session naming and the
absence of the redundant standby control. It does not simulate equipment I/O.
The physical claims above come only from the owner-operated TEST007/TEST008 runs.
