Rebuild beta and campaign file activations

docs/guides/beta-test-plans.md

@@ -29,8 +29,8 @@ servers. Servers held by another active beta or with pending deployment work
 are excluded, as are instances on unavailable, draining, or disabled hosts.
 Unknown or stale player counts are not treated as empty. If the
 requested counts cannot be met, including coverage of every selected map-scoped
-file, the beta does not start. Deployment and restarts still wait for confirmed
-empty lobbies and restart capacity.
+file, the beta does not start. File deployment rebuilds servers after waiting
+for confirmed empty lobbies and rebuild capacity.
 
 Open **Advanced options → Choose specific servers** for manual selection. The
 picker includes servers matching any file in the bundle; each file must have a
@@ -349,7 +349,7 @@ Health monitoring continues after a pass until promotion.
 
 For failures, select hold as failed, pause for investigation, or automatic
 rollback. Rollback queues restoration only for files touched by the beta.
-Restoration and restart both wait for an empty server and restart capacity.
+Restoration rebuilds the server after waiting for an empty lobby and rebuild capacity.
 The manual option holds those changes in a rollback campaign until you select
 **Resume when empty**. Promotion is always manual.
 
@@ -361,9 +361,9 @@ Review the promotion preview before confirming. API clients fetch it with
 409 and requires a fresh preview.
 
 Confirming promotion creates a campaign without reading the existing files on
-additional servers. Each server waits for an empty lobby and restart capacity,
-then captures rollback snapshots immediately before applying its queued files
-and restarting. Campaign history records snapshot capture, and file comparisons
+additional servers. Each server waits for an empty lobby and rebuild capacity,
+then captures rollback snapshots before rebuilding with its queued files.
+Campaign history records snapshot capture, and file comparisons
 become available once those snapshots are confirmed. Tested servers retain their
 original pre-beta snapshots; their composed configuration is still checked at
 promotion to determine whether another activation is needed.
@@ -393,9 +393,9 @@ 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
+configured waves, and starts a fresh testing window at submission. Servers rebuild
+with the requested files 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,
@@ -407,7 +407,7 @@ 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
+unsubmitted activations are superseded. Adding/removing files, changing targets or
 changing the policy still requires a new beta.
 
 ## API and storage

docs/guides/provisioning.md

@@ -150,14 +150,19 @@ and post-action health checks still apply.
 
 ## Campaigns, betas and maintenance
 
-Campaigns, beta runs, and maintenance submit durable restart requests to
+Campaign and beta file changes submit durable rebuild requests to
 Provisioning and observe the resulting operation by ID. Their pages link to that
 operation, and its history links back to the requesting work. Provisioning owns
-the empty-server check, conflict handling, restart capacity, remote command, and
+the empty-server check, conflict handling, capacity limits, remote command, and
 health verification. The callers retain file deployment, beta evidence, and
 maintenance outcome verification. Jobs remain visible while waiting for players,
 other work, or integration configuration.
 
+File rebuilds require host agent 1.9.2 or later. They capture rollback snapshots
+before replacing the instance, and install the requested files over the promoted
+setup. Queued file activations wait for the agent update when necessary.
+Maintenance jobs and beta recovery cycles without file changes still use restarts.
+
 [Maintenance](maintenance.md) also submits recovery operations and links each attempt
 to its incident. A failed Maintenance restart can hand its reserved slot to a rebuild
 after five minutes; unrelated recovery slots remain held. Drift campaigns follow