Complete provisioning job detail pages and lifecycle evidence

docs/provisioning.md

@@ -75,6 +75,59 @@ new attempt, preserving prior history; paused or closed beta work cannot start a
 queued restart. Recovery of an already submitted restart continues even if its
 requester closes. Upgrades adopt existing restart intent for observation only.
 
+## Operation details
+
+Each job page puts its recorded outcome, blocking condition, and available next
+action before launch files. Execution is grouped into phases, with separate
+milestones for remote deletion, local cleanup, and replacement creation during a
+rebuild. Copy the operation ID or link when investigating or handing off a job.
+Related work links back to the requesting campaign, beta, maintenance item, or
+collection. A completed provisioning job does not imply that its requester has
+finished its own verification.
+
+New operations record structured verification evidence alongside their activity:
+the check result, source, evaluation time, and expected/observed map when relevant.
+Game status can be verified by RCON or accepted fresh telemetry. Engine-map checks
+do not independently verify a T6 start location. Passed checks describe their
+recorded observation; later checks can fail or become unknown. Completion describes
+what was verified at that time, while **View server** opens the current instance.
+Older history retains its recorded stages and outcomes; unavailable evidence is
+not inferred from stage wording.
+
+Submission attempted, command accepted, and verified completion are separate
+milestones. A failed restart may still have ongoing recovery observation and hold
+restart capacity. Its original failure remains in history even if recovery later
+succeeds and releases the slot. Capacity and request order are snapshots, not
+guarantees of the next job admitted or an estimated completion time. Blocked
+requests can be bypassed by eligible work.
+
+Recovery controls use the server's current eligibility checks. **Resume health
+verification** observes the existing instance without submitting another create or
+restart. **Resume cleanup** retries local cleanup after confirmed remote deletion,
+including eligible historical deleted identities; replacement or newer-operation
+guards still apply. **Resume rebuild cleanup** completes cleanup before creating
+the replacement in its reserved slot. Resuming the same operation preserves its
+earlier failure and resume events. Uncertain commands have no generic Retry action.
+
+Create and rebuild capture a setup when queued and select the latest promoted
+files again when creation begins. The page distinguishes **Setup captured when
+queued** from **Files selected for this attempt**. A queued capture does not pin
+versions; an attempted selection is not proof that every file was installed.
+**Launch another server** uses the latest promoted setup with a fresh identity and
+port, rather than repairing or replaying the recorded job.
+
+Five recent events remain visible. Expand full history to search, change order,
+and load older pages. A fixed history watermark keeps the viewed pages stable as
+events arrive; **Jump to latest** incorporates new activity. The detail view
+fetches a bounded recent-event window, while full history loads on demand.
+
+The page refreshes every five seconds while visible, including terminal jobs whose
+recovery or available actions may still change. **Page updated** describes the
+last successful detail fetch; it is separate from the worker's evaluation and
+telemetry receipt times. A refresh failure keeps the last snapshot visible and
+does not erase an acknowledged action result. These timestamps are not worker
+heartbeat or completion-time promises.
+
 ## Routes and compatibility
 
 - `/provisioning`: active operations and history filtered by action.
@@ -89,6 +142,16 @@ requester closes. Upgrades adopt existing restart intent for observation only.
 - `/api/provisioning/:id`, `/:id/resume`, `/:id/cancel`, `/preview`, and
   `/house-party` preserve the existing operation, recovery, removal cancellation,
   launch preview, and fleet destruction APIs.
+- `GET /api/provisioning/:id?events=recent` returns the same detail with five recent
+  events plus activity totals/latest ID and a failure excerpt. Omitting the option
+  preserves the full legacy event response. Progress, capacity, named related work,
+  and normalized warning messages are additive fields; the original warning string
+  and lifecycle fields remain available.
+- `GET /api/provisioning/:id/events` reads history with `order=newest|oldest`,
+  literal-text `query`, `limit` (default 25, maximum 100), an exclusive event-ID
+  `cursor`, and an upper-ID `watermark`. Keep the returned watermark when loading
+  more and use `nextCursor` until it is null. Begin without a watermark to include
+  newly arrived events. These reads do not probe Komodo or RCON.
 
 Old `/deployments` pages redirect to their `/provisioning` equivalents, preserving
 query parameters. Collection launch links at `/provisioning/collections/:id` or