Dreaming

Dreaming reviews your recent test runs and proposes small, reviewed improvements to your tests' rules — turning the manual analyzing-failures loop (read the report, find the cause, fix it in the right place) into suggestions you simply approve. You start a pass whenever you like; it runs off to the side of your test runs, so your suite gets more reliable the more you run it. You stay in control: Dreaming only proposes changes; nothing is edited until you approve it.

How it works

Once you've reviewed a test's proposals, those runs won't be proposed again — each run is only ever analyzed once. Later passes instead check whether the changes you accepted actually helped (see below). While proposals are waiting for your review, Dreaming won't start another pass, so review them before you analyze again.

What Dreaming changes

• Rules (rules.md) — the guidance your agent follows for a test or folder. Most proposals are here: a new rule learned from a failure, or a small refinement to an existing one. See agent behavior for how rules shape a run.
• App knowledge (ui.md) — facts about the app under test.
• Setup / teardown (setup.md, teardown.md) — steps run before and after a test.
• Procedures (procedures/*) — your reusable, shared steps.
• Test definitions — occasionally, a proposed tweak to a test's own steps.

Dreaming only ever appends a line or refines an existing one — it never rewrites your files wholesale, and it never bakes in brittle pixel coordinates. Per test and file it proposes at most one edit, combining everything it learned. It does not change your device information — that lives with your device profiles, not in a prose file.

When it's not your test — advisories

Sometimes the trouble isn't your test at all. A tool (including your own custom tools), the AskUI SDK, or the environment around the run can be at fault — and no change to your rules or tests would fix that. When Dreaming spots something like that, it doesn't invent a change. Instead it adds a short advisory to your review: a plain-language description of what looked wrong, and a prominent pointer to email an AskUI solution engineer at support@askui.com.

You acknowledge or dismiss an advisory — nothing is edited either way. It's simply Dreaming telling you "this one needs a human, not a test change."

It's experimental — turn it on deliberately

Dreaming is an experimental feature. You find it under Extending → Dreaming. When you switch it on, a warning appears explaining that learned changes can, over time, drift and steer your tests in the wrong direction. You tick a box to confirm you understand, then press Turn on Dreaming (the button stays disabled until you tick the box). Before you start, make your own backup of your project — copy the whole project folder somewhere safe, or zip it up. The setting is per project: every project starts with Dreaming off.

The Extending → Dreaming tab

Everything about Dreaming lives on one tab — Extending → Dreaming:

• Turn it on (the experimental warning above).
• Choose the analysis model. On the AskUI hub, we recommend — and default to — the best available model. Dreaming runs only occasionally, so stronger reasoning over your runs is worth far more than saving a few cents; you can instead pick "same as your test runs" or a specific model. If you bring your own model, Dreaming uses the same model as your test runs by default — untick "Same as for my test runs" to configure a separate model for Dreaming (endpoint, model, API key), for example a more capable one.
• See what it costs. After each pass, the tab shows the cost of the last analysis and how many analysis sessions you've run. The same cost also appears on the review banner and at the top of the review page, so you always know what a round of Dreaming cost you.
• Run it on demand. If there are new runs to analyze, an Analyze now button starts a pass right there — the same one the Dashboard offers.

Good to know

• It starts fresh from when you turn it on. Dreaming only learns from runs you make after enabling it — turning it on never trawls your entire history, so you won't come back to hundreds of old runs waiting to be analyzed. Turning it off and on again starts fresh once more.
• It respects edits you make yourself. If you changed a test or rule after a run and only then run Dreaming, it works from your current version — it won't undo your change or re-suggest something you've already fixed.
• It won't change things for the sake of it. If your tests keep passing, Dreaming proposes nothing — that's the expected, healthy outcome.
• It shows how confident it is. Each suggestion says how many of your recent runs back it up (e.g. "4 of 5 runs"), so a recurring problem stands out from a one-off.
• It checks whether its past changes helped. From your real runs since a change, Dreaming works out whether it helped — and if a change didn't, it proposes a revert in your next review (you still approve the undo). If you edited the file yourself in the meantime, it stays out of the way.
• It remembers what it changed, so it won't flip a file back and forth from one session to the next.
• It pays off most on suites you run repeatedly (for example nightly regression) — that's where the accumulated lessons compound.
• It runs off to the side of your test runs and never interferes with or slows down one. If you switch projects while a pass is running, it finishes and the results wait in the project it analyzed.
• If analysis can't finish (for example the model provider is unreachable), the banner tells you, and your files are left untouched.
• If a file a proposal targets was deleted before you accepted it, that change is skipped with a notice instead of recreating the file.