Car Brick Wall Crash

<instructions>
Generate a single, self-contained HTML file that runs directly in a browser.

Build a realistic 2D crash experiment on a canvas: a car accelerates from the left side of the scene and crashes into a freestanding brick wall. The wall is made of individual physical bricks, not a static image. When the user starts the test, the car must hit the wall, transfer momentum into the bricks, and cause the wall to deform, collapse, scatter, or partially survive according to the simulated physics.
</instructions>

<core-experience>
The page has one primary experiment view:

- A side-view test track.
- A car waiting on the left.
- A brick wall standing on the right.
- A clearly visible "Test" button.
- A settings menu that lets the user change the experiment parameters.

When the user clicks "Test":

1. The scene resets to the current settings.
2. The car launches toward the brick wall.
3. The car collides with the bricks.
4. The bricks respond as separate bodies with mass, friction, gravity, contact, rotation, and momentum transfer.
5. The simulation continues until the debris settles or the user resets/runs another test.

The result should feel like a real physics experiment, not a scripted animation.
</core-experience>

<default-experiment-values>
These defaults are mandatory. They must be the initial values on first load so every model runs the same baseline experiment.

- Car speed: 22 m/s
- Wall columns: 12 bricks wide
- Wall rows: 8 bricks tall
- Wall depth layers: 2 layers thick
- Brick mass: 2.5 kg per brick
- Brick size: 0.50 m wide x 0.24 m tall
- Gravity: 9.81 m/s2
- Brick friction coefficient: 0.72
- Brick restitution: 0.18
- Car mass: 1,250 kg
- Car width: 4.2 m
- Car height: 1.45 m
- Ground friction coefficient: 0.85
- Simulation scale: 80 pixels per meter
</default-experiment-values>

<settings-menu>
The settings menu must let the user configure at least:

- Car speed, in meters per second
- Wall columns, the number of bricks across the wall
- Wall rows, the number of bricks stacked vertically
- Wall depth layers, the number of overlapping brick layers that make the wall thicker
- Brick mass, in kilograms per brick

Changing settings must not silently change unrelated parameters. The user should be able to run the same experiment repeatedly with the same settings and get stable, comparable behavior.

Use sensible min/max ranges:

- Car speed: 5 to 45 m/s
- Wall columns: 4 to 24
- Wall rows: 3 to 16
- Wall depth layers: 1 to 5
- Brick mass: 0.5 to 12 kg
</settings-menu>

<physics-requirements>
The simulation must prioritize physically plausible behavior.

The car:

- Has mass, velocity, momentum, and collision shape.
- Moves horizontally on the track before impact.
- Slows down because of impact and ground friction.
- Must not pass through the wall unrealistically.
- Should show compression, tilt, bounce, recoil, or visible impact response if the implementation supports it.

The bricks:

- Are individual rigid bodies.
- Stack into a coherent wall before impact.
- Fall under gravity.
- Collide with the car, the ground, and each other.
- Rotate when hit off-center.
- Transfer force through neighboring bricks.
- Can slide, topple, scatter, or remain standing depending on the test parameters.

Collision handling:

- Prevent obvious tunneling through bricks.
- Resolve overlap in a stable way.
- Conserve momentum well enough that heavier bricks and lower car speed visibly change the outcome.
- Use friction and restitution so bricks do not behave like frictionless rubber.
- Keep the simulation numerically stable across the full settings range.
</physics-requirements>

<visual-requirements>
The scene should be clear, readable, and satisfying to watch.

- The car should be recognizable as a car, with body, cabin, wheels, and visible forward motion.
- The brick wall should look like a real staggered brick wall, with alternating seams between rows.
- Bricks should remain individually visible during collapse.
- Add impact feedback such as dust, debris particles, brief camera shake, or tire skid marks if it improves realism.
- Show the ground plane and enough environment context to read scale and motion.
- The canvas must resize cleanly to the browser window.
- The test should run smoothly at normal laptop screen sizes.
</visual-requirements>

<interface-requirements>
- Include a "Test" button that launches the experiment.
- Include a "Reset" control.
- Include a settings menu or panel for the configurable parameters.
- Display the active parameter values clearly.
- Display basic experiment telemetry such as current car speed, elapsed time, and number of moving bricks.
- The initial page state must already show the default car and default brick wall before the user presses Test.
</interface-requirements>

<determinism-and-comparability>
This is a benchmark prompt. The default run must be comparable across models.

- Use the mandatory default values exactly.
- Avoid hidden randomness in the baseline test.
- If randomness is used for optional dust or visual effects, it must not change the physical result.
- The same settings should produce the same physical outcome on repeated runs.
- Do not fake the crash with pre-scripted brick positions.
</determinism-and-comparability>

<quality-bar>
This should feel like a serious physics sandbox compressed into one HTML file.

The best result will demonstrate:

- Strong spatial reasoning.
- Real-time rigid-body simulation.
- Stable collision resolution.
- Clear UI for experiment controls.
- High visual polish without sacrificing physical plausibility.
- Clean, maintainable code organization inside the single file.
</quality-bar>

<output-format>
Output ONLY the complete HTML file. No explanations before or after.

The file must start with `<!DOCTYPE html>` and end with `</html>`.
</output-format>

<important>
- You MUST write the result directly into a file named "index.html" on the user's computer. The user should not have to see or handle the code.
- The page `<title>` must be your model name, for example "GPT 5.5" or "Claude Opus 4.8".
- The visible heading or brand in the page must also be your model name.
- Do not ask clarifying questions. Make the necessary design and engineering decisions yourself.
</important>