Smooth convoy startup and record Workshop 0.0.153

docs/evidence/convoy-startup-performance-2026-11-10/README.md

@@ -0,0 +1,38 @@
+# Convoy startup investigation — 10 November 2026
+
+The production logs associate three large convoy timing windows (352, 396 and 400 ms maxima) with two creation events and subsequent cargo loading in each window. There were no interception events in those selected runs. These are minute aggregates: they identify startup as the investigation target, not the exact native function responsible for each stall.
+
+## Native result
+
+The [native comparison](comparison.json) completed both startup gates: three convoys, 15 vehicles, 30 living crew, zero failed or pending cargo insertions. Baseline had 204 successful cargo insertions and candidate 216 because cargo choices are random. Both had zero script errors and identical existing resource diagnostics (37 lines, 23 distinct messages). Cleanup and unchanged source fingerprints were verified.
+
+| Observation | Baseline | Candidate |
+| --- | ---: | ---: |
+| Maximum global update gap, active-round window 2 | 342 ms | 140 ms |
+| Maximum mission tick, same window | 324 ms | 128 ms |
+| Maximum HQ convoy scope, across both windows | 381 ms | 9 ms |
+| Maximum separately queued survey / creation / cargo callback | Not separately measured | 34 / 55 / 3 ms |
+| Startup-ready gate, elapsed since supervisor start | 111.1 s | 123.1 s |
+
+The candidate moves work outside the HQ scope, so **9 ms alone is not the improvement measure**; queued callbacks and global update gaps must be considered too. One creation callback exceeded 50 ms; none of the candidate convoy callbacks exceeded 100 ms. Mixed preparation window 1 still had large global gaps (655 / 620 ms), which are not attributed to convoys. One convoy location and the random cargo differ between arms. This is evidence of smoother startup in this local trial, not a matched-layout benchmark or a general CPU/FPS claim.
+
+## Implementation
+
+- Survey friendly base approaches one site per callback; avoid terrain/water calls for road segments that cannot improve the XZ distance ranking.
+- Resume road lookup, road setup and formation candidates across callbacks. Keep original candidate ordering, tie-breaking, terrain checks and formation validation. Each 20 ms callback handles at most eight pieces with a cooperative 2 ms target.
+- Consume the finite receipt once, then create at most one group, vehicle or crew member per 50 ms callback. Recheck ownership and placement as the world changes. Failed startup retains partial entities and cannot refill the allocation.
+- Freeze cargo choices, then submit at most two inventory insertions per 50 ms callback. Preserve accepted callbacks and the weapon/magazine completion barriers.
+- Cancel loading safely if the original truck or crew is lost; surviving escorts retain the ordinary controller policy.
+- Measure startup, road survey, creation, cargo, normal runtime and interception separately. Inspect global update intervals alongside those scopes.
+
+The 2 ms survey target is cooperative. A single native allocation, query, trace or inventory insertion cannot be preempted. Work is spread out; this does not establish lower total CPU consumption or higher steady-state FPS. Dense terrain can take longer to finish searching.
+
+## Validation
+
+[Regression summary](regressions.json) records 25 targeted programs. [Initial broader results](regressions-initial.json) retain the obsolete synchronous budget-harness failure; the [final asynchronous budget result](budget-regression-final.json) preserves its original budget/replay assertions and adds a post-yield capacity check. Negative controls reject removal of work bounds, cargo barriers, truck validation and the final budget recheck.
+
+Native runs use isolated Workbench profiles, the same input configuration and a frozen baseline/candidate source tree. The FIA player faction avoids an unrelated authored extraction site failure; enemy convoys remain USSR. The supervisor stops after three production convoys reach readiness with finite physical cargo, followed by the next performance flush. This only qualifies startup, not the later driving/combat/reboarding fixture phases or multiplayer behavior.
+
+Random mission layouts are not seeded. Before/after runs therefore have unmatched placement geometry and are observations rather than a controlled FPS benchmark. Preparation windows must be distinguished from windows entirely in the active mission. Baseline and candidate details, startup positions, raw timing rows, source hashes and cleanup evidence are retained alongside the final comparison report.
+
+No production server deployment or Workshop publication was performed for this investigation.