A rule needs something on both sides of it

[dmitrat]

Reported from a screenshot: the connection's own context menu drew Database…, Close database, a rule, Create ▸, then two rules with nothing between them, Refresh, and two more rules below it with nothing after them at all.

What it was

The other half of the change that gave each node its own menu (#219). Every item in that shared menu learned to hide itself where it does not apply; the five separators - the only elements with no condition on them - were left drawing the shape of a menu that is no longer there.

Measured over all fourteen kinds of node, and every one of them was wrong:

node	drawn before
connection	Database…, Close, ─, Create, ─, ─, Refresh, ─, ─
any folder	─, Create, ─, ─, Refresh, ─, ─
table	─, Create, ─, Select, Edit, Structure, Definition, ─, Refresh, ─, Rename, Empty, ─, Drop
sequence	─, ─, ─, Refresh, ─, ─, Drop
column	─, ─, ─, Refresh, ─, ─

Even the table - the node that has one of everything - opened with a stray line.

The fix

Each separator asks whether both sides of it are there. Refresh applies to every node, so anything above it always has something below - which is why the first three rules ask only about what precedes them.

The guard

ARuleHasSomethingOnBothSidesTests reads the real menu: the order and the conditions come from DatabaseExplorer.axaml, the answers from the real ViewModel, so it walks every node type and reports the sequence that would be drawn. It asserts the exact menu of a connection, a folder, a column and a table, and the general rule - no leading rule, no trailing rule, no two running together - over all fourteen.

• Red before the fix on all fourteen node types.
• Red again with each of the five conditions removed one at a time.
• Driven afterwards against a fresh build: the connection, a folder and a table draw what the fixture says.

Studio: 1019 green.

🤖 Generated with Claude Code