Superbench 2.1

# 15. Ember Glider

Build a serene 3D gliding game at sunset. The player pilots a small glider across a chain of three floating islands, riding thermal updrafts to stay aloft and passing through glowing ember rings that mark the route. The goal: reach the final beacon on the third island, finishing under the par time. A defined journey with an end — not an endless flight.

The point is calm, legible purpose: follow the rings, manage altitude, reach the beacon. Altitude is the resource — it always drains, thermals restore it, and the rings form both the path and the progression meter. A first-time player should understand everything from one sentence and one HUD.

The first screen must state the goal in one line ("Ride the thermals through the rings. Reach the beacon before sunset.") with the controls below it. One key press launches. No other menus.

## Core Loop

- The glider flies forward continuously; the player controls pitch and bank. Speed ties to pitch: diving gains speed, climbing bleeds it.
- Altitude decays constantly in still air. Cylindrical thermal columns rising from the islands restore altitude while inside them; each thermal is marked by rising ember particles visible from far away.
- Rings sit along the route as checkpoints: pass through to bank progress and respawn there on a crash. A HUD counter tracks them (e.g. "Rings 7 / 14").
- Running out of altitude over open air means a water crash: brief splash, then respawn at the last ring with a small time penalty.
- Landing on an island is safe (rolling stop, relaunch by pitching down off the edge or pressing R).
- Passing the final ring and flying through the beacon gate ends the run: a finish screen with total time vs par, rings hit, and crashes. A defined ending, then Free Flight stays available.

## The Journey

- Three floating-island groups in sequence: **Ember Shore** (low thermals, wide ring spacing, teaches the loop), **Ashen Peaks** (taller islands, thermals off the direct line, forces route choices), **The Beacon** (a climb: rings stack upward on strong thermals to the beacon gate).
- Ring count and positions are fixed per run; the route must be completable without exploits: each leg is flyable from thermal to thermal with sensible margins.
- Par time is shown on the first screen and in the HUD; finishing under par earns an Ember Medal on the finish screen.
- Best time and medal persist in `localStorage` and show on the first screen.

## Flight Model

- Simple but honest energy management: airspeed, altitude, and sink rate trade against each other. Thermals add climb. No fuel gauge, no unrealistic hovering.
- Stall behavior: too slow and the nose drops with a warning shudder until speed recovers.
- Controls must feel smooth: banked turns roll the glider and the horizon; pitch inputs are gentle, not twitchy.
- A compass ribbon or subtle on-screen marker points toward the next ring when it is off-screen.

## HUD and Screens

- Always visible: altitude (bar or tape), airspeed, ring counter, current island name, elapsed time vs par.
- Next-ring direction indicator when the ring is off-screen.
- Crash: brief splash/fade, "+10s" penalty notice, respawn at last ring.
- Finish screen: total time, par time, medal earned or missed, rings hit, crashes; buttons for Retry and Free Flight.
- Free Flight: same world, no timer, no crash penalty.

## Controls

- **W / S or Arrow Up / Down**: pitch up / down
- **A / D or Arrows**: bank left / right
- **R**: relaunch from last ring — **Esc / P**: pause — **Enter**: start, confirm
- Mouse drag to look around is allowed; keyboard alone must be fully playable.

## Visual Rules

- Full-screen 3D rendered into a `<canvas>` via Three.js (or comparable WebGL via CDN, listed in `manifest.json.externalAssets`).
- Sunset mood: warm gradient sky, low sun, drifting clouds, god-ray-like light shafts if cheap, ember particles rising from thermals, water with sun glitter below.
- Islands are stylized floating landmasses: low-poly cliffs, trees, grass caps, waterfalls spilling off edges. Beautiful stillness, not empty grey rocks.
- The glider banks and pitches visibly; a soft ember trail marks its path. Rings glow and burst gently when passed.
- No external models, textures, or audio fetched at runtime; everything procedural or code-built (one CDN font allowed).
- Honor `prefers-reduced-motion`: no camera roll exaggeration or shake; flight unchanged.
- 30+ fps at 1280×800 on a 2020 laptop.

## Hard Requirements

- Single `index.html`, no build step; opens over `file://`.
- Keyboard accessible; `lang="en"` on `<html>`.
- No login, no analytics, no network requests for runtime art, models, audio, or data.

Expose a small automated verification hook:

