Interdependent Inputs With Rollback

Four inputs — a number, a select, a range and a number — each of which must not exceed the one to its right. An edit that would break the chain does not get clamped or merely flagged: it rolls back to the value of its parent.

This exposes shaky state modelling faster than almost anything else on the list. Four fields with pairwise constraints invite four ad-hoc if statements, and the result is correct for the case the candidate had in mind and wrong for the others.

Naming the relationship as data fixes it. A map from each field to its parent means one rule covers all of them — including the fact that the last field is unbounded, which falls out of it having no parent rather than needing its own branch.

The direction most people miss is downward. Rolling back handles raising a field past its parent. It does nothing about dragging the last field down below the one before it, which breaks the same chain from the other end. Walking left from the edited field and pulling anything now too large down with it covers that in a few lines.

The guard that matters most looks like a formality: check Number.isFinite before comparing anything. Number("abc") is NaN, and every comparison against NaN is false — so a corrupt value passes every bound check, lands in state, and the form silently stops enforcing anything at all.

The range input is in the requirements deliberately, because it fires continuously while dragged and any implementation that fights the user shows up immediately.