The short version: we have repaired the upload path, made the old code safer to change, added repeatable verification, and deployed the latest backend and frontend to Render. It is usable as a small pilot. The remaining work is mostly final security hardening and real browser-based user acceptance.
The repositories are older than this modernization effort. The earliest visible backend commit is cb7aeb3 from January 2026, and the earliest visible frontend commit is fa1a61e from March 2026. The concentrated repair and modernization sequence began on 11 August 2026.
This was not one isolated bug. The app had duplicated legacy code, incomplete deployment assumptions, weak upload-state recovery, old validation paths, and little deterministic test coverage. We treated the upload flow as a connected system instead of patching only the visible error.
Prepared the Django backend for Render, documented deployment gotchas, added missing migrations, switched storage configuration to the R2-compatible path, repaired dependency problems, served static assets, and made the frontend API base URL configurable.
Removed dynamic header evaluation, rejected empty CSV drafts, normalized legacy header metadata and owner phone values, scoped upload access to the correct owner, restricted telemetry/origins, consolidated duplicate backend logic, and extracted validation phases so they could be tested.
Centralized session and resume state, made requests use the correct session-first token, split the large wizard component into clearer pieces, cleared stale matching state, escaped server-controlled messages, and added reproducible frontend verification.
The backend now handles blank rows atomically and rolls back a partial upload if a later storage operation fails. The frontend accepts legacy licence naming, keeps Argos optional when that is the current business rule, preserves retryable wizard steps after request failures, and avoids race conditions when users select files quickly.
The Render backend is serving Django, static assets, admin, and the upload APIs. The latest public health check returned HTTP 200 after the expected free-tier wake-up delay.
The Render frontend has the matching, recovery, and file-selection fixes. Its production build and 51-test CI suite passed before deployment.
Both services auto-deploy from render-deploy-setup. This is intentionally acceptable as the small production-like environment until real users justify a larger operating setup.
These are the three remaining active Beads tickets. They are follow-through work, not evidence that the deployed release is broken.
First finish the telemetry/origin hardening. Then perform full GUI uploads with the legacy CSV scenarios, including valid, invalid, blank-row, missing-optional-Argos, and recovery cases. Finally decide which remaining documentation, sample-data, plans, and generated build artifacts in the worktrees should be committed or discarded; they were deliberately kept out of the release commits.
We are no longer at “old app deployed and hoping.” The core upload path is covered by tests, the highest-risk authorization and validation issues were addressed, the UI recovery behavior was improved, and the exact release commits are live. We should call it a stable pilot, not a fully finished product, until the remaining security review and browser QA are complete.