docs(milestone): record K1 control and archive acceptance
This commit is contained in:
DCCONSTRUCTIONS
parent
71c85e9894
commit
fecb5885d0
36
README.md
36
README.md
|
|
@ -27,8 +27,9 @@ The K1 acquisition now also requires an operator project name. Frontend and
|
|||
backend normalize it with NFKC plus surrounding-whitespace trimming, reject
|
||||
control/surrogate characters and values above 96 Unicode characters, and
|
||||
preserve it as local session/catalog display metadata. It is never used as a
|
||||
filesystem path. Because K1 command publishing is disabled, the current runtime
|
||||
does not claim that this value has been transmitted to the scanner.
|
||||
filesystem path. The physically accepted interactive control path carries the
|
||||
same validated value in its single canonical START; there is no separate
|
||||
project-name write.
|
||||
|
||||
Plugin SDK v0alpha2 now provides executable, vendor-neutral identity, session,
|
||||
operation, runtime-action, stream, evidence and compatibility contracts. Every
|
||||
|
|
@ -42,10 +43,10 @@ normalizer to produce transport-neutral local consumer views; portable SDK
|
|||
stream envelopes, process isolation, durable operations, multi-device routing
|
||||
and the remote Edge split remain later gates.
|
||||
|
||||
The current runtime cannot read K1 firmware automatically. It keeps the exact
|
||||
profile inactive until the operator explicitly attests firmware `3.0.2` and
|
||||
direct-LAN topology; state records that basis as `operator-attested`, not as
|
||||
device-derived evidence.
|
||||
The application-control bootstrap reads and correlates live `DeviceInfo` before
|
||||
START. The exact profile requires model `LixelKity K1`, observed platform type
|
||||
`A4`, activated state, firmware `3.0.2`, and direct-LAN topology. The UI selects
|
||||
that profile but does not ask the operator to attest firmware manually.
|
||||
|
||||
The repository now contains one narrowly gated state-changing command:
|
||||
`ble wifi-configure`. It accepts only the reviewed firmware-3 provisioning
|
||||
|
|
@ -138,7 +139,8 @@ local reception; plugin-commanded v0.5.0 acquisition uses the separately gated
|
|||
canonical K1 START/STOP dialogue.
|
||||
|
||||
The exact recovered `ModelingRequest` start/stop encoder, response correlator
|
||||
and device-status state machine are implemented as inert protocol components.
|
||||
and device-status state machine are installed in the operator-gated interactive
|
||||
control path.
|
||||
The plugin also contains the exact ten-request pre-START bootstrap recovered
|
||||
from retained LixelGO traffic. Its first `DeviceInfoRequest` has no device ID;
|
||||
the response supplies live vendor identity, serial, model, activation and
|
||||
|
|
@ -157,7 +159,7 @@ keepalive 60, exact
|
|||
response subscriptions, QoS2 completion and the five response-gated batches.
|
||||
It consumes operation keys before publish and poisons unknown outcomes without
|
||||
retry. One background owner services that socket through response-gated
|
||||
connection, workspace, project, START, STOP and steady-green stages. The normal
|
||||
connection, workspace, project, START, STOP and device-standby stages. The normal
|
||||
UI collapses only the pre-START controls into one explicit operator intent;
|
||||
navigation cannot emit a command. The first operator-present physical attempt on 2026-07-18 emitted only
|
||||
the first six bootstrap requests, then failed closed while correlating the third
|
||||
|
|
@ -172,11 +174,13 @@ workspace-entry request 7, project-prompt reads 8–10, user-confirmed START 11,
|
|||
immediate status read 12 and state-gated reads 13–14 onto one continuously owned
|
||||
MQTT session. No captured operator delay is a protocol timer: the final reads
|
||||
wait for live `SCANNING`, project binding and `init_ready`, while STOP/save waits
|
||||
for live `READY` plus physical standby confirmation. Standalone START and STOP
|
||||
for live unbound `READY`. Standalone START and STOP
|
||||
are both rejected. The same socket is serviced throughout launch and STOP
|
||||
confirmation, and no captured human delay is replayed as a protocol timer.
|
||||
Plugin v0.5.0 wires this executor to the facade and plugin UI; physical command
|
||||
acceptance remains an operator-run gate.
|
||||
Plugin v0.5.0 wires this executor to the facade and plugin UI. The full staged
|
||||
START/live/STOP/save cycle is physically accepted on the reviewed unit. START
|
||||
and STOP each retain an explicit operator action; final local sealing now follows
|
||||
the scanner's protocol-reported unbound READY without a redundant second click.
|
||||
|
||||
This locked bootstrap is repeatable in the current workspace, not yet a
|
||||
standalone release install. The frontend consumes sibling `file:` packages from
|
||||
|
|
@ -314,7 +318,9 @@ present.
|
|||
- [Device-plugin observation runtime and K1 extraction](docs/adr/0009-device-plugin-observation-runtime-and-k1-extraction.md)
|
||||
- [Plugin-owned frontend device workflows](docs/adr/0010-plugin-owned-frontend-device-workflows.md)
|
||||
- [Laboratory plugin runtime handshake and transport seam](docs/adr/0011-laboratory-plugin-runtime-handshake-and-transport-seam.md)
|
||||
- [Device-bound K1 command authority](docs/adr/0012-device-bound-k1-command-authority.md)
|
||||
- [Redacted live lab report](docs/lab/001_K1_LIVE_MQTT_20260715.redacted.md)
|
||||
- [Canonical control and durable archive milestone](docs/lab/004_K1_CANONICAL_CONTROL_ARCHIVE_20260719.redacted.md)
|
||||
- [Session manifest schema](schemas/session-manifest.schema.json)
|
||||
- [Reference input provenance](docs/reference/README.md)
|
||||
|
||||
|
|
@ -330,9 +336,11 @@ capture of traffic to or from the confirmed K1 address, and offline analysis of
|
|||
owned artifacts.
|
||||
|
||||
The reviewed provisioning write requires its named profile and explicit operator
|
||||
confirmation. Application command publishing remains disabled: physical
|
||||
double-click is the verified start/stop mechanism. Any future MQTT publisher,
|
||||
router configuration change or new BLE write requires its own evidence and
|
||||
confirmation. The interactive application-control publisher is enabled only for
|
||||
the exact K1/A4/FW 3.0.2 direct-LAN profile and only inside one operator-opened,
|
||||
response-gated session; physical double-click remains the independent fallback.
|
||||
The legacy shadow publisher remains structurally disabled. Any broader firmware,
|
||||
topology, scanner-family or command surface requires its own evidence and
|
||||
reviewed step. Random writes, fuzzing, brute force, firmware operations,
|
||||
destructive file access and credential guessing remain out of scope.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,46 +19,47 @@ Each gate produces evidence and an explicit GO, PAUSE or BLOCKED result.
|
|||
| Stage 5 camera | GO (live) — left/right RTSP/H.264 preview observed, read-only runtime adapter and physical UI acceptance completed |
|
||||
| Stage 6 live viewer | GO — React Control Station, embedded self-hosted Rerun cloud/trajectory, plugin-owned spatial controls and live device/Mac metrics |
|
||||
| Stage 7 observation archive | GO (point/pose/telemetry contract) — durable catalog, recovery, capture-clock-bounded RRD preparation, archived metric time series, saved-session timeline and atomic playback are implemented |
|
||||
| Stage 7 recorded cameras | GO (contract), acceptance pending — acquisition-owned fMP4 archive and player are implemented/tested; one real archived K1 camera plus point-cloud session has not passed playback yet |
|
||||
| Stage 7 recorded cameras | GO — the accepted physical session sealed real fMP4 camera data, produced two digest-bound recorded sources and passed manifest/init/segment range admission alongside a 107 MB RRD; browser QA opened real frames from the 170 MB camera epoch at multiple shared-timeline positions |
|
||||
| Plugin isolation | GO (laboratory control plane) — vendor backend/frontend and optional scene controls are plugin-owned; manifest/runtime descriptor parity, versioned handshake, lifecycle health and transport correlation fail closed while execution remains in-process |
|
||||
| K1 application control | OPERATOR ACCEPTANCE READY — the failed protocol-collapsed path and standalone START/STOP remain disabled. Plugin v0.5.0 installs one continuous control-session owner; one explicit UI launch intent advances connection, workspace, project and START only across live response barriers, while STOP and steady-green confirmation remain separate. No wall-clock transition, automatic retry, navigation-triggered command or repository-test equipment I/O exists. A full operator-run physical cycle and native-project verification remain open |
|
||||
| K1 application control | GO (physical staged cycle) — after fixing the PCAP-proven `sint64` time field, one explicit UI launch completed all 14 canonical operations on one control session, reached live `SCANNING + project + init_ready`, displayed real points, then one explicit STOP returned K1 to unbound `READY`. No retry or fallback command was sent. Native-project reuse through LixelGO/USB remains an independent verification |
|
||||
| Stage 8 product storage | PAUSE — retention, replication, encryption, capacity monitoring and long-run browser/WASM stress remain deployment gates |
|
||||
|
||||
USB project copying remains optional ground truth rather than a blocker for the
|
||||
now-verified network path. Owner-operated LixelGO traffic verifies the MQTT
|
||||
start/stop mapping and RTSP camera transport. The exact start/stop protobuf
|
||||
encoder, response correlator and device-status state machine now exist without a
|
||||
publisher. Retained PCAP plus client static analysis prove that OpenAPI is one
|
||||
encoder, response correlator and device-status state machine now run in the
|
||||
separately gated interactive publisher; the legacy shadow publisher remains
|
||||
disabled. Retained PCAP plus client static analysis prove that OpenAPI is one
|
||||
private application-level value in this LixelGO build, not a per-scanner
|
||||
credential. The selected BLE peripheral returns its own LAN IP; the initial
|
||||
unbound `DeviceInfoRequest` then returns vendor ID, serial, model, activation and
|
||||
version facts for that live K1. Mission Core's shadow bootstrap reproduces the
|
||||
10 observed pre-START requests byte-for-byte across five recovered batches:
|
||||
initial DeviceInfo binding; ModelingStatus plus RTK read; time sync plus
|
||||
DeviceInfo/RTK; NTRIP read; then cloud/RTK/DeviceInfo reads. The first
|
||||
10 observed pre-START requests byte-for-byte across four response windows and
|
||||
five observed publish groups: initial DeviceInfo binding; then the ordered
|
||||
ModelingStatus/RTK and time-sync/DeviceInfo/RTK groups without an invented
|
||||
response barrier between them; NTRIP read; then cloud/RTK/DeviceInfo reads. The first
|
||||
ModelingStatus request has no mandatory synchronous response barrier; readiness
|
||||
is separately attested through live DeviceStatus. A fixed macOS Keychain loader
|
||||
now reads the exact 36-byte authority without environment/file/browser fallback.
|
||||
The response orchestrator correlates required headers/results and rejects
|
||||
identity/profile drift. The installed publish boundary is a separate
|
||||
write-disabled type that cannot call its injected sink. A dormant coordinator
|
||||
is now wired into the XGRIDS facade and plugin manifest. Explicit operator arm
|
||||
loads the Keychain value into a bounded 15–300 second process-memory lease;
|
||||
expiry, disarm, reprovision, acquisition preparation and shutdown drop both the
|
||||
lease and orchestrator. Public state contains only lease timing/booleans. There
|
||||
is deliberately no batch-emission method, live MQTT sink or UI button in the
|
||||
installed runtime. A separate physical-acceptance-only transport and dialogue
|
||||
executor now implement the reviewed MQTT exchange without facade/UI wiring.
|
||||
Each operation key is consumed before publish, automatic reconnect and
|
||||
application retry are forbidden, and any unknown outcome poisons the transport.
|
||||
identity/profile drift. The legacy shadow publisher remains a separate
|
||||
write-disabled type that cannot call its injected sink. Its dormant coordinator
|
||||
is wired into the XGRIDS facade only for redacted planning/state. Separately,
|
||||
plugin v0.5.0 installs the reviewed physical-acceptance transport behind explicit
|
||||
operator actions and one continuous background session owner. Each operation
|
||||
key is consumed before publish, automatic reconnect and application retry are
|
||||
forbidden, and any unknown outcome poisons the transport. Public state contains
|
||||
only bounded lifecycle, counter and failure metadata; authority and device
|
||||
identity remain private.
|
||||
The one-time `k1link authority provision` command delegates secret entry to the
|
||||
macOS Keychain TTY prompt and validates through the production loader without
|
||||
receiving the value in argv/environment/file/browser state. During the first
|
||||
physical attempt that CLI loader did not receive macOS approval, so a temporary
|
||||
process-local Security.framework lab adapter supplied the already reviewed
|
||||
value. The transport emitted bootstrap ordinals 1–6 and received all five
|
||||
required responses through batch 3, but the orchestrator raised
|
||||
`ApplicationBootstrapError` while correlating that batch. No START was emitted;
|
||||
required responses through the old third window, but topic-only routing
|
||||
misassociated the unbound and bound RTK responses and the orchestrator raised
|
||||
`ApplicationBootstrapError`. No START was emitted;
|
||||
live DeviceStatus stayed READY and the local point/pose counts remained zero.
|
||||
The local capture was sealed and the temporary Keychain item was deleted.
|
||||
The second physical attempt then correlated all ten bootstrap requests and one
|
||||
|
|
@ -77,10 +78,15 @@ START confirmation. Captured human delays are not replayed or treated as minimum
|
|||
timeouts. After the immediate operation-12 read, operations 13–14 wait for the
|
||||
same bound K1 to report `SCANNING`, a bound project and `init_ready=true`.
|
||||
The same transport is then serviced until an explicit STOP request; post-STOP
|
||||
ownership waits for live `READY` plus physical standby confirmation. System-error
|
||||
and status reports are decoded into redacted safety state. This path is not
|
||||
wired into the plugin runtime/UI and has only synthetic regression coverage;
|
||||
physical STOP/save remains untested and the button is the safe fallback.
|
||||
ownership waits for live unbound `READY`. System-error
|
||||
and status reports are decoded into redacted safety state. The next staged
|
||||
physical attempt, after correcting the protobuf `sint64` time field, completed
|
||||
all 14 canonical operations, reached live scanning with real point/pose data and
|
||||
then completed one explicit STOP. K1 returned to unbound `READY`; no retry or fallback device command was
|
||||
sent. The durable local session is catalogued as ready/replayable, its RRD and
|
||||
two camera sources pass digest-bound range admission, and physical double-click
|
||||
remains the fallback. Reuse of the vendor-native project is still verified
|
||||
separately through LixelGO or USB.
|
||||
|
||||
The Stage 6 live path uses a bounded raw-first bridge: loss in the visualization
|
||||
queue cannot discard MQTT evidence. The queue holds four preview messages;
|
||||
|
|
@ -110,8 +116,9 @@ saved-session switching, persisted replay reattach and manual source
|
|||
input/apply/reset until that acquisition has been finalized. The successful
|
||||
automatic-source action is an internal start-result boundary and intentionally
|
||||
does not masquerade as an operator source switch. The K1 scene-level stop
|
||||
control is plugin-owned; with the active read-only profile it stops and seals
|
||||
local reception only and never claims to stop the scanner.
|
||||
control is plugin-owned. A plugin-commanded acquisition sends one canonical STOP
|
||||
and seals locally after protocol-reported standby; an operator-manual acquisition
|
||||
still stops and seals only local reception and reports scanner state as unknown.
|
||||
|
||||
## Stage 0 — repository and host baseline
|
||||
|
||||
|
|
@ -297,11 +304,10 @@ useful stream is decoded or structurally identified.
|
|||
- automated scan-button electronics;
|
||||
- OpenWrt/monitor-mode infrastructure;
|
||||
- firmware or internal-Linux analysis;
|
||||
- physical end-to-end shared-timeline playback for a newly archived session
|
||||
containing point cloud plus one selected K1 camera;
|
||||
- browser-visible end-to-end shared-timeline playback of the accepted archive
|
||||
containing point cloud plus one selected K1 camera (backend preparation and
|
||||
digest-bound byte admission are already accepted);
|
||||
- OS-independent plugin/edge authority provider, PCAP-to-executor transcript
|
||||
regression, runtime ownership integration, a separately reviewed and newly
|
||||
permitted operator-present START/STOP attempt, and stable-artifact proof after
|
||||
STOP;
|
||||
regression and runtime ownership integration;
|
||||
- long-running large-session WebViewer/WASM memory telemetry;
|
||||
- production retention, replication, encryption and cross-platform packaging.
|
||||
|
|
|
|||
|
|
@ -186,10 +186,16 @@ special time-sync session is exactly
|
|||
`${device_id}:DeviceConfigRequest:Publish_Proto_DeviceConfig_SetTime`. The
|
||||
repository shadow bootstrap reproduces all ten retained payloads and their
|
||||
topic order byte-for-byte. Time sync is the only mutation before START; the
|
||||
other nine requests are reads.
|
||||
other nine requests are reads. Its Unix timestamp is protobuf `sint64`, not
|
||||
`int64`/`uint64`: the retained value `3568430060` ZigZag-decodes to
|
||||
`1784215030` (`2026-07-16 15:17:10 UTC`). The runtime encoder must therefore
|
||||
ZigZag-encode the current epoch before writing field 1 of the nested time
|
||||
configuration.
|
||||
|
||||
The first ten requests use five response-barrier batches, but those barriers are
|
||||
not the whole application lifecycle. Two independent owner-operated START
|
||||
The first ten requests contain five observed publish groups but only four
|
||||
application-response windows. The initial DeviceInfo response is the identity
|
||||
binding barrier; ordinals 2–6 then retain their exact publish order without an
|
||||
invented response barrier between ordinals 3 and 4. Two independent owner-operated START
|
||||
captures contain the same 14-operation order: the ten requests above, START,
|
||||
one bound `ModelingStatus` read, then a bound `DeviceInfo` plus
|
||||
`ModelingStatus` refresh about 24–25 seconds after START. The first capture
|
||||
|
|
@ -198,11 +204,15 @@ reached it after 54.130 seconds. This variation is operator/UI time, while the
|
|||
stage order is invariant. In both captures the original control MQTT connection
|
||||
remained open throughout initialization and the later refresh; no DISCONNECT or
|
||||
UNSUBSCRIBE occurred. DeviceInfo response establishes identity before later
|
||||
bound requests. Required response barriers are correlated by topic, exact
|
||||
bound requests. Required response barriers are correlated by operation key, topic, exact
|
||||
session, vendor identity, application authority and numeric success. The
|
||||
initial and immediate post-START ModelingStatus reads are intentionally not
|
||||
treated as mandatory synchronous responses. Readiness belongs to live
|
||||
DeviceStatus plus point/pose observation.
|
||||
treated as mandatory synchronous responses. In both retained captures operation
|
||||
12 has no application response; the single bound ModelingStatus response in
|
||||
that part of the lifecycle arrives only after operation 14 and belongs to it.
|
||||
An unanswered optional operation therefore cannot reserve FIFO ownership over
|
||||
the required operation-14 response. Readiness belongs to live DeviceStatus plus
|
||||
point/pose observation.
|
||||
|
||||
The UI/event correlation is also fixed by the retained capture. Requests 1–6
|
||||
follow successful data connection. Entering the scan workspace causes request
|
||||
|
|
@ -221,7 +231,7 @@ from `SCANNING` with a bound project. It emits only a non-executable digest and
|
|||
wire metadata, uses QoS 2 with retain false, and declares automatic retry
|
||||
forbidden. It has no MQTT publish dependency and cannot send a command.
|
||||
|
||||
Publishing remains deliberately disabled. The exact 36-byte authority has a
|
||||
Legacy shadow-plan publishing remains deliberately disabled. The exact 36-byte authority has a
|
||||
read-only macOS Keychain loader with no environment, file, browser or API
|
||||
fallback. A facade-owned dormant coordinator can arm it only after explicit
|
||||
operator confirmation, a connected/attested K1, idle runtime and no active
|
||||
|
|
@ -230,8 +240,9 @@ seconds and is revoked by expiry, disarm, reprovision, acquisition preparation
|
|||
or shutdown. The current one-shot boundary is structurally write-disabled,
|
||||
exposes no emission method and cannot touch its injected sink.
|
||||
|
||||
A separate physical-acceptance-only implementation now exists outside the
|
||||
facade/runtime. Retained-PCAP re-audit fixes its MQTT contract at 3.1.1,
|
||||
A separate operator-driven physical-acceptance implementation is installed in
|
||||
plugin v0.5.0 through the facade/runtime. Retained-PCAP re-audit fixes its MQTT
|
||||
contract at 3.1.1,
|
||||
`clean_session=false`, keepalive 60, the three ordered 9/5/42-topic control
|
||||
subscription groups, separation from the point-cloud client, QoS 2
|
||||
request/PUBCOMP completion and
|
||||
|
|
@ -240,12 +251,14 @@ consumes every ordinal/action operation key before publish, never reconnects or
|
|||
retries, rejects stale/duplicate/unexpected responses and poisons every unknown
|
||||
post-publish outcome. A 15–120 second permit requires explicit operator-present,
|
||||
owner-controlled-device, LixelGO-closed, battery/storage and expected-state
|
||||
confirmations. START additionally requires the complete five-batch bootstrap;
|
||||
STOP requires its own separate permit. This code is not installed as a plugin
|
||||
action. On 2026-07-18 its first operator-present physical attempt made one
|
||||
confirmations. START additionally requires the complete four-window bootstrap;
|
||||
STOP requires its own separate permit. No plugin state read, poll, navigation or
|
||||
automatic lifecycle event may invoke either action. On 2026-07-18 its first
|
||||
operator-present physical attempt made one
|
||||
connection and emitted bootstrap ordinals 1–6. All six QoS 2 publishes completed
|
||||
and five required responses were collected, but exact correlation rejected one
|
||||
response in batch 3. The executor stopped before building or publishing START;
|
||||
and five required responses were collected, but the old topic-only collector
|
||||
misrouted one of the two `GetRtkAdvance` responses in its third window. The
|
||||
executor stopped before building or publishing START;
|
||||
K1 remained `READY`, project binding stayed absent and point/pose remained zero.
|
||||
No automatic retry was attempted. A second explicitly permitted attempt then
|
||||
correlated all ten bootstrap responses and one START success response, with 11
|
||||
|
|
@ -265,8 +278,9 @@ observed connection, workspace-entry and project-prompt checkpoints instead of
|
|||
wall-clock floors, sends the immediate post-START ModelingStatus read, services
|
||||
the same MQTT socket until live `SCANNING + project + init_ready`, then emits the
|
||||
DeviceInfo/ModelingStatus refresh. It continues servicing that socket until an
|
||||
explicit STOP request and afterwards until live `READY` plus operator-confirmed
|
||||
standby. System-error and DeviceStatus reports are decoded into redacted safety
|
||||
explicit STOP request and afterwards until live unbound `READY`. That device
|
||||
status is the canonical standby evidence; no second visual acknowledgement is
|
||||
required. System-error and DeviceStatus reports are decoded into redacted safety
|
||||
state; a fault forbids further automatic action. Standalone START/STOP are
|
||||
disabled. MQTT keepalive/report processing also continues while the operator is
|
||||
between UI actions; the 15–120-second command permit is created at the actual
|
||||
|
|
@ -284,13 +298,18 @@ one-shot process and deleted immediately afterward. It is not the product
|
|||
authority architecture. The acceptance executor now records only ordinal,
|
||||
message type, response topic, payload size, SHA-256 and a safe correlation
|
||||
reason; it never exposes response bytes or authority in diagnostics. The
|
||||
retained clean-cycle still completes all nine bootstrap barriers offline, so
|
||||
the open issue is a live batch-3 response divergence. The complete stop/save
|
||||
sequence has not physically proved a durable vendor project. A
|
||||
correlated STOP success, stream quiescence, return to
|
||||
`READY`/steady-green hardware state and appearance of a reusable native project
|
||||
are separate gates. The verified physical double-click remains the acquisition
|
||||
control until a separately reviewed one-shot write gate closes.
|
||||
retained clean-cycle now completes all nine bootstrap barriers offline while
|
||||
ordinals 3 and 6 are simultaneously in flight and routes them by exact
|
||||
session/device identity. After repairing the PCAP-proven protobuf `sint64` time
|
||||
field, the next operator-run physical cycle completed all 14 canonical requests
|
||||
on one socket, reached `SCANNING + project + init_ready`, delivered real
|
||||
point/pose data and completed one correlated STOP. Streams quiesced, K1 returned
|
||||
to unbound `READY`; no retry or fallback STOP was sent. The operator also
|
||||
observed stable green, but that observation is not a second protocol gate. The
|
||||
local archive sealed and passed digest-bound RRD and recorded-
|
||||
camera admission. Appearance and reuse of the vendor-native project through
|
||||
LixelGO or USB remains a separate gate. Physical double-click remains the
|
||||
operational fallback.
|
||||
|
||||
## Decoder and raw-capture bounds
|
||||
|
||||
|
|
|
|||
|
|
@ -134,8 +134,10 @@ directly and use their sibling metadata receive timestamps when present.
|
|||
from a browser timer or accumulated across a device counter reset.
|
||||
10. Choose **Остановить устройство и запись** in the scene. The
|
||||
plugin-commanded path emits one canonical STOP on the original socket,
|
||||
waits for live unbound READY, and asks the operator to confirm the constant
|
||||
green indicator before capture, camera archive and summaries are finalized.
|
||||
waits for live unbound READY, then finalizes capture, camera archive and
|
||||
summaries automatically. The UI does not ask for a redundant green-indicator
|
||||
confirmation because READY plus cleared project binding is already the
|
||||
scanner's protocol evidence.
|
||||
|
||||
Each new live run creates a direct child below `MISSIONCORE_EVIDENCE_DIR`, or
|
||||
`.runtime/mission-core/evidence/sessions/` by default, with raw MQTT frames,
|
||||
|
|
@ -336,9 +338,10 @@ listener and its process memory must be closed unconditionally.
|
|||
left/right compressed RTSP preview and acquisition-owned fMP4 archive use a
|
||||
separate generic media path. Historical sessions predating that archive have
|
||||
no recoverable video.
|
||||
- Physical double-click remains the K1 scan start/stop control. Any MQTT command
|
||||
promotion needs reviewed Keychain item provisioning, operator-present use of
|
||||
the uninstalled response-gated transport and durable-save proof.
|
||||
- Physical double-click remains the independently verified device-local fallback.
|
||||
Mission Core also contains the installed response-gated operator-present
|
||||
acceptance transport for the exact K1/A4/FW 3.0.2 profile; its full
|
||||
START-to-STOP durable-save cycle was physically accepted on 2026-07-18/19.
|
||||
- No terrain map, elevation model, obstacle segmentation, localization fusion,
|
||||
mission planner or vehicle control is implemented by this viewer milestone.
|
||||
- Exact coordinate axes and the scanner-to-vehicle transform remain a mounting
|
||||
|
|
|
|||
|
|
@ -128,15 +128,14 @@ requires every model to be covered by a reviewed, plugin-local, path-confined
|
|||
compatibility profile. The current XGRIDS profile matches exactly:
|
||||
|
||||
- XGRIDS LixelKity K1;
|
||||
- wire-level platform type `A4`;
|
||||
- firmware `3.0.2`;
|
||||
- direct-LAN topology;
|
||||
- one retained physical laboratory evidence scope.
|
||||
|
||||
Unknown or unattested firmware fails closed. The current runtime does not read
|
||||
firmware from the device: it activates this limited, read-only profile only
|
||||
after explicit operator attestation of firmware `3.0.2` and direct-LAN topology,
|
||||
and records the basis as `operator-attested`. That claim is not device-derived
|
||||
proof. The profile independently records observation, decode, replay,
|
||||
Unknown or mismatched firmware fails closed. The UI selects the profile and the
|
||||
canonical bootstrap verifies model, platform type, activation and firmware from
|
||||
a correlated live `DeviceInfo` before START. The profile independently records observation, decode, replay,
|
||||
physical-verification and write evidence. Loading it cannot authorize a
|
||||
transport mutation. BLE Wi-Fi provisioning and application control retain
|
||||
separate explicit operator gates.
|
||||
|
|
@ -149,30 +148,30 @@ is one private application-level authority; vendor ID and serial come from the
|
|||
BLE-selected live K1 and are cross-checked against status. Plugin v0.5.0 owns a
|
||||
single interactive MQTT session from connection through STOP/standby, with one
|
||||
explicit UI action per recorded lifecycle boundary and no automatic retry. A
|
||||
fixed Keychain loader and dormant shadow coordinator remain present. Stable
|
||||
physical proof after STOP remains unresolved; write capability is exposed only
|
||||
while that interactive socket owner is active.
|
||||
fixed Keychain loader and dormant shadow coordinator remain present. The staged
|
||||
physical START/live/STOP/unbound-READY cycle is accepted on the reviewed unit;
|
||||
write capability is exposed only while that interactive socket owner is active.
|
||||
|
||||
## Semantic lifecycle
|
||||
|
||||
The transitional facade now creates separate provisional device,
|
||||
device-session, acquisition and operation IDs. Acquisition can be prepared,
|
||||
wait for receiver readiness, then wait for an external physical start, and become acquiring only after real point
|
||||
data, wait for an externally confirmed stop, finalize and complete. Capture-only
|
||||
stop reports the K1 physical state as unknown.
|
||||
data. Plugin-commanded STOP finalizes automatically after the same bound control
|
||||
session reports unbound READY. Operator-manual capture-only stop still reports
|
||||
the K1 physical state as unknown.
|
||||
|
||||
Preparation requires a project name. The frontend and backend both apply NFKC
|
||||
normalization plus surrounding-whitespace trimming, reject control/surrogate
|
||||
characters and names above 96 Unicode characters, and store the result as
|
||||
session/catalog display metadata. It is not a path component. Because command
|
||||
publishing is off, the current integration does not claim that the name reaches
|
||||
K1.
|
||||
session/catalog display metadata. It is not a path component. The accepted
|
||||
interactive START carries this exact validated value to K1.
|
||||
|
||||
The K1 contribution may mount a `SpatialControlsView` beside the host-owned
|
||||
viewport. It presents plugin lifecycle wording, the local stop action and live
|
||||
`ModelingReport` scan time, route distance and speed. Under the current
|
||||
capture-only profile the stop action seals local reception; it does not claim a
|
||||
device stop. `ModelingReport` is consumed before the visual preview queue through
|
||||
viewport. It presents plugin lifecycle wording, the stop action and live
|
||||
`ModelingReport` scan time, route distance and speed. In plugin-commanded mode
|
||||
the stop action sends the canonical device STOP; in operator-manual mode it
|
||||
seals only local reception. `ModelingReport` is consumed before the visual preview queue through
|
||||
an injected observer, preserving the generic normalizer/Rerun boundary.
|
||||
|
||||
The operation journal is bounded and in memory. It records IDs, idempotency,
|
||||
|
|
@ -180,9 +179,9 @@ declared deadlines, progress and terminal results without action parameters or s
|
|||
It is not durable, distributed or recoverable after process restart.
|
||||
|
||||
Semantic acquisition actions coexist with legacy `stream.*` actions for
|
||||
v1alpha1/UI compatibility. On this profile, start and stop operate the local
|
||||
receiver and operator workflow only. K1 scanning is still started and stopped
|
||||
by physical double-click; no modeling request is published.
|
||||
v1alpha1/UI compatibility. On the exact accepted profile, a plugin-commanded
|
||||
acquisition owns canonical START and STOP plus local reception. Physical
|
||||
double-click remains the independently verified device-local fallback.
|
||||
|
||||
Left/right camera preview transport, endpoint paths and H.264 framing are now
|
||||
observed under the exact compatibility profile. The local read-only adapter
|
||||
|
|
@ -190,8 +189,8 @@ copy-remuxes one selected RTSP producer into bounded fMP4/WebSocket delivery for
|
|||
the generic MSE UI. New acquisitions archive selected-camera init/segments/index
|
||||
independently of browser delivery. The generic recorded player, manifest-v2
|
||||
validation and shared `session_time` controls are connected; historical sessions
|
||||
created before this archive contract contain no recoverable video, so physical
|
||||
recorded-camera acceptance remains open. Portable FFmpeg packaging, disk-backed
|
||||
created before this archive contract contain no recoverable video. The TEST007
|
||||
recorded-camera package and browser playback are physically accepted. Portable FFmpeg packaging, disk-backed
|
||||
browser buffering, fan-out and remote delivery also remain open. Device
|
||||
calibration command and sensor-to-vehicle extrinsics are unavailable.
|
||||
|
||||
|
|
@ -223,9 +222,9 @@ views.
|
|||
4. Physically accept a newly archived left/right K1 session, then package the
|
||||
read-only RTSP/H.264 adapter for each target OS, add disk-backed sealed media
|
||||
caching and evolve same-host MSE delivery toward an authenticated Edge media
|
||||
plane. Keep the modeling-command publisher disabled until operator-owned
|
||||
Keychain item provisioning, physical acceptance of the reviewed uninstalled
|
||||
transport and durable-save confirmation gate.
|
||||
plane. Keep modeling commands limited to the installed operator-present,
|
||||
exact-profile acceptance transport until durable-save confirmation is
|
||||
physically accepted.
|
||||
|
||||
Complex equipment will likely be assembled from separately useful component
|
||||
plugins into configured hardware packs, while standalone equipment remains
|
||||
|
|
|
|||
|
|
@ -41,7 +41,9 @@ K1 application control is exact-profile, live-bound and fail-closed.
|
|||
boundaries and one continuous control MQTT session. The first ten operations
|
||||
are pre-START; operation 11 is START; operation 12 is a bound ModelingStatus
|
||||
read; operations 13–14 are the post-initialization DeviceInfo/ModelingStatus
|
||||
refresh. The only preparatory mutation is time/timezone sync. No stage is
|
||||
refresh. Operation 12 is response-free in both retained captures; the sole
|
||||
later ModelingStatus response follows and belongs to required operation 14.
|
||||
The only preparatory mutation is time/timezone sync. No stage is
|
||||
collapsed, skipped or automatically retried. Captured wall-clock gaps are
|
||||
operator/UI timing, not protocol delays. Stage progression uses explicit UI
|
||||
actions and live K1 state reports.
|
||||
|
|
@ -55,9 +57,10 @@ K1 application control is exact-profile, live-bound and fail-closed.
|
|||
new operator-authorized attempt.
|
||||
8. No firmware, activation, account, update or vendor-cloud mutation belongs to
|
||||
this path. `GetCloudServerConfig` is a local K1 read.
|
||||
9. STOP completion has separate gates: correlated result, local stream
|
||||
quiescence/evidence sealing, READY plus steady green, then independent native
|
||||
project verification.
|
||||
9. STOP completion has separate gates: correlated result, protocol-reported
|
||||
unbound READY, then local stream quiescence/evidence sealing and independent
|
||||
native-project verification. Stable green is useful physical corroboration,
|
||||
not a second operator acknowledgement in the application lifecycle.
|
||||
|
||||
## Recovered START sequence
|
||||
|
||||
|
|
@ -85,7 +88,9 @@ captured special relation
|
|||
## Current implementation boundary
|
||||
|
||||
`application_bootstrap.py` provides DeviceInfo decoding, the exact ten-request
|
||||
shadow plan and a five-batch response-barrier orchestrator. Its private retained
|
||||
shadow plan and a four-window response-barrier orchestrator. The initial
|
||||
DeviceInfo response binds identity; ordinals 2–6 then remain ordered in one
|
||||
window so ordinal 3 does not create a barrier absent from the captures. Its private retained
|
||||
regression completes with 10/10 request payload/topic matches and correlated
|
||||
required responses. `ModelingStatusRequest` remains non-blocking exactly where
|
||||
the capture had no synchronous response. `application_authority.py` reads the
|
||||
|
|
@ -101,11 +106,11 @@ its injected transport sink can be called. Both shadow paths remain blocked by
|
|||
`vendor-writes-disabled` and `publisher-not-installed`; no MQTT publisher or
|
||||
automatic retry path exists.
|
||||
|
||||
`application_execution.py` adds the dormant facade boundary. An
|
||||
`application_execution.py` defines the legacy dormant shadow boundary. An
|
||||
operator-confirmed arm may retain authority for 15–300 seconds in a
|
||||
non-exportable process-memory lease and construct the shadow orchestrator. The
|
||||
lease and orchestrator are dropped together on expiry/disarm and also before
|
||||
reprovision, acquisition preparation or shutdown. Plugin v0.4.0 exposes only
|
||||
reprovision, acquisition preparation or shutdown. The prior plugin v0.4.0 exposed only
|
||||
shadow arm/disarm/state actions and redacted snapshots. The coordinator has no
|
||||
request-emission method and the installed sink is explicitly uninstalled; this
|
||||
runtime wiring does not widen write authority.
|
||||
|
|
@ -123,15 +128,14 @@ the same operation key can never be attempted again by that transport.
|
|||
|
||||
The acceptance executor requires a 15–120 second single-action permit backed by
|
||||
five explicit operator confirmations. After the failed 2026-07-18 physical
|
||||
attempt proved that five response batches alone are insufficient, the collapsed
|
||||
bootstrap entry point and standalone START/STOP were disabled. The uninstalled
|
||||
replacement binds requests 1–6 to connection, request 7 to scan-workspace entry,
|
||||
attempt exposed topic-only response routing and an invented ordinal-3 barrier, the collapsed
|
||||
bootstrap entry point and standalone START/STOP were disabled. Their staged
|
||||
replacement, installed in plugin v0.5.0, binds requests 1–6 to connection, request 7 to scan-workspace entry,
|
||||
requests 8–10 to project-prompt entry and START to a separate operator permit.
|
||||
There is no separate project-name mutation; the validated name is carried by
|
||||
START. Operations 13–14 are gated by bound `SCANNING`, project presence and
|
||||
`init_ready`, not by the observed 24–25-second duration. The same owner services
|
||||
MQTT through explicit STOP and waits for live READY plus operator-confirmed
|
||||
standby. Fault/status observations are redacted and any fault forbids automatic
|
||||
MQTT through explicit STOP and waits for live unbound READY. Fault/status observations are redacted and any fault forbids automatic
|
||||
continuation. The socket remains serviced during operator/UI waits, and each
|
||||
short action permit is created at its button confirmation rather than at
|
||||
connection time.
|
||||
|
|
@ -142,10 +146,10 @@ touch the control MQTT client. The standard UI turns one explicit launch intent
|
|||
into response-gated REST actions for session open (1–6), workspace entry (7),
|
||||
project preparation (8–10) and START. This is control compression, not protocol
|
||||
compression: each next action waits for the exact server/device phase, and
|
||||
local polling never retries or times a K1 write. STOP and steady-green
|
||||
confirmation remain separate operator actions. Preparing local reception happens before the
|
||||
START event is released. After STOP, local capture remains owned until live
|
||||
unbound READY and explicit visual confirmation. Page close, model switching,
|
||||
local polling never retries or times a K1 write. STOP remains a separate explicit
|
||||
operator action; the subsequent READY/unbound transition completes without a
|
||||
second click. Preparing local reception happens before the START event is released.
|
||||
After STOP, local capture remains owned until that live protocol state. Page close, model switching,
|
||||
polling and service state reads cannot emit START/STOP; model switching is
|
||||
blocked while the socket is open. Repository tests replace the transport with
|
||||
in-memory fakes and perform no equipment I/O.
|
||||
|
|
@ -159,8 +163,8 @@ command has not been executed in this milestone.
|
|||
|
||||
## Promotion gate
|
||||
|
||||
Promotion now requires operator-present physical acceptance of the uninstalled
|
||||
transport:
|
||||
Promotion now requires operator-present physical acceptance of the installed,
|
||||
explicitly staged transport:
|
||||
|
||||
1. provision the reviewed private authority into the fixed local Keychain item;
|
||||
2. confirm battery/storage and select one K1 over BLE;
|
||||
|
|
@ -171,7 +175,8 @@ transport:
|
|||
reads and observe calibration plus first point/pose/camera data;
|
||||
7. send one STOP without retry and correlate its response;
|
||||
8. seal local evidence while accepting the bounded stream tail;
|
||||
9. wait for READY and steady green;
|
||||
9. wait for protocol-reported unbound READY and record stable green as physical
|
||||
corroboration;
|
||||
10. verify the native project through the vendor-supported workflow.
|
||||
|
||||
Any unknown response, identity change, fault, low battery/storage or unexpected
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
- Date: 2026-07-18
|
||||
- Device scope: one owner-controlled LixelKity K1, firmware `3.0.2`
|
||||
- Result: **PAUSE — START acknowledgement is not lifecycle acceptance**
|
||||
- Result: **GO — staged START, live acquisition, STOP and READY recovery accepted**
|
||||
|
||||
This report contains no device identity, application authority, address,
|
||||
credential, raw MQTT payload or project contents. Private evidence remains in
|
||||
|
|
@ -22,6 +22,12 @@ completed and five required responses arrived, but the batch-3 response did not
|
|||
pass exact correlation. The executor stopped before START. K1 remained READY
|
||||
and steady green; point/pose counts stayed zero.
|
||||
|
||||
Subsequent comparison with the independent fast capture proved that ordinal 3
|
||||
is not an application-response barrier: ordinals 4–6 may be published before
|
||||
its response. Ordinals 3 and 6 share a response topic but use distinct unbound
|
||||
and bound sessions. The repaired collector therefore routes by operation plus
|
||||
session/device identity and waits for the combined ordinal 2–6 response window.
|
||||
|
||||
## Attempt 2
|
||||
|
||||
After adding redacted live-response diagnostics, one new explicit permit was
|
||||
|
|
@ -37,6 +43,65 @@ The bounded decoder maps the observed namespace/value as
|
|||
`0x32040000 + 307 = ALGORITHM_ERROR`. A normal operator power cycle restored
|
||||
steady green. No guessed STOP or repeated START was sent.
|
||||
|
||||
## Attempt 3
|
||||
|
||||
The production plugin UI completed BLE selection and one reviewed Wi-Fi
|
||||
provisioning operation, then opened the staged control session from one explicit
|
||||
operator launch intent. The MQTT owner completed six QoS2 publishes and
|
||||
correlated five required responses. K1 remained in `READY`; no ModelingRequest,
|
||||
START or STOP was emitted. The session failed closed on ordinal 4
|
||||
`DeviceConfigRequest`, whose correlated response carried result `0x32040002`.
|
||||
Automatic and same-session retry remained disabled.
|
||||
|
||||
Re-reading the original clean-cycle PCAP exposed an encoder defect rather than
|
||||
a lifecycle-order failure. The captured time value is protobuf `sint64`: wire
|
||||
varint `3568430060` ZigZag-decodes to Unix epoch `1784215030` (`2026-07-16
|
||||
15:17:10 UTC`). Mission Core had encoded the current positive epoch directly as
|
||||
an unsigned varint. The timezone and surrounding request structure matched, but
|
||||
the device therefore received the wrong timestamp semantics and rejected the
|
||||
time-sync request. The encoder now applies canonical `sint64` ZigZag encoding,
|
||||
with an exact captured-value regression test. A new physical attempt remains
|
||||
operator-gated and requires a fresh steady-green check.
|
||||
|
||||
## Attempt 4
|
||||
|
||||
After fresh provisioning and an operator-confirmed steady-green check, one
|
||||
explicit plugin UI launch used the repaired staged session. All 14 canonical
|
||||
requests completed on one MQTT connection: 14 QoS2 transactions, 12 correlated
|
||||
application responses and the two evidence-backed optional-response cases. K1
|
||||
reported `SCANNING`, a bound project and `init_ready=true`; the live receiver
|
||||
decoded point cloud and pose data and the operator saw the scene on screen. No
|
||||
device system error was reported.
|
||||
|
||||
The operator then issued exactly one STOP from the plugin UI. Its QoS2 and
|
||||
correlated application response completed on the same control session. K1
|
||||
reported `READY`, cleared its project binding and initialization flag, stopped
|
||||
the live streams, saved, blinked during finalization and returned to a stable
|
||||
green indicator. No retry, fallback STOP or second device command was sent.
|
||||
|
||||
The local evidence session sealed with 6,088 raw MQTT messages and 73,260,759
|
||||
payload bytes, including 2,529 point-cloud and 2,680 pose messages. The durable
|
||||
manifest recorded 7,670,356 decoded points, zero decode errors, 36.029 m of
|
||||
route and a 302.677 s observation interval. Background preparation produced a
|
||||
107,002,392-byte digest-bound Rerun recording and admitted two recorded-camera
|
||||
sources. Ranged reads of the RRD, camera manifests, MP4 initialization data and
|
||||
media segments all passed their generation and content-digest checks.
|
||||
|
||||
Natural RTSP closure during K1 STOP exposed a local finalization race: the
|
||||
camera gateway initially classified the expected source end as an acquisition
|
||||
failure before the control owner could enter its standby-confirmation phase.
|
||||
The raw capture and all committed camera segments were already durable, and the
|
||||
device STOP had succeeded. The gateway now marks device-STOP source termination
|
||||
as expected, closes that camera generation as complete and preserves the
|
||||
separate unexpected-EOF failure path. A recovery boundary also permits the
|
||||
already-observed unbound READY state to retire an already-terminal local
|
||||
acquisition without ever sending a second STOP. Synthetic regression coverage
|
||||
exercises both paths.
|
||||
|
||||
One independent product check remains outside this control acceptance: confirm
|
||||
that the vendor-native project is reusable through LixelGO or USB. The
|
||||
application START/STOP, local archive and offline byte-serving gates are closed.
|
||||
|
||||
## Canonical-diff finding
|
||||
|
||||
Re-audit of two independent owner-operated LixelGO START captures found the
|
||||
|
|
@ -62,7 +127,11 @@ The first retained capture reached START at `+202.423 s`; the faster one at
|
|||
Both preserved the stage order, sent operation 12 within about one second of
|
||||
START, sent operations 13–14 about 24–25 seconds after START and kept the same
|
||||
control MQTT connection open throughout. Neither capture disconnected or
|
||||
unsubscribed during initialization.
|
||||
unsubscribed during initialization. Neither capture contains a response to
|
||||
operation 12; each contains exactly one bound ModelingStatus response in this
|
||||
interval, immediately after operation 14. The repaired correlator therefore
|
||||
retires an unanswered optional operation-12 owner before admitting required
|
||||
operation 14.
|
||||
|
||||
The same re-audit shows that those wall-clock gaps are not protocol timers.
|
||||
Requests 1–6 follow connection, request 7 follows explicit workspace entry,
|
||||
|
|
@ -83,9 +152,14 @@ The legacy collapsed `run_bootstrap()` executor now rejects before emission.
|
|||
The replacement acceptance-only executor uses explicit connection/workspace/
|
||||
project-prompt checkpoints with no captured-delay replay. It owns operations
|
||||
1–14, gates the final refresh on live K1 state, surfaces redacted system errors,
|
||||
keeps the same socket serviced through explicit STOP and waits for READY plus
|
||||
operator-confirmed standby. The socket is also serviced between every UI action;
|
||||
keeps the same socket serviced through explicit STOP and waits for unbound
|
||||
READY. The socket is also serviced between every UI action;
|
||||
START/STOP permits begin only at their respective confirmations. Standalone
|
||||
START/STOP are rejected. This remains an
|
||||
uninstalled synthetic-test-only boundary; no new physical attempt is authorized
|
||||
by this implementation. Physical double-click remains the canonical fallback.
|
||||
START/STOP are rejected. Plugin v0.5.0 installs the staged boundary behind
|
||||
explicit operator UI actions; no state read, poll, navigation event or test may
|
||||
authorize a physical attempt. Attempt 4 proved that path through live scanning,
|
||||
one explicit STOP and stable-green standby. A 2026-07-19 UX review removed the
|
||||
post-READY button because the live READY/unbound report already proves the state;
|
||||
the explicit pre-STOP operator action remains. Physical double-click remains the
|
||||
operational fallback; native-project reuse is still checked separately. The
|
||||
follow-up archive/UX findings are recorded in Lab 004.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,106 @@
|
|||
# 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: direct LAN is active; alternative connection modes remain disabled
|
||||
UI anchors until independently accepted.
|
||||
- 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.
|
||||
|
|
@ -34,7 +34,7 @@ The plugin owns:
|
|||
acquisition pipeline UI.
|
||||
- the interactive canonical application-control session: one socket owner, one
|
||||
operator launch intent, response-gated workspace/project/START stages, a
|
||||
separate STOP confirmation, live status gates and no automatic retry.
|
||||
separate explicit STOP action, live status gates and no automatic retry.
|
||||
|
||||
The plugin does not own:
|
||||
|
||||
|
|
@ -74,11 +74,10 @@ in-process and its health is lifecycle-only; process isolation, crash/restart
|
|||
containment and signed deployment remain later supervisor gates.
|
||||
|
||||
The compatibility profile is descriptive and cannot itself authorize a vendor
|
||||
write. The current runtime cannot inspect K1 firmware: it keeps the profile
|
||||
inactive until the operator explicitly attests firmware `3.0.2` and direct-LAN
|
||||
topology, and records that basis as `operator-attested` rather than
|
||||
device-derived evidence. Validate the current exact-match profile without
|
||||
device I/O with:
|
||||
write. The UI selects the exact firmware `3.0.2` / direct-LAN profile; the
|
||||
canonical bootstrap then requires a correlated live `DeviceInfo` match for
|
||||
model `LixelKity K1`, platform type `A4`, activation and firmware before START.
|
||||
Validate the current exact-match profile without device I/O with:
|
||||
|
||||
```bash
|
||||
uv run python plugins/xgrids-k1/profile_loader.py
|
||||
|
|
@ -92,12 +91,13 @@ START carrying the project name. Local state polling controls only when the
|
|||
next reviewed action may be requested; it never schedules a device command by
|
||||
elapsed time. START waits for bound `SCANNING + project + init_ready` before
|
||||
operations 13–14. STOP is separately permitted, never retried, and keeps the same socket until K1
|
||||
reports unbound READY and the operator confirms a steady green indicator. The
|
||||
reports unbound READY. That protocol state automatically completes local sealing;
|
||||
stable green is physical corroboration rather than a second UI gate. The
|
||||
admin CLI still provisions the fixed Keychain item through Apple's hidden
|
||||
prompt without accepting the private value as an argument. No physical command
|
||||
is emitted merely by loading the plugin, opening the page, navigating, polling
|
||||
state or running repository tests. Full v0.5.0 physical acceptance remains an
|
||||
operator-run gate.
|
||||
state or running repository tests. The full v0.5.0 START/live/STOP/save path is
|
||||
physically accepted on the reviewed K1/A4/FW 3.0.2 unit.
|
||||
|
||||
The optional owner-controlled iPhone/LixelGO observation tool lives under
|
||||
[`lab/iphone-capture/`](lab/iphone-capture/). It pins `pymobiledevice3` in a
|
||||
|
|
|
|||
Loading…
Reference in New Issue