The arm transition goes quiet — preview must announce the gap, not vanish into it

[liversedge]

From PinPointStudio's preview handover, 28 August 2026, §4.4 — the half of #108 that its exit criterion did not cover, split out so it is not lost when #108 closes.

What is unknown

Preview at connect works (2f604b1, confirmed on device). The arm transition is untouched and nobody has watched it.

CORE 5.11k makes preview alone an independent mode and preview alongside a capture Stream a derived view — so arming while preview is running is a camera reconfiguration, not a Stream change. That is where the measured 8.85 s warm-up and #101's format stall live.

What is being asked for, and what is not

⚠ Not that it be instant. They are explicit about this. Reconfiguring the sensor takes what it takes.

⛔ That it be visible. 5.11c/I36 oblige us to account for the whole interval from opened_at onward, and that obligation does not pause because the camera is busy:

• Announce the gap as an absent segment (5.11c3), with a reason — not silence.
• Report readiness across the transition, so the host can say "reconfiguring" rather than "the picture stopped".
• Come back afterwards without the operator touching anything.

Exit criterion

On hardware: connect, see preview, press Capture. The host either keeps its picture, or is told in an absent segment that the interval was not retained and why — and preview returns on its own when the camera settles. Nothing goes quiet.

[liversedge]

Somebody has watched it now — preview survives the arm, and the ring does not notice

The device suite arms mid-test with preview running and reads the counters on both sides of it (make test-device, iPhone 16, against a live PinPointStudio, 2 September 2026):

DEVICE-RUN preview channel=true stream=st:cf05c06298c9af75:preview segments=554
DEVICE-RUN with preview: frames 5734 maxInterArrival 4 ms
DEVICE-RUN preview across the arm: segments=734
DEVICE-RUN second arm: frames 1260 maxInterArrival 4 ms

• ✅ Preview does not stop when capture starts. 554 segments announced before the arm, 734 after it — 5.11k makes preview alongside a capture Stream a derived view, not an exit, and it behaves as one.
• ✅ It costs the ring nothing. Max inter-arrival 4 ms with preview running, at a 4.17 ms frame period.
• ✅ It comes back with nobody touching anything, across a disarm and a second arm, with no recording error — the case that used to fail with invalid argument when a link peer outlived the recording session.
• ✅ The picture is live at connect with nothing armed, which is #108's half, re-confirmed on every hosted row.

⛔ Not closing — the half this issue is actually about is untested

The exit criterion is "the host either keeps its picture, or is told in an absent segment that the interval was not retained and why". This run is the first branch: the picture was kept, so the second branch never fired and nothing here says it works. What is still unproven:

An absent segment across a reconfiguration that does drop frames, with a reason (5.11c3)	⛔ never observed
readiness reported across the transition, so the host can say "reconfiguring"	⛔ not asserted anywhere

⚠ And this run is a weak instance of the case. #101's eight-second format stall is what makes the transition interesting; arm() here reported armed immediately and preview never had a gap to announce. The interesting run is a cold arm that changes format under a running preview — a phone that has not just been through five other hosted tests.

⚠ Worth pairing with #116 when it is taken: both want a Stream held open across an event, and neither conformance suite asserts one.