Dashboard-Architektur

Vision

Die Arbeit mit einem Agenten ist heute ein Textstrom. Das Dashboard macht daraus eine Werkbank: Der Agent rendert interaktive Live-Widgets; Benutzer heften sie an eine persistente Oberfläche; der Chat wird seitlich angedockt (oder ausgeblendet), und der Hauptinhalt ist das Board. So wird aus dem „Gespräch mit dem Agenten“ die „Bedienung eines Kontrollpanels, das der Agent für Sie erstellt hat“, ohne dass Sie die Sitzung jemals verlassen.

Grundsätze:

• Ein Board ist eine Ansicht einer Sitzung, kein neues Objekt. Jede Sitzung (Thread) hat zwei Ansichten: das Transkript und das Board. Eine Sitzung ohne angeheftete Widgets ist ein einfacher Chat. Sobald ein Widget angeheftet wird, existiert das Board. Boards übernehmen Identität, Agentenzuordnung, Benennung, Anheftung und Lebenszyklus der Sitzung. Es gibt kein dashboard_create, keine Board-Registry und kein separates ACL-Modell.
• Gleichwertigkeit des Agenten. Alles, was Benutzer auf einem Board tun können, kann auch der Agent mit Tools tun: Widgets hinzufügen/aktualisieren/entfernen, sie anordnen, Tabs verwalten, den sichtbaren Tab wechseln und den Chat andocken oder ausblenden.
• Nativ, nicht eingebettet. Das Board besteht aus Lit-Komponenten in der Control-UI-Shell (demselben Designsystem wie der Rest der App). Nur der Inhalt eines Widgets wird in iframes sandboxiert. Keine URL-Leiste, keine Browser-Bedienelemente.
• Kleine Agentenoberfläche. Widgets werden über stabile Namen adressiert und direkt aktualisiert. Das Layout ist ein flexibles, automatisch komprimierendes Raster; der Agent gibt Größen und Anker an, niemals Pixel oder Koordinaten.
• Berechtigungen statt Vertrauen. Widget-Code ist beliebiges, vom Agenten verfasstes HTML/JS in einer streng abgeschotteten Sandbox. Zugriff (Gateway-Daten, Aktionen, Netzwerk) besteht nur über ein deklariertes, vom Betreiber gewährtes Berechtigungsmanifest.

Konzepte

UX-Abläufe

• Übernahme: Der Agent ruft show_widget in einem beliebigen Chat auf → das Widget wird wie bisher inline im Transkript gerendert → beim Darüberfahren erscheint An Dashboard anheften → das Widget erscheint auf dem Board der Sitzung. Der Agent kann pin: true übergeben, um dasselbe zu bewirken.
• Board-Ansicht: Eine Sitzung mit einem Board erhält einen Ansichtsumschalter (Chat / Dashboard). Board-Ansicht = Tableiste (nur bei >1 Tab) + flexibles Raster + angedockter Chatbereich. Das Chat-Dock ist in der Größe veränderbar, verschiebbar (links/rechts/unten) und genau wie die Seitenleiste einklappbar. Der Dock-Zustand wird pro Tab gespeichert.
• Ziehen: Benutzer ziehen Widgets; das Raster wird automatisch komprimiert (Widgets rücken nach oben, benachbarte Elemente ordnen sich neu an). Die Größenänderung über einen Griff rastet in Größenstufen ein. Keine pixelgenaue Platzierung – für niemanden.
• Warnung beim Zurücksetzen: /new / /reset fordert bei einer Sitzung mit Board in der Web-UI eine Bestätigung an („Der Kontext wird zurückgesetzt, das Dashboard bleibt erhalten“) und behält das Board bei.
• Seitenleiste: Angeheftete Sitzungen zeigen ihre Board-Ansicht, sofern eine vorhanden ist. Das Board der Home-Sitzung ist das standardmäßige „Agenten-Dashboard“.
• Interaktionen (drei Stufen, siehe unten): stille Zustandsereignisse, sichtbare Prompt-Sendungen und Automatisierungsauslöser.

Interaktionsstufen

