Allow revising active betas with fresh tests and history

docs/beta-test-plans.md

@@ -197,8 +197,8 @@ Set wave size to 1 for a canary, a larger number for batches, or 0 for all
 selected servers. Later waves receive files after the previous waves pass.
 Health-outage budget violations on any tested server block promotion.
 
-The test window starts when the beta opens, including time waiting for empty
-servers. Missing evidence at the deadline produces **inconclusive**.
+The test window starts when the beta opens or a revision is submitted, including
+time waiting for empty servers. Missing evidence at the deadline produces **inconclusive**.
 Health monitoring continues after a pass until promotion.
 
 For failures, select hold as failed, pause for investigation, or automatic
@@ -208,7 +208,7 @@ The manual option holds those changes in a rollback campaign until you select
 **Resume when empty**. Promotion is always manual.
 
 Pause holds evaluation and wave advancement. Resume retains completed progress and the
-original deadline, but starts new timing intervals. A fresh attempt resets
+current revision's deadline, but starts new timing intervals. A fresh attempt resets
 progress and restarts deployed servers when empty. Recovery cycles repeat
 gameplay milestones and checklist sign-offs while carrying health outages forward.
 
@@ -217,6 +217,32 @@ recent 200 evidence entries. On upgrading from the old reporter protocol,
 active progress resets. Unsupported checks in existing plans and saved presets
 become manual review items; they cannot silently pass.
 
+## Updating an active beta
+
+Choose **Update beta** on the beta detail page, upload replacements for existing
+bundle files, and review the changes and selected servers before choosing
+**Deploy revision**. Text files show a diff when both files are small enough;
+binary and large files show their checksums. Files must actually change.
+
+The beta keeps its ID, servers, scope and test policy. Each revision creates new
+file versions, clears current test progress and checklist sign-offs, repeats the
+configured waves, and starts a fresh testing window at submission. Files install
+and servers restart through the normal empty-server and capacity gates. Promotion
+requires the new revision to pass. Pause and retry retain the current revision's
+deadline; they do not create a revision.
+
+Revision history retains downloadable bundle files and previous test results,
+including the last 200 evidence entries shown at replacement. All underlying
+attempts and evidence remain in SQLite, separated by revision. Rejecting the beta
+restores the original pre-beta files, even after multiple revisions or while a
+new revision is waiting to deploy. Files originally absent are removed.
+
+Updates are available until promotion or rollback, including paused, failed and
+expired tests. An activation already in progress must settle first; interrupted
+file writes and deleted participants must be resolved before an update. Pending,
+unsubmitted restarts are superseded. Adding/removing files, changing targets or
+changing the policy still requires a new beta.
+
 ## API and storage
 
 `POST /api/betas` accepts `testPlan`.
@@ -228,6 +254,12 @@ recent evidence under `test`.
 `GET/POST /api/betas/presets` lists/saves reusable plans. Saved presets are
 copied into a beta; later edits do not change an active plan.
 
+`POST /api/betas/:id/revisions` accepts multipart `expectedRevision`, optional
+`notes`, and replacement uploads named `file:<scriptId>`. A stale revision is
+rejected. `GET /api/betas/:id` includes the current `revision` and `revisions`
+history; `GET /api/betas/:id/revisions/:revision/files/:scriptId` downloads an
+archived file (or the original pinned file before its first update).
+
 Internal progress records support attempts and recovery cycles. The reporter
 does not know about or supply these records. Legacy betas without a test plan
 also use `game_end` at round 2 or later for their match-completion gate.