add-camera-interconnect — re2 advise after Thor-in-the-loop amend

ADVISE: accept READER: fable-5-1-arch-review SPAWN: .spawns/add-camera-interconnect-1789036399-61019-f82dd407

Author this pass: Grok (commit da58dff). Prior reviews kept: Sol 2026-09-10-advise.md, Fable 2026-09-10-re-advise.md. This file does not overwrite either.

Blind take (written from the Why, the living spec, and the delta before opening design.md, tasks.md, or the plant docs)

1. Pin: remux runs in the record process, not the AI slice. Same watchdog, same priority, same storage path as body NVENC.
2. Pin: “no re-encode” is the hardware-buying clause. Sat cameras must emit a container-ready H.265 stream (RTSP/SRT) that Thor can depacketize without touching NVDEC.
3. Pin: sat container timestamps come from sat PTP, and that is the clock the /i JSONL keys to. The clock SHALL must cover it.
4. Pin: the Thor 5GbE jack is now in the record path (sat in), not only the AI path. Losing that link stops two of three masters.
5. Pin: the MGBE scenario must name T4000 = 3 and T5000 = 4.
6. Refuse: any Thor stage that decodes a sat before writing it. Decode is AI only.
7. Refuse: USB-C trunk. It belongs under the fabric requirement, not the clock one.
8. Tradeoff: one writer makes Thor a single point of failure for all three masters. The body has the NVMe ring; sats have nothing unless the sat records locally. Accept for bring-up; sat-local fallback is a camera-selection criterion, not this change.
9. Tradeoff: a sat master over live RTP has no retransmit; a dropped packet is a hole in the master forever. Acceptable only while remux is record-class and the switch is dedicated to the plant.
10. Open: does the sat stream ride the NVMe ring, or go remux → NAS direct? Wording, not hardware.

Comparison (after opening the delta diff, design.md, tasks.md, docs/INTERCONNECT.md, docs/STREAM-BUDGET.md)

Take	Delta after da58dff	Status
1 remux is record-class	“Remux is record, not AI.” Drop set is “AI decode or overlay” only	answered
2 no re-encode	“written to the NAS by Thor (remux, no re-encode)”	answered
3 sat PTS = sat PTP, JSONL keys to it	“Clock and sidecar alignment” unchanged; Thor is now the single writer of both HEVC and JSONL per camera, so 1:1 pairing is a file-system fact	answered
4 5GbE in the record path	not stated as such; follows from the plant	note, not a SHALL
5 MGBE 3 / 4	GIVEN says “three (T4000) or four (T5000 / AGX kit)”	answered
6 no decode before write	“remux, no re-encode” plus decode in the drop set	answered
7 USB-C under fabric	moved to “Hybrid camera fabric”	answered
8 Thor SPOF for sat masters	not stated	note, camera-kit scope
9 RTP loss = master hole	not stated	note, camera-kit scope
10 ring vs direct	“HEVC recording, the NVMe ring, satellite remux to storage” lists them side by side	wording only

The one clause asked for on 2026-09-10-re-advise.md is present in both places recommended: the storage path in “HEVC record path” and the drop set in “Record-first under AI drop”. The thermal-sag scenario now names “sat remux to the NAS” as a thing that keeps writing. The invariant in the packet anchor holds verbatim.

Steelman against my own take

The strongest argument that this still needs a send-back is take 8 and 9: Thor-in-the-loop moves the sat master’s integrity onto the PoE link and Thor’s uptime, and the delta says nothing about a sat-local fallback or loss handling. If the living spec is the only thing a buyer reads, they could buy a sat with no on-camera record and be surprised the first time the 5GbE link flaps.

That does not survive the Why. The Why is “the wrong fabric buys the wrong cameras”. Thor-in-the-loop buys the same satellite either way: a PoE camera that emits H.265 with PTP timestamps. Whether that camera also records to SD is a sat SKU criterion, and sat SKUs are explicitly out of scope here (add-sensor-lens-kit). The fabric decision does not change with or without the fallback. So it is a note for the sensor-kit change, not a defect in this delta.

Take 4 (5GbE now in the record path) is real but is a consequence of the chosen path, not a missing requirement. Record-first already says sat remux SHALL continue; a link that cannot carry it is a plant failure the switch requirement already scopes (“uplink sized for the HEVC payload plus overhead”).

Notes (not gating)

• Docs lag the SHALL. docs/INTERCONNECT.md decision table says “Sats = camera H.265” and the plant draws “Thor remux / NVDEC” as one box; docs/STREAM-BUDGET.md:77 says “satellite masters from camera H.265 (or Thor remux)“. The delta now says Thor remux SHALL write the sat master. Strike the “or” in both docs so a reader of the docs and a reader of the spec buy the same plant. Added as an unchecked task below; it is docs, not spec, so it does not block fold.
• Sat-local fallback (takes 8, 9) should appear as a sat-SKU criterion in add-sensor-lens-kit: “sat MAY record locally; if it does, local file timecode SHALL match the PTP timestamps Thor remuxes”. Not this change.
• Ring vs direct (take 10): “the NVMe ring, satellite remux to storage” reads as two paths. If sats also land in the ring, one word (“via the NVMe ring”) would close it. Wording only; no hardware changes either way.
• Carried from re-advise, still non-gating: sat master quality is bounded by the sat encoder (RV1126B class), and NVDEC on T4000 fits two sat proxies, not six. Both are doc sentences, not SHALLs.

Verdict rationale

Accept. The prior send-back was one clause and it is answered in full, in the places recommended, with the scenario updated to match. Hybrid fabric, HEVC-not-RAW, sat-side encode on T4000, PoE boundary, independent MGBE lanes, clock at capability level, and record-first with remux on the record side are all normative and mutually consistent. Nothing in the delta buys the wrong camera, switch, or QSFP part. The remaining items are documentation alignment and a criterion for a different change.