docs(scripting): #789 owner accepts the measured Windows-VM budgets (idle p50 ≤ 500 µs, ≤ 50 pts batched at 10k/s)

Claude-Session: https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi

docs/plans/2026-11-09-out-of-process-script-runner-design.md

@@ -530,10 +530,10 @@ size for 2× headroom (10k/s). The passthrough fast path is excluded because it
 
 | Metric | Budget | Notes |
 |---|---|---|
-| Added latency per evaluation, p50 | ≤ 150 µs | Host enqueue → reply decoded, trivial script, idle system |
+| Added latency per evaluation, p50 | ≤ 150 µs (Linux, macOS); **≤ 500 µs on a Windows VM** | Host enqueue → reply decoded, trivial script, idle system. **Windows-VM budget accepted by the owner 2026-11-12 (lmxopcua#789, §14 #15):** windev measured 355–388 µs, because a blocking hand-off costs about 10× macOS there (§12.8). 500 µs is 0.2 % of the 250 ms alarm budget |
 | Added latency per evaluation, p99 | ≤ 2 ms | At 10k evals/s. Compare the 250 ms alarm budget: under 1% of it |
 | Throughput | ≥ 10,000 trivial evals/s/node with K=2 | With opportunistic batching |
-| Host CPU for IPC | ≤ 25% of one core at 10k evals/s | Serialisation + pipe I/O, measured by an opt-in perf test. Since lmxopcua#789 the harness reports it as the out-of-process runner's host CPU minus the in-process runner's in the same phase ("vs InProcess"): the raw figure includes the harness's own pacing loop and pool, which InProcess pays too (§12.2) |
+| Host CPU for IPC | ≤ 25% of one core at 10k evals/s (Linux, macOS); **≤ 50 points batched at 10k/s on a Windows VM** | Serialisation + pipe I/O, measured by an opt-in perf test. Since lmxopcua#789 the harness reports it as the out-of-process runner's host CPU minus the in-process runner's in the same phase ("vs InProcess"): the raw figure includes the harness's own pacing loop and pool, which InProcess pays too (§12.2). On a Windows VM the gate is the `paced 10,000/s, batched` row (windev measured +36 to +45; one-at-a-time +71 to +84 is reported but not gated). At 5k/s, the planning envelope [A-14], out-of-process is already below InProcess |
 | Bytes per eval on the wire | ≤ 64 B + 24 B per input | Positional slots, §4.4 |
 | Shard restart → first result, 1,000 cached scripts | ≤ 2 s | §7 lazy PE load |
 | Worker idle RSS | ≤ 200 MB + scripts | Per shard. **Revised by the owner 2026-11-11 (lmxopcua#789)** from the original ≤ 80 MB + scripts **[A-3]**. Compiling in the worker (§14 #7) keeps Roslyn's code and metadata resident once it has run (measured 159–187 MB), and no GC setting moves it (§12.2). A worker that has only loaded cached PEs sits far below that (measured 36–58 MB). The perf harness reports both against 200 MB |
@@ -1700,7 +1700,7 @@ Each has a recommendation, marked ★.
 14. **Does this need a real-deployment scale target?** [A-14]'s 5k evals/s/node is a guess. The owner should
     supply the expected VT / Calc / alarm counts per node for the target sites, or accept the guess as the
     gate.
-15. **Windows idle-latency and host-CPU budgets (lmxopcua#789, §12.8).** On the windev VM one blocking hand-off costs
+15. **DECIDED 2026-11-12: the owner accepts the measured windev values. §8.2 now states per-platform budgets: Windows VM idle p50 ≤ 500 µs and ≤ 50 points batched at 10k/s. No bare-metal measurement is required, and no transport change will be made. lmxopcua#789 is closed.** Windows idle-latency and host-CPU budgets (lmxopcua#789, §12.8). On the windev VM one blocking hand-off costs
     ~26 µs of latency and ~18 µs of CPU, ten times macOS, and an evaluation needs four of them. Idle p50 is 355–388 µs
     (InProcess alone 132–143 µs). Host CPU at 10k/s is +71 to +84 points one evaluation at a time and +36 to +45
     batched, against ≤ 150 µs and ≤ 25.