```js
window.__glider = {
  ready: true,
  getState(),        // phase (start/flying/crashed/finish/freeflight), island, ringsHit, time, crashes
  start(),           // launch the run
  setInput(input),   // { pitch, bank } for scripted flight
  getGlider(),       // position, altitude, airspeed, heading, inThermal
  getRings(),        // all rings with position and passed state
  getThermals(),     // thermal columns with position and strength
  teleportToRing(i), // for testing later legs
  getTiming(),       // elapsed, par, penalties
  resetProgress()    // clear localStorage bests
};
```

The hook must call the same game functions the UI uses, not a parallel simulation.

## Loop / Validation Rule

Do not stop until you have personally verified all of the following in a browser:

1. The first screen states the goal, par time, controls, and any stored best; launching has no console errors.
2. Pitch and bank respond smoothly; diving gains speed, climbing bleeds it, and a stall drops the nose with a warning.
3. Altitude decays in still air and rises inside a marked thermal; the HUD altitude readout matches the glider.
4. Passing through a ring increments the counter and sets the respawn point; the ring burst plays.
5. Crashing into water respawns the glider at the last ring with the time penalty applied; the ring counter and route state are preserved.
6. The off-screen ring indicator points correctly toward the next ring.
7. Using the hook to teleport to the final island, the beacon gate ends the run with a finish screen showing correct time, par, medal, rings, and crashes.
8. Finishing under par awards the medal; over par does not; best time persists across a page reload via `localStorage`.
9. Pause works; Retry restarts cleanly without reload; Free Flight removes timer and crash penalty.
10. Landing on an island is safe and relaunch works.
11. Reduced-motion mode keeps flight identical with camera effects removed.
12. The game holds 30+ fps at 1280×800 while inside a thermal with full ember particles.

If any check fails, fix the specific mechanism and run all twelve checks again.

# 14. Low-Poly Tower Defense

Build a low-poly 3D tower defense game on a floating diorama island. Enemies follow a winding path from a portal to the island's heart; the player spends gold on towers to stop them. Survive all 10 waves without losing 20 lives to win. A defeat screen at 0 lives, a victory screen after wave 10 — not an endless mode.

The point is a legible economy of decisions: kills earn gold, gold buys and upgrades towers, and every wave the player re-reads the battlefield and adapts. A first-time player should grasp the whole game from one look at the HUD: gold, lives, wave 3/10.

The first screen must state the goal in one line ("Stop 10 waves. Don't lose 20 lives.") with the controls below it. One click starts the run. No other menus.

## Core Loop

- Enemies spawn at the portal and walk the fixed path to the heart. Reaching the heart costs lives (1 per enemy, 3 per elite).
- The player places towers on valid build tiles beside the path using gold. Towers attack automatically in range.
- Kills award gold instantly. Between waves the player builds, upgrades, or sells; a Start Wave button (or Space) launches the next wave.
- Waves escalate in count, HP, and enemy mix. Wave 10 is a boss wave with a single large enemy.
- All 10 waves cleared with lives remaining → victory screen. Lives at 0 → defeat screen. Both show stats (gold earned, kills, towers built) and a Restart that works without reloading the page.

## Economy and Towers

- Starting gold must afford exactly 2 basic towers with a little left over. Gold, kill bounties, tower costs, and sell refunds (75%) must all be visible and consistent.
- Exactly 3 tower types, each with a clear role:
  - **Arrow tower** — cheap, fast, low damage; the breadline.
  - **Cannon tower** — slow, splash damage around the impact; the answer to packs.
  - **Frost tower** — no damage or token damage; slows enemies in range; the force multiplier.
- Each tower has 2 upgrade tiers above base. Upgrades cost more than the previous tier and visibly change the tower (size, color accents, projectile) and its stats (damage, range, rate, slow strength).
- Towers can be sold for a 75% refund of total gold spent on them.

## Waves and Enemies

- 10 hand-tuned waves, previewable: before starting a wave, the HUD shows its composition (counts and types).
- At least 4 enemy types, distinct in silhouette and color:
  - **Runner** — fast, low HP.
  - **Soldier** — balanced.
  - **Brute** — slow, high HP.
  - **Boss** — wave 10 only; huge HP bar, slow walk, worth 10 lives if it leaks.
- Flying or path-ignoring enemies are out of scope.

## The Island

