From PinPointStudio's preview handover, 28 August 2026, §4.6 — filed as their words have it: "a product question, not a bug". It needs a decision before it needs code.
What the device can actually do
This handset has one AVCaptureSession. CORE 5.6d gives each lens its own Source, and PinPointStudio asks about every camera Source at declare — but only one of them can be previewing at any moment, because only one camera is running.
Until 2f604b1, AppModel.livePreview was a single slot and the second request stopped the first. src:camera:wide is asked for first, so wide — the lens an operator actually watches — was destroyed milliseconds after being created, and both Sources were acked opened. A Source that is not the running camera is now refused with a reason, which is legitimate under E18 clause 1c and which Studio handles.
⛔ The lens is never switched to satisfy a preview request. Lens.captureRank makes a lens change calibration-affecting, and changing it mid-session is currently forbidden.
The question
If an operator wants to frame with the ultra-wide, the only way to show it to them is to switch the active lens — which is calibration-affecting.
- Leave it as it is. Preview follows the capture lens. Framing on a different lens is not offered, and the host's request is refused with a reason. Costs nothing; an operator who wants the ultra-wide's field of view cannot see it before committing to it.
- Allow a lens switch for framing, before arming only. Preview follows whichever lens is asked for while the session is unarmed; arming pins it and any calibration is re-taken or invalidated. Needs a rule for what happens to calibration, and a reason it cannot happen mid-session.
- Something narrower — e.g. the host may name a preferred preview Source at
declare, chosen once, before anything is calibrated.
⚠ Whichever it is, 5.6d still lets Studio ask about every Source, so the refusal path stays regardless. This decides only whether a request can ever cause a switch.
Exit criterion
An answer recorded here, and if it is anything but the first option, an issue against E3 with the calibration rule written down.
From PinPointStudio's preview handover, 28 August 2026, §4.6 — filed as their words have it: "a product question, not a bug". It needs a decision before it needs code.
What the device can actually do
This handset has one
AVCaptureSession.CORE5.6d gives each lens its own Source, and PinPointStudio asks about every camera Source atdeclare— but only one of them can be previewing at any moment, because only one camera is running.Until
2f604b1,AppModel.livePreviewwas a single slot and the second request stopped the first.src:camera:wideis asked for first, so wide — the lens an operator actually watches — was destroyed milliseconds after being created, and both Sources were ackedopened. A Source that is not the running camera is now refused with a reason, which is legitimate under E18 clause 1c and which Studio handles.⛔ The lens is never switched to satisfy a preview request.
Lens.captureRankmakes a lens change calibration-affecting, and changing it mid-session is currently forbidden.The question
If an operator wants to frame with the ultra-wide, the only way to show it to them is to switch the active lens — which is calibration-affecting.
declare, chosen once, before anything is calibrated.⚠ Whichever it is,
5.6dstill lets Studio ask about every Source, so the refusal path stays regardless. This decides only whether a request can ever cause a switch.Exit criterion
An answer recorded here, and if it is anything but the first option, an issue against E3 with the calibration rule written down.