Many UI automation bugs happen at the exact moment a workflow crosses from preparation into an irreversible action.
The solution is to make that transition a first-class boundary.
Before the boundary
Before clicking the final Submit, Publish, Send, or Create control, the system can still validate and abort safely.
Useful checks include:
- exact hostname and account;
- expected editor or form;
- content bound to the intended target;
- required fields present;
- no login, CAPTCHA, rate-limit, or rejection state;
- no unexpected navigation.
At the boundary
The final server-side action should have a strict budget of one.
That does not mean every visible button labeled “Publish” is necessarily the final request. Some interfaces open a local confirmation panel first. What matters is that the workflow recognizes the actual server-side submission and permits it only once.
After the boundary
After submission, the system should become read-only.
It should verify:
- whether the browser reached a public permalink;
- whether the expected title is present;
- whether the expected body persisted;
- whether the result belongs to the same authorized site.
If the browser times out or the response is ambiguous, the correct next action is reconciliation, not another submit.
Why this matters
A single-submit boundary turns a vague automation instruction into a small transaction protocol.
It reduces duplicate posts, duplicate registrations, repeated messages, and other accidental mutations while still allowing the workflow to operate autonomously.
For browser agents, this is one of the most useful design rules: be flexible while observing, deterministic at the write boundary, and read-only immediately afterward.
Top comments (0)