A prototype already says press this, arrive there. That is a test case. The useful part is that nobody wrote it: it came out of the design, and when the design changes the test changes with it.

## How it works

A flow in the Design surface is a graph: screens, and transitions with an event and an action. Pathrule compiles that graph into a sequence of simulator actions and runs it against your app in the [simulator](/docs/studio/simulator).

Taps are resolved by accessibility identifier or by label, which is the second reason the design's node ids travel into the code at handoff: the same id that makes a fidelity comparison exact makes the tap unambiguous.

## A hand-written UI test drifts. This one cannot.

A test written by hand describes the flow as it was on the day someone wrote it. The design moves, the test does not, and after a few months the suite is a record of an old product.

Here the flow and the test are the same object. Rewire a transition and the test takes the new route on its next run, because there is no second copy of the journey to keep in step.

## An authoring problem is not a test failure

This is the rule that makes the report worth reading.

A graph with a screen nothing reaches, or a transition whose trigger has no visible control, is a **design defect**. Reporting it as "step 3 failed" teaches you to distrust the whole run, and a report you distrust is a report you stop opening.

So the flow is audited before it is executed, and those problems are reported as what they are: something to fix in the design, separate from what the app did when the flow was actually run.