docs(overhaul): bound resize automation frame-boundary correction

docs/research/2026-09-01-overhaul/476-fix-round2-resize-driver.md

@@ -0,0 +1,52 @@
+# #476 F2 — automation resize boundary only
+
+Lead contract2026-09-05. Parent production0ca10cf24; graphical failure record
+f6285e0ed / 476-480-graphical-r1.md. No GPU capture change is authorized.
+
+## Proven cause
+
+Root independently read GameWindow.OnRender1803–1848: PrepareFrame precedes
+the immutable render input and render graph. RetailUiRuntime988 ticks its
+automation inside private presentation. ScriptRunner235–250 consumes up to
+eight completed commands per tick. resize614 persists/applies the requested
+Window.Size; the synchronous framebuffer event only arms next-boundary
+Vulkan recreation (VulkanHostInputCameraCompositionFactory128–145 and
+VulkanGraphicsContext134–148). FrameRootComposition670 exposes WINDOW size,
+so wait-framebuffer530 can complete immediately within the old render.
+RenderFrameOrchestrator267–270 correctly captures that submitted old extent.
+Run log83→88→92 and95→100→102 prove event→old-size capture→new recreation.
+
+## Bounded change
+
+Only RetailUiAutomationScriptRunner and its existing probe tests, plus short
+evidence/ledger documentation. After a successful resize command advances
+the command index, yield the runner's multi-command loop until its next Tick.
+Do not re-execute resize; retain following explicit framebuffer waits for
+asynchronous native updates. In production the next Tick is inside the next
+render after successful PrepareFrame; failed/minimized preparation never
+reaches UI. Other commands keep existing same-tick batching and timing.
+
+No arbitrary sleep, discarded screenshot, capture retry, new generation or
+render-extent state, native GPU edit, route edit, retail algorithm change,
+lighting/placement fix, or FPS work. This is modern diagnostic scheduling,
+not an AC behavior deviation; no new register row unless implementation
+actually introduces one. Existing AD-121 remains unchanged.
+
+## Verification and closure
+
+New regression must model synchronous framebuffer publication on resize:
+first Tick applies exactly one resize and makes zero screenshot requests;
+next Tick satisfies wait and requests the FIRST screenshot at the new size.
+Keep existing asynchronous resize test, failure/invalid handling and ordinary
+batching passing. Cover sequential resizes without duplicate application.
+Lead removes the production yield, observes this new witness fail, restores
+exactly, and runs affected Release tests. Implementer returns frozen diff,
+commands/results and hashes; do not commit. Root owns integration and one
+narrow review of this diagnostic delta, not reopened GPU/retail lenses.
+Then unchanged original26-command graphical route: retain first request and
+both first-resize PNGs. No pass without inspecting dimensions and every PNG.
+Record PASS/FAIL and graceful exit; all visual results provisional for owner.
+
+No build/test beside either client. Recheck process names before commands;
+lead authorizes one sequential build window. This is second fix round for
+the #476 work, not permission for a third fix round or scope expansion.