fix(mobile,docs): drop the pointless retry on a wire skew and stop exempting desktop from the advisory

Author: Zerlight

apps/mobile/src/components/host/host-connection-state.tsx

@@ -61,13 +61,20 @@ export function HostConnectionState({
               <Text modifiers={[TITLE, CENTERED]}>{title}</Text>
               <Text modifiers={[SECONDARY, CENTERED, textSelection(true)]}>{body}</Text>
             </VStack>
-            <Button
-              label={t('retry')}
-              systemImage="arrow.clockwise"
-              modifiers={[buttonStyle('borderedProminent')]}
-              onPress={onRetry}
-            />
-            {failure ? (
+            {/* An app below the host's floor has nothing to retry: redialing only flashes
+                "connecting" and lands back here. Updating the host is a real action, so that
+                skew keeps the button. */}
+            {wireRemedy === 'update-app' ? null : (
+              <Button
+                label={t('retry')}
+                systemImage="arrow.clockwise"
+                modifiers={[buttonStyle('borderedProminent')]}
+                onPress={onRetry}
+              />
+            )}
+            {/* The technical line distinguishes causes on an ordinary failure; under a named skew
+                it only repeats the copy above in triage voice. */}
+            {failure && wireRemedy === undefined ? (
               <Text modifiers={[FOOTNOTE, SECONDARY, CENTERED, textSelection(true)]}>
                 {failure}
               </Text>

docs/ARCHITECTURE.md

@@ -332,10 +332,12 @@ host reads the older pong and reports that the host must update. The tunnel need
 wire-version surface of its own (it versions only its subprotocol and peer frames) — the relay
 carries `WireMessage` frames opaquely and the pong returns on the same peer connection. Moving
 `MIN_COMPATIBLE_WIRE_VERSION` waits until the clients it will refuse can render that advisory:
-at least two shipped mobile releases carrying the update-required screen. The handshake exchange
-itself has been in clients since wire v64 (2026-07-31, first released in v0.13.0), but those
-builds only surface the technical message after their retry budget — the procedure is in
-`docs/RELEASE.md`.
+at least two shipped mobile releases carrying the update-required screen, and a desktop release
+carrying it too — desktop's bundled daemon is lockstep with its renderer, but that renderer also
+dials a daemon it did not ship (a `runtime.json` advertisement, or the Developer-tab override).
+The handshake exchange itself has been in clients since wire v64 (2026-07-31, first released in
+v0.13.0), but those builds only surface the technical message after their retry budget — the
+procedure is in `docs/RELEASE.md`.
 
 Who receives a host frame is declared in `wire/delivery.ts`, not decided in the transport: a
 correlated reply follows its `replyTo` to the connection that asked, and everything else fans out

docs/RELEASE.md

@@ -36,7 +36,8 @@ How to cut, sign, notarize, and publish the Electron desktop app, plus the packa
 
 A release that bumps `MIN_COMPATIBLE_WIRE_VERSION` (root `AGENTS.md`, Invariant 1) refuses every client below it, so it ships only once those clients can say so themselves:
 
-- The below-floor handshake advisory (`ping`/`pong` accepted at any version; the client renders an update-required state from the pong's `minCompatible`) must be in at least **two shipped mobile releases** before the floor moves — count from the first store build that contains the update screen, not from the handshake exchange itself (in clients since wire v64, 2026-07-31, first released in v0.13.0: those builds only show the technical message after their retry budget). Desktop ships lockstep with its daemon and needs no window; the webview deploys on its own schedule with no store lag, so it needs none either.
+- The below-floor handshake advisory (`ping`/`pong` accepted at any version; the client renders an update-required state from the pong's `minCompatible`) must be in at least **two shipped mobile releases** before the floor moves — count from the first store build that contains the update screen, not from the handshake exchange itself (in clients since wire v64, 2026-07-31, first released in v0.13.0: those builds only show the technical message after their retry budget).
+- **Desktop is not exempt, only unbounded.** Its bundled daemon is lockstep with its own renderer, but the renderer does not always dial that daemon: `resolveDaemonUrl()` prefers the Developer-tab `daemonUrl` override, then any daemon already advertising itself in `runtime.json` — and the supervisor deliberately stands down when another install's daemon already serves the machine. So a pre-advisory desktop build does meet a newer daemon, and the advisory must have shipped in a desktop release before the floor moves. Auto-update adoption bounds that wait; there is no store-review count to hold it to, so the trigger is a judgement call rather than a number. The webview has no store lag, but a cached bundle or a long-lived tab can be just as old and is covered by the same rule.
 - Bump `WIRE_PROTOCOL_VERSION` and `MIN_COMPATIBLE_WIRE_VERSION` in the same commit, retire the frames and fields the floor makes unreachable, and delete the client's `peerWireVersion` gates that can no longer be false.
 - Before tagging, check both rendered states by hand: an older client build against the new daemon shows the update-app state, and the new client against an older daemon the update-host state. The transport and client-core tests cover the mechanics; the release check is the screen.