1. Zustandsereignisse (Standard). Interaktionen mit der Widget-Benutzeroberfläche, über die das Modell informiert sein sollte, auf die es jedoch nicht reagieren soll. bridge.emitState({...}) fügt einen strukturierten Sitzungshinweis hinzu (derselbe Mechanismus wie bei Gruppenaktivitätshinweisen). Es wird kein Agentendurchlauf gestartet; das Modell sieht die gesammelten Hinweise bei seinem nächsten Durchlauf.
2. Prompts (explizite Kommunikation). bridge.sendPrompt(text) – erfordert eine Benutzeraktivierung; sendet eine sichtbare Benutzernachricht an die Sitzung (der angedockte Chat zeigt sie an). Ratenbegrenzt; jede Sendung muss vom Benutzer bestätigt werden, sofern das Widget nicht über die gewährte Berechtigung prompt verfügt.
3. Automatisierung. bridge.runAction(name, args) – löst eine im Manifest deklarierte Aktion aus. Anfänglicher Satz von Verben: cron.trigger (einen vorhandenen Cron-Job jetzt ausführen) und binding.refresh. Cron-Jobs werden bereits in sichtbaren, isolierten Ausführungssitzungen ausgeführt und können ein günstigeres Modell verwenden: Das ist der Weg „ein kleines Modell treibt das Widget an“. Es gibt nirgends versteckte Sitzungen.

Widget-Modell und Hosting

Widget-HTML/JS wird vom Agenten verfasst (typischerweise über show_widget), in die Standard-Dokument-Shell eingebettet (CSP-Meta, Größenmelder, Bridge-Bootstrap) und in <iframe sandbox="allow-scripts"> gerendert (niemals allow-same-origin).

• Inline-Widgets (Transkript) behalten die aktuelle Canvas-Dokument-Pipeline bei: im Zustandsverzeichnis gespeichert, vom Gateway bereitgestellt, nach Geltungsbereich bereinigt, keine Genehmigung (sie haben konstruktionsbedingt keine Berechtigungen – Prompt-Sendungen werden vom Benutzer bestätigt).
• Board-Widgets sind Sitzungszustand: Die Bytes liegen in der SQLite-Datenbank des zuständigen Agenten (board_widgets) und werden über eine zentrale Gateway-Route (/__openclaw__/board/<agentId>/<sessionKey>/<name>/) bereitgestellt, die die Datenbank liest. Beim Anheften eines Transkript-Widgets werden die Bytes kopiert. Begrenzungen: 256 KB pro Widget, 48 Widgets pro Board.
• Direkte Aktualisierung: Das erneute Ausgeben eines Widgets mit demselben name ersetzt die Bytes, erhöht revision, sendet board.changed und veranlasst Live-Ansichten, nur dieses iframe neu zu laden.
• Byte-Bindung: Gewährte Berechtigungen werden an den sha256-Hash der Widget- Bytes gebunden. Beim Ändern der Bytes bleiben Gewährungen für data/net/actions nur erhalten, wenn die neue Revision eine Teilmenge des gewährten Manifests deklariert; ein erweitertes Manifest fordert den Betreiber erneut zur Bestätigung auf.

Widgets hosten Inhalte; MCP-Apps sind eine Inhaltsart

Das Widget ist das OpenClaw-Grundelement: die benannte, angeheftete, dimensionierte, sitzungseigene Board-Zelle mit einem Gewährungsdatensatz. Was darin gerendert wird, ist eine Inhaltsart:

