Conform blueprint launches to desired fleet counts

docs/deployment-blueprints.md

@@ -2,16 +2,31 @@
 
 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, launched together from one preview.
+and two Town lobbies. Counts are desired fleet totals: existing and queued
+servers count toward each target, and only missing servers are created.
+
+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.
+The preview shows **Target / Existing or queued / To create** for each map.
+Matching is by game and exact map variant; T6 Town and Farm are distinct even
+though they share an engine map. Provisioning identities are counted once when
+they appear in both the server registry and active creation queue.
+
+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.
 
 ## Build and launch a collection
 
 1. Choose **Create blueprint** on Deployments and name the lineup.
-2. Add maps from Black Ops I or II and set the number of lobbies for each.
+2. Add maps from Black Ops I or II and set the desired total lobbies for each.
 3. Choose **Save & preview** to review every new server ID and game port.
 4. Enter each lobby's Plutonium key, or leave its field blank to reuse the key
    saved for that exact server ID.
-5. Choose **Launch all N servers** and follow the collection progress page.
+5. Choose **Create N missing servers** and follow their collection progress page.
+   If every target is already met, choose **Done**; no operation is created.
 
 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
@@ -33,7 +48,11 @@ the preview clears typed keys so they cannot be applied to changed server IDs.
 
 Submitting the same preview again returns the same collection, including after
 a lost response or an application restart. Reusing the blueprint with a new
-preview deliberately creates another collection with fresh available capacity.
+preview recomputes the shortfall, including servers queued by earlier launches.
+It does not add another full copy of the lineup. If the shortfall or assigned
+capacity changes before submission, the request is rejected without changes and
+requires a fresh preview. Previously saved additive previews are checked against
+the current shortfall too.
 
 The worker provisions servers sequentially; health verification and failures are
 recorded separately for each. One failure does not undo servers already created
@@ -72,7 +91,7 @@ Each map in a blueprint retains the game, map variant, image reference, composed
 when available, generated map configuration, and matching promoted script/plugin
 bytes. Credentials, lobby IDs, and ports are not copied from the source server.
 
-Use **Launch N servers** on a blueprint card to review fresh capacity. Remove a
+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.
 
@@ -133,11 +152,13 @@ require inspection rather than replaying provisioning automatically.
 - `POST /api/deployment-collections/preview`: preview `{ blueprintId }`.
 - `POST /api/deployment-collections`: atomically queue `{ previewId, keys? }`,
   where `keys` maps exact preview server IDs to optional replacement keys.
+  A satisfied preview returns `{ ok: true, collectionId: null }` with HTTP 200,
+  without creating a collection, saving keys, or kicking the worker.
 - `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 }`, `{ blueprintId }`,
-  or `{ deploymentId }` for a single-server recipe. Multi-server blueprints must
-  use the collection endpoint; they cannot silently launch only one entry.
+- `POST /api/deployments/preview`: preview `{ game, mapSlug }` or `{ deploymentId }`
+  for an explicitly new single-server recipe. 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.
 - `POST /api/servers`: existing request plus optional `previewId`; the game and