M1-10: Finalization and crash recovery #10

Closed
opened 2026-08-06 10:53:42 -04:00 by agent · 0 comments
Member

On stop, turn the in-flight state into the two artifacts of record, and recover
cleanly when the app died before it could.

The output contract

Every completed capture is exactly two files:

2026-08-06-090139-tjgcaz_audio.m4a
2026-08-06-090139-tjgcaz_transcription.vtt

Wes: "I want the output to be a VTT file and the audio file."

On stop

  1. Finalize the audio file (issue 05).
  2. Assemble .parts/*.vtt into the single transcript — strip the WEBVTT header from parts
    2..n and concatenate. Absolute timestamps mean nothing needs recomputing.
  3. Delete the parts folder.

The phone assembles, not the sync tool

Considered having the sync tool concatenate, which would avoid re-sending data. Rejected: a
45-minute transcript is roughly 30 KB, so the duplicate transfer costs nothing, while
assembling on the device means one assembler in one place rather than the same logic
reimplemented in every client. This is the reliability-over-cleverness call, and it is the
kind of duplication that produced v2's byte-identical-copy-paste problem.

Crash recovery

On launch, find any .parts/ folder with no corresponding final transcript and finish the
job: assemble what exists, pair it with whatever audio survived, and surface the memo. A
recording interrupted by a crash must still appear in the list as a usable memo
, not vanish
and not appear as a corrupt entry.

Done when

  • A normal stop produces exactly two files and no leftover parts folder.
  • Force-quitting mid-recording and relaunching produces a usable memo from what survived.

Milestone 1 of the Stash v3 rebuild, scoped 2026-08-06. M1 is a functioning iOS app on Wes's
phone with no sync at all — the entire goal is recording voice memos reliably and getting
them off the device by hand. Sync arrives in M3.

Working agreement for every issue in this repo: feature branch, tested before the PR opens
(on-device where the label says so), then Wes reviews the PR and we walk the code together.
Docs update in the same commit. A PR that takes more than 20 minutes to review is too big —
say so and split it.

On stop, turn the in-flight state into the two artifacts of record, and recover cleanly when the app died before it could. ## The output contract Every completed capture is exactly two files: ``` 2026-08-06-090139-tjgcaz_audio.m4a 2026-08-06-090139-tjgcaz_transcription.vtt ``` Wes: *"I want the output to be a VTT file and the audio file."* ## On stop 1. Finalize the audio file (issue 05). 2. Assemble `.parts/*.vtt` into the single transcript — strip the `WEBVTT` header from parts 2..n and concatenate. Absolute timestamps mean nothing needs recomputing. 3. Delete the parts folder. ## The phone assembles, not the sync tool Considered having the sync tool concatenate, which would avoid re-sending data. Rejected: a 45-minute transcript is roughly 30 KB, so the duplicate transfer costs nothing, while assembling on the device means **one assembler in one place** rather than the same logic reimplemented in every client. This is the reliability-over-cleverness call, and it is the kind of duplication that produced v2's byte-identical-copy-paste problem. ## Crash recovery On launch, find any `.parts/` folder with no corresponding final transcript and finish the job: assemble what exists, pair it with whatever audio survived, and surface the memo. **A recording interrupted by a crash must still appear in the list as a usable memo**, not vanish and not appear as a corrupt entry. ## Done when - [ ] A normal stop produces exactly two files and no leftover parts folder. - [ ] Force-quitting mid-recording and relaunching produces a usable memo from what survived. --- *Milestone 1 of the Stash v3 rebuild, scoped 2026-08-06. M1 is a functioning iOS app on Wes's phone with **no sync at all** — the entire goal is recording voice memos reliably and getting them off the device by hand. Sync arrives in M3.* *Working agreement for every issue in this repo: feature branch, tested before the PR opens (on-device where the label says so), then Wes reviews the PR and we walk the code together. Docs update in the same commit. A PR that takes more than 20 minutes to review is too big — say so and split it.*
wk closed this issue 2026-08-08 12:33:09 -04:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Stash/stash-ios#10
No description provided.