Öffentliche Docs

Mit der CLI starten und denselben Kontext im Web-Arbeitsbereich lesen.

Die LogBrew Docs halten Setup, Telemetrie-Reads, Dashboard-Zustand und agentenlesbare Markdown-Spiegel unter einem vorhersehbaren öffentlichen Pfad.

Dashboard öffnenMarkdown lesen
Erster Befehl
logbrew status --json

Status ist lokal, token-sicher und gibt Recovery-Schritte zurück, die Agents vor dem Lesen von Projektdaten parsen können.

Befehlsübersicht

Status

Lokale Authentifizierung, API-Erreichbarkeit und Recovery-Schritte vor jedem privaten Read prüfen.

logbrew status --json

Befehlsübersicht

Logs

Mit aktuellen Fehlern starten, wenn ein Release, Projekt oder Trace Kontext braucht.

logbrew logs --level error --json

Befehlsübersicht

Issues

Offene Fehlergruppen auflisten, bevor resolve, close, ignore oder reopen entschieden wird.

logbrew issues open --json

Befehlsübersicht

Trace-Detail

Eine bekannte Trace-ID lesen, wenn Logs oder Issues auf einen fehlgeschlagenen Request zeigen.

logbrew trace <trace_id> --json

Befehlsübersicht

Actions

User-Events nach Name filtern, wenn der wichtige Kontext eine Produktaktion ist.

logbrew actions --name checkout_failed --json

Befehlsübersicht

Releases

Rollout-Kontext mit Log-, Issue-, Trace-Span- und Action-Zahlen vergleichen.

logbrew releases --json

CLI zuerst

Lokale Authentifizierung und API-Erreichbarkeit prüfen

Der erste Read sollte Menschen und Agents zeigen, ob die CLI die LogBrew API erreicht, ohne Token-Material offenzulegen.

  • JSON-Modus nutzen, wenn ein Agent stabile Felder braucht.
  • Menschliche Ausgabe nutzen, wenn eine Entwicklerin oder ein Entwickler den nächsten Befehl braucht.
  • Auth-Recovery immer zurück zu Login und Status führen.

Beobachten

Produktionssignale nach Ressource lesen

Logs, Issues, Actions, Traces, Releases und Projekte sollten getrennt genug für schnelles Scannen und verbunden genug für Kontext-Recovery bleiben.

  • Logs behalten Level-, Release-, Umgebungs-, Projekt-, Trace- und Suchfilter.
  • Issues behalten Status, Trace-Kontext und Mutationsvokabular.
  • Traces behalten Span-Namen, Release-Kontext, Umgebungskontext und Projektumfang.

Agents

Öffentliche Docs ohne Browserzustand lesbar halten

Jede öffentliche Seite sollte einen Markdown-Spiegel haben und ohne JavaScript, Cookies, Login, CAPTCHA oder Challenge-Seiten erreichbar bleiben.

  • llms.txt nutzen, um öffentliche Agent-Ressourcen aufzulisten.
  • robots.txt nutzen, um öffentliches Lesen zu erlauben und private Routen zu schützen.
  • Dashboard-Daten hinter Backend-Auth und Noindex-Metadaten halten.

API-Karte

Dashboard an Backend-Routen ausrichten

Der Web-Arbeitsbereich sollte die bestehenden Rust-API-Routengruppen lesen, ohne Dashboard-only-Speicher oder alternative Verträge zu erfinden.

  • Logs werden über /api/logs mit Level-, Release-, Umgebungs-, Projekt-, Trace- und Suchfiltern gelesen.
  • Issues werden über /api/telemetry/issues und /api/telemetry/issues/{issue_id} gelesen und geändert.
  • Actions, Releases und Trace-Details werden über /api/telemetry/actions, /api/telemetry/releases und /api/telemetry/traces/{trace_id} gelesen.
  • Projekte und Auth-Status kommen aus /api/projects, /api/auth und CLI-Statusbefehlen.