# Inspect your workspace

Use read commands to understand setup state and email activity without the dashboard. Supply `BARUA_MANAGEMENT_KEY`, then use the [installed helpers](/docs/guides/quickstart.md).

## Discover access first

```sh
node "$BARUA_SKILL/scripts/manage.mjs" capabilities
node "$BARUA_SKILL/scripts/manage.mjs" setup
```

Read the `reads` entries to see which projections are allowed. Success means the requested read completed; it does not mean setup is ready to send. The setup response identifies the current blockers.

## Check the relevant surface

```sh
node "$BARUA_SKILL/scripts/inspect.mjs" event-status
```

This reads the live event-status projection. Use `events` for event diagnostics and `stats` for workspace statistics; `stats` requires `people:read`. The [inspection reference](/skills/barua-setup/references/inspection.md) maps each command to its HTTP route and permission.

Other reads include `brand` and `plan`, plus sender `domain` state. For emails forwarded into Barua, use `inbound-templates` and `inbound-template --id`. Read only the surfaces relevant to the reported problem.

## Follow the evidence

If events are missing, check [the event contract](/docs/events.md#check-what-arrived) for rejected payloads and receipts. A successful HTTP response may only acknowledge queued work. Check the stored outcome before calling it complete.

If a person exists but no email appears, follow [Play admissions and runs](/docs/guides/plays.md), then [email history](/docs/guides/emails.md). A profile or an enabled Play alone does not prove that a message was eligible or delivered.

## Keep the report bounded

The helpers return bounded pages and do not automatically traverse every cursor. Fetch another page only when it is needed for the task. Distinguish unavailable data from an empty result.

Report the observed state and the next permitted action. Use [Recover a blocked task](/docs/guides/troubleshooting.md) before resuming or retrying a write.