Veröffentlichen und teilen

Das Veröffentlichen ist die Übergabe von Ihrem Harness an die betriebene Plattform: Das Dashboard hört auf, die Ausgabe eines Agenten zu sein, und wird zu etwas, auf das sich Ihr Team verlassen kann — eine stabile URL, geregelt durch Ihre Zugriffsrechte, die auch nach Ende der Sitzung weiter antwortet.

Entwurf und Hauptzweig sind echte Git-Branches

Das ist keine Metapher. Jedes Dashboard ist ein Git-Repository, gehalten als Bare-Repo im Objektspeicher. Ihre Änderungen — von Ihrem Agenten, vom In-App-Assistenten, vom Code-Editor — sind Commits auf einem draft-Branch. Das Veröffentlichen mergt diesen Entwurf in main.

Drei Konsequenzen, mit denen Sie planen sollten:

• Sie können nicht direkt in main schreiben. Schreibvorgänge dorthin werden verweigert; der einzige Weg, wie Inhalt die Live-Version erreicht, ist eine Veröffentlichung.
• Jede Veröffentlichung erstellt ein Versions-Tag. Das Tag hält den Zustand fest, in dem sich main vor dem Merge befand — also ist v1 das, was Ihre erste Veröffentlichung ersetzt hat, v2 das, was Ihre zweite Veröffentlichung ersetzt hat, und die aktuell live geschaltete Version ist main, ungetaggt bis zur nächsten Veröffentlichung.
• Gleichzeitige Veröffentlichungen mergen, statt zu überschreiben. Wenn sich main bewegt hat, während Ihr Entwurf offen war, und beide unterschiedliche Dateien betroffen haben, landen beide Änderungssätze. Wenn sie dieselbe Datei inkompatibel betroffen haben, schlägt die Veröffentlichung mit 409 PUBLISH_MERGE_CONFLICT fehl und nennt die widersprüchlichen Pfade. Es wird nicht stillschweigend ein Gewinner ausgewählt.

Sie können diese Historie lesen:

print(client.viz.list_tags(viz_id))
print(client.viz.get_commit_log(viz_id, "main", max_count=20))
print(client.viz.preview_publish(viz_id))   # diff between draft and main

console.log(await client.viz.listTags(vizId));
console.log(await client.viz.getCommitLog(vizId, 'main', { maxCount: 20 }));
console.log(await client.viz.previewPublish(vizId));

Ein Dashboard veröffentlichen

Ihr Agent kann das direkt über MCP tun; in der App ist es der Knopf Veröffentlichen; im Code ist es ein Aufruf:

client.viz.publish(viz_id)

await client.viz.publish(vizId);

Das Veröffentlichen führt zunächst eine Gesundheitsprüfung des letzten Builds des Dashboards durch. Ist das Bundle FAILED oder veraltet, wird die Veröffentlichung mit einem 409 verweigert, statt etwas zu befördern, das nicht dargestellt wird — übergeben Sie force=true, um das bewusst zu übergehen.

Die Veröffentlichung mergt dann, taggt und startet einen Build. Der Status wird erst dann PUBLISHED, wenn dieser Build erfolgreich ist; schlägt er fehl, landet das Dashboard in ERROR, und main wird zurückgesetzt. Also ist die Rückkehr von publish() nicht dasselbe wie die Tatsache „das Dashboard ist live" — lesen Sie publishStatus zurück, bevor Sie jemandem sagen, der Link funktioniere. (Dieselbe Regel wie bei einer Aktualisierung, die 202 liefert: Der Abschluss des Aufrufs und der Abschluss der Arbeit sind zwei verschiedene Dinge.)

Wer es öffnen kann — drei Modi, nicht zwei

Das Veröffentlichen entscheidet, dass das Dashboard live ist. Ein separates Feld, viewMode, entscheidet, wer es öffnen kann. Diese beiden zu verwechseln ist der häufigste Fehler hier.

viewMode	Wer es öffnen kann
public	Jeder mit dem Link. Kein Konto erforderlich.
protected	Nur ein Betrachter, für den Ihr Backend ein Embed-Token ausgestellt hat — mit Filtern pro Betrachter auf Zeilenebene. Siehe Einbetten.
private	Niemand außerhalb Ihres Kontos. Veröffentlicht, aber von der öffentlichen Oberfläche aus nicht erreichbar.

