Why verified construction matters

A browser can report that a click completed even when the game rejected the request, changed route, opened an unexpected modal or accepted the build after the automation timed out. Recording success at that point creates false state.

The larger risk arrives on retry. If the first action actually succeeded but the client did not observe it, repeating the same instruction can spend resources on unintended work or advance a different location. Verification exists to close that uncertainty gap.

TBot rechecks the account, world, selected village, route, target location and current plan revision immediately before mutation-capable work. Earlier observations help planning, but they are not trusted forever.

If the visible Kingdoms surface no longer matches the planned instruction, the item is not forced through. It remains waiting or blocked until a later snapshot produces a coherent context.

A useful postcondition describes game state, not browser mechanics. Depending on the instruction, proof may be a specific queue entry, a new level, a changed resource balance or another exact transition expected from that action.

Generic page movement or a disappearing button is weaker evidence. TBot favors the narrowest live outcome that can show the planned work was accepted for the intended village and location.

Before an irreversible attempt, TBot can persist a guard describing the intended action. If the browser stops, the page times out or the app restarts, that guard tells recovery what must be reconciled before another attempt.

This does not make automation infallible, and construction support remains Beta. It does make uncertainty explicit: verified success, a known blocker, an operational failure and an ambiguous result are different states instead of all becoming ‘clicked.’