Record, transcribe, identify speaker, transcript, summary, save. The web app already did that. Flutter had to do the same visit, not a similar one. I wrote the bug in five Strapi APIs and a mismatched sequence.
200 is not the product
Each call can succeed and the visit can still be wrong if speaker ID ran too early or save ran without a summary React would have stored.
Retries belong in the chain
A failure React retried and Flutter aborted produced different objects. I treated that as networking. It was the spec.
Status the user can read
Transcribing, identifying, summarising, saving — not one spinner for the whole pipeline. Recording itself is a different fight: stop and interruptions.