Dangerous Dave platformer · hy4

We need build index.html self-contained. Need run browser inspect initial and console, brief checks. Need think design carefully, playable route reachable, physics, controls, restart states, hazards, enemy patrol, trophy exit feedback, procedural drawing.

Let's inspect cwd maybe empty.

Need write robust game. Need design level tile-based perhaps 40x20 at tile 32 or maybe canvas 960x576 (30x18). Need fit viewport perhaps responsive CSS canvas scaling, logical 960x576. Dangerous Dave inspired side/top? Traditional tile platformer with solid brick platforms, ladders? We'll make 2D side view platformer. Need one completable level with solid platforms, trophy, exit, fire/water hazards, patrol enemy. Route physically reachable. Need perhaps jumping and platforms. We need actually verify via browser automation; can expose debug state perhaps window.__game for testing. Use keyboard actions via browser tool. Need understand browser tool behavior (likely screenshot/inspect etc). We'll create game with clear HUD and controls. Need perhaps test movement/jump near start. Need gameplay route perhaps manageable. Need physics and collision robust.

Let's determine level design with coordinates logical perhaps 960x544 (30 cols x17 rows, tile 32). Canvas 960x544. Ground bottom row y=16*32=512 to 544. Need solid platforms and wall collision. Need hazards (fire and water), one enemy patrol, trophy, exit. Need route reachable. Need likely four "islands" with gaps water/fire. Design all platforms enough jump distances given physics.

Player size maybe 24x28, movement 3 px/frame, gravity 0.55, jump velocity -10.5 => max height v²/(2g)=100px = 3 tiles, hang time ~38 frames; horizontal travel ~114 px = 3.5 tiles. Can jump 3-4 tile gaps. Need safe. Use dt normalized to 60fps to be stable. Maybe speed 3.3, gravity .55, jump -11.2 => 114 pixel height, jump horizontal 130. We'll make platforms gap <=3 tiles. Need ground sections and water pools perhaps hazards occupying tiles at ground level; gaps with water hazard at bottom. Fire tiles on platforms. Solid tiles drawn brick. Need walls? "solid-wall collision" means collision with solid platforms from sides and bottom maybe ensure solid walls. Add vertical walls that must be jumped over, or platform structure. Need collision resolver that handles x and y separately. Need ensure can land on nearby solid surface. Starting area ground perhaps at x=64 and platforms. Need jump test near start, landing on nearby solid surface. We can have first solid platform around x~160 maybe at y=416. Player spawn x=60,y=480? Need grounded on ground at y=512. Jump near start could land on elevated platform if move right while holding jump. We should test via browser. Also need landing on nearby solid surface perhaps starting ground itself. Requirement checks likely automated/source review plus browser screenshots. Need visible trophy and exit. Ideally both in first viewport? Canvas maybe level wider than view with camera horizontally; that complicates identifying both initially. Could fit entire level in one screen at 960 width to have trophy and exit visibly identifiable. Make level 30 tiles = 960, all visible. Route from left to right with a few platforms. We can draw trophy around x~700 and exit x~890. Need all visible at initial state. Good.

Let's plan tile map 30x17 (TILE=32), logical 960x544. Need nice retro pixel styling, no external assets. Use CSS with center layout, dark background, border, HUD. Canvas can scale to width via CSS while logical fixed. Keyboard events on window prevent default for arrows/space.

Level:

Rows indices y pixel:
0=0
...
16=512 ground.

Ground base perhaps solid tiles all along row16 with some water gaps. But water hazard can be tile or zone in gaps. Better map:
- solid ground row16 across from columns 0..29, but water pools rendered as water tiles replacing some ground? If no solid under water, player falls into water. Could define hazards occupying bottom row voids. Need gaps with water at y=512-544 (hazard tile), no solid. Need cross via elevated platforms.
- fire hazards on ground / platforms, e.g. columns 11-12 at row15 (y480-512), perhaps need jump over.
- raised platforms at row13 (y416), etc.
- walls (solid vertical columns) with height 2-3 tiles. Need route jump over/around. Need ensure route physically reachable; can design with staircase platforms.

Maybe simplest: continuous ground row16 all columns, with water hazards as non-solid water tiles at row15 (a pool along surface? Need touching hazard triggers loss; could water in recessed gaps). Use gaps at x=8-10 and x=18-20, with water tiles at row16; elevated platforms straddle gaps. Fire patches on ground (hazard tiles row15) and can jump over. Enemy patrol on a long platform. Vertical solid wall perhaps at x=14 from rows13-15, height 3 (96 px) must jump from a raised platform? Need route physically reachable via step platforms. But perhaps avoid hard wall. Solid-wall collision can be tested against side of raised blocks. Need platform edges. Need route physically possible without precise sequence. Could make broad continuous ground and raised solid platforms that don't block path, with walls on upper optional path? But "solid-wall collision" generic requirement means collisions with solid platforms including walls. We can include wall structures that are obstacles but route around via jumps.

Let's formulate using E/W or coordinate map. Want route across larger map with trophy placed on elevated platform near right and exit at ground far right. Need trophy collect before exit. Need ensure physically reachable. Could place trophy at ground midway and exit to right; simplest. But then hazards/enemy and platforms need route. Add trophy on elevated platform maybe enough. Need perhaps trophy can be collected by walking. Let's make route perhaps:
- ground row16 from x cols 0-7, then water gap cols 8-10 (96px), then ground cols 11-17, water gap cols18-20, ground cols21-29.
- platforms at row13 (y416) over water gaps: cols7-11 (x224..384) and cols17-21 (x544..672), allowing cross. But from ground y512 to platform y416 = 96px (3 tiles), max jump 114 px; can jump onto it from edge if horizontal speed. Need player's feet from ground at512; platform top416, difference96, within. Solid platform side at x224 can obstruct if player approaches; need jump from x~200, height to reach top. Good. We can make platform at row14 (y448) (2 tiles up =64) easier, with bridges spanning gaps. Let's use row14 platforms:
  - bridge A cols6-12: x192..416, top448. Access from ground near x160 with jump (height64). It extends across water gap cols8-10. There may be a fire on bridge? Need ensure route. At x~384, step/jump down to ground after gap but ground begins col11 (x352), so from bridge can simply drop onto ground at x352 or continue. Great.
  - bridge B cols16-22: x512..704, top448, water gap18-20 (x576..672), then ground begins col21. Similar.
- enemy patrols on ground around x=420..500 (cols13-15); need jump over enemy. Or on a raised platform. Patrol can touch kill. Need route possible. Put enemy on ground between bridge A and B, x430-500. Need jump over from left; can use bridge A extension to x416 to drop maybe near enemy; too hard? Make patrol only 60px region x430-490 and player jump over from x390 with jump. Fine.
- fire hazard at row15 (y480) covering cols14-15 maybe x448-512, which would be between enemy and bridge B; need jump over fire from x416 to x544 (128px), maybe max jump ~135; with raised platform at x512 top448, can land. Need careful.
- water at bottom gaps, touching water triggers death.
- vertical wall maybe at x=22, rows13-15? But bridge B top row14 and wall could conflict. Let's design "wall" column at x=24 maybe rows13-15 (y416..512), height3 tiles. To pass, need jump from an elevated platform on left to another top? Could make wall at col24 from row14-15 (64px tall) and platform at row12 y384 on left; need jump over. But max height114, can jump from ground to top of 64px wall easily. Player horizontal collision with side. Need perhaps wall top is solid and can land on it, then jump down. Put a 2-tile-high wall at col24 (x768) from rows14-15 (y448..512), with top at448. Starting from ground y512, jump 64px; can land on top. But while moving right horizontally, collision logic might stop at side until above top, then pass; works. We can also have a raised platform at row13 perhaps y416 near x704 to help. Need not overcomplicate. Exit at col28 ground x896, y480? Door from y448 to512, visible at right. Trophy perhaps at col25-26 on elevated platform? Need collect before exit. Good.

Maybe use a consistent tile map encoded as strings. Define solid tiles "B" (brick), maybe "S" stone, "X" wall? Need all procedural. Could define grid arrays of chars:
- 17 rows each 30 chars.
- B solid brick, maybe G different solid? We can just use "#".
- "." empty.
- water "~" at gaps row16; fire "^" maybe row15; enemy "E" spawn; trophy "T"; exit "D"; player "P". We can parse entities then not solid. Need ensure string lengths. Could instead define programmatic arrays via rectangles, simpler and less error-prone, plus draw based on lists. "tile-based" would be stronger if actual grid map. Use 2D array of 17 strings, parse each char. Need count 30. We can make from arrays with padding via `.padEnd(30,'.')` so no need exact lengths, but visibility. Use coordinate-based with map generated programmatically from rects into grid, plus explicit hazards. Could still be a tile map: `grid[row][col]`; fill solid from rectangular definitions; water/fire cells. Then parse. Easier avoid string length bugs. But a literal map is readable. Need likely include level objects. Let's design exact map maybe can write one with rows of 30 chars and verify via script.

Could use map strings with exactly 30 chars. Let's lay out coordinate columns 0..29. Need maybe row indices 0-16. Canvas 960x544. Let's draw sky background; lower part maybe underground style. Entities:
P at row15 col2 (x64,y480 feet512)
T at row13? col22 maybe x704,y416? Need accessible.
D at row14-15 col28 perhaps door 2 tiles tall, but entity stored one coordinate and drawn 2 tiles high.
E at row15 col13? Need patrol range.
Fires "^" at row15 positions; water "~" row16 gaps.
Solid "#" for ground row16 except gaps; platform row14 bridges; walls etc. Need row15 fire standing on ground. But if ground row16 solid, player center/feet at y512; hazard row15 y480-512 overlaps player's body (player height28 from y484 to512), so touching fire. Good.
Water row16 y512-544; if player falls into gap, feet can reach >512 and overlaps water. Good.
Solid bridge row14 y448-480; player can stand top at448. Need if platform side blocks from ground; jump height114 gets feet to398; enough. Need collide with underside if jumping from below; that's okay but perhaps can use route from left at x<192 to jump onto bridge. The bridge starts col6=192; ground up to col7? Let's pick water gap cols8-10 (x256-352), ground cols0-7 (through x256) and cols11-29 except gap18-20. Platform A at row14 cols6-12 (x192-416). This means from ground x160, jump right; player's x ~160.. maybe gets blocked by bridge side at x192 unless feet above448. Need jump rise64 needs about 7-8 frames, horizontal ~24px, so from x160 you'll reach x192 around 10 frames, enough. Need press Right+Space simultaneously; works. But can also start under bridge and jump into underside, blocked; then moving right won't reach top. Need perhaps platform A begins at col7=224, accessible from x192 with enough run-up. Or bridge could be at row13 y416 (96px high) and platform side risk. Better make bridge at row14 and give a smaller step platform at row15 (y480) leading up? A 1-tile high platform (solid row15) from cols5-6, then bridge row14 cols7-12. Player can jump onto step easily then bridge. But then that step may act as wall; manageable. Could make start bridge from col7 with a 1-tile stair at col5-6. Need map.

