Wrap a one-off automation script in a usable internal web tool

I have a Python script that regenerates and re-uploads the weekly sales report CSV to the shared drive, and right now only I can run it because it lives in my terminal with hardcoded arguments. Wrap it in a small internal web UI on Replit so the 3-person ops team, none of whom write code can trigger it themselves without touching code or a terminal.

CURRENT SCRIPT
A Python script (report_gen.py) that takes a --week-start date argument, queries the sales database, builds a CSV, and uploads it via the Google Drive API — currently run manually from my laptop

WHAT TO BUILD
1. A single-page web UI with a form matching the script's actual parameters — week_start_date (required), and an optional --dry-run flag that skips the actual upload step — with real input validation matching what the script itself expects (a date picker for a date argument, a number input with the script's actual valid range for a numeric one), not a single freeform text box the user has to know the right syntax for.
2. A "Run" button that executes the script with the form's values and shows live output as it runs — streamed log lines appearing as they're produced, not a blank screen until the whole script finishes and then a wall of text all at once.
3. A run history list: every past run, who triggered it, when, with what parameters, and whether it succeeded or failed, with the ability to click into any past run and see its full captured output again.
4. If the script can take more than a few seconds, show a clear in-progress state and disable the Run button while a run is active — do not let the same job be started twice concurrently by two people clicking Run within a few seconds of each other, since two simultaneous runs would both try to upload a file with the same name, and one upload could silently overwrite the other mid-transfer.

ACCESS CONTROL
Gate the whole UI behind a single shared password for now — the ops team is small and this doesn't need individual logins yet, but it must not be reachable by an unauthenticated request — this tool runs real automation with real side effects, so it should not be reachable by just anyone who finds the URL.

SAFETY RAILS
Before wiring the Run button to actually execute the script, confirm with me what the script's actual side effects are — it overwrites last week's file on the shared drive if run twice for the same week, and there is no automatic backup of the previous version — and add a confirmation step in the UI before running if any of those side effects are destructive or hard to undo, rather than making "click Run" as casual an action as loading the page. If the script can fail partway through in a way that leaves things in a bad intermediate state, note that risk explicitly rather than presenting the wrapped version as safer than the original script just because it now has a nicer UI.

CONSTRAINTS
Keep the script's own logic untouched — this is a UI wrapper around the existing script, not a rewrite of what it does.

OUTPUT
Alongside the UI, a short note on exactly how the web UI invokes the underlying script (subprocess call, direct function import, etc.) and what happens to its stdout/stderr to produce the live log view.