Snap & Talk: a retake that hears nothing keeps the earlier words, the toolbar's Cancel asks first, and the notice never says 'Use Off'
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 18/100
Línea de trabajo
Start in ReadbackModel.swift: the stop path around lines 1036-1054 and process() around 1343-1364, plus the cancel path near 1063-1069 and shortcutLabel near 516. The issue depends on the unmerged #330 branch, which supplies the fake recorder for --check-readback, so confirm that branch is merged first. Done means each listed --check-readback case passes and the native microphone checks are confirmed by hand.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Outcome: a silent retake never hides a section's words. The toolbar never discards a long take without the page's question. The narration notice names a key only when that key works.
1. A retake that hears no words keeps the earlier words
- Problem:
- Stop's quiet screen catches only takes under 0.35 s or −55 dB (ReadbackModel.swift:1036-1039).
- Every other take first moves the section's audio, original text and edited text into history/ (:1044), unlinks both transcripts (:1051) and drops the draft (:1054).
- When transcription returns nothing,
process()throws (:1343) and saves.failedwith no text (:1362-1364). - The page then shows "Transcription stopped" with only Retry transcription (ReadbackView.swift:462-465). Retry re-runs the same silent audio (ReadbackModel.swift:1118-1124). Re-record is hidden in ⋯ (ReadbackView.swift:419), and the summary says "1 needs a retry" (:240-241).
- Nothing reads history/, so the notes or narration look gone.
- Meetings already decided that a recording which heard no speech is never offered for retry (docs/workbench.md:207).
- Change:
- Stop: archive only the previous audio and original. Keep narration.txt linked, and keep the draft.
process()with words: archive the still-linked edited text, then write the new files.process()with no words:- archive the silent WAV and clear
audio; - set
.readywith no failure when text is still linked; otherwise set.needsNarrationwith "No speech was heard. Record the narration again."; - set the notice to "No speech heard. The screenshot and any earlier narration were kept."
- archive the silent WAV and clear
- Real engine errors: keep
.failedand Retry, as today. - One sentence in docs/snap.md.
- Check:
--check-readbackwith ControlledTranscriber and #330's fake recorder:- imported notes, empty result:
.ready, notes intact, silent WAV in history/, no "retry" anywhere; - narrated section, empty result:
.ready, edited text kept; - fresh capture, empty result:
.ready; - nothing linked, empty result:
.needsNarration; - engine error:
.failed, earlier text still on disk; - words: new text, earlier text archived.
- Removing the no-words branch must fail the first four.
- imported notes, empty result:
2. The toolbar's Cancel narration asks as the page does
- Problem: while narrating, the chooser lists Stop narration and Cancel narration side by side (ToolbarActivityActions.swift:60-64).
- Cancel calls
cancelNarration()directly, which deletes the take (ReadbackModel.swift:1063-1069). A take can run 300 s (:1023). - The page asks "Discard this narration?" after 10 s (ReadbackView.swift:255-257, :128-131; docs/desktop.md:119).
- docs/workbench.md:118: every door gives the same result.
- Cancel calls
- Change:
- One rule in ReadbackModel shared by both doors:
cancelAsksFirst(elapsed:);- a published
pendingCancelNarrationholding the take's identity; requestCancelNarration();confirmCancelNarration(_:), which re-checks the identity.
- The question clears whenever recording ends, including the 300 s auto-stop.
- The page's existing dialog binds to it.
- The chooser calls
requestCancelNarration()and, when it asks, opens Snap & Talk with the page's dialog showing. - No NSAlert: it would block the narration timer.
- One rule in ReadbackModel shared by both doors:
- Check:
--check-readbackwith a check-only take fixture:- at 74 s it asks and keeps the file;
- Keep recording keeps the take running;
- Discard with the matching identity removes the file; a stale identity does nothing;
- at 5 s it discards at once;
- Stop and the auto-stop clear the question.
- The existing ToolbarActivityChooserTests pass.
3. The narration notice names a key only when it works
- Problem:
shortcutLabel(ReadbackModel.swift:516) returns "Off" when the shortcut is disabled (VoicePreferences.swift:26-27) and ignoresshortcutFailure(:453).- The notice reads "Narrating section 2. Use Off again to stop." (:1016).
- The help (ReadbackView.swift:276) and the options sheet (:580) say "Off captures the display…".
- The toolbar already filters both cases (FloatingToolbar.swift:371-375), and so does Dictate (AppModel.swift:612). #15 Slice B fixes Home and Dictate.
- Change:
usableShortcutLabel: nil when the shortcut is off or failed to register.static narrationNotice(section:shortcut:): without a usable key it ends "Use Stop narration to finish."- The help names the key only when it is usable.
- The options sheet shows the failure, or "No shortcut is set. Capture & narrate on the page still works."
- Check:
--check-readback:- the pure notice, with and without a key;
- shortcut disabled in a scratch defaults suite: nil;
- enabled: "⌥C";
- with a registration failure: nil.
Native checks owed (microphone)
- Re-record over a section with notes while the input is muted: the notes stay, and no Retry appears.
- Narrate past 10 s, then choose Cancel narration in the chooser: Snap & Talk opens with "Discard this narration?". Keep recording continues the take.
- With ⌥C off, choose Capture & narrate: the notice ends "Use Stop narration to finish."
Value before scope
- Outcome: no hidden words, no unasked loss of up to five minutes of narration, and no instruction to press "Off". Evidence: the traced paths.
- Simpler route: Stop's quiet-take rule, the page's own dialog, and the toolbar's existing shortcut filter.
- Owner: ReadbackModel.
- Complexity: no new control, label or setting.
- Verified by: --check-readback.
Grammar: Quality.
Sequencing: the #330 branch is ReadbackModel's only writer tonight. Build after it merges, reusing its fake recorder: item 1 first, then items 2-3.
Refs #134, Refs #15
Build-ready record from the overnight lead session of 15 Oct 2026 (round two), verified against main edc15df by an independent skeptic per item. Implementation follows on a claude/* branch; this issue closes only after native acceptance.
Build-ready record from the overnight lead session of 15 Oct 2026 (second discovery round), verified against main edc15df by an independent skeptic per item. This issue closes only after native acceptance.
- Lenguaje dominante
- Swift
- Estrellas
- 0
- Forks
- 1
- Merge medio
- 12 h 29 min
- PR fusionados (30 d)
- 201
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de Ship-Work/workbench
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
documentation good first issue help wanted
Dificultad 2/5 Medio día Aptitud para principiantes 74/100
Ship-Work/workbench#29 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Library: Quit asks before discarding an open resource editor, and Use with transcripts says the skill is chosenPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 22/100
Los mantenedores suelen responder en 1 día
-
Persona: Show with nothing to show says why, Remove group… asks first, and an unsaved layout survives leaving the pagePosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
Todos los issues de Ship-Work/workbench
Issues similares
-
builtin-port enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
cmlarsen/writemorebetter#235 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
callstack/agent-device#3627 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
maziyarpanahi/openmed#4207 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 60/100
meshtastic/Meshtastic-Apple#2603 ·
Los mantenedores suelen responder en 1 día
-
bug Windows
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100