armature copy rotation weirdly flips the direction I am trying to make an animation of closing/opening of a Book. For this I'm using bones to control the same. I have added the bones as shown in the image, the closing of the covers are controlled by a controller bone on top. But I have an issue in completing the animation with the constraints.

Process followed to achieve it:  (Note: Careful with the naming of the bones, check the image)


The bones are parented as shown in the image. And then the Cover.L, Cover.R, edge.LRoll and edge.RRoll , I have added the bone constraint of "Copy Rotation" in the local space. The middle two bones (edge.LRoll and edge.RRoll) take the rotation from the controller and the side two covers take the rotation from their opposite edges (i.e Cover.L takes from edge.RRoll). (I have named the bones in the picture and also represented the parenting with the yellow arrows)

Basically this should help in coordination of the rotation of the covers with respect to the rotation of the edges, when the controller is rotated. Now I added "Limit Rotation" to the middle edges so that they don't rotate more than 90 degrees in local&amp;World space respectively for R and L edges. Everything works fine till now as constraints for middle edges works well.

Now I want to constraint the rotation of the Covers from 0-180 degrees in World space and added the same to both the covers.


THE PROBLEM:  As I added the constraints of limit rotation to covers, the Cover.L works well in its boundaries, but the Cover.R weirdly flips its direction the moment it nears the 180 degrees. SO I want to fix this issue


Here is the constraints I have added (May be useful before opening the blendfile)


So, I am unable to understand what is wrong with this. Please guide me how to fix this issue?? Im I doing wrong somewhere? or is it a bug?

WHAT I HAVE TRIED
 - I have tried limiting the rotation with respect to the local space, changing the limit angles but this doesn't give proper limits.
 - I saw somewhere that the "roll" of the bones can sometimes cause rotation issues, so I even kept all the rolls to Z axis. 

Btw: I am new to the working on Armature, that is the reason I might have been asking very basic issue. I have been following this tut https://www.youtube.com/watch?v=hjZa-h_f5Ts&amp;t=6s

My blend File for further investigation: https://pasteall.org/blend/2b57b74d8746407ba12897f0c5d9559b
After researching this issue, I get the impression that there is something problematic about how Blender calculates rotations internally which makes rotation constraints reset bone values to zero whenever exceeding +/-180 degrees. It turns out that Blender continues calculating rotations even within ranges for which constraints are currently limiting rotations, and that these internal rotation calculations can continue after passing the constraint thresholds. What I find particularly baffling is that unchecking the For Transform checkbox for a Limit Rotation constraint stops "out of bounds" rotation values from being reported in the Transform panel, yet this doesn't actually stop the calculations themselves, which will still go on to create flips when transforming past +/- 180 degrees. This leads me to wonder what changing this setting meaningfully, operationally achieves, because it doesn't do anything to change this insufferable behavior. 

I noticed in the video that the author doesn't seem to have your issue. But then again, I don't think he ever rotated the control bone far enough at any point to tell me for sure that his rig wouldn't have done what yours is doing. So it's not clear that his rig would behave differently than yours if pushed past +/- 180 degrees. 

Some elsewhere have suggested creating drivers to address this problem, which seems to me like a very labor intensive workaround for something that shouldn't even be a problem. I noticed that the author creates drivers toward the end of the video, and I don't see any drivers in your file. I don't know that adding these drivers would have solved your issue, as I only skimmed the video. But I found it of possible interest that you didn't have any drivers set up before reporting this issue. 

I can't find any problems with the rig itself, but I could have missed something. I have found other links to similar questions which either go without answers or explicitly report that there is no solution.

I would really like to see a satisfactory solution presented, personally.