Diwall

English
Download 1.24.4

Architecture

Why Diwall is built the way it is: what it guarantees, what it refuses, and where its limits are.

Diwall is not a service. It is a command that a model runs, reads the answer of, and runs again — one browser per call, nothing listening in between.

model (any model that can run a shell command)
   │  diwall-shot --url … --som --a11y --guide-version 1.3
   ▼
shot.py ── Playwright ── headless Chromium, one process per call
   │        credentials resolved here, and only here
   ▼
stdout   one JSON object: succes, boussole, capture, elements_som, a11y_tree, evaluations
disk     /tmp/diwall/<operation_id>/*.png      captures
         /var/log/diwall/operations.jsonl      operations log
   │
   ▼
the model reads the JSON and the capture, decides, and calls Diwall again

diwall-rpa hands a whole scenario file to the same shot.py, in a single call.

Two consequences follow from the diagram.

The live state of the page does not survive between two calls. Each call starts a new browser. Cookies and storage can be carried over (--sauver-session, --reprendre-session); a ticked checkbox or a half-filled form cannot. A sequence that depends on that kind of state belongs in one scenario. → The session does not survive between two calls

What the model reads, its provider receives if the model is hosted. Diwall’s output is written to be read, and the model you choose decides where it goes next. → What Diwall does not do behind your back

In detail