The seed is the whole mechanism. A reduce over an empty array has to return something, and `0n` is the identity for addition, so it reads as the neutral choice. For a minimum it is not neutral. It is the floor of the domain, because the economic layer already clamps downside at zero: in the Zig kernel, downside is derived from net savings and clamped, and a genuine no-action case can be zero across every economic field [7]. Put the seed on the floor and the aggregate can only ever report the floor. min(6300, 0) is 0. min(4100, 0) is 0. min(1, 0) is 0 [6].
So the reported lowest p95 downside was not slightly off. It was short by the entire quantity, 6,300 cents [2], which is 63.00 in the base currency unit [1]. And the direction of the error scales with the risk: the worse the candidate, the more confident the zero.
The fix is constrained by two things that are easy to miss from outside the codebase. JavaScript's `Infinity`, the usual sentinel for a minimum, is unavailable, because money crosses this system as canonical decimal strings and must not pass through floating point; `bigint` has no infinity, and a `number` sentinel would break the numeric contract [14]. Throwing on an empty list was available but wrong, because emptiness is legitimate here: price coverage may not match forecast scope, and that run should be persisted as infeasible with an explanation rather than fail as an internal error [15]. What is left is the overload that the author landed on, `minBigInt(left, right)` and `minBigInt(values)`, which can still return zero for an empty list and keep the frontier schema stable, provided the non-empty path starts from a real element instead of a seed [16].
According to the dev.to writeup, the author expected the hard defects to be in percentile selection, amortization, or provider-specific eligibility [12]. The utility was small enough to read without stopping, which is roughly why it got read without stopping.
For this to be your bug rather than his, three things have to hold. You carry money as `bigint`, so the conventional sentinel is off the table [14]. You compute a min or max aggregate for presentation rather than for the decision itself [9]. And your tests assert the primary recommendation, the way the passing fixture asserted expected saving and p95 downside directly [10], rather than the summary fields. The reviewable pattern in a codebase like this is narrow: a reduce whose initial value is the identity element for a different operator than the one in the body.
