E3.3 — Under host control

[liversedge]

Epic: E3 — The live host link in the app
Release: v1 · Layer: Core

The host arms the device; the device reports readiness, never a state name.

Components

• Arm/disarm from the host — ✅ composed 5dfb47c, reaching AppModel through a delegate
• Readiness measurement on the wire — ✅ composed, returned from the arm call rather than published later (MSG 5.2a)
• Keepalive lapse → cold — ✅ built. AppModel.hostLinkDidLoseLink (AppModel.swift:1357). ⚠ Scoped to warm → cold per REQ-STATE-3, and it deliberately does not go cold under an open preview Stream: that would stop the camera and nothing would restart it, since 5.11.2 gives the host no reason to ask twice
• ⛔ The two halves have never met. Ours built 27 Aug, PinPointStudio's built 27 Aug — test 4 of hardware-run-2026-08-27.md

Exit criterion

The host arms the device; RT-10's message half closes.

Requirements

REQ-STATE-1, REQ-STATE-3

---

_{Scope: delivery-scope.md · Requirements: traceability.md · PRD: capture-companion-requirements.md · Conformance: ppcp-conformance.md}

[liversedge]

Arm and disarm from the host are composed — 5dfb47c

HostLinkSession.handle's default: arm no longer drops arm/disarm. They reach AppModel through a delegate, and the answer to arm is a readiness measurement returned from the call rather than published later — MSG 5.2a, and the reason a delegate was chosen over an AsyncStream.

What closed that was not in the component list, and should have been. arm() had four exits and three returned silently, so on the paths that fail — permission refused, no usable mode, a ring that will not start — a host held the settled: false it got in reply and waited for a settled that never came. Every exit now reports, with CORE 5.15's four blocked_reason values, ordered permission → hardware → storage → heat. Raised by PinPointStudio before we hit it.

Keepalive lapse → cold is wired to .linkLost, scoped to warm → cold only: 7.4d and HostLinkDriver's own header forbid a lapse costing a captured frame, so armed is never dropped this way.

⛔ Not closing. The exit criterion is the host arms the device and no host has. That needs make conform SCENARIO=reference-host ROW=e33 driving the real AppModel path — the row does not exist yet. This target cannot test for a missing call site, which is exactly what this level is made of.

⚠ Two gaps found and deliberately left, both recorded at their call sites: a locally-disarmed device cannot tell a host it stopped (Readiness has no terminal negative), and the settle timeout reports no_source, which is the nearest of the four and a stretch.

[liversedge]

A readiness obligation arrives from preview — #112

Preview now runs from connect (2f604b1), which puts a second demand on this level's readiness reporting: CORE 5.11k makes preview alone an independent camera mode and preview alongside a capture Stream a derived view, so arming while preview is running is a camera reconfiguration — the measured 8.85 s warm-up and #101's format stall.

⚠ PinPointStudio are not asking for it to be instant. They are asking that readiness be reported across the transition, and that if preview drops while the camera reconfigures, the interval is announced as an absent segment (5.11c3) rather than going silent.

Tracked separately in #112 because it is not part of this level's exit criterion — RT-10's message half — which is unchanged. The component list here is also unchanged: keepalive lapse → cold is still not built.

[liversedge]

✅ The two halves have met — a host armed this device, 2 September 2026

The component list's last line read "the two halves have never met". They have. make test-device against a live PinPointStudio, iPhone 16, over Wi-Fi:

DEVICE-RUN session=sess:cc9fe9bf-… ref=tb:host
DEVICE-RUN clock agreement before arming: ± 1.31 ms (gate 5.0 ms)
DEVICE-RUN armed by the host after 0 s (state armed, torch commanded: true)
DEVICE-RUN torch after arming: TorchState(on: true, modeIsOn: true)

The device test no longer arms itself: it waits for the host's arm, and asserts what the device did afterwards. Four separate hosted rows in that run each reached armed through the host.

What landed with it — be030e8, 18197d1

• The torch is a CR-02 Actuator. Declared control: on_off, actuator_command answered, and ⛔ the ack carries the achieved state rather than the request — setTorch writes torchMode and reads isTorchActive back, and TorchOutcome.applied is unconstructible without that reading. actuator_state is now the autonomous path only, because the ack carries the value itself and a post-command emission would be the confirmation 12.2a forbids.
• ⛔ A defect the library's change exposed: ppcp_event.status was never surfaced in the Swift stack, so the delegate ran for commands the engine had already refused (12.1a/12.1d/12a) — a non-host peer's command would have physically lit the torch on its way to being told it was not allowed. Status is now carried through as engineAnswered and the handler returns before touching hardware.
• device_status per Source and buffer_status for the shot-windowed ring, and the health tick now starts at warmUp rather than arm — CR-02 4a named the gap as "nothing is reported before arm", and emitting only while armed would have rebuilt it.
• A host's disarm leaves the camera warm. Preview and the torch persist between buckets; arm() is idempotent on an armed or settling device; the Capture button gives way to "<host> controls capture" while a host is linked.
• ⚠ The ack under-reported and now does not. isTorchActive lags the mode by hundreds of milliseconds and does not move while the main thread blocks, so the delegate re-reads after 700 ms and answers with the current observation. Measured: torch ack on=true after 700 ms, against an earlier run where the ack carried a stale off after the on.

⛔ Not closing, and the reason is the criterion's own wording

The exit criterion reads "The host arms the device; RT-10's message half closes." The first clause is met. The second cites a row that is about something else — RT-10 in ppcp-conformance.md is "session_resume refused without a completed handshake", which has no bearing on arm — so this looks like a mis-citation carried in from the generator rather than a real obligation.

⚠ Proposed correction, for whoever takes this next: this level's remaining obligation is the on-device conformance run — the interop row that "answers arm with a Readiness measurement (5.15a — never a state name)" — driven on the phone rather than from the simulator. Leaving the issue open on that rather than closing it against a criterion that does not read.

⚠ The two gaps recorded on 27 August are unchanged: a locally-disarmed device still cannot tell a host it stopped (Readiness has no terminal negative), and the settle timeout still reports no_source, which is the nearest of the four blocked_reason values and a stretch.