The question
When a message crosses a boundary, does it keep its meaning?
A shared world depends on many small agreements: which object a command names, how a number is represented, who owns a buffer, and when an old result must be refused. This instrument lets you examine those agreements in a real browser worker.
Open the observatoryUses JavaScript, WebAssembly and a browser worker. Everything runs locally in this tab; it does not connect to a game server.
One command. Several places to get it wrong.
Explanatory diagram. Open the instrument to observe the actual execution.
Three things to try
- Let the examples run. The instrument compares actual browser observations with independent expectations. A deliberate rejection can be the expected result.
- Transfer the supplied command. Choose “Transfer wire probe” and compare the sender’s buffer before and after. The transfer gives up the sending buffer; entering WebAssembly still involves a copy.
- Try the boundary checks. Choose “Run boundary checks” to examine unusual text inputs and a retained output while WebAssembly memory grows. You can also alter the hexadecimal frame and inspect the rejection.
What this lets us say
These are executable checks of a bounded contract foundation. The browser package and its expected results were preserved together from a passing build. The observations you see belong to this instrument and your current browser.
The instrument does not create a shared game world. It has no multiplayer authority, prediction, rendered bridge or graphics qualification. A well-formed command is not permission to perform an action. Those responsibilities need their own experiments.
If the instrument cannot start
The explanation on this page remains available without scripts. The executable page needs WebAssembly and worker support. A loading or execution error is a failed attempt in that browser; it does not establish a passing result. Use the journey’s first-contracts chapter to read the wider context.