My understanding of the traditional color theory (Itten's) is
that it's based on the HSV space. The rules are governed by H, and
the S and V values should not alter the color model.
The graphical UI in your current implementation implements H
and S only, which is fine for simplicity. I can adjust S and V via
the HSV sliders. However, I have noted that the H value will shift
when using the S / V sliders. Consequently, the shifted H value
would modify the color values as well. As such, for example,, using
the default setting for the analogus rule, sliding the S or V
sliders left and right would eventually turn all the swatches into
the single hue.
This looks like some kind of rounding error to me. Either you
are rounding off values too soon in the color space conversion, or
the reference space used is not able to support all the colors
defined in the HSV space. But it is clearly a bug.
Now that I've tried the custom rule which allows me to unlock
the arms, I think that you are likely to be using RGB as your
internal base color space, and then performing color value
conversion from that space. However, it also seems like that you
are storing integer values only, so sliding S values back and forth
will always point the H values to either pure R, pure G or pure B.
Perhaps if you use float values inside the program would eliminate
the bug I explained above?