- A single floating low-poly diorama: cliff sides, water or clouds below, trees/rocks as decoration, a readable path from portal to heart.
- Flat-shaded geometry, soft daylight, gentle shadows. The aesthetic should match a premium low-poly illustration, not grey boxes.
- Build tiles are visibly marked (flat pads or plots). Invalid placement (path, water, occupied) must be rejected with clear feedback.
- Towers and enemies read clearly at the default zoom: color-coded, with HP bars on damaged enemies.

## HUD and Screens

- Always visible: gold, lives, wave counter ("Wave 3 / 10"), and the Start Wave control.
- Selecting a tile or tower shows a small radial or panel: build options with costs, or upgrade/sell with costs and stat deltas.
- Speed control: 1× and 2×. Pause at any time.
- Victory and defeat screens: run stats and a Restart button.

## Controls

- Mouse: hover to inspect, click tile to build, click tower for upgrade/sell, drag to pan slightly or orbit a few degrees.
- **1 / 2 / 3**: select tower type — **Space**: start wave — **F**: toggle speed — **Esc / P**: pause — **Enter**: confirm.
- Keyboard-only play must be possible: Tab cycles build tiles and buttons; Enter activates.

## Visual Rules

- Full-screen 3D rendered into a `<canvas>` via Three.js (or comparable WebGL via CDN, listed in `manifest.json.externalAssets`).
- No external models, textures, or audio fetched at runtime; all geometry procedural or code-built.
- Combat feedback: projectiles visible in flight, muzzle flash or glow, splash radius flash, frost tint on slowed enemies, gold bounty popups on kills.
- Honor `prefers-reduced-motion`: reduce particle bursts and idle bobbing; gameplay unchanged.
- 30+ fps at 1280×800 with the final wave on screen.

## Hard Requirements

- Single `index.html`, no build step; opens over `file://`.
- Keyboard accessible; `lang="en"` on `<html>`.
- Persist best wave reached in `localStorage` and show it on the first screen.
- No login, no analytics, no network requests for runtime art, models, audio, or data.

Expose a small automated verification hook:

```js
window.__defense = {
  ready: true,
  getState(),        // phase (start/build/wave/victory/defeat), gold, lives, wave, speed
  startGame(),
  startWave(),
  setSpeed(n),       // 1 or 2
  getTiles(),        // build tiles with occupancy
  placeTower(type, tileId),
  upgradeTower(towerId),
  sellTower(towerId),
  getTowers(),       // type, tier, damage, range, spent gold
  getEnemies(),      // type, hp, path progress, slowed state
  getWavePreview(n)  // composition of wave n
};
```

The hook must call the same game functions the UI uses, not a parallel simulation.

## Loop / Validation Rule

Do not stop until you have personally verified all of the following in a browser:

1. The first screen states the goal and shows best wave from `localStorage`; starting a run has no console errors.
2. The island, path, portal, and heart are immediately readable; build tiles are visibly marked.
3. Placing an arrow tower on a valid tile deducts the correct gold; invalid tiles are rejected with feedback.
4. Starting a wave spawns its previewed composition; enemies follow the path and towers fire automatically in range.
5. Kills award the correct bounty instantly; leaks reduce lives by the correct amount (1 normal, 3 elite-type, 10 boss).
6. Cannon splash damages multiple enemies; frost visibly slows enemies (tint + speed) without killing them.
7. Both upgrade tiers change tower stats and appearance; selling refunds 75% of total spent.
8. Speed toggle runs the wave at 2×; pause halts everything; keyboard-only play (Tab/Enter/1-2-3/Space) completes a full wave.
9. Lives reaching 0 shows the defeat screen; clearing wave 10 (boss included) shows the victory screen; Restart resets cleanly without reload.
10. The wave counter, gold, and lives are always correct and readable at 1280×800.
11. Reduced-motion mode keeps the game fully playable.
12. The game holds 30+ fps during wave 10 at 1280×800.

If any check fails, fix the specific mechanism and run all twelve checks again.

# 21. Skyhook Cargo

Build a playable harbor crane challenge in one HTML document: move a suspended cargo crate around a solid tower and settle it onto a marked pad, with visible pendulum physics and telemetry that agrees with the scene.

Work tool-free. Do not browse, execute code, inspect files, or call tools. Reason silently, then return the complete HTML document in one message. No preliminary plan, commentary, or subsequent repair turn.

## Required features

