flagon-io/automation-lab

I added mod(a, b) to math.js. It returns a non-negative remainder, so mod(-1, 3) is 2. It throws a RangeError when b is 0. A negative b also gives a non-negative result, so mod(-1, -3) is 2. I added tests to test.js for positive and negative operands, an exact multiple, a negative divisor, and the zero case. node test.js passes, and I wrote the JSDoc comment directly above the function because the repo's house-style check requires it. I did not run that check itself or the other workflows. The new code sits next to the module.exports line and the end of test.js, so it may conflict with #5 and #12, which also edit math.js and test.js.

The modulo function implementation is correct and complete. The formula ((a % b) + Math.abs(b)) % Math.abs(b) properly handles negative operands to return non-negative remainders as required. Error handling correctly throws RangeError when b is 0. Tests comprehensively cover all specified cases: positive operands, negative dividend, negative divisor, exact multiples, and the zero divisor case. All tests pass. JSDoc comment is present and accurate.

Reviewed by g1t on Claude Haiku 4.5.

Infinite divisors give NaN: mod(1, Infinity) and mod(-1, Infinity) both return NaN because Math.abs(b) is Infinity and Infinity % Infinity is NaN. This is not in the issue and does not block merge, but it is worth either handling or documenting.

Checked the change against issue #13 and ran node test.js, which passes.

• mod(-1, 3) gives 2 and mod(-1, -3) gives 2, as required. Other cases (mod(7, 3), mod(6, 3), mod(-3, 3), mod(7, -3), mod(5.5, 2)) are also correct.
• b === 0 also catches -0, so mod(1, -0) throws RangeError.
• The new export is added to module.exports, and the JSDoc matches the one-line style of the other helpers.
• Only the new function and its tests change. Nothing else in the repo depends on the export list.

Non-blocking gap: mod(1, Infinity) and mod(-1, Infinity) return NaN, because Infinity % Infinity is NaN. The issue does not cover infinite inputs, so this does not need to block the merge. If you want to handle it, return a for finite a with an infinite b, or document the behaviour.

Reviewed by g1t on Claude Haiku 5.5.

Checked: read the diff against math.js and test.js at the checked-out head (the working tree matches the diff). Ran node test.js: passes. Ran the CI house-style loop from .g1t/workflows/checks.yml by hand: passes, since mod has a /** */ block directly above it. Probed edge cases by running the function: mod(7,3)=1, mod(-1,3)=2, mod(-6,3)=0, mod(-1,-3)=2, mod(-1e-20,3)=0, and non-integers behave. The result is never negative and never -0. mod(x, 0) and mod(x, -0) throw RangeError.

Conclusion: the change does what issue #13 asks and nothing else breaks. It is exported, and existing tests still pass.

Not blocking:

• The sign convention for a negative divisor is a deliberate choice. mod(1,-3) is 1, where JavaScript's % and Python's % would give -2. This follows the issue's "non-negative remainder" wording, so it is correct as specified. Worth stating in the README so later readers don't assume the usual convention.
• Non-finite inputs are not covered by the spec. mod(1, Infinity) and mod(Infinity, 3) return NaN. Acceptable, but untested.
• Merge conflicts with #5 and #12 are likely in the module.exports line and at the end of test.js, as the PR says. I did not check those branches.

Reviewed by g1t on Claude Haiku 5.5.