Use current promoted files for blueprint launches

docs/deployment-blueprints.md

@@ -4,6 +4,9 @@ The Deployments page is the starting point for reusable server collections. A
 blueprint describes a whole lineup: for example, two Kino lobbies, one Moon lobby,
 and two Town lobbies. Counts are desired fleet totals: existing and queued
 servers count toward each target, and only missing servers are created.
+Blueprints save game/map selections and lobby counts. Every new server uses the
+latest promoted scripts, plugins, baseline, and matching configuration overlays
+when provisioning begins.
 
 For example, a blueprint targeting four Kino and two Der Riese lobbies, with
 two Kino already registered, creates two Kino and two Der Riese lobbies.
@@ -16,7 +19,7 @@ Registered servers count even if stopped or unhealthy; conforming does not
 restart or reconfigure them. Failed creation jobs without a registered server,
 destroyed records, and servers awaiting removal do not count. Excess servers and
 maps outside the blueprint are kept. This action fills deficits; it does not
-destroy servers or change existing files to match saved recipes.
+destroy servers or change existing servers' files.
 
 ## Build and launch a collection
 
@@ -31,14 +34,15 @@ destroy servers or change existing files to match saved recipes.
 Blueprints support up to 40 distinct game/map selections, 1–20 lobbies per map,
 and 100 servers total. The host's configured port range and existing fleet may
 allow fewer. A blueprint can be saved even when there is insufficient capacity
-to launch it. Each map captures its promoted managed files when added.
+to launch it. Saving a blueprint does not capture or pin managed file versions.
 
 Use **Edit** on a blueprint card to change its name, description, maps, or lobby
-counts. Existing map recipes are retained when their counts change; newly added
-maps capture their current promoted setup. Already reviewed launches keep their
-original lineup and file contents, including after blueprint edits or removal.
+counts. Already reviewed launches keep their original lineup, including after
+blueprint edits or removal; their managed files still follow the latest promotions.
+Previously saved blueprints automatically use this policy without being resaved.
 Blueprints saved by the earlier single-server release load as one-server lineups
-and can be expanded directly.
+and can be expanded directly. Any file snapshots in older blueprints are ignored
+when preparing new launches.
 
 A collection preview does not reserve capacity. At submission, all lobby IDs,
 ports, and keys are validated again. The entire collection is then queued in one
@@ -84,43 +88,48 @@ verify the engine map, not the variant's start location.
 ## Save and reuse a blueprint
 
 Expand **Make this a reusable blueprint** in a launch preview and give it a name
-and optional description. You can save a recipe even when host configuration or
+and optional description. You can save the map even when host configuration or
 available capacity blocks launching. Names are unique without regard to case.
 
-Each map in a blueprint retains the game, map variant, image reference, composed configuration
-when available, generated map configuration, and matching promoted script/plugin
-bytes. Credentials, lobby IDs, and ports are not copied from the source server.
+Each map in a blueprint retains the game, exact map variant, and desired lobby
+count. Image references, managed files, and composed configuration are resolved
+from the current setup for each new launch. Credentials, lobby IDs, and ports are
+not copied from the source server.
 
 Use **Conform fleet** on a blueprint card to review missing servers. Remove a
 blueprint from the library when it is no longer needed; its existing servers,
 reviewed previews, and deployment history remain intact.
 
-On a creation detail page, **Launch again** opens its original recipe with the
-next available lobby and port. This reproduces the original managed launch files,
-not the server's later live state. The preview also lets you save that historical
-recipe as a blueprint. Older deployments without a recipe retain their history
-but cannot offer this action.
+On a creation detail page, **Launch again** selects the original game and map
+with the next available lobby and port, using the latest promoted setup. The
+preview also lets you save that map as a blueprint with a target of one lobby.
+The recorded files remain visible as deployment history. Older deployments
+without a recorded recipe retain their history but cannot offer this action.
 
-## What is frozen
+## Promotions and deployment history
 
-The exact managed file bytes, file hashes, version metadata, composed config,
-selected map, and image reference are stored in SQLite. Promotion or deletion of
-an artifact after preview cannot change those bytes. A submitted preview is bound
-to one deployment: retrying the same submission returns the original operation,
-including after an application restart or a lost HTTP response.
+A preview shows the currently promoted managed files, configuration, and image
+reference for the selected map. It does not pin those versions. New launches
+resolve the promoted setup again when submitted and when provisioning begins, so
+promotions made after a preview or while a job is queued apply to that server.
+This applies to blueprint collections, single-server launches, and **Launch again**.
 
-Existing API clients that omit a preview still work. Their recipes are captured
-when queued, before provisioning begins. Queued jobs from before this update use
-the promoted setup at provisioning time because they have no recorded recipe.
+The files selected at provisioning, their hashes and version metadata, composed
+configuration, selected map, and image reference are recorded in SQLite for
+deployment history. These records do not override promotions on future launches.
+Existing API clients that omit a preview and jobs queued before this update
+also use the promoted setup at provisioning time.
 
-This is a launch snapshot, not a permanent version lock. Subsequent campaigns,
-betas, and drift reconciliation continue to follow the server's game/map scopes.
+A submitted preview is bound to one deployment: retrying the same submission
+returns the original operation, including after an application restart or a lost
+HTTP response. The reviewed game/map, lobby ID, port, and key checks are preserved.
+Already running servers continue to receive updates through campaigns, betas,
+and drift reconciliation using the server's game/map scopes.
 Container tags can resolve to newer images; use a digest for a fixed image.
 Without a promoted baseline, Plutainer seeds its own defaults on first boot,
 which are not captured. Host, network, game-file volumes, destination directories,
 and RCON/Plutonium credentials use the environment and key store at launch time.
-A changed main config filename blocks reuse rather than silently loading the
-wrong configuration.
+The current main config filename and launch settings apply to new deployments.
 
 Recipes do not include the separately stored Plutonium or integration credentials.
 Managed files can themselves contain sensitive configuration, so protect database
@@ -142,12 +151,12 @@ require inspection rather than replaying provisioning automatically.
 
 ## API
 
-- `GET /api/blueprints`: list summaries.
+- `GET /api/blueprints`: list lineup summaries with game/map selections and counts.
 - `POST /api/blueprints`: save `{ name, description?, previewId }` or
-  `{ name, description?, deploymentId }` for a single-server recipe, or
+  `{ name, description?, deploymentId }` for a single-map target of one lobby, or
   `{ name, description?, entries: [{ game, mapSlug, count }] }` for a collection.
-- `PUT /api/blueprints/:id`: edit `{ name, description?, entries }`. Unchanged
-  game/map selections keep their saved recipes.
+- `PUT /api/blueprints/:id`: edit `{ name, description?, entries }`. All entries
+  use the latest promoted setup when launched.
 - `DELETE /api/blueprints/:id`: remove a library entry.
 - `POST /api/deployment-collections/preview`: preview `{ blueprintId }`.
 - `POST /api/deployment-collections`: atomically queue `{ previewId, keys? }`,
@@ -157,7 +166,7 @@ require inspection rather than replaying provisioning automatically.
 - `GET /api/deployment-collections`: list collection progress summaries.
 - `GET /api/deployment-collections/:id`: collection and per-server progress.
 - `POST /api/deployments/preview`: preview `{ game, mapSlug }` or `{ deploymentId }`
-  for an explicitly new single-server recipe. All blueprints, including one-server
+  for a new single server using the latest promoted setup. All blueprints, including one-server
   targets, must use the collection endpoint so existing servers count correctly.
   Returns an ID, expiry, recipe summary, capacity, key
   availability (never its value), and prerequisite checks.