History: redo a transcription, and save the recording it came from

[bojieli]

Retry only ever answered the words never arrived. The more common complaint is that
they arrived wrong — a name misheard, a provider that was the wrong one for the
accent — and that row is completed, which canRetry excludes by definition. The only
recovery was to say the whole thing again.

Two offers per history row, on all four clients:

	macOS	Windows	Android	iOS
Redo the transcription	circular arrow, replacing Retry on completed rows	row menu, renamed per row	own button under the row	circular arrow
Save the original audio	⬇ → save panel	row menu → save dialog	"Save audio" → document picker	⬇ → Files

Both are keyed to canRedo — the recording still being on disk — rather than to the
status. For a dictation that succeeded that means Keep audio was on when it was made,
so on most rows neither offer exists at all rather than sitting there disabled. Keep
audio's own description now says what keeping it buys beyond Retry, on all four.

Three decisions worth reviewing

A redo is not Retry renamed. Retry recovers words that never reached a cursor, so it
types them. A redo is read in the history: typing into whatever sits behind the settings
window, or replacing the clipboard on a phone, would be a surprise. It updates the row
and leaves Copy one button away. The shared request is the same call either way — only
the caller knows whether the text is owed to a cursor somewhere.

A redo drops the rewrite beside the transcript it replaced. deliveredText prefers
the styled version, so without this a redo of a rewritten dictation would replace the
words and still show the old ones — a button that appears to do nothing. Failed rows
never carry a rewrite, so Retry is unaffected. Covered by a test in the Swift suite.

Windows double-click stays retry-only. A completed row is not broken, a double-click
on one is as likely to be exploratory as intended, and every one of these spends a
request. The redo asks for itself from the row menu.

Layout

macOS, Windows and iOS give redo and Retry one control between them, since a row can
only ever want one of the two. Android puts the redo on a line of its own beneath the
row: a fourth control beside the transcript leaves the transcript too narrow to read,
which is the thing the row is for.

Mirrored four ways

canRedo and audioExportName are hand-ported to Swift, C# and Kotlin with the same
test in each of the three suites, per the usual rule for shared core logic. Saved files
are named donottype-20260828-143205.wav; on disk they are named for a UUID, which is
useless in a downloads folder. The format is fixed rather than cultural in all three — a
filename with a slash in it is not a filename.

Verification

Swift core	524 tests pass
C# core	471 tests pass, dotnet format --verify-no-changes clean
Android	JVM unit suite passes, gradlew lint clean
iOS	shared unit tests + both UI suites pass on the simulator
Builds	all four clients, including the WinForms app

New tests in all three core suites cover canRedo on kept versus discarded audio, the
export name, and the stale-rewrite drop.

Not done: the CLI is untouched — dnt history retry still only reaches failed rows.
The ask was the history UI on desktop and mobile, and the CLI is a separate surface. I
also did not drive the installed macOS app: killing the running copy would cost its
Accessibility grant on the next ad-hoc rebuild.

🤖 Generated with Claude Code

https://claude.ai/code/session_016jptSNBmsbgyPSf8FMpxpa