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