Which parts of customer access can this animation illustrate, and which need real evidence?
Move pink UI nodes and cyan API nodes to intercept matching dots and squares in a 30-second, randomized game. A capture means a moving graphic entered a matching node’s 60-pixel radius. It is not a sale, API request, successful accessibility audit or prediction of agent-led commerce.
The page has no catalog, inventory, checkout, authentication, live customer traffic or agent integration. Randomness, viewport dimensions, animation frame rate and placement affect counts. Pixel motion and attraction do not model buyer intent, trust or conversion. Compare game runs as examples, not business readiness scores.
Agent spawn probability is elapsed time ÷ 30 × 0.9: it is 45% at 15 seconds and approaches 90% near the end. That describes each new random spawn, not 90% of the entire run. Under approximately uniform spawning, the time-average probability is about 45%; the observed mix varies. If 4 of 10 spawned agent squares are captured, the displayed agent capture rate is 40%.
A matching node captures a graphic only inside 60 pixels. From 60 to under 150 pixels, it adds velocity toward the node; inside 60 pixels a mismatched type does not capture it. Graphics spawn after accumulated ticker time exceeds 400 milliseconds, with at most one spawn per frame. Their position and velocity are random; movement uses pixels per frame, not a physical or commercial model.
The report records spawned and captured counts, node count and cumulative-stat snapshots at two-second elapsed-time boundaries, including the final state. Rates divide each captured count by its corresponding spawned count and round to whole percentages. Uncaptured graphics may leave the canvas, and the run ends even if graphics remain. The JSON does not contain node coordinates, individual customer trajectories or real orders.
W3C explains that a feature using dragging generally needs a single-pointer alternative without dragging, while keyboard accessibility is a separate requirement. A real storefront should let people complete the same buying task through the supported input methods, not merely show a colorful UI node. This demo adds center-placement buttons that can be clicked, tapped or keyboard-activated; canvas relocation still uses dragging and is not a complete accessibility implementation. W3C: Understanding Dragging Movements
OpenAPI 3.1 describes HTTP API capabilities in a format people and software can discover and understand. An API node in this game supplies no such definition or working endpoint. For an actual integration, examine the documented operations, request/response schemas, authentication, error behavior and authorized purchase workflow. A machine-readable description alone does not establish correct inventory, user permission, merchant trust or a completed purchase. OpenAPI Specification 3.1.0
Google’s Product guidance explains that structured product information can support richer search presentations, including price, availability, shipping and returns. It also says result enhancements are discretionary. For real product pages, keep the visible offer and machine-readable data aligned with the actual item and policies. The game contains no product data and cannot demonstrate search eligibility, ranking improvement or agent purchase conversion. Google Search: Product structured data
Reset and Play Again start a new random run with two default nodes and cleared counters, clock and spawn accumulator. You can drag nodes during a run, drag a dock type onto the canvas, or activate a dock button to add one at the center. The final mix shown is the observed share of spawned graphics, not the late-run spawn probability. Export retains that run’s cumulative stats locally; it is not a saved storefront configuration or reloadable test.
Single-pointer alternatives and their distinction from keyboard requirements.
HTTP interface discovery and capability descriptions, not conversion guarantees.
Product-information opportunities and discretionary result enhancements.