Every real-world mechanize script has to, first and foremost, make no assumption as to which screen actually will pop-up next.   (It’s not enough merely to check for HTTP 202.)   You have to identify the screen:   did “The Monastery Gates” really appear?   And so on.   The next follow-on question is to be sure that you are (still) logged in ... a peculiarly frequent problem with this particular site, sometimes.   You do this by explicitly checking, every time, that you do indeed find text like “Log my_userid Out” at the expected spot, vs. “Log In” at that same spot.

A mechanize-script in actual production is not quite as simple as it first appears:   it must be a finite-state machine (FSM) design, because in the final analysis the host web-site is driving the bus.   Your logic must send the HTTP messages that you expect will work, but you always have to reconcile this with what actually comes back.   “Kilroy was an optimist” sometimes.

Fact of the matter is, a production mechanize-script is often two FSMs:   one which tracks the state of the host, and the second which tracks the state of what you are trying to do.