• html – vom Agenten über show_widget verfasst, Bytes im Board-Speicher.
• mcp-app – eine MCP-App-Ansicht eines Drittanbieters (ui://-Ressource eines konfigurierten Servers), die innerhalb der Widget-Zelle gehostet wird.

MCP-Apps definieren das Widget-Modell nicht; Widgets haben die Fähigkeit erhalten, sie zu hosten. Identität, Platzierung, Anheftung, Gewährungen und die API für Autoren bleiben OpenClaw-eigen – dadurch bleibt show_widget-Code so kurz wie heute und muss niemals wissen, dass die MCP-Apps-Spezifikation existiert.

Gemeinsame zugrunde liegende Infrastruktur (hier findet die Vereinfachung statt):

• Ein Sandbox-Host. html-Widgets werden über dieselbe gehärtete Pipeline gerendert, mit der MCP-Apps ausgeliefert wurden (doppeltes iframe auf dem dedizierten Sandbox- Ursprung, pro Widget deklarierte CSP, die ausfallsicher dekodiert wird), statt über einen zweiten maßgeschneiderten iframe-Host. Der Proxy empfängt HTML als Wert, daher sind lokale Inhalte der natürliche Anwendungsfall.
• Ein Autorisierungsmodell. Der Zugriff eines Widgets ist eine gewährte Positivliste, unabhängig von seiner Art: für html-Widgets Host-Tools; für mcp-app-Widgets die für die App sichtbaren Tools des Servers (über den bestehenden allowedAppToolNames- Mechanismus, dauerhaft pro Widget statt pro Erzeugungsdurchlauf).
• Host-Tools für html-Widgets (über die Widget-Bridge verfügbar gemacht und anhand der Gewährung geprüft):
  • openclaw.prompt.send – Stufe 2; über den sichtbaren Composer geleitet, vom Benutzer bestätigt, sofern nicht gewährt
  • openclaw.state.emit – Sitzungshinweise der Stufe 1 (zusammengeführt, größenbegrenzt)
  • openclaw.data.read – parametrisierte schreibgeschützte Bindungen (bestehender Satz von Lese-RPCs auf der Positivliste), Gateway-seitig aufgelöst
  • openclaw.cron.trigger – Automatisierung der Stufe 3
• net = CSP. Der Netzwerkzugriff verwendet die bereits ausgelieferte, Widget-spezifische CSP- Deklaration (connect-src-Ursprünge) – das selbstaktualisierende Wetter-Widget ruft seine API direkt aus der Sandbox ab, ohne Beteiligung des Gateways.
• Gewährungen. Ein Widget, das nichts deklariert, wird sofort gerendert (sandboxiert, default-src 'none', Prompt-Sendungen werden einzeln bestätigt) – dasselbe Vertrauensniveau wie bei heutigen Inline-Chat-Widgets. Deklarierte Tools/Ursprünge versetzen das Widget auf dem Board in pending: Eine Platzhalterkarte listet sie in verständlicher Form auf, mit Zulassen/Ablehnen per einfachem Tippen. Gewährungen gelten pro Widget-Namen; bei html-Widgets sind sie an die Bytes gebunden (sha256), und bei geänderten Bytes bleibt die Gewährung nur erhalten, wenn die Deklaration verkleinert wurde.
• Autoren-Shim. Der Dokument-Wrapper injiziert window.openclaw.prompt, window.openclaw.state, window.openclaw.data und window.openclaw.cron als stabile Autoren-API. Dashboard-Aufrufe teilen sich einen einzigen, an das Ansichtsticket gebundenen Anfragekanal; Größenmeldungen und Theme-Tokens bleiben separate Host- Benachrichtigungen.

Plugin-Berechtigungsdeklarationen

Aktivierte Plugins können den Widget-Host über dashboard.dataBindings und dashboard.actionVerbs in openclaw.plugin.json erweitern. Plugin-lokale IDs werden zu Gewährungsnamen mit dem Präfix der Plugin-ID, beispielsweise workboard.cards.list und workboard.dispatch; % und . werden im Plugin-ID-Segment maskiert, damit eine andere Aufteilung von Plugin und lokaler ID nicht dieselbe persistierte Gewährung übernehmen kann. Während der Plugin-Registrierung überprüft OpenClaw, dass jede Bindung auf einen RPC verweist, der vom selben Plugin mit operator.read registriert wurde, und jede Aktion auf einen, der mit operator.write registriert wurde; ungültige Deklarationen führen zum Fehlschlagen des Plugin-Ladevorgangs. Die validierte Registry wird nur bei Änderungen am Plugin-Lebenszyklus neu aufgebaut, während Widget-Gewährungen Widget-spezifisch sowie an Bytes und Revision gebunden bleiben.

Modelliertes Restrisiko: WebRTC-Datenkanäle

Die Sandbox-CSP gibt die vorgeschlagene webrtc 'block'-Direktive aus, aber Chromiums aktueller Satz von CSP-Direktiven implementiert sie nicht. Skriptfähige Widgets können daher im aktuellen Chromium WebRTC-Datenkanäle für ausgehende Verbindungen verwenden. Dasselbe Restrisiko besteht bereits bei Inline-Chat-Widgets und dem MCP-Apps-Host auf main.

Akzeptierter Kompromiss: OpenClaw sperrt skriptfähige Widgets nicht aufgrund dieses Restrisikos. Widget-Inhalte erhalten Zugriff auf sensible OpenClaw-Daten nur über eine vom Betreiber gewährte, bytegenau fixierte data:read-Berechtigung, und die Permissions Policy der Sandbox blockiert den Zugriff auf Kamera und Mikrofon. Eine DOM-API-Schutzvorkehrung ist eine Best-Effort-Tiefenverteidigung, keine Sicherheitsgrenze, und gehört in eine nachgelagerte Härtung.

Transkriptanzeige: eine Widget-Karte

Die Inline-Anzeige wird auf dem Widget-Primitiv vereinheitlicht. Wenn ein Tool-Ergebnis eine UI enthält — show_widget-Ausgabe oder ein MCP-Tool-Ergebnis mit einer App-Ressource — materialisiert das System ein flüchtiges, automatisch benanntes Widget (sitzungsbezogen, bereinigt), und das Transkript rendert eine einzelne Widget-Karte, die nach Inhaltsart weiterleitet. Die automatische MCP-App-Anzeige bleibt exakt so, wie es die Spezifikation erwartet (keine zusätzliche Modellarbeit); darunter ist sie lediglich ein Widget. Dadurch entfallen die parallelen mcpApp- Sonderfälle beim Chat-Rendering (Oberflächenfreigabe, separate Deduplizierung), jede Inline-UI erhält dieselbe Anheftoption, und die Widget-Registry wird zum primären Pfad für das erneute Öffnen (die Rekonstruktion durch Durchsuchen des Transkripts bleibt als Rückfalloption für nie angeheftete Verläufe bestehen). Der schreibgeschützte, ticketgebundene eigenständige Host überschneidet sich mit Boards als dauerhafte Oberfläche zum erneuten Öffnen — ein in T6 zu prüfender Konsolidierungskandidat, keine Annahme.

Komposition: v1 verwendet Raster-Nachbarschaft (Agent-Chrome-Widget neben einem App-Widget auf einem Tab). v2 ergänzt hostverwaltete App-Slots — das HTML des Agent-Widgets deklariert eine Slot-Region, und der Host setzt die tatsächliche App-Ansicht als gleichrangige Sandbox zusammen. Die App wird niemals innerhalb des iFrames des Agenten gerendert: Eine Verschachtelung würde die Bridge- Identität aufbrechen und Overlays beziehungsweise Clickjacking der freigegebenen App-UI ermöglichen, daher ist der Slot ein Layout-Vertrag und keine Einbettung.

Serverseitig bereitgestellte Widgets (angeheftete MCP-Apps)

Mit dem vereinheitlichten Host ist das Anheften einer MCP-App eines Drittanbieters lediglich ein Widget, dessen Inhalt vom Server abgerufen statt gespeichert wird: board_widgets enthält den Deskriptor (serverName, toolName, uiResourceUri, ursprüngliche toolCallId + sessionKey) anstelle von HTML-Bytes, und das Board stellt die Ansichts-Lease über die 10-minütige TTL des Chat-Durchlaufs hinaus neu aus (bei Veraltung wird die ui://-Ressource erneut abgerufen). Inline-MCP-App-Ansichten im Chat erhalten dieselbe An Dashboard anheften- Option wie Agent-Widgets. Erneut geöffnete Ansichten sind derzeit bewusst schreibgeschützt; angeheftete Apps, die interaktiv bleiben sollen, erhalten eine dauerhafte Freigabe für die app-sichtbaren Tools des Servers (explizite Positivliste, die dem Betreiber beim Anheften angezeigt wird), entkoppelt vom ausstellenden Lauf. Nicht freigegebene angeheftete Ansichten bleiben schreibgeschützt — und sind weiterhin für Anzeige- Dashboards nützlich. v1 heftet an das Board der ursprünglichen Sitzung an; sitzungsübergreifendes Anheften benötigt einen Lease-Broker und muss warten. Abstimmung mit dem offenen PR #109807 (ui/message- Composer-Routing, Weitergabe von Theme und Größe).

WorkBoard-Integration

Das WorkBoard-Integrationsprogramm belässt Karten und Boards im Besitz des Plugins und verknüpft versandte Karten über die bestehenden sessionKey und runId wieder mit ihren Sitzungs-Boards, stellt WorkBoard-Feeds und Versand über vom Plugin deklarierte Bindings und Aktionen bereit und kombiniert diese Ergebnisse mit den bestehenden Widget-Arten html und mcp-app, statt einen WorkBoard-spezifischen Widget-Typ einzuführen.

Layout: flexibles Raster

12 Spalten, feste Zeilenhöhe, automatische Verdichtung (Schwerkraft nach oben, beim Ziehen zur Seite schieben — Gridstack-Semantik, nativ implementiert; die Rasterberechnung bleibt rein und DOM-frei). Widget-Layoutstatus pro Tab: { name, w (1-12), h (rows) } plus Reihenfolge. Agent-Vokabular:

• size: sm (3×3) · md (6×4) · lg (8×6) · xl (12×8) · full (Tab mit einem einzelnen Widget)
• after: <widgetName> optionaler Sortieranker; weggelassen = anhängen
• Benutzer können frei ziehen und die Größe ändern; dasselbe Reihenfolge-und-Größe-Modell lässt sich verlustfrei hin- und zurückübertragen.

Datenmodell (agentenspezifische DB)

Neue Tabellen in agents/<agentId>/agent/openclaw-agent.sqlite (erfordert eine Erhöhung der Schemaversion der Agent-DB — Zustimmung des Betreibers erforderlich, bevor dies integriert wird):

CREATE TABLE board_tabs (  session_key TEXT NOT NULL,  tab_id      TEXT NOT NULL,           -- Slug  title       TEXT NOT NULL,  position    INTEGER NOT NULL,  chat_dock   TEXT NOT NULL DEFAULT 'right',  -- left|right|bottom|hidden  created_by  TEXT NOT NULL,           -- 'user' | 'agent'  PRIMARY KEY (session_key, tab_id)) STRICT; CREATE TABLE board_widgets (  session_key  TEXT NOT NULL,  name         TEXT NOT NULL,          -- stabiler Widget-Name  tab_id       TEXT NOT NULL,  title        TEXT,  html         BLOB NOT NULL,          -- Quelle des umschlossenen Dokuments  sha256       TEXT NOT NULL,  revision     INTEGER NOT NULL,  size_w       INTEGER NOT NULL,  size_h       INTEGER NOT NULL,  position     INTEGER NOT NULL,       -- Reihenfolge innerhalb des Tabs (Eingabe für automatische Verdichtung)  manifest     TEXT NOT NULL DEFAULT '{}',  -- Berechtigungsmanifest als JSON  grant_state  TEXT NOT NULL DEFAULT 'none', -- none|pending|granted|rejected  granted_sha  TEXT,                   -- bytegenau fixierte Freigabe  created_by   TEXT NOT NULL,  created_at   INTEGER NOT NULL,  updated_at   INTEGER NOT NULL,  PRIMARY KEY (session_key, name)) STRICT;

Ein Board existiert, sobald Zeilen für den sessionKey vorhanden sind. Beim Löschen einer Sitzung werden ihre Board-Zeilen gelöscht. /new//reset berührt sie nicht.

Protokolloberfläche

RPCs (zentrale Methodentabelle, TypeBox-Schemas in gateway-protocol):

• board.get { sessionKey } → Tabs + Widget-Metadaten (keine Bytes) — operator.read
• board.update { sessionKey, ops[] } — CRUD/Neusortierung von Tabs, Verschieben/Größenänderung/ Entfernen/Lösen von Widgets, Dock-Status, Tab fokussieren — operator.write
• board.widget.put { sessionKey, name, html, manifest, placement } — operator.write (Agent-Tool-Pfad und Anheftpfad)
• board.widget.grant { sessionKey, name, decision } — operator.approvals
• board.event { ticket, payload } — ticketgebundene Aufnahme von Statusereignissen der Stufe 1; die bisherige Form { sessionKey, widget, payload } für vertrauenswürdige Hosts bleibt bestehen — operator.write
• board.prompt.authorize { ticket } — gibt zurück, ob das Senden einer sichtbaren Eingabeaufforderung weiterhin eine Bestätigung bei jedem Klick benötigt — operator.read
• board.data.read { ticket, bindingId, params? } — Gateway-seitige Auflösung von Core-Lesebindings oder Lesebindings aktiver Plugins anhand einer Positivliste — operator.read
• board.action { ticket, action, ... } — Automatisierungsversand mit exakter Freigabe über den bestehenden Cron-Sofortausführungspfad oder ein validiertes Aktionsverb eines aktiven Plugins — operator.write

Ereignisse (in EVENT_SCOPE_GUARDS, Lesebereich):

• board.changed { sessionKey, revision, widget? } — persistierter Status wurde geändert; die UI ruft erneut ab (und lädt einen iFrame neu, wenn widget vorhanden ist).
• board.command { sessionKey, command } — vorübergehende UI-Steuerung (Agent wechselt den sichtbaren Tab, schaltet das Chat-Dock um) — das ui.command-Muster.

Widget-Bytes werden über die authentifizierte HTTP-Oberfläche bereitgestellt, nicht über den Socket.

Agent-Tools

Insgesamt drei Tools (Core, immer registriert; Rendering wie bisher durch die Client-Berechtigung inline-widgets beschränkt):

• show_widget { title, widget_code, name?, pin?, size?, tab?, after?, capabilities? } — nach Namen erstellen/aktualisieren; pin platziert es auf dem Board. Ohne name/pin verhält es sich exakt wie bisher (inline, flüchtig).
• dashboard { action, ... } — Board-Verwaltungsverben: read, tab_create, tab_update, tab_delete, tabs_reorder, widget_move, widget_remove, unpin, focus_tab, set_chat_dock.
• Bestehende cron-Tools decken die Automatisierungsstufe ab; kein neues Tool erforderlich.

Tool-Beschreibungen vermitteln das Größen-/Anker-Vokabular und das Stufenmodell. Der Agent wird über Sitzungsbenachrichtigungen über Benutzerereignisse der Stufe 1 informiert, z. B. [dashboard] user clicked "Refresh" on widget weather (tab main).

Was dadurch ersetzt wird

• extensions/workspaces wird gelöscht. Experimentell, enabledByDefault: false, nie in einer stabilen Version enthalten (erstmals in den Betas von 2026.7.2 erschienen). Keine Migration; eine Doctor-Regel entfernt veraltete <stateDir>/workspaces/, falls vorhanden. Übernommene Ideen: reine Rasterberechnung, Bridge-Sicherheitsmodell (Port-Bootstrap, Binding-Beschränkung, Ratenbegrenzungen), bytegenau fixierte Genehmigung.
• Das Widget-Hosting wird von extensions/canvas in den Core verschoben. Der Canvas-Dokument- speicher, der Dokument-Wrapper, die HTTP-Bereitstellung und das Tool show_widget werden Teil des Cores (src/canvas/); das Plugin behält das Node-Canvas-Steuerungstool (canvas) und A2UI. Die pluginSurfaceUrls["canvas"]-Ankündigung und die /__openclaw__/canvas-Pfade sind ausgelieferte Verträge für native Clients und bleiben stabil. Discord-Sitzungen behalten die Discord-eigene Variante show_widget.

Nichtziele (dieses Programm)

• Gemeinsame Nutzung von Boards durch mehrere Benutzer/ACLs (zukünftig; wird über die Sitzungsfreigabe eingeführt).
• Natives Board-Rendering unter macOS/iOS (dort ist es überall verfügbar, wo die Control UI eingebettet wird; der Inline-Widget-Pfad bleibt unverändert).
• Integrierte Daten-Widgets (Sitzungs-/Nutzungs-/Cron-Karten) — die Berechtigungs-Bridge und von Agenten erstellte Widgets decken v1 ab; eine Registry integrierter Arten kann später hinzukommen.

Implementierungsplan

Unabhängige Worktrees, mit Codex erstellt, nacheinander prüfen und integrieren. Erst integrieren, dann korrigieren.

Validierung gemäß Repository-Regeln: fokussiertes Vitest lokal, vollständige Prüfungen auf Crabbox/Testbox, $autoreview vor jeder Integration, Live-Nachweis für T6.