You have a staging copy of your shop, a test account and a folder of tests, and you want to know whether sign in, add to cart and checkout still work after today's change. This is automated web testing at its smallest: one flow, one test command, one result you can read. FlowLatch opens the folder, runs the command through Shell and shows the real exit code on a card. If the flow fails, it points at the line and proposes a fix as a diff, and you decide whether to accept it. The steps below take 4 actions from folder to result. Work only on an app you build or are authorised to test, use the test account and fake data, and use the test mode of your own payment set-up for the payment step, never a real card. Email checks go to a test inbox set up for the test.
Start FlowLatch, choose the folder that holds your tests as the working folder, and pick Ask first so every action that changes something waits for your OK. Connect a model if you have not yet, and use the Test button to check the endpoint.
Ask for the structure of the tests. list_dir and glob show the files, and read_file opens the checkout flow so you and the agent start from the same text before anything is run or changed. Each action appears in the chat as a card with its result.
Tell the agent which test command your project uses. Shell runs it on Windows or in WSL, and the card shows the full output and the real exit code, not a summary. Expand the card if you want every line, and use grep on the output to jump to the failing step.
On a failure, ask what the output says. The agent proposes an edit as a diff, and nothing is written until you accept it. Reject what looks wrong, then run the command again to see the new exit code. Repeat until the flow passes or you know what to change in the app.
tests/listedtests/checkout-flow-test.txtloadedyour test commandexit 0FAIL reports/0 matches# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page textThis outline is plain text and lives in the repository next to your tests. Your own test framework turns each step into code, and FlowLatch uses the file as the specification when it writes that code, runs it and compares the result with the three expect lines. Change the product name and the pages to match your own staging app.
Start by asking where the tests are. list_dir shows the folders, glob lists every file that matches a pattern such as the checkout tests, and read_file opens the ones you care about so you can see how a flow is built today. grep then searches for the selectors and the waits they use. All of this only reads, so it is a sensible first step in Plan only mode, which writes a plan and runs nothing. The plan survives a restart, so you can come back to it tomorrow. When you are ready for real runs, switch to Ask first and read the plan once more. Write down the flows that are already covered, so you know which ones are missing a test.
After a runtime upgrade, e2e suite failures often come from the environment rather than from your app, so read the first error before you touch a test. Shell runs your test command and the card keeps the full output and the real exit code, which is the only honest pass or fail. grep can pull the failing step out of a long log. Ask for a plain explanation of the error in the chat, compare it with the output, and only then decide whether a test file needs an edit. If the error names a missing package or a changed setting, fix the environment first and run the same command again. Often the suite then passes with no edit at all, and the exit code on the card proves it.
Selector maintenance in ui test automation is the most common chore, because a changed layout breaks selectors that were tied to it. grep finds the old selector in every file, read_file shows the steps around it and edit_file proposes a stable label or test id in its place. In Ask first the agent pauses and shows the diff. Accept the lines that look right, then let Shell run the command again. A green exit code after the edit is the result you wanted, and the diff stays in your repository history for the next reviewer. If the command still fails, read the new output before you ask for another change, because a second edit on top of a wrong guess makes the cause harder to see. Keep each diff small enough to read in one sitting.
When a ui e2e test breaks, the real cause is often a fixed wait, shared test data or the order of the tests, not the app. Ask FlowLatch to run the failing test several times with the same command and report each exit code. Mixed results mean the test is flaky. If your framework saved a screenshot, ocr reads the text in it, and the page text from the failed run adds a second clue. Fix the wait or the data in a diff, review it, and run the test again. Give each test its own data and reset it, wait for a visible condition instead of a fixed pause, and keep tests independent of each other's order. Repeat the run once more after the fix; one pass proves little.
