Recorder Re-transcribe stays disabled for lazily unloaded Parakeet after restart

[SeoFood]

Platform

macOS

Description

On v1.6.0-daily.20260729, selecting Parakeet TDT v3 as the Recorder engine leaves Re-transcribe disabled after relaunch when the Parakeet model is persisted but lazily unloaded.

Opening Settings > Integrations > Parakeet and manually reloading the model immediately enables Recorder retranscription. The problem returns after restarting TypeWhisper. Apple Speech and Canary are not affected in the reported setup.

The reporter first confirmed that direct Recorder retranscription itself works correctly on the Daily build, then isolated this separate Parakeet restore issue.

Steps to Reproduce

1. Download and load the Parakeet TDT v3 model.
2. Use an active model auto-unload policy. The reported setup uses 10 minutes.
3. Select Parakeet as the transcription engine in Recorder.
4. Restart TypeWhisper.
5. Open Recorder with an existing recording.
6. Select Parakeet, or switch the Recorder engine from Apple Speech or Canary to Parakeet.
7. Observe that Re-transcribe is disabled.
8. Open Settings > Integrations > Parakeet and reload Parakeet TDT v3.
9. Return to Recorder and observe that Re-transcribe is enabled and works.

Expected Behavior

Recorder should allow retranscription when the selected Parakeet model is already downloaded and can be restored lazily. Clicking Re-transcribe should restore the selected model on demand and continue with transcription.

Actual Behavior

Recorder requires Parakeet to be loaded before enabling Re-transcribe, so the user cannot initiate the operation that would normally restore the model. A manual reload from the plugin settings is required after every app restart.

Likely Root Cause

AudioRecorderViewModel.canTranscribeRecording(_:) calls ModelManagerService.canPrepareForTranscription(_:).

For non-Apple engines, canPrepareForTranscription(_:) currently returns true only when engine.isConfigured is already true. With an active auto-unload policy, Parakeet intentionally starts lazily unloaded. The button is therefore disabled before ModelManagerService.transcribe(...) can reach its existing triggerRestoreModel(...) path.

Suggested Fix

Allow Recorder retranscription for an available local engine whose selected model can be restored, even when the runtime model is not currently loaded. Trigger the existing lazy restore path after the user starts retranscription.

Add regression coverage for:

• Parakeet selected and downloaded but unloaded after relaunch
• Re-transcribe remaining available in that state
• Lazy restore followed by successful retranscription
• Missing or deleted model state still producing an actionable error

Diagnostic Context

• TypeWhisper: v1.6.0-daily.20260729
• Parakeet plugin: 1.3.0
• Selected model: parakeet-tdt-0.6b-v3
• Auto-unload policy: after 600 seconds

[Dbhardwaj99]

I'd like to take this one.

The diagnosis matches what I see. canPrepareForTranscription (ModelManagerService.swift)
returns early on isConfigured, then grants the catalog grace only to Apple Speech:

guard engine.providerId == AppleSpeechModelSelection.providerId else { return false }

So an auto-unloaded Parakeet fails, and canTranscribeRecording
(AudioRecorderViewModel.swift:817) disables the button before transcribe() can reach the
triggerRestoreModel branch.

What stood out is that the dictation path doesn't have this problem, and not by accident —
canTranscribe checks only canUseForTranscription, with a comment saying readiness
is handled downstream in transcribe(). Recorder is just the stricter of two gates.

There's also already a predicate for this exact state:
DictationViewModel.engineIsReadyOrRestorableForPreview is
isConfigured || hasPersistedRestorableModel || canPrepare, backed by
hasPersistedRestorableModel reading plugin.<id>.loadedModel — the same default
ParakeetPlugin.restoreLoadedModel() reads. It went in for the same bug class on #943.

So I'd reuse that rather than add a second Parakeet-shaped special case, and let the existing
restore path do the work. That keeps manual unloads correctly disabled, since those clear
loadedModel — which LivePreviewEngineResolutionTests already asserts. Tests would go in
AudioRecorderViewModelTests covering the four states listed, including deleted-model still
surfacing an actionable error.

One call I'd like from you first: widen the non-Apple branch of canPrepareForTranscription
itself, or have Recorder call a shared ready-or-restorable helper and leave that function
alone? The second is a smaller blast radius but leaves two predicates around. Are there other
callers you wouldn't want loosened?