1. Scene and framing. Render a real-time perspective 3D or coherent 2.5D harbor diorama with depth, modeled crate, cable, crane, striped solid tower, water, and landing pad. Physics may run in a vertical 2D plane. Keep the entire playable plane visible in a fixed camera, with clear silhouettes and restrained atmospheric detail. No image or video backdrop standing in for gameplay.
2. Controls. Arrow Left/Right or A/D accelerate the trolley horizontally; Up/Down or W/S shorten/lengthen the cable within limits. Show equivalent holdable on-screen buttons. Release applies trolley braking, not an instant load stop. Include Pause, Reset, and Cable ± controls with instructions. Prevent page scrolling while gameplay keys are active. Reset restores the same initial state.
3. Coupled motion. Integrate gravity and a constrained cable with a bounded timestep and substeps or an equivalent stable method. Trolley acceleration excites load swing; braking leaves momentum; changing cable length affects the actual constraint. The load is not a scripted sine wave. Cable cannot stretch freely. A simplified nonrotating crate is acceptable.
4. Solid world. The crate has finite dimensions and contacts the tower, floor, and pad without passing through or remaining embedded. Cable length and trolley travel limits are enforced. Arrange the tower so the load can be hoisted above it and transferred to the pad; keep the trolley and cable anchor above all obstacles. Prevent the cable from cutting through the tower, by restricting unsafe movement or modeling cable contact. Contact must not produce explosive motion.
5. Truthful instruments. Draw a plumb reference below the trolley and a visible swing-angle arc. Display signed cable angle, load speed, actual cable length, contact state, and settle progress from the same current physics state used to draw the scene. Compute angle from anchor/load positions. Use world units consistently; no canned telemetry. The HUD must remain readable at 1280×720.
6. Landing rule. Show the pad's footprint and a two-second settle ring. Delivery requires the crate's full horizontal footprint inside the pad, bottom in surface contact, speed below 0.15 world units/second, and absolute cable angle below 5 degrees continuously for two simulation seconds. Any violation clears settle progress. Show success only after this condition; pause freezes simulation and settle time. Success must be reachable through ordinary controls.

## Output constraints

Return exactly one complete HTML document, starting with <!DOCTYPE html>, with inline CSS and JavaScript; no Markdown fences or surrounding text. No imports, CDNs, fetches, external assets, libraries, fonts, audio, build step, or network requests. Use native browser APIs, procedural geometry, and procedural shading. It must run by opening the file locally in a current desktop browser. Fit 1280×720 and adapt to narrower windows without hiding controls. Start playable without setup. Use readable text and visible focus states.

## Loop / validation rule

Do not stop drafting until all six features are represented and the following checks can be performed. You cannot execute them in this tool-free response: mentally trace them and correct the document before returning it; do not claim tests passed.

1. Open locally while offline: the full harbor and controls appear without dependencies; resize and confirm controls remain usable.
2. Reset, accelerate right for one second, release, then reverse: the load lags, overshoots, and reverses continuously; cable length stays constrained and the angle readout matches the arc.
3. Hoist and lower: the rendered cable and numeric length agree. Push the load against the tower and floor: neither load nor cable passes through the tower; no persistent embedding or explosive jump occurs.
4. Compare speed while swinging and after settling; compare contact text with actual contact. Pause during motion and during settling: both world and progress stop, then resume without a jump.
5. Move partly over the pad or enter while swinging: no delivery. Hoist around the tower, place fully on the pad, and hold the stated conditions: the ring completes after two simulation seconds and delivery appears.
6. Reset after success and repeat using on-screen controls: initial state and empty settle progress return, and all actions remain possible.

If any mental check fails, fix and re-run all mental checks before output. The operator runs the actual checklist after generation; no tool use or extra generation is permitted.

# 22. Concourse Divide

Build an interactive station diorama in one HTML document where two opposing crowds visibly reroute around closing gates, queue without crossing walls or one another, and resume when a route reopens.

Work tool-free. Do not browse, execute code, inspect files, or call tools. Reason silently and return one complete HTML document in one message, without a plan, explanation, or repair turn.

## Required features

