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

## Erster Befehl
```bash
logbrew status --json
```

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

```bash
logbrew status --json
```

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

```bash
logbrew logs --level error --json
```

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

```bash
logbrew issues open --json
```

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

```bash
logbrew trace <trace_id> --json
```

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

```bash
logbrew actions --name checkout_failed --json
```

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

```bash
logbrew releases --json
```

## 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.

## 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.

## Ö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.

## 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.

## Public agent links
- Docs: https://logbrew.co/de/docs
- Docs Markdown: https://logbrew.co/de/docs.md
- Home Markdown: https://logbrew.co/de/page.md
- llms.txt: https://logbrew.co/llms.txt
- Sitemap: https://logbrew.co/sitemap.xml