Architecture

Diwall n’est pas un service. C’est une commande qu’un modèle lance, dont il lit la réponse, puis qu’il relance — un navigateur par appel, rien à l’écoute entre les deux.

modèle (tout modèle capable d'exécuter une commande shell)
   │  diwall-shot --url … --som --a11y --guide-version 1.3
   ▼
shot.py ── Playwright ── Chromium sans interface, un processus par appel
   │        identifiants résolus ici, et seulement ici
   ▼
stdout   un objet JSON : succes, boussole, capture, elements_som, a11y_tree, evaluations
disque   /tmp/diwall/<operation_id>/*.png      captures
         /var/log/diwall/operations.jsonl      journal des opérations
   │
   ▼
le modèle lit le JSON et la capture, décide, puis appelle de nouveau Diwall

diwall-rpa confie un fichier de scénario entier au même shot.py, en un seul appel.

Deux conséquences découlent du schéma.

L’état vivant de la page ne survit pas entre deux appels. Chaque appel démarre un nouveau navigateur. Les cookies et le stockage peuvent être conservés (--sauver-session, --reprendre-session) ; une case cochée ou un formulaire à moitié rempli, non. Une séquence qui dépend de ce type d’état doit tenir dans un seul scénario. → La session n’est pas conservée entre deux appels

Ce que le modèle lit, son fournisseur le reçoit si le modèle est hébergé. La sortie de Diwall est écrite pour être lue, et c’est le modèle que vous choisissez qui décide où elle va ensuite. → Ce que Diwall ne fait pas dans votre dos