1. Legible station. Use a fixed elevated 3D or 2.5D camera showing the full concourse, walls, three labeled passages through a central divider, and two opposing destination zones. Distinct cyan and amber agents need visible bodies, ground contact, and direction cues. Keep routes readable at 1280×720; ornament must not hide agents or gates.
2. Fixed population. Start exactly 48 persistent agents, 24 of each color, in separated staging areas on opposite sides. Each seeks the destination on the other side. Give agents stable IDs and render every active agent. Arrived agents remain visibly parked in nonoverlapping destination slots. No respawning, teleporting, disappearing, or removing agents to resolve congestion. Reset restores the same layout and seed.
3. Real routes. Build navigation from the actual walkable geometry. Agents choose currently reachable passages and replan when gates change. Use finite-radius collision boundaries and local separation/avoidance; opposing streams must negotiate passage, with an explicit yielding or lane rule to prevent permanent symmetric deadlock. Paths may be grid- or graph-based. Do not use pre-recorded trajectories or gate-specific animated paths.
4. Interactive gates. Provide labeled toggle buttons for North, Center, and South; clicking the matching gate also toggles it. Start all open. On closure, stop new entries immediately; any agents already inside the gate footprint can exit before the solid shutter closes. Show this as amber Closing, then red Closed when empty. Never crush, overlap, or teleport an agent. Closed gates are genuinely impassable. Reopening restores connectivity.
5. Inspectable behavior. Clicking an agent selects it and shows its ID, destination, current planned route, and last two seconds of actual trail. A route line cannot run through closed gates. Show total active, arrived, and waiting counts derived from agents, maintaining active + arrived = 48. Waiting is a subset of active; display why the selected agent is waiting. If no path exists, show No route and wait safely rather than walking through barriers.
6. Recovery and controls. Include Pause and Reset. With all gates closed and drained, agents stop safely. Reopen South: agents with destinations still outstanding must resume and all 48 must eventually arrive within 90 simulation seconds with South kept open. No auto-completion timer. Pause freezes movement, trails, and simulation time. Provide keyboard-accessible gate controls, clear instructions, and a layout that remains usable when resized.

## Output constraints

Return exactly one complete HTML document beginning with <!DOCTYPE html>, with inline CSS and JavaScript and no Markdown fences or surrounding prose. No external libraries, imports, CDNs, fonts, assets, network requests, or build step. Use native browser APIs and procedural visuals. Open locally offline in a current desktop browser. Start the simulation immediately and keep controls visible.

## Loop / validation rule

Do not stop drafting until all six features and these checks are accounted for. Do not execute tools or claim runtime verification; mentally trace and correct your implementation before returning it.

1. Open offline and observe two legible colored streams and exactly 48 agents; resize without losing controls.
2. Reset; after three simulation seconds close Center and select a nearby traveler. The gate drains before solid closure; the selected route and visible movement divert through an open passage.
3. Close North and South as well. Let closing gates drain. Remaining travelers wait, routes do not cross solid shutters, and active + arrived stays 48.
4. Pause, inspect a waiting agent, then resume and reopen South only. Travelers replan and move; all 48 arrive within 90 simulation seconds after reopening. No agent crosses a wall, shutter, or another body to escape congestion.
5. Reset and close a different gate first, toggling a gate while occupied. Confirm the same safe closure and recovery logic works; IDs and counts remain consistent.
6. Reset again, check identical starting positions, and exercise keyboard and pointer controls. Selected route, recent trail, waiting explanation, and actual motion agree throughout.

If any mental check fails, fix and re-run all mental checks before output. The operator performs real checks afterward; no additional response or tool-assisted repair is allowed.

# 23. Lightkeeper's Atelier

Build a real-time 3D lantern workshop in one HTML document that makes polished metal, rough metal, ceramic, stone, and glass visibly distinguishable as a movable inspection light sweeps across them.

Work tool-free: no browsing, file inspection, code execution, or tool calls. Reason silently and return the complete HTML document in a single response. Do not include a plan, commentary, or follow-up repair.

## Required features

