Open to: feedback on privacy-first / browser-local architecture, conversations about distribution for solo-built products, and swapping notes on in-browser OCR and WebAssembly performance limits.
Helpful distinction between runtime helper threads and the libuv pool. One practical debugging trap: raising UV_THREADPOOL_SIZE will not move CPU-bound JavaScript off the event loop; it changes libuv’s pool capacity, while CPU-heavy work needs worker_threads or a separate process. I’d also label any observed startup thread count with the exact Node and platform versions, since “seven” is an observation rather than a portable guarantee.
The consistency-group caveat in your post-discussion update is crucial for app-and-database backups: a file-level snapshot can be readable yet logically inconsistent if the database and application state are captured at different points. I’d document the quiesce/snapshot/restore sequence and test it on a clean instance, using paused writes or a database-native consistent dump where appropriate. That turns “backup completed” into a reproducible recovery path.
The exact byte-boundary cases are a strong way to make this deterministic. I’d also assert that the client clears its selected-file preview and progress state after a 413, so a retry with a smaller file cannot reuse stale metadata. And your distinction is important: a local mock validates client behavior, while a few genuine uploads are still needed to confirm the gateway’s cap.
