Diagnosing an interface you are building

You changed some CSS, or a script, and something moved. Or a button stopped responding and the console says nothing useful. This is the case Diwall was originally built for: a model that writes web code cannot see the result of what it wrote.

This one ships as a real scenario. Run it now:

diwall-rpa --scenario /opt/diwall/scenarios/exemples/depannage_local.json \
  --guide-version 1.3

The sequence

1 — Probe first, cheaply. --mode fast returns the accessibility tree and no screenshot. If the page is broken structurally, you know in about a second without rendering anything.

2 — Read the console. erreurs_js and erreurs_console come back in every answer. A blank page hiding a script error looks exactly like a blank page hiding a server error; the console tells them apart.

3 — Capture with numbering, if the problem is visual. --som shows what is actually interactive, which is often the answer on its own: an element you thought was a button is a styled <div> that no one can click.

4 — Prove the fix. Compare against a reference captured before the regression:

diwall-watch --url http://localhost:8080/ \
  --comparer-pixel /opt/diwall/references/localhost/reference.png \
  --guide-version 1.3

What this case demonstrates

The loop closes without a human in it. The model changes code, looks, reads the console, and compares against a known-good state — then decides whether to continue. Before, the same loop required someone to open a browser and describe what they saw.

That description was the weak link. It is what this whole site is about.

Why a screenshot is not enough →

Its limit

Pixel comparison has a noise floor of about 0.19 % — two renders of an unchanged page differ by that much. A regression smaller than the floor hides in it. For structure rather than appearance, compare structurally instead:

diwall-monitor-verifier --scenario page.json --reference page.ref.json