research: re-test L157/L160 on the incremental base (L167, none promoted)

7 runs each: L157 near 55.4% but a 16.7 ms worst tick (UpdateChunks/level sort/overlay); L160 tick-safe but lower
all-around near and later arrival; both: forward cone 25.2% and p99 <= 11 ms, but worst tick up and a 14.3 ms run.
Also found: voxel.StreamingIncrementalDesiredSet defaults to 0, so L165/L166 gains need it enabled.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016dhxM43dnWvUu2B5Ph1iG1

Standalone/Research/WorldAssemblerM3/Linux167/REPORT.md

@@ -0,0 +1,39 @@
+# L167 — Re-test L157 and L160 on the faster base
+
+**Result:** No candidate meets the full default bar. Leave L157 and L160 disabled. L160 is tick-safe in this W8 run but lowers all-around near readiness and delays arrival. L157 improves readiness but still spikes; combining them improves readiness most, but worsens worst ticks and delays arrival.
+
+## Measurement
+
+Ran base, L157, L160, and both in seven interleaved repetitions each at 30 m/s. Each measured run covered a 12-second move and 5-second dwell, with eight effective tile slots and the four-strata owner plan. One base warm-up was excluded. Timing began with 1/5/15-minute loads at 0.77/0.96/1.46 and no other build or editor process running. Values below are medians across seven runs; p99 range and maximum worst tick show the full run spread.
+
+The common base had `StreamingIncrementalDesiredSet=1` with audits off, matching the faster L165/L166 path. The checked-in CVar default remains off; this was a controlled runtime setting for the comparison. Null-RHI provided no camera-forward samples, so the 55-degree forward cone uses travel direction.
+
+| Condition | Tick p99 median (run range), ms | Worst tick median / run max, ms | Near readiness, % | Forward cone, % | Far holes, % | LOD0–2 arrival, s |
+| --- | ---: | ---: | ---: | ---: | ---: | ---: |
+| Base | 7.289 (6.786–7.513) | 12.061 / 12.465 | 43.39 | 15.77 | 3.00 | 2.230 |
+| L157 | 8.582 (8.046–12.462) | 12.462 / 16.689 | 55.44 | 18.61 | 2.64 | 2.469 |
+| L160 | 7.187 (6.962–8.009) | 11.747 / 12.503 | 38.03 | 20.32 | 2.59 | 2.447 |
+| Both | 8.932 (8.064–10.973) | 12.594 / 14.278 | 45.55 | 25.24 | 2.85 | 2.461 |
+
+Near readiness, cone readiness, and far holes improved for L157 and the combination; L160 lowered all-around near readiness. All three candidates delayed median arrival by 0.216–0.239 seconds. L157 had one run above the 11 ms p99 limit and a 16.689 ms worst tick. The combination stayed within the p99 limit in all seven runs, but its median worst tick was 0.533 ms worse than base and one run reached 14.278 ms. L160 passed the tick limits but failed readiness and arrival gates. Therefore none qualifies as default.
+
+## Spike count and cause
+
+Trace data attributes the L157 spikes to main-thread desired-set and scheduler work, not the 1 ms apply budget:
+
+- At the 16.689 ms worst tick, `UpdateChunks` took 15.500 ms. `SubmitTiles` took 8.807 ms, including 8.336 ms in level sorting; desired rebuild took 5.353 ms. Apply took only 0.374 ms. The scheduler trace counted 912 reserve-declined tiles and three near tasks submitted.
+- A second 16.198 ms tick had 13.852 ms in `UpdateChunks` and an 11.777 ms desired rebuild, including 6.679 ms of overlay materialization. `SubmitTiles` took 0.813 ms and apply took 1.087 ms.
+- The combined run's 14.278 ms maximum had 10.279 ms in `UpdateChunks`, 2.859 ms draining pending results, and one applied result taking 2.799 ms against the 1 ms budget (`time_limit_reached=1`). Its level sort was only 0.095 ms. The budget is checked after a result completes, so it cannot bound one expensive apply.
+
+These traces show more than one source: level sorting under L157 admission, expensive desired-set rebuild/materialization, and individual result-apply cost in the combined mode. No tuning change was attempted because the measured work does not support a single cap adjustment that would address all three; all candidates also fail another promotion gate.
+
+## Checks and limits
+
+- VFHost Linux Development build succeeded with `-NoUBA -MaxParallelActions=4`; the temporary VFHost plugin source link was restored afterward.
+- `verify.py fast` passed in 298.0 seconds: 268 pass, 0 fail, 5 diagnostics. Its 84 binary runs had 82 pass and 2 expected failures. Geometry checks and Clang/GCC W1/W8/W12 determinism passed. The L167 source stamp matched the L166 verifier binary (`ba79279c16018d2996e724df0f7c0e8a210929baebc1aa14bef6a76fbda96faa`).
+- Movement timings used W8, the effective slot count read back by this VFHost command. W12 movement was not run; the command's 12-core affinity exposed eight TaskGraph background workers and eight effective streaming slots. Fast-tier W12 determinism did run. The live movement `TileHashDump` hook was not enabled; no geometry-generation source changed.
+- Runner `py_compile` and `git diff --check` passed on the final files. No Unreal `Source/` files changed.
+
+Changed Unreal `Source/` files: none.
+
+Artifacts are under `Saved/Linux/l167/`; the interleaved movement runner is `RunL167Movement.py` alongside this report.