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

## First command
```bash
logbrew status --json
```

# Command map
## Status
Check local auth, API reachability, and recovery steps before any private read.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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