A machine that has to walk

Build a browser simulation of a Theo Jansen strandbeest — a walking machine driven by the Jansen linkage — that actually walks across uneven terrain under rigid-body physics.

Context you should know: this is going into a video watched by a large audience, your build runs on camera against two other frontier models, and your work will be credited to you by name. Every model gets this identical prompt. This one is a test of whether you know the mechanism, not whether you can animate something that looks like it.

Requirements:

1. **The real Jansen linkage, at the canonical proportions.** Twelve links per leg in the correct topology, using the published "holy numbers" link lengths that Theo Jansen derived. Getting the geometry right is part of what's being evaluated — look it up and verify it rather than approximating. A leg built at wrong proportions produces a visibly wrong gait, and that is the point of the test.

2. **The foot path must be the correct Jansen curve** — a long flat bottom stroke with a high lifted return. Draw the traced foot path as an overlay that can be toggled on, so the curve is inspectable. If your foot trace isn't flat along the bottom, the linkage is wrong.

3. **Rigid-body physics, not animation.** Every link is a body with mass, connected by real constraints, solved by a physics engine or your own solver. The whole machine is a free body under gravity. It stays upright and moves forward *only* because its feet push against the ground through friction. Nothing is keyframed, nothing is scripted along a path, and the body's position is an output of the simulation rather than an input. If you disabled the crank, the machine should stand there and then fall over — not glide.

4. **A full walker, not a single leg.** At least six legs (three pairs) on a shared crankshaft with the correct phase offsets between pairs, so there is always ground contact and the gait is stable. Both sides of the machine.

5. **Uneven terrain.** Procedurally generated ground with slopes, steps, and scattered obstacles — the kind of surface that exposes a machine that is secretly sliding. It has to keep walking across it, recover from stumbles, and it is acceptable for it to eventually be defeated by terrain that is genuinely too hard.

6. **A live parameter panel** listing every link length, the crank speed, ground friction, and gravity, all editable while it runs. Changing a link length must rebuild the linkage and visibly degrade the gait — that is the proof the simulation is real and not a costume over an animation. Include a reset-to-canonical button and a readout of distance traveled and average speed.

7. **Camera and presentation.** A camera that follows the machine, plus a free orbit, and a wireframe/skeleton toggle that shows the linkage bars and joints over the rendered mesh. It should look considered — proper materials and lighting, a real sense of scale and place, a machine that looks built rather than sketched. Untextured primitives and programmer art are failures.

8. **Sixty frames per second** with the full machine, terrain, and constraint solve running. Frame drops are visible on camera. Profile it and fix it.

9. **Single self-contained `index.html`.** Any library via CDN — three.js, a physics engine, whatever you want. No build step, no server, no API keys, no hotlinked assets. You have free reign to look up what libraries exist and how to use them.

10. **QA it by running it.** Watch it walk for a sustained distance. Confirm the foot path is the correct curve, the machine advances on friction rather than sliding, it survives the terrain, the phase offsets keep it stable, and that editing a link length breaks the gait the way it should. Fix what breaks.

Work completely autonomously. Do not ask for anything until it's finished.

DONE when: the machine walks a long distance across uneven ground on real physics, the traced foot path matches the Jansen curve, and mis-tuning a link length in the panel visibly wrecks the gait.