docs(plans): record rig live-gate PASS for the resolver cache (+2 objs/compile vs +289 pre-fix)

2026-08-12 17:49:29 -04:00
parent df17b53f08
commit 20f2ae05ca
2 changed files with 16 additions and 2 deletions
@@ -565,6 +565,20 @@ Run on the docker rig first, then wonder-app-vd03 after deploy (tooling at `E:\A
 3. Re-dump. Pass gate: triple grows ≤ ~10 objects per forced compile (the accepted `CreateFromAssemblyInternal` residual). Pre-fix behavior: ~300+ per compile.
 4. Also expect the *steady-state* count to collapse on a restarted post-fix node: the 21-script site should hold ~1 closure set (+ statics) instead of 21 — thousands → hundreds, with a corresponding working-set drop.

+### Task 9 result — rig leg PASS (2026-08-12)
+
+Executed on the docker rig, site-a node A (`scadabridge-site-a-a`, aarch64, standalone `dotnet-gcdump`), forced compiles = 3 rounds of Tick-script (template #2147, script 1033) body edit + `instance deploy --id 95`:
+
+| | pre-fix image (`5a781c70`) | post-fix image (`df17b53f`) |
+|---|---|---|
+| triple baseline (per type) | 1,332 (8 h uptime) | 760 (fresh boot) |
+| after 3 forced compiles | 2,199 | 766 |
+| growth per compile round | **~+289 per type** | **+2 per type** (`CreateFromAssemblyInternal` residual, as predicted) |
+| `NativeHeapMemoryBlock` growth | +861 | **0** |
+| `Script<Object>` | 3 → 6 | 4 → 7 (proves compiles really ran) |
+
+Functional: cluster converged under the bootstrap guard, Tick script executing, notifications flowing site→central, no steady-state errors. Driver script body restored afterwards. **Remaining leg: wonder-app-vd03** — same procedure after the fix is deployed there (operator decision); tooling notes in the table above apply (script bodies must change; `E:\ApiInstall\_tools\diag\`).
+
 ## Out of scope / follow-ups

 - `SiteScriptCompileCache` is unbounded across code revisions (every edited script body adds a permanent entry). After this fix each entry is small, but an LRU cap is a reasonable hygiene follow-up.