Advise — add-sensor-lens-kit

ADVISE: send-back READER: sol-arch-review SPAWN: /Users/dukejones/work/ClientProjects/AllSystemsGo/AICamera/.spawns/add-sensor-lens-kit-1789037141-10627-76690e3c

Independent take (blind pass)

1. Pin the body camera to the Thor enclosure and a native CSI-2/GMSL/HSB ingest path suitable for 4K30.
2. Pin satellites to camera-side 4K30 H.265 over PoE; GMSL RAW is not the v1 satellite fabric.
3. Pin bring-up to one body plus two satellites, with four- and six-satellite counts reserved for budget tables only.
4. Require electronic iris and focus on picture cameras; treat electronic zoom as optional for v1.
5. Require Cooke /i-class metadata from every camera, normalized into frame/timecode-locked JSONL beside each HEVC file.
6. Require the shipped satellite module to expose UART/control for lens metadata and ToF; a sealed PoE turret is only a bring-up stub.
7. Pin one 1D ToF sensor per satellite and one shared Ethernet 3D lidar on the rig, not a 3D lidar per camera.
8. Refuse exact camera or lens SKUs until datasheets establish mechanics, BSP support, power, thermal, and control compatibility.
9. Refuse a design that makes Thor encode every satellite stream, because record continuity and the T4000 encode ceiling require edge encoding.
10. Accept the tradeoff of lower-latency native body capture versus scalable PoE satellites with greater latency and metadata-synchronization risk.

Comparison and steelman

The design gets the central fabric decision right: local native capture for the body, edge-encoded PoE H.265 for two bring-up satellites, and no premature SKU commitment. Its strongest defense is that the living hardware-kit spec already defines the Cooke-class JSONL contract, so this delta need not repeat every sidecar field. That is a good boundary, but the design still has to identify hardware classes capable of satisfying that contract rather than recommending classes that cannot.

Findings

1. The production body path is not pinned. design.md:11 and the delta at specs/hardware-kit/spec.md:5 allow HSB without marking it as the temporary AGX bring-up fallback described in docs/SENSORS.md:19. The packet invariant and product direction are an enclosure-mounted CSI/GMSL body path. Distinguish the bring-up escape hatch from the production requirement.
2. The satellite class contradicts the lens-metadata contract. design.md:12-13 recommends an industrial P-/DC-iris box, while docs/SENSORS.md:25-27 explicitly says P-iris alone is insufficient for a hero satellite and the living spec requires frame-accurate Cooke-class metadata from every camera. Keep a turret as an encode mule, but specify a shipped class with a barrel/electronic metadata path into the Ethernet sidecar flow.
3. The sensor design omits its range/control path. docs/SENSORS.md:30-33 requires one UART 1D ToF sensor per satellite and a shared rig lidar. The design does not explain how the satellite module exposes that UART or keeps ToF/lens observations aligned with the camera sidecar. This can remain class-level, but it cannot remain absent.

Exact retail SKUs remain correctly deferred to add-datasheet-pack, and the existing 1+2 / 4 / 6 stream-budget tables need no duplication here. Resolve the two owed task boxes, then re-advise.