# Milestone 017 latency remediation report

## Baseline

Milestone 016 recorded an unsuitable local Wi-Fi tail: 100 HTTP requests had
7.5 ms minimum, 186.7 ms average, 508.0 ms p95, 713.3 ms p99, and 985.4 ms
maximum round-trip time. The available browser samples ranged from 19 to 548
ms for command acknowledgement and from 30 to 551 ms for an authoritative
painted view. ESP handler and send measurements were materially smaller during
the partial runs. The M016 project-owner-approved deviation records that the
remaining controlled runs could not be completed on that path.

## Browser remediation

The player now uses the centered avatar as a 96 by 96 CSS-pixel transparent
touch target. Pointer movement changes only a local avatar deflection capped at
28 CSS pixels. A 12-pixel dead zone, diagonal hysteresis, and a 360-to-170 ms
monotonic cadence resolve a cardinal movement intention without exceeding the
150 ms server cooldown.

The browser sends at most one move at a time. While that command awaits an
acknowledgement or error, changing drag direction replaces one local latest
intention. Release removes the unsent intention. Consequently a slow socket
cannot accumulate a client-side movement backlog. No browser code predicts a
maze position, collision result, inventory, visibility, timer, or outcome.

Each received projection is translated so its authoritative `self` cell is
directly below the fixed avatar. This replaces rectangle-centering, which could
put the fixed avatar over a wall when a visible projection reached a maze edge.
Drag displacement is measured from the pointer-down position rather than from
the edge of the transparent target, preventing an unintended move on touch.

## Required deployment-network remediation and retest

Do not use the M016 Wi-Fi path for latency acceptance. Place the ESP and both
test clients on the same dedicated 5 GHz access point or the ESP fallback AP,
with no WAN routing, captive portal, VPN, power-saving transition, or active
bulk traffic. Record access-point model/band/channel, client hardware,
browser/version, RSSI, device address, build identity, and viewport.

Repeat the M016 procedure for two players with zero observers and with four
observers. For each player, collect at least 200 accepted moves and export:

```js
window.maze32PlayerApp.pointerFeedbackSamples()
window.maze32PlayerApp.latencySamples()
```

Record p50, p95, p99, and maximum values separately for pointer feedback,
command acknowledgement, complete authoritative view, and painted
authoritative view. Capture `/diagnostics` before and after each run and 100
ICMP plus application/WebSocket round trips. The acceptance target remains
painted-update p95 at or below 100 ms, maximum at or below 150 ms, and no
accepted sample at or above 500 ms. Do not mark this report as a passing
device measurement until those controlled results exist.