One chip, three modes: Dictate, Rewrite, Translate on the phones

[bojieli]

What this changes

The phones' mode control was a two-state Dictate/Rewrite toggle. A target
language set in Settings silently overrode it, so the chip could read Rewrite
over a dictation that came back translated, and switching between them meant
leaving the text field, opening the app, and coming back.

It is now one three-way picker: a menu on each keyboard, three segments on each
app's own screen. TranscriptMode already had exactly these three cases;
LiveMode names them for what the user is choosing, with a single resolver from
mode to stage, so "both at once" is unconstructible rather than merely avoided.

The target language stays in Settings, and the picker does not offer a language
list. A keyboard cannot type into its own popup, so a list there would be a fixed
handful quietly disagreeing with the free-text target the app already stores —
and the popup's job is to answer one question.

Modes that cannot run

They are offered and disabled with the sentence saying why, which is what this
project already does for an unavailable rewrite. Rewriting and translating need
the same thing — a backend that takes text and gives text back — so they share
one rule and differ only in the noun: SecondStageJob. Telling someone their
backend "cannot rewrite text" when they asked for a translation sends them to fix
the wrong setting. The rewrite sentences are byte-identical to what they were,
so the existing parity assertions still mean what they meant.

Translate with no language configured is the state the old toggle could not
represent at all. It gets its own case and its own sentence.

On iOS the extension cannot read the app's Keychain, so it could never say why a
rewrite would not run — it just offered it. The app now publishes which case the
shared rule landed on and the keyboard rebuilds the sentence from it, so the
wording still lives in exactly one place.

The desktops are unchanged

macOS and Windows pick the operation by which key is held, so a persistent chip
would be a second answer to a question the keyboard has already answered. There a
target language still replaces what the second key produces, and the settings
window still says so — now through RewriteAvailability.forSecondKey rather than
through resolve, which the phones use.

Migration

Both phones read the old settings: a target language means Translate, a rewrite
style means Rewrite, anything else is Dictate. That is what an older build
actually did with those two settings. The settings-transfer document keeps its
shape, so a file written here still opens in an older client.

Verified

• Swift 593 tests, Kotlin unit tests, C# 619 tests — all pass.
• Android instrumentation on the emulator: the three segments exist, Translate is
  refused with no language set, and choosing a mode that cannot run does not
  become the stored one.
• iOS shared tests (32) including the new bridge cases, and the mode UI test on
  the simulator.
• On the Pixel: the menu opens over the keyboard with Translate greyed out;
  choosing Rewrite stores liveMode=rewrite and repaints the chip; the app screen
  shows three segments. Installed and left on Dictate.
• On the iPhone: built and installed for the device.

🤖 Generated with Claude Code

https://claude.ai/code/session_0199EDkXZ1NZzx1dk9KYTpmG