Alternative: no need to use bridge to cross water if gap <=3 tiles can just jump across from ground to ground: from x250 to x352, horizontal102px, jump travel ~130. That route is straightforward. Then elevated platform is optional. Water gap 3 tiles. Could jump from left ground edge to right ground. That ensures physically reachable. Put bridges perhaps above for visual and land check. But hazards/fire and enemy can be jumped too. We can place solid platforms spanning gaps higher, but player can just leap gap from ground; need ensure jump enough. With speed3.6 and gravity0.55/jump-11.2, airtime ~40 frames -> horizontal144 px. Gap 96, player width24 means needed ~120 from takeoff x248 to landing x344, feasible. Great. So route can simply jump water gaps. Need perhaps bridge at row13 y416 with width across gap, gives a landing surface if jumping from a higher step; not necessary. We can add lower platform at row14 y448 extending slightly into gap to make easier. But could block direct jump due underside? If platform at row14 y448 spanning gap, player jumping from ground could collide underside at y448 (player top starts y484; jumping upward loses34px before top hits448, so can't reach full jump height); side collision might block crossing under it. That could make route impossible unless land on platform. Need careful. Avoid overhead slab across entire gap, or make platforms one tile wide (stepping stones) that can be landed on. So perhaps use small floating solid platforms above gaps at row14, e.g. cols9-10 (x288..352) spanning two tiles. Player jumps from ground x240; can land on top y448 (64px rise), then jump to right ground x352. This is intuitive. There is still potential to hit underside, but from left edge could jump early and land atop. Need platform starts at x288, 1 tile into gap; player horizontal from x240 reaches x288 after 13 frames, by then feet at maybe 512-11.2*13+.275*169 ~413, above448; can land. Good. Need right edge platform x352, right ground starts x352; can simply walk off onto ground. Nice.

Let's design route with stepping stones:
- Ground row16 solid cols0..7 (x0-256), gap water cols8..10 (x256-352), ground cols11..17 (x352-576), gap water cols18..20 (x576-672), ground cols21..29 (x672-960).
- Floating solid platform row14 or row15? row14 y448, cols9-10 (x288-352) and cols19-20 (x608-672). Top448. Player can jump onto from ground. Need no overhead collision if starts from left edge: platform starts32px into gap; good.
- Fire hazards row15 on ground at cols14-15 (x448-512) and maybe cols23-24 (x736-800). Need jump over. Width64, jump horizontal ~140; fine. Can jump from x416 to x544 on ground, maybe need clearance horizontally ~64+player width24=88; feasible. Need enemy patrol around cols12-13 maybe x384-448; combined with fire could create one long obstacle from x384-512 (128px), still feasible but tight. Separate enemy: enemy patrol on elevated platform maybe to avoid route complexity. Place enemy on a long upper platform at row12 cols12-16 (x384..544, y384) and optional route? Trophy could be there requiring encounter? We want at least one patrolling enemy affecting player. Could put enemy on ground region cols12-13 with patrol range x390..430 (40 px), then fire at cols15-16. Gap between. Player can jump over enemy, land, then jump fire. Manageable but tricky. Need route physically reachable; can give enemy patrol on upper platform that can be avoided by staying ground. But "touching a hazard or enemy causes loss" still testable. Fine. Put enemy on a raised platform at row12? Need player can't touch incidental. Maybe enemy patrols on ground near start in a short zone, and player can jump over. Good.

Need trophy and exit visibly identifiable. Could put trophy around x720 on raised platform row13, and exit at x900. To collect trophy, perhaps just walk along ground near x720 where trophy at row15 y480 (center y496) and player body overlaps; that's easy. Exit drawn at x896,y448-512. Trophy at x720,y456 maybe. Need not have elevated platform. Place trophy at row14 col23 (x736,y448) perhaps a floating platform at row15 col23 under it? Or just floating collectible, drawn cup with glow. Player can collect by jumping to it. Could have trophy at ground row15 col22 (x704) and exit at x896, making route straightforward. We can draw large cup 28x28 centered in tile with gold sparkle. Need visually identifiable from screenshot. Add HUD "TROPHY: NEEDED" / "TROPHY: COLLECTED" and maybe label arrows? Could draw a golden cup and "TROPHY" text near it on canvas; procedural. Exit as bright green door with "EXIT" sign. Need visible feedback when reaching exit without trophy: a red banner at top of canvas and HUD status "NEED THE TROPHY!" while level remains active. Need trigger collision with exit each frame; show feedback for maybe 2.5 seconds and maybe nudge player left to avoid repeated retrigger. Could simply display persistent warning while in exit area and no trophy. Need keep active. Could show overlay floating message "TROPHY REQUIRED!" near door and HUD. Need avoid win. Once trophy collected then touching exit wins.

Need win/loss states with overlay and Restart button. Restart during play via visible button and maybe R key. Need perhaps restart after win/loss. Button should stay accessible, maybe HTML button above canvas. Also stage overlay with "You Win"/"Oops!" and a restart button inside overlay. Requirement "Provide Restart after either outcome and during play." Having a persistent HTML Restart button satisfies all; overlay can also have button. Need maybe canvas pointer interactions? We'll make persistent button; also key R. On game over, show dark translucent canvas overlay with state and "Press R or Restart". Need maybe button in DOM is available. Could have single `<button id=restartBtn>` labeled "Restart Level (R)" and overlay with button id=overlayRestart; both call restart. Good.

Need physics with gravity, landing, solid-wall collision; jumping only grounded. Use fixed timestep perhaps requestAnimationFrame with accumulator. Need browser testing with keyboard events. Need provide debug object `window.__platformer` for inspection, maybe getState(), maybe warp? Could use for automated testing but need actual checks via keyboard. The browser tool likely can `key` press and `inspect`, screenshot. Need know exact semantics perhaps press key text. We'll try. We can expose state for inspecting. Need perhaps no external calls.

Let's design exact code.

HTML:
```
<!DOCTYPE html>
<html lang=en>
<head>...
<style>
:root ...
body { margin:0; min-height:100vh; background...; color...; font-family:...; display:flex; ...}
.game-shell { width:min(100vw - 24px, 1000px); }
header ... 
.hud {display:flex; ...}
canvas {width:100%; aspect-ratio:960/544; image-rendering:pixelated; border...; display:block; background:#10182e;}
.controls ...
button...
.overlay maybe DOM overlays easier than canvas? Need show state overlay inside stage. Could use absolute div. But canvas drawn game states with overlay is fine. Use DOM overlay maybe easier verify. Need no network.
#messageBanner maybe top HUD status.
</style>
</head>
<body>
<div class=shell>
<h1>DAVE-STYLE DASH</h1>
<div class=topbar><div id=status>...</div><button ...>↻ Restart (R)</button></div>
<div class=canvasWrap><canvas id=game width=960 height=544 aria-label=...></canvas><div id=overlay hidden>...button...</div></div>
<div class=help>←/→ or A/D ... | Space jump | R restart ...</div>
<div class=legend ... icons? use text spans with CSS colored blocks maybe no emoji? External none. "Gold cup = trophy"; "Green door = exit"; etc.
</div>
<script>...
```
Need use no external fonts; system monospace. Could use Unicode emojis? Procedural drawing requirement everything game drawn procedurally; UI text okay. Avoid emoji maybe use simple chars; canvas graphics drawn with shapes. Buttons use text.

Draw background:
- dark blue gradient from #1a2a4a to #0b1024.
- stars deterministic positions (seeded array) maybe not externally.
- distant mountains/pixel clouds. tile-based brick.
- maybe checkerboard cave.
- solid tiles: brick pattern with mortar, highlight, random variation based on tile coords deterministic. Tiles at row16 ground etc.
- floating platforms have stone/metal style with golden top edge.
- water tiles at row16: animated waves using sin(t), blue fill with highlights, bubbles; hazard.
- fire at row15: animated flame shapes, orange/red with glow; hazard.
- trophy: gold cup shape with handles, stem, base, shine and "TROPHY" label; need maybe bob animation. Draw at x=?.
- exit: green arched door with frame, sign "EXIT", perhaps lock state red/green depending trophy. Need visibly identifiable. If trophy not collected, door red-ish? But requirement exit visible; use green door with a red "LOCKED" strip maybe. Draw sign "EXIT" above. If collected, glows gold/green.
- enemy: red/purple creature with eyes/feet, patrol bobbing. Need direction and animation. Draw procedurally.
- player: small adventurer (Dangerous Dave-inspired but not copying exact) with cap, shirt, skin, boots; direction; eyes. Need draw with rectangles. Could use simple pixel art via ctx.fillRect.
- particle feedback maybe optional.
- status HUD in DOM or canvas top bar: `state`, trophy status, "Need the trophy" warning. We can draw top overlay inside canvas with level title and status. Requirement display controls; DOM help does. Could also draw small "TROPHY REQUIRED" near door when touched. Need visible feedback. Side panel perhaps topbar status.

Physics:
Constants: W=960,H=544,TILE=32, GRAVITY=0.58, MAX_FALL=13, MOVE=3.4, JUMP=11.6, maybe Coyote? jumping only grounded; no coyote to be literal. Need robust collision.

Player `w=22,h=28`, spawn x=64, y=512-28=484. `vx`, `vy`, grounded. Input object. On keydown:
- ArrowLeft/KeyA -> left
- ArrowRight/KeyD -> right
- Space -> `jumpQueued = true` if !repeat? Need prove jumping only while grounded. In update:
```
if (input.jump && player.grounded && state==='playing') { player.vy=-JUMP; player.grounded=false; input.jump=false; }
```
Could hold Space and auto-jump on landing; maybe undesirable. Use keydown set `jumpPressed=true`; consume on update regardless; implementing with `jumpQueued=false` after processing. If player in air, queued should be consumed (not buffered) so no jump. Good.
- `keys` set by event.code. Need track keydown and keyup; on Space preventDefault. On keydown if code R restart. On keyup delete.
- browser tool `key` perhaps sends one keydown+keyup quickly; if jumpQueued set on keydown, update sees it. Good.
- Pointer/touch controls? Not required. Could optionally add on-screen buttons? But no need. However browser testing can use keyboard.
- Restart button click.

Update fixed step:
```
function step() {
 if state !== playing { maybe update animation only; return; }
 if jumpQueued { if grounded ...; jumpQueued=false; }
 let ax based on keys; player.vx = dir*MOVE;
 player.vy = Math.min(player.vy+GRAVITY, MAX_FALL);
 moveX(player, player.vx);
 moveY(player, player.vy);
 // friction? direct.
 // enemy update independent (even play only)
 // hazards collision AABB with water/fire rects; enemy AABB
 // trophy rect; exit rect
 // bounds
}
```
Need order maybe x then y. collision with solid tiles:
```
function solidsOverlapping(box) { determine tile range floor(x/TILE).. floor((x+w-1)/TILE), etc; if grid[r][c]==='#' return...}
function moveX(ent, dx) {
 ent.x += dx;
 for each tile overlapping ... if solid:
   if dx>0 ent.x = c*TILE - ent.w;
   else ent.x = (c+1)*TILE;
   ent.vx=0; // maybe
}
function moveY(ent, dy) {
 ent.y += dy;
 ent.grounded=false;
 for each overlapping solid:
   if dy>0: ent.y = r*TILE - ent.h; ent.vy=0; grounded=true;
   else if dy<0: ent.y=(r+1)*TILE; ent.vy=0;
}
```
Potential issue when grounded and vy=gravity each step: moveY (0.58) overlaps ground by 0.58, resolves and grounded=true. Fine. Need if x moves into wall; collisions. Need multi-tile collision loops; after setting ent.x, need recompute overlapping tiles for each collision perhaps one loop and break? A single tile often enough; can loop through all overlapping tiles, but if first is not solid and second is, still gets resolved. Could compute candidate tile range before/after. Simpler:
```
const x1=Math.floor(ent.x/T), x2=Math.floor((ent.x+w-1)/T)
const y1=Math.floor(ent.y/T), y2=Math.floor((ent.y+h-1)/T)
for r... for c... if solid:
 if(dx>0) ent.x=Math.min(ent.x, c*T - ent.w)
 else ent.x=Math.max(...)
```
This handles. Since setting x changes overlap but we only need first side tile; using min/max over all works. Likewise y set min/max. Need check only after movement. Need avoid tunneling at high speed; max13<TILE32 so fine.
- Need bottom bounds: if y>H+50, loss perhaps "Fell into the pit!" (but water should catch first).
- Need top bound maybe clamp y≥0.
- Solid tiles include ground and floating platforms and walls, all grid.
- Need "solid-wall collision" perhaps can include vertical wall blocks at col26 rows14-15? Need design and test. Could add walls that are clearly drawn and require jumping. Need make route around. Let's decide level route more concretely.

Map entities:
- Ground solid row16 all cols except 8,9,10 and 18,19,20. Those gap cells water hazard.
- floating platform "stepping stone" at row14? Let's use row14 top y448. Place solids at:
  - cols9,10 (x288..352) (first gap)
  - cols19,20 (x608..672) (second)
  - maybe start area "nearby solid surface" elevated at cols4-6 row13 (x128..224, y416) too high 96 from ground but reachable. Or row14 cols4-5 (x128..192,y448), accessible easily for jump test.
  - maybe upper platform at cols12-16 row12 (y384), connected via steps? Could hold enemy patrol, but not required route. Put enemy on ground.
- wall at col25 (x800), rows14,15 (y448..512) 2 tiles high, top y448. Need can jump onto top from ground x~736 (64px rise), then hop down to right. But fire might be near wall. Maybe wall at col25 rows15 only (1 tile high) makes easily step/jump and clearly collision. We need "solid-wall collision" physically collision with vertical sides; any solid tile side qualifies. The wall could be 2 tiles high. Need route from left to right: from ground y512, jump from x760; top of wall y448, diff64; can land on top x800..832; then move right and drop to ground x832 onward. Player width22; collision logic when jumping toward wall: at frame when feet below448 (y>420? Wait player top = feet-28; feet if y coord top? use y top; standing top484, feet512. To clear wall top448, player's bottom must <=448, i.e., y<=420; jump height needed64. At ~7 frames, vy ~-7.5, displacement~ -67, bottom445; enough. Horizontal from x760 at 3.4*7=24 reaches x784, side at800 after12 frames. By then bottom~512-11.6*12+0.29*144=414, above448, so can pass. Good. It might land on top around x800 at ~? gravity; top wall from y448. Need jump arc: bottom positions (relative): 500,489,478,468,458,449,441,433,... wait solve t=6: 512-69.6+10.44=452.8; t=7:512-81.2+14.21=445; so above448 at t7. At x760+23.8=784, player right edge806, collision side at x800 occurs at t~? Need initial right784? Let's set x=752 maybe. At t7 x776, right798; at t8 x779, right801 >800, side collision until bottom<=448. At t8 bottom438 (yes), so no overlap with wall row14? wall occupies y448..512, player bottom438, no overlap; passes. Then descending, at t? bottom448 again around t30 maybe; by then x~854, past wall x800-832, so might land on ground right side. Fine. If x starts 740, at t8 right~789, no collision; at t10 x774? Actually 740+34=774+22=796; t11 right800; by then bottom maybe424; can pass. Descending later x~850 >832, land ground. Could even jump over wall entirely. Great. Need perhaps trophy before wall. Put trophy at col23 (x736), ground row15; collect before wall. Exit at col28 (x896), ground row15/14. Then playing route:
  - Start x64 ground. Jump over small platform? 
  - First water gap x256-352: can jump from x230 reaching x~370 over ~40 frames, land ground at x352. Need speed3.4*40=136, from x230 to366, player width22; feasible but tight. Floating stone at x288-352 lets land midair. Need perhaps use platform to cross.
  - enemy around x400-440 on ground. Jump over.
  - fire at x480-512 (1 or 2 cells). Jump over.
  - second water gap x576-672: jump from x550 to x686 (136), feasible; stepping stone x608-672 helps.
  - wall at x800, jump over.
  - trophy at x736? Need collect before wall. It is on ground after second gap. Could walk into. Need maybe fire around x720 making trophy tricky. Add fire at col23? We can place trophy on a raised ledge to ensure jumping. But no need. Need fire and water hazard at least one each. We have water gaps and fire row15. Need maybe fire at cols15-16 (x480..544) and col22? Could be too much. Keep one fire patch.
  - Wall at col25 x800; trophy at col23 x736; exit at col28.
  - Patrol enemy perhaps at x400-450, on ground. Need jump over. Need not overlap fire. Place fire at cols16-17 x512-576 just before second gap. But water starts x576, so have fire contiguous with water; jump from x480 over fire (64) and maybe land near x576 edge/water—need jump across both fire (64) and water (96) =160 plus player width, impossible with max144. Need put fire earlier: cols13-14 x416-480, then ground to x576 gives room to land around x500, then jump water. Enemy could patrol at x368-400 just after first gap, then fire at x448-480. Need jump enemy, then fire, but can do separate. Or put enemy on elevated platform to avoid obstacle. Let's simplify:
  - Enemy patrol ground x380-430 (range 50). Can jump over from x350 to x460.
  - Fire at cols15-16 (x480-544), width64. Can jump from x448 to x576, but right edge x576 is water start. Need land before x576, e.g. x548; total from x448 to x548=100, feasible but need clear fire x480-544 and player width22, so need left edge >544 at landing, around x548. At descending to ground ~40 frames from x448 gives x584 (water), too far if holding right continuously; can release and slow? Direct vx no inertia, can stop horizontal midair at x550 and drop onto ground before x576. Fine but tricky. Could instead fire only one tile x480-512 and ground x512-576 landing area. Then easy. Make fire cols15 (x480..512), one flame tile, or 2 tile patch with a solid small platform to land after. Better one tile is enough to be visible. Maybe fire row15 cols15-16 but floating solid platform above at row13 to land and then step down onto ground after? Hmm.
  - Let's place fire at cols14-15 (x448..512), then ground x512..576 2 tiles safe. Need jump from x416 to x520, 104px; feasible. Enemy patrol on elevated platform, not ground, to avoid consecutive obstacle.
  - Enemy patrol on a long floating platform at row12 cols11-16 (x352..544,y384) with enemy range x384..480. Player on ground doesn't touch it unless jumping high; visually there. But "touching an enemy causes loss" can still happen if player jumps onto platform; and patrol is visible. Need at least one patrolling enemy. This is okay. Yet tends to be irrelevant to route; still required behavior exists. Could place enemy on ground after all obstacles near x700-750 and can jump over; maybe route still okay. Need no coincidence with trophy. Could place enemy on ground x690..740 and trophy above at x736 to collect by jumping over enemy? Fun. But could be difficult. Better simple enemy patrol on ground near start x160..220 so player must jump over early, and platform for jump test nearby. Need route can jump over it easily (range50). Place elevated enemy on platform maybe no need.

Let's analyze route with a patrolling enemy on ground between water gaps:
- First water gap ends ground x352. Enemy patrols x384..432, width24. Player lands from gap around x360 and can stop before enemy. Jump from x360, horizontal max136, land x496. Fire at x448..512 would overlap landing; shift fire to x512..544 one tile. Then jump from x360 over enemy to x470; fire at x512..544; can do second jump from x470 to x570 but water starts576; land x560 maybe by controlling. One-tile fire at512-544 can be jumped from x480 to x560 (80px). Fine.
- second water gap x576..672; from x560 need jump to x700, 140px; max horizontal if full airtime ~136 plus width maybe player left x560 to x696, right718 >672 and ground starts672, so can land at x696 if descending. Actually need only left >672 by landing, displacement112; feasible. Stepping stone helps.
- Then trophy x736 (ground), wall x800, exit x896.

Need enemy could move unpredictably and kill while jumping; but can jump over. Patrol range x380-430, enemy w24. Player jump from x360 to x496; at early ascent enemy maybe x380-430; player's bottom above enemy top (enemy top maybe484, height28), need 28px lift; after3 frames, bottom~480, could overlap at x370; if enemy x380, player's right392 >380, could collide while not high enough yet. Need start jump from x340 perhaps after water crossing, but need land from gap. Could use stepping stone at x288..352 then jump from x330 to enemy; still close. Better enemy patrol on a raised platform above main route; no accidental collision. Or make enemy range x680..730 after water gap, with trophy at x736; player can jump over enemy to trophy, but same issue. Could patrol on a narrow elevated ledge, requiring optional interaction; safer route.

I think put enemy on a floating platform at y384 (row12) from cols11-16 (x352..544), with patrol across platform x384..510. This is visually clear and does not block ground route. Need "touching an enemy causes loss" — yes if player reaches platform. Could test by debug teleport maybe not necessary. We can include platform route reachable via stacked blocks:
- ground y512
- platform row14 y448 at cols12-13 maybe
- upper platform row12 y384 at cols11-16. Jump from row14 platform to row12 (64px) and enemy there. Optional. But we can place enemy patrol on row14 platform y448 instead, where foot top448; player might land on it from ground. Put a long isolated platform at row13 cols12-16 (y416) with enemy. Need player can jump to it (96px rise) but not necessary. Fine.
- Or make enemy patrol on a high bridge spanning first gap, with route crossing below via gaps? Need no overhead blocking jump. Put enemy platform at row11 (y352) cols8-13; too high to interfere. Visually still enemy, but perhaps not meaningful. Requirements don't demand enemy be unavoidable. At least one patrolling enemy. Let's put it on a floating ledge at row13 cols11-16 (x352..544,y416). Enemy stands y388..416; patrol x384..500. This ledge is solid and can be reached from ground (96px climb, within max jump114) from left side x320 or below; but side collision may need careful. Could add a step at row14 cols10-11 (x320..384,y448), then jump to row13 ledge. However first water gap has stepping stone at x288..352 row14, which can serve as step; from it y448 (feet448) jump to ledge y416 difference32 and move right, easy. Thus upper route reachable. Enemy patrols there. Ground route below may have fire; the ledge offers alternate.

Need maybe too many solids over first/second gaps cause underside collisions. Let's map:
- Gap1 x256..352, stepping stone row14 x288..352 (top448).
- Upper enemy ledge row13 cols11..16 (x352..544,y416), starts exactly where ground resumes. Its underside y448 above ground y512, clearance64; player height28, can walk under it on ground with top484 >448? Wait row13 spans y416..448; player on ground top484, so clearance from y448 to484=36, enough, no overlap. Good. jumping from ground below ledge will hit underside, but can cross gaps via stepping stone on left or simply jump from x230 to x366 perhaps ledge begins x352 y416..448; during jump at x352 player might be at high y~400 with body overlapping ledge side, could collide. Could make grounded route over gap via stone and then drop under ledge to ground. Need perhaps no overhead ledge covering landing zone. Ledge x352..544; from stone x288..352 at y448, the player can walk right onto ledge? Ledge top416, one tile higher, need jump from stone (feet448) to top416 32px. Fine. But then enemy there. Could instead go down from stone to ground at x352; ledge overhead at y416-448 means stone row14 y448-480 ending at x352. At x352 begins ground row16 y512, but ledge row13 y416-448 leaves gap y448-512; player height28 fits. Need walk off stone right edge at x352 with feet448, fall to ground feet512; no collision with ledge if player's x>=352 and top at420? Wait at feet448, player top420; ledge row13 y416-448, so player's body y420-448 overlaps ledge if x enters x352—side collision prevents moving right until player falls enough that top>=448 (feet>=476). On stone, if move right off edge, x can move because stone ends x352; but ledge begins x352 at y416-448 and will collide from side while player's top420-448. Need wait falling; with direct x velocity, collision stops at x330 until top>=448, then can move right and land ground. That's okay, but maybe awkward. Could put upper ledge starting x384 leaving room to fall from stone at x352 to ground before x384. Good. Let's set ledge cols12-16 = x384..544, row13 y416. Enemy patrol x400..500. Step from stone x288..352 to ledge? Gap32 and height32; jump from x330 can clear side onto ledge x384; feasible. Ground route: from stone end x352 fall to ground at x352-576, ledge starts384 overhead; player can land at x360 before ledge, then walk underneath because top484>448 clearance. Great. This works.
- Fire on ground row15 cols15-16 (x480..544) under ledge; upper ledge overhead means jumping from ground under it will hit underside; but player can jump over fire horizontally? Need 64px patch while under ledge. However jumping from ground at x448 (top484) hits underside y448 after ~34px rise, limiting jump height; can still clear fire because fire top480, player's bottom needs <=480 at apex, only32px rise needed; underside limits to feet448 so enough. It can jump over fire with a short hop while ceiling prevents high arc; horizontal travel while enough height maybe 20 frames, enough ~68px. Could work but tricky. Maybe place fire before upper ledge starts, e.g. cols10-11 x320..384. But first gap ground resumes x352; fire at x352..384 just before ledge. Enemy ledge starts x384, no overhead during fire jump. Need jump from x320 (over water?) to x400; tricky. Or place fire after ledge, at cols17-18 (x544..608) but x576-608 is water gap, hazard overlap. Could set fire at cols16-17 x512..576 (2 tiles) and water starts576. Need jump from x480 to x576, landing at start of water impossible; stepping stone at x608..672 top448 could catch, but horizontal need128 to x608, maybe possible if jump from x480; plus ceiling ledge ends x544 overhead. Could jump from ledge itself to second stone; nice route. Ground route might be impossible across fire + water combined. Need ensure simple route. Could place fire on a decorative tile above ground on a solid platform or as a vertical flame that can be jumped with enough space after. We can adjust water gaps positions.

Maybe avoid overhead platforms near fire entirely. Put enemy on a high isolated ledge in first section, fire in middle area, water gaps before/after with enough safe zones.

Let's step back and design a clean, definitely reachable ground-level route:
- Continuous ground with two water gaps of 2 tiles rather than3. Jump max ~140, easy.
- Small stepping platforms above gaps but not overhead blocking direct jump (place them at row15? If row15 y480 top, one tile above ground, stepping stone in gap; can jump onto from ground and drop; still side collision but manageable).
- Fire patches of 1 tile on ground with at least 2 safe tiles before/after.
- Enemy patrol on a floating ledge high above, not obstructing ground path, but reachable via optional platform (or at least on a platform). Vertical wall at right with plenty run-up.
- Trophy on ground before wall; exit after wall.
No need force use of elevated platforms. Need keep "solid platforms" plural—ground and floating ledges/stepping stones. Need "solid-wall collision" via wall and platform edges.

Coordinates:
- Ground row16 solid all cols except water gaps:
  gap1 cols8-9 = x256-320 (64px), water row16.
  gap2 cols18-19 = x576-640 (64px), water row16.
  Ground resumes x320 and x640. Easy jump across with max140.
- Stepping stone above gap1 at row14 cols8-9? top448, x256-320. But this is directly overhead at start of gap; jumping from ground x224 might hit underside. Better place at row14 col9 only x288-320, allowing jump from x224 to x288 when high enough. But still can just jump gap. Need perhaps not have overhead across gap at all; place floating platforms in decorative upper areas not over direct route:
  - platform row13 cols3-6 x96-224, y416 (near start, can jump onto; but 96px height from ground and side at x96 near spawn; need run-up from x64; reachable). This provides nearby solid surface for jump test but might be hard.
  - platform row14 cols4-6 x128-224,y448 (64px high), easier. Start x32? Need spawn x48 maybe; can run to x96 then jump onto platform x128. Good.
  - enemy patrol ledge row12 cols12-16 x384-544,y384, high enough not to interfere with ground jump; need optional steps to reach it. Add row14 platform cols11-12 x352-416,y448; from there jump to row12 ledge (64px up). But row12 y384, step top448 diff64; fine. Need side x384; can jump from x352 platform to ledge. This ledge is 128px above ground? top384, diff128 > max114, can't from ground, but from step yes. Good. Enemy patrol there.
  - fire row15 cols14-15 x448-512 under ledge? Ledge y384-416, plenty ceiling, no interference. Fire top480; can jump. Good.
  - second gap x576-640 with stepping platform maybe row14 cols18-19 x576-640 overhead; would block direct jump. Don't include. Could have decorative floating platform row13 cols20-22 x640-704,y416 after gap, not overhead. Fine.
  - wall col25 x800 rows14-15 y448-512; can jump over. Need fire maybe also at cols22-23 x704-768 before trophy? Too much. Keep one fire patch.
  - trophy at col23 x736-ish row15, ground.
  - wall col25 x800.
  - exit at col28 x896 row14-15.
  - Maybe wall can be climbed via a small platform row14 cols24 x768-800,y448; player can jump from ground onto it (64px), then onto wall top y448; but wall top also448, making easy. Could include to help. However step platform adjacent to wall and same height might make wall route trivial and side collision clear. Fine. Need perhaps wall at col25 rows13-15 (3 tiles, top416) requiring step from platform row14 (top448) jump32 onto top; visually more substantial. But simple jump from ground to top416 requires96px rise, within max114; could work. Could make wall 2 tiles to ensure easy.
- Need trophy perhaps at col23 x736, wall at col25 x800; exit col28 x896. Good.

Let's calculate jump physics carefully with fixed step. Use normalized dt=1 at 60fps. Gravity0.55, jump velocity -11.5. Max height = 11.5²/(1.1)=120px. Airtime to return same ground = 2*11.5/0.55≈41.8 frames; horizontal speed3.6 ->150px. Easy gaps64 + width22 =86. Fire width64 + width22=86. Wall width32 and height64; easy. Starting platform row14 top448 diff64; reachable. Upper ledge row12 top384 from step448 diff64; reachable. Nice.

Potential collision with stepping platform/ledge while jumping over ground hazards: don't place low ceiling directly over hazards. Start platform row14 x128-224 maybe not over water gap. Fine. Step platform x352-416 row14 over ground, but first gap ends320; safe. Enemy ledge y384-416 x384-544, no ceiling issue. Fire x448-512 below ledge but high enough: player's top at484; jump rises120 would bottom392, top364, would hit underside of ledge y416 after player top crosses416 at ~68px rise, limiting to bottom448. Still enough to clear fire requiring bottom ≤480; yes. Horizontal duration with bottom≤480: from t~3 to t~38; plenty. Fine.
- Wall col25 rows14-15 top448; need player bottom ≤448 while crossing x800-832. Jump from x740 or760; max bottom=392, plenty. Could land on top. Easy.
- Need perhaps exit door overlapping wall? Exit at col28 x896..928 y448..512, fine.
- Hazard water row16 x256..320 and x576..640. If player falls, water tiles at y512..544; player's body overlaps once bottom>512 and x in gap; death. Need no solid under water.
- Fire row15 x448..512 (two tiles) y480..512. Need jumping over from x416 to x544: displacement128, within150. Could land at x544 with left >512 clear. Starting from x416, right438, need jump to x544; displacement128. At t~36, x545, bottom roughly? y bottom=512-11.5*36+0.275*1296=512-414+356=454 (still above ground); at t42, bottom~512-483+485=514, x567, so landing around x563. Good. Fire ends512, safe. Need stop horizontal input around x550 to avoid second water gap at576; can release Right. Since direct vx set zero on release, player falls at x550; safe ground x512-576. Good. Browser user can do. Route physically reachable. Enemy ledge above perhaps no issue.
- First water gap from x224 takeoff to x320 ground: displacement96, landing around x360 (x224+150*~0.7? Actually full airtime150; if hold right, at landing x374). Ground from320-576, safe. Start x224 near platform end at224; but start platform row14 x128-224 overhead y448-480. If player on ground at x224, platform above and side. Jumping from underneath may hit platform underside (top448, bottom480). Player top484, after one frame top477.5 overlaps platform if x range includes x<224. At x224 exactly player left224 and platform ends224, no overlap; can jump just past edge. Need perhaps start at x232, clear. Fine.
- Second water gap start x576: need jump from x520 maybe, but fire ends512, only64px safe run-up. Jump from x520, hold right, landing x670; ground resumes640, safe. Stepping platform row13 x640-704 y416 maybe overhead near landing; player's body at descent could collide with side at x640 if feet<416? At landing near x670 and feet maybe448? Need check platform occupies y416-448; player's top at descent maybe420, could overlap side at x640. If jumping from x520 and holding right, at x640 after33 frames, bottom≈512-379.5+299.5=432, top404, which overlaps platform y416-448; side collision at x640 would stop player at x618 (platform left - width22) until falling below y448 (top>=448 / bottom>=476) around t39, x660? But collision stops x at618 (danger over water x576-640); once falling sufficiently, can move right; at t39 x still618, then move 3.6 per frame, need left>640 by t45, but player will hit water/ground at t42 perhaps y512 at x629, still in water gap x576-640 -> death. So overhead platform at x640 row13 could sabotage second gap. Don't place platform starting exactly at gap end. Put decorative platform higher row11 y352 or farther right x704. Let's avoid platforms over landing zones. Maybe put upper ledge only around x352-544 as above; second gap has no overhead. Good. Need solid platforms plural already start platform, step platform, enemy ledge. Fine.
- For enemy ledge row12 x384-544 top384, player jumping first gap from x224 to x360 may land at x360, before ledge x384. If holding right to x374 at landing, no collision; then can walk. Enemy ledge's underside y416, player top484; no issue. Jump over fire under ledge as above.

Need wall and exit perhaps add a small "brick tower" around col25 rows14-15. Could route from x736 after collecting trophy, jump onto wall top or over. Need no platform overhead. Wall x800-832; from x736 hold right jump, at x800 after18 frames bottom=512-207+89=394, top366; wall top448, so can pass. At t~? bottom returns448 around t34, x858 >832, so lands on ground right of wall. Great. No need land on wall. Wall collision mostly if approach without jump. Good.

Need perhaps we can actually play full level with browser tool via keyboard sequence. Need inspect state via `window.__game`. Could maybe use debug helper to warp for trophy/exit checks, but requirement says representative checks focused readily accessible behavior. We can test movement/jump near start, Restart, and maybe simulate collect trophy/exit by manipulating state or using debug teleport. Need not full play? We should test key behaviors perhaps via debug API or direct state manipulation. Could use browser tool to execute JS? Browser tool actions include inspect, screenshot, motion, click, drag, key, type, scroll. No `eval` action. But inspect may output DOM/console; perhaps we can create a debug panel with buttons? We can use `type` into input if we add hidden dev controls; not necessary. Could expose `window.__game` but can't evaluate arbitrary JS via provided tools. Could use browser `inspect` maybe returns console only, not JS eval. Need see. Perhaps browser tool `inspect` can output DOM text and console; we can encode state in DOM HUD status and inspect that. Use visible/invisible `<div id=debugState>` text with JSON state updated each frame. Then `inspect` can read it. Could also use `type` to interact with a hidden input if available. But we can make DOM HUD includes player coordinates maybe helpful for verifying movement/jump. Add a small `<span id=coords>Pos ... Grounded ...</span>`, maybe as debug readout but styled. This is acceptable. Need perhaps set `data-*` attributes on body or canvas with state for easier inspection. We can have JS update `document.body.dataset.state`, `dataset.playerX`, etc. Browser inspect may show DOM. Could include status text.

Need browser tool's `key` maybe accepts text like "ArrowRight" or "d"? Need test. Perhaps action key with text `"ArrowRight"` or `" "`; likely Playwright keyboard.press. We'll try. Need hold keys? `key` might be single press, not hold. Could use `drag`? Could use keydown events via on-screen buttons if we add them. We can add touch controls / on-screen left/right/jump buttons that can be clicked and held? Browser `click` is instantaneous pointer down/up; our input handling can latch? Need test movement/jump. Could implement keyboard events with discrete keydown and `jumpQueued` and movement using a "sticky" key debounce? If browser key action sends keydown+keyup quickly, movement only for one frame (~3.4px) and jump might be queued but no horizontal hold. That's still enough to check landed on ground after jump perhaps but not nearby elevated platform. Requirement "Test movement and a jump near starting area. Check player lands on a nearby solid surface and trophy and exit visibly identifiable." Could make movement via a clickable control with press-and-hold semantics. Browser tool `key` might hold? Let's learn by experimenting after writing. Could use `motion` frames to see animation, but no key holding. Could implement a "demo" or "tap-to-move" behavior where discrete key presses impart momentum or step. But user expects hold keys. Could support both: keydown sets active, keyup clears; additionally on short taps, apply a minimum movement duration (e.g., 10 frames) and a queued jump. That might make browser automation easier but could feel odd. Better perhaps browser `key` action sends keydown and not keyup? Need know. Pi browser tool docs not provided, but likely action "key" maps Playwright `page.keyboard.press(text)`, which sends down+up. Could use `type` to hold? No. Could use a debug interface via URL hash? Could trigger scripted inputs through `location.hash` with e.g. #right-jump? Or add hidden buttons that set an autopilot for a few frames. For our testing, we can expose a query parameter `?test=...` that runs scripted input but need not be visible; however user might open with no query. Could add an internal debug API and use DOM click elements to trigger it. We can add a tiny "TEST" panel? Not ideal visually but could be hidden via CSS and accessible through click coordinates? Could create tiny buttons at offscreen or transparent that browser click can hit. But we can also use browser `click` on canvas at coordinates to set player destination? Need not.

Maybe browser tool supports `key` with text like `"ArrowRight:down"`? Need infer from tool schema. `action: key`, `text:string`. Could be that it uses Playwright `keyboard.press(text)`; no separate down/up. `motion` could capture multiple frames while key held? Perhaps `key` sends a keydown event and leaves it pressed until next key action? Let's inspect tool behavior experimentally with a minimal HTML? Could write index and test. Need be efficient. We can include robust support for both:
- On keydown, set `keys[code]=true` and also `tapTimers[code] = 10` frames. On keyup, remove from keys but tap timer remains. In update, direction active if `keys.left || tapFrames.left >0`. So a short press moves ~34px. Jump queued works. This makes normal holding also work. Need avoid immediate keyup canceling jump. Fine.
- Could support repeated key events to accumulate tap frames. Press Right multiple times => move. Browser tool can send key multiple times in parallel? Tools can call multiple `browser` perhaps sequential.
- Add on-screen buttons for left/right/jump with pointerdown/up; a `click` might trigger pointerdown+up quickly; use tap timer similarly. Could test by click coordinates. Need perhaps add buttons below canvas as "◀", "JUMP", "▶" for touch support, nice. But requirement display controls; DOM text. Could use these to verify jump perhaps easier. Yet browser click sends down/up quickly and tap timer gives movement. Good.

Need implement "nearby solid surface" perhaps start platform at x128-224 row14 top448. With a 10-frame tap Right plus jump, from spawn x64, move 36 px to100, jump ascent; can't reach platform x128 if no continuous horizontal. Need multiple right presses or hold key if possible. We can design platform closer: x96-192 row14 and spawn x64; one 10-frame tap right (36px) to x100, side at96; jumping from x64 + right and space simultaneous, at t7 x89, right111; platform starts96 y448-480, player bottom maybe445, top417; no overlap with platform (bottom445<448), so above top; at descent can land on platform if x≥96. With 10 frames right, x100, then stops; descending at t~35 with x100, bottom around? 512-402+337=447, lands at448 on platform x96-192. Great! So one short tap plus jump can land on nearby platform at row14 top448. Nice. Need test with browser key presses perhaps send Right and Space nearly simultaneously. Could add a single "Jump" button that includes slight rightward assist? No, that changes gameplay. But we can use two key events: one Right press and one Space press maybe `multi_tool_use.parallel` to call two browser key actions simultaneously? Browser tool calls may run concurrently but likely not; still tap timers overlap. Need perhaps press Right then Space one after another; tap timer lasts10 frames, and jump gets queued on second; enough. Great.
- Starting platform x96-192 row14. Need ensure when player jumps from x64 with right tap10 frames, horizontal reaches x100 by frame10; then stays. At t around? Need jump from x64 starts frame0. Need platform side x96 at t10; at t10 bottom=512-115+27.5=424.5, top396.5; platform y448-480, no overlap. Continue to x100; descending bottom reaches448 around t? Solve 512 -11.5t +0.275t² =448 =>0.275t² -11.5t+64=0; roots (11.5 ± sqrt132.25-70.4)/.55=(11.5±7.865)/.55 =>6.6 and35.2. At t35 bottom448, platform top448 and x100; landing. Great. So one right tap + space yields land on platform near start. Nice! Need platform perhaps visually "starter ledge". However starting at x64 under left of platform? Platform x96, so no ceiling directly. Good.
- After landing, player can walk right along platform to x192 and drop. Need normal hold; tap repeated works. Fine.

Need perhaps implement input "tap frames" only for keyboard events? Could simply on every keydown set a `heldUntil` timestamp 180ms; even if keyup, movement active for 180ms. That gives ~11 frames. On normal hold, keys set until keyup. On short browser press, movement continues 180ms. This is a small "input buffering" for responsiveness; not harmful. Jump uses queued flag. Need avoid repeated keydown auto-repeat set `jumpQueued=true` repeatedly; check `if (jumpQueued && player.grounded)`. If Space held and auto-repeat might jump on landing; that's okay but "jumping only while grounded" still true. Could perhaps set only on `!e.repeat`. Use `if(!e.repeat)`. Good.
- Button pointerdown set `keys.left=true` plus `tapUntil=now+200`; pointerup keys.left=false but tap persists.
- Need use `performance.now()` in update? Tap frames easier decrement each fixed step. Define `tap.left`, etc. On keydown set `tap[dir] = Math.max(tap[dir], 12)`; on each step decrement. On keyup, don't erase tap. Input direction active if keys.left || tap.left>0. This can cause movement after release for 12 frames; acceptable. Need multiple key presses maybe.
- For browser testing, key action likely emits code based on text. Need our keydown handler support both `e.code` and `e.key`: map lower-case `"arrowleft"`, `"a"`, `"arrowright"`, `"d"`, `" "` / `"space"` / `"spacebar"`. Browser tool may send text `"Space"` or `" "`; map robustly. Need on keyup similarly. We can define `keyName(e)` from `e.code` or `e.key`. Good.
- Need perhaps restart via key R robust. Use `e.key.toLowerCase()==='r'`.
- Need focus: window keydown listens globally. Browser tool likely page has focus. Buttons can be clicked.

Need game loop with accumulator:
```
let last=performance.now(), acc=0, frame=0;
function loop(now) {
 const dt=Math.min(50, now-last); last=now; acc+=dt;
 while(acc>=1000/60){ update(1); acc-=1000/60; }
 draw(now/1000);
 requestAnimationFrame(loop);
}
```
Animation continues even game over with `time` frame increments maybe global tick (increment in loop regardless). Enemy update only playing. Need maybe if tab hidden huge dt clamp.
- `state='playing'|'won'|'lost'`.
- `lossReason`.
- `exitNotice` timer decrement in update (frames). When touching exit without trophy, set to 150 frames (2.5s), maybe message persists. To avoid player repeatedly colliding, no issue.
- Need player may overlap exit and then collect trophy later? Trophy is before exit, so can backtrack. If trophy collected while on exit? no. Could perhaps place trophy near exit just before. Fine.
- Need collisions with exit: define rect maybe x=896,y448,w=48,h=64 (door 1.5 tiles). For AABB. If no trophy, `exitNotice=180`; maybe push player left by 8? Could set `player.x = exit.x - player.w - 4; player.vx=0;` so visible feedback and keeps level active. But pushing back each frame if overlapping. Need perhaps if player is at door and holds right, clamp x to door left - w; collision like solid wall. That gives visible feedback but no loss. We can make door itself non-solid? Better clamp only when no trophy. Draw red "LOCKED!" banner. If trophy collected, passing into door wins.
- Trophy rect e.g. x=728,y=464,w=32,h=36 perhaps ground at512; player body y484-512 overlaps lower cup. Need trophy visual maybe y448..512 (64px tall) to be identifiable; use x=720..752, y448..512. Collision rect x720,y448,w32,h64. Player standing top484 overlaps y484..512. Easy.
- Exit visual x=888,y432,w56,h80 (to ground512), with "EXIT" sign. Collision rect x896,y448,w40,h64. Need label.
- Need trophy maybe on a pedestal and label "TROPHY" above; can draw. On collection, remove and show HUD "TROPHY: TAKEN". Maybe particles. Need optional sparkle. Good.

Need map grid generated:
```
const COLS=30, ROWS=17;
function makeLevel(){
 grid = Array.from({length:ROWS},()=>Array(COLS).fill('.'));
 for c=0..29 grid[16][c]='#';
 [8,9,18,19].forEach(c=>{grid[16][c]='~';});
 // starter ledge row14 cols3-5? x96..192 = cols3,4,5 (96..192)
 for c=3..5 grid[14][c]='#';
 // step platform row14 cols11..12? x352..416
 for c=11..12 grid[14][c]='#';
 // upper enemy ledge row12 cols12..16 x384..544
 for c=12..16 grid[12][c]='#';
 // maybe extra platform row13 cols21..22 x672..736 (after second gap)
 for c=21..22 grid[13][c]='#'; // Could this interfere with trophy/wall route? x672-736 y416; player crossing second gap from x520 may land around x670,y512 under platform; player top484 >448, no overlap because row13 bottom448; fine. But as they jump high at x640, could hit side? Platform starts x672, after gap end x640, so no collision during gap. At t~34 x642, bottom432 top404; platform starts672, no overlap. At t~40 x664, bottom~502 top474 >448, can pass under. Fine. It may be overhead near landing but starts672, enough. Could provide trophy atop it? Trophy at x720,y? Maybe collect by jumping onto platform. But requirement route complete—if trophy on platform row13 top416 at x720, need player jump from ground to it (96px) after second gap; doable but could be tricky with platform side. Could instead put trophy on ground around x736; solid platform above maybe trophy below? Need not. Let's keep trophy ground at x736, no overhead platform to avoid confusion. Maybe omit extra platform.
 // wall col25 rows14,15
 grid[14][25]='#'; grid[15][25]='#';
 // fire row15 cols14,15
 grid[15][14]='^'; grid[15][15]='^';
 // water row16 gaps set.
}
```
Need water and fire are hazard cells parsed into rectangles. Grid entries not solid. Need perhaps ground row16 under wall? wall at col25 rows14-15 and ground row16 solid, so 3-tile column from y448 to544; top448. Good.
- Need player spawn x=64,y=484 (col2 row15). Under starter ledge? Starter platform x96+, clear.
- Enemy spawn on upper ledge at x=400, y=384-28=356. Patrol range min=384, max=512 maybe; width24. Need enemy stays on ledge x384..544; `min=390,max=510`. Direction=1, speed=1.1. Draw with `enemy.x`. Need collision rect maybe x+, y+, w24,h28. Need maybe player can reach upper ledge from step platform: step platform row14 x352..416 top448; enemy ledge row12 x384..544 top384. From step at x360,y420 (feet448), jump diff64; moving right from x360 to x400; side of ledge x384,y384-416. At ascent, at t~7 feet~392, top364, no overlap with ledge y384-416? Wait player's body spans364..392, overlaps ledge y384..416 by8, and x right reaches384 aroundt7, so side collision might stop until top≥416? Actually to be above ledge top384, player's bottom must≤384, which occurs aroundt8-9; by then x391, right415 >384, but if bottom≤384, no vertical overlap with ledge (ledge y384+), so can pass. Then descend and land on top y384. Need max rise128? from feet448 to min328? Wait jump -11.5, max rise120, feet min328, so bottom≤384 for many frames. Fine. So reachable. Need step platform itself row14 x352..416 y448-480; from ground y512, jump64 onto it from x320; side x352. Fine. Good. Enemy is reachable.
- Need upper ledge x384..544 y384-416; player jumping from ground below maybe hits underside at y416, but route to it via step. Good.
- Fire x448-512 y480-512 under ledge; player jumping under ledge hits underside y416 when player's top goes below416 (feet444), limiting max rise68 (feet444), still clear fire (need feet≤480). Actually to avoid overlap fire y480-512, player's bottom must≤480; rise32. Ample. Horizontal travel under ceiling while bottom≤480 might be ~? from t3 (feet480) to t39 (feet480), so ~36 frames *3.6=130px. Need from x416 to x544=128, just possible. Starting x416 and holding right, at t39 x556, landing ground beyond fire x512; feasible. But wall? no. Great.
- Step platform row14 x352-416 y448-480 may affect approach to fire: on ground, top484, platform bottom480, clearance4; player can walk under it (top484 >480), barely. If jumping from x416 just past platform edge, fine. Need no collision when standing under x352-416: player top484, platform ends y480, no overlap. Good.
- Upper ledge row12 bottom416, plenty.

Need maybe water gap1 x256-320 and starter ledge ends x192, step platform begins x352. Gap jump from x224 to x352; no overhead. Good.
- Water gap2 x576-640; fire ends512, safe ground 512-576 (64px) before gap. Need jump from x520 to x640, player left at landing maybe x670; ground begins640, safe. Need no overhead platforms. Great.
- Wall x800-832; trophy x720-752; exit x896. Fine.
- Need perhaps solid platform at row14 x3-5 (starter ledge) has no ground below? Ground continuous under it; it's a raised platform with 32px gap (row15). Fine.
- Need perhaps "solid-wall collision" from wall col25 or platform sides. Good.
- Need all solids drawn with same brick style. Need unique styling maybe top edge. We can detect if tile above empty and draw grass/metal highlight. Procedural.

Need background perhaps draw stars/cave pattern using deterministic hash. Need no randomness each frame maybe use sine. We can define stars array generated via seeded LCG at init. No network. Need perhaps draw a few clouds/mountains.
- Draw tile world from grid; use `drawTile(c,r,type,time)`:
 solid: base #8a4a2e etc, inner rectangles, mortar lines; top edge #d19a52 if grid[r-1][c] not solid; bottom shadow. Maybe slight varied color based hash.
 ground row16 maybe stone with dirt cap.
 water: blue rect with wave lines; hazard highlight; bubbles.
 fire: dark base + flame shapes using quadratic curves, time phase. Need perhaps shape built with paths. Ensure collision zone matches tile.
- Need draw labels/collision overlays? Not needed.
- Need draw trophy with gold cup:
```
save(); translate(cx, cy + sin(time*3)*2)
shadowBlur ...
ctx.fillStyle gold; cup bowl trapezoid path; handles strokes; stem; base; white shine; text "TROPHY" above maybe at y-12.
```
Need fit tile x720..752, y448..512. Put center x736, base y505, cup from y458 to488. Text "TROPHY" at y442 maybe. Draw pedestal perhaps x716,y500,w40,h12. Trophy collision rect maybe x716,y452,w40,h60. Need label. Could draw a small arrow or halo.
- Need door:
  x888,y432,w56,h80; frame dark, inner green; arch; knob; sign at y420 maybe. Need "EXIT" on sign. If no trophy, red chain/lock icon and "LOCKED" text. If collected, pulsing gold glow. Maybe draw sign "EXIT" always. Need collision rect perhaps x892,y448,w48,h64. Door visible.
- Need player:
  draw at x,y w22,h28. Cap red, face peach, blue shirt, brown pants/boots; white eye. Need perhaps direction-based eye. Use `ctx.fillRect` integer pixel coordinates. Maybe bob/leg animation based on time and grounded. Could draw with rectangles only. Need no external assets.
- Enemy: purple/red blob with spiky back, eyes, legs; patrol direction. Draw with path/rect. Maybe use `ctx.arc` for eyes. Need bob.
- Hazard losses: overlay dark with big text "YOU LOST" and reason. Win overlay "LEVEL COMPLETE!" and trophy icon drawn perhaps. Need restart button persistent. Could overlay DOM rather than canvas; but canvas overlay is fine and all procedural. Persistent DOM button works even when overlay covers canvas? Put HTML button above canvas, not covered. Also overlay DOM button with click. Need perhaps if canvas CSS scales, overlay position. Use `.stage {position:relative}`, overlay absolute inset0; pointer events. But overlay button might be easier. We can use DOM overlay:
```
<div id="endOverlay" class=end-overlay hidden>
 <div class=card><h2 id=endTitle>...</h2><p id=endText>...</p><button id=overlayRestart>Restart Level</button></div>
</div>
```
Need set `hidden` property and CSS `[hidden]{display:none!important}`. Requirement "Draw everything procedurally" likely refers game objects, not DOM overlay; fine. But to be safe, perhaps draw overlay on canvas and use persistent button above; no separate DOM overlay button needed. Yet "Provide Restart after either outcome" persistent button is clear. Could also draw text "Click RESTART (R)" in canvas overlay. Need perhaps overlay button visible in DOM topbar. Good.
- Need "status" topbar update with `TROPHY: not collected` and state. Could display warning. Need visible feedback on exit without trophy:
   - DOM status text "LOCKED EXIT — FIND THE GOLD TROPHY!" in red and add class `warn`, maybe pulse.
   - canvas floating banner near top: `TROPHY REQUIRED!` with red background.
   - door label "LOCKED".
   - state remains playing (not game over).
Need maybe `exitNotice` decays; make visible feedback after touch. Could set to 180 frames; while overlapping door, refresh each update. Need perhaps when player backs off, notice persists 3 seconds. Good.
- Need loss state on hazard/enemy:
```
function lose(reason){ if(state!=='playing') return; state='lost'; lossReason=reason; ...}
```
Need if player falls out of bounds. Hazard collision uses `rectsOverlap(player, hazardRect)` maybe need small forgiveness margins to avoid unfair edges: shrink player box by2 and hazard by4. Could implement `hitbox(player, insetX=3,insetY=2)`. Fire/water may trigger too easily; use inset. Need water at row16 y512-544; player standing on adjacent ground with feet512 has no overlap with y512 because AABB uses `<`; okay. If x partially over water at edge but standing on ground, water overlap might kill; that's expected if touching. Could shrink water top by4 (y516). Fine.
- Enemy collision similarly shrink.
- Trophy and exit overlap use full rect or slight margins.
- Need collision with solid while x/y: implement detailed. Need ensure side collision of wall works. Let's write helper:
```
function isSolid(c,r){return r>=0&&r<ROWS&&c>=0&&c<COLS&&grid[r][c]==='#';}
function overlapTiles(box) ...
function moveX(e,dx){
 e.x+=dx;
 if(dx===0)return;
 const c1=Math.floor(e.x/TILE), c2=Math.floor((e.x+e.w-0.001)/TILE);
 const r1=Math.floor(e.y/TILE), r2=Math.floor((e.y+e.h-0.001)/TILE);
 if(dx>0){
   let limit=e.x;
   for r...for c... if(isSolid(c,r)) limit=Math.min(limit,c*TILE-e.w);
   e.x=limit;
 } else ...
}
```
Potential issue: if moving right and a solid tile is behind the entity due c1 including current location (e.g., standing atop ground row16, r2=floor((y+h-.001)/32)=15 when bottom511.999, so ground row16 not included—good). For platform beneath, similarly no overlap because bottom exactly top; using -.001 avoids. If falling slightly into ground, r2=16; then during x movement, ground tile under feet is solid and `c*TILE-e.w` might push entity left if dx>0, which is wrong! With separate axis collision, y should be resolved at end of previous frame so standing doesn't overlap; but when grounded and gravity is applied before x movement, we might apply vy=0.55 then x move while y still at exact surface (bottom=448 or512); no overlap due -.001. Fine. But if y was 447.5 etc, resolve. Need update order perhaps x before gravity/y? Standard:
```
player.vy += gravity;
moveX(player,vx);
moveY(player,vy);
```
At start of step y is resolved from previous frame. Good. If a platform side and ground under player, y doesn't overlap ground. Fine.
- For y collision:
```
e.y += dy;
e.grounded=false;
const c1..., c2...
if(dy>0) limit = e.y; for solid tiles: limit=Math.min(limit, r*TILE-e.h); e.y=limit; if(limit !== old) vy=0,grounded=true;
else ...
```
Using `r*TILE-e.h` handles any solid tile overlapping; but if the player is inside a side-adjacent solid from x movement? x collision prevents. Need if a solid tile above but not overlapping? no.
- Need if dx<0 and wall behind, use max((c+1)*TILE). Good.
- Need if dx>0 and multiple solid cols, min c gives leftmost. Fine.
- Need y<0 and multiple solid rows, max((r+1)*TILE) gives bottommost ceiling. Fine.
- Need clamp x bounds: if x<0 set0; if x+w>W set W-w. Need collision with invisible boundaries.
- Need floor/water: if y>H+32 lose. But water rect should catch.
- Need perhaps player can stand on top of wall at y448 and then walk to right; fine.

- Enemies: update with simple direction reversal and maybe align to ledge. Need update even if no player due state. `enemy.x += enemy.dir*speed; if(enemy.x<min...)...`. Need perhaps collision with solids? Patrol range fixed; no need. Need make sure enemy y=384-28=356 and height28, feet384 on ledge top384. Good.
- Need draw enemy at `enemy.x, enemy.y`.
- Need animate `tick` globally.

- Restart:
```
function restart(){
 grid=buildGrid(); // recreate
 hazards=...
 trophyCollected=false;...
 player = {x:64,y:484,...}; enemy={...}; state='playing'; ...
 keys.clear? Maybe preserve? Better clear.
 status update.
}
```
Need grid initial built once; restart can rebuild to prove restoration. Need no mutable level except trophy; but explicit rebuild anyway.
- Need start screen? no, immediately playable.
- Need maybe pause when window loses focus; clear keys.
- Need `document.getElementById('restartBtn').addEventListener('click', restart);` and maybe `overlayRestart`.
- Need visible "Restart during play" topbar button. Could also key R.
- Need debug state update:
```
const hud = {status,pos, ...};
function updateReadout(){
 statusEl.textContent=...
 coordEl.textContent=`x:${Math.round(player.x)} y:${Math.round(player.y)} ${player.grounded?'grounded':'airborne'} | Trophy:...`;
 document.body.dataset.gameState=state; ...
}
```
Update each frame maybe okay. Need include `aria-live` on status.
- Need maybe canvas fallback text.

Need perhaps make responsive CSS: canvas width100%; height:auto; container max-width1000. Need browser viewport1200x800; canvas should fit perhaps width ~960 and height544; header/help add ~150 => total ~700 fits. Good. Use body padding10. Need canvas width maybe 960 and CSS `width:100%;` so at viewport 1200 with shell max 1000 => 1000x566; plus header etc ~100 =>666, fits. Good.
- Need topbar with status and button and maybe position debug. Could show coordinates in small muted text. Need no separate control buttons perhaps.
- Need color design retro arcade: dark navy, neon cyan, orange/gold, red. Use CSS image-rendering. Could use CSS box shadows, no gradients? Fine.
- Need avoid external fonts. Use `font-family: "Courier New", monospace`.
- Need maybe `user-select:none`.

Need browser test. Need maybe expose a small test API on `window.__game`:
```
window.__game = {
 get state(){return {state, player:{...}, trophyCollected, enemy:{...}, ...}},
 restart,
 setPlayer(x,y) { ... }, // debug could enable tests but not needed; can leave only get.
 collectTrophy()...? 
};
```
For tests, we can perhaps use browser `inspect` with DOM HUD. But to test win/loss maybe need direct state manipulation. Could add hidden debug buttons that simulate conditions, but that could be considered cheating? Not user-facing. Better to test via full gameplay if possible; perhaps time-consuming but doable with keyboard if we can hold. Could use URL query `?test=win` etc to set player near goal; but no need for user app. Yet requirement says "brief pass through representative checks in task, focused on readily accessible behavior"; we can check movement/jump/restart/visuals and perhaps state transitions via a debug script or direct state mutation. We can add a small dev API and use a `javascript:` URL? Browser tool doesn't navigate. Could perhaps use `type` into address bar? no.

Maybe `browser inspect` action can run JS to evaluate something? Need see. Let's write file and use browser reload first. Then `inspect` might return DOM/console and maybe can evaluate the page? Let's see. We can also use `browser key` with `text` to run keyboard; perhaps enough.

Could make a visible "Developer/test" panel with buttons like "Give trophy", "Teleport to exit", "Touch fire" in a `<details>` collapsed. Then browser click can open and click; but this is not part of game and could clutter. Could place tiny invisible buttons at known coordinates and use browser click; but user might accidentally trigger. Better perhaps use keyboard shortcuts (not displayed) to test:
- `F1` simulate trophy collection (not needed)
- `F2` teleport near exit without trophy
- `F3` teleport near exit with trophy
- `F4` touch hazard
These are hidden and could be considered game cheats, but harmless. Yet user requirement restarting restores state; debug shortcuts could be used to verify. We can avoid including them in final visual. Browser tool can send key `"F2"` etc. That might work. But hidden shortcuts could be considered bypasses, no issue. Better to have a public `window.__platformer` debug object with methods; still no way to call via tool perhaps. Could use `onclick` of canvas with special coordinates? Hmm.

Alternative: implement a "route demo" button in UI that uses scripted inputs to auto-play level; then browser click can test full level quickly. But that adds complexity and may fail. Not needed.

Let's first create file. Need careful code correctness. Maybe use canvas roundRect? Browser likely modern Chromium; can use custom paths to be safe. Use no `roundRect` perhaps. Need no external resources. Need `ctx.setTransform` etc. Need handle scaled canvas. Need draw text with fonts. Need deterministic star array.

Let's draft code thoroughly.

HTML structure:
```
<div class="shell">
 <header class=title-row>
   <div><h1>PIXEL PERIL</h1><p>...></p></div>
   <button id=restartBtn ...>↻ RESTART <span>R</span></button>
 </header>
 <div class=statusbar>
   <span class=lamp ...></span>
   <strong id=status>GET THE TROPHY, THEN REACH THE EXIT</strong>
   <span id=readout>...</span>
 </div>
 <div class=stage>
  <canvas ...></canvas>
  <div id=endOverlay hidden ...>
    <div class=endCard>...button...</div>
  </div>
 </div>
 <div class=footer>
  <div class=controls><b>CONTROLS</b> ... kbd ...</div>
  <div class=legend>...</div>
 </div>
</div>
```
Use unicode arrows maybe okay. Buttons use `aria-label`.

DOM overlay:
```
<div id=endOverlay class=endOverlay hidden>
 <div class=endCard>
  <div id=endIcon ...></div>
  <h2 id=endTitle>...</h2>
  <p id=endBody>...</p>
  <button id=overlayRestart>RESTART LEVEL</button>
 </div>
</div>
```
CSS `[hidden]`.
Need perhaps overlay blocks keyboard? no.

Status classes: `statusbar.locked`, `.won`, `.lost`. JS set className.
Need `exitNotice` red status. Need status priority.

Readout maybe:
```
`X ${Math.round(player.x)}  Y ${Math.round(player.y)}  ${player.grounded?'GROUNDED':'AIRBORNE'}  •  ${trophyCollected?'CUP TAKEN':'CUP OUT THERE'}`
```
 Might be too much but useful.

Canvas draw:
```
function draw(time) {
 ctx.clearRect...
 drawSky(time)
 for r... for c... switch tile
 drawLabels maybe
 if(!trophyCollected) drawTrophy...
 drawExit...
 drawEnemy...
 drawPlayer...
 drawCanvasHud(time)
 if(end state) drawEndShade? DOM overlay handles, but maybe also draw tinted overlay? Could draw translucent fill and text? DOM overlay enough.
}
```
Need order: hazards behind entities, platforms perhaps after background but before entities. Water/fire draw after solids. Maybe grid solids first then hazards. Need fire glow not clipped by platform; fine.
- Draw sky full canvas. Need maybe `drawStars`.
- Draw a subtle grid of tile lines? Could.
- Draw ground row16 as solid tiles; water cells as water.
- Need draw fire at row15; if no solid under fire? ground row16 solid yes. Good.
- Need draw solid tiles, including wall.
- Need `drawCanvasHud`: top left semi-transparent panel with "LEVEL 1 · CAVERN RUN", trophy icon/indicator, maybe controls abbreviated. Could make top bar not obscure gameplay (rows0-1). Need perhaps exit/trophy labels visible. Use small text at x14,y18. Need avoid misidentification.
- Need perhaps draw "FIRE" / "WATER" labels near hazards? Could draw small "FIRE" text above flames, "WATER" on waves. Nice.
- Need perhaps draw "JUMP!" above starter platform? Could help check landing. Maybe draw a white arrow and "TEST LEDGE" at x96,y432. But not necessary. Could add signage "LEDGE" to make nearby solid surface clear. Maybe fine.
- Need decorative route arrows? Not necessary.
- Need draw platform top edges with bright yellow to distinguish solid surfaces.
- Need draw trophy label "GOLD TROPHY" maybe at x690,y430, with gold background. Need enough visual identification. Exit sign likewise.
- Need draw warning banner if exitNotice>0:
```
ctx.fillStyle='#ff405a'; roundRect at x330,y50,w300,h46; text "TROPHY REQUIRED FIRST!" and smaller "Go back for the gold cup."
```
Need perhaps door label "LOCKED" when no trophy. Good.

Need maybe draw player status if collected trophy: small gold cup trailing or halo; maybe HUD string. Could add a little cup icon above player. Nice but not necessary.

Need drawing helper `pixelText` maybe use ctx.fillText with monospace bold. Need call `ctx.textBaseline='top'`. Fine.

Need perhaps use shadows: `ctx.shadowBlur` etc; resetting after. Need no performance issue.

Input details:
```
const held = {left:false,right:false};
const tap = {left:0,right:0};
function canonical(e){ let k=e.code||e.key; switch(k) ...}
window.addEventListener('keydown', e=>{
 const k=canonical(e);
 if([...]) e.preventDefault();
 if(k==='restart'){restart();return;}
 if(k==='left'){held.left=true;tap.left=Math.max(tap.left,12);}
 ...
 if(k==='jump'&&!e.repeat){jumpQueued=true;}
});
window.addEventListener('keyup', e=>{... held[...] = false;});
```
Need canonical e.code gives "ArrowLeft"/"KeyA"/"Space"; e.key gives "a"/" "/"Spacebar". Use lower-case:
```
let k=(e.code || e.key || '').toLowerCase();
if(k==='arrowleft'||k==='keya'||k==='a') return 'left';
...
if(k==='space'||k==='spacebar'||k===' '||k==='  '||k==='jump')...
if(k==='keyr'||k==='r')...
```
If browser key action text `"Space"`, Playwright sets code="Space" key=" " maybe canonical by code works.
- Need prevent default for arrows/space while typing no inputs. No text inputs. Fine.
- Need support hidden test shortcuts maybe after initial normal keys:
```
if(k==='f2'){ trophyCollected=false; setPlayer(exit.x-...); }
...
```
Could add but perhaps unnecessary. Maybe implement `window.__platformer` with:
```
Object.defineProperty(...); 
window.__platformer = { snapshot(){...}, restart, test:{...}};
```
For browser automation perhaps `inspect` could output `window`? unlikely.
Could add a `<input id=debugCommand>` hidden offscreen and `type` action could type a command then Enter; JS parses commands. That's too weird. Hidden keyboard shortcuts easier. We can include:
```
if (k==='f2') { player.x = 860; player.y=484; ...; } // near exit
if (k==='f3') { trophyCollected=true; player.x=860;...}
if (k==='f4') { player.x=fire.x+...; ...} // loss
```
But no need to expose in controls; browser tool can press F2/F3/F4. However could accidentally open browser devtools? F2/F3 maybe fine. We can instead use digits 1/2/3 as hidden test shortcuts; users might press but not know. Need not compromise game. But maybe reviewers dislike hidden cheats. Could avoid and rely on full manual route via keyboard.

Let's think browser key action semantics. Perhaps action "key" sends keydown and holds until another key? The schema has separate actions `key`, `type`, `click`, `drag`, etc, no keyup action. It could be designed to press a key with `page.keyboard.press`. Maybe `motion` captures key state? Could call key then motion, which may show frames after press; if key remains down, movement continues. Need test. We'll see after writing. We can use `motion` maybe number of frames? `motion` action no params besides maybe text? Schema only x,y,... generic. Perhaps returns motion frames over 1s and can show movement. Good.

Need perhaps implement a simple autoplay option via URL hash to test full route. We could control player with a scripted command queue if `location.hash` starts `#test=...`; but no navigation tool to set hash. Could use browser `type` into address bar? no.

Could add hidden keyboard shortcuts for test scenarios and use browser `key` F2/F3/F4. That gives us reliable checks of win/loss/restart. Let's include them but perhaps not advertise; they don't harm gameplay. Need maybe make them require a modifier (`Ctrl+Shift+F2`) to avoid accidental. Browser key action with text perhaps can send `"Control+Shift+F2"`? Maybe Playwright keyboard.press supports. But complicates. Use numeric keys `1`, `2`, `3` maybe hidden. Could write hidden test panel in DOM with `data-test` buttons of zero opacity? Browser click at known coordinates. Hmm.

Could simply expose a small "QA shortcuts" line in a collapsed `<details>` at bottom, with buttons:
- `Test locked exit`
- `Test win`
- `Test hazard`
Could be visible as a tiny `<details>` titled "Quick checks"; not part of game aesthetics maybe okay. But user didn't ask. Could include a `<details class=diagnostics>` collapsed; browser tool can click it open then buttons. However browser click coordinates need account for CSS scaling; could use inspect to find. Might be fine.
- But hidden cheats might confuse that exit can be completed with trophy only; test buttons can force trophy. Still okay.
I think simpler to use `window.__platformer.test` plus add a tiny `<button id=qaButton hidden?>` maybe no. We only need reporting what we actually checked; can say we checked movement/jump/restart and visual IDs; win/loss logic unverified in browser (code implemented). But task says "brief pass through representative checks in task" not necessarily all. Could still check win/loss via direct JS if browser tool supports. Let's see later.

Need perhaps use browser `inspect` to see console. Let's write file first. Use `write` with full content maybe 700 lines; need be careful. Let's draft around 600 lines. Need no external assets.

Let's write.

Need run browser reload inspect initial output/console.

Initial screenshot looks good, trophy/exit visible, hazards. Need console empty. Need test movement and jump near start, landing on nearby solid surface, Restart restore. Need understand key action. Let's try one key press ArrowRight then inspect state/readout. Need perhaps browser key maybe text `"ArrowRight"`. Also maybe jump with `"Space"`. Could call parallel? Let's first test right.

Interesting DOM says X96 while screenshot/status top right says X78 maybe screenshot captured earlier than DOM; tap timer continues. Key action apparently sends keydown+keyup, and tap timer 12 frames moves ~43px; readout DOM at X96 but screenshot perhaps earlier frame. Need wait/motion then inspect. Need test jump. We can call key Space; player grounded at maybe x96 after right tap. To land on nearby platform x96-192 top448, need right+jump simultaneous. We can restart first then send ArrowRight then Space quickly. Need perhaps tap timer still active when Space press, likely yes if actions sequential within <200ms. Since browser call may take time. Could use multi_tool_use.parallel two browser key calls to send at same time, but may race. Could perhaps add hidden test keys via URL? Alternatively use key `"ArrowRight"` then `"Space"` sequential; tap timer lasts 12 frames=200ms, tool latency maybe ~100ms, enough. Need jump from x64 to x100; platform x96-192; likely land. Let's test. First restart via click button or R. Use key R. Then press ArrowRight and Space. Could use parallel tool calls to make simultaneous. Need maybe one tool call with multi_tool_use.parallel two browser calls; can run concurrently. Let's do restart then perhaps separate actions.

Need send right+jump. Let's use parallel calls maybe.

Parallel calls executed sequentially perhaps first ArrowRight at X82 grounded; second Space at X107 airborne Y481. Need wait via motion to see landing on ledge. Use browser motion maybe captures frames.

Interesting after motion player at x107,y484 grounded, not jump? Perhaps Space key didn't trigger? In second key DOM readout Y481 airborne, then motion shows grounded x107. Maybe jump happened briefly but player hit underside of starter ledge at x96-192 row14 y448-480! Player starting x107 under ledge (since ledge x96-192). Jump from beneath ledge: top y484 hits underside y480 after 1 frame, so vy set0 and falls back to ground. So cannot jump onto platform from directly underneath; need takeoff before x96 (e.g., x64) and move right during jump to land on platform. Our parallel key calls had ArrowRight first causing x~107 by time Space pressed, so player was under ledge. Need test jump near starting area from x64 with both right+space at same frame. Need sequence perhaps press Space first then ArrowRight quickly; jump queued and right tap active. If Space first triggers jump, then right key shortly after; should land on platform if x goes to ~100. Let's restart, press Space, then ArrowRight sequentially. Need perhaps Space key call's DOM might show initial jump; then right call will add tap. Let's do.

Jump works (y435 after ~?), now press right immediately.

Tool call latency enough for full jump to complete before right press, so can't land on ledge. Need perhaps use browser `drag` action to hold right? Maybe click and drag on an on-screen control can hold via pointer events? Browser `drag` from x,y to toX,toY might issue pointerdown, move, pointerup over duration; if we add on-screen control button where pointerdown sets held right, and drag across it could hold for some time. But need combine jump simultaneously. Could add a "jump right" test button or touch controls. Hmm.

Could perhaps use `key` action with text `"ArrowRight+Space"` or `"Shift+..."`, but our canonical doesn't parse. Playwright `keyboard.press("ArrowRight+Space")` maybe sends chord? Actually Playwright syntax uses "+" separators, e.g. `Control+A`. Could use `"ArrowRight+Space"` where both keys pressed simultaneously? Need know browser tool implementation. We can test with action key text `"ArrowRight+Space"` or `"Space+ArrowRight"`; likely `page.keyboard.press(text)` interprets plus as modifier combination and can press both; could work. We can add handler parsing combined keys in canonicalKey: if `e.code`? For `ArrowRight+Space`, Playwright may dispatch two keyboard events with codes ArrowRight and Space; both held briefly. Our tap timers would overlap. Need try after restart. Could send `"Space+ArrowRight"` perhaps. Let's test. Need perhaps support actual simultaneous key press via Playwright `keyboard.press("Space+ArrowRight")`; yes docs: shortcut string e.g. "Control+Shift+T"; it presses keys in sequence and releases in reverse; can include nonmodifier? likely yes. That would produce Space down, ArrowRight down, ArrowRight up, Space up, all near-instant; our `jumpQueued` set on Space down, tap.right set12 frames. Next animation frame, jump while grounded and right active. Great. Let's try.

Great! Space+ArrowRight works, jump at x74 airborne y427. Need wait/motion to see landing on ledge. Use motion perhaps 2s.

Great: player landed on starter ledge at x92,y420 grounded (top y448, player h28 => y420). That satisfies movement & jump landing. Screenshot shows trophy/exit clearly. Need check Restart restores initial state. We are at x92,y420, trophy out. Press R or button; need use restart button maybe requirement asks "Use Restart". Could click button to verify. Need find coordinates: screenshot 1200x800, button around x1025,y38. Browser click action. Use click x1025 y38. Then inspect.

Restart works: x64 y484 grounded cup out there, trophy visibly back, enemy back perhaps moved slightly. Need maybe test collectible state return after collecting trophy; requirement says "Use Restart and check that the initial player and collectible state return." We haven't collected trophy yet. Need test restart after trophy collection maybe need get there. Could use hidden debug shortcuts or full play. Need perhaps add a simple programmatic test interface to browser via keyboard chords? Maybe use `window.__platformer` not enough. Could simulate full level with `Space+ArrowRight` combo repeated plus timing. Need possible but tricky. Could perhaps use hidden debug key shortcuts via browser `key` text like `"Shift+F2"` etc; we can add temporary test hooks, run checks, then remove them. This is a good approach: modify file to include temporary debug shortcuts, use them to verify win/loss/restart, then remove debug shortcuts before final. Need ensure final file saved. We have time. Could also use browser console command via `"javascript:..."`? no. Could alter file temporarily to add URL hash or keyboard shortcuts, then reload and test. Then remove. Let's do temporary hidden shortcuts:
- `1` key teleport player to trophy and collect on next update (overlap) while state playing.
- `2` teleport player near exit with trophyTaken=false to see locked feedback.
- `3` teleport player near exit with trophyTaken=true to win.
- `4` teleport into fire to lose.
- maybe `5` teleport into enemy to lose.
But need canonicalKey currently returns "restart" for `"r"`; add handling for digits. We can add to canonicalKey and keydown. Need maybe test restart after trophy collection: press `1`, wait; status trophy secured; press restart button; should cup out there. Then press `2`, wait; locked feedback and state active. Press `3` maybe win; `4` loss; restart after each. Could also test overlay restart button. Then remove shortcuts from final file. This is robust. Need be cautious not to accidentally leave test code. Could perhaps add shortcut code guarded by `const QA = true`, then remove entire block after. Since we can edit. Need maybe use canonicalKey returns `"qa1"` etc. Let's add temporary code to keydown or direct `window.addEventListener` separate:
```
window.addEventListener("keydown", e => {
 if(e.key==='1'){ player.x=730;player.y=484; }
 if(e.key==='2'){ trophyTaken=false;player.x=880;player.y=484;}
 if(e.key==='3'){ trophyTaken=true;player.x=880;player.y=484;}
 if(e.key==='4'){ player.x=470;player.y=484;}
 if(e.key==='5'){ player.x=enemy.x;player.y=enemy.y; }
});
```
Need maybe key events on `1` could trigger from browser tool. No conflict with controls. Add inside IIFE with comment `// TEMP_QA_START` and `// TEMP_QA_END` to remove precisely. Need perhaps `e.preventDefault()`. Need ensure exit overlap from x880? exitRect x892..940, player width22 at x880 -> right902 >892, overlaps. y484..512, exit y440..512; overlap. If no trophy, notice plus clamp x to869? Good. If trophy, win.
- Trophy: x716..756,y448..512; set player.x=730,y484 -> overlap; next update collects. Need note that player might be under something? no.
- Fire: x448..512,y480..512; set player.x=470,y484 -> hurtbox x473..489? fire inset x453..507,y485..507; overlap, loss.
- Enemy: set player.x=enemy.x,y=enemy.y; overlap, loss. Could test.
- Water: set player.x=270,y500 perhaps water rect y512; player bottom528 -> overlap; but grounded on no solid, falls; loss. Could add key6.
Need perhaps test all required outcomes. Add temporary shortcuts and reload. Then remove. Let's do edit with insertion before window.__platformer or near listeners.

Need reload and run tests. Also maybe check locked exit, trophy, win, loss, restart after outcome. Let's do reload then key1, inspect.

Need issue key1 then perhaps motion or inspect after a frame. Browser key action likely waits one frame; update may occur. Let's do.

Trophy collection works, door unlocked and trophy gone. Now restart to check collectible returns. Use click restart.

Great. Now locked exit test key2.

Locked feedback works, level remains active. Need perhaps verify can move away; maybe press ArrowLeft and inspect x decreases. Could do quickly. Need perhaps test win with key3; QA handler if state playing, okay. Need perhaps key3 can be pressed while locked notice; should set trophyTaken true and x880; update win. Let's do.

Win overlay works. Need test restart after outcome using overlay button. Click around (600,486) in viewport coordinates shown; button center ~600,486. Use browser click.

Need test hazard loss (fire/water/enemy). Use key4, then overlay; test restart after loss perhaps R. Could also key5/6. Let's do key4.

Need test water/enemy loss perhaps key5,6 after restart. QA handler auto-restarts if state not playing, then sets player. Press 5 from lost state will `restart()` then set enemy. Need update next frame loss. Let's do key5.

Enemy loss works. Water key6.

All loss types work. Need test restart after loss via R perhaps. Then remove temporary QA code. But before removal, consider full route physically reachable. Need perhaps verify player can actually traverse full level using actual controls, not just teleports. We should analyze or test with scripted autopilot. Since requirement says keep level's route physically reachable. Need ensure no hidden collision issues. We can simulate game in Node by extracting logic? Could use browser keyboard chords and clicks, but full route may be hard. Could build a temporary QA autoplay routine using key `7` that executes a fixed sequence of inputs across frames and observe outcome. Or use internal physics model via Node by duplicating functions? Easier: add temporary QA "autopilot" with a scripted command sequence that uses the same update loop and input fields to complete the level. Then press a key to start, wait few seconds, inspect win. This verifies reachability. Need design script carefully. Could alternatively use pure JS in Node (no DOM) by copying physics functions and map; but more work. Browser autopilot easier with temporary code. Need time budget maybe ~8 minutes left? We have plenty maybe. Need ensure final code has no QA shortcuts. Let's implement temporary `qaAutopilot` that overrides held/taps/jumpQueued per frame based on tick. But need script sequence and avoid hazards. Could also use direct teleport to checkpoints and use physical movement for each obstacle, which is enough to show route reachable. We can write a custom `window.__platformer` method or key `7` to set player at a sequence of checkpoints. But to fully prove, perhaps script actual inputs from start to finish. Need figure precise controls and timing. Could use a simple AI that reacts to map and hazards, or set waypoint positions and use `held.right`, `jumpQueued`. Perhaps easier to use a direct controller that sets player's x,y velocity? That wouldn't test physics. But we can script held inputs and jump events based on current position.

Let's reason map geometry and fixed-step:
- Player starts x64,y484, grounded on ground (top512). Starter ledge x96-192, y448-480 overhead. Need avoid hitting underside. To go right from ground under ledge, can walk right; player top484 > platform bottom480, so no overlap. Good. At x192, ledge ends. Need cross first water gap x256-320. Need jump around x220-230. If holding right from start at3.6/frame, starting x64:
  - to x224 requires160/3.6≈45 frames. Need jump at x224. Could script hold right continuously and jump when x>=220. Player at x220, right242. Jump duration~42 frames, horizontal151 -> x371 at landing, ground from320; safe. Need ensure upper enemy ledge at x384 y384-416: landing x371 before384, safe. Step platform x352-416 y448-480 overhead near x352: At jump from x220, as player approaches x352 after37 frames, bottom maybe? t37:512-425.5+376.5=463, top435; step platform y448-480, overlap vertically (448-463), and x352-... side collision at x352 could stop player at x330 until bottom>480? But platform step starts x352 at row14 y448-480. At t37 x353, bottom463, top435, overlap; side collision will stop x at330 (352-22). This is a problem! The step platform x352-416 row14 (y448-480) begins right after first water gap and could block the descending jump. Need check carefully. At t37, bottom=512 -11.5*37 +0.275*1369 =512-425.5+376.5=463.0; top435. Step platform y448-480; overlap. Player reaches x352 around t37 from x220+133=353, so side collision at x330. It will stop at x330 (over water? water gap x256-320; x330 is ground from320, safe). Then player continues descent; when top>=480 (bottom>=508) around t? landing ground y512 t42, can move right. So can land on ground at x330 and then walk right under step platform (top484 > bottom480; clearance4), so okay. It doesn't kill. Fine. If x330 is ground (x320..), yes. Good.
- Then fire x448-512, upper ledge x384-544 y384-416, step platform x352-416 y448-480. Player on ground under step/ledge. Need jump over fire. Starting from x416 maybe just past step; upper ledge underside y416; ceiling limits jump. Need jump from x416 or x420 with bottom512; fire starts448. Need horizontal travel while bottom<=480 to clear x512+playerwidth22 => left>512, displacement from416 to>512 =96. Under ceiling, jump can rise until player's top hits416 => y=416, bottom444; hit at t? bottom=444 solution 0.275t²-11.5t+68=0 roots (11.5±sqrt132.25-74.8)/.55=(11.5±7.58)/.55=>7.1 and34.7. At t7 ceiling sets y=416, vy=0; then gravity pulls down. Need compute bottom from y416 with vy? our moveY sets vy=0 when hit ceiling; then next frame gravity0.55, so bottom starts444 then increases quadratically. It reaches480 after about sqrt(36/0.275)=11.4 frames, so total low-bottom window from t3 to t~18, horizontal ~54px, insufficient to clear64 fire! Wait need more careful: Fire inset y485..507, player's bottom must <=485 to avoid overlap; after ceiling hit at bottom444, gravity fall to485 in~12 frames; from t3 (bottom480ish) to t~19 =16 frames *3.6=58px. Need from x416 to x534 (right edge >512 with player width22) =118px. Not feasible under ceiling. But upper ledge x384-544 y384-416 acts as ceiling only if player's x overlaps its tiles. Could jump from x416 under it, yes ceiling. Could jump from before x384 and clear fire by passing over upper ledge top? Need jump onto upper ledge (top384) from step platform, encounter enemy. Or approach fire from x384 and jump high enough to land on upper ledge, etc. Ground route under ceiling may indeed be impossible. Need redesign to ensure simple route physically reachable. Need remove upper ledge over fire or make it higher so ceiling doesn't limit arc. Put enemy ledge at row10 (y320) or row11 (y352) where underside384/352, giving more clearance. From ground jump max bottom392 (rise120), so player top364; if ceiling underside384, player top would hit384 after ~? rise100, not full; still enough. If ledge row11 y352-384, underside384; player top starts484, can rise100 to384, bottom412. Ceiling hit at bottom412. Then fall to485 in sqrt(73/.275)=16.3 frames; total low window maybe t4 to t~? ascent to ceiling t? bottom412 solve .275t²-11.5t+100=0 roots (11.5±sqrt132.25-110)/.55=(11.5±4.72)/.55 =>12.3 and29.5; hit at t12.3, then fall16 frames => total low window t3..28 =25frames*3.6=90px. Still less than118. If ledge row10 y320-352 underside352, player top can rise132 to352, but max rise120 so no ceiling hit. Then full jump low-bottom window ~38 frames*3.6=137px, enough. Put enemy ledge row10 (y320) high above ground; but then need make it reachable via stacked platforms? Could be optional; requirement only at least one patrolling enemy; no requirement to reach enemy. But "route physically reachable" main ground route. Could place enemy on high ledge row10. Need maybe visually less integrated but okay. Need keep solid platforms plural. Could add step platforms from ground to high ledge via row14, row12, row10 stacked with 64px increments; but then could interfere with route. Maybe not needed; enemy can patrol on a high isolated ledge, player can touch it if they choose to climb via platforms. But if no path to it, still okay? "Touching a hazard or enemy causes a loss state" can be tested by debug but not physically; level route doesn't need enemy. Yet perhaps better design stacked platforms on side not overhead fire. We can redesign upper enemy ledge position to avoid over fire.

Simpler: Move enemy ledge to x352-480 instead of x384-544 and fire to x544-576? Need water gap at576; fire one tile before water would be tight. Or move enemy ledge to x352-448, fire x480-512; then ceiling only until448, fire starts480; no overhead over fire. Need jump from x448 to x544 (96px) with no ceiling; full jump can. Good. Put upper ledge row12 x352-448 (cols11-14), step platform x320-384 maybe. Enemy patrol x360-420. Fire x480-512 (one tile) or x480-544 two tiles; no ceiling from x448 onward. Need jump from x448 to x544 (96px) with full jump; max horizontal150, feasible. Ground after fire x544-576 1 tile, then water x576-640. Need jump fire and water as one perhaps from x448 to x640: displacement192 >150; impossible. But can land at x560 after fire jump by releasing right, then jump water from x552 to x672 (120), feasible. Need careful with direct horizontal control. Could script it. But human can. Need perhaps safe area between fire and water of at least2 tiles to land and prepare. Move second water gap to cols20-21 (x640-704), giving ground x544-640 three tiles. Then trophy/wall/exit positions need shift right maybe still fit. Exit at col28 x896, wall col26 maybe x832, trophy col24 x768. We have width30. Let's redesign with clear spacing:
- ground gaps: cols8-9 (x256-320), cols20-21 (x640-704).
- fire: cols15-16 (x480-544).
- safe ground between fire and second gap: x544-640 (3 tiles).
- enemy ledge above x352-448 (cols11-14) row12 y384-416; doesn't overlap fire. Step platform x320-384 row14 y448-480 maybe over ground; could block first gap landing but fine. Enemy ledge side at x352; need maybe enemy patrol x360-420. Need path to upper ledge via step platform: step x320-384 top448; upper ledge x352-448 top384 (64px higher), so reachable by jumping from step. Good.
- second gap x640-704; wall at col26 x832 rows14-15; trophy at col23 x736; exit col28 x896. Need enough space between gap end704 and trophy736/wall832. Good.
- gap1 landing and step platform x320-384 row14 could block jump but can land x330 then walk under. Fine.
- fire x480-544 no ceiling. Need perhaps upper ledge ends448, so jump from x448 just past it, full arc.
- second gap x640-704; from safe ground x544-640, can jump from x600 to x744 (144), ground starts704; safe. Need no overhead platforms. Good.
- trophy x716-756 (just after gap at704) with label. Wall x832-864. Need wall jump from x768 to x? full arc; exit x892. Need maybe trophy at x716 overlaps landing from gap; player may collect while airborne/landing. Great.
- Need update water labels positions from x608 to x672? draw labels at x288 and x672 maybe. Need fire label x512.
- Need enemy y remains356 on ledge top384. Step/ledge positions updated. Patrol max maybe420. Need `maxX=420`. Need ensure enemy stays on ledge x352-448: enemy width25, maxX=420 => right445<448. Good.
- Need QA teleport positions unchanged: trophy x716..756, player x730 works; fire x480..544, player x470 no longer in fire (ends before480). Need set QA key4 x500. Water key6 x270 still first gap; okay. Exit same.
- Need exit lock/win unchanged.
- Need draw labels: "SOLID LEDGE" x144; "FIRE" x512; "WATER" x288 and x672. Need adjust.
- Need maybe draw wall at col26 instead of25. Need enough path to exit: wall x832-864 top448; trophy x716-756, exit x892. Jump from x768 full arc to x912 maybe could hit exit (with trophy, win), good. Need clear wall width32 and then door. Great.
- Need perhaps solid platform at row14 cols3-5 starter ledge overhead from x96-192; from start we can walk under with top484 > bottom480. Fine.
- Need `g[14][25]` wall changed to26; `g[15][26]`.
- Need water columns [8,9,20,21].
- Need upper ledge cols11-14 (x352-448), step cols10-11 (x320-384) perhaps. Need fire cols15-16 (x480-544). Need no ceiling over fire. Step platform x320-384 row14; upper ledge x352-448 row12; from x320-384 under step, can jump onto step from ground. Fine.
- Need maybe first gap jump from x220 to x330 lands ground under step. Good.
- Need enemy patrol on upper ledge with y356. Need path from step x320-384 to ledge x352-448: from step top448 (player y420), jump to ledge top384 (player y356). Need moving right into ledge side x352 while rising. At t? Start x330 on step, bottom448, top420; ledge y384-416; body overlaps y384-416? top420 >416, no. After one frame, bottom436.95, top408.95, overlaps ledge y384-416 if x reaches352. Starting x330, right352 exactly (no overlap due `<` maybe x+w=352, ledge x352; no overlap). Next frame x333.6, right355.6 >352 and body y~398..426, overlaps ledge y384-416, so side collision stops at x330 (c*32-w=352-22=330). It will stay until player's top≥416 (bottom≥444) on descent, which happens later; but could never get above ledge because side blocked while ascending. Need to jump from farther left and approach side after clearing top? To land on top y384, need bottom≤384; max rise120 from448 to328, so at t? bottom384 around t8. Starting x300? But step starts x320; player on ground perhaps. Need horizontal distance to side x352: from x300 takes~14 frames; by then bottom=448-161+54=341, top313, above ledge top384 (bottom341<384), so no overlap. But can you jump from ground at x300 to ledge top384? Diff128 > max rise120, so no. Need start on step at x300? step starts320, can't stand at300. Could start at x320 on step and jump straight up, then move right once above top: hold right only after ~10 frames. Human can. So reachable with timing. Fine.
- Could place upper ledge starting x384 (one tile later) to allow more horizontal run from step x320-384. From x330 on step, right352, ledge x384 after15 frames; by then bottom maybe? t15:448-172.5+61.9=337.4, top309; above ledge top384; no overlap, can move onto ledge as descending and land. Great. So set upper ledge cols12-14? x384-480, but ends480 where fire starts480, no overlap (ends exactly at480). Enemy patrol x400-450. Step x320-384 adjacent. Ledge x384-480 y384-416. Fire x480-544; starts at ledge end, no ceiling over fire. Good. Need from step x330 to ledge x384, full jump with right held; at t15 x384, bottom337<384, no collision, then descend onto ledge top384 around t29, x434, good. Easy. Enemy there. Great.
- Need ledge perhaps row12 cols12-14 (3 tiles x384-480), enemy patrol min390 max450 (right475<480). Fine.
- Need step platform row14 cols10-11 (x320-384), top448. First gap ends320; step starts320 overhead at landing zone x320-384. Jump from x220 to x330 might collide side of step at x320 when descending at t? from x220, x320 at t28; bottom=512-322+216=406, top378, step y448-480, no overlap! Wait at t28 bottom406 (above step top448), so no collision. As x enters step horizontally, body is above step top, and descending might land on step top448 at t? solve bottom448 roots6.6,35.2; at t35 x346, bottom448, so lands on step top y448 at x346, not ground. That's fine—step is solid and route can continue from elevated platform. Need then avoid enemy ledge overhead at x384 y384-416. On step top448, player y420, body420-448; upper ledge y384-416 ends416, clearance4; walking right under ledge possible. Need fire starts480,y480; from step top feet448, can walk off at x384 to ground? Upper ledge starts384 y384-416; player body on step top y420-448, no overlap with ledge (ends416), so can walk under. Step ends384; player falls to ground from y420 to484; as x>384 under upper ledge, top maybe420 <416? Actually top420 >416, no overlap; safe. At x448, ledge ends; can jump fire from ground. Good. Nice.
- Need first gap jump from x220 with right held could land on step x346 top448. That avoids water. Great.
- Need release right to avoid walking off while under ledge? Could walk right under ledge and fall; no hazard until fire x480. Upper ledge ends480, fire starts480. Need jump before x480 from x448; but player might be on ground after x384, enough 64px run to x448. Fine.
- Need maybe fire jump from x448 with full jump because upper ledge ends at480 and might overlap x448-480 during first part. At x448, jumping under ledge y384-416; ceiling underside416; player top484; can rise68 before hitting at top416. That limits bottom444; as before, low window perhaps not enough to clear fire. But we can jump from x480 after passing under ledge. Fire starts x480, so need jump from x448 or earlier; but could jump from x448 while under ledge, ceiling until x480. Alternatively move left slightly or jump vertically under ledge then move right after clearing ceiling? Need route from ground to fire obstacle with overhead ledge ending exactly at fire start; player can stand at x458 (under ledge up to480) and jump; ceiling limits. Could jump from x448 and wait under ceiling, then move right once above ledge? Hmm. To clear fire x480-544, need horizontal from x448 to >544 =96+player width? Need left>544, displacement96. If ceiling restricts low window to ~58px, no. Could start jump from x470 just under ledge edge, need to x>544 displacement74; low window58, still insufficient. Could move right from x470 to x480 while rising under ledge (10px), then at x480 leave ceiling and continue full jump? But jump height lost due ceiling; vy=0 at bottom444, then falls; not enough.

Need eliminate ceiling immediately before fire. Make upper ledge end well before fire, e.g. cols12-13 x384-448, leaving ground x448-480 before fire without ceiling. Then player can stand at x450 (just beyond ledge) and jump over fire x480-544. Need displacement to left>544 from x450 =94; full jump horizontal150, feasible. Great. Upper ledge x384-448 (2 tiles), enemy patrol x390-420, width25; max420 gives right445<448. Step x320-384. Fire x480-544. 32px clear run before fire. Need player can jump from x448 (right at ledge end) with no ceiling because ledge tiles x384-448 end at448; player's left x448, right470, no overlap. Starting at x448 on ground, full jump. Need jump takeoff x448, fire starts480; at t3 bottom480, x459, body x459-481 overlaps fire x480-544 by1, but hurtbox inset player x462..478? Wait hurtBox = player inset3 => x451..469? Actually player.x=448, w22, hurtbox x451,w16 => right467. So no overlap with fire inset x485..539 until player moves. At t? bottom≤485 for t3..39; player x at t3=459, hurtbox right478; still clear. At t5 x466, hurtbox right485; fire inset starts485; strict > maybe no overlap. At t6 x470, hurtbox right489 >485, but bottom? 512-69+9.9=453, y hurtbox top? player y425, hurtbox y427..? bottom481; fire inset y485..507, no overlap because hurtbox bottom=player.y+28-2=478? Let's compute player bottom=453, hurtbox bottom=451, clear. Fine. At descent t39 bottom~482, hurtbox bottom480 <fire top485, clear. At t40 bottom~?512-460+440=492, hurtbox bottom490, x592, hurtbox x595..? Already beyond fire x539, clear. So holding right from x448 across fire to x592 at landing, safe. Need fire drawn x480-544; ground to x640. Great.
- Need collision with fire only when overlaps y; fine.
- So upper ledge x384-448, row12; no ceiling over x448+.
- Need step platform x320-384 row14; from first gap landing at x346 on step, player can walk right under ledge and drop to ground before x448. Then set up jump at x448.
- Need enemy patrol on upper ledge x384-448; enemy range390-420. Could potentially touch player while jumping from step to ledge, optional. Fine.
- Need second gap x640-704. Need jump from x600 maybe; safe.
- Need wall at x832.
- Need trophy x716-756 after second gap; can collect on landing. Need jump from x600 with right held: at t42 x751, lands ground at x704+, collects trophy. Great. Need then wall at x832; from x751 after trophy, need stop, maybe jump wall from x760. Fine.
- Need exit x892. Could jump wall from x760; full arc151 ->x911, overlap exit with trophy => win. Great. This creates a nearly continuous autoplay with right held and jumps at x220, x448, x600, x760. Need ensure at x220 from start under starter ledge? starting x64, hold right through starter platform overhead (no collision because top484 > bottom480). At x220 jump. Need perhaps step platform starts320, ledge etc. Jump from x220 to step x346 as above. Then continue right: player lands on step top448 at t35 x346, grounded. Holding right continues; at x362 (platform end384) walks off. Upper ledge x384-448 y384-416; player falling from top448 has body top420..448, no overlap with ledge, so can pass under. At x384, player left may reach384 while y420 (body420-448), no overlap with ledge (ends416). Good. Falls to ground y484 (bottom512) after ~? from feet448 to512 under gravity from0, ~15 frames, horizontal54px -> x438. So by x448, player on ground under/after ledge. Need jump fire at x448. If autopilot schedules jump when x>=448 && grounded, yes.
- Jump fire from x448; upper ledge ends448, no ceiling. Full jump to x592 ground after fire. Need perhaps second gap starts640, schedule jump at x600. Holding right from x592 to600 in ~2 frames, jump. Need ensure grounded; yes.
- Jump second gap from x600 to x751, landing on ground after704. Trophy at716-756; overlap during descent/landing, collected.
- Need wall at832; schedule jump at x760 maybe after landing and trophy. Holding right from751 to760 ~3 frames; grounded. Jump wall from760; full arc to911, exit at892; win. But wall x832-864 top448, need clear. At t? from760, x832 at20 frames, bottom=512-230+110=392, top364, wall y448+, no overlap; good. At t42 x911, bottom512, door x892-940 y440-512 overlap => win. Great.
- Need potential collision with upper ledge after first gap as player on step and moves right; okay.
- Need potential collision with step platform during first gap jump from x220: step x320-384 row14 y448-480, player at t28 x321, bottom406 top378, above step; descends to land on step top448 at t35 x346. Good.
- Need potential collision with upper ledge x384-448 row12 y384-416 during first gap jump if holding right beyond t35? At t42 original jump would x371,bottom? But because lands on step at t35, vy0 and grounded; holding right continues; at t? x384 around46 frames after jump, but now on step top y420, body420-448, no overlap with ledge y384-416. Safe.
- Need perhaps moving from step at x362 off edge under ledge: as gravity starts, y420.5, body420.5-448.5; no overlap with ledge end416. Fine.
- Need fire jump from x448: at t1 x451.6, bottom500.95, top472.95, fire x480+ no x overlap. Fine. At t6 x469.6, right491.6, bottom453? yes; body bottom453, no y overlap with fire y480+. At descent around t37 x581, bottom455? Wait compute bottom at t37=463 (from earlier), top435; no y overlap with fire y480. At t39 bottom?512-448.5+418.3=481.8, top453.8, hurtbox bottom479.8, fire inset top485, just clear. At t40 bottom?512-460+440=492, hurtbox bottom490, x592, hurtbox x595..? fire ends544, clear. Safe. Ground at x592 within544-640. Good.
- Need second gap jump from x600: water x640-704. At t? player bottom>516 around t42, x751, ground from704, safe. During descent at x704 after29 frames, bottom?512-333.5+231.4=409.9, well above water; fine.
- Trophy collection may happen at x716 around t33, bottom~?512-379.5+299.5=432, player y404, trophy rect y448-512; player's bottom432<448, so no overlap yet. At t38 x737,bottom?512-437+397=472, player's body y444..472 overlaps trophy y448..512 and x716..756, so collects in air. Good.
- Wall jump from x760: at t? wall x832 after20f, bottom392; clear. At t? land x911 at42, exit; win. Need perhaps exit sign/door does not act as solid; win triggered. Great.
Thus full route is reachable with simple autopilot. We should redesign map as above and test autopilot via temporary QA. Great.

Need update code map and drawing labels, enemy range, wall. Also QA fire x500. Add autopilot key7. Need design autopilot controller:
```
let autopilot = false, jumpPoints = [220,448,600,760], nextPoint=0;
if key7: restart(); autopilot=true; next=0;
in update before input determination:
if (autopilot) {
 held.right=true;
 if (state==='playing' && player.grounded && nextPoint<... && player.x>=points[next]) {
   jumpQueued=true; nextPoint++;
 }
}
```
Need avoid jumpQueued being consumed before update? Set at top of update, then normal jump handling sees it. Need ensure `player.grounded` at x220. Should be. At x448 after first landing and walking/dropping, grounded. At x600 after fire jump landing. At x760 after second gap/trophy. Need maybe x thresholds overshoot due 3.6, but okay. Need perhaps `debugAutopilot` variable. Need remove after testing.
- Need ensure autopilot doesn't restart on state won; controlled by state.
- Need maybe if jump happens at x220 then next=448; good.
- Need pause at x thresholds? continuous right.
- Need perhaps `held.right` remains true after win; restart clears held; fine.
- Need `taps.right` not needed.
- Need add `autopilot` reset in restart? If restart called from QA setup then set true. Could declare `let qaAuto=false,...`; in restart set false, but key7 sets after restart. Need place in update. Alternatively avoid altering restart by set qaAuto after.
- Need maybe autopilot has watchdog: if state lost or won, stop; if tick since start >600 and not won, maybe inspect failure. Fine.

Let's update map and temp QA. Need multiple edits. Use edit call with exact replacements. Need careful they don't overlap. We'll do one call with several distinct regions.

1. buildLevel:
```
for (const c of [8, 9, 18, 19])
```
-> `[8,9,20,21]`
2. platforms block:
```
for c=11..12 g[14]...
for c=12..16 g[12]...
```
-> step cols10..11, ledge cols12..13.
3. fire cols14..15 ->15..16.
4. wall col25 ->26.
5. enemy maxX 510 ->420, x=402 maybe still on ledge x384-448. Fine; min390 max420. Ledge starts384; enemy x402 initial. Good.
6. drawCanvasHud labels FIRE 480->512, WATER second608->672.
7. QA key4 x470->500; add autopilot.
8. Add qa variables and update hook.
9. Need perhaps update `drawWater` labels maybe text at y534 within water tile; second water x640-704, text center672. Good.
10. Need maybe trophy at x716 after gap ends704, okay.
11. Need wall at col26 x832-864; exit x892. Good.

Let's edit.

One edit failed perhaps QA block differs due earlier insertion position. Need inspect relevant tail. Use read around event listeners.

We have ~5 min. Need apply edits quickly. First six maybe applied? Since one failed entire edit call likely atomic? Need check. It says could not find edits[7], likely no edits applied. Need check.

No edits applied. Need redo with smaller edits and exact QA block. Read tail around 805-835.

Need apply all edits in one call with correct QA block. Also need perhaps autopilot could be added but time. We can simplify: redesign map to ensure reachability; perhaps skip autopilot test due time, but need remove QA anyway. Need apply map changes and QA block perhaps not need autopilot. But we have ~4 min; can add autopilot and test quickly maybe. Yet instruction says finalize as soon as possible. We need save index.html now with map changes and remove QA debug code. Could skip autopilot test and rely on analysis. Need ensure no temporary QA shortcuts remain in final. Need perhaps initial version already worked and route maybe not physically reachable. Need essential fix: move platforms/fire/gaps as planned. Then remove QA entirely. Let's do that. Need maybe test initial and a quick jump/restart again after changes (reload with QA removed). Need perhaps full route not tested but analyzed. Could add autopilot temporarily but likely too much. Given time, prioritize final clean file and essential checks.

Apply edits:
- map gaps [8,9,20,21]
- platform block
- fire block
- wall col26
- enemy maxX420
- labels
- remove first TEMP_QA variables? We didn't add them. There are only QA event listener. Need remove entire block. Need also perhaps remove first TEMP_QA_START comments? Only one block. Need check `rg TEMP_QA`. only 810 and824. Good.
- Need perhaps add autopilot? no.
- Need maybe `restart()` clears held but no qaAuto variables.
Let's apply exact.

Need verify no QA left; check file syntax perhaps via Node? Need reload browser and inspect console. Also initial movement/jump/restart. Need perhaps quickly test full route? Could implement simple internal autopilot via console not possible; but maybe we can use key chords repeatedly with timing. Time ~3-4min. Need at least reload and inspect initial. Need maybe use browser tool to execute a key chord sequence with `motion` to hold right? Perhaps we can use `key` with `"ArrowRight+Space"` at key points and repeated `ArrowRight` presses; but tool latency ~0.5s means tap movements not continuous. Could use URL query with autopilot but no. We can rely on prior QA tests for state logic and re-run quick initial checks after map changes. Need ensure no console errors. Let's reload.

Looks good. Need verify movement/jump/restart after final changes. Use Space+ArrowRight and motion as before. Need note starter ledge same. Then restart button. Could perhaps test locked/win/loss no QA shortcuts; earlier QA tests were on old map but core logic unchanged except map positions. We should perhaps not need. But need if final map trophy collection overlap still works. Trophy same, exit same. Fire moved; loss logic unchanged. Enemy ledge moved. We could perhaps add hidden QA again? No time. Core code unchanged. Need maybe route physically reachable—need perhaps at least simulate via browser with keyboard chord maybe could hold right continuously through `motion`? Could use `key` action with `"ArrowRight"` maybe keyup doesn't stop tap after12 frames. Need repeated presses, but tool latency ~0.5s and each press moves43px. Could sequentially press ArrowRight 20 times and Space at strategic positions; possible but time. Need perhaps simply use `key` with `"ArrowRight+ArrowRight+..."` maybe chords. But need jump timing and long holds. Could use `key` action with `"ArrowRight"` repeatedly perhaps 4-5 calls to reach x220, then `"Space+ArrowRight"` to jump onto step etc. But each tool call latency maybe ~0.5s, and tap lasts 200ms; between calls player stationary. We can press repeatedly and inspect x. Need many tool calls; time budget maybe 3min. Could use multi_tool_use.parallel to send multiple key actions at once, perhaps each sets tap.right=12 frames but they might overlap; if sequential in same event loop, could extend movement maybe. But not necessary. We can report full route not manually verified; code design and earlier QA checks. But task explicitly says "Keep level's route physically reachable." We need be confident. Our analysis suggests yes. Could perhaps do a quick offline physics simulation in Node by extracting the update logic and map to verify autopilot. We can create a temporary Node script that copies simplified physics from index.html? Could use JSDOM not available; but can parse map from source and reimplement update. Time maybe 2min. But we can also embed an autopilot in a temporary copy of index.html (not final) and use browser key7, then revert. Yet finalization instruction says save now, fix only essential issues. We already saved. Maybe enough.

Need check no QA leftover and file size. Then jump/restart quick. Let's do jump with chord and motion.

Need motion to land.

Screenshots show player landed on starter ledge. Good. Trophy/exit visible. Need restart check final. Click restart.

Need final checks: no QA, no external resources, file present. Could run quick `rg` and maybe syntax via Node extracting script? Browser console no errors confirms. Need maybe check full route with map from screenshot: first water x367-430? scaled; step platform x434-500; upper ledge x503-568; fire x597-672; second water x768-830; trophy x835; wall x965; exit x1025. Let's map scaled: logical x320 step at screenshot x434, upper ledge x503, fire x597, second water x768, trophy x835, wall x965, exit1025. There seems wall at x965 and exit x1025, leaving only ~60 screen = ~50 logical? In logical wall x832 (screenshot965) width32 (37), ends x864(screen1001), exit starts x892(screen1035) — screenshot exit door starts1025 perhaps. Gap ~30 logical, okay. Need jump wall from x760 to x911 win; fine. Need maybe trophy at x716-756 (screen835-882) after second gap end704(screen818), okay. Good.

Need ensure route clearance: upper enemy ledge x384-448, fire x480-544, step x320-384. Screenshot shows step lower platform x434-500, enemy ledge x503-568; actually step ends at x384 (screen500), ledge starts x384(screen500), contiguous. Fire x480(screen597), yes. 32 logical gap. Good. Need maybe from step under ledge: step top448, ledge y384-416, clearance from416 to448=32; player height28 fits. Great.

Need perhaps full route from first gap jump to step: first water x256-320, step x320-384; jump from x220 to x346 lands step. Good. Need second water x640-704, trophy x716; jump from x600 to x751 lands ground after gap and trophy. Good. Need wall x832-864, exit x892; jump from x760 to x911. Good. Route reachable.

Need maybe player can start from ground under starter ledge and walk right, but starter ledge y448-480, player top484, clearance4; collision code uses `y+h-0.001` etc, so no overlap. Fine.

Need perhaps locked exit clamp x to869, door x892; player can move away. Good. Need no trophy in final screenshot? restart restores it, yes.

Need maybe remove QA code fully. Check.

Need final response concise, mention what actually checked, which remain unverified. Need be honest: checked initial load/console, movement/jump landing, trophy/exit visual, restart restores player and collectible state. Earlier QA checks with temporary shortcuts (now removed) verified locked exit feedback/active, trophy collection, win, fire/water/enemy losses, restart after outcomes. Need mention full continuous route not manually played end-to-end, though map adjusted and physics spacing designed/analysis. Need perhaps say no console errors. Need mention final file path. Ensure no need more test. Could perhaps mention full route remains unverified. Good.

Need be concise.