Der Link eines veröffentlichten Dashboards sieht so aus:

https://cloud.vibedasher.com/v/<slug>

Diese URL liefert nur dann Inhalt, wenn das Dashboard sowohl veröffentlicht als auch public ist. Ein protected-Dashboard unter derselben URL braucht ein angehängtes Token.

Öffentlich zu werden wird separat freigeschaltet, und ein Agent kann es nicht allein tun

Firmendaten weltweit lesbar zu machen ist das einzige unumkehrbare Ding in diesem ganzen Ablauf, deshalb hat es eine eigene Schranke, statt einfach bei publish mitzulaufen. Zwei Schalter, beide auf Kontoebene, beide serverseitig auf jeder Route geprüft, die viewMode schreiben kann:

• allowForPublicViz — ein kontoweiter Notschalter. Schalten Sie ihn aus, kann nichts im Konto von irgendjemandem über irgendeine Route öffentlich gemacht werden.
• apiKeysMayPublish — standardmäßig false. Selbst wenn öffentliches Teilen erlaubt ist, darf ein Aufrufer, der sich mit einem API-Schlüssel authentifiziert, nicht derjenige sein, der ein Dashboard auf öffentlich umschaltet. Ein Admin muss dies aktivieren und kann das nur aus einer Browser-Sitzung heraus tun — PUT /v1/account weigert sich, dies von einem API-Schlüssel aus zu setzen, sodass der Schalter sich nicht selbst aktivieren kann.

Der zweite Punkt ist der entscheidende. An anderer Stelle auf dieser Plattform handelt ein API-Schlüssel als der Benutzer, der ihn erstellt hat, mit dessen voller Rolle (siehe Wer sieht was). Die Veröffentlichung ins offene Internet ist die bewusste Ausnahme: Ihr Agent kann das Dashboard bauen, veröffentlichen und innerhalb Ihres Kontos teilen, aber standardmäßig kann er nicht dasjenige sein, das es öffentlich macht. Ein Mensch in einem Browser muss einmal Ja gesagt haben, auf Kontoebene.

Der Code ist eingefroren; die Daten sind es nicht

Das ist die Eigenschaft, die ein veröffentlichtes Dashboard eher hostenswert als exportierenswert macht.

Der Dashboard-Code wird bei der Veröffentlichung als Momentaufnahme festgehalten. Das Bundle wird einmal gebaut und aus dem Speicher ausgeliefert. Ihr Entwurf entwickelt sich unabhängig weiter und sickert nicht in die Live-Version, bis Sie erneut veröffentlichen.

Die Daten werden zur Ansichtszeit live gelesen. Jedes Diagramm auf einem veröffentlichten Dashboard fragt beim Öffnen den aktuellen Inhalt seiner Datensätze ab. Eine Aktualisierung, die um 3 Uhr morgens eintrifft, erscheint um 9 Uhr auf dem veröffentlichten Dashboard, ohne dass irgendetwas neu gebaut wird und ohne dass jemand beteiligt ist. Das ist der ganze Grund, warum die Datenhälfte in der Plattform lebt — siehe Ihre Daten aktuell halten.

Veröffentlichung aufheben und erneut veröffentlichen

DELETE /v1/viz/{id}/publish nimmt das Dashboard vom Netz: Der Status kehrt zu NOT_PUBLISHED zurück, und das Live-Bundle wird entfernt. Ihr Entwurf bleibt unangetastet.

• Der Slug wird behalten und bleibt reserviert, sodass eine erneute Veröffentlichung dieselbe URL wiederverwendet.
• Alte Links scheitern uneinheitlich. Die Betrachterseite antwortet mit 404, die öffentliche API mit 403, und die zwischengespeicherten Datenendpunkte mit 404. Wenn Sie das programmatisch behandeln, verzweigen Sie nicht allein nach dem Statuscode.
• Das Umbenennen des Slugs bricht jeden bestehenden Link dauerhaft. Es gibt keine Weiterleitung von einem alten Slug zu einem neuen. Wählen Sie den Slug, bevor Sie die URL verteilen.

Einbetten

Veröffentlichte Dashboards werden über ein einbettbares Iframe dargestellt, das Sie in jede App, Dokumentationsseite oder Website einfügen können — öffentlich oder pro Betrachter mit zeilenbasierten Filtern gesichert. Siehe Ein Dashboard einbetten.