Fix native provisioning scheduling and progress reporting

2026-10-04 14:50:59 -04:00
parent 1bbee98b62
commit 2adadb0d05
18 changed files with 569 additions and 84 deletions
@@ -374,3 +374,29 @@ coverage is not evidence that a real T5/T6 server has been deployed here. Run:

 Legacy backend code remains for existing database registrations. New native
 launches do not require its configuration, API, network or mounted directories.
+
+### Provisioning progress and diagnostics
+
+Native launches distinguish initial eligibility evaluation from an actual wait
+for startup capacity. The operation page records payload preparation, command
+submission, agent acknowledgement and execution, and separate container, game,
+map and Plutonium revision checks. Native actions use host-agent steps rather
+than legacy Komodo deployment steps. Evidence remains available after completion.
+
+The **Host agent execution** panel reads the durable command state directly,
+including its queue time and latest report time. Agent receipts are recorded in
+the provisioning history when received; they do not wait for a fleet scan.
+An agent command marked completed still requires EC readiness verification.
+The **Controller activity** panel shows current observations and their elapsed
+time while the operation is active. It is a live snapshot, not historical proof
+of which task delayed a previous deployment.
+
+Campaign, beta and maintenance observers run independently of provisioning.
+New requests and completed agent commands wake provisioning; an arrival during a
+pass schedules another pass. File drift scans use bounded batches of four reads
+per scan to reduce agent polling round trips. Startup and disruption safety gates
+remain enforced at command admission.
+
+Older completed operations whose progress snapshots were already discarded
+cannot recover missing check results from this change. Their surviving events
+and host command records remain available without inventing verification times.