feat(perception): integrate calibrated operator pipeline

Add calibrated K1 projection, recorded and near-live perception qualification, unified Rerun operator layers, bounded replay admission, audited viewer controls, worker experiments, and lab evidence.

docs/handoff/001_MISSION_CORE_AI_WORKER_K1_20260719.redacted.md

@@ -0,0 +1,627 @@
+# Mission Core handoff: AI worker, external perception and K1 Quick Connect
+
+Date of factual refresh: 2026-07-19 21:15 MSK.
+
+> 2026-07-20 superseding update: official firmware analysis proved that the
+> exact K1 `3.0.2` AP credential is firmware-constant and that the SSID follows
+> an identity/MAC rule. A prepared Mac completed AP-ready, CoreWLAN association
+> and the normal control lifecycle. This did **not** solve clean-host bootstrap:
+> the provider had been separately imported from the firmware archive. The
+> owner closed this product branch, rejected automatic firmware download,
+> iPhone extraction and hard-coding, retained the working UI/Keychain state and
+> selected Bridge/direct-LAN as the continuing route. Canonical details:
+> `docs/lab/004_K1_FW302_AP_CREDENTIAL_PROVIDER_20260720.redacted.md`.
+
+This document is a transition context for a new engineering chat. It separates
+committed/accepted work from current uncommitted K1 work and from future plans.
+It contains operational addresses, ports, repository paths and public
+fingerprints, but no password, private key, token, device secret, raw capture or
+camera image.
+
+## Executive state
+
+Mission Core currently has two independently meaningful physical results:
+
+1. The Mac/K1 control and archive path is accepted for one owner-controlled
+   XGRIDS LixelKity K1, firmware 3.0.2, Bridge/direct-LAN, handheld, GNSS without
+   RTK. Mission Core can run the reviewed MQTT bootstrap, START acquisition,
+   display live points, send explicit STOP, observe final READY/unbound and open
+   the durable Rerun/camera archive.
+2. A replaceable Windows RTX 4090 worker is accepted for one recorded,
+   camera-only perception job. The Mac publishes a bounded immutable
+   `missioncore.compute-job/v1`; Windows verifies it, runs pinned YOLOX-S through
+   pinned Triton, publishes `missioncore.compute-result/v1`; Mission Core
+   revalidates and projects the optional result into the matching saved Rerun
+   recording.
+
+This is not yet a live autonomous-vehicle stack. The worker has no K1 authority,
+Triton is not exposed to the LAN, the current transfer is SSH/SCP laboratory
+bootstrap, Tailscale is not installed, and live fan-out/fusion/tracking/free
+space/control are not accepted.
+
+The current K1 Quick Connect implementation is a separate uncommitted worktree.
+It proved BLE AP activation, exact AP-ready observation and prepared-host native
+macOS association/control. It remains laboratory-only because a clean host has
+no autonomous evidence-backed credential source. The implementation and current
+machine state are retained, but Bridge/direct-LAN is the product route.
+
+## Canonical topology and authority
+
+```text
+XGRIDS K1
+  | BLE / MQTT / RTSP
+  v
+Mission Core Edge on Mac
+  - sole K1 command authority
+  - sole acquisition lifecycle owner
+  - authoritative raw .k1mqtt + camera fMP4 archive
+  - durable session catalog and Rerun projection
+  |
+  | bounded immutable missioncore.compute-job/v1
+  | current lab transport: SSH/SCP
+  v
+Mission Core AI Server Worker on Windows / RTX 4090
+  - verifies the complete job and every digest
+  - reconstructs and decodes only the admitted camera epoch
+  - calls local pinned Triton / pinned model
+  - atomically publishes missioncore.compute-result/v1
+  |
+  v
+Mission Core Edge validates result and creates optional derived Rerun layer
+```
+
+The Windows machine is an executor, not a second Mission Core. It does not know
+K1 credentials, IP, MQTT topics or RTSP endpoints and cannot discover,
+provision, START or STOP the scanner. Derived inference never replaces or
+rewrites the Mac source archive.
+
+## Why the original architecture proposal was narrowed
+
+The supplied architecture review was accepted as a boundary, not as a mandate
+to install every named technology immediately. The following principles were
+kept:
+
+- one vendor owner for K1 control and source streams;
+- immutable raw-first evidence and separately versioned derived data;
+- replaceable external compute;
+- local mission/safety authority rather than a remote GPU dependency;
+- explicit separation of command/state, real-time flow and archive transport;
+- declarative, reproducible deployment built mostly from mature components.
+
+The following were deliberately deferred because they would precede the first
+vertical evidence:
+
+- custom universal Mission Core Node Runtime;
+- custom cross-platform installer, node console, OTA, model package format and
+  generic scheduler;
+- ROS 2 before a real onboard computer, robot state and actuator/autopilot
+  contract exist;
+- BehaviorTree.CPP before a local mission executor is needed;
+- Zenoh until direct/routed transport can be compared on identical data;
+- MCAP as a replacement for the accepted K1 raw source;
+- dora-rs as a control/safety foundation;
+- LM Studio for the camera/LiDAR detector vertical.
+
+Triton was selected for the first executor because it already provides pinned
+model repositories, HTTP/gRPC, health, metrics and replaceable inference
+backends. Mission Core continues to own its northern job/result contracts.
+
+## Windows host identity and hardware
+
+Live read-only inventory at the refresh time:
+
+- host: `<worker-host>`;
+- interactive/SSH account: `<worker-host>\<worker-user>`;
+- OS: Windows 11 Pro x64, version 10.0.26200, build 26200;
+- last boot: 2026-07-19 15:38:18 MSK;
+- PowerShell: 5.1.26100.7705;
+- CPU: Intel Core i9-13900KF, 24 cores / 32 logical processors;
+- RAM: 95.85 GiB;
+- GPU: NVIDIA GeForce RTX 4090, 24,564 MiB VRAM, compute capability 8.9;
+- NVIDIA driver: Studio 610.47 WHQL;
+- live GPU snapshot: about 10,229 MiB used, 13,910 MiB free, 41 C and 68.68 W;
+- disk `C:`: NTFS, 1,861.99 GiB total, 1,700.86 GiB free;
+- disk `D:`: NTFS label `DC`, 1,863.00 GiB total, 411.44 GiB free;
+- Git: 2.53.0.windows.1;
+- Codex CLI: 0.142.1;
+- FFmpeg: 8.0.1 essentials build;
+- native host Python: not installed; Windows Store aliases exist but do not
+  resolve to a Python runtime;
+- Tailscale: not installed.
+
+The driver was upgraded from 591.86 to 610.47 after the first Triton startup
+showed CUDA Minor Version Compatibility mode. The official NVIDIA installer was
+978,481,008 bytes, SHA-256
+`59AC4A1659664AAD0A6FC525E5DF99B3FA76887BDE663F9E36E0E7EBB5DBA937`,
+had a valid NVIDIA Corporation Authenticode signature and returned exit code 0.
+After reboot, the compatibility warning disappeared and the full compute smoke
+passed.
+
+## WSL and Docker substrate
+
+- WSL: 2.7.8.0;
+- default distribution: Ubuntu 24.04, WSL version 2;
+- kernel: 6.18.33.1-microsoft-standard-WSL2;
+- Docker Desktop distribution: WSL2 and currently running;
+- Docker Desktop: 4.78.0;
+- Docker Engine/client: 29.5.3;
+- Docker Compose: 5.1.4;
+- Docker Linux VM: 32 CPUs and approximately 50.43 GB memory;
+- storage driver: overlayfs;
+- NVIDIA container runtime is registered; default runtime remains `runc` and
+  the Compose service explicitly requests all GPUs.
+
+Docker Desktop's engine-owned image/layer VHDX remains on `C:`. Mission Core
+application state is on `D:`. Moving Docker's VHDX was intentionally not made a
+pilot prerequisite.
+
+## Isolated Windows directory layout
+
+Root: `D:\NDC_MISSIONCORE`.
+
+```text
+D:\NDC_MISSIONCORE\
+  README.md
+  workspace\
+    mission-core-compute\      versioned deployment and worker repository
+  runtime\
+    cache\                     disposable downloads/build cache
+    derived\                   decoded intermediates and immutable results
+    docker-cli\                isolated Docker CLI state for SSH automation
+    jobs\                      bounded transferred compute jobs
+    logs\                      service/task transcripts
+    models\                    Triton model repository and weights
+    tmp\                       disposable temporary data
+  secrets\                     machine-local credentials, never committed
+```
+
+The root itself is not a Git repository. Only
+`D:\NDC_MISSIONCORE\workspace\mission-core-compute` is versioned. Runtime
+weights, jobs, results, caches, logs and secrets are outside Git.
+
+## Windows worker repository
+
+Repository:
+`D:\NDC_MISSIONCORE\workspace\mission-core-compute`.
+
+Current state:
+
+- branch: `main`;
+- HEAD: `a3c36c3 feat(perception): prove recorded Triton vertical`;
+- previous commits:
+  - `3c62815 guard native CUDA runtime compatibility`;
+  - `d1043d0 qualify CUDA 13.3 driver path`;
+  - `8edd003 bootstrap Windows GPU compute node`;
+- working tree: clean;
+- Git remote: none configured.
+
+Versioned content includes `compose.yaml`, `.env.example`, model config,
+baseline/decision/acceptance docs, bounded PowerShell start/stop/test/handoff
+scripts and `worker/run_yolox_recorded.py`.
+
+No custom Windows service, host Python environment, LM Studio integration,
+universal model loader or second Mission Core instance was installed.
+
+## Active Triton deployment
+
+Container: `mission-core-triton`, Compose project `mission-core-compute`.
+
+Pinned image:
+
+`nvcr.io/nvidia/tritonserver:26.06-py3@sha256:58df7489c3f2276f9591d500a012dee03e23d35543ce3c390b4c001e6bf90794`
+
+The local image reports Triton 2.70.0 and a roughly 22.7 GB image size.
+
+Effective deployment properties:
+
+- `gpus: all`;
+- shared memory: 2 GiB;
+- model control: explicit;
+- automatic model config completion: disabled;
+- strict readiness: enabled;
+- server does not exit for one model error;
+- HTTP 8000, gRPC 8001 and metrics 8002 enabled;
+- every host binding is loopback-only: `127.0.0.1:8000-8002`;
+- `D:\NDC_MISSIONCORE\runtime\models` is mounted read-only at `/models`;
+- `no-new-privileges:true`;
+- container restart policy: `no`;
+- health check: HTTP `/v2/health/ready` every 5 seconds;
+- current state: running and healthy;
+- live, ready and metrics checks: HTTP 200;
+- GPU metrics present;
+- CUDA compatibility warning absent;
+- deprecated model-config warning absent.
+
+The committed `.env` contains only the loopback bind and pinned Triton image.
+No credential is required for the current loopback-only service.
+
+## Startup, shutdown and task bridge
+
+The normal operator scripts are:
+
+```powershell
+Set-Location D:\NDC_MISSIONCORE\workspace\mission-core-compute
+.\scripts\Start-MissionCoreCompute.ps1
+.\scripts\Test-MissionCoreCompute.ps1
+.\scripts\Stop-MissionCoreCompute.ps1
+```
+
+`Start-MissionCoreCompute.ps1` uses the node-local Docker CLI directory,
+targets Docker Desktop's Linux engine pipe, creates loopback-only `.env` from
+the example when absent, starts Docker Desktop when needed, performs Compose
+pull/up and waits for Triton readiness.
+
+Docker Desktop's Windows credential helper rejects the OpenSSH network-logon
+token even for public image pulls. The reviewed workaround is not a second
+deployment path: `Invoke-StartAsInteractiveUser.ps1` creates/starts the
+on-demand `MissionCore-StartCompute` task in the logged-on user's limited
+interactive token. It executes the same committed start script and writes
+`D:\NDC_MISSIONCORE\runtime\logs\start-compute-latest.log`.
+
+Scheduled task state:
+
+- `MissionCore-DockerDesktop`: enabled logon trigger for the interactive user,
+  limited privilege, currently Running;
+- `MissionCore-StartCompute`: no trigger, on-demand only, last result 0,
+  currently Ready;
+- Triton Compose restart policy is `no`.
+
+Therefore Docker Desktop starts at user logon, but Triton is not a fully
+autonomous reboot-surviving service. It is started explicitly/on demand.
+
+## Model repository
+
+Accepted model: official YOLOX-S ONNX release 0.1.1rc0, Apache-2.0.
+
+- model path: `runtime\models\yolox_s\1\model.onnx`;
+- byte length: 35,858,002;
+- SHA-256:
+  `C5C2D13E59AE883E6AF3B45DAEA64AF4833A4951C92D116EC270D9DDBE998063`;
+- Triton platform: ONNX Runtime GPU;
+- model version: 1 only;
+- input: FP32 `[1,3,640,640]`, name `images`;
+- output: FP32 `[1,8400,85]`, name `output`;
+- one GPU instance;
+- preprocessing: bilinear resize, top-left letterbox, BGR, pad 114;
+- postprocessing: official YOLOX grid/stride decode, score 0.25, NMS 0.45,
+  COCO-80.
+
+The model is useful only as a contract/timing smoke. It is not accepted for
+navigation, obstacle avoidance, free-space or safety decisions.
+
+## Accepted recorded job and result
+
+Source Mission Core session:
+`20260718T201659Z_viewer_live` / display name `TEST007`.
+
+Accepted input:
+
+- source: `sensor.camera.left`, physical codec epoch 1;
+- job: `recorded-camera-fae25b92ecf645c2c9765dd4`;
+- schema: `missioncore.compute-job/v1`;
+- full input SHA-256:
+  `fae25b92ecf645c2c9765dd4b4963f23cf8c101f22fd5a2e14a104f0b447140d`;
+- 59 digest-bound files, 4,567,569 package bytes;
+- reconstructed H.264 stream: 4,549,458 bytes;
+- stream SHA-256:
+  `bceca577f762fdb79c4e8901e5c2a2330fd07d24dc091b1b703c5af4010d8a56`;
+- decode: H.264 High, 800x600, 56 frames, 5.497 seconds;
+- synchronization: `host-arrival-best-effort`;
+- frame timestamps are made strictly increasing from best-effort decode time;
+  this is not calibrated camera/LiDAR sensor time.
+
+Accepted result:
+
+- result:
+  `result-5484a72e81192b19f4e1da2a2dcfd10c876c277ff3e96c6d60cbc9d917b9f604`;
+- schema: `missioncore.compute-result/v1`;
+- detection schema: `missioncore.object-detections/v1`;
+- 56/56 frames processed;
+- 54 frames with detections;
+- 56 generic COCO `person` detections;
+- detection artifact: 23,802 bytes;
+- detection SHA-256:
+  `71b291616e87bbdd2b7a295b1e00dac2ff3e60c627e63b72a27ba802c32a3ae0`;
+- client-observed inference latency: mean 15.611 ms, p50 15.001 ms,
+  p95 23.728 ms, max 31.099 ms.
+
+Triton currently reports 168 successful inference requests, 0 failed. Three
+56-frame executions account for that count. The final exact repeated command
+reused the already published content-addressed result and did not increase the
+counter, proving idempotent reuse.
+
+The first runner attempt completed inference but failed its post-inference EOF
+guard. No partial result was published. The runner was corrected before the
+accepted immutable result was produced.
+
+## Rerun result projection on the Mac
+
+Mission Core revalidates exact session/job/result binding, all digests,
+timestamps, dimensions and frame count before projection. It builds one complete
+RRF2 derived overlay, approximately 62.55 MB, cached privately by
+result/recording identity.
+
+The browser accepts the overlay on an isolated Rerun channel. Missing or invalid
+perception returns no optional layer and never replaces the base point-cloud
+recording. In TEST007 the `Распознавание` switch showed the real recorded left
+camera frame with `person · 34%` Boxes2D; `Облако точек` returned to the base 3D
+view.
+
+Committed Mac work:
+
+- `648d5bc feat(compute): add bounded camera job contract`;
+- `31fc4f6 docs(perception): record external worker acceptance`;
+- `2b53168 feat(perception): project recorded results into Rerun`;
+- `ada2a55 docs(perception): record Rerun projection acceptance`.
+
+Mac `main` is currently at `ada2a55`; `origin/main` remains at `75d2e5d`, so the
+four perception commits are local and not pushed.
+
+## Other active workloads on the RTX host
+
+The GPU workstation is shared. These containers are not part of Mission Core:
+
+- `sentinel-frigate`, image `ghcr.io/blakeblackshear/frigate:0.17.2-tensorrt`,
+  healthy, publishes host ports 5000, 8554, 8555 TCP/UDP and 8971;
+- `sentinel-ollama`, image `ollama/ollama:latest`, publishes host port 11434 and
+  has no configured container health check.
+
+Their current resource use contributes to the roughly 10 GiB observed GPU
+allocation. Mission Core currently has no resource reservation, scheduler or
+admission policy against these workloads. Long-epoch and live performance tests
+must record this co-tenancy or isolate it deliberately.
+
+## SSH access from the Mac
+
+Windows OpenSSH was installed through official winget package
+`Microsoft.OpenSSH.Preview` 10.0.0.0 because Windows Feature-on-Demand failed:
+
+- `Add-WindowsCapability`: Access denied;
+- DISM with `/LimitAccess`: `0x800f0912`, source files not found;
+- `wuauserv` startup/ACL changes were denied by host policy.
+
+Current Windows SSH facts:
+
+- service: `sshd`, Running, Automatic;
+- binary: `C:\Program Files\OpenSSH\sshd.exe`, version 10.0.0.0;
+- listen: `0.0.0.0:22` and `[::]:22`;
+- ED25519 host fingerprint:
+  `SHA256:LgvblT9h+5KJFtkDq6JWGUyvgpiFyeL6cztVVMY0ZQM`;
+- public-key authentication: enabled;
+- password authentication: also enabled;
+- strict modes: enabled;
+- max authentication attempts: 6.
+
+The Mac connection uses a key and strict pinning, but the server itself is not
+yet key-only. Disabling server password authentication is an explicit future
+hardening action, not a completed fact.
+
+Mac SSH alias in `~/.ssh/config`:
+
+```sshconfig
+Host mission-gpu
+    HostName <worker-host>.local
+    User <worker-user>
+    IdentityFile ~/.ssh/id_ed25519
+    IdentitiesOnly yes
+    HostKeyAlias mission-gpu
+    UserKnownHostsFile ~/.ssh/known_hosts_mission_core
+    StrictHostKeyChecking yes
+    ServerAliveInterval 15
+    ServerAliveCountMax 3
+```
+
+Connection and safe read-only smoke:
+
+```bash
+ssh -o BatchMode=yes mission-gpu whoami
+ssh -o BatchMode=yes mission-gpu \
+  'powershell.exe -NoProfile -NonInteractive -Command "$env:COMPUTERNAME"'
+```
+
+The dedicated known-hosts entry matches the Windows ED25519 fingerprint above.
+No private key or password is stored in this repository or Ops.
+
+## Windows network and firewall
+
+Current physical Wi-Fi:
+
+- SSID/profile: `<owner-lan-ssid>`;
+- interface: `Беспроводная сеть`;
+- category: Private;
+- IPv4: `<worker-lan-ip>/<owner-lan-prefix>`;
+- IPv4 connectivity: Internet.
+
+VPN profile:
+
+- name: `Сеть 5`;
+- interface: `hidemy.name VPN OpenVPN Adapter`;
+- category: Public;
+- IPv4: `<vpn-assigned-ip>/<vpn-prefix>`.
+
+Windows Firewall is enabled for Private and Public profiles. The active custom
+SSH rule is:
+
+- name: `MissionCore-SSH-From-Mac`;
+- display name: `MISSION CORE SSH from Mac`;
+- enabled, inbound allow, Private only;
+- interface: `Беспроводная сеть` only;
+- protocol/local port: TCP/22;
+- remote address: `LocalSubnet`;
+- local address: Any.
+
+The broad MSI-created `OpenSSH SSH Server Preview (sshd)` inbound rule is
+disabled. The current custom rule is broader than the original single Mac IP
+because it admits the local subnet, but it remains confined to the Private Wi-Fi
+interface and does not apply to the Public VPN profile.
+
+Triton ports 8000-8002 listen only on 127.0.0.1. No Windows firewall rule exposes
+them to the LAN. Consequently the Mac cannot yet call Triton directly; the
+accepted recorded path transfers bounded artifacts through SSH/SCP and executes
+the runner on Windows.
+
+The current worker IPv4 `<worker-lan-ip>` previously appeared as a K1 target in
+historical TEST007 evidence. Before concurrent K1/worker LAN exposure, reserve
+non-conflicting addresses or prove topology separation. Do not expose Triton on
+this address until that conflict and the source-restricted firewall contract are
+reviewed.
+
+## Current K1 Quick Connect state
+
+The K1 plugin exposes three explicit local connection directions:
+
+- Bridge/direct-LAN: K1 joins an existing shared network; physically accepted;
+- Direct Connect/controller-hotspot: K1 joins the controller's network;
+  implemented/offline-verified, not physically accepted;
+- Quick Connect/device-AP: K1 becomes the AP and a prepared Mac joins it;
+  physically accepted on the current host, retained as laboratory-only.
+
+The reviewed LixelGO flow is:
+
+1. keep one BLE connection open;
+2. write one reviewed 100-byte AP-enable frame (99 zero bytes plus final 1);
+3. poll `7f02` until the live status reports `WIFI_AP`, baseline address
+   `192.168.56.1` and the AP-ready byte changes from 0 to nonzero;
+4. while BLE remains alive, use the native OS Wi-Fi API to scan exact SSID and
+   associate;
+5. continue to K1 network/control only after association.
+
+The earlier evidence session
+`.runtime/mission-core/evidence/sessions/20260719T173132Z_viewer_k1_ap_association`
+proved AP activation, AP-ready and native SSID discovery but stopped at the
+secure prompt. A later prepared-host session
+`.runtime/mission-core/evidence/sessions/20260719T220850Z_viewer_k1_ap_association`
+completed one CoreWLAN association and admitted `192.168.56.1`; the normal UI
+then completed control/acquisition. The operator disconnected afterward only to
+restore the external chat route.
+
+Final credential findings:
+
+- LixelGO persists `WiFiAP_SSID` and `WiFiAP_Password` in a per-device profile;
+- the Unity flow later passes those profile values to the native join path;
+- no password derivation from DeviceInfo, serial, BLE UUID or AP SSID was found;
+- official K1 `3.0.2` firmware contains one firmware-constant AP credential and
+  constructs the SSID from device identity with a MAC fallback;
+- the reviewed BLE exchange enables the AP and reports readiness but exposes no
+  observed credential response;
+- LixelGo login and the scanner AP are separate layers. The owner performed no
+  explicit hardware-to-account pairing, which is consistent with the local
+  firmware-defined credential, but does not prove universal account access;
+- the successful Mission Core run depended on a separate firmware import into
+  this Mac's Keychain. A copied build on a clean Mac would fail before BLE.
+
+The owner closed this branch. Do not download firmware during connection, seek
+the value from iPhone, hard-code it, or present machine-local Keychain state as
+portable automation. Keep the existing UI, implementation, Keychain/provider
+state and evidence intact. Continue through Bridge/direct-LAN.
+
+## Current Mac repository and runtime state
+
+Repository:
+`<mission-core-repository>`.
+
+- branch: `main`;
+- HEAD: `ada2a55`;
+- `origin/main`: `75d2e5d`;
+- local Mission Core HTTP service: `127.0.0.1:8000`;
+- current health: service OK, one of one plugin runtimes ready;
+- current local server PID at 2026-07-20 closure refresh: 97887;
+- worker/perception commits are clean and local;
+- K1 Quick Connect changes are uncommitted and make the worktree dirty.
+
+The dirty set spans K1 docs/profile/frontend, native CoreWLAN helper,
+BLE AP activation, host-network adapter and tests. It must not be reset or
+cleaned because it contains the current physical Quick Connect implementation
+and evidence-aligned fixes.
+
+Latest validation of the current dirty tree:
+
+- complete backend suite: passed;
+- Ruff: clean;
+- mypy: clean across 75 source files;
+- frontend: 140 unit tests passed;
+- TypeScript typecheck: clean;
+- production Vite build: clean;
+- Swift helper parse: clean;
+- `git diff --check`: clean.
+
+## What is accepted, partial and not started
+
+Accepted:
+
+- physical K1 Bridge control lifecycle START/live/STOP/READY;
+- durable session catalog, point cloud and camera playback;
+- bounded content-addressed recorded camera job;
+- Windows digest verification and deterministic 56-frame decode;
+- pinned Triton/YOLOX-S inference on RTX 4090;
+- immutable content-addressed result and exact-repeat reuse;
+- validated optional Rerun camera/Boxes2D projection;
+- strict SSH host-key pinning and local-lab access path;
+- reproducible Windows worker repository and operator scripts.
+
+Partial/laboratory-only:
+
+- Quick Connect is physically accepted on one prepared Mac but has no clean-host
+  credential bootstrap and is closed as a product route;
+- Windows is a reproducible lab worker but Triton is loopback-only and manually
+  started;
+- SSH is source-restricted by firewall and the Mac uses a key, but sshd still
+  permits passwords;
+- the worker result is recorded-only and camera-only;
+- GPU resource use is shared with unrelated Frigate/Ollama workloads.
+
+Not accepted/not implemented:
+
+- Direct Connect physical test;
+- second K1 or firmware portability matrix;
+- RTK, UGV, UAV, calibrated sensor time or camera/LiDAR extrinsics;
+- long TEST007 epoch throughput/resource qualification;
+- bounded live inference, queue/drop policy and recovery testing;
+- direct authenticated LAN worker transport;
+- Tailscale/routed worker transport and deny-by-default grants;
+- point-cloud inference, camera/LiDAR fusion, tracking, segmentation or free
+  space;
+- actuator/autopilot integration, mission executor or safety authority;
+- production process supervision, operation journal, retention, encryption,
+  replication and resource scheduler;
+- custom installer/node console/model marketplace, intentionally deferred.
+
+## Recommended next gates in exact order
+
+1. Continue K1 operation through the accepted Bridge/direct-LAN path. Preserve
+   the prepared Quick Connect implementation and evidence without extending it.
+2. Commit the retained K1 mechanism/evidence/docs in logical commits when the
+   owner chooses; do not claim clean-host portability.
+3. Qualify the 206-second TEST007 camera epoch on the same immutable model
+   profile, recording transfer, decode, inference, GPU memory, queue depth and
+   co-tenant effects.
+4. Define a direct authenticated worker endpoint that preserves the current
+   `compute-job/result` schemas; reserve a non-conflicting worker address and add
+   a source-restricted firewall rule before any LAN port exposure.
+5. Add bounded live fan-out from the sole Mac RTSP owner with explicit sampling,
+   latest-wins/drop counters, deadlines, stale state and failure isolation.
+6. Kill/restart Triton, power off the worker and break transport while proving
+   K1 control/raw archive continue and the UI reports degraded perception.
+7. Repeat the same endpoint contract through Tailscale; do not expose public
+   Triton ports.
+8. Only after this evaluate tracking, segmentation/free-space and a LiDAR CPU
+   processor. Keep every result versioned and non-safety until calibrated and
+   separately accepted.
+9. Evaluate ROS 2/BehaviorTree only when an actual onboard computer,
+   robot/autopilot and actuator/safety contract exist. Evaluate Zenoh only
+   against the measured direct transport.
+
+## Canonical local sources for the next chat
+
+- `docs/10_EXTERNAL_PERCEPTION_WORKER.md` — job/result and Rerun contract;
+- `docs/adr/0014-bounded-external-perception-worker.md` — accepted architecture;
+- `docs/lab/005_FIRST_RECORDED_PERCEPTION_20260719.redacted.md` — physical
+  recorded evidence;
+- `src/k1link/compute/jobs.py` — compute job creation/validation;
+- `src/k1link/compute/results.py` — result validation/Rerun projection inputs;
+- `docs/adr/0013-k1-local-connection-matrix.md` — K1 connection directions;
+- `src/k1link/device_plugins/xgrids_k1/ble/ap_activation.py` — reviewed AP
+  activation session;
+- `src/k1link/host_network/wifi.py` — OS Wi-Fi profile boundary;
+- `plugins/xgrids-k1/macos/associate_wifi.swift` — CoreWLAN and Keychain helper;
+- this handoff — exact current machine/runtime/SSH/partial-acceptance snapshot.