Requesting several operations together can reduce conversational overhead. Sending a chain of clicks internally would nevertheless obscure where work went wrong. Browser flow retains fresh target resolution, explicit expectations and a stopped-step trace.
Validate the whole declared boundary before effects
Flow receives a start and bounded steps with timeout limits. The current contract accepts one to six steps with each declared wait between 250 and 15,000 milliseconds. That bound is not a guarantee that the whole batch will finish within one such interval. Unit tests reject arbitrary code, excessive steps and excessive waits. It is a convenient small batch, not an unlimited scripting entry.
Declared navigation destinations pass scope and target checks before the first effect. This reduces the chance of discovering a forbidden later destination only after earlier actions. Preflight cannot eliminate subsequent site changes, so current-state checks still continue during execution.
Resolve every click from a current observation
Each click performs a fresh find and compares current name, role and required destination. Truncation and ambiguity stop it. References collected before the batch are not blindly pressed in order, since earlier actions can change the document.
A unique disabled or sensitive target still fails. The route then uses existing click-and-wait verification. Navigation and wait steps check their own expectations too. Batching does not create a bypass around ordinary Broker dispatch and outcome checks.
Return completed steps and the stopping point together
Trace retains step number, kind, verified status and destination. Failure paths return completed steps, failed step, error and disabled automatic replay. Uncertain dispatch retains a separate state rather than resending the input.
Receiving a batch reply does not mean the whole batch succeeded. Its status and trace must be inspected. A stopped result missing a final step cannot become complete. An outer task finish and a flow's partial-execution status are different evidence, so the caller must compare step results with the final work criterion.
Separate replaying the batch from repairing a failed point
A started-flow fingerprint blocks automatic repetition of the same batch. A narrow failure before the first click with no effects differs from partial execution after earlier verified steps. Replaying those steps could duplicate existing results.
The implementation retains remaining-step information after an uncertain click. Confirming its late result does not establish that all remaining steps ran automatically. The actual verified trace must be read. This batch is not a database transaction that rolls earlier actions back.
Keep the unit of verification unchanged
Unit tests cover strict workflow shape, semantic selection and expectations. Historical task comparisons and sequential-operation tests concern the inputs and completion criteria fixed then. The presence of flow code cannot establish completion of a new site's whole workflow.
I read the current flow, selection and matcher code and compared associated tests. I did not execute a customer workflow again. Fewer conversational calls do not establish a fixed speed or model-cost improvement for every task; that needs separate measurement. Keeping the measurement unit intact preserves a meaningful comparison.
Keep detailed execution evidence behind a short request
Short input is convenient for customers and agents, while a maker needs to know where work started and which steps finished. I reduced the outer request while retaining the inner trace.
Data import, approval and reporting in business software benefit from the same rule. A single process button can still expose stage outcomes and the stopping point. Batch convenience must not erase verification, so a user can choose the next needed inspection rather than press the same button again after failure.