[jeremybarnum]

The LoopKit part of Sport Mode, where the watch borrows the pod from the phone and runs Loop itself. It replaces #612, from my fork so you can push edits. Nothing changes for a pump or CGM that doesn't opt in.

What's in it — attempts to create the protocols and make things more generic:

• Hand-off protocols (replacing Sport Mode, part 1/5: LoopKit — glucose zombie guards, PumpConnectionLendable, mirror-store carb entries #612's PumpConnectionLendable). One lets a device give another controller what it needs (exportConfiguration(), init(adopting:localState:), and localState: what the device learned that belongs to this controller only, such as its Bluetooth handle, which the host keeps and hands back at the next adopt). One lets a device that allows a single controller be released and taken (releaseControl(), takeControl(), readiness). One reports a pump's delivered total, which both sides audit against, as well as its pulse size. None of them mentions a phone or a watch.
• A fault description from the device (localizedInoperableDescription, defaulted to nil), so the app can show device faults in a device agnostic way.
• The watch now keeps its own dosing decisions; see the Loop PR.

Worth a look:

• Leverages CarbStore: carry the sync identifier on new carb entries #654 for editable carb entries.
• The new protocols are new public API; a few members go beyond the minimum, to keep the app's "keep your wrist up" and "turn Bluetooth off and on" hints without naming a device.

This comes before OmnipodKit, G7SensorKit and Loop PRs which use these protocols.

[ps2]

I'd like to land a smaller ExclusiveDeviceControl, since it becomes public API we keep. I went through how LoopKit/Loop#2545 and loopandlearn/OmnipodKit#177 use each member. I think this covers everything they do today:

public protocol ExclusiveDeviceControl: DeviceConfigurationSharing, DeviceManager {
    /// Persisted, so a relaunch doesn't take control back.
    var isControlReleased: Bool { get }
    func releaseControl()

    /// Connect, and keep reacquiring however the kit sees fit until ready or released.
    func takeControl()

    /// Link up and the device answered; changes reported via
    /// DeviceManagerDelegate.deviceManagerControlDidBecomeReady(_:).
    var isControlReady: Bool { get }

    /// Whether taking control with this export and local state means finding the
    /// device first (the host may need to keep its screen or radio awake).
    static func takeControlNeedsSearch(adopting configuration: SharedDeviceConfiguration,
                                       localState: [String: Any]?) -> Bool

    /// The last take failed in a way only resetting the host's radio fixes. Default false.
    var hostRadioNeedsReset: Bool { get }
}

What changes from the current version:

1. lastForeignSessionAt: drop it. Only the test mock in Loop implements it, and nothing reads it.
2. connectionDiagnostics(): drop it. The kit can write that text to the device log itself through DeviceManagerDelegate, as OmnipodKit already does elsewhere. It then shows up in the device log alongside the handback entries instead of inside them.
3. escalateTakeControl() / endTakeEscalation(): fold them into takeControl(). OmnipodKit would switch to scanning by address on its own when the link hasn't come up after its own wait, and stop once control is ready or released. When and how to rescan is device-specific Bluetooth behavior, so it fits in the kit. It also means a host can't leave an escalation running by forgetting to end it. Loop's reclaimEscalateAfter would become a constant in OmnipodKit.
4. takeControlNeedsSearch: keep only the static version. After adopting, the host still has the same export and localState, so it can ask the static one. The firstContact check in the watch's takeover would use it too. OmnipodKit's instance check can stay internal for its own takeControl().
5. hostRadioNeedsReset: keep it for the "Turn watch Bluetooth off and on" hint. Alternatively, the kit could issue that as a device alert and drop the member. I'm fine either way.

As far as I can tell, none of the loan, settle or audit logic changes. DeviceConfigurationSharing and PumpDeliveryOdometer stay as they are. Does that work for you, or is there something one of these members does that I've missed?

Separately, could you update the description? It still lists the carb store additions, but #654 has replaced those, and the glucose guards were dropped.

[jeremybarnum]

Description updated. Your proposal works as far as I'm concerned and can tell. Changes pushed.

[jeremybarnum]

Regarding hostRadioNeedsReset there wasn't enough evidence that the solution was needed for the problem - it was legacy from before directAuth. So I just got rid of it.