Rotate the layout without restarting the player's progress

A resize handler can accidentally behave like a new game. This fixture checks the boundary between presentation state and the player's progress when the available orientation changes.

This edition is a laboratory fixture. Node and the companion HTML page execute the authored functions against synthetic cases. No physical device panel was run, no ad network reviewed the build, and no campaign result is inferred from a passing test.

What the documentation actually supplies

MDN: orientation state is the governing reference for the browser primitive. MDN documents ScreenOrientation's change event as a notification that screen orientation changed. Receiving that event does not require an application to discard game state. The fixture policy around that primitive is ours.

The failure the fixture isolates

The input contains a score and remaining moves plus the new dimensions. The corrected branch updates the presentation fields while preserving progress. The broken branch rebuilds an initial state and loses both values. The test therefore reproduces a state-management error without claiming to rotate a physical device.

The broken branch is retained so a producer can see the exact mistake, not only the repaired output.

All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.

What a pass does not prove

A passing result proves that the supplied progress survives this model transition. It does not prove that sprites, hit regions, audio or the actual host's resize events behave correctly. State preservation and geometric correctness are separate acceptance conditions; both must pass before a real playable is considered usable after rotation.

Untested cells in this edition: physical devices, host SDKs, network packaging limits, store-opening callbacks, and campaign performance. Those remain empty on purpose.

Next check on a real build

Keep canonical game state outside the layout constructor. When integrating with a browser or SDK, make resize events idempotent and test them during a drag, during a transition and on the end card. Record the state before and after each event rather than relying on a screenshot alone.

Open the runnable fixture to re-execute the cases in a browser. Download the case record to keep inputs, expectations and limits with a QA ticket.

Background in the archive: Playable ad device testing matrix and Playable spec sheet before you build. Those guides describe practice; they are not a substitute for this fixture and this check does not recertify their every claim.