Architektur
Warum Diwall so aufgebaut ist: was es garantiert, was es ablehnt und wo seine Grenzen liegen.
Diwall ist kein Dienst. Es ist ein Befehl, den ein Modell ausführt, dessen Antwort es liest und den es erneut ausführt – ein Browser pro Aufruf, nichts lauscht dazwischen.
Modell (jedes Modell, das einen Shell-Befehl ausführen kann)
│ diwall-shot --url … --som --a11y --guide-version 1.3
▼
shot.py ── Playwright ── Chromium ohne Oberfläche, ein Prozess pro Aufruf
│ Zugangsdaten hier und nur hier aufgelöst
▼
stdout ein JSON-Objekt: succes, boussole, capture, elements_som, a11y_tree, evaluations
Disk /tmp/diwall/<operation_id>/*.png Aufnahmen
/var/log/diwall/operations.jsonl Operationsjournal
│
▼
das Modell liest das JSON und die Aufnahme, entscheidet und ruft Diwall erneut auf
diwall-rpa übergibt eine ganze Szenariodatei an dasselbe shot.py, in einem einzigen Aufruf.
Aus dem Schema ergeben sich zwei Folgen.
Der aktuelle Zustand der Seite bleibt zwischen zwei Aufrufen nicht erhalten. Jeder Aufruf startet einen neuen Browser. Cookies und lokaler Speicher können übernommen werden (--sauver-session, --reprendre-session); ein angekreuztes Kontrollkästchen oder ein halb ausgefülltes Formular nicht. Eine Abfolge, die von einem solchen Zustand abhängt, gehört in ein einziges Szenario. → Die Sitzung bleibt zwischen zwei Aufrufen nicht erhalten
Was das Modell liest, erhält sein Anbieter, wenn das Modell gehostet ist. Diwalls Ausgabe ist zum Lesen geschrieben, und das Modell, das Sie wählen, entscheidet, wohin sie als Nächstes geht. → Was Diwall nicht hinter Ihrem Rücken tut