1. Art-directed scene. Create a brass-framed glass lantern with a visible inner light on a slate workbench, plus four equal-size labeled sample spheres: polished brass, rough brass, glazed ivory ceramic, and matte charcoal stone. The two brass spheres must share base color and differ principally in roughness. Include a small red object visibly inside the lantern behind the glass. Use coherent scale, grounded geometry, a dark workshop background, warm key/cool fill separation, and a clear hero composition. Labels must be readable at 1280×720.
2. Actual 3D. Use native WebGL/WebGL2 or another native browser rendering approach that projects real 3D geometry with depth and normals. Provide pointer-drag orbit within useful limits and zoom, plus Home camera. Geometry must remain coherent from both sides; do not substitute a flat image, CSS card, or pre-rendered turntable.
3. Material response. Lighting must depend on surface normal, light direction, and camera direction. Polished brass has a compact bright colored specular response; rough brass has a broader dimmer response; ceramic has an ivory diffuse body and a distinct glossy highlight; stone is predominantly matte with restrained procedural surface variation. Glass must show the red inner object through its surface, with stronger reflection toward grazing angles. Correctly order glass and inner geometry; avoid opaque or disappearing panes. A procedural environment and approximate glass are allowed; physically exact refraction is not required.
4. Controlled lighting. Expose a key-light azimuth slider from -90 to +90 degrees, a key on/off button, and a separate inner-lantern on/off button. Draw a small light-source marker that follows the key. The internal light illuminates nearby lantern geometry and a visible patch of the table; a bright unlit sprite alone is insufficient. Keep exposure fixed across toggles so their effect is visible. Provide a Sweep toggle that moves the actual key continuously, without changing camera or materials.
5. Grounding and shadows. The external key casts geometric shadows from opaque lantern parts and sample spheres onto the table. Moving the key changes shadow direction coherently, and disabling it removes its shadows. Use shadow maps or geometric projected shadows; a fixed painted oval is insufficient. Transparent glass may omit shadow casting. Avoid pervasive floating, severe shadow acne, and obvious geometry clipping.
6. Diagnostic presentation. Provide Beauty and Neutral inspection modes. Neutral disables decorative haze, bloom, and vignettes while retaining identical geometry, lights, exposure, and materials. Show current key azimuth and both light states. Home resets camera; Reset restores camera, modes, lights, and azimuth to a documented default. Keep controls accessible by keyboard and usable after resize. No performance claim or fake FPS readout is required.

## Output constraints

Return only one complete HTML document beginning with <!DOCTYPE html>, inline CSS and JavaScript, without Markdown fences. No external libraries, imports, CDNs, fonts, images, models, textures, network requests, or build step. Generate all geometry and shading locally using native browser APIs. It must open offline in a current desktop browser. Start at the composed hero view with controls and instructions visible. If WebGL is unavailable, show an honest capability error instead of a fake render.

## Loop / validation rule

Do not stop drafting until every feature and the checks below are represented. You cannot execute these checks in this tool-free response; mentally trace and correct the document without claiming runtime success.

1. Open offline: the complete 3D lantern, four labeled spheres, red inner object, workbench, and controls appear. Resize and verify legibility.
2. Set Neutral mode. Sweep key azimuth from -60 through 0 to +60 degrees. Highlights move across surfaces; polished and rough brass remain distinct despite matching base color. Ceramic retains a glossy diffuse body and stone remains matte.
3. Observe the key marker and table shadows across the sweep: shadows change consistently with light position. Switch key off: its highlights and shadows disappear without auto-exposure compensating.
4. With the key off, toggle the inner light: nearby frame and table visibly brighten and darken. The lamp is more than an emissive dot.
5. Orbit to both sides and zoom: depth, silhouette, glass transparency, red inner object, and shading remain coherent. Glass reflection strengthens at grazing angles; the inner object does not draw incorrectly in front of the frame.
6. Toggle Beauty/Neutral: only decorative effects change. Use Home and Reset, then verify the documented default and the Sweep control. Keyboard controls and light-state labels match the rendered state.

If any mental check fails, fix and re-run all mental checks before output. The operator validates the result after generation; no extra generation or tool-assisted repair is allowed.

# 24. Wrecklight Salvage

Build a playable three-phase salvage game in one HTML document: pilot a small tug through a wreck, power a reactor vault with two recovered cells, then tow the physical reactor through an extraction gate and settle it in a dock to win.

Work tool-free. Do not browse, inspect files, execute code, or call tools. Reason silently and return one complete HTML document in one response. No plan, explanation, or follow-up repair turn.

## Required features

