Do not show a playing state before playback is accepted

A successful tap is not the same as successful audio playback. This fixture exercises the promise boundary so the interface cannot claim sound is playing after a rejected request.

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: audio rejection is the governing reference for the browser primitive. MDN states that HTMLMediaElement.play returns a promise resolved when playback starts and can reject when playback is disallowed or the source is unsupported. Script-initiated playback remains subject to browser policy. The fixture policy around that primitive is ours.

The failure the fixture isolates

The fixture supplies an accepted or rejected playback promise. The corrected branch waits for it and returns an accurate state; the broken branch immediately reports playing. No sound file or external media is loaded. This isolates state handling without claiming to test a particular browser's autoplay restrictions.

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 pass establishes that the interface can represent a rejected request. It does not prove audible output, device volume, codec compatibility or a real user-activation path. Those require browser and device checks with an actual permitted media file, and should be recorded separately from this promise-handling regression.

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

In a real playable, trigger playback from the intended interaction and keep the UI pending until the promise settles. Offer a useful muted state if it fails. Repeated taps should not create overlapping media requests, and a mute preference should remain coherent after restart or orientation changes.

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.