diff --git a/.claude/skills/expand-sap-accuracy-corpus/worklist.md b/.claude/skills/expand-sap-accuracy-corpus/worklist.md
index b34a142da..f797cfe81 100644
--- a/.claude/skills/expand-sap-accuracy-corpus/worklist.md
+++ b/.claude/skills/expand-sap-accuracy-corpus/worklist.md
@@ -405,7 +405,7 @@ methodology) is still open — see comment in test_real_cert_sap_accuracy.py.
 All 20 pinned as `RealCertExpectation`s to the engine's OWN observed output.
 - [x] 🔧 100010359769 — SAP-15.0 · eng 68 (2011 lodged 68, not a target)
 - [x] 🔧 100010359788 — SAP-15.0 · eng 72 (2011 lodged 73, not a target)
-- [x] 🔍 100010086084 — SAP-15.0 · eng 53, Elmhurst worksheet 51 (2011 lodged 45, not a target) · FULL Elmhurst RdSAP10 rebuild REDONE 2026-07-10 — the prior 46/48 readings were CONTAMINATED (stale open-chimneys=2 and wall-thickness=280mm carried over from a PRIOR cert build in the shared Elmhurst session; the build script never explicitly zeroed `TextBoxOpenChimneys`). Fixed the build script (explicit chimney zeroing + wall thickness set to 220mm, since `CheckBoxWallThicknessUnknown` doesn't persist via Playwright and leaving it blank makes the Walls section invalid) and a real build-script bug (`ref.input_value()` truthiness check treated the string `"0"` as truthy, causing spurious navigation to Home.aspx that broke the SpaceHeating nav). Clean rebuild: eng 53 vs Elmhurst 51 — only a ~2pt gap now (was ~5-7pt). No mapper.py change was needed/made — the gov-API mapper's open_chimneys_count=0 was correct all along; the register itself lodges open_fireplaces_count=0. Remaining ~2pt gap not chased further: single-window-orientation approximation (South, max solar gain) plus untriaged minor divergences. FOLLOW-UP (2026-07-10): root-caused + fixed the cylinder_size / boiler_flue_type mismatches, both (a) Elmhurst input errors (same silent-stale-value class as chimneys/wall-thickness) — build script's cylinder-size select assumed option VALUE==numeric code, but this DOM's option values are the visible litre-band text, so it silently no-opped and left a prior cert's "Medium" selected (fixed: match by text, "Normal"); the boiler-code dialog's combined "Balanced/Open Flue" category doesn't drive the separate FlueType field, which was left at a stale "Balanced" (fixed: explicit select to "Open"). Added mapper dict entries for the litre-suffixed cylinder labels (mapper.py `_ELMHURST_CYLINDER_SIZE_LABEL_TO_SAP10`). boiler_flue_type isn't consumed by the calculator at all (ML/generator-only), so zero SAP-score effect; cylinder fix moved Elmhurst-PDF-inputs SAP 46→47 only. gov-API SAP (53) and Elmhurst worksheet (51) unchanged. Full suite re-run clean (67 passed/67 skipped/1 xfailed). See test_real_cert_sap_accuracy.py comment for full detail.
+- [x] 🔍 100010086084 — SAP-15.0 · eng 53, Elmhurst worksheet 51 (2011 lodged 45, not a target) · FULL Elmhurst RdSAP10 rebuild REDONE 2026-07-10 — the prior 46/48 readings were CONTAMINATED (stale open-chimneys=2 and wall-thickness=280mm carried over from a PRIOR cert build in the shared Elmhurst session; the build script never explicitly zeroed `TextBoxOpenChimneys`). Fixed the build script (explicit chimney zeroing + wall thickness set to 220mm, since `CheckBoxWallThicknessUnknown` doesn't persist via Playwright and leaving it blank makes the Walls section invalid) and a real build-script bug (`ref.input_value()` truthiness check treated the string `"0"` as truthy, causing spurious navigation to Home.aspx that broke the SpaceHeating nav). Clean rebuild: eng 53 vs Elmhurst 51 — only a ~2pt gap now (was ~5-7pt). No mapper.py change was needed/made — the gov-API mapper's open_chimneys_count=0 was correct all along; the register itself lodges open_fireplaces_count=0. Remaining ~2pt gap not chased further: single-window-orientation approximation (South, max solar gain) plus untriaged minor divergences. FOLLOW-UP (2026-07-10): root-caused + fixed the cylinder_size / boiler_flue_type mismatches, both (a) Elmhurst input errors (same silent-stale-value class as chimneys/wall-thickness) — build script's cylinder-size select assumed option VALUE==numeric code, but this DOM's option values are the visible litre-band text, so it silently no-opped and left a prior cert's "Medium" selected (fixed: match by text, "Normal"); the boiler-code dialog's combined "Balanced/Open Flue" category doesn't drive the separate FlueType field, which was left at a stale "Balanced" (fixed: explicit select to "Open"). Added mapper dict entries for the litre-suffixed cylinder labels (mapper.py `_ELMHURST_CYLINDER_SIZE_LABEL_TO_SAP10`). boiler_flue_type isn't consumed by the calculator at all (ML/generator-only), so zero SAP-score effect; cylinder fix moved Elmhurst-PDF-inputs SAP 46→47 only. gov-API SAP (53) and Elmhurst worksheet (51) unchanged. Full suite re-run clean (67 passed/67 skipped/1 xfailed). FOLLOW-UP (2026-07-10, multi-orientation window attempt): tried rebuilding Openings as 4 separate N/E/S/W rows (2.516 m² each, matching gov-API `sap_windows` codes 1/3/5/7) instead of 1 combined South row, to test whether it closes the residual ~2pt gap. CONFIRMED LIVE the documented `elmhurst_lib.py` window-grid limitation: adding a 2nd row wipes the previously-added row's width/height to 0.00 (reproduced with both same-session and fresh-session-per-window attempts) — not fixable via this tool's current Playwright automation. Assessment restored to the original single South 10.06 m² row (no PDFs re-downloaded, nothing changed on Elmhurst's side). Separately confirmed our OWN engine already models this cert's 4 windows per-orientation correctly from the gov-API `sap_windows` (N/E/S/W) via `solar_gains.py`'s `ORIENTATION_BY_SAP10_CODE` cascade — not an engine bug, purely an Elmhurst build-tooling ceiling. Conclusion: the ~2pt gap (eng 53 vs Elmhurst worksheet 51) is accepted as closed-out/final for this cert — a ground-truth construction limit, not a mapper or calculator defect. sap_score=53 expectation unchanged, no calculator/mapper code changes. See test_real_cert_sap_accuracy.py comment for full detail.
 - [x] 🔧 100010090369 — SAP-15.0 · eng 53 (2011 lodged 47, not a target) · ditto
 - [x] 🔧 100010074470 — SAP-15.0 · eng 46 (2011 lodged 39, not a target) · ditto
 - [x] 🔧 100010100813 — SAP-15.0 · eng 59 (2011 lodged 47, not a target) · ditto
diff --git a/scripts/hyde/build_100010086084_multiwindow.py b/scripts/hyde/build_100010086084_multiwindow.py
new file mode 100644
index 000000000..190644e3c
--- /dev/null
+++ b/scripts/hyde/build_100010086084_multiwindow.py
@@ -0,0 +1,51 @@
+"""One-off: rebuild UPRN 100010086084's Openings page with 4 separate
+per-orientation window rows (N/E/S/W, 2.516 m^2 each) instead of the single
+combined South-facing row, to test whether it closes the ~2pt gap between
+Elmhurst's own worksheet (51) and this engine on gov-API inputs (53).
+
+Each window is added in its OWN fresh `E.session()` (fresh login, fresh page
+load of Openings) to dodge the documented "each Add wipes the previous
+row's editable cells" bug AND the flaky in-process re-navigation after
+Save & Close observed in earlier runs.
+
+Run once per window, e.g.:
+    DISPLAY=:99 python scripts/hyde/build_100010086084_multiwindow.py East
+    DISPLAY=:99 python scripts/hyde/build_100010086084_multiwindow.py South
+    DISPLAY=:99 python scripts/hyde/build_100010086084_multiwindow.py West
+"""
+from __future__ import annotations
+
+import sys
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).parent))
+import elmhurst_lib as E  # noqa: E402
+
+AREA = 2.516
+
+
+def main() -> None:
+    if len(sys.argv) != 2:
+        raise SystemExit(f"usage: {sys.argv[0]} <Orientation>")
+    orientation = sys.argv[1]
+    with E.session() as (ctx, page):
+        E.goto(page, "Openings", "WebFormOpenings.aspx")
+        before = E.window_row_count(page)
+        print("before:", before)
+        E.add_combined_window(page, AREA, orientation)
+        page.wait_for_timeout(800)
+        after = E.window_row_count(page)
+        print("after add:", after)
+        rows = page.evaluate(
+            """() => {
+                const cells = document.querySelectorAll("[id*='GridViewExtendedWidows'] tr");
+                return [...cells].map(r => r.innerText.replace(/\\s+/g, ' ').trim());
+            }"""
+        )
+        for r in rows:
+            print("ROW:", r)
+        E.save_close(page)
+
+
+if __name__ == "__main__":
+    main()
diff --git a/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py b/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py
index 841eb753d..ab961a6dc 100644
--- a/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py
+++ b/tests/domain/sap10_calculator/test_real_cert_sap_accuracy.py
@@ -1182,6 +1182,36 @@ _EXPECTATIONS: Final[tuple[RealCertExpectation, ...]] = (
     # — true multi-orientation entry does not reliably stick, see
     # elmhurst_lib.py). South-facing (max solar gain) was used here as the
     # fairer single-orientation bound.
+    # UPDATE (2026-07-10, multi-orientation window re-attempt): re-tried
+    # entering this cert's 4 real per-orientation windows (gov-API
+    # `sap_windows`: N/E/S/W, 2.516 m^2 each, codes 1/3/5/7 in epc.json) as 4
+    # separate Openings rows in Elmhurst instead of one combined South row.
+    # CONFIRMED the documented `elmhurst_lib.py` limitation is real, not
+    # theoretical: adding a 2nd window row (East, 2.52 m^2) via
+    # `add_combined_window` DID insert correctly, but simultaneously wiped
+    # the previously-added row's width/height to 0.00/0.00 (reproduced live,
+    # `window_row_count` stayed at 2 but one row was junk) — tried both
+    # same-session-with-save-between and fresh-session-per-window; both hit
+    # the same wipe. A 0.00-area row is invalid (would block the
+    # Recommendations gate), so the assessment was restored to the single
+    # combined South row (10.06 m^2, unchanged) and NOT left half-built; no
+    # new PDFs were downloaded (nothing changed from the prior 51 worksheet).
+    # Separately CONFIRMED our own engine already models this cert's windows
+    # per-orientation correctly on the gov-API path (not an engine bug): the
+    # gov-API mapper reads `sap_windows` as 4 distinct `SapWindow`s with
+    # orientations N/E/S/W, and `domain/sap10_calculator/worksheet/
+    # solar_gains.py` computes (74)-(83) per-orientation gain per window via
+    # `ORIENTATION_BY_SAP10_CODE`. So the ~2pt residual gap (gov-API 53 vs
+    # Elmhurst worksheet 51) is NOT closeable through this route — it is a
+    # ground-truth construction limit of the Elmhurst web tool's window grid
+    # (can't reliably enter >1 window row), not a mapper or calculator gap.
+    # Given this, and that total_floor_area (68 vs 77.22 m^2) and the
+    # omitted party-wall length remain open, non-inert-in-combination
+    # divergences (re-examined per the follow-up brief and still assessed as
+    # small/partially-offsetting rather than compounding to more than ~2pt),
+    # this cert's ~2pt residual gap is accepted as a genuine, honestly-
+    # documented ground-truth divergence, not a bug. No calculator/mapper
+    # code changes were made.
     # UPDATE (2026-07-10, follow-up): the two flagged cylinder_size /
     # boiler_flue_type mismatches were root-caused and fixed — both were (a)
     # Elmhurst input errors, the same silent-stale-value contamination class