# Diagnose setup without changing it

```ts
const report = await arbi.diagnose()
for (const check of report.checks) {
  console.log(check.check, check.status, check.message, check.hint ?? '')
}
```

In the CLI, use `arbi doctor` or `arbi doctor --json`. A nonzero exit means at least one check
needs attention. Doctor reads existing configuration and the cached token; it never silently
logs in to make the report green. Without a configured deployment, configure the CLI first.

Checks cover deployment reachability, the deployment domain used to derive identity keys,
acceptance of the current session, explicit current-workspace selection and its membership role.
A proxy may have a different hostname: keep `deploymentDomain` set to the actual deployment's
domain. A workspace appearing in a list is not proof that its encryption key is currently open,
or that an agent may execute a task. Temporary grants, expiry and task authorization remain
separate and enforced by the existing API. Project visibility does not confer workspace access.

The function uses raw GET requests. It bypasses the authenticated client's login/retry middleware,
never opens a workspace and never creates an authorization grant or starts a task. An offline
unlock without a live token is reported as unverified; diagnosis does not clear the offline identity.

Hosts can run the same checks from an existing session, including behind a same-origin proxy:

```ts
import { diagnoseSetup } from '@arbidocs/sdk/browser'
const report = await diagnoseSetup({
  url: window.location.origin,
  deploymentDomain: 'your-deployment.example',
  accessToken: session.getState().accessToken,
  workspaceId: session.getState().selectedWorkspaceId,
})
```

An optional raw `fetch` adapter and `timeoutMs` support hosts and tests. Do not pass a fetch adapter
that automatically logs in, selects workspaces or grants access. Requests use omitted cookie
credentials, explicit Bearer authentication only on API checks, and reject redirects.

Reports contain fixed messages, HTTP status codes and recognized membership roles. They omit
credentials, account identities, workspace names, keys, document content and raw server errors.
They are not telemetry and are not sent anywhere automatically.

A browser's `Failed to fetch` cannot reliably distinguish CORS, DNS, TLS, mixed-content and
private-network denial. The diagnostic points to DevTools instead of claiming a cause it cannot
observe. Test from the actual browser origin: a successful CLI request does not prove browser
network policy is satisfied. Configure allowed origins or an appropriate same-origin proxy on
your deployment; do not disable browser security.