Capture current mission, AI, map and administration development

Include the current addon, terrain integrations, tools, regression tests and recorded development evidence.

docs/evidence/garrison-slicing-2026-10-08/README.md

@@ -0,0 +1,54 @@
+# Guard work slicing — 8 October 2026
+
+The reviewed live log `logs_2026-10-08_16-41-19` contained 981 ms update gaps and
+856 ms guard/garrison scopes in the latest played round's 20 stable, populated
+windows. Its journal flush peak was 7 ms. These are elapsed wall times, not proof
+of CPU attribution or a complete explanation of every stall.
+
+The source now uses a shared 100 ms background worker for town/object guards.
+It alternates services and discovery/placement work, caches 250 m static-world
+cells, resumes ground and roof candidate searches, and loads resources/creates
+soldiers individually. Distance is checked before and after native creation;
+placement clearance is checked immediately before creation. Exhausted searches
+wait before retrying. Shutdown removes the callback. A native call remains
+indivisible, so no hard maximum frame time is promised.
+
+`native-fixture.c` overrides observer positions to represent an approach to St
+Philippe on Everon; it leaves guard queries, navigation, physics, RHS infantry
+allocation and Cessna flight intact. It suppresses unrelated procedural site
+generation after initial startup. A first attempt without that isolation was
+terminated by `No safe terrain or valid authored fallback for required site
+everon-medical-1`; this change does not fix that separate generation failure.
+
+The completed Reforger 1.8.0.13 fixture admitted two town squads (7 and 8 soldiers)
+without unsafe birth positions. It performed 1,349 guard work slices, totaling
+613 ms and peaking at 19 ms. The optional Cessna took off with RHS_AFRF aircrew and
+patrolled. The emitted telemetry includes `garrison_work_ms` and a measured
+`performance_flush_ms` sample of 1 ms. Pending final telemetry windows are not
+included when the runner terminates.
+
+This is a component test on different hardware/terrain/population from the live
+Chernarus session. It is not a matched performance benchmark, an assurance of
+lag-free gameplay, or reproduction of the live Cessna startup failure. Retained
+native `error.log` includes existing resource warnings; no claim of a completely
+clean engine log is made.
+
+Cessna preparation now checks at 250 ms rather than scanning crew inventories on
+every 50 ms control callback. Timeout reasons distinguish unready crew, seating,
+missing manpacks and engine startup. Three consecutive pre-service failures
+pause further allocations until the next round. Loss of an aircraft that entered
+service still schedules its normal replacement. The real server's old generic
+timeout did not identify its failed gate; the isolated RHS test did not reproduce
+that failure.
+
+`report.json` records final source hashes. The private runner requires the local
+engine/addon caches named in it and never connects to or modifies the live server.
+Focused town policy/HQ registration checks and the source-bundle audit passed.
+No publication or server restart was performed.
+
+A second native fixture deliberately moved its observer into a partly prepared
+squad's next spawn position and forced every Cessna preparation to fail. It
+verified at most one birth per slice, cancellation/removal of the partial squad,
+exactly three aircraft failures followed by a pause, and no further guard
+callbacks after HQ shutdown. The final marker is retained in `fault-summary.log`.
+The injected failures test the retry limit, not the cause of the real failure.