For Stakeholders

Why it matters

This closes a real gap: the app's default upload route (presigned S3, used by any clinic that hasn't connected Google Drive) reported no progress at all while uploading — on iOS in particular, the request body was buffered in memory and the operating system only reported it as sent once, at the very end. To a user, a large file upload over a slow connection was indistinguishable from a frozen app. That's a trust problem as much as a UX one: staff who can't tell if something is working are more likely to force-quit the app, retry unnecessarily, or lose confidence in it generally.

Impact

• Touches four everyday staff actions: clocking in/out, adding patient files,

recording patient voice notes, and sending voice messages in staff chat.

• Fixes the worse of the two upload routes (S3, the default) to match the better

behavior the Google Drive route already had, then adds visible progress reporting on top of both.

• Purely additive to the UI — no change to what gets uploaded, where it's stored, or

any data model. Low functional risk.

Risk

• Scope is narrow. Confined to packages/clinic-mobile; no server, database, or

web package changes. Nothing about storage or file handling on the backend changed.

• The upload mechanism changed, not just the UI. The S3 upload switched from a

fetch + FormData request to expo-file-system's createUploadTask API. That's the one place a stakeholder should expect QA to focus — a regression here would affect every S3-backed file upload on mobile, which is the default configuration for clinics without Google Drive connected. See For Quality.

• Translation coverage: the one new user-facing string ("Speed") was added to

all nine supported languages, so there's no untranslated-string risk shipping with this.

Status

Unreleased — this PR has not shipped. Treat any figures or descriptions here as describing code on a branch, not current production behavior.