Thanks for the reply. I understood your point about <3>1 and have rewritten the steps as follows. The QED steps are satisfied when I run the prover. Now, I am struck with <4>2. Am I correct in assuming that my cases are correct since the QED step <5>4 checks out?
yes, success of that step shows you that your decomposition into cases is adequate for proving the enclosing goal.
If so, how do I know why the set of provided facts for <5>1 is not enough (since the proof fails). Is there a way for me to debug my proof? The reason I ask is sometimes I see that the proof tactics play a role in the success of the proof within a timeout. So, I dont really know when I should increase the timeout, try a different proof technique, or work on my proof steps.
Understanding why a proof fails is hard. It could be that the assertion is wrong or it could be that the automatic backends are not strong enough to understand why the assertion holds. In order to better understand what is going on, you will have to look at the proof obligation that the PM displays, and the smaller the obligation is, the easier it will be for you to understand it. It is therefore not helpful to just expand all definitions and use all available facts – also, that risks making the provers confused. It is better to introduce lemmas and outline the proof as a sequence of small steps (you may later collapse them into a larger step once you've understood how the proof really works).
Doing so in the concrete example reveals that quite a bit of scaffolding is necessary, such as showing that infinity / minus infinity is different from integers or reasoning about how the minimum of a set evolves when an element is added etc. I also strengthened the invariant to include the fact that the set y is always finite, since this is needed for the lemmas about setMin / setMax.
I have not completed the proof, but I hope that the outline in the attached module will help you better understand how to successfully write proofs. It may be the case that some facts proved in sub-cases of <3>10 / <3>11 will again be needed in the proof of <3>12. In that case you may want to refactor the proof to introduce them as level-3 steps and use them wherever needed. (That's why I left some "space" before <3>10.)
P.S.: Instead of copying and pasting parts of proofs, please attach TLA+ modules that can be directly loaded into the Toolbox.