[widechaos]

Closes #2671. After transcription stops, generating Detailed Notes can still prefer the recording store’s leftover plain transcript over the saved transcript containing speaker edits. The same stale input also produces a different content hash, so the outdated indicator remains after regeneration.

Use the live transcript only while the matching meeting is still transcribing. Stopped meetings use the current saved transcript; active and finishing transcription keep their existing behavior.

I reproduced the failure through the real PersonalNotesView generation handler with synthetic transcript data and an intercepted action call. The stopped-meeting regression fails on the original source; 38 related tests pass with the patch. Tests cover saved names and hashes, active transcription, finishing transcription, and another meeting. Lint and type checking pass (six existing lint warnings); changed-file formatting passes.

The harness mocks note persistence and native IPC. I did not test real recording, live model output, or a packaged desktop build. PR #2587 already fixes speaker-label resolution; this fixes the stale input bypassing that formatter.

[Chadpiha]

Thanks for this @widechaos! Approving :)

I traced it end to end. The root cause is a bit broader than the description says:

• The meeting store’s transcript is always plain joined text: buildTranscriptText while recording, and main’s buildOrderedTranscriptText after stop. It is never segment JSON.
• recordingNoteId is never cleared after stop.

So after any stop, runNoteAction passed plain text to parseTranscriptSegments, which returned []. The prompt therefore had no speaker labels at all, not just stale ones, and isMeetingNote and knownPeople were empty. The hash was taken over that plain text while isEnhancementStale hashes the saved JSON, so they never matched and the dot stayed. A restart cleared the store, which is why that workaround worked. Your change fixes both symptoms.

I confirmed that every regenerate entry point (template picker, Generate AI Summary callout, action picker, chips, / menu) goes through runNoteAction. Note chat, chat actions and get_note already read the saved transcript.

I pushed one commit that tightens the new tests:

• dropped the “finishing meeting” case, since the store always sets isRecording and isTranscribing together
• added a speaker named only by a mapping, so the test proves mappings reach the summary input
• renamed the cases to say what they assert
• added a check that runAction was called before reading the call
• removed a duplicated assertion

A non-blocking note: the live-transcript branch you kept looks unreachable. Every action entry point is hidden while the open note is recording (canRunTemplate, offersActions in NoteEditor.tsx). If it ever did run, it would send the same unlabeled plain text. Always using activeNoteRawTranscript would be simpler, but that can be a follow-up.