# Shared acceptance checks

Each build receives this list before implementation. It defines observable behavior, not the architecture.

## Required checks

1. **Load and visuals.** Serve the folder locally and open it in a current desktop browser. There is no runtime exception. All game visuals are procedural points, lines, or polygons; there are no external visual assets.
2. **Normal gameplay.** The player can move in both directions, jump from a solid platform without unlimited mid-air repeats, aim after a viewport resize, and shoot each of the three moving targets. Hits produce articulated ragdolls. Hazard shapes are harmful and platforms are solid.
3. **Normal → Inversion with live state.** Fire at least ten bullets, then use Advance update before they all expire. Existing bullets remain in the room and begin curving toward screen right. Platform surfaces become harmful and former hazards become solid. Gravity pulls player and ragdolls right; the player can settle and jump away from a right-facing support. A mode switch does not embed the player in a newly solid surface or create an unavoidable immediate death.
4. **Inversion → Time Fracture with live state.** Kill at least one target and leave at least one bullet in flight, then advance. The preexisting bullet reverses from its current position exactly once. Targets stop moving; a previously dead target visibly reassembles and becomes hittable again after about two seconds. New bullets fly straight. Gravity points down and platform/hazard roles return to Normal.
5. **Time Fracture → Normal.** Advance again. Target movement resumes. The player, bullets, collisions, and UI agree on Normal's rules; no stale inversion or rewind state leaks into the new cycle.
6. **Natural timing.** Independently of debug controls, three successive mode changes occur at roughly 60, 120, and 180 seconds of active play, in the stated order. The cycle repeats.
7. **Recovery.** Die, restart ten times, and play again. Each restart resets mode, timer, targets, bullets, ragdolls, and controls. Releasing a movement or fire input while the window is unfocused must not leave it stuck on return.

## Evidence standard

Record PASS, FAIL, or NOT_RUN per check. A builder's statement or source review is not a browser PASS. For a failure, record exact input sequence, expected behavior, actual behavior, viewport, and console error if any. Use the same browser viewport and replay sequence for every build. A debug update must preserve world state; test the uninterrupted 180-second sequence separately. Record visual polish separately from functional results.