Public docs

Start with the CLI, then read the same context in the web workspace.

LogBrew documentation keeps setup, telemetry reads, dashboard state, and agent-readable mirrors in one predictable public path.

First command
logbrew status --json

Status is local, token-safe, and returns recovery steps that agents can parse before reading project data.

Command map

Status

Check local auth, API reachability, and recovery steps before any private read.

logbrew status --json

Command map

Logs

Start with recent errors when a release, project, or trace needs context.

logbrew logs --level error --json

Command map

Issues

List open failure groups before deciding whether to resolve, close, ignore, or reopen.

logbrew issues open --json

Command map

Trace detail

Read a known trace id when logs or issues point to one failing request.

logbrew trace <trace_id> --json

Command map

Actions

Filter user events by name when the important context is a product action.

logbrew actions --name checkout_failed --json

Command map

Releases

Compare rollout context with log, issue, trace span, and action counts.

logbrew releases --json

CLI first

Check local auth and API reachability

The first read should tell humans and agents whether the CLI can reach the LogBrew API without exposing token material.

  • Use JSON mode when an agent needs stable fields.
  • Use human output when a developer needs the next command.
  • Keep auth recovery pointed back to login and status.

Observe

Read production signals by resource

Logs, issues, actions, traces, releases, and projects should stay separated enough to scan quickly and connected enough to recover context.

  • Logs keep level, release, environment, project, trace, and search filters.
  • Issues keep status, trace context, and mutation vocabulary.
  • Traces keep span names, release context, environment context, and project scope.

Agents

Keep public docs readable without browser state

Every public page should have a Markdown mirror and remain reachable without JavaScript, cookies, login, CAPTCHA, or challenge pages.

  • Use llms.txt to list public agent resources.
  • Use robots.txt to allow public reading and protect private routes.
  • Keep dashboard data behind backend auth and noindex metadata.

API map

Match the dashboard to backend routes

The web workspace should read the existing Rust API route groups instead of inventing dashboard-only storage or alternate contracts.

  • Logs read from /api/logs with level, release, environment, project, trace, and search filters.
  • Issues read and mutate through /api/telemetry/issues and /api/telemetry/issues/{issue_id}.
  • Actions, releases, and trace detail read through /api/telemetry/actions, /api/telemetry/releases, and /api/telemetry/traces/{trace_id}.
  • Projects and auth state come from /api/projects, /api/auth, and CLI status commands.