UiPath desktop automation, rewritten as a selector expression language with operator precedence

What every UiPath explainer leaves on the table

Open ten guides about driving desktop apps from a script. They will all describe the same XML form: one tag per element in the path, attributes as flat key=value pairs, a Strict mode that requires every attribute to match exactly, a Fuzzy mode that lets attributes drift with matching:aaname='fuzzy' and fuzzylevel:aaname='0.4'. They will describe Studio's Selector Editor (Ctrl+E) and the UI Explorer overlay. They will mention anchor-based matching for elements with no useful accessibility name. None of them present the option that this page is about: a selector grammar with parentheses, operator precedence, and a real parser. That option exists. It is the surface Terminator chose because the operator writing the workflow is now often an LLM, and an LLM is much better at composing an expression than at hand-editing XML fragments inside a designer.

The selector AST, top of selector.rs

Twenty-three variants. The interesting ones for a reader coming from a UiPath background are the five spatial variants and the boolean group. UiPath has spatial matching through anchors, but it is an activity that wraps two selectors. Here it is a single selector token (rightof:) that takes another selector as its inner argument and parses the same way as everything else.

The parser. Shunting Yard, three precedence levels, no surprises.

Or has precedence 1, And has precedence 2, Not has precedence 3. The output queue holds Selector values, the operator stack holds tokens. Same algorithm Dijkstra wrote for arithmetic expressions in 1961, applied to a tiny boolean algebra over UI matchers. The full implementation is fewer than seventy lines.

Why >> is parsed before everything else

Descendant chaining is not a boolean operator. (role:Window && name:Notepad) >> role:Edit means: find a Window whose name is Notepad, and inside that, find an Edit. Each side of >> is itself a complete selector expression. The From<&str> implementation splits on >> first and recursively parses each segment, producing a Selector::Chain. Inside each segment, the boolean operators are then resolved with the Shunting Yard pass.

Side by side: same target, two surfaces

Notepad's text area is a single element in the Windows UIA tree. UiPath addresses it with an XML fragment configured in Studio. Terminator addresses it with a single string parsed into a chained boolean expression. The runtime does the same thing on both sides; the authoring surface is the part that differs.

<!-- A typical UiPath selector. Edited in Studio's Selector Editor (Ctrl+E).
     Attributes inside one tag are an implicit AND.
     There is no OR, no NOT, no parentheses, no precedence. -->
<wnd app='notepad.exe' cls='Notepad' />
<ctrl name='Text Editor' role='editable text' />

Six recipes that exercise the grammar

Each one is a single string. Each one parses through parse_atomic_selector for the leaves and parse_boolean_expression for the operators. None of them require a designer or a manifest file.

What happens between desktop.locator(...) and the click

Four actors, eight messages, one round-trip through the parser, one walk of the live UIA tree. The assistant calls the SDK, the SDK constructs a Selector via From<&str>, the engine walks the chain, and a UIElement comes back wrapped in a Locator. After that point, .click(), .typeText(), and friends are all that remains.

With the grammar vs. without it

The same intent, two authoring loops. One ends with a person in a designer dragging a UI Explorer crosshair and toggling Strict / Fuzzy on a per-attribute basis. The other ends with a string in a file an AI assistant just wrote, parsed in microseconds, and either an executable element or anInvalid variant the runtime can refuse to act on.

What a real MCP turn looks like on stdio

One valid selector chains, walks the UIA tree, finds the element, and clicks. One malformed selector parses into Selector::Invalid and never reaches the engine. The assistant sees both responses on the same channel and can react in the next turn.

The four steps that get this wired into your assistant

Nothing extra to install for the grammar specifically. It comes with the Rust core, which the Node and Python SDKs both link against, and it is the same parser the MCP agent uses when an AI assistant emits a selector.

The comparison row that belongs in every roundup

Most comparisons of UiPath alternatives stop at license type, supported operating system, and recorder capability. The selector representation is the row that decides whether an LLM can author a workflow without a designer.

The numbers that describe the surface

0 file (selector.rs), 0 Selector AST variants, 0 precedence levels (Or=1, And=2, Not=3), 0 spatial operators (rightof, leftof, above, below, near), 0 descendant chain operator (>>), and 0 typed Invalid variant the parser returns instead of letting a malformed selector match anything.

Where this leaves UiPath, and where it does not

UiPath remains the right tool for an organisation that wants a designer-first authoring loop, a hosted control plane (Orchestrator), formal enterprise support, and a marketplace of pre-built activities. Terminator does not replace any of that. What Terminator replaces is the part of the workflow where a developer or an AI assistant is going to write code anyway. For that part, an XML fragment in a designer is a strange interchange format, and a parsed expression language is a more honest one.

Install with claude mcp add terminator "npx -y terminator-mcp-agent@latest". Ask your assistant to call get_window_tree on a running app. Watch what it emits as a selector string. The string will be a single line that parses cleanly through selector.rs. That is the entire pitch.

Frequently asked