A second profile proves the solver is general: half gravity, a taller hull, a bigger step — and one apex checked by hand #152

src/engine/physics.test.ts is new: the solver walked under two profiles that share no number, in a world of plain boxes with no game in it. WALKER is 600 u/s² of gravity, 200 u/s, a 20-unit step and a 40×40×64 hull; DRIFTER is half the gravity, a 450 u/s jump, 320 u/s, twice the step and a 60×60×120 hull. Every assertion is computed from the tuning it was handed rather than from a number typed twice, and the apex is checked against a hand calculation with its units written out: v₀ = 300 u/s under g = 600 u/s² gives v₀²/2g = 75 u at v₀/g = 0.5 s = 32 ticks at 64 Hz, and 450 u/s under 300 u/s² gives 337.5 u at 1.5 s — the half-step integrator samples v₀t − ½gt² exactly at tick boundaries, so the sampled peak is the analytic apex and both are asserted to the unit and the tick. Friction and its stop-speed floor, the air cap and the one-tick air gain, the step onto a ledge inside the step size and the stop against one above it, the three speeds, the crouch rate and the strafe-jump gain are each asserted under both profiles; stuck and groundUnder are exercised with both hulls, neither of which is 32×32×72, including a post and a shelf the wide hull reaches and the narrow one does not.

The file is worth checking by mutation, which is how I checked it: re-bake any field of MoveTuning or Hull into src/engine/physics.ts — tuning.gravity → 800, tuning.stepSize → 18, hull.radius → 16, and so on for all fourteen — and at least one test in the new file fails. No production code changed in this pull, so the golden digests are untouched bit for bit; bun test is 683 pass, 0 fail.

src/client/movement.test.ts loses the second-tuning half it was carrying (that is now the engine's job) and keeps Counter-Strike's own assertions, gaining exact ones for the 130 and 85 u/s walk and duck speeds, the 64/46 eye heights and the three-tick drift to 20.5 u/s. GUIDE.md's physics section and README.md's engine list point at the new file; the seam table's tuning row is split into the mover's pair (movement.CS_MOVE/movement.CS_HULL for the shooter, nothing for the range, whose eye stands still) and the rest (targets.STANDARD, targets.EYE and the drills).

One thing I did not change: CONTACT = 2 in src/engine/physics.ts is a real scale dependency — the solver's ground-contact slack is in the caller's units, so a profile written in metres would treat a floor two metres down as underfoot. Both profiles here are of one scale, so no test trips it, and moving it would either change the shooter's arithmetic (and its digest) or widen MoveTuning, which is a design call beyond this issue. It is now stated plainly in the test's docstring and in the guide rather than left as the "nothing below reads a scale" claim.

🤖 Generated with Claude Code

Closes #124