Methods with a to but no from are drawn from the start node, like constructors #18

What happens

A method whose @StateRefinement has a to but no from, next to other @StateRefinements with a from, is drawn as an entry transition: an arrow from the start node, like a constructor. This rule came from #15.

Found while rendering study exercise A1_56 (javax.swing.undo.UndoManager). canUndo() and canRedo() are queries whose return value tells the state:

@StateRefinement(from = "redo(this) == redoable", to = "redo(this) == redoable && return")
@StateRefinement(to = "return ? redo(this) == redoable : redo(this) == notRedoable")
boolean canRedo();

In the redo diagram, canRedo [return] and canRedo [!return] come out of the start node next to new UndoManager():

Why it is wrong

• To a novice the start node means "how an object is created". canRedo does not create an UndoManager. It is a check on an existing one.
• In this exercise if (um.canRedo()) um.redo(); is exactly the guard that the verifier's hint suggests. The diagram should show it as a step from notRedoable to redoable, but it shows it as a second way to create the object.
• In the verifier (AuxStateHandler.getStates) a @StateRefinement with a to and no from has from = true: the method can be called in any state and moves to to. The first alternative whose from matches is used. So the from-less alternative applies in every state that the earlier froms do not cover. The parser already draws those edges (notRedoable --canRedo [return]--> redoable). The extra arrow from the start node is only about an object whose state is unknown (a field, a parameter). That case is not a state in the diagram.

Expected

Only constructors and factory methods (static methods that return the class) come from the start node. A method with a to but no from is drawn from every state that its earlier from= alternatives do not cover, and never from the start node.