Function spring_value 

pub fn spring_value(t: f64, config: &SpringConfig) -> f64

Solve spring animation at time t (seconds). Returns a value between 0.0 and 1.0 representing progress.

Constat #6: SpringConfig accepts any f64 (it’s schema-level, not range-checked at parse time), and rustmotion validate used to check nothing about it either. mass <= 0 or stiffness <= 0 fed straight into sqrt/division below produced NaN (sqrt of a negative/undefined ratio, or division by zero), and negative damping flipped the decay exponent’s sign so the “settling” oscillation diverged to +-infinity instead. Either poisons every transform/opacity value downstream once it merges into AnimatedProperties. validate_schema.rs now rejects these combinations as errors (belt), and this floor keeps the solver itself finite and bounded even if an out-of-band caller skips validation (suspenders) — see spring_robustness_tests below.

duration (issue #167 lot E, SpringConfig::duration): when set, t is linearly rescaled before it reaches the physics below — not the physical parameters themselves — so that spring_rest_time on the unscaled spring lands exactly on duration. The spring’s shape (oscillation count, overshoot amplitude) is entirely a function of damping/stiffness/mass, so rescaling only the time axis preserves it; see spring_duration_tests::duration_remap_preserves_shape. This does not resize whatever keyframe segment spring_value is being evaluated within — see the duration field’s doc comment on SpringConfig for why that is a separate, author-owned concern.