BUILD NOTE
A WordPress-hosted game should be checked like a public product, not only like a working upload. The editor can save a page successfully while the public route still has missing assets, narrow layout, cached scripts, or a canvas that only works on one device.
Practical note
The first test is the public URL in a fresh browser session. The page should show a recognizable title, a loading state, and the first game screen without requiring a download. If the route is meant to fetch a bundled runtime package, that package should stay in WordPress storage and the page should explain what is happening while it loads.
The second test is interaction. A game is not verified when the menu appears; it is verified when the player can start a run, use the main input, see feedback, and return or restart without the layout breaking. For Diligesker’s Lab, that means checking Netherguard after opening a clue flow and checking Block Smash after starting an actual arcade run.
The third test is documentation. The matching project page should mention current controls, known limitations, and a contact path for useful reports. A short update log entry should record visible changes so returning visitors can tell whether the public build has been reviewed recently.
Checklist
- Check the public route, not only the editor preview.
- Keep project notes aligned with visible game behavior.
- Record meaningful visible changes in the update log.