The previous page showed a static "Server online" pill even though it did not
track backend liveness. It also left the selected file in an uploadable state
after completion, which made it too easy to start the same file again and then
land in a saved record that could only fail with "complete file already
exists".
Remove the misleading server-status UI and make saved uploads describe their
next action. Records with every chunk uploaded now show a Finish action, stale
server records are cleared, and a terminal "complete file already exists"
response clears the saved browser progress instead of inviting another resume.
A successful completion also clears the active file selection so the primary
actions settle back to idle.
Test Plan:
- just check
Refs: none
Replace the placeholder browser script with the PLAN.md upload flow. The static
UI now creates upload records, slices the selected file into fixed-size chunks,
uploads missing chunks with a concurrency pool of three workers, retries failed
chunks with exponential backoff, pauses via AbortController, and completes the
upload once the server has accepted every chunk.
Persist pending upload records in IndexedDB and render them in the page so a
reload can resume from server-authoritative progress. When the File System
Access API is available, the app stores a file handle and asks for read
permission during resume; when it is unavailable or permission is denied, the
same pending record resumes after the user reselects the matching file. Browser
state is helpful but not trusted: every resume starts by querying the server for
completed chunks.
Add a JavaScript syntax check to the justfile, update the static-page test and
documentation, and extend TESTS.md with the manual resume scenarios that still
need real-browser repetition.
Test Plan:
- just check
- UPL_BIND=127.0.0.1:39123 UPL_DATA_DIR=$(mktemp -d) cargo run
- curl -fsS http://127.0.0.1:39123/healthz
- curl -fsS http://127.0.0.1:39123/ | rg "Choose file|Pending uploads|app.js"
- firefox --headless --screenshot /tmp/upl-page.png http://127.0.0.1:39123/
Refs: PLAN.md milestones 5, 6, and 7
Add the first upload API endpoint from PLAN.md. POST /api/uploads now
validates the requested file name, generates a server-owned upload id, creates
the staging and complete directory layout, and writes durable meta.json before
returning chunk scheduling details to the browser.
Keep filesystem layout knowledge in storage.rs so later chunk upload and
completion work can reuse the same boundary. API handlers translate storage
errors into JSON HTTP responses without leaking layout details into the router.
Document the new modules and UPL_DATA_DIR configuration, and extend TESTS.md
with the automated creation coverage.
Test Plan:
- just check
Refs: PLAN.md milestone 2
Introduce the first PLAN.md milestone: replace the hello-world binary with
an Axum server that binds to localhost by default, exposes a health endpoint,
and serves the static browser UI from the repository's static directory. The
router is available through the library crate so integration tests can exercise
server behavior without opening a network listener.
Add a justfile for routine validation and document the initial project shape,
configuration knobs, and reusable test checklist. The rustfmt config now uses
only stable options so the new formatting recipe runs without nightly warnings.
The upload API and resumable chunk behavior are intentionally left for later
milestones; the UI currently handles file selection only.
Test Plan:
- just check
Refs: PLAN.md milestone 1
ddidderr
