Arquitectura
Por qué Diwall está construido así: qué garantiza, a qué se niega y dónde están sus límites.
Diwall no es un servicio. Es un comando que un modelo ejecuta, cuya respuesta lee, y que vuelve a ejecutar — un navegador por llamada, nada a la escucha entre una y otra.
modelo (cualquier modelo capaz de ejecutar un comando de shell)
│ diwall-shot --url … --som --a11y --guide-version 1.3
▼
shot.py ── Playwright ── Chromium sin interfaz, un proceso por llamada
│ credenciales resueltas aquí, y solo aquí
▼
stdout un objeto JSON: succes, boussole, capture, elements_som, a11y_tree, evaluations
disco /tmp/diwall/<operation_id>/*.png capturas
/var/log/diwall/operations.jsonl registro de operaciones
│
▼
el modelo lee el JSON y la captura, decide y llama de nuevo a Diwall
diwall-rpa entrega un archivo de escenario completo al mismo shot.py, en una sola llamada.
Del esquema se derivan dos consecuencias.
El estado vivo de la página no se mantiene entre dos llamadas. Cada llamada inicia un nuevo navegador. Las cookies y el almacenamiento pueden conservarse (--sauver-session, --reprendre-session); una casilla marcada o un formulario a medio rellenar, no. Una secuencia que dependa de ese tipo de estado debe ir en un único escenario. → La sesión no se mantiene entre dos llamadas
Lo que el modelo lee, su proveedor lo recibe si el modelo está alojado. La salida de Diwall está escrita para ser leída, y el modelo que usted elija decide adónde va después. → Lo que Diwall no hace a sus espaldas