# The phone is a paired peripheral of a Gateway endpoint, never a subnet member

The Android app needed a subnet identity. We ruled: the phone is a **paired peripheral** of a host-side Gateway endpoint (spt-core's ratified Gateway type — human-backed, `user-msg` authority), following the lecturn precedent. One Mobile Gateway endpoint exists per user, with an instance per paired host; the phone pairs with each host binary directly and never holds the subnet seed, never appears in the registry, never speaks the daemon P2P protocol.

## Considered options

- **Full spt-core node on the phone** — rejected for v1: no ARM/Android build target exists (xtask panics on non-x86_64), the elevation seam has no Android arm, Android doze kills always-on daemons, and it *still* wouldn't deliver remote digests (cross-node digest is unbuilt in spt-core regardless of where the client runs).
- **Subnet member with a client-class protocol** — rejected: requires a new daemon ALPN + registry/trust semantics in spt-core, contradicting the build-independently constraint, and reopens the "is it a node?" question lecturn already resolved as NO.
- **Paired peripheral (chosen)** — zero spt-core changes; the phone↔host protocol is spt-mobile's private contract.

## Consequences

- Hybrid path stays open by design: the device-link verbs are daemon-shaped (list / digest / send / history), so a future on-phone node (once Android is an spt-core build target) replaces the transport, not the app logic.
- The phone is dark only when NO paired host is reachable — multi-host pairing with user-ordered priority is v1 scope precisely to blunt this.
- Everything the phone does lands on the subnet with the user's authority (`user-msg`), which is exactly the Gateway contract.