Re-advise — add-sensor-lens-kit

ADVISE: accept READER: fable-5.1-arch-review SPAWN: /Users/dukejones/work/ClientProjects/AllSystemsGo/AICamera/.spawns/add-sensor-lens-kit-1789038683-8881-84d4b0da

Read after Grok’s send-back amend. Prior send-back: reviews/2026-09-10-advise.md (sol-arch-review).

Independent take (blind pass)

Written from the proposal Why, openspec/specs/hardware-kit/spec.md, the delta, docs/SENSORS.md, docs/CAMERAS.md, and docs/LENS.md before opening design.md or tasks.md.

1. Pin: the body must satisfy the living-spec /i sidecar, and CAMERAS.md says no CSI/GMSL module speaks /i. Design must name the body /i path (PL or LPL contacts or barrel port to a UART on Thor), not defer it to “a reader later”.
2. Pin: sidecar timestamp source per camera. Body is Thor-clocked. Sat picture is camera-encoded; /i bridge and ToF are separate Ethernet streams. Design must say which clock stamps them (PTP on the sat vs Thor arrival) or “locked to timecode” is unmet.
3. Pin: the shipped sat is RV1126B core in our case with UART ToF and barrel /i. That is firmware we own, forwarding ToF and /i over Ethernet. Design must say whether this change scopes that firmware or hands it to a follow-on.
4. Pin: “electronic iris and/or focus” is too loose against a sidecar that requires both T-stop and focus distance. Cine /i glass is manual with external FIZ motors; EF electronic glass has in-lens motors but needs an EF electronic mount. Design must pick the fork or name both.
5. Pin: body pipe is CSI-2. GMSL on the body is a deserializer card and BSP weeks for a 20 cm flex. “CSI-2 or GMSL” is acceptable only if GMSL is not on the body BOM.
6. Refuse: HSB or USB as production body ingest. Refuse: sealed P-iris turret as shipped sat class. Both are in the delta; the design must not reopen them.
7. Refuse: retail SKUs in this change. add-datasheet-pack owns them, and the living-spec manifest rule applies to RV1126B module, ToF, and /i bridge once steered.
8. Tradeoff: PoE H.265 sats give 100 m, cheap BOM, days of bring-up, and no PoE on Thor. They cost RAW into ISP, cuVSLAM on sat pixels, and hardware genlock. Sync is PTP class. Design should state this as accepted, not silent.
9. Encoder budget: body takes one of two T4000 NVENC HQ 4Kp30 slots; sats are camera-encoded and Thor only remuxes. Consistent with the living spec sag rule.
10. Power: PoE switch feeds sats and never backfeeds Thor. ToF and /i bridge power on the sat module itself, not a third supply.

Comparison

Both send-back conditions are met, in the design and in the delta, and both packet anchors hold.

• HSB/USB is named as AGX bring-up fallback only at design.md:14-16, and the delta’s body requirement says it SHALL NOT be the production path. Production body is enclosure-mounted CSI/GMSL into Thor NVENC (design.md:11-13).
• The P-iris turret is an encode mule at design.md:17-18. The shipped sat is RV1126B core in our case with barrel /i to Ethernet sidecar and UART 1D ToF on every sat (design.md:19-22). The delta says the turret SHALL NOT be the shipped class.

Against my take:

• Take 1 (body /i path) is answered at class level. The body class row in docs/SENSORS.md:39 is PL/LPL with /i or EF electronic, and docs/LENS.md:48 gives the transport: PL contacts or barrel port to UART/USB on Thor. Design.md points at that. Good enough for a classes-not-SKUs doc.
• Take 2 (clock) is answered structurally, not explicitly. Putting picture, /i, and ToF on one RV1126B module is exactly what makes a single timecode possible. That is the architectural reason the module beats the turret, and it is the strongest steelman for the amend.
• Take 6, 7, 9, 10 are already in the delta or the living spec. Nothing reopened.
• Take 5: design.md:11 keeps “CSI/GMSL” on the body. docs/CAMERAS.md:68 pins the body to CSI-2 and reserves GMSL for sats. I read the body GMSL as a flex-length hedge, not a deser card. Acceptable.

Notes for act and for add-datasheet-pack

These are the take items the design does not answer. None contradicts the living spec, so none is a send-back. They are what the next node must pin.

1. Sat lens control fork (take 4). Design.md says “motorized iris/focus” and “barrel /i” without choosing how the motors get there. Two honest shapes: cine /i glass plus external FIZ motors and a barrel-to-Ethernet bridge, or EF electronic glass on an EF electronic mount board with EF data mapped into /i fields. The first is a four-figure add per sat. The second means the RV1126B module needs a mount with contacts, which almost none have. add-datasheet-pack should shop with this fork named, or it will return a C-mount module that satisfies neither.
2. Sidecar clock source (take 2). Write it down: the sat module stamps /i and ToF with its own encoder timecode, PTP-disciplined, and Thor remuxes without restamping. Thor arrival time is only for the bridge-box case. One line in design.md or LENS.md closes this.
3. Sat module firmware is a change of its own (take 3). “RV1126B module + our case” with UART ToF forwarded over Ethernet is firmware we own. Proposal out-of-scope does not name it. Name the follow-on change-id at fold time so the fold does not leave the shipped sat as an unowned requirement.
4. Accepted tradeoff should be written (take 8). PoE H.265 sats give up RAW into ISP, cuVSLAM on sat pixels, and hardware genlock. docs/CAMERAS.md already carries the table. Design.md should say the trade is accepted so nobody reopens GMSL sats as a v1 fix later.
5. tasks.md hygiene. Line 5 is an unboxed note in a checklist. Harmless; fold will drop it.

Same-session author and reader: no. Author is grok-conductor, reader is this spawn.