Iris#149) #91

New issue

Closed

opened 2026-10-22 17:59:12 +00:00 by alf · 1 comment

alf commented

2026-10-22 17:59:12 +00:00

Owner

Worum es geht

Teil des Features Autonome Web-Blöcke (Spezifikation und alle Entscheidungen: iris/Iris#149). Der Linux-Server bekommt die Routen, die ein Client für autonome Plugin-Blöcke braucht. Die Aktionen selbst laufen nicht hier, sondern auf dem Client-Gerät; der Server ist Ablage und Verlauf.

Zu tun (Wire-Protokoll, byte-genau wie der Mac-Server)

POST /agent/<job>/canvas {title, blocks}: Canvas-Nachricht an den Job anhängen, ohne Lauf (Ausgangspunkt: jobs_store.append_canvas_message, bisher nur über das interne Werkzeug show_canvas erreichbar).
POST /agent/<job>/notify {plugin_id, text}: Hinweis-Nachricht „von Plugin X“, kein Lauf.
POST /agent/<job>/ask {plugin_id, text}: Nachricht mit Herkunft plugin:<id> wie vom Nutzer, löst einen Lauf aus.
PUT /agent/<job>/canvas-plugin/<block>/state {state, snapshot_id}; der Canvas-Snapshot (canvas.py, canvasSnapshotData) trägt das Feld state und autonomous. Heute hat der Linux-Server die canvas-plugin/…/submit-Routen des Mac-Servers gar nicht (Gegenstück in IrisRemoteServer.swift); das ist mit zu klären.
GET /plugins/<id>/actions → {version, actions_api, actions, files:[{path, sha256, size}]} und GET /plugins/<id>/file?path= (authentifiziert, nur Dateien des Plugins).

Dazu autonomous: true darf ein Klick nicht isCompleted setzen und keinen Auto-Submit/Lauf auslösen (canvas.py, canvas_routes.py, jobs_store.py).

Nicht Teil

Ausführen von Aktionen im Container, Sandbox, iOS/Browser.

Abnahme

Mit einem Mac-Client gegen den Linux-Server: Block anhängen ohne Lauf (Log), Zustand speichern und im Snapshot wiederfinden, Plugin-Dateien mit Hash abholen, Notify und Ask mit Kennzeichnung. Tests in tests/ (wie test_canvas.py). Nach der Änderung Wire-Protokoll-Doku (Entwicklerdokumentation/02-Wire-Protokoll.md) im selben Zug.

## Worum es geht Teil des Features **Autonome Web-Blöcke** (Spezifikation und alle Entscheidungen: **iris/Iris#149**). Der Linux-Server bekommt die Routen, die ein Client für autonome Plugin-Blöcke braucht. **Die Aktionen selbst laufen nicht hier**, sondern auf dem Client-Gerät; der Server ist Ablage und Verlauf. ## Zu tun (Wire-Protokoll, byte-genau wie der Mac-Server) 1. `POST /agent/<job>/canvas` `{title, blocks}`: Canvas-Nachricht an den Job anhängen, **ohne Lauf** (Ausgangspunkt: `jobs_store.append_canvas_message`, bisher nur über das interne Werkzeug `show_canvas` erreichbar). 2. `POST /agent/<job>/notify` `{plugin_id, text}`: Hinweis-Nachricht „von Plugin X“, kein Lauf. 3. `POST /agent/<job>/ask` `{plugin_id, text}`: Nachricht mit Herkunft `plugin:<id>` wie vom Nutzer, löst einen Lauf aus. 4. `PUT /agent/<job>/canvas-plugin/<block>/state` `{state, snapshot_id}`; der Canvas-Snapshot (`canvas.py`, `canvasSnapshotData`) trägt das Feld `state` und `autonomous`. Heute hat der Linux-Server die `canvas-plugin/…/submit`-Routen des Mac-Servers gar nicht (Gegenstück in `IrisRemoteServer.swift`); das ist mit zu klären. 5. `GET /plugins/<id>/actions` → `{version, actions_api, actions, files:[{path, sha256, size}]}` und `GET /plugins/<id>/file?path=` (authentifiziert, nur Dateien des Plugins). Dazu `autonomous: true` darf ein Klick **nicht** `isCompleted` setzen und **keinen** Auto-Submit/Lauf auslösen (`canvas.py`, `canvas_routes.py`, `jobs_store.py`). ## Nicht Teil Ausführen von Aktionen im Container, Sandbox, iOS/Browser. ## Abnahme Mit einem Mac-Client gegen den Linux-Server: Block anhängen ohne Lauf (Log), Zustand speichern und im Snapshot wiederfinden, Plugin-Dateien mit Hash abholen, Notify und Ask mit Kennzeichnung. Tests in `tests/` (wie `test_canvas.py`). Nach der Änderung Wire-Protokoll-Doku (`Entwicklerdokumentation/02-Wire-Protokoll.md`) im selben Zug.

alf added the

typ

feature

label

2026-10-22 17:59:21 +00:00

alf referenced this issue from iris/Iris

2026-10-22 17:59:21 +00:00

Autonome Web-Blöcke: Plugin-Aktionen mit eigener Laufzeit, Zustand und Starter (Spezifikation) #149

alf commented

2026-10-22 18:57:33 +00:00

Author

Owner

Stand iris/Iris#149: Schritte 1–4 sind auf dem Mac gemergt (Laufzeit, Manifest und Routen GET /plugins/<id>/actions und /file, irisCall, Lebenszyklus). Für diesen Server noch zu bauen: die beiden Routen samt bundle_hash (Referenzvektor in Entwicklerdokumentation/02-Wire-Protokoll.md, 56 Fälle der Manifest-Prüfung sind im Mac-Testskript scripts/test-plugin-actions-core.sh) und eine Route, mit der Remote-Clients den Zustand eines autonomen Blocks speichern (irisSaveState/irisFinish; Snapshot-Felder autonomous, blockStates, finishedBlockIDs). Die Zustandsroute ist noch nicht entworfen, sie entsteht mit Schritt 7.

Stand iris/Iris#149: Schritte 1–4 sind auf dem Mac gemergt (Laufzeit, Manifest und Routen `GET /plugins/<id>/actions` und `/file`, `irisCall`, Lebenszyklus). Für diesen Server noch zu bauen: die beiden Routen samt `bundle_hash` (Referenzvektor in `Entwicklerdokumentation/02-Wire-Protokoll.md`, 56 Fälle der Manifest-Prüfung sind im Mac-Testskript `scripts/test-plugin-actions-core.sh`) und eine Route, mit der Remote-Clients den Zustand eines autonomen Blocks speichern (`irisSaveState`/`irisFinish`; Snapshot-Felder `autonomous`, `blockStates`, `finishedBlockIDs`). Die Zustandsroute ist noch nicht entworfen, sie entsteht mit Schritt 7.

alf closed this issue

2026-10-27 10:41:36 +00:00