1. Readable world and movement. Use a top-down 2.5D or elevated 3D wreck diorama with real-time depth cues, solid walls, a visible vault, two cells, a home dock, and an extraction gate. Keep the whole compact map visible. Use WASD/arrows for acceleration with inertia and damping, Space or an on-screen Interact button for pickup/attach/release, plus holdable directional buttons. Show instructions and current objective. Finite-size tug and cargo must collide with walls and closed doors; bound timesteps to prevent tunneling. Prevent gameplay keys from scrolling the page.
2. Phase 1 — Restore. Two physical cells begin at different reachable wreck locations. Pick up one at a time only when close and moving slowly. A carried cell remains visibly attached to the tug, disappearing from its original location. Bring each to a different marked vault socket and interact to install it. Each installed cell remains visible and lights its socket. Only two installed cells open the solid vault door and start Phase 2; elapsed time or tug proximity alone cannot advance the phase.
3. Phase 2 — Recover. The opened vault exposes one glowing reactor. Approach and interact to attach a visible tow cable. The reactor has independent position and velocity, inertia, collision radius, and a bounded cable constraint. Turning and braking produce visible trailing motion. Release detaches it at its actual position; reattach only within reach. Phase 3 begins only when the attached reactor itself fully clears a marked threshold outside the vault. The tug crossing alone does not count. Preserve all installed cells and door changes.
4. Phase 3 — Extract. Keep towing the same reactor to the dock. A beacon detects the reactor within a clearly drawn approach zone before the extraction gate and arms that gate's repeating cycle: four simulation seconds open, three closed. Before activation it stays open. Show phase with moving gate geometry, colored floor markings, and a countdown derived from actual gate state. When closing, stop new entries but let any body already in the gate footprint clear before the solid shutter finishes closing; show amber Closing during this extension and start the closed duration after it clears. Do not crush bodies or cut the cable: postpone solid closure while a body or the attached cable intersects the doorway. Tug or cargo cannot pass a fully closed gate.
5. Honest victory. Show the dock footprint. Victory requires the reactor's complete footprint inside it, speed below 0.15 world units/second, and cable detached continuously for two simulation seconds. A moving, attached, or partly docked reactor cannot win; the tug alone cannot win. Show a settle ring driven by these conditions and reset it on violation. Preserve the world on victory and permit inspection. Make the complete ordinary run achievable in roughly 2–4 minutes without unavoidable hazards or pixel-perfect steering; give enough passage clearance to tow successfully.
6. Inspection and restart. Include Pause, Reset, and a clearly labeled Review: Phase 3 button. Review loads a deterministic valid late-game fixture: both cells visibly installed, vault open, reactor already cleared from the vault and attached behind the tug, extraction beacon not yet triggered, tug and reactor immediately outside its approach zone. It must use the same simulation, gate, collision, and victory code as normal play. Show REVIEW FIXTURE persistently and never present it as an earned run. Reset returns to Phase 1 and clears everything. Display phase, installed-cell count, attachment, gate state, reactor speed, and dock settle progress from real state. Pause freezes all physics and timers. Controls and status remain usable after resize.

## Output constraints

Return exactly one complete HTML document starting with <!DOCTYPE html>, inline CSS and JavaScript, without Markdown fences or prose. No imports, libraries, CDNs, external images, models, fonts, audio, network requests, or build step. Generate all visuals procedurally with native browser APIs. Open locally offline in a current desktop browser and start in Phase 1 with instructions visible. Optimize framing for 1280×720 while supporting narrower windows.

## Loop / validation rule

Do not stop drafting until all requirements and checks are represented. Do not execute tools or claim runtime verification: mentally trace these checks and correct the document before returning it.

1. Open offline and resize. Move and brake with keyboard and on-screen controls; wall contact blocks the tug without clipping or explosive motion.
2. Attempt the vault before any delivery and after only one cell: it stays closed. Install both cells: both sockets visibly light, the door physically opens, and Phase 2 begins. No duplicate pickup or installation is possible.
3. Attach the reactor, turn, brake, release, and reattach: the same cargo persists and trails physically. Cross the vault threshold with only the tug: Phase 3 waits until the attached reactor fully clears it.
4. Tow toward extraction: the reactor activates the beacon and gate cycle. Wait through a closed phase and attempt entry; neither body passes. Enter during open, linger with a body or cable in the doorway, and verify safe amber Closing until clear. Countdown and geometry agree.
5. Cross into the dock with only the tug, then with a partly docked, moving, or still attached reactor: no victory. Fully dock, detach, and settle for two simulation seconds: victory appears with the actual reactor still visible in place.
6. Pause during a gate cycle and during docking: all timers freeze. Reset: Phase 1 and original objects return. Load Review: Phase 3: valid late-game geometry and persistent REVIEW FIXTURE label appear. Repeat checks 4–5 there through the same mechanics; review loading itself must not grant victory.

If any mental check fails, fix and re-run all mental checks before output. The operator runs real validation afterward; no additional generation or tool-